By Shreshta Shyamsundar and Chidambaram GS
During a critical service incident, teams often shift a customer‑remediation workflow onto an emergency route: approvals are shortened, a priority queue opened, and on‑call staff cleared to follow alternate procedures until service recovery. The incident may be declared closed, while an emergency route remains active for a small customer segment.
The issue is not that the emergency route was incorrect—production needs such routes and a human approved it—but that the temporary exception has become part of the platform’s runtime without an active incident, owner, or expiry condition. The authors call this unmanaged runtime state "exception drift": temporary authority granted under pressure that is hard to retire when the pressure lifts.
What is exception drift?
Exception drift occurs when temporary exception behavior outlives its authorized scope, authority, or duration and emergency accommodations settle into normal execution. Common manifestations include a routing rule left reachable, an approval shortcut that survives closure, or a tool permission that continues to affect execution after the triggering condition has passed.
Enterprises typically have human processes—incident management, change control, and postincident reviews—but the gap is architectural. Many agent platforms treat organizational operating state as external to runtime rather than as an authoritative input to it. Once a workaround proves useful, it can fade into invisible operating state: routing remains enabled, shortened approval paths remain reachable, and temporary queues keep taking work.
The practical question is: "Which operating mode is active for this workflow, user, or segment at this moment?" If that answer is left implicit, each agent, workflow, and gateway will invent its own.
The lifecycle of an exception
Organizations move through a predictable sequence: normal operations, incident declaration, a temporary exception window, closure review, and return to normal. Declaring a concession is loud and obvious; retiring it is quiet and often neglected—especially if the workaround improved throughput. That asymmetry is where drift hides. From the platform’s perspective, the lifecycle should only close when it can prove that every exception path has been retired or formally adopted through change governance.
Why this matters more for AI agents
Agents raise the stakes because they act: they select tools, trigger workflows, coordinate with other agents, and adapt at runtime. An accommodation created during an incident can propagate across routing, tool use, approval paths, and downstream agents. While a traditional exception is legible in a runbook, an agent can carry the same exception across many paths simultaneously, making it harder to locate and retire.
The missing technical layer is an authoritative operational‑state context that arrives with the request rather than being reconstructed from history or memory. Historical traces and retained memory can explain why an accommodation once existed; they should not be the source of truth for whether it remains authorized. Memory informs execution; operating mode governs it. When they disagree, authoritative runtime state must win.
A minimal example of that context
The authors propose a minimal JSON structure that binds an exception to a mode, scope, authority, expiry, and status:
{ "mode": "incident", "exception_id": "INC-4721", "scope": { "segment": "premium-customers", "region": "us-east", "workflow": "customer-remediation" }, "authority": "service-owner", "expires": "incident-close", "status": "active" }
This operating mode complements, but does not replace, existing patterns: feature flags target behavior by context, RBAC governs what a principal may do, and tenancy metadata locates a request. Operating mode determines whether exception behavior is authorized at all, acting as a higher‑order governance constraint consumed by the runtime.
Design pattern: exception‑aware agents
Operating mode becomes actionable when platforms treat it as a first‑class runtime construct. Platforms already inject identity, permissions, tenant context, and policy into requests; operating mode should be part of that set. Agents must consume it as authoritative state after the organization declares an exception, scopes it, assigns authority, and sets an expiry—rather than reconstructing it from prompts or accumulated context.
This reframes the architectural test: can the platform guarantee that exception behavior is impossible outside an authorized operating mode? Emergency behavior exists because the platform enables it; therefore the platform must enforce a minimal runtime contract that makes boundaries testable. Each workflow invocation should receive the operating mode with the user request, and orchestration, routing, and tool gateways should read the same state.
The control plane as the natural home
The natural home for operating mode is an external control plane. Incident management platforms, maintenance window services, and change management workflows already hold authoritative operational state; an exception‑aware architecture extends those signals into execution with explicit scope, authority, expiry, and closure semantics. Implementation details will differ, but the core principle stands: exception state should be authoritative, observable, and externally managed, kept out of prompts, workflow definitions, and agent memory.
Exception‑aware execution and return to normal
With explicit operating state, behavior changes when system state changes and prompt wording stops being the lever. In normal mode, agents use standard workflows, routing, and approvals. In incident mode, the same workflows can expose scoped accommodations that the authorized mode makes available—expedited approvals, alternate routing, deferred reviews, emergency runbooks.
The payoff is testability: a workflow in normal mode must never reach an emergency path; a workflow in incident mode must reach only those accommodations allowed by scope, authority, and expiry. For the opening incident example: if the emergency route is opened only inside a declared exception scoped to affected segment and workflow, owned by a service owner, and stamped with an expiry tied to incident closure, then when the incident closes the mode returns to normal and the routing gate stops handing that route to the segment. Closure then becomes a check: the platform replays the exception’s scope against live routing, approval, tool, and queue configurations and confirms no path still resolves to emergency behavior.
No one needs to remember to retire the route; it is bounded by state and the platform can show it is gone.
Shared operating state for multi‑agent systems
The problem compounds across collaborating agents. Customer‑facing, orchestration, and execution agents may share a workflow but disagree about state, so one keeps applying emergency routing after another has returned to standard controls. A shared operating state gives them a single governance boundary: the exception is represented once and read consistently everywhere. As agents become more autonomous, shared operational state matters as much as shared identity and authorization; fragmented state produces fragmented accountability.
Making exception drift observable
Explicit operating state delivers observability. Historically accommodations scatter across workflow definitions, approval policies, routing configurations, and tool permissions, making them hard to see. Represented as runtime state they become measurable: closure can trigger automated validation, and the platform can watch for residual exception behavior between closures. Useful checks are direct: is the exception routing path still reachable, do its temporary approvals or elevated permissions still resolve, does any expired exception still affect behavior? Tracking how many exceptions are open, how long they remain open, and how often they harden into permanent change turns drift from an audit finding into a monitored signal.
From adaptive agents to governed systems
The shift is from documenting exceptions and hoping they are retired to representing exceptions as runtime state that can be propagated, validated, monitored, and closed. The test for a platform is whether it can demonstrate that an exception stayed bounded to its purpose and duration.
This approach does not require inventing a new governance model—the disciplines for identity, permissions, change, and operational risk already exist. The recommendation is to extend those disciplines to operating state. Once operating mode is authoritative, observable, and testable, drift becomes detectable, closure verifiable, and recovery an engineering result: temporary accommodations stay temporary, governance lives in the architecture, and enterprise agents earn trust at scale.
References
The article cites ISO 22301:2019, ITIL 4 Change Enablement, and product documentation from LaunchDarkly, ServiceNow, and PagerDuty as examples of existing systems and practices that hold operational state today.
