The pitch and the practice
The public story of the last two years has been autonomy. Give the agent a goal, walk away, come back to finished work. It is a good demo and it sells software.
The story practitioners tell each other is different. It is a recurring theme in the places where people compare notes on real deployments: the systems that hold up in production are not the most autonomous ones. They are the best-orchestrated ones — clear task boundaries, explicit handoffs, deterministic checks at the joins.
I want to be careful about how strongly I put this. It is not a settled consensus with a number attached. It is a repeated observation from people running these systems, corroborated by several independent 2026 write-ups, and I have not found a credible source arguing that full autonomy is the accepted production path. Take it as the direction of the evidence, not a proof.
What autonomy actually costs
Autonomy is not free capability. It is a trade, and the thing you trade away is legibility.
A long autonomous run makes many decisions you did not see. When the result is right, you cannot tell whether it was right for good reasons. When it is wrong, the failure is usually not in the last step — it is a wrong assumption made forty steps back that everything downstream faithfully built on. Debugging that is harder than doing the work yourself, which is the worst possible outcome for a productivity tool.
There is a resource cost too, and it is the one people notice first. Independent agents each carry their own context, and cost scales with how many you are running rather than with how much work gets done. Anthropic’s own guidance on multi-agent working says as much — keep routine tasks in a single session, and reach for a team when the work genuinely justifies it.
What orchestration means concretely
Orchestration is an unglamorous word for four specific practices.
Task boundaries you can state in a sentence
If you cannot say what done looks like in one sentence, the task is not ready to hand over — to an agent or to a person. Most agent failures I have investigated were not reasoning failures. They were a brief that contained two jobs, and the agent optimised the wrong one.
Explicit handoffs
The joins between steps are where work is lost. State what crosses each boundary:
## Handoff contract
Every delegated task must state, before it starts:
- the single outcome that counts as done
- the files or systems it is allowed to touch
- what it must return: the result, the evidence, and anything it could not do
A task that cannot be described this way is not ready to delegate. Split it or do it yourself.The last line is the discipline. “A task that cannot be described this way is not ready to delegate” catches the bad delegations before they cost you an hour, which no amount of model capability will do for you.
Deterministic checks at the joins
Between steps, check with code rather than with judgement. Did the file get written. Does it parse. Do the tests pass. Is the output the shape the next step expects. These are cheap, they are reliable, and they convert a silent forty-step drift into a loud stop at step three.
This is the same argument as the verification bottleneck, applied inside the workflow rather than at the end of it. Verification you can only do at the end is verification you will do badly.
A human at the decisions, not at every step
The false choice is between watching everything and watching nothing. The useful position is watching the decisions: the moments where a choice constrains everything after it. Approve the plan, not the keystrokes. Review the diff, not the reasoning trace.
The uncomfortable implication
If orchestration is the lever, then the valuable skill is not prompting an agent. It is decomposition — the ability to take a real piece of work and break it into pieces with clean edges, each with a stated outcome and a checkable result.
That is an old skill. It is what good engineering managers and good operators have always done, and it turns out to be exactly what these systems reward. The people getting the most out of agents are frequently not the most technical people in the room. They are the ones who are best at defining work.
It also explains why so many pilots stall. The pilot tests the model. The production system tests your decomposition. Those are different exams, and the second one is the hard one.
How to tell which one you have built
A short diagnostic. For any AI workflow you are running:
- Can you state each step’s definition of done in one sentence?
- Is there a deterministic check between each step and the next?
- When something goes wrong, can you point at which step and why, in under five minutes?
- Does adding volume increase cost roughly in line with the work done, or with the number of agents you spun up?
- Are humans reviewing decisions, or reviewing everything, or reviewing nothing?
Systems that answer those well tend to survive contact with real workloads. Systems that answer them badly tend to produce impressive demos and then quietly stop being used, and the post-mortem is almost never “the model was not clever enough”.
Where this lands
Autonomy will keep improving, and some of what needs orchestrating today will not need it in a year. That is fine. The practices above do not become worthless when the models get better — clear boundaries, explicit handoffs and checks at the joins are how you make any system of many parts legible, whether the parts are models or people.
Build for orchestration and you get the benefit of every capability improvement as it arrives. Build for autonomy and you are waiting on one.
Sources
From idea to operation
Make the next AI decision concrete.
NavAIgate helps leadership teams identify high-value AI opportunities, prove them safely and turn the winners into working systems.