You govern machines. You manage people. Now your team is both.

Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027. Not because the models are weak. Because of escalating cost, unclear value, and missing controls. Read it again: the projects die from the operating model, not the model.

I have spent five years running delivery. Here is the thing nobody warns you about when you drop AI into an engineering org: the code was never the hard part. The code ships. The org around the code is what cracks. Tokens burn, output is a lottery, quality is a coin flip, nothing compounds, and the lead quietly becomes the bottleneck again. People look at that and conclude AI is bad. It is not. The frame around it is missing.

This is the spine of how I think about that frame. I call it two names because it lives on two floors: Governed Autonomy at the engineer level, Managed Autonomy at the org level. Same shape, different floor. Everything below is one of those two, and each section here is a door into a longer piece.

The executor changed. The discipline did not.

For most of my career delivery was one job: make the frame and the validation predictable, scalable, repeatable, so projects stop dying on the soft middle where nobody owns the truth. At Stenn I cut production criticals by 33% as one lever in a broader policy. At a crypto company I cannot name, criticals dropped over 50% once ownership moved to the teams. Different companies, same move every time. The discipline never changed.

What changed is who holds the keyboard. The executor used to be a person writing code. Now the executor is a model writing code and running its own loops. That is the whole shift, and every other consequence falls out of it.

Here is the part people miss. When execution moved to the machine, the value and the difficulty moved with it. They did not disappear. They relocated into the two things the human still owns: the frame you set going in, and the judgment you apply coming out. The question stopped being "can AI write the code." It can. The question became "how do you run framing and validation at scale so the flow is predictable and actually pays off." That is not a pivot into AI. It is the same job I always had, with a faster, dumber, tireless executor inside the frame.

You govern machines. You manage people.

Once execution leaves the human, two control jobs remain, and they are not the same job.

The engineer now runs a fleet of agents. There are no people underneath an engineer in that loop, so the work is pure rule setting: specs, rails, gates, limits. You hand the agent a frame and let it move autonomously inside it. Freedom within the frame. This is Governed Autonomy. You are governing a non-human executor the way you govern a process.

The manager runs the system the engineers live in: standards, single source of truth, stage contracts, cost, the org-level reflection loop. Underneath a manager there are people, each one already governing their own fleet. So the manager's work is people plus the system those people run in. This is Managed Autonomy. You are managing humans who are themselves governors.

Governance here is not the boardroom kind. You govern a machine the way you govern a process: rules, limits, gates. You manage a person. The split tracks who is underneath you, not how senior you are.

Berkeley's California Management Review landed on the same convergence from the top down. Their March 2026 piece on governing the agentic enterprise argues that agentic failures come from misalignment across organizational layers, not from weak models. I got to the same place from the floor, with my hands on the fleet. The verbs are doing real work here. You govern a thing that has no career, no motivation, no growth path. You manage a person who has all three. The moment your team is both at once, you need both disciplines, and most orgs are trying to run the whole thing on one.

Why does AI feel bad at your company?

Because most teams eat AI from the tail. They take the raw output as clay and patch it, iteration after iteration, until it vaguely resembles what they wanted. That is slow, it never compounds, and it is the actual source of the "AI is bad" myth. "AI is bad" almost always decodes to "I cannot frame and validate."

Clay is not the villain, though. Clay is the right method in exactly one place: the frame. Up front, uncertainty is high and you genuinely cannot spec what you do not understand yet. So you open the frame by shaping it, iterating with the model as a thinking partner until the fog hardens into a real spec. That is what front-loading actually is. Not "magically wrote a perfect spec." Shaped a spec out of clay before any execution started.

The industry caught up to this and named it. Spec-driven development and context engineering both say the 2026 bottleneck is not generation speed, it is drift: confident, plausible code that quietly solves the wrong problem because nobody grounded it. GitHub reports teams on Spec Kit ship with roughly an order of magnitude fewer regenerate-from-scratch cycles. Same law, dressed in someone else's vocabulary: shape the clay at the front, then execute clean. The people patching output at the tail skipped the only stage where clay belongs.

The three laws that hold it

Strip the frame down and three invariants hold the whole thing up.

The law of preparation. Quality of preparation is proportional to stability of output, and inversely proportional to the attention you have to spend later. Preparation means collecting context and describing the task so completely that the description answers its own questions before they are asked. The output of that stage is real project and technical documentation, which is just another word for the frame.

Every return edits the input. Any control gate, review, QA, acceptance, can bounce a task back. Most teams have the correction loop: rejected, returned, redone. That is just rework. It builds nothing. The reflection loop is the part that matters: every return triggers one question, why did this come back at all, then root-cause, then a fix to the preparation or the SOP, and that entire class of defect retires forever. The default address for that fix is the input, because a return almost always means the frame was underspecified.

Every return edits the input. The correction loop redoes the work. The reflection loop retires the defect.

Managed autonomy, not unsupervised autonomy. The human sits on the entry and the exit. The middle is autonomous by construction, not by hope. The gate shrinks as the system matures, but accountability stays human and does not get delegated to the fleet. This is not "autonomy is impossible by nature." It is "the gate is here today, and shrinking it is my job."

What does the delivery loop look like?

Seven stages with exactly two human gates. Idea becomes a frame at the entry. The frame becomes a product at the exit. Between them the work runs itself.

Preparation, a human gate, turns the idea into documentation that answers questions in advance. Orchestration plans and decomposes on that context. Delegation hands clean subtasks to sub-agents, one agent, one task, one definition of done. Autonomous execution runs self-check loops inside the docs. Review is a separate reviewer agent checking the result against the spec, because an executor is a bad judge of itself. An optional QA loop goes deeper only on risky changes. Acceptance, the second human gate, is where you take the result and judge the system that produced it.

The human is compressed into the two edges. The middle is autonomous because the frame made it autonomous, not because you crossed your fingers. I will break down each stage and its handoff contract in its own piece, because the contracts between stages are where this stops being a diagram and starts being a system.

It does not replace agile. It sits on it.

None of this throws out your process. It lays on top of it. Preparation is backlog refinement plus a definition of ready. Orchestration and delegation are planning and assignment. Execution is the sprint. Review is PR review. The QA loop is testing. Acceptance is the demo. The reflection loop is the retro, except continuous instead of once a fortnight.

The manager did not disappear. The manager changed altitude. You used to guard the hygiene of a process run by people. You now guard the hygiene of a process run by people and their fleets: predictability, blockers cleared, the health of the loop. That is the conductor-of-the-fleet role, and it is the part Gartner's 40% are missing. The model was never the question. The system around it always was.

That is the bet. Predictable, self-improving delivery where neither the lead nor the team is the bottleneck, run on two floors: govern the machines, manage the people, and let every return make the whole thing smarter.