Formwork for agents: a reusable shape you can pour into any stage of your SDLC

For a year I thought of governed autonomy as one frame you drop over the whole SDLC. Input gate, autonomous middle, output gate, done. It looked clean on a slide. It was wrong in production.

In the real thing it was never one frame. It was dozens of nested loops, each with its own input, its own execution, its own exit. I was pouring concrete without formwork and calling the shape that came out luck.

This is the shape. It is reusable, it goes into one piece at a time, and by the end you should be able to pour it into your own pipeline instead of copying mine.

The mistake I made about governed autonomy

You do not roll governed autonomy onto an SDLC. Nobody with a real org recuts the whole pipeline in a day, and the ones who try do it badly and call the mess "transformation." A production SDLC is a fractal. Zoom into any stage and you find the same thing again: someone frames the work, something executes it, someone checks it before it moves on. Requirements have that structure. So does design, so does the release decision, so does incident triage.

So you do not replace the pipeline. You pour one loop, in one stage, and leave the rest alone until it earns the same treatment.

That is what formwork is. The form is the reusable part, the shape you clamp onto a stage before you pour. The concrete is not reusable. Every stage gets its own invariants, its own gates, its own numbers. Confuse the two and you either build one rigid thing that fits nowhere, or you rebuild from scratch every time. The whole point is one form, different pours.

Which piece do you pour first, and why requirements testing just became pourable

Three tests decide whether a stage is worth pouring into. Is the work thick, meaning a lot of repeated human labor sits there. Is it repetitive, meaning it runs often enough to pay back the cost of building the form. Is the output verifiable, meaning you can tell cheaply whether it came out right. Fail the third and you stop: no verifiable exit, no pour, the human stays.

By those tests, requirements testing is the sharpest first pour in the whole pipeline, and it only became pourable this year.

Start with the cost. A defect caught in requirements is 10 to 100 times cheaper to fix than the same defect caught in production. That is Boehm, and it has been true for decades. Requirements are the far left edge of shift-left. There is nowhere cheaper to catch a mistake.

Now the reason it stayed human for twenty years. Requirements are text and judgment. There is no code to run, no test that turns green, nothing to execute. A machine had nothing to grab. So the requirements gate was held by a human, a scarce senior QA at grooming, not because that was correct but because that was the only thing that could read intent. LLMs moved the verifiability line. For the first time the boundary of what a machine can check runs through natural language and intent, not only executable code. The one gate that was human by necessity stopped being human by necessity. It did not just become automatable. It became pourable for the first time in the history of the craft.

That also makes it the worst case, which makes it the best example. Text in, judgment out, is the hardest corner there is. A stage whose output is a passing test is easier: the machine closes its own exit gate. A stage whose output is pure taste, a product call, is not pourable at all and stays with a person. Requirements sits at the hard extreme. If the form holds here, it holds on the easier stages by construction.

I watched a team build a tool that does exactly this, aimed at the requirements stage QA used to hold by hand. It thins the thickest part of the human's work, the framing, and it has its own governed loop underneath: its own input, its own checks. One level thins the frame of the level above it, and is itself a poured piece on its own level. That is the fractal, standing in front of you, not on a slide.

We ran this play before AI. It was called shift-left.

None of this is new intent. In the pre-AI world a good QA already tested requirements before a line of code existed. Ambiguity, testability, completeness, invariants, contradictions. The job was to turn a vague business wish into a falsifiable contract, and to stand as a boundary, not a wall, between engineering and whatever the product owner walked in with that morning. Not a wall that blocks. A boundary that formats and hands it back: here are eight questions, answer them and it moves.

So why did shift-left stay a slide for most teams. Because the boundary was held by a scarce resource. One good QA, a bottleneck at grooming, slow, expensive, easy to route around. And a boundary that slows you down reads as a wall, so product treated it as one.

Here is the part that matters. Shift-left was the first derivative: we moved quality left, toward the requirement, and caught defects where they are cheap. But the moved-left work stayed thick human labor. We relocated it, we did not thin it. Agents are the second derivative: now we thin the relocated work itself. That is the whole move, and it is continuous with what QA always did, not a pivot into something new.

And it removes the exact objection that kept shift-left on the slide. The boundary is no longer a scarce human at grooming. It runs on every requirement, in seconds, for the price of nothing. When the boundary stops slowing you down, it stops reading as a wall. That is why the moment is now and not in 2019. The practice was always right. The economics were not there.

My own numbers, and treat them as mine: Bug-mits at Stenn drove production criticals down 33 percent, one factor in a broader policy. At a crypto company the same class-not-incident approach took criticals down more than 50 percent and moved ownership onto the teams. You will get different numbers on your context. The method transfers, the figures do not.

The formwork: what a governed gate actually contains

Here is the form, filled in for the requirements gate. Six slots.

Where you pour: turning a raw business wish into a falsifiable frame for development. What comes in: the raw requirement plus the product intent behind it. The autonomous middle: in the pre-AI world a QA doing this by hand, now an agent making the first pass and returning "twelve ambiguities, eight open edge cases, three requirements with no acceptance criterion, two contradictions." The exit gate: Definition of Ready, meaning the frame is falsifiable, invariants are explicit, criteria exist, holes are closed or explicitly deferred. What fails goes back to the owner. The reflection slot: a production defect that turns out to be a hole in the requirement becomes a new check on the input gate, and that class of defect retires. The autonomy dial: how much the agent decides alone versus escalates, and where a human still stands.

One form. On another stage the concrete is different, the slots are the same.

An empty frame doesn't stop the machine. It feeds it.

One disclaimer before this section, because without it the rest is slop. Everywhere here "agent" means an agent wired to the product knowledge base, to the code for context, to the artifacts, and to the operator. A bare agent with none of that is not what this is about. That is the slop everyone complains about, and it is a different, shorter article.

Now the thing that makes the input gate different from any gate a human ever stood on. A human who hits missing information stops. That is the default: something is missing, ask. An agent who hits missing information generates. Same gap, opposite reflex. Absence, to a person, is a signal to halt. Absence, to a model, is an invitation to produce the most plausible continuation.

And it is not only missing data. Ambiguity is just as fatal, and worse in a specific way. For a human, ambiguity surfaces: two people read the line differently and it comes out in conversation. For a model, incompleteness and ambiguity collapse into one failure mode. Both become a silent, confident, arbitrary choice. The model cannot tell the difference between "the data is not here" and "the data allows two readings." In both cases it samples something plausible and drives on.

An empty frame doesn't stop the machine. It feeds it.

That inverts the priority of the whole craft. For twenty years the top enemy at the requirements stage was ambiguity, because two humans would diverge. Now the top enemy is the gap the agent fills for you, silently, before anyone sees it. Ambiguity at least shows up to two people. A gap shows up to nobody until the agent has already poured something into it. Completeness moves from third place to first.

So the rails are strict and specific. The agent never invents what is not in the source. When something is missing it resolves in a cascade before it ever bothers a person: the requirement itself, then the persistent product memory and context, then the system and the code, then the operator. That is what a senior QA does and a junior does not. The junior pings the product owner about everything, which is noise. The senior remembers how it was decided last time, checks how the system already behaves, and carries up only what memory and the system cannot close.

But memory hallucinates too, and on the root gate that is the expensive kind. Stale or misapplied memory is worse than a blank, because it looks grounded, and grounded gives false confidence. So every auto-resolution from memory is an assumption, and it goes into an assumption log. That is how you catch the two different holes. The known unknown, where the agent feels the gap, gets stopped and asked, which is exactly the reach-back channel Quarterdeck exists to be. The unknown unknown, where the agent was confident and wrong, cannot be caught by a question because the agent does not know to ask. It gets caught by forcing every assumption out into the open where a human can see it. Two mechanisms, not one.

The stakes are why the rails are tighter here than anywhere. A defect at the last stage costs one unit. A defect at the input gate costs N units, where N is how many downstream stages inherit and multiply it. Height in the fractal is blast radius. So the rule for the dial writes itself: the higher the stage, the more conservative the autonomy. The requirements gate is the highest, so it is the last place you hand an agent full autonomy, because here a mistake is not local, it is systemic. This is also why bare speed is a trap. When 25 percent more AI adoption tracks with delivery stability dropping 7.2 percent, and frontier agents now finish alone what took a human around five hours, the executor got faster and the frame did not get better. Faster pour into empty formwork is just more concrete on the floor.

I have watched this from the other side too. I generated 1300 articles through a pipeline, and every bad one came from the same place: a thing I had not put in the frame. Never the model. The frame.

One dial runs the gate, and readiness is a number

If you tried to make readiness mean "every question answered," you would never ship. A diligent agent asks infinite questions, and most are small-radius noise: what color is the button. Chase all of them and the gate becomes a wall again.

So readiness is not completeness. It is risk-weighted completeness. The frame is ready when there is no open question whose blast radius crosses your threshold. Weight each question by two things, not one: how many downstream stages a wrong answer corrupts, times how irreversible it is, meaning can it be fixed cheaply later or does it set like cement. A big-radius question that is trivial to fix downstream can wait. A big-radius question that cements blocks.

And that threshold is not one setting among many. It is the single dial that runs the entire gate. A question below it, the agent auto-resolves and logs the assumption. A question above it, the agent escalates to a human through reach-back. Readiness is defined as no question left above it. Turn it up and you get more autonomy and a wider blast radius on the agent, which is fine on cheap downstream stages. Turn it down and you get conservative, close to the source, which is what the requirements gate needs. Your autonomy dial and your readiness bar are the same knob seen from two sides.

You don't validate a spec. You watch what chokes on it.

You cannot validate a specification against the truth, because at that stage the spec is the truth for everything below it. There is nothing above to check it against without falling into "who checks the checker" forever. So you check two cheaper things. In the moment: internal properties you can test on the spec itself. Does every requirement have a falsifiable criterion, are there contradictions, does every claim trace to a source with no dangling assumptions. That is not a bottleneck anymore, because judging text is exactly what the machine can now do. And on the seam: the output of a stage is validated by whether the next stage can consume it without coming back to ask.

On a gate you don't want the smartest reviewer. You want the most reproducible one, and the most honest about what it doesn't know.

The goal on that seam is precise. You want the next stage to choke on the input, not halfway through its execution, and God forbid at its own output. Choke at the door and the defect never propagated. Choke deep and it already multiplied. Which means the two checks are actually one mechanism with two observers: the receiving stage runs the same cheap self-validation on the frame it was handed, before it starts executing.

That gives you a real number. Run the next stage's agent dry against the frame and count how many times it reaches back for missing information above your threshold. Zero means the frame is ready. Many means it is full of holes, send it back. Reach-back frequency on a dry run is your readiness metric, and it makes Quarterdeck two things at once: the help channel in production, and the readiness gauge on a dry run.

One more thing, because a real SDLC is half-migrated and stays that way. The next stage does not have to be an agent. It can be an old manual process, a person with a checklist. The gate contract does not care, because it is defined by a property, consumability, not by who stands on the other side. A person chokes on a broken frame the same way an agent reaches back. This agnostic seam is not a detail. It is the condition that makes "pour one piece" possible at all. If the gate required an agent on both sides, you could only pour the whole SDLC at once, which is the thing we already said nobody can do.

But note the asymmetry, because it matters for calibration. The consumer and the instrument are different roles. A human consumer is a kind measurer and therefore a poor one: he silently fills small gaps with common sense, which hides the defect in the frame. So even when the real next stage is manual, keep an agent with the no-invent rail as your test consumer on the dry run. It surfaces the holes a person would quietly paper over.

The uncomfortable part: on a gate, the machine beats the human

Say it carefully, because the loose version is wrong and gets torn apart in ten seconds. Not "people are less reliable than AI." A person is often smarter than the agent on a specific question. But on a gate, the person is less reliable, and for an unexpected reason: the things that make a human good make him a bad control.

His virtues are the gate's vices. He fills the unspoken gap with common sense, usually correctly, and in doing so hides the fact that the frame had a gap. He smooths, he does not make noise over small things, he moves on. On a gate you want none of that. You want the opposite.

The agent wins on exactly two axes. Reproducibility: it applies the same check to requirement number one and requirement number five hundred, does not get tired, does not cut the corner on Friday, does not forget the edge case that was on the list. And honesty about the edge of its knowledge: forced by the rail, it dumps the assumption into the log instead of masking the gap with itself. Not because it is more intelligent. Because human virtue, on a control point, works against you.

And the sharp caveat, or the whole claim rots. This is true only with the rails. A bare agent is the worst gate of all: it invents like a human but wrong, and without the human's nose for "this smells off." The reliability lives in the formwork, not in the model. Take the form away and the gold turns back into a pumpkin. Which loops the whole thing shut: the value was never the AI. It was the shape we poured it into.

That asymmetry is also your warning label for pouring one piece at a time. On the seam where an AI stage hands to a human, the human forgives holes, papers them over. On the seam where a human hands to an AI stage, the agent exposes them, if it has the rails. Know which seam you are standing on. That is the whole difference between a migration that surfaces its own defects and one that buries them a stage downstream.

This is a frame, not a recipe

I am not going to give you the numbers, because a recipe with numbers lies. Everyone's context is different. What the form gives you is three things. The slots, so you know what you even have to decide, which is how you avoid forgetting the assumption log and eating an unknown unknown. The admission valve, the three tests that say pour here or leave it human. And the instrument, the dry-run reach-back count, so you can find your own values instead of guessing them. The absolute values are yours. "Find them yourself" without an instrument is not a frame, it is a shrug. The instrument is the part that makes it a frame.

And there is a bottom to the recursion, so nobody asks who gates the gate forever. You stop where the invariant is so cheap and so stable that a human architect maintaining it by hand is cheaper than any automation. That is the floor of the nesting, and a person stands on it on purpose.

Which is where the QA goes. Not away. Up. Off executing the boundary by hand and onto designing it: which checks live in the gate, which invariants are mandatory, where the dial sits, which production defect earned which new check on the input. The scarce resource stops being the bottleneck and becomes the architect of the gate. That is the QA-as-systems-judge, the person who says "this won't survive production, rewrite it," except now he says it to the shape of the machine, not to a pull request.

I left one whole thing out on purpose. When reflection fires and tells you something is broken, the fault can be anywhere in the SDLC, not in your poured loop, and locating it is its own discipline with its own rules per stage. That is the next piece, not this one.

For twenty years QA was the role you apologized for. It turns out it was the input gate all along, held by a person because nothing else could read intent. The machine can read intent now. The person who spent a career testing requirements does not lose the job. He designs the form the machine pours into. Clean code was always copper. This is where the gold was.