AI Agents

The Gates Come Before the Agent Fleet

A software factory is five gated stages, and the agent is the cheap part — review capacity is the real constraint.

The Gates Come Before the Agent Fleet — article cover
On this page6 SECTIONS
  1. Five stages, five gates
  2. The gate that fails open
  3. Isolation is a cost ladder, not a checkbox
  4. What the evidence actually supports
  5. The practical starting point
  6. Sources

On January 6, 2026, Stephen Toub opened nine pull requests from a phone at 35,000 feet. Seven merged. He works on dotnet/runtime, and per Firecrawl’s writeup of the pattern, his conclusion was blunt: one person with good judgment and a phone can now generate PRs faster than a team can review them.

That is the whole problem. The question stopped being whether agents can write code and became how a team absorbs the output. Firecrawl’s guide argues the answer is a software factory — and that the agent is the cheap part.

Five stages, five gates

Firecrawl describes an AI software factory as the system around a coding agent: work arrives from a queue, agents run in isolated workspaces, verification runs automatically, and a human sits at an explicit merge gate. The published examples converge on the same skeleton — intake, isolation, tools, verification, merge — whatever each company calls it.

Stage What it decides Published example
Intake Which work is worth starting Sentry’s Seer scores issues for actionability first
Isolation Where the agent runs without colliding Stripe boots pre-warmed devboxes in about 10 seconds
Tools What the agent can reach Stripe’s Toolshed exposes roughly 500 internal tools over MCP
Verification Whether the change is right Spotify’s LLM judge vetoes about 25% of agent sessions
Merge gate Who is accountable Faire requires two human reviews on agent-authored PRs

The ordering matters more than the tooling. Each gate stops work from reaching the next stage, and the expensive stages sit at the end. Firecrawl’s framing of the asymmetry is the design constraint: generation scales with spend, review does not.

The gate that fails open

Intake is where most of the waste gets created. The naive version assigns an agent to every open issue; the published versions filter first. Firecrawl also flags a second intake question almost nobody asks: has someone already fixed this upstream?

At Stripe’s reported 1,300 merged agent PRs a week, spawning agents onto solved problems is exactly the waste a factory exists to remove. Firecrawl’s developer index is pitched at that question, and the detail worth stealing is about failure modes. When you scope a search to a repo, the response includes a repos block with an indexed flag. Both an indexed repo with no matches and an unindexed repo return HTTP 200 with success: true.

So a gate written as “if no results, spawn an agent” cannot distinguish “nobody reported this” from “we have no coverage here.” It waves both through. Reading repos[0].indexed and treating false as unknown rather than clear is a one-line fix that turns a search box into an actual gate.

Isolation is a cost ladder, not a checkbox

Two agents editing one working directory is the fastest way to lose a day. Firecrawl lays out three models in ascending cost: git worktrees (files and branch, but shared ports, databases, and deps), containers (adds deps and network, still shares host resources), and cloud sandboxes (everything, plus concurrency).

Worktrees are where to start, and they hold until roughly the fourth concurrent agent. The structural note Firecrawl pulls from Anthropic’s managed agents architecture is worth more than any of the tooling choices: split the system into a stateless brain, disposable hands, and a durable append-only session log. If you build nothing else, build the log — it is what lets everything else be thrown away.

That same instinct shows up in what a hosted sandboxed shell changes for agentic tools: the value is not the shell, it is that a bad run costs nothing and parallel runs cannot corrupt each other.

What the evidence actually supports

Firecrawl cites Microsoft data from ten months on dotnet/runtime: agent PRs of 1 to 50 changed lines succeeded 76 to 80% of the time, while performance work landed at 54.5%. The published summary calls the coding agent excellent at well-specified changes, very good at investigating issues, and relatively poor at architecting solutions.

That shapes intake more than any prompt technique. A size filter and an explicit “agent-ready” label are not bureaucracy; they are how you keep the fleet inside the band where it works.

One more signal: Spotify’s Fleetshift shipped in 2023, two years before it had an agent to put in it. The gates came first.

The practical starting point

If you are building this, the sequence Firecrawl’s examples suggest is unglamorous. Pick one intake rule and one merge gate before you scale anything. Write the session log. Make your dedup check distinguish “no coverage” from “no matches,” because that is the difference between a gate and a machine that generates review work faster than you can absorb it.

The limitation is that most of this evidence is published architecture from large engineering organizations with dedicated platform teams. The supplied material does not say what the smallest viable version looks like for a five-person team, and that is the version most readers would actually need.

Sources

AI-assisted summary compiled from the sources above, reviewed by a human before publishing.

FOUND_THIS_USEFUL?

Support more practical AI articles, tutorials, and build notes.

BUY_ME_A_COFFEE
SHAREXEMAIL