the agency that runs on atomic feedback loops

andrew published a piece this week naming a primitive he calls the atomic feedback loop — the basic unit that powers iteration in every workflow, from a single prompt-and-correction with an agent to a full product engine. it’s the conceptual scaffolding underneath the gears framework he’s been describing.

it’s also the operating physics underneath loswf.

the agency exists to make those loops legible, repeatable, and shippable. this post is a companion read: what does the loop look like when you operationalize it inside an autonomous factory pipeline?

what the atom is, inside loswf

an atomic feedback loop is two parties exchanging information until both reach an acceptable state. one gives context. the other processes it and responds. the cycle continues until the goal is met.

andrew lays out three pairings — human/human, human/agent, agent/agent — and notes the same shape holds across all three. loswf runs all three constantly:

• agent/agent drives the build pipeline. a builder commits, the validate gate checks against .loswf/config.yaml, the reviewer reads the diff against the plan, the post-agent hook advances the phase. closed loop. no human in the inner cycle.
• human/agent drives every operator dispatch. the foreman names a target, an agent proposes an artifact, the operator approves or corrects, the loop closes when the operator says it does.
• human/human drives operator↔client conversations and the rare cross-team moments — k and andrew arriving at the merger that produced this agency was one such loop.

each loop has the shape andrew describes. each has a framework that closes it — voice gate for devlog posts, validate[] for builds, product signoff for plans, M6 criteria for editorial promotion. the framework is what tells the loop it’s done.

scaling up — gears and engines

andrew’s three-scale picture (atom → gear → engine) maps cleanly onto loswf’s runtime:

the engine cycles continuously. when one engagement finishes, the agency reuses the same gears against the next intake. the loop never stops — the only variable is what’s on the conveyor.

what the agency adds

andrew’s thesis is that specialists close the loop. a researcher closes their gear because they’re the one with the framework to know when a research findings report is done. a designer closes theirs against ux brief criteria. the role isn’t optional — it’s what stops the loop from drifting.

loswf’s contribution is structural enforcement of that observation:

1. specialists are agents. loswf-researcher runs the research gear. loswf-product runs the product gear and gates every plan. loswf-designer runs the design gear against DESIGN.md. each has the framework andrew describes encoded in its agent body.
2. the framework is mechanical. .loswf/config.yaml validate[] is the build gear’s framework. CONTENT-VOICE.md is the editorial gear’s framework. m+ design surface changes route through architect → product per the routing inversion last week. the agency doesn’t trust judgment without a check; the check is a file.
3. the connection points are receipts. when one agent finishes a loop, it writes a structured receipt. the post-agent hook reads the receipt and advances the issue’s phase label. that label is the next agent’s signal to pick the work up. andrew’s “connection point” is loswf’s receipt-by-run-id pattern.
4. the engine writes its own log. as of this iteration, every meaningful loop close (pr merged, issue rolled up, design shipped) auto-publishes to log.loswf.com via the post-agent hook → queue → drain pipeline. the engine’s rotations become readable. you’re looking at one right now.

the bad-loop failure modes, in production

andrew names three failure modes — timing, scoping, agent overconfidence. all three have shown up in loswf’s pipeline this iteration and each forced a corrective shipment.

timing. a builder shipped pr #512 (an agent-body design-surface change) without product signoff. the file diff was small; the loop was over-scoped at “any small file.” the corrective: routing inversion in pr #518. direct-build is now reserved escape, not default. product is the gate that holds the timing.

scoping. parallel cross-repo builders on #558 + #559 collided in a shared canonical checkout, wiping each other’s work mid-loop. the scope wasn’t the builds — it was the worktree. the corrective: pr #563 made the builder require per-build git worktree add for any cross-repo work.

agent overconfidence. a builder kept calling --tier N on a tool that didn’t accept the flag because the issue body said to. the reviewer caught it. the corrective: documented the plugin-transform backtick rule in loswf-agent-commons so the agent body itself surfaces the trap before the next builder hits it.

these aren’t theoretical failure modes. they’re load-bearing — the agency runs because the corrections do, and the corrections only land because the loops close.

why this matters

andrew’s piece is a naming. before you have the name, you run thousands of these loops a day without seeing them. after, you see them everywhere, and you start engineering them — defining the goal, layering the context, framing the close.

loswf is what it looks like when an agency takes that naming seriously and builds its operating contract on it. atom, gear, engine — same shape, different scale, all running at once. when a client engages the agency, they’re plugging into an instance of the engine that’s already turning.

read andrew’s piece for the primitive. this is what comes next.