Exception Drift (Operating Mode as Runtime State)
Temporary, authorized emergency/incident exceptions (altered routing, approvals, permissions) that outlive the incident that justified them because the platform has no authoritative, scoped, time-bound runtime representation of "which operating mode is active" — fixed by injecting organizational operating state (normal/incident/recovery, with scope/authority/expiry/status) into the agent runtime as a first-class input, alongside identity and permissions, so closure can be automatically verified.
Also known as: exception drift, operating mode, exception-aware agents, runtime operating state, incident mode as runtime input
Part of: Agent Governance (Internal)
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| Operating Mode as Runtime State: A Contract for Enterprise Shreshta Shyamsundar and Chidambaram GS · 2026-09-11 | exception drift | The process by which temporary exception behavior (an emergency routing rule, a shortened approval path, an elevated tool permission) outlives its authorized scope, authority, or duration and settles into normal execution without anyone deciding it should. |
| Operating Mode as Runtime State: A Contract for Enterprise Shreshta Shyamsundar and Chidambaram GS · 2026-09-11 | operating mode | An explicit, authoritative runtime value (normal, incident, recovery, or a declared exception) describing which organizational operating state currently governs execution, handed to the agent runtime the way identity, tenant, and permissions already are. |
Documents (1)
- Operating Mode as Runtime State: A Contract for Enterprise Shreshta Shyamsundar and Chidambaram GS · 2026-09-11 source ↗ Reader 🖥️
Because enterprise AI agents infer whether they're operating under normal, incident, or recovery conditions from prompts and accumulated context rather than receiving it as authoritative input, temporary emergency exceptions quietly harden into permanent runtime behavior ('exception drift') — the fix is to make organizational operating mode a first-class, scoped, time-bound runtime construct, injected alongside identity and permissions, whose closure the platform itself can verify rather than merely document.
Propositions touching this concept (12)
By publication month, oldest first (extraction month when no publication date is known).
2026-06
- explicitcontestedContrary to the source whitepaper's framing that developers should keep moving fluidly between 'conductor' (hands-on, file-level) and 'orchestrator' (goal-level, delegated) modes, a developer with a sufficiently reliable harness and rule set can 'graduate' to living in orchestrator mode essentially permanently, reserving conductor-level granularity mainly for deep debugging or initial exploration rather than as a recurring operating mode.
2026-08
- explicitIf loops become a common operating mode, the unit for evaluating coding agents should shift from a single bounded-task benchmark run to a loop operating over time — where convergence, cumulative cost, drift, and escalation quality matter — extending the already-open problem of harness-level evaluation.
2026-09
- explicitException drift is architectural, not a failure of human incident/change-management process: enterprises already have adequate human machinery (incident management, change control, postincident review), but most agent platforms treat organizational operating state as external to the runtime rather than as an input to it.
- explicitWhen the answer to "which operating mode is active" is left implicit, every agent, workflow, and tool gateway invents its own answer.
- explicitProduction agent behavior depends as much on runtime context (identity, tenant, environment, permissions, session state, policy, tool access) as on capabilities (models, tools, orchestration); operating mode is the one piece of that context usually missing.
- explicitAI agents raise the stakes of exception drift relative to traditional (human/runbook) exceptions, because agents act autonomously across tools, workflows, and other agents, so a single accommodation introduced under pressure can propagate along many execution paths simultaneously, making it structurally harder to locate and retire than an exception recorded in one runbook.
- explicitHistorical traces and retained agent memory can explain why an accommodation once existed, but should never decide whether it is still authorized; memory informs execution, operating mode governs it, and when the two disagree, authoritative runtime state should win.
- explicitOperating mode is architecturally distinct from feature flags (LaunchDarkly-style targeting), RBAC (who may act), and tenancy metadata (where a request belongs): permissions determine who may act, policies determine how, and operating mode determines whether exception behavior is authorized at all — a higher-order governance constraint on agents, workflows, approvals, tools, and escalation paths.
- explicitThe right architectural test is whether the platform can guarantee that exception behavior is impossible outside an authorized operating mode — emergency behavior should exist only because the platform enables it, for no other reason.
- explicitOperating mode should be owned by an external control plane (incident-management platforms, maintenance-window services, change-management workflows) rather than embedded in prompts, workflow definitions, or agent memory, because those systems already hold authoritative operational state.
- explicitIn multi-agent systems, exception drift compounds because collaborating agents (customer-facing, orchestration, execution) can disagree about operating state — one continuing emergency behavior after another has reverted to standard controls — so a single, consistently-read shared operating state is necessary to avoid fragmented accountability.
- explicitMaking operating mode explicit converts exception drift from something detectable only via audit, after the fact, into an observable, continuously monitored runtime signal — how many exceptions are open, how long they stay open, how often they harden into permanent change.
Open gaps (1)
- illogicalThe article insists memory should never decide whether an accommodation is 'still authorized' and that authoritative runtime state must win when the two disagree, yet allows expiry to be tied to a soft condition like 'incident-close' — a status that itself has to be recorded and read from somewhere, often by human judgment. If that status update is delayed, inferred, or manually entered, the 'authoritative state' is not obviously more reliable than the informal traces it's meant to replace; the piece never explains what structurally distinguishes a trustworthy 'incident-close' status from the kind of soft, human-mediated signal it dismisses when it comes from memory or prompts.Operating Mode as Runtime State: A Contract for Enterprise — read next: Distinguish structurally-guaranteed authority (a hard-timestamped, cryptographically scoped token) from merely relocated human judgment (a status field someone updates); read against the piece's own JIT/short-lived-token material and against extract-privilege-drift-multi-agent-systems on runtime enforcement.