An Agent Is Not an Operating Capability Until Someone Owns the Pager
By Equipo Quantum Developers
Summarize:
Operating thesis
An agent may complete a demonstration and still not belong in operations. The test is not whether it responds. The test is whether somebody accepts its alerts, funds recurring cost, decides when to reduce autonomy, and can retire it without losing cases. If those decisions have no owner, the enterprise owns a technical demonstration rather than a capability.
NIST calls for inventory, clear roles, continuous monitoring, and safe deactivation processes in the AI RMF Core. The decisive step is therefore not “moving to production.” It is signing an operating charter that assigns authority and resources across the lifecycle.
The charter that turns software into a service
The document should fit on two pages and point to live evidence. Its blocks are:
| Block | Decision made explicit |
|---|---|
| Purpose | object, population, outcome, and prohibited actions |
| Owner | person accountable for outcome and residual risk |
| Authority | who changes policy, permissions, models, and scope |
| Service | operating window, SLO, dependencies, and degraded mode |
| On-call | actionable alert, first response, and escalation |
| Runbook | diagnosis, pause, recovery, and reconciliation |
| Budget | build, usage, review, support, and contingency |
| Changes | tests, approval, version, and rollback |
| Evidence | events, artifacts, retention, and access |
| Retirement | triggers, owner, case destination, and credentials |
A list of names is insufficient. The owner needs actual authority to stop execution, negotiate budget, and accept or reject risk. If operations handles incidents while product can expand scope without approval, accountability is fictional.
Start with purpose and boundary, not an agent name
Describe the object and action: “propose collection assignment for cases with complete documentation,” not “intelligent finance agent.” State eligible population, observable outcome, and irreversible point. Record actions that always require a person and sources that may never be used.
This prevents two failures. The first is silent expansion: a useful agent receives new tasks without new assessment. The second is diffuse accountability: after failure, every team says it owned only one component. The charter names one outcome owner and specific owners for data, platform, control, and response.
An SLO with a consequence
Google defines an SLO as a target for a service indicator and distinguishes agreements by their associated consequences in Service Level Objectives. A minimum agent set can cover:
- eligible cases accepted by the flow;
- decisions verified as correct;
- exceptions assigned within the window;
- closures with complete evidence;
- irreversible actions with valid approval;
- age of the pending queue.
Every breach needs a response. Missing evidence blocks closure; declining quality returns the agent to recommendation; an aging queue narrows eligibility; a failed dependency activates degraded mode. An indicator without an agreed consequence informs but does not govern.
On-call and runbook: who wakes up and what they can do
Not every alert deserves a page. An on-call alert should represent a threat to the outcome or SLO and be actionable. Google SRE’s chapter on Being On-Call emphasizes clear escalation paths, defined procedures, and sustainable load. Copying a rotation without enough capacity turns a design gap into human exhaustion.
The alert card carries the affected object, severity, safe first action, required permission, and domain escalation. The runbook distinguishes four failures:
- Model or rule: anomalous output; revert version or switch to recommendation.
- Tool: an external action fails; stop unsafe retries and protect idempotency.
- Data: source is late or inconsistent; freeze the affected population.
- Human operation: review or approval lacks capacity; prioritize by consequence.
After recovery, the team reconciles cases left in uncertain states. A restart is not a resolution when an action might have executed before failure.
A budget with an owner
Operating cost includes consumption, integrations, evidence storage, observability, review, on-call work, incidents, and changes. The FinOps Principles center business value and ownership of technology usage and cost. The charter should name the cost center, boundary, anomaly signal, and person authorized to change it.
The purpose is not a blunt cap that drops the agent at month end. Define modes: inside budget, operate; near the boundary, reduce nonpriority work; outside it, require an owner decision. Cost per outcome matters more than cost per call.
Change and reauthorization
Policy, source, tool, model, prompt, permission, and population are versioned components. The charter classifies a change as routine, material, or emergency. A material change requires representative tests, owner review, and rollback. An emergency change expires and receives retrospective review.
Reauthorization begins when possible consequences change, a new population appears, evidence degrades, or cost no longer sustains value. Do not wait for an annual meeting when context changed today.
Retire without leaving invisible debt
The retirement rule names triggers: purpose no longer exists, control is ineffective, cost leaves its range, a replacement is available, an obligation changes, or outcomes cannot be verified. The plan stops intake, resolves or transfers cases, retains evidence according to policy, revokes identities, removes secrets, and updates the catalog and runbooks.
In Quantum Automation Center, catalog, states, timelines, artifacts, logs, analytics, permissions, and approvals can connect the charter to actual runs. The charter should not become a forgotten PDF; each link should resolve to the current operating object.
The acceptance test
Before calling the agent a capability, require a demonstration:
- the owner explains the accepted outcome and the decision not delegated;
- on-call receives a test alert and locates the case;
- the operator pauses intake without losing the queue;
- the team reverts a change and reconciles state;
- finance identifies full cost and its boundary;
- control reconstructs one decision from evidence;
- the owner performs a simulated retirement.
These are not ceremonies. They expose missing permissions, single-person dependence, and documentation that never worked.
The strongest counterargument
A complete charter can make exploration expensive. A small team may spend more time designing rotations and documents than learning whether the idea solves a problem. Premature discipline may also freeze an architecture that should still change.
That argument is valid for isolated, reversible tests. Use a light charter: owner, data boundary, small budget, and expiry. The full contract appears before production impact or operating dependency. What cannot happen is a “pilot” processing real work for months without accountability.
When not to use this approach
Do not apply the full contract to an isolated prototype that does not touch production, retain sensitive data, or affect real work when removed. Still give it an owner and expiration.
Use the charter as soon as a person depends on the output, an action reaches a system of record, or interruption creates a queue. At that point, owner, pager, runbook, budget, and retirement are not bureaucracy. They are the definition of an operating capability.
Sources
Article topics
