Operating Mode as Runtime State: A Contract for Enterprise

Shreshta Shyamsundar and Chidambaram GS · rss · 2026-09-11 source ↗ Reader 🖥️

Agent Governance (Internal)Agent Memory Exception Drift (Operating Mode as Runtime State)Multi-Agent Orchestration Privilege Drift / Scope Sprawl SRE & Incident Response

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.

practical · architectural essay / design-pattern proposal (O'Reilly Radar op-ed) — Prescriptive architecture piece, not an empirical study: no production case study, adoption data, or named implementation is cited. It argues by a single illustrative incident vignette, a JSON schema example, and three comparison tables, then generalizes to a design pattern.

Structure

Part	Role
Opening incident vignette	concrete case establishing the failure mode
"The problem is unmanaged exception state"	names and diagnoses 'exception drift'; locates the gap as architectural, not procedural
"The exception lifecycle"	five-stage model (normal -> incident -> exception window -> closure review -> normal); identifies retirement as the unsolved stage
"Why this matters more for AI agents"	argues agents amplify drift because they act autonomously across many paths; introduces the memory-vs-operating-mode distinction and a JSON contract example
"A design pattern for exception-aware agents"	proposes operating mode as a first-class runtime input alongside identity/tenant/permissions/policy; contrasts it with feature flags, RBAC, tenancy; gives the six-field contract (Table 1)
"Building an exception-aware control plane"	argues operating mode should be owned by an external control plane (incident/change/maintenance systems), not embedded in prompts or memory
"Exception-aware execution"	shows behavior gated by mode (Table 2) and reframes closure as an automated replay-and-check, not a manual step
"A common operating model for multi-agent systems"	extends the pattern to collaborating agents, arguing for one shared, consistently-read operating state
"Making exception drift observable"	reframes drift as a monitored runtime signal rather than an audit finding
"From adaptive agents to governed systems"	closing synthesis (Table 3, traditional vs. exception-aware) and call to extend existing governance disciplines to operating state

Key terms

exception drift Exception Drift (Operating Mode as Runtime State)
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 Exception Drift (Operating Mode as Runtime State)
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.
runtime state
Authoritative context supplied to the agent at request time by an external system of record, as opposed to anything inferred, reconstructed, or remembered from prompts and conversation history.
exception-aware
Describes a platform or agent architecture in which emergency behavior is reachable only through a declared, scoped, time-bound operating-mode exception, and is otherwise structurally impossible.
closure
A verifiable event in which the platform replays an exception's declared scope against live routing/approval/tool/queue configuration and confirms no path still resolves to the exception behavior.

Propositions

explicitA controlled emergency exception granted during an incident, appropriately authorized, can nonetheless persist indefinitely after the incident ends, because the platform has no mechanism to retire it once the pressure that justified it lifts.conf: high
explicitAn exception is safe while the incident that justified it is live; it becomes dangerous the moment the platform can no longer show the incident has ended.conf: high
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.conf: high
extendsHow to Manage Privilege Drift in Multi-Agent Systems · p1 — Extends the privilege-drift pattern (permissions accumulate unmanaged over time) to a structurally identical but distinct failure: exception/operating state accumulates unmanaged when it isn't represented as authoritative runtime input.
explicitWhen the answer to "which operating mode is active" is left implicit, every agent, workflow, and tool gateway invents its own answer.conf: high
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.conf: high
explicitThe exception lifecycle has five predictable stages (normal operations, incident declaration, temporary exception window, closure review, return to normal); organizations handle the front of that sequence well but consistently fail at the retirement stage — proving an exception's effects have actually disappeared.conf: high
explicitDeclaring an exception is loud and visible; retiring one is quiet, especially when the workaround measurably improved throughput or recovery speed — this asymmetry is where drift lives.conf: high
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.conf: high
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.conf: high
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.conf: high
explicitA minimal, testable runtime contract for an exception needs six fields: mode, exception ID, scope, authority, expiry, and status.conf: high
supportsYour AI agent just blamed the network team. Now what? · p3 — Parallel scoped, time-bound authorization pattern (grant tied to a specific context, revoked/expired after it ends), here generalized from diagnostic-agent credentials to the broader incident/exception contract.
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.conf: high
supportsHow to Manage Privilege Drift in Multi-Agent Systems · p5 — Same underlying principle — enforce at runtime, at the point of use, rather than assume correctness from a one-time design or authorization decision — applied to operating mode instead of permissions.
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.conf: high
explicitClosure should be an automated, testable check — the platform replays the exception's declared scope against live routing, approval, tool, and queue configuration and confirms no path still resolves to the emergency behavior — rather than a manual cleanup step someone has to remember to perform.conf: high
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.conf: high
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.conf: high
explicitThe proposed pattern requires no new governance model; it extends existing disciplines for governing identity, permissions, change, and operational risk to operating state itself.conf: high

Arguments

Enterprises building AI agents should treat operating mode (normal/incident/recovery/exception) as a first-class, authoritative runtime input — architecturally equivalent to identity, tenant, and permissions — rather than something agents infer from prompts or memory. strength: medium

Explicit premises:

Temporary exceptions granted under incident pressure routinely outlive the incident because platforms have no mechanism to retire them (p1, p3).
Retiring an exception is quiet and asymmetric compared to declaring it, so exceptions are prone to silently hardening into permanent behavior (p7).
Agents act autonomously across many paths, so an exception can propagate further and become harder to find and retire than in traditional, human-mediated systems (p8).
Memory can explain why an accommodation existed but should not determine whether it is still authorized (p9).

Implicit premises:

Organizations can reliably and continuously translate their existing incident/change-management processes into clean, machine-readable operating-mode state (mode/scope/authority/expiry/status) — the piece assumes narrative incident tickets convert cleanly into a typed runtime contract without addressing that translation gap.
Whatever component enforces gating on operating-mode state (orchestration layer, tool gateway) cannot itself be bypassed, misconfigured, or compromised — the pattern assumes the enforcement point has integrity, without discussing how that integrity is itself guaranteed.
The platform team has, or will readily build, the cross-system engineering capacity to implement scope-aware validation across routing, approval, tool, and queue configuration — treated as a natural consequence of making state explicit rather than as a large undertaking in its own right.
People under the same incident pressure that currently produces informal, undocumented exceptions will reliably fill out the formal mode/scope/authority/expiry contract instead of reaching for an informal workaround — i.e., formalizing the mechanism will not itself be skipped under pressure.

Inferences:

Generalizes from a single incident vignette to a general architectural claim about enterprise agent platforms.
Argues by analogy to already-normalized runtime injection of identity, tenant, and permissions context.
Uses a contrast argument (vs. feature flags, RBAC, tenancy) to establish operating mode as a distinct, necessary primitive rather than a redundant one.

Closure (retirement of an exception) should be implemented as an automated, replayable validation check rather than a procedural or manual step. strength: medium

Explicit premises:

Traditional governance documents exceptions and trusts they are retired; retirement failure is exactly the observed failure mode (p6, p7).
Explicit runtime state (scope, expiry) is structured and queryable, so it can be compared against live configuration (p11).

Implicit premises:

Every path through which an exception can shape execution (routing, approval, tool access, queue) is enumerable and inspectable by the platform at closure time — there is no channel through which an exception's effect can persist outside the platform's own configuration surface (e.g., a downstream cache, a human's private workaround, or a rule that has leaked into a model's memory or a vector store).

Inferences:

Infers from 'state is explicit and typed' to 'therefore closure can be fully automated,' eliding cases where an exception's effects propagate into artifacts the platform doesn't control.

Multi-agent systems require a single, shared, consistently-read operating-mode state — rather than each agent inferring or holding its own — to prevent fragmented accountability. strength: low

Explicit premises:

Collaborating agents can disagree about state, with one continuing emergency behavior after another has reverted (p15).
Shared state gives them a single governance boundary where the exception is represented once and read consistently everywhere (p15).

Implicit premises:

Agents in a distributed multi-agent deployment can read a single shared operating-mode value with effectively no consistency lag — the article assumes an instantaneous, universally-consistent view of 'the mode,' without addressing caching, replica lag, or partial-network-partition scenarios standard in distributed systems.

Inferences:

Extends the single-agent runtime-injection pattern to a distributed multi-agent setting without new supporting evidence specific to multi-agent consistency.

Narratives

A customer-remediation workflow is moved to an emergency route during a service incident (shortened approvals, priority queue, an alternate on-call procedure). The incident ends, but the route stays active for a small customer segment after everyone has moved on. The article closes by replaying this same incident through its proposed fix: with operating mode as runtime state, the route opens only inside a declared, scoped, owned, expiring exception, and closes automatically when the incident closes.
→ Grounds the abstract thesis (exception drift, operating mode as runtime state) in one concrete, mundane example used twice — once to diagnose the problem, once to demonstrate the solution — giving the reader a before/after test of the proposed architecture.

Questions addressed

✅ How does a platform prevent a legitimate, authorized emergency exception from silently becoming permanent, unmanaged runtime behavior?
Treat operating mode as authoritative, scoped, time-bound runtime state, owned by an external control plane, with automated closure validation.
✅ How should an agent decide whether it is currently permitted to use emergency/exception behavior?
Consume authoritative operating-mode state supplied at request time, rather than infer it from prompts, conversation history, or memory.
✅ How can an organization make exception drift observable and measurable rather than discoverable only via audit?
Instrument operating-mode transitions and closures as a monitored runtime signal: count of open exceptions, time open, rate of hardening into permanent change.
⭕ How does this operating-mode layer actually get built and integrated into an existing enterprise's incident/change tooling, and at what engineering cost?
⭕ Does formalizing exception declaration into an easy, lightweight schema risk increasing the volume or scope of exceptions granted (since declaring becomes frictionless), rather than only fixing the retirement problem?

Gaps

incompleteNo treatment of who authors and maintains the mapping between an incident-management system's narrative state (tickets, severity levels) and the proposed six-field runtime contract (mode/scope/authority/expiry/status) — a translation-and-ownership gap structurally identical to one already flagged in the corpus for privilege-drift's permission inventory.
Read next: Platform-as-product / internal-platform-adoption literature on what keeps a shared governance artifact from decaying; read directly against extract-privilege-drift-multi-agent-systems#g1 (who owns the platform-wide permission inventory as it decays).
incompleteNo discussion of what happens when the authoritative operating-mode source itself is unavailable, stale, or wrong (e.g., the incident-management system is down during the incident it's supposed to describe, or a status update lags true resolution). The article treats the external control plane as a reliable oracle and never examines its own failure modes.
Read next: Distributed-systems literature on control-plane/oracle availability and staleness; the gap is structurally parallel to extract-privilege-drift-multi-agent-systems#g2 (what happens if the JIT token-issuing broker is unavailable or slow).
incompleteFormalizing exception declaration into a lightweight schema could itself be gamed: an actor under pressure could declare an overly broad scope or a soft, rolling expiry ("expires: incident-close" where closure is never formally triggered) to durably legitimize what is functionally still an ad hoc workaround. The article never asks whether making exceptions easy to declare could increase their volume or scope rather than shrink drift.
Read next: Goodhart's-law / gaming-the-control literature; compare with the corpus's privilege-drift material on JIT tokens being requested more liberally once the friction to request them drops.
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.
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.
uninformedThe article names feature flags (LaunchDarkly), RBAC, and tenancy metadata as adjacent-but-distinct patterns, and cites ITIL/ISO change and incident frameworks, but never engages existing runtime policy-engine literature (OPA/Rego, AWS Cedar) — which the corpus's own privilege-drift piece names as the concrete tooling category for 'enforce at runtime, at the point of invocation.' Operating mode as proposed here is architecturally a policy-as-code problem (a context attribute gating an authorization decision), and the piece doesn't connect it to that existing ecosystem.
Read next: Policy-as-code literature (OPA, Cedar) for how a 'mode' attribute would actually be evaluated as part of an authorization decision at tool-invocation time; read against extract-privilege-drift-multi-agent-systems#g4.

Operating Mode as Runtime State: A Contract for Enterprise

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents