Multi-agent orchestration for enterprise integration
How to coordinate several AI agents, deterministic workflows and people across ERP, finance and partner systems, with the patterns, governance and failure handling that keep a multi-agent process safe in production.
Most enterprise processes already cross team and system boundaries: procure-to-pay touches purchasing, receiving, accounts payable and suppliers; hire-to-retire touches HR, IT, payroll and facilities. When AI agents join these processes, the question is not whether one agent can do everything, but how to split the work so that each agent stays narrow, accountable and governable, while the process as a whole still finishes reliably.
When you need more than one agent
Start with one agent and a small set of tools. A single agent is easier to test, secure and explain. Move to multiple agents when at least one of these is true:
- Different owners. Procurement, finance and HR each own their data, rules and risk appetite. Separate agents let each team govern its own tools and policies.
- Different permissions. If one agent would need write access to purchasing, payments and supplier master data, splitting it reduces the damage any single compromised or confused agent can do.
- Different platforms or organizations. A supplier's or logistics partner's agent runs on its own platform. You delegate to it over A2A rather than integrating with its systems.
- Separation of duties. Controls such as "the party that requests a payment may not approve it" are easier to enforce when proposing and approving are done by different agents and people.
- Parallel work. Independent checks, such as credit, stock and compliance, can run at the same time and be combined.
If none of these apply, more agents only add latency, cost and failure points.
Five orchestration patterns
| Pattern | How it works | Good for | Watch out for |
|---|---|---|---|
| Supervisor (orchestrator and workers) | An orchestrator agent plans, delegates tasks to specialist agents, and combines their results. | Exception handling and investigations where the next step depends on findings | The orchestrator becomes a single powerful point; keep its own tools minimal |
| Sequential hand-off | Each agent finishes its step and hands the case to the next, like a pipeline. | Well-understood flows such as intake → validation → posting | Errors propagate downstream; validate at each hand-off |
| Parallel fan-out and fan-in | Independent tasks go to several agents at once; results are aggregated. | Credit, stock and compliance checks for one order | Partial failures and timeouts; define what "enough results" means |
| Event-driven choreography | Agents subscribe to business events and react, with no central coordinator. | Loosely coupled domains already connected by an event broker | Hard to see the end-to-end state; needs strong tracing |
| Workflow-led (agent in the loop) | A deterministic workflow or integration flow owns the process and calls agents only for judgement steps. | Regulated, high-volume or audited processes | Less flexible, but the most predictable; often the best default |
In practice, enterprises mix these. A common and safe combination is a workflow-led backbone for the steps that must always happen in order, with a supervisor agent handling exceptions that need investigation.
Reference architecture
Three design choices matter most. First, the orchestrator has almost no tools of its own: it plans and delegates, but posting, paying and updating are done by domain agents with narrow permissions. Second, agent-to-agent delegation and tool access are separate channels: A2A for handing tasks between agents, MCP through the gateway for touching systems. Third, policy is evaluated outside the agents, so a manipulated agent cannot talk its way past a rule.
Worked example: a supplier invoice exception
An incoming supplier invoice fails the three-way match against its purchase order and goods receipt. The quantity invoiced is higher than the quantity received, and the total is 48,000.
| # | Who | What happens | Control |
|---|---|---|---|
| 1 | Integration flow | Publishes an InvoiceMatchFailed event with the invoice, PO and trace ID. | Event schema validation |
| 2 | Orchestrator agent | Creates a case and delegates "explain the mismatch" to the procurement agent as an A2A task. | Delegation depth limit 2; case budget |
| 3 | Procurement agent | Calls get_purchase_order and get_goods_receipts (read-only). Finds a second delivery not yet posted. | Read-only tools; user context of the AP clerk |
| 4 | Orchestrator agent | Asks the supplier's agent over A2A to confirm the delivery. The task moves to input-required until the supplier responds. | Signed Agent Card; partner allow-list; response treated as data |
| 5 | Procurement agent | Proposes posting the missing goods receipt. Policy requires a warehouse user to confirm. | Approval for inventory postings |
| 6 | Finance agent | After the match succeeds, calls create_payment_request for 48,000 with an idempotency key. | Policy: amount over 10,000 needs approval |
| 7 | AP manager | Sees the request, the evidence gathered and the trace, and approves. A different person from the requester. | Separation of duties |
| 8 | Integration flow | Posts the payment proposal in ERP and closes the case. The audit log shows every step under one trace ID. | Tamper-evident audit |
Notice what never happens: the orchestrator does not post anything; the supplier agent's reply cannot trigger a payment on its own; and the finance agent cannot approve its own request. If the supplier had asked to change bank details, the request would leave this process entirely and go to the supplier master-data process, which has its own verification.
Governing a multi-agent process
Delegation chains: permissions only shrink
Every hop from one agent to another should carry the original user's identity and a token whose scope is equal to or narrower than the caller's. OAuth 2.0 Token Exchange (RFC 8693) is the usual mechanism: the gateway exchanges the incoming token for one scoped to the target agent or tool. A worker agent must never gain permissions its delegator lacked.
Agent registry and Agent Cards
Keep a registry of every agent: its owner, purpose, risk tier, allowed tools, allowed delegates and current version. For A2A, publish and verify signed Agent Cards so agents only delegate to peers you have approved, and so a spoofed agent cannot impersonate a trusted one.
Budgets, limits and stop conditions
- Depth limit: how many delegation hops a case may take (two or three is usually enough).
- Budget: maximum tool calls, model tokens and elapsed time per case, enforced outside the agents.
- Loop detection: stop a case when the same tool is called with the same arguments repeatedly, or when agents keep handing work back and forth.
- Escalation: when a limit is hit, the case goes to a person with its full history rather than failing silently.
Human approval and separation of duties
Decide in policy which actions need approval, who may approve, and that the approver differs from the requester. Show approvers the evidence and the trace, not just the agent's summary, because agents can present confident but wrong conclusions. Keep approval requests rare and meaningful; if people approve dozens of low-risk actions a day, they stop reading them.
Shared state and memory
Store case state in a system you control (a workflow engine or case table), not only in agent memory. Treat anything written by another agent or an external party as untrusted input, and do not let one case's context leak into another's.
Reliability and failure handling
Multi-agent processes fail in the same ways distributed integrations do, plus a few new ways. Most classic integration patterns apply directly:
- Correlation and tracing. Propagate W3C Trace Context through agents, gateways, integration flows and events so one trace ID reconstructs the case.
- Idempotency. Every write tool takes an idempotency key, so an agent's retry after a timeout does not post twice.
- Sagas and compensation. For multi-step changes, define compensating actions (cancel the payment proposal, reverse the goods receipt) and let the orchestrator or workflow run them when a later step fails.
- Long-running tasks. Use A2A task states and push notifications, or asynchronous request-reply, instead of holding connections open while a partner or a person responds.
- Timeouts and deadlines. Give each task a deadline shorter than its caller's, and decide in advance what the orchestrator does when a worker misses it.
- Circuit breakers and quotas. Stop one misbehaving agent from flooding an integration flow and stalling a shared system.
- Dead-letter handling. Cases that cannot complete go to a monitored queue with their history, not into a silent retry loop.
Multi-agent security risks
The OWASP Top 10 for Agentic Applications describes several risks that grow when agents work together:
| Risk | How it shows up between agents | Control |
|---|---|---|
| ASI01 Agent goal hijack | Instructions hidden in a document or partner reply spread from one agent to the next | Treat inter-agent messages as data; policy outside agents; approvals for high-impact steps |
| ASI03 Identity and privilege abuse | A worker agent acts with the orchestrator's broader rights | Token exchange with narrowing scopes on every hop |
| ASI07 Insecure inter-agent communication | A spoofed agent sends A2A messages a trusted agent acts on | Signed Agent Cards, mutual authentication, partner allow-lists |
| ASI08 Cascading failures | One agent's retry loop backs up a shared integration flow | Budgets, quotas, circuit breakers, depth limits |
| ASI09 Human-agent trust exploitation | An approver trusts a fluent summary built on fabricated evidence | Show source evidence and trace; keep approvals meaningful |
| ASI10 Rogue agents | An agent keeps acting outside its mandate | Registry, per-agent kill switch at the gateway, anomaly alerts |
See the OWASP Agentic Top 10 mapped to integration controls for the full list.
Implementation checklist
- Confirm the process really needs several agents; prefer a workflow-led backbone where steps are fixed.
- Give each agent one domain, one owner and the narrowest tools that do the job.
- Keep the orchestrator's own tools minimal; it delegates rather than acts.
- Use A2A for delegation and MCP through a gateway for system access.
- Carry user identity end to end; exchange tokens so scope narrows at every hop.
- Register every agent; verify signed Agent Cards for partners.
- Evaluate policy outside the agents; require approval and separation of duties for high-impact actions.
- Set depth limits, budgets, deadlines and loop detection, with escalation to people.
- Make writes idempotent and define compensating actions.
- Propagate one trace ID and keep a tamper-evident audit trail.
- Test with adversarial content in documents, partner replies and agent messages before go-live.
FAQ
What is multi-agent orchestration?
It is coordinating several AI agents, each responsible for one domain, together with workflows and human approvers, so they complete a business process. One component owns the overall goal, delegates tasks, tracks their state and handles failures.
Should the orchestrator be an AI agent or a workflow engine?
Use a deterministic workflow or integration flow when the steps are known and must always happen in order, and use an orchestrator agent when the next step depends on what earlier steps find. Many enterprises combine them: a workflow backbone with an agent handling exceptions.
How do MCP and A2A fit into multi-agent orchestration?
A2A is used when one agent delegates a task to another agent, including agents on partner platforms. MCP is used when an agent calls a tool or reads data, ideally through a gateway that applies identity and policy. They are complementary.
How do you stop agents from escalating privileges through delegation?
Carry the original user's identity on every hop and exchange tokens so each agent receives a scope equal to or narrower than its caller's. Enforce policy outside the agents, at the gateway and in the downstream APIs.
Sources and further reading
- A2A: What's new in v1.0
- Model Context Protocol: 2026-07-28 key changes
- OWASP Top 10 for Agentic Applications 2026
- RFC 8693: OAuth 2.0 Token Exchange
- W3C Trace Context