The Agent Factory Floor

Software teams used to describe themselves with sports metaphors. The agentic SDLC earns an industrial one: a software factory, with two levels. Above, the developer zone — where humans define, constrain, and approve. Below, the agent factory floor — where specialist agents run the line.

The developer zone

Three stations, all human:

• Define specs — intent and acceptance criteria; the contract the floor works against
• Design guardrails — security, permissions, budgets; the boundaries the line runs inside
• Review & approve — the gate between the build side and the deploy side

The geometry is the point: the human gate isn't a notification that fires while work proceeds — it's a station the work physically passes through. The deploy agent has no path that doesn't come through approval.

The floor

Each agent on the line holds a role, the way a hire would: the planning agent works as a tech lead, turning specs into sequenced tasks. The coding agent works as a senior engineer, implementing with docs inline. The testing agent is QA — running, repairing, re-running. The review agent audits like a security-minded staff engineer before any human spends attention. Then past the gate: the deploy agent ships, and the monitoring agent stands the SRE watch — including the 2 a.m. self-healing rollback that turns a midnight page into a morning report.

The half of the floor that is still people

Draw the floor and it is tempting to conclude the humans have been arranged neatly around the edges. AWS's version of this argues almost the reverse: the agents were never the hard part, and the biggest single change their method makes is to how the humans are scheduled.

The reasoning follows from the batch-size argument two sheets back. If a sprint's length is what created the queue, and agents have made construction fast, then the remaining queue is entirely in human coordination — and the fix has to be applied there. So the sprint collapses: "it should be hours or less than a day." And the requirements conversation stops being a document relay and becomes a mob elaboration — product, development, QA and operations in one room for half a day, using AI live to turn an intention into stories while everyone who would otherwise have raised an objection three weeks later raises it now.

What comes out is a set of stories broken into units of work, agreed by everyone who has standing to disagree. Construction is run the same way: small cross-functional teams, together, exchanging API specs directly rather than through tickets. Co-location can be virtual; what cannot be virtual is the synchrony.

Two smaller floor rules follow from the same logic, and both are about protecting continuity rather than adding capability:

• Contiguous blocks of time. Working with an agent means giving context, judging output, and redirecting — a loop that a meeting in the middle breaks twice over, since the developer loses flow and the run loses its context. Some Amazon teams responded by declaring afternoons meeting-free. That requires leadership cover, which is the tell that it is a scheduling decision rather than a tooling one.
• A dev environment that actually works — including for your dependencies, not just your service. A floor that can produce a change in an hour and cannot integration-test it for a day has simply relocated the bottleneck into the last room before the gate.

The feedback spine

Two more stations close the loop. The feedback agent collects what the run learned — what broke, what got retried, what the humans corrected — and writes it back. And everything the floor learns lands in a shared store that the next run's planning agent reads first.

What the floor is reported to produce, and how well that is evidenced

AWS reports results from running this with customers, and they are striking: three distributed teams across three countries closing several months of planned work in about twenty hours of mob time; a fintech launching in 48 hours an application it had planned to launch in two months.

Those belong on this sheet because this is the sheet about the floor. They belong on it with a caveat attached, and the caveat comes from the same talk.

To their credit, the recommended way in is an experiment rather than a rollout: take something already in the backlog, estimate it the way you normally would, then do it the new way and compare. The pattern they describe seeing afterwards is consistent — executive backing, one signature win, wider trials, and then local mutation, with teams inventing roles the method never specified (one group in Japan turned the scrum master into an "AI-DLC master") and wiring their own tooling in. A methodology that survives being modified by its users is usually a real one; that still is not a measurement.

What the floor stands on

Draw the floor as roles and you have drawn the org chart. Dex Horthy's version of the same factory, from the AI That Works episode he hosts with Vaibhav Gupta, is drawn as a stack instead — four layers, and a build-or-buy decision taken per layer rather than once for the whole thing. His claim is that if you understand these four layers you can make every purchasing decision from your own needs, and that the folly is buying at one layer and thereby being forced to buy everything beneath it.

• Compute — the process has to run somewhere: your EC2, your Kubernetes, or literally a stack of MacBooks in the office. Or a vendor's box, which can still sit inside your cloud. Horthy calls this the well-established layer; bring-your-own-cloud is a solved shape.
• Dev environment — the toolchains needed to compile and test, a way to preview what the agent built, and the shared services an application really has. Gupta adds identity here, not in the harness: the environment carries who the agent is and therefore which keys and scopes it can reach. Horthy calls this the most controversial layer and the one you will want to own "unless you're building tiny little toy Next.js apps" — because it is where a hundred repos and a shared dev cloud stop fitting inside someone else's base image.
• Harness — split in two. The inner harness is the loop itself: Claude Code, Codex, Amp, Devin, or something built on OpenCode or Pi. The outer harness is what you wrap around it: skills, injected tools, the compaction policy, the testing loops. You can buy a thick inner harness and keep the outer one thin, or the reverse.
• Control plane — the layer Horthy calls "the most interesting and underserved piece." Its jobs, as he lists them: dispatch new work; read session traces; read the plans and architecture docs the agents produce; schedule runs on a cron or from a webhook; review and iterate on the code, "a PR-shaped thing" that need not live in GitHub; permissions and audit — who can talk to what, who can see which service; spend and budgeting; and the compounding of what every engineer keeps telling the agent back into the outer harness.

Set this beside the floor above and the two drawings turn out to be the same machine seen from two sides. The planning, coding, testing and review agents are harness — inner loop plus outer loop. The human gate, the dispatch of specs onto the line, the budgets in the guardrails station: all control plane. The feedback spine that writes learnings back is the control plane's "compounding engineering" job. What the floor drawing leaves out entirely is the two layers underneath — and Horthy's point is that those are the ones an enterprise most needs to own.

One floor, drawn from the inside

Gupta then describes the factory Boundary actually runs, and it is worth having on the sheet because it is the first floor in this pillar drawn by the people who built it rather than by the people selling it.

Compute is a pool of MacBooks and Mac minis they own, provisioned from a repo and a script, with no containers and no boot time. The inner harness is Claude Code or Codex run headless, streaming JSON to a file; the outer harness is "actual while loops that we've built around this," which read the transcript back when a run ends. Each machine runs a local REST server with no UI. A hosted web app — the dispatcher, with its own database — listens to Slack, Linear and GitHub and talks to the machines over a tunnel. Two layers owned by choice, one deliberately not: "I want to make it swappable, because the harness is going to change all the time."

The loop that matters most is the review loop. A pull request goes to CodeRabbit; if the reviewer is unhappy the agent fixes and resubmits, and the rule is hard-coded: do not notify a human until CodeRabbit is happy, or until three iterations get hit. Only then is a person asked to read — and the person still presses merge. After the human says they are happy, a further agent babysits the rebase against a busy main branch until the change lands: "an agentic merge queue."

Why build the control plane rather than buy Horthy's? Gupta's answer is unflattering and, Horthy agrees, correct: nobody's control plane yet exposes an API surface that plugs into this team's Slack, this team's GitHub issues, this team's CLI — and every company's working style has a different definition of what an issue even is. Until the interfaces between layers are agreed — ACP and AG-UI exist, neither carries lifecycle hooks, and every harness still has its own — the control plane is the layer where the integrations are, and the integrations are the product.

One incoherent machine

Which surfaces the floor's one structural weakness, and it is not a human one.

Ten specialist agents means ten separate pictures of the system — ten chances to act on a stale service name, a moved API, a deprecated pattern. Worse, the mob rituals above raise the stakes: a room full of people agreeing quickly is only an improvement if what they agreed on is what the floor then builds against. A factory where every station has its own blueprint doesn't produce ten small errors. It produces one incoherent machine.