Agent orchestration depends on expression, runtime and observability

At a glance

What this is: This is an analysis of agent orchestration as a three-layer stack, with the key finding that expression, runtime, and observability solve different problems.

Why it matters: It matters because agentic systems inherit governance failures when execution, recovery, and visibility are treated as engineering details instead of control points for identity, privilege, and auditability.

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.

👉 Read Arize's analysis of agent orchestration across frameworks, runtimes, and observability

Context

Agent orchestration is the coordination of AI agent behaviour across control flow, execution durability, and observability. The security issue is not just whether an agent can act, but whether its actions can be attributed, recovered, and constrained when the system spans multiple steps, tools, and decision points.

For identity and access teams, the orchestration question quickly becomes a governance question. Agent runtimes can hold state, resume work, and invoke tools over long sessions, which means privilege, audit trails, and delegated access need to be designed for the full execution path, not only the initial login or token issuance.

The article’s core claim is that many debates about multi-agent design are really debates about one layer of the stack, while the harder reliability and control problems sit in runtime and observability. That is typical of emerging agent programmes: teams focus on framework choice first and discover governance gaps later.

Key questions

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. If the agent can lose state on failure, the organisation cannot reliably audit what happened or prove which actions were completed versus replayed.

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. Each extra agent expands the attack surface and makes policy enforcement harder. The risk is not only model error, but also uncontrolled delegation, duplicated permissions, and failure propagation across the workflow.

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. If those signals are disconnected, the logs may show traffic but not governance. The test is whether investigators can reconstruct the path of a meaningful agent action from start to finish.

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.

Technical breakdown

Expression layers: how agent control flow is encoded

Expression is the layer where a team defines what the agent does in code. Frameworks such as graphs, state machines, supervisors, loops, and handoffs encode how tasks decompose and how decisions move between steps or subagents. The architectural risk is that expression choices shape context sharing, conflict resolution, and failure propagation long before a model is called. If the control flow is fragmented, agents can diverge even when each individual step looks correct. This is why many multi-agent arguments are really arguments about task topology rather than orchestration in general.

Practical implication: treat control-flow design as part of the governance surface, not just application logic.

Durable runtimes: why long-running agents need replay and recovery

A runtime is the execution layer that keeps an agent alive across crashes, retries, worker loss, and long pauses. Durable execution systems journal state, replay events deterministically, and resume work from checkpoints rather than restarting from scratch. That matters because production agents increasingly operate like distributed workflows, not stateless chat sessions. Without a durable runtime, a transient failure can corrupt state, lose tool outputs, or create inconsistent decisions across steps. The article correctly places this layer alongside execution resilience patterns already proven in workflow orchestration.

Practical implication: use checkpointing, event logs, and resumable execution for any agent that can persist beyond a single request.

Observability for agents: tracing, evals, and replay

Observability is the layer that reveals what the agent actually did, not what the prompt designer expected it to do. Traces, replays, evaluators, and judges let teams inspect reasoning-action mismatches, step repetition, role drift, and premature termination. In multi-step systems, these failures are often invisible from the outside and easy to misdiagnose as model quality problems. The deeper point is that agent reliability becomes measurable only when execution history is captured in enough detail to reconstruct the decision path. That is where production governance and debugging finally overlap.

Practical implication: instrument traces and replay before scaling agent access to sensitive tools or workflows.

Threat narrative

Attacker objective: The objective is to exploit delegated agent execution so the system acts beyond its intended scope or loses control over what it did.

1. Entry occurs when an agent receives delegated access to tools, data sources, or long-running workflows through an orchestration layer. Escalation happens when weak context sharing or poorly scoped handoffs let the system carry forward broader permissions than the task requires. Impact follows when unobserved execution compounds into incorrect actions, unauthorized data access, or failed recovery in production.

NHI Mgmt Group analysis

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.

Runtime durability changes the attack surface by extending the trust window. A durable agent can survive crashes and resumes, which is operationally useful but also means access decisions are no longer limited to one bounded interaction. If state checkpoints, retry logic, and resumption policies are not governed, failures can become privilege persistence mechanisms. This is why runtime design belongs in security architecture reviews, not only platform engineering discussions. Practitioners should treat resumability as a control requirement with explicit scope and expiry.

Observability is the control plane for proving agent behaviour, not just debugging it. The article’s strongest insight is that production failures become visible only when traces and replay data are available at the right granularity. For identity teams, this is analogous to the difference between issuing access and proving how that access was used. Without trace-level evidence, you cannot validate whether an agent stayed within task scope or crossed a delegation boundary. The practitioner conclusion is to require auditable execution records before granting sensitive tool access.

Context engineering has created a new class of governance debt. The field keeps focusing on prompt quality and framework choice, but the real operational debt accumulates when context, state, and privilege are distributed across layers that are not reviewed together. That creates hidden dependencies between orchestration design and access control decisions. NHI governance provides the right mental model here because it already assumes credentials, scope, and lifecycle must be managed together. Practitioners should align agent governance reviews with identity lifecycle controls rather than treating them as separate disciplines.

Agent orchestration will converge toward runtime and observability standards faster than framework loyalty suggests. Frameworks are becoming easier to swap, but durable execution and traceability are becoming the enduring differentiators for production use. That means procurement conversations should move away from surface syntax and toward control evidence, recovery semantics, and audit quality. In identity terms, the market is moving from “what can the agent do?” to “what can we prove the agent did?” Practitioners should measure tools by governance fit, not by framework popularity.

What this signals

Context, state, and delegated access are now the three points where agent programmes fail first. Teams that focus only on prompt quality will miss the operational controls that decide whether a long-running agent remains governable after the first tool call. The practical next step is to align orchestration reviews with identity lifecycle, auditability, and recovery requirements, then validate them against NIST AI Risk Management Framework.

Execution replay will become the most valuable evidence in agent governance. Once agents can resume work after failure, security teams need a way to prove what happened between checkpoints. That makes trace data and event logs the closest thing to an identity attestation for agent behaviour, especially when MITRE ATLAS adversarial AI threat matrix style abuse patterns are in scope.

For practitioners

• 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.
• Gate sensitive tools behind observability Allow access to production or sensitive systems only when the orchestration layer can prove trace-level visibility, deterministic recovery, and bounded resumption.

Key takeaways

• Agent orchestration fails when control flow, runtime resilience, and observability are treated as one problem.
• Multi-agent systems create governance risk when delegated access and shared context are not bound to a clear execution identity.
• Security teams should require replayable traces and durable recovery before granting agents access to sensitive tools.

Key terms

• Agent Orchestration: Agent orchestration is the coordination of multiple AI agents or workflows to complete a task set with limited human intervention. In identity terms, it creates delegated execution paths that need ownership, scope limits, and auditability because work is no longer performed only by a person in one session.
• Durable Runtime: A durable runtime is an execution environment that can pause, checkpoint, recover, and resume an agent without losing state. It prevents crashes or worker loss from turning into broken workflows, inconsistent decisions, or uncontrolled re-execution of privileged steps.
• Trace-level Visibility: Trace-level visibility means recording the sequence of steps that led to an AI outcome, not just the final response. It is essential in multi-step systems because it shows which retrieval, prompt, or tool event introduced the failure and whether the action was authorised.
• Execution Identity: An execution identity is the non-human identity that performs a task at runtime, such as a Terraform role, Kubernetes controller, or CI/CD service account. It is the identity that matters when evaluating who can actually retrieve or decrypt a secret in production.

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.

👉 The full Arize article unpacks the layer-by-layer examples, runtime patterns, and observability details behind agent orchestration.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and the identity lifecycle behind delegated access. It helps security and identity practitioners translate agent behaviour into controls they can govern and audit.