The point where enterprise AI stops
Most large organisations already run dozens of AI components. One classifies support tickets. One flags suspicious transactions. One summarises documents. Each works well inside its box. The value stops at the edge of the box, because the moment a piece of work crosses from one system to another, a person, a script or an email has to carry it.
That is the state of enterprise AI in most companies today: intelligent in parts, manual in between. Agentic AI promises to close the gap by letting software plan, act and hand off work across systems. The promise is real. It is also where most pilots fail, because teams add agents without adding the thing that lets agents work together: orchestration.
What orchestration is
Orchestration is the control plane for a system of agents. It decides which agent does which task, in what order, with what context, under which rules, and what happens when something goes wrong. It is the difference between a set of clever components and a system that can be trusted with a process.
Three things it is not:
- It is not workflow automation. Automation executes fixed steps. Orchestration handles ambiguity, long-running tasks, and decisions that depend on what happened upstream.
- It is not prompt chaining. Chaining passes one model's output to the next. It has no shared state, no governance, and no way to change course mid-task.
- It is not a bigger model. One model asked to do everything carries every responsibility, every tool and every risk in one place. Orchestration separates them.
Why it matters now
Four pressures are pushing orchestration from an architecture choice to a governance requirement.
Agents are starting to act, not just answer. When an agent can issue a refund, change a record or send an email, the question "how did it decide" stops being academic.
Complexity grows faster than headcount. Every new agent brings its own prompts, tools, assumptions and failure modes. Without a coordinating layer, logic duplicates, context fragments, and failures propagate in ways nobody designed.
Cost needs discipline. Uncoordinated agents default to the most capable model for everything. Orchestration lets routine classification run on a small model and escalates to a large one only where the stakes justify it.
Regulators and risk teams are asking new questions. Not "what was decided" but "which data was used, which rules applied, and who could have stopped it". Orchestration is where those answers are recorded.
What a working orchestration layer does
In our experience the layer has eight jobs. Skip one and the system will tell you which, usually in production.
- Task routing. Decomposing a request into subtasks and assigning each to the agent built for it, based on capability and current system state.
- State and context. Preserving what has happened across handoffs and long-running work, and giving each agent only the context it needs.
- Inter-agent communication. A standard way for agents to exchange information and return results, so integration is designed once.
- Policy enforcement. Applying security, privacy and business rules at execution time, not in a review afterwards.
- Observability. Telemetry across every agent: latency, cost, failure conditions, and the path each decision took.
- Error handling. Detecting failure early, retrying where safe, and stopping where not.
- Human-in-the-loop. Escalating specific decisions to a person with full context, without pausing the whole workflow.
- System integration. Mediated access to CRMs, ERPs, data stores and external services, so no agent hard-codes a credential or bypasses an access policy.
Where it pays back first
Not every process needs orchestrated agents. The ones that do share a shape: they cross systems, run for a long time, or require decisions under uncertainty.
- Cross-system operations such as order-to-cash or incident response, where one agent validates, another retrieves, a third applies rules and a fourth acts, and a partial failure must not corrupt state in three platforms.
- Long-running investigations and approvals such as compliance reviews or procurement, where context must survive hours or days and ownership must stay clear.
- Decision-heavy workflows with escalation such as credit or risk assessment, where separate signals are consolidated, confidence is measured, and borderline cases go to a person with the reasoning attached.
- Analytics that should trigger action, where forecasting and scenario agents reconcile their outputs and then rebalance stock or adjust pricing rather than stopping at a dashboard.
- Customer service that changes shape mid-conversation, from a general enquiry to a billing dispute to a compliance concern, without losing context or authorisation.
How to start
Three recommendations from the engagements where this has gone well.
- Pick one process that crosses a boundary. Not the biggest, the one whose manual glue is most visible. Map every handoff and every decision before writing a prompt.
- Design the control plane before adding agents. Decide how state is stored, how policy is enforced, and where humans intervene. Agents are easy to add to a good control plane and impossible to govern without one.
- Instrument from day one. If you cannot see latency, cost and decision paths per agent, you cannot run it in production, and you will not be able to explain it to a regulator.
Where Good Analysis fits
We help organisations move from isolated AI components to orchestrated systems: assessing readiness, choosing the first process, designing the control plane, and building the first use case with governance and measurement in place. The service is described on the AI Readiness page. If you have agents that work in isolation and a process that still runs on email, that is usually where we start.
