Nothing enters the estate ungrilled

The short version

Bottom line. Give an AI agent the ability to write, test, deploy and close its own work and the bottleneck stops being execution. It becomes admission — deciding what is allowed to become work in the first place, and proving afterwards that it was really finished. Twenty-six commands now run that corridor, and each one fires at a moment rather than on request.

• What it cost — a fabricated cause reached an approved plan and three units of work before a benchmark killed it. The measurement was real; the reason given for it had never been observed.
• What changed — every idea now walks the same corridor: captured, triaged, interrogated, sequenced, delivered, then supervised in production before anyone may call it done. 449 pieces of work have been through it; 322 are closed.
• What still needs work — the last gate is the weakest. 14 pieces of work sit in supervised production and 12 are past their review date, because closing that stage is still done one at a time, by hand.

The bottleneck moved, and nobody moved the controls

Traditional delivery is rate-limited by build time. An agent that can implement a change, push it, wait for the pipeline, verify it against the live system and write the documentation is not rate-limited by any of that. It is rate-limited by how fast someone can decide what is worth building — and an agent will accept that decision from anyone, including itself.

The failure that made this concrete is worth stating plainly, because it looks like success right up to the end.

A performance audit measured a build step taking 177 seconds across nineteen invocations. Real measurement, correctly done. The agent then explained it — container startup overhead — and projected a saving of about 157 seconds. The explanation was approved, a plan was created, three units of work were written under it, and implementation began.

Startup was 0.7 seconds. The real saving was around nineteen seconds, not a hundred and fifty-seven. It surfaced only because a benchmark happened to run before the change was pushed.

A measurement is a finding. The reason for it is a hypothesis. Nothing in the process had distinguished between the two, because the agent had produced both in the same breath, in its own voice, with no seam between measuring and concluding. There was no bad data and no bug to fix. The gap was procedural: the idea became work without anything having tried to break it first.

Nine doors, and a command waiting at each one

Each box is a command, and the design rule is that a command fires at a moment, not on request. The end of a session triggers the wrap-up. The closing of the last unit of work triggers the readiness review. A review date arriving triggers the close-out. Where a step depends on somebody remembering to invoke it, it does not get invoked — which is exactly what happened when the handover material was four bullets at the bottom of a checklist rather than a discipline with its own name.

Stage	What it actually does	What it refuses
Capture	Files a raw idea in seconds. Never asks questions, never blocks	Nothing — the whole point is that capture is free
Triage	Walks the backlog and asks whether each item is still true. Kills the dead, merges duplicates, enriches the survivors	Leaves nothing vague enough to design against
Interrogate	Four layers of adversarial challenge against the proposal, ending in an explicit approval gate	Proceeding on an unexamined because
Sequence	Builds the dependency graph across the approved queue, orders it to get work out fastest, writes the position onto the card	Sequencing anything stale enough to need re-challenging
Deliver	One disposable sub-agent per unit of work: implement, push, wait for the pipeline, prove it, document it, return a verdict	More than two failures before halting the whole run
Wrap up	Config-as-code, documentation, monitoring coverage, security, decisions recorded, loose findings routed	Closing while any finding is unrouted
Readiness review	Asks one question: can this be judged, weeks from now, by somebody with no memory of it?	Parking a known liability into production
Supervised window	A dated period in production with the work still open and still owned	Going straight from built to done
Close out	Re-runs the acceptance criteria against the live service	Closing on the strength of the original claim

The gate that exists because approval is not proof

The third door is the one that changed the estate’s behaviour, and it is deliberately unpleasant. Before any proposal becomes work, it is interrogated across four layers — the premise, the design, the operability, the failure modes — and it does not pass because it survived. It passes because the person accountable for it says so, explicitly, at a close-out gate.

Two rules make that gate load-bearing rather than decorative.

The agent is not allowed to create work on its own initiative. Creating a unit of work is a commitment carrying a lifecycle, a delivery report and a review; it is not a note. Before this rule, any stray observation became a new item, and the board reached 119 open commitments, 50 of them with no live work underneath at all and 45 untouched for over a month. Untrackable. An approved interrogation is now the only thing that authorises creating one.

An approval given to an un-interrogated proposal is a reason to stop, not a licence to start. That is counter-intuitive and it is the exact lesson from the 177-second failure: the plan was approved enthusiastically, by the right person, on the strength of a cause nobody had checked. So when work arrives already blessed, the correct response is to say the gate has not been run and offer to run it — and then honour an explicit override, made against a stated objection rather than inferred from enthusiasm.

Delivery is fanned out; the decision-maker’s attention is not

Once work is admitted, the constraint inverts. Now the goal is to burn as little human attention as possible, and the main thread is treated as the scarce resource it is.

Each unit of work is handed to a disposable sub-agent that owns it end to end — writes the change, pushes it, waits out the build, proves it against the live system, writes the documentation — and returns a short structured verdict. Its working context is then thrown away. The main thread sees the verdict, never the transcript. That is what makes a long delivery run survivable: the expensive, noisy part of the work never accumulates where the decisions are made.

Three constraints keep that from being reckless.

• Changes are strictly serial. One unit at a time, because parallel units push to the same repositories and would collide in the build queue.
• The run halts after two failures. A blast-radius cap, not an alarm.
• A missing verdict is not a failure. An agent that returns nothing is asked again before anything is recorded — and the outcome is never inferred from what its work appears to have done.

The same shape now answers the backlog of overdue supervised windows: fan the review out, keep the verdicts in the main thread, and let the person handle the next thing that genuinely needs them rather than watching a build run.

What the corridor has actually moved

Signal	Where it stands
Work items through the pipeline	449, of which 322 are closed
Closed per month	52 · 121 · 85 · 63 over four months
Lead time, idea captured to work closed	median 47 days, ninetieth percentile 90 days
Work closed within a day of being captured	8 of the last 63 — the corridor is not the only path, and small things still move fast
Currently open	127 — 50 unfiltered, 37 triaged, 18 approved and waiting, 8 in flight, 14 in supervised production
Decisions written down	501 architecture decision records, 27 standards, 52 design documents
Named traps captured	448, each one a mistake paid for exactly once

The lead-time figure is the honest one and it is mostly queue, not work. Forty-seven days from idea to closed, on a queue with 87 items waiting in front of the approved ones, is a statement about appetite rather than about throughput. The pipeline’s job is not to make that number small — it is to make sure that nothing crosses the line without having been challenged, and that the ordering reflects dependencies rather than whoever shouted last.

How we know the gates were really passed

The temptation with a staged pipeline is to record the current stage. That was the original design and it was wrong: a single field saying where this is now went stale silently, and every rewrite destroyed the history of how it got there.

The gates now leave receipts that accumulate and are never removed. Passing the triage gate adds a mark. Passing the interrogation gate adds another. Entering supervised production adds a third, closing out adds a fourth — and the completed item carries all four for the rest of its life.

The point is that a skipped gate stays visible. Work marked finished but carrying no interrogation receipt is a delivery that never had an approved design, readable months later on the record itself rather than overwritten on the way past. Today 39 items carry the interrogation receipt and 104 carry the triage one, against 322 closed — most of the estate predates the gates, and the record says so honestly instead of implying otherwise.

Where this is behind the industry

The last gate does not drain itself. Every other stage fires on an event. Closing out a supervised window fires on a date, one item at a time, invoked by hand — so twelve are overdue, the oldest by a week. A stage that depends on somebody remembering is the stage that decays, which is the argument the rest of this pipeline is built on. It needs the same treatment: sweep the whole column, fan the reviews out, return verdicts.

Closing a work item is still an assertion, not a proof. Every item carries acceptance criteria, written at design time and required by the contract — and nothing executes them at the moment of closing. Their presence reads as verification that never happened. One closed item owned the removal of an obsolete synchronisation job; the job was still running weeks later, and the record said finished. Closing it had deleted the only thing tracking the obligation.

The queue is longer than the appetite. Fifty items sit unfiltered and thirty-seven triaged against eight in flight. That is not a pipeline problem, but a corridor that admits work faster than it delivers it will eventually stop being trusted, and the honest control is to stop capturing or to start killing.

Domain classification is patchy. Only 131 of 449 items carry the tag that says which discipline the outcome serves, because the rule arrived after most of them did. Reporting by domain is therefore an estimate presented as a fact.

Next steps

1. Make the close-out gate a sweep, not a single-item command. One invocation, every overdue window, reviews fanned out, verdicts returned to the main thread.
2. Execute the acceptance criteria at the moment of closing, and show the result. A claim of done should be produced by the system rather than asserted by whoever did the work.
3. Put a number on the queue’s growth rate against its drain rate. Today both are visible and neither is charted, so the gap between them is only noticed when it is embarrassing.
4. Backfill the domain classification so reporting by discipline stops being an estimate.

Related

• Delivery and GitOps — the pillar this sits under
• The change lifecycle — the same corridor, drawn live from the record
• ADR-0403 — delivery as a verb, and the envelope an agent may act inside
• ADR-0389 — supervised production is an enforced stage, not a courtesy
• ADR-0372 — where findings go when they are not the work in hand
• When the memory ran out, every fact got a lifespan