This page covers six control surfaces and 22 practices. It also covers five ways a fleet fails and the metrics that catch review debt early. This operating model sits behind every merge request on this site. It is not a sales pitch.
Most writing about managing AI coding agents is vendor marketing for an orchestration product. This page is different. It describes the operating model this studio runs. The same model landed the merge request that shipped this page. Every fleet we have run, and every fleet we have read about, shows one finding. Once generation is cheap, review throughput is the bottleneck. Model capability is not.
Each of the six control surfaces has a named owner and prevents a specific failure. If you skip one, the fleet does not get slower. It gets faster at producing work that nobody can trust.
Each one governs a different thing. A fleet with a missing surface fails without noise. The failure looks like progress.
Owner: The person who writes the task: a tech lead or the engineer who requests the work
The acceptance criteria a task carries before an agent starts, and whether 'done' has a checkable definition
Owner: The owner of the sandbox and orchestration layer: the fleet operator
Whether two agents can touch the same mutable state at the same time
Owner: The orchestration harness and the pipeline definition. No single agent owns them
The sequence a task moves through, and what a fresh context inherits at each hand-off
Owner: The owner of the review queue: a tech lead or the review-stage configuration
How many tasks can be in flight before the review queue grows without bound
Owner: The curator of workspace memory: often a lead engineer or the fleet operator
Whether every later session has to re-argue a decision that was made once
Owner: The owner of the harness's budget defaults: the infra or platform owner
The ceiling on any single loop's steps, tokens, wall-clock time, and cost, and the gate every landing path must pass
Filter by maturity (crawl, walk, run). Then copy the visible list as a Markdown adoption checklist.
Showing all 22 practices
Task specificity caps output quality. Model capability does not. Give an agent "add authentication" and it will produce something that runs. That something may have little to do with the need. The agent filled the gaps itself, as anyone would when the ask is underspecified. A task is a spec. It has background and a named goal. It also has explicit constraints and an acceptance criterion. Someone can check it without asking the requester what they meant. A chat-prompt task is faster to write. It also gives you a confident, well-executed answer to the wrong question.
Fleets of coding agents fail on shared mutable state long before they fail on reasoning. Two agents edit the same file. Two tasks change a shared dev database at once. One agent's blanket add picks up another agent's uncommitted work. The model did not cause any of these. Better prompting cannot fix them, because the failure is architectural: two writers share one piece of state with no ownership boundary. The fix is plain and mandatory. Give each task one branch, one working tree, and one sandbox. A task that misbehaves then has a blast radius of one task.
A fleet needs named stages with named exit artifacts. The agent does not decide for itself when it is done. Plan produces a plan. Code produces a diff and an open request. Review produces a verdict. Merge produces a merged change. Verify produces a pass or a routed-back failure. Every stage starts a fresh context. That context inherits only what the previous stage wrote down. A stage that cannot advance releases the slot. It does not loop in place and wait for input that will not come. Skip a stage, or let an agent self-certify that a later stage is unneeded, and the fleet reverts. It becomes one long, ungated context that nobody can audit.
Once generation is cheap, review is the bottleneck. More agents without more review capacity do not raise throughput. They grow a queue of unread work. The fix has layers. Machine review runs first. It is adversarial and independent, and it catches what a first pass misses before a human opens the diff. A human then reviews decisions and the diffs that carry risk. Nobody has the attention to read every line of every PR. A fleet sized past its review capacity ships no faster. It converts engineering hours into a growing pile of merge requests that nobody has read.
A fleet that forgets re-argues the same decision every session, at the same cost. It reaches a different answer half the time. The reasoning that settled the question last time lived in a context windowThe context window is the maximum text, measured in tokens, a model can consider at once. that no longer exists. Conventions drift the same way. Every fresh agent invents its own idiom for a problem the last agent already solved, because nothing durable told it otherwise. The fix is memory that outlives any single session. It is shared and versioned at workspace level. People curate it so that it does not grow into an unread pile. A per-tool cache dies when the process exits and does not meet this need.
Every agent loop needs an explicit ceiling on steps, tokens, wall-clock time, and cost. The harness enforces the ceiling. The model cannot, because it has no reliable internal sense of when to stop after six failed tries. Every landing path also needs a gate that no agent can bypass. Never push directly to the default branch. CI is the arbiter. A budget that runs out forces a terminal state. The loop does not idle forever. Skip either control and the failure takes the same shape twice. A retry storm turns a two-dollar task into a two-hundred-dollar task. Or an unreviewed 3am change goes unnoticed until it is live.
No practices match that combination. Clear a filter to see more.
Each of these looks like an agent capability problem from the outside. None of them is one.
Looks like: Merge lag climbs while "throughput" improves. The fleet completes more tasks, and a longer queue of them waits to ship.
Guardrail: Cap in-flight tasks at the review capacity you have. Run machine review before human review.
Looks like: The agent writes the tests that it then passes. An all-green suite says nothing about whether the feature is right.
Guardrail: Have a different context author the acceptance criteria before the code stage. Make verification its own stage.
Looks like: Every agent invents its own idiom for the same problem, because nothing durable told it what the last agent decided.
Guardrail: Durable memory plus house conventions that the fleet reads. Lint and CI enforce them. Hope does not.
Looks like: The agent improves things that nobody asked for. The diff is twice the size that the task needed.
Guardrail: Name the scope in the task. Review bounces diffs that touch files outside the stated files.
Looks like: A loop costs forty times the estimate. The team finds out on the monthly invoice and not while it happens.
Guardrail: Hard ceilings, a per-task budget and "release, don't stall" in place of idle looping.
You can measure each of these today. Each one can look better than it is.
This page has no invented metrics. It has no throughput multipliers and no client names. It states what this repository's own history proves.
The capability list this research associates with high-performing delivery teams. Retrieved 2026-08-24.
The research programme behind the delivery metrics our release and delivery pages measure. Retrieved 2026-08-24.
The method for setting a service-level objective our release scoreboard follows. Retrieved 2026-08-24.
CodeHerder is the task registry and per-task sandbox layer that runs this operating model day to day. It is the how behind the why on this page.
What teams ask us before adopting this operating model.
No. Vibe coding is a chat prompt and a hope. This model uses a written spec with a machine-checkable acceptance criterion, an isolated sandbox, and a named stage sequence. A verification stage runs after review. A human does not eyeball the output and call it good.
Link to this answer: Is this just vibe coding at scale?Review, once generation is cheap. More agents do not raise throughput if review capacity stays fixed. They grow an unread queue with a faster-looking front end. Machine review before human review is the fix. See the review-throughput surface above.
Link to this answer: What's the bottleneck?Something has to implement the six surfaces. Isolation, stage gates, and spend ceilings are hard to run by convention alone. The framework is an implementation detail. Judge any tool by whether it gives you these six things. Ignore its feature list.
Link to this answer: Do we need a framework or an orchestrator?Isolation: one task, one branch, one working tree, one sandbox. It is the least glamorous of the six surfaces. It causes the most damage when you skip it. See the isolation surface above.
Link to this answer: How do you stop two agents breaking each other's work?This operating model covers how work gets delivered. It does not cover compliance sign-off. Those are a different set of questions, and they are real. Our AI Security Review has the InfoSec, privacy, risk, and procurement checklist that a regulated system must also clear.
Link to this answer: Does this hold up on regulated or audited code?No. Review throughput is the human bottleneck by design. Do not engineer it away. The review and stage-gate surfaces exist to apply a senior engineer's judgment efficiently across more work.
Link to this answer: Does it replace engineers?Pick two surfaces and leave the other four. Start with task definition (require an acceptance criterion on every task) and spend and blast radius (a hard ceiling and branch protection). Both are crawl-maturity and cheap. Together they prevent the two failure modes that do the most damage.
Link to this answer: How do we start on Monday?Fleet control needs more than agents that pass their own tests, since a green suite can still hide a broken feature. CodeHerder runs all six surfaces this playbook maps, across the whole fleet.
Source: https://customlabs.io/agentic-delivery/