Every coding-agent demo has the same shape: someone types a request into a chat window, the agent produces something impressive, the video ends. What the video never shows is the second run. Or the tenth. Or the run where the agent was confidently wrong and nobody noticed for a week.
After months of running an agent fleet against our own backlog — including the day it shipped 22 fixes to production — I've stopped believing the interesting question is "which model" or "which prompt." The interesting question is: what happens around the agent?
The chat window is the wrong container
A chat window has no memory of how the last task went, no queue, no gate, no record. Each session starts from zero and ends when you close the tab. That's fine for exploration. It's a terrible shape for delivery, because delivery is a repeated game: the same kinds of tickets, week after week, where the value comes from the tenth run being more reliable than the first, not less.
When the container is a chat window, quality depends on whoever wrote the prompt that day. When the container is a process, quality depends on the process — and processes can be fixed.
What a process actually adds
Four things, none of them glamorous:
Dispatch is a state change, not a conversation. In our setup, moving a ticket to Ready is what sends it to the fleet. The ticket carries its context — project, history, linked docs, acceptance criteria. Nobody re-explains the codebase in a prompt; the process delivers the context with the work.
Execution is recorded, not remembered. Every step an agent takes lands in a run history — inputs, outputs, retries, durations. When a run goes sideways, you read the steps. Debugging a chat transcript is archaeology; debugging a run is engineering.
Judgment has a place to live. The work pauses at gates a person opens. Not because humans review better than a second model pass — often they don't — but because someone has to own the merge, and ownership needs a recorded act: who approved what, for which change, when.
Verification is a workload, not a vibe. The most useful thing we ever added to the loop wasn't a smarter builder — it was a skeptic: a second pass of agents prompted to refute the first pass's work. Builder and skeptic as separate process steps, with separate incentives. On our loudest day that second pass caught 18 real problems in fixes that had already shipped.
"Just write better prompts" doesn't survive contact
The counterargument I hear most: all of this is scaffolding around a model problem, and next year's model will make the scaffolding unnecessary.
Maybe. But notice that we don't reason this way about people. A brilliant engineer with no ticket queue, no code review, no CI, and no deploy gate is not a team — it's a liability with commit access. We built the process layer for humans not because humans are dumb, but because delivery is a system property. Correctness under repetition comes from the system.
Models keep getting better and the scaffolding keeps mattering, because the scaffolding is where accountability lives. "Who approved this deploy and what evidence did they have?" is not a question a bigger context window answers.
The tooling gap
Here's the practical problem: the process layer barely exists as a product category. Workflow tools route events between systems but treat an agent as just another HTTP call. Agent frameworks give you the loop as a library and leave the persistence, the gates, the audit trail, and the UI as an exercise. Trackers hold the tickets but can't run anything.
So teams either duct-tape the three together — and the glue becomes the weakest part — or they skip the process entirely and run agents from chat windows, which works right up until it matters that it doesn't.
That gap is why we're building Rollout the way we are: tracker, workflow engine, and agent runtime in one system, so the process is the product. But the argument stands independent of our product. If you run agents on real work, run them through a process: a queue they're dispatched from, a runtime that records what they did, gates a human owns, and a verification pass with no loyalty to the builder.
The model is the easy part to upgrade. The process is the part you'll keep.