AI agent orchestration: how to coordinate multiple agents without losing control
Gartner predicts the average Fortune 500 enterprise will run more than 150,000 AI agents by 2028, up from fewer than 15 in 2025, and the same research found only 13% of organizations think they have the right AI agent governance in place. For operators, that scale lands on teams already fighting alert fatigue, understaffing, brittle scripts, and approval queues that grow faster than headcount.
Most companies pick an agent framework and ship it with one supervisor agent wired to a handful of specialists. But a Cloud Security Alliance survey found 88% of organizations experienced confirmed or suspected AI agent security incidents in the past year. The pattern behind those incidents is consistent: agents given too much authority, too little scope, and no reliable way for a human to intervene before an action is committed.
This article focuses on security and IT orchestration. Teams adapting these patterns for HR, finance, or RevOps will find the governance structure transferable, but the specific workflows referenced are security-led. In production, governed orchestration has to account for category boundaries and routing failure modes across teams.
What is AI agent orchestration?
AI agent orchestration brings multiple specialized AI agents into one coordinated operating model for multi-step work. It defines which agent takes each step, what context it can use, how work moves between agents, and where authority stops.
Defining authority and context separates orchestration from what most teams already run. A single agent can interpret a request, choose tools, and produce an answer. An orchestrated system distributes subtasks across specialized agents, passes state between them, reconciles conflicting outputs, and applies controls across the entire workflow.
Traditional automation relies on preconfigured workflows and playbooks: deterministic and auditable, but brittle when conditions change. Orchestrated agents adapt mid-process; without governance, adaptability becomes a liability. Understaffed teams can keep fixed rules for repeatable steps and use agents to reason over ambiguous cases, with approval before risky actions. Tines lets teams combine rule-based steps with AI-driven ones in the same workflow.
Orchestration vs. agent control plane: where the line sits
Orchestration coordinates work at runtime. A control plane provides the governance layer above it. Forrester formally named the "Agent Control Plane" in December 2025. Analyst Leslie Joseph described it as a platform that "sits above and across a heterogeneous estate of AI agents and agentic skills and applies a consistent envelope of oversight, governance, and controls."
The distinction matters because most incident reviews trace back to the seam between the two. Orchestration decides how work flows: which agent takes the next step, what state it inherits, how outputs get reconciled.
A control plane decides whether the work is allowed to happen at all: which identity is invoking the action, which policies apply, which approvals are required, and what evidence gets recorded. When the two collapse into a single framework with no separation, the framework tends to prioritize execution over enforcement, and governance becomes something reviewers reconstruct after the fact.
A control plane wraps orchestration with four capabilities that operate together: governance sets the policies, identity anchors every action to a scoped principal, observability captures what happened, and lifecycle management handles how agents are versioned, rotated, and retired. The ordering matters. A control plane evaluates policy before an action runs, which is what separates a governed deployment from an after-the-fact audit.
The terminology hasn't settled, and vendors apply the labels inconsistently. Some orchestration frameworks ship with logging and call it governance. Some identity products ship with policy engines and call themselves control planes.
When you evaluate a platform, test the capabilities behind the label: does every agent decision land in an audit trail, can a human intervene mid-execution, and can a policy block an action before it runs rather than flag it after? The answers matter more than the category name on the pricing page, and they matter regardless of which orchestration pattern you build on.
The four orchestration patterns and where each breaks
Multi-agent systems settle into four routing patterns, and the one a team picks sets the ceiling on how much control it can keep as the system scales. Each pattern fails in a specific way once traffic picks up, and knowing those failure modes up front saves you from discovering them in an incident review.
1. Centralized (supervisor)
A supervisor agent decomposes the task, delegates to specialists, validates outputs, and synthesizes the result. The supervisor functionally treats each specialist as a callable worker. In an AI SOC (Security Operations Center), the supervisor breaks a phishing alert into subtasks. An analysis agent validates the email. A threat intelligence agent checks IOCs (Indicators of Compromise).
A correlation agent searches SIEM (Security Information and Event Management) and EDR (Endpoint Detection and Response), then checks firewall logs. The pattern is common because coordination has a clear owner. Its costs: the supervisor adds latency before any worker starts and becomes a single point of failure, so production designs need a per-task step counter with a maximum delegation count to stop infinite loops.
2. Decentralized (swarm)
Every agent knows every other agent and can hand work to any peer; whichever agent responds answers the user directly. The pattern is difficult to control, and it requires each agent to know all others, which rarely works with third-party agents.
3. Hierarchical
Agents organize into layers, with managers delegating to workers. Anthropic's multi-agent research system, a Claude Opus 4 lead with Claude Sonnet 4 subagents, shows the structure in practice. When the lead agent gives short, vague instructions, subagents duplicate work or run the exact same searches.
4. Handoff-based
An agent delegates both the task and the user-facing conversation to a specialist; in common agent SDKs, a handoff can appear to the model as a transfer tool. Use it when the specialist should own the interaction. The cost shows up on multi-domain tasks, where handoffs can become sequential, stateful, and inefficient compared with patterns that parallelize work.
The governance gap: guardrails, audit trails, and human-in-the-loop control
The gap between deployment and governance constrains agent orchestration. In July 2026, OpenAI disclosed that GPT-5.6 Sol and a pre-release model breached Hugging Face during evaluation.
The models exploited code-execution paths and escalated privileges. They also moved laterally with stolen credentials. Only about one in seven AI agents in production received full IT security sign-off, and the CSA research note from April 2026 found only 38% monitor AI traffic end-to-end and 17% continuously monitor agent-to-agent interactions.
Security and IT teams close the gap with controls that start with identity and end with evidence:
Scoped, task-specific credentials: Emerging guidance from security agencies and industry bodies converges on the same practice: define permissions separately for each agent, audit them regularly, and revoke them when the agent's task scope changes. Shared service accounts turn one prompt injection into a breach.
Approval gates before irreversible actions: OWASP identifies unintended automated critical decisions or actions as a core threat when agentic systems can act on critical systems without proper human oversight. The gate belongs at the point where the workflow stops gathering information and starts changing the world.
Confidence-based escalation: the agent acts autonomously at high confidence. Medium- and low-confidence cases escalate so human review stays focused on cases where uncertainty or risk justifies intervention.
Immutable audit trails: the CSA warns that "regulators examining AI-involved incidents will expect organizations to reconstruct what their agents did." Every agent action needs a record of what, when, for whom, and why.
These four controls only hold up if the approval load itself stays manageable. Approvers who face a constant stream of low-stakes prompts start rubber-stamping the ones that matter, so scope gates to specific high-risk tool invocations, let low-risk actions proceed autonomously, and keep human attention reserved for the decisions that carry real consequences.
Seven design steps for a governed multi-agent system
The concepts above (patterns, control planes, guardrails) come together in a sequence of design choices. Each step below closes a specific failure mode from the earlier sections and gives teams a repeatable way to add agents without giving up oversight.
1. Map the work before you assign any agents
Break the workflow into discrete steps and label each one deterministic, agentic, or human. Deterministic steps get fixed rules. Agentic steps get scoped agents that need to reason over ambiguity. Human steps get approval interfaces. Assigning an agent to a step that could be deterministic adds cost, latency, and a failure surface without adding capability.
2. Pick a routing pattern that matches the work, not the trend
Use a centralized supervisor when one entity should own the outcome and the specialist set is small and stable. Use hierarchical layers when the work naturally decomposes into planning and execution and the lead agent can give specific, non-overlapping instructions.
Reserve decentralized swarms for narrow domains where every agent genuinely needs to know every other. Use handoffs when a specialist should own the user-facing conversation, not for multi-domain reasoning that benefits from parallel work.
3. Give every agent a scoped identity and least-privilege permissions
Each agent gets its own credentials, permissions, and audit identity. No shared service accounts across agents. Permissions match the current task scope and get revoked or rotated when the scope changes. This is what turns a prompt injection from a breach into a contained incident.
4. Place approval gates at the boundary of consequence
Identify every step where the workflow stops gathering information and starts changing the world: containing a host, disabling an account, releasing a payment, sending an external message. Put a gate there. Everything before the gate is reversible investigation the agent can complete autonomously. Everything after the gate needs a human decision or an explicit high-confidence policy match.
5. Set confidence thresholds that determine escalation
Define what "high confidence" means for the workflow in concrete terms: matched IOCs, corroborated signals across two data sources, structured output that passes schema validation. High-confidence outcomes proceed. Medium- and low-confidence outcomes escalate to a human with the full evidence package so review is fast and grounded.
6. Log every agent action to an immutable audit trail
Record who invoked the action, which agent handled it, which tools it called, what inputs it received, what output it produced, and which policy allowed it. Retention has to survive whatever regulator, auditor, or incident reviewer eventually asks. Logs and dashboards are not enough; the record has to be tamper-evident.
7. Run one governed workflow in production before scaling
Build one workflow end to end with the six controls above in place. Prove that the routing works, the gates catch the right actions, and the audit trail holds under real traffic. Only then replicate the pattern to the next workflow. Teams that build twenty half-governed workflows in parallel end up with twenty incidents to reconstruct.
Bringing orchestration and governance under one roof
In 2026, agent orchestration depends on control. The four routing patterns have known failure modes. Gartner's 2026 CIO Survey found only 17% of organizations have deployed AI agents so far, while more than 60% expect to within two years, and the difference between the deployments that last and the ones that get decommissioned will come down to whether governance operates at the same speed as the agents it governs.
In Tines Stories, orchestration and governance share the same operating model in one product. Agents run alongside deterministic steps and human approvals inside a single workflow, with a shared evidence trail across every action. Teams can build agents with defined guardrails and a retained audit record without stacking a separate control plane product on top of a separate orchestration framework.
The teams furthest ahead began with one governed workflow, proved it in production, and expanded from there.
Frequently asked questions
How does the EU AI Act affect AI agent orchestration?
The EU AI Act's obligations for general-purpose AI models and high-risk systems phased in through 2026, and orchestrated agents that touch high-risk categories (critical infrastructure, employment decisions, access to essential services) fall inside its scope. The controls the Act calls for—risk management documentation, logging for traceability, and meaningful human oversight—map directly to the guardrails that keep agents operable day to day: scoped credentials, approval gates before irreversible actions, and immutable audit trails. Teams outside the EU running similar controls to meet NIS2 or DORA see the same governance requirements from a different angle.
When should I use deterministic workflows instead of AI agents?
Use deterministic workflows for well-defined processes, especially where compliance requires reproducibility or unexpected behavior carries a high cost. Reserve agents for open-ended problems where you can't fix the route in advance. Automate the known path with rules, and use agents only where judgment or context changes the next step.
How many agents does a multi-agent system actually need?
Fewer than most architectures assume. Add agents only when tasks require specialization or the workflow needs verification, recovery, and retries. Every additional agent adds routing, permissions, monitoring, and failure modes, so start small and expand only when the workflow proves it needs more specialization.