What Is AI Orchestration?

Every AI system in production has an orchestration layer. Almost none of them have one that anybody sat down and wrote on purpose — which is why it ends up holding the decisions nobody has read.

The incident review starts on a Tuesday morning with a customer who was charged twice and received three confirmation emails for a single order. The trace is not mysterious. Step three of an automated fulfillment run — charge the card, send the confirmation — completed cleanly. Step four, which provisions the account against a downstream service, timed out at ninety seconds. The enclosing job caught the timeout, retried, and the retry began at step one, because that is what the enclosing job has always done. Somebody in the room asks the obvious question, which is who decided that a timeout in provisioning should replay a payment, and the room goes quiet in a very particular way. Nobody decided it. A git blame on the retry wrapper lands on a commit from nineteen months ago, two lines changed, merged the same afternoon it was opened, with a message that reads "fix flaky provisioning." The engineer who wrote it left the company last spring. That two-line change is, functionally, the most consequential piece of business logic in the payment path, and it has never been reviewed by anyone who understood it as business logic.

The word people reach for when they finally name this thing is orchestration, and the word does a lot of quiet damage, because it makes the thing sound composed. Definitions in the field tend to describe AI orchestration as the coordination of models, tools, data sources, and services into a single coherent process — accurate as far as it goes, and almost useless as a description of what exists inside most companies. What actually exists is the residue of everything the team did not specify. The prompt was specified. The retrieval strategy was specified. The tool interfaces were specified, schema'd, and unit tested. The ordering, the retries, the timeouts, the question of what happens when step four fails after step three has already touched the outside world — none of that was specified, so it got answered incrementally, under pressure, by whoever was on call. Orchestration is the name for the part of the system that was never designed, and it is where the system's real behavior lives.

Orchestration is what accumulates in the space between the designed parts

The mechanism by which this happens is not negligence, and it is worth being precise about, because teams that understand it as a discipline failure will try to fix it with more discipline and get nowhere. The decisions that constitute an orchestration layer do not arrive as a set. They arrive one at a time, months apart, each one looking small enough that routing it through a design process would be absurd overhead. A vendor starts returning HTTP 200 with an error body, so somebody adds a conditional. A model call occasionally hangs, so somebody sets a timeout, picking ninety seconds because that felt safe. A downstream service rate-limits during month-end, so somebody introduces a queue. A run occasionally dies halfway, so somebody wraps it in a retry, and the retry naturally wraps the whole thing, because wrapping the whole thing is one line and wrapping the resumable part is a week of work nobody has budgeted.

Every one of those changes is locally correct. Every one of them is reviewed as what it appears to be: a small diff touching plumbing, approved in four minutes by a colleague who is reading it as plumbing. What none of them is reviewed as is the thing they collectively become, which is the operating policy of the system — the standing answer to what this company does when a process is half-finished and reality has already been altered. That policy exists whether or not it was written. It governs money, customer communications, and regulatory artifacts. It was assembled by accretion out of a dozen unrelated afternoons, and there is no document in the company that describes it, because at no point did anyone believe they were writing one.

This is also why orchestration resists the usual remedies. You cannot grep for it, because it is not a module; it is spread across decorators, config values, queue settings, framework defaults, and the implicit ordering of lines in a function. You cannot review it in a pull request, because it never appears in a single pull request. And you very often cannot find its author, because a meaningful share of it was never authored at all — it came from library defaults. Somebody's framework retries three times with exponential backoff unless told otherwise, and that default, chosen by a maintainer who knew nothing about your invoicing rules, is now the rule that determines whether a customer gets billed twice. A default is a decision that was made by someone who had never heard of you.

The logic with the largest blast radius gets the least scrutiny

There is an asymmetry running through how AI systems get reviewed, and once you see it, it explains a great deal about which failures actually reach customers. Review attention tracks the legibility of an artifact, not its blast radius. The prompt gets read by everyone, repeatedly, often by people with no engineering role at all, because it is prose and prose invites opinions. Model selection gets a comparison spreadsheet and a meeting. Evaluation harnesses get built, tuned, and argued about. All of this scrutiny is aimed at the component whose failure mode is usually a mediocre answer, while the component whose failure mode is a duplicate charge, a wrongly issued refund, or a compliance letter sent to the wrong party sits in an annotation on a decorator that nobody has opened since it was written.

The ownership pattern makes it worse. The prompt has an owner, and often a whole team. The retrieval index has an owner. Each tool integration has an owner who gets paged when its endpoint changes. The orchestration between them has no owner, because it is not a thing anyone was assigned; it is the space between the things people were assigned. In practice its owner is whoever is on rotation at the moment it misbehaves, which means it gets modified by people operating under time pressure, in the specific state of mind least suited to reasoning about a systemic policy, and those modifications are exactly what the next person inherits as the status quo. Accretion is not just how the layer forms. It is how it deepens, permanently, one incident at a time.

It is worth noting where this shows up in the aggregate numbers. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. That last phrase gets read as a warning about models saying the wrong thing, and in most real programs it is nothing of the sort. The risk that goes uncontrolled is rarely inside the model; it is in the sequence wrapped around it — in what the system is permitted to do twice, what it does with a half-completed run, and which irreversible actions it can take without a person confirming. Those are orchestration questions, and a program that has never treated its orchestration as a reviewable object has no controls to speak of, however carefully it has evaluated its model.

Making the accreted layer into something a person can read in one sitting

The remedy is not another framework, and it is certainly not a diagram drawn after the fact that describes what everyone hopes the system does. What changes the situation is moving these decisions out of interstitial code and into a declared artifact — one place where the ordering is stated, where the steps that touch the outside world irreversibly are marked as such, where the behavior of a partially completed run is written down rather than inherited from a wrapper, and where the points at which a human must sign off are positions in the design rather than a boolean somebody set during an outage. The test of whether you have this is embarrassingly simple: can a competent person who was not present when the system was built read the orchestration in one sitting and correctly predict what happens when step four fails after step three sent the email? If the answer requires reading source code across four repositories, the orchestration is still accreted, no matter what it is called on the architecture slide.

This is the argument running through much of the writing collected at Enterprise Autonomy, which treats the coordination layer — not model quality — as the thing that determines whether autonomous systems survive contact with an enterprise. It is also the structural bet behind how StudioX handles this: an AI Mission is a declared object rather than a call graph that emerged, the Reasoning Core makes the runtime judgments about sequencing and exception handling instead of leaving them to a hotfixed conditional, Observations render what was decided and why so the reasoning can be inspected after the fact rather than reconstructed from logs, and Human-in-the-Loop is a stated position within the mission rather than an interruption someone bolted on. Specialist Agents still do the work. The point of the mission is that the policy governing them is a document somebody can be accountable for, which is precisely what an accreted layer can never be.

The mental model worth carrying out of this is that your orchestration is the part of your system's behavior that no one voted on, and it is also the part that most closely resembles a policy. Every organization running AI in production has one; the only variable is whether it was written or whether it condensed. So stop asking what your orchestration layer is built on, which is a tooling question with a boring answer, and start asking what your orchestration policy says and who would put their name to it. Then run the cheap diagnostic: pick a live system, ask three engineers what happens when step four fails after step three has already sent the email, and count the distinct answers you get. Three answers is not a documentation gap that better wiki hygiene will close. Three answers means the policy does not exist, and the system has been making it up in production this whole time.