TL;DR: Agent orchestration is really three problems, not one: expression defines control flow, runtime provides durable execution, and observability makes failures visible, according to Arize. The practical lesson is that production agents break less from model quality than from missing state, recovery, and trace-level governance, which makes identity, privilege, and audit controls part of the design.
NHIMG editorial — based on content published by Arize: What is agent orchestration? Frameworks, runtimes, and observability explained
By the numbers:
- The MAST paper analysed 1,642 execution traces from seven popular multi-agent frameworks and found failure rates between 41% and 86.7%.
- The MAST paper identified 14 failure modes across multi-agent systems, grouped into system design issues, inter-agent misalignment, and task verification.
Questions worth separating out
Q: How should security teams govern AI agents that run long, multi-step workflows?
A: Security teams should require durable execution, full event history, and clear ownership for every multi-step agent workflow that touches sensitive data or privileged tools.
Q: Why do multi-agent systems create more security risk than single-agent systems?
A: They introduce more trust relationships, more message paths, and more shared state that can be poisoned or misused.
Q: How do security teams know if agent observability is actually working?
A: Observability is working only when teams can tie together token activity, tool calls, and latency for a specific agent session.
Practitioner guidance
- Define agent execution identities Assign each persistent agent a distinct execution identity with scoped permissions, explicit ownership, and a documented lifecycle that covers creation, rotation, suspension, and offboarding.
- Require durable audit trails Capture event logs, replay data, and trace records for every tool call and state transition so security teams can reconstruct agent behaviour after failures or disputes.
- Review handoffs for privilege drift Inspect multi-agent handoffs, shared context, and supervisor permissions for scope expansion, then remove any permission that is not required across the full task path.
What's in the full article
Arize's full article covers the operational detail this post intentionally leaves for the source:
- Layer-by-layer examples of agent frameworks, runtimes, and observability stacks used in production.
- Specific implementation references for durable execution, replay, and recovery patterns.
- The research discussion behind the MAST failure analysis and trace-based debugging approach.
- Named product examples that illustrate how teams operationalise orchestration at scale.
👉 Read Arize's analysis of agent orchestration across frameworks, runtimes, and observability →
Agent orchestration layers: what IAM and security teams should watch?
Explore further
Agent orchestration is becoming an identity problem as much as an engineering problem. Once an agent can persist state, resume execution, and invoke tools across sessions, the organisation is no longer governing a single request. It is governing an execution identity with a lifecycle, delegated privileges, and audit obligations. That is where IAM, PAM, and NHI controls intersect with orchestration design, especially when long-lived agent sessions touch sensitive systems. The practitioner conclusion is simple: orchestration should be reviewed with the same discipline used for non-human identity governance.
A question worth separating out:
Q: What frameworks should teams use to assess agent orchestration risk?
A: Use NIST AI RMF for governance, OWASP Agentic AI Top 10 for application risk patterns, and MITRE ATLAS for adversarial behaviour. Where agents touch credentials or delegated access, add NHI governance and access lifecycle controls so the orchestration layer is reviewed as part of identity security.
👉 Read our full editorial: Agent orchestration depends on expression, runtime and observability