What is agentic orchestration?

Agentic orchestration is the layer that runs a sequence of AI steps to finish a whole job rather than a single task, and decides what needs a person along the way. A single agent drafts the reply, reads the document, or classifies the request. Orchestration takes the job from arrival to finished: it works out what kind of work this is, gathers what the next step needs, runs each step in order, carries the result forward, handles the cases that fail, and stops for a human where the consequence warrants it. The distinction that matters in practice is that one agent finishes a task, while orchestration runs the sequence of them and owns what happens between.

Why is orchestration harder than running a single AI step?

Because reliability compounds downward and state has to survive. A step that is right 95% of the time is useful on its own. Ten of those steps chained together, each depending on the last, finish correctly around 60% of the time, and the failure shows up at the end where it is most expensive to find. On top of that, every step needs to know what earlier steps decided, which means the system has to carry state accurately across handoffs, recover cleanly when a step fails partway, and avoid repeating an action that already had a real effect. The model quality is rarely the constraint. The structure around the sequence is.

How do you know an orchestrated system is working?

By testing the finished job, not the individual steps. A sequence can pass every step-level check and still produce the wrong end result, because the errors that matter are the ones that appear at a handoff. A real evaluation runs realistic end-to-end cases through the whole sequence, grades the final output against what a competent person would have produced, and keeps running after launch so quality drift is caught before a customer catches it. Alongside that, the system records what it did at each step, so any finished job can be reconstructed and explained.

Where should a person stay involved in an orchestrated workflow?

At the points where being wrong is expensive and hard to reverse. Money leaving the business, a commitment made to a customer, anything entering a professional or regulated record, and anything the system itself flagged as uncertain. The design goal is a checkpoint that a busy person can actually clear in seconds with the evidence in front of them, placed where it changes an outcome. A review step placed everywhere becomes a rubber stamp within a month, which is worse than no review at all, because it looks like control while providing none.

Agentic Orchestration: What Makes Multi-Step AI Hard

A supplier emails a purchase order at four on a Friday afternoon. Somebody has to read it, work out which customer it belongs to, check it against what was quoted, notice that the quantity changed, price it, raise the confirmation, and get it into the system before Monday. That is seven or eight decisions, and every one of them depends on the one before it.

A single AI step handles any one of those, and is now easy to demonstrate and reasonably easy to build. Hand a model a document and it will pull the fields out. Hand it a customer email and it will draft a reply. Hand it a spreadsheet and it will tell you what looks wrong. Any of these can be standing up and working in an afternoon, which is why so many businesses have one, and why so few of them have anything that finishes a job.

The gap between those two things is the subject of this piece. A task is one move. A job is the whole sequence: the enquiry that arrives, gets understood, gets checked against what already exists, gets priced, gets a reply drafted, gets a person’s confirmation where the consequence warrants it, and lands in the systems that run the business, with a record of what happened. That sequence is what a person actually does, and it is what an operation actually needs. The layer that runs it is agentic orchestration, and the plainest way to hold the distinction is this: one agent finishes a task, orchestration runs the sequence of them and decides what needs a person.

That sounds like a modest step up. It is the point where nearly all of the real difficulty in applied AI lives, and the reason is arithmetic before it is anything else.

Reliability compounds downward

Take a step that works correctly 95% of the time. On its own, that is genuinely useful. A person reviews the occasional miss, the work gets done faster, everyone is pleased.

Now chain ten of those together, each one depending on the output of the last. The odds that all ten are correct are 95% multiplied by itself ten times, which is about 60%. Four jobs in ten come out wrong somewhere. Push the per-step accuracy up to 98%, which is a real engineering achievement, and ten steps still finish clean only about 82% of the time.

That arithmetic assumes each step fails independently and that any wrong step spoils the finished job, which is the pessimistic case rather than the universal one. Real failures correlate, and a well-placed check absorbs some of them. It is still the right number to start from, because the optimistic case is the one every demonstration shows you. The chain is generally less reliable than its weakest link, and considerably less reliable than its average one.

This is the fact that separates a demo from a system, and it has three consequences that shape everything else.

The first is that per-step quality has to be much higher than it feels like it needs to be. The intuition that “95% is great” is correct for one step and badly wrong for ten.

The second is that errors surface late. A misread field in step two does not announce itself in step two. It travels, quietly, and emerges in step nine as a price that is wrong, a customer matched to the wrong record, or a document filed against the wrong job. By then the cost of finding it is far higher than the cost of catching it at the source, and the person who has to untangle it has no visibility into where it started.

The third is the one that decides whether the whole thing is worth building: the sequence has to be designed to contain error, not merely to perform steps. Steps that check each other. Steps that refuse to proceed on a value they are unsure about instead of guessing. A confidence signal that means something and gets acted on. The moment a step is allowed to pass a shaky answer downstream as though it were solid, the arithmetic above stops being a manageable problem and becomes the reason the project quietly gets abandoned.

State is the part nobody pictures

The second source of depth is less obvious and, in practice, causes more grief.

Every step after the first needs to know things. What kind of request is this. Which customer. What did the lookup in step three return. Which of the two possible interpretations did the system settle on, and how sure was it. What has already been done, so it is not done again.

Holding that reliably across a sequence is a real engineering problem, and it fails in specific, recognisable ways.

It fails when context gets passed along wholesale. Handing every step everything that has happened so far seems safe and is the most common early design. It degrades quality, because a model given fifty pages of accumulated history to answer a question that needed two paragraphs attends to the wrong things, and it makes the cost behave badly, since the bill is driven by how much each step is handed far more than by the model’s headline price. Each step needs exactly what it needs, and deciding what that is turns out to be one of the highest-return decisions in the whole build.

It fails when the sequence has no memory of its own decisions. If step four resolved an ambiguity one way, step seven must not silently resolve it the other way. Consistency across a sequence is something you build, and it does not arrive on its own.

And it fails hardest when a step has a real-world effect. Sending an email, charging a card, writing to a customer record, and booking a slot are not retryable in the way a calculation is. If a sequence dies after the email went out and gets restarted from the beginning, the customer receives two. A system that acts on the outside world has to know what it has already done and refuse to do it twice, which sounds obvious and is a specific piece of design that has to be there before launch rather than after the first incident.

Failure is a design surface, not an exception

Ask what happens when a step fails, and the honest answer for most early builds is that somebody notices eventually.

An orchestration that runs real work needs a considered answer to a short list of questions, and the answers are different for every business. What happens when an external system is down for an hour. What happens when a document arrives in a format nobody anticipated. What happens when a step returns something that is well-formed and wrong. What happens when the job is half-finished and cannot continue: does it roll back, does it hold, does it escalate, and to whom, with what context attached so that person can act without reconstructing the whole thing from scratch. That escalation path is a real job with a real cost, and who owns the work the system hands back is where more projects die than anywhere else. A good share of what lands there is a downstream system refusing the result, which is an integration problem rather than an AI one.

This is where the difference between a proof of concept and a production system is most visible, and it is the least glamorous part of the work. In the builds I have worked on, the failure paths take more of the schedule than the path where everything goes right. They are also the entire reason a business can rely on the thing, which is why an application that has to keep working after launch is a different discipline from one that has to work once.

Deciding what needs a person

The principle that a human stays on anything consequential is easy to state and gets asserted constantly, including by us. The design underneath it is where the value is.

Put a review step on everything and you have built approval fatigue. Within a month the person clicking approve has stopped reading, because nothing they have seen in weeks was ever wrong, and the one that mattered goes through with everything else. There is a name for this in the safety literature, automation bias, and it is what a review step degrades into when it is asked to cover everything. A checkpoint that is always cleared is not a control. It is a record that looks like one.

Put a review step nowhere and the first expensive mistake ends the project, and reasonably so.

The useful version sits between, and it comes from two questions asked of each point in the sequence. How costly is being wrong here, and how reversible is it. A draft reply that a person will read anyway is cheap and reversible. Money leaving the business is neither.

Getting that placement right, and making the checkpoint fast enough that a busy person actually clears it instead of rubber-stamping it, is its own question with its own arithmetic. What matters for the sequence is that the gates are placed deliberately, because a review step slower than doing the work by hand is one people route around, and then the old spreadsheet comes back within six weeks.

Permissions per step, not per system

A sequence that touches several systems raises a question a single agent mostly avoids: what is each step allowed to do.

The instinct is to grant the orchestration one broad credential that can reach everything, because it is quicker and it works. That credential then becomes the largest single piece of exposure in the business, and a system that reads content from the outside world is exactly the kind of system that can be talked into using its own tools against you.

The disciplined version scopes each step to what that step actually requires. The step that reads the document does not need permission to send mail. The step that drafts the reply does not need write access to the accounting system. Read-only stays the default until a step demonstrably needs to write, and every action taken is recorded against the step that took it, so an audit six months later can answer what touched a record and why. This costs more to set up and is the difference between a contained incident and an uncontained one. Working out what each step should actually get, and what to do when a vendor offers only full access or none, is a separate exercise worth doing before anything is built.

Evaluating a sequence is a different exercise

Testing a single step is comparatively simple. Assemble examples, run them, grade the answers.

Testing a sequence is harder in a way that catches people out, because a system can pass every step-level check and still produce the wrong finished job. The errors that matter in an orchestration are the ones that live in the handoffs, in the accumulated drift across ten steps, and in the interaction between a step that was slightly generous and a later step that took it literally.

So the test has to be the finished job. Realistic cases, start to end, graded on what came out the far side against what a competent person would have produced. That set has to include the awkward ones, since the polished path is the one that already works. Assembling that set and grading it honestly is an exercise in its own right. It also has to keep running after launch, because model behaviour changes underneath you and quality drifts without anyone doing anything wrong. And the system has to record enough about each run that a wrong result can be traced back to the step that caused it, which is a build requirement rather than a nice extra.

The part worth carrying out the door

None of what makes this hard is about the model. The model is a commodity, roughly the same one your competitor can rent. The difficulty is structure and judgment applied to one business: which steps, in what order, with what carried between them, checked where, and what happens on the day it breaks. That gets derived from how your operation actually works, including the parts that are irregular and the parts only two people understand, which is why it arrives as a design decision rather than a purchase.

Ask a vendor to show you an agent and you will see a task done well. That is a fair thing to show and it proves very little about whether your work will finish.

The questions that separate the two are short, and each of them is a piece of work rather than a sentence. What happens at step seven when step two was wrong, and who owns the ones that come back. What the system does when it is half-finished and the connection drops. Where a person confirms and why there. What each step is allowed to touch. How the finished job was tested, on how many real cases, and how you would know it had got worse.

A system that has good answers to those is doing the work. One that has an impressive demonstration and no answers is a task dressed as a job, and the difference will show up in month two rather than week one. The single agent is the easy half. The sequence is the product.

The Depth of Agentic Orchestration