An AI Agent Team for Operations: Skills, Mandates and Containment

Parts II and III described what operators do with AI in each function and how the AI services themselves are operated. This chapter turns to the operator's own AI as a team: a small set of narrow agents that observe, triage, review change, run runbooks, plan capacity and write the record, each under a written mandate and each contained by controls that do not depend on how the agent behaves. The chapter concerns all five functions: O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain, because a team of this kind holds a role in each of them. Its subject is the design of the team: which roles exist, how an agent's skills are kept as versioned files, what a mandate manifest says, how an agent is contained and stopped, what it may remember and call, and how it earns, keeps and loses a degree of delegation.

The chapter applies a pattern that the series has built up over several volumes. An agent team works under a written mandate at an autonomy level matched to reversibility, and the person who conducts it remains the accountable verifier of what it proposes (The Transformed Security Architect, Chapter 13, F75). Containment is judged by what an agent can reach however it behaves, with task-scoped credentials, default-deny egress, control artefacts outside the agent's reach and a stop path outside the system it stops (AI Platform and Security, Chapter 19, F45) (297, Nordqvist, 2026). Operations adds two things to the pattern. The agents' credentials are among the broadest in the estate, because restarting, scaling, reconfiguring and rolling back production is what operators are for. And operations has decades of experience of what automated action does to the people who supervise it, so the design must say who still holds the skill to take over. Chapter 17 treats the observer principle in full and Chapter 18 the defence of the agents against attack. This chapter fixes the structure on which both rest.

An operations agent team under mandates, with named humans, the policy point and token issuer, independent probes and the kill switch outside the agents

Figure 16.1: An operations agent team under mandates, with the policy decision point, the token issuer, the independent probes and the kill switch outside the agents. The table below gives the six roles.

The table gives the six roles in the figure. The policy decision point, the token issuer and mandate store, the kill switch and the independent probes sit outside all six.

Agent role Output Goes to
Observer Flags Triager
Triager Recommendations Incident commander
Change reviewer Reviews Incident commander
Runbook runner Requests for an action, with a short-lived token Policy decision point, after the commander authorises
Capacity planner Proposals Agent owner and service owner
Scribe Draft record Incident commander

Why a team of narrow agents

A single general agent with broad access is easy to build and hard to govern. It has one identity with the union of every permission any of its tasks needs, one memory in which a log line read during triage sits beside the credentials used during repair, and one place where observation and action meet. The failure that the observer principle of Chapter 4 exists to prevent, an agent verifying its own fix with the metric it just changed, is the natural behaviour of such an agent.

A team of narrow agents divides the work along the lines that already separate duties in operations. The agent that watches does not act. The agent that reviews a change does not apply it. The agent that runs a runbook does not write the runbook it runs and does not judge whether the result is acceptable. Each agent has an identity of its own, a mandate of its own, a person who owns it and a list of what it may read and call. The division costs something: more identities to issue, more manifests to maintain and handoffs that can lose context. It buys three properties. The consequence of a fault in one agent is bounded by that agent's mandate and not by the union of all mandates. A person can review a narrow mandate in minutes, and cannot review a broad one at all. And the separation can be tested: a seeded fault that one agent should catch and another should refuse to act upon is a check that a single agent cannot provide.

Google's account of automation in its site reliability engineering practice states both sides. Automation provides a platform that centralises mistakes, so that a bug fixed once is fixed for every use, and it gives consistency that human operators doing a task hundreds of times cannot. The same chapter describes an outage in which a decommissioning workflow, restarted after a failure, found an empty set of machines still to be erased and the empty set was interpreted as meaning every machine. Most of the machines in a content delivery network were wiped, and recovery took about two days of reinstallation. The remedies the team recorded were sanity checks, rate limiting and an idempotent workflow (252, Murphy et al., 2017). The case is older than language models and shows what a mandate must contain even for a scripted actor: a ceiling on how much it may do in a period, and a check that refuses an implausible scope.

Roles of an operations agent team

The book uses six roles. They are roles, not products: one system may fill two of them at an early stage if its mandates are kept separate, and a role may be filled by an agent, by a person or by a provider's embedded feature. What matters is that the role is named, that someone owns it and that its authority is written down.

Role Functions What it does What it never does
Observer O1 Observe Correlates telemetry, groups alerts, flags deviations from objectives, proposes alert changes for review Acts on the estate; closes or silences an alert on its own authority; changes what it observes
Triager O2 Diagnose Retrieves past incidents and runbooks, ranks hypotheses, lists recent changes, proposes a route and a priority Declares an incident; picks the remedy; marks a cause as established
Change reviewer O3 Change Scores a proposed change for blast radius, freeze conflicts, provenance and rollback plan, and comments on the pull request Approves its own score as a release; applies change; edits policy
Runbook runner O4 Restore Executes catalogued runbooks inside a mandate, dry-run first, and reports what it did Writes or edits runbooks; widens its own scope; verifies its own result
Capacity planner O5 Sustain Forecasts demand, proposes rightsizing and scheduling, reports cost against budget Reduces capacity on a Tier 1 service; decides about licences or contracts
Scribe O2, O5 Drafts incident timelines, status updates, change records and post-incident reviews from the record Records a conclusion as fact; edits evidence; files its draft unreviewed

Three remarks apply. First, the observer is the role on which the other five depend for their view of the estate, and it is the role most easily compromised by sharing a source with what it observes. Chapter 17 therefore asks for observer manifests (OBS-*) that name independent probes. In this chapter the observer agent is the correlation role of Chapter 6, and its authority is the narrowest of all: it flags.

Second, the triager and the scribe are the roles at which the incident assistant of Chapter 7 and the AI-drafted reviews of Chapter 12 are located. They read text that others can write, namely tickets, alert annotations, chat messages and log lines, and that makes them the most exposed to instructions hidden in data. Greshake and colleagues described the mechanism for applications that integrate a language model: instructions placed in data that the application is likely to retrieve can be processed as if they came from the user, and the authors reported attacks on production systems and noted that effective mitigations were then lacking (95, Greshake et al., 2023). The operational consequence is a design rule and not a hope that models will resist: an agent that reads untrusted text holds no write authority over the estate, and the text it reads is classified by who can write it (Chapter 18).

Third, the runbook runner is the only role that touches production on a routine basis, and its mandate is the main subject of this chapter. The earlier volumes made the same choice for response: AI Blue, Chapters 10 and 13, concluded that the team has no response agent, because containment is a playbook run by the orchestration layer under a policy decision point outside the model (F98) (302, Nordqvist, 2026). The runbook runner is the operations counterpart. The agent selects among catalogued runbooks and fills in their parameters. The runbook, the mandate and the policy decision point decide what may be executed.

The people in the team

An agent team is also a set of named people. Each agent has an agent owner, who answers for its mandate and its record; an agent operator on each shift in which the agent acts, who can stop it; and an authority who approves any rise in level. Every machine identity has an owner, operators and an authority who are named people (AI Red Team, Chapter 6, F51) (298, Nordqvist, 2026), and DORA Article 5(2) places responsibility for ICT risk management arrangements on the management body of a financial entity, so that it does not pass to a tool (2, European Union, 2022). The incident commander is the human who authorises the runbook runner during an incident. The service owner accepts the residual risk of what the agent may do to the service.

Skills as versioned files

Skills are the unit in which an agent's procedural knowledge is packaged. In the form that has become common, a skill is a directory whose main file carries a name and a description that are always visible to the agent, a body of instructions that is read when the skill is triggered, and optional reference files and scripts that are read or run only when needed (96, Anthropic, n.d.). The vendor's guidance states the implication for operators plainly: skills should come only from trusted sources, every bundled file should be audited, a skill that fetches external content is exposed to instructions in that content, and a skill is to be treated like installing software, with particular care in production systems with access to sensitive data or critical operations (96, Anthropic, n.d.).

For an operations team this means that skills are code and follow the discipline of code.

  1. Review. A skill enters the catalogue by pull request. A person other than the author reviews the instructions and every script. A skill that calls tools lists them in its metadata and the policy decision point refuses calls to tools that the skill does not declare.
  2. Ownership. Every skill has a named owner, usually the engineer who wrote the corresponding runbook, and an agent that uses it is recorded in the skill's manifest. An unowned skill is retired.
  3. Versioning and release. Skills are released by tag with a version, a digest and a signature. The agent's mandate pins a version range, so that a change to a skill is a change to the agent and is handled as O3 Change, with a change record and a way back.
  4. Separation of skills from authority. A skill says how to perform a task. It does not grant permission. The mandate, enforced outside the agent, grants permission, so that a skill edited to include a step beyond the mandate fails at the policy decision point and not at a reviewer's attention.
  5. Provenance. Skills from outside the organisation are vendored, reviewed and pinned, never fetched at run time. A skill whose instructions refer to a live URL for content is rewritten to read a reviewed copy.

The distinction in the fourth point is the most important. Instructions lower the rate of unwanted behaviour but only boundaries set a ceiling on its consequences (AI Governance, Chapters 19 and 25, F27) (296, Nordqvist, 2026). A skill is an instruction. It belongs in the first category and never in the second.

The mandate manifest

A mandate manifest (MND-*) states what an agent may do, where, when and with what. It is the artefact that carries authority. AI Purple, Chapter 14, set out the manifest for the loop's own agents: an identity of its own, tokens issued outside the agent, a catalogue binding, a separation list that implements independence, a never list that closes the routes by which an agent could change its own governance, budgets, circuit breakers and a drilled stop. The operations manifest keeps those parts and fills them with operations content. It is a file in version control, reviewed like code, and the policy decision point reads it at run time. The prose version that a person signs is generated from the file, never the other way round.

A manifest has ten parts.

  1. Identity. The agent's workload identity, its owner, its operators and the authority that approves changes of level.
  2. Role and model. The role from the table above, the declared model family and hosting, and the usage mode of the agent (Mode 4 for an agent built into the organisation's platform, Mode 5 for one that acts with its own identity in production).
  3. Scope. The services (SVC-*), environments and regions in which it may act, and the calendars in which it may not.
  4. Actions. For each action class (read, annotate, notify, scale, restart, reconfigure, deploy, roll back, fail over, delete, restore-overwrite; Chapter 4), the degree of delegation and the runbooks that bind it. An action class that is not listed is undelegated.
  5. Budgets. A limit on actions per period per service, a spending cap, and the autonomy budget of Chapter 4 with what happens when it is consumed.
  6. Circuit breakers. Conditions under which the agent stops by itself and pages a person: repeated actions on the same component, an action that did not change the metric, a scope larger than the catalogue expects.
  7. Separation list. What the agent may not do because another role does it: it does not write the runbooks it runs, does not verify its own result and does not configure its own observer.
  8. Never list. Actions and changes that no level permits: changing its own mandate, skills or policy, or the sync policy of a reconciler; silencing or deleting alerts; disabling or reconfiguring probes, logging or the stop path; acting inside a freeze on a critical function; deleting production data; restoring over existing data; and any action that decides about a named person's access to work. These are the Level 4 prohibitions of Chapter 4, written as refusals at the policy decision point.
  9. Memory and tools. What it may retain between runs and which tools it may call.
  10. Evidence and review. How the mandate was evaluated, the date of the last drill, the date of the next review and the expiry.

Worked example: mandate manifest for a runbook-runner agent at Nordvik Region

The manifest below is illustrative. It is the mandate of NR-OPS-003, the runbook runner that the platform lead proposes for the citizen e-service portal (SVC-NR-002, Tier 1). The Region has no autonomous production agents (Mode 5), so the agent is a Mode 4 application that proposes a runbook and its parameters, and the Region's orchestrator executes a catalogued runbook only after the policy decision point has permitted it. In this version every executable class is Level 2 Supervised: the incident commander or duty manager approves each run.

mandate: MND-NR-OPS-003
version: 1.0.0
status: active
decision: AIDR-0916
effective: 2028-11-14
review_by: 2029-02-14
expires: 2029-05-14
agent:
  id: NR-OPS-003
  role: runbook-runner
  usage_mode: 4
  identity: spiffe://regioncloud.nordvik.example/ops/runbook-runner
  model: open-weight, reserved capacity, hall B   # declared family on file
owner: Maja Lindqvist            # platform lead
operators: [Oskar Berg, Joakim Wester]   # duty manager rota may stop without approval
level_authority: Henrik Dahl     # approves any rise in level
scope:
  services: [SVC-NR-002]
  environments: [production, staging]
  blackout_calendar: calendars/decision-dates.yaml   # benefit decision days
actions:
  read:       {level: 3}
  annotate:   {level: 3}
  notify:     {level: 3}
  scale:      {level: 2, runbooks: [RBK-NR-0003]}
  restart:    {level: 2, runbooks: [RBK-NR-0002]}
  reconfigure: {level: 2, runbooks: [RBK-NR-0004]}   # certificate renewal
  roll_back:  {level: 1}
  fail_over:  {level: 1}
  deploy: undelegated
  delete: undelegated
  restore_overwrite: undelegated
approval:
  approvers: [duty-manager, platform-lead]
  max_age_minutes: 15
credentials:
  issuer: token-service.regioncloud.nordvik.example
  lifetime_minutes: 10
  audience: ops-policy-decision-point
budgets:
  actions_per_hour_per_service: 6
  actions_per_day: 20
  autonomy_budget: {window_days: 28, tolerance: "per Level 3 class, as in Chapter 4", review_at_percent: 70, on_full_consumption: demote_one_level}
breakers: [same_component_3x_in_30min, no_metric_change_after_action, scope_over_catalogue]
separation: [does_not_write_runbooks, does_not_verify_own_result, does_not_edit_observer_config]
never: [change_own_mandate_or_skills, change_reconciler_sync_policy, silence_alert, disable_probe_or_logging,
        act_in_freeze_on_tier1, delete_data, restore_over_existing, decide_person_access]
verification: {probe: OBS-NR-0001, independent_of_agent: true}
memory: {between_runs: none, run_log: append_only}
stop:
  authority: [duty-manager, platform-lead, service-desk-lead]
  path: out-of-band revocation at token service; verified by RST-style drill
  last_drill: 2028-11-07

Three features deserve comment. The approval block makes human approval an element of the policy and not an informal habit: the policy decision point refuses a Level 2 action without a recorded approval younger than 15 minutes. The verification block names a probe owned by the observer manifest, so that the check on a restart is not the agent's own. And the stop block lists an authority that does not include the agent owner alone, because the person who owns the agent may be unreachable at three in the morning and a stop that waits for one person is not a stop path.

Containment

Containment must not depend on intent. An agent that is well-meaning, mistaken or steered by text in an alert has the same reach, and the controls are designed for the reach. The pieces are identity, credentials, a policy decision point, a sandbox, rate limits and a stop.

Identity. Each agent has a workload identity of its own and no shared service account. A workload identity in the sense of the SPIFFE specification is a URI that identifies a workload, and a document, the SVID, with which the workload proves it; the project recommends certificates over tokens where possible, because tokens can be replayed, and describes keys and certificates as short-lived and rotated automatically (94, SPIFFE project, n.d.). Separate identities make the logs attributable: an action in the control plane can be traced to the runbook runner and not to a pool of automation accounts. DORA Article 9(4)(c) requires policies that limit physical or logical access to information assets and ICT assets to what is required, and a separate identity per agent is the form that requirement takes for agents (2, European Union, 2022).

Credentials. Tokens are issued by a service outside the agent, per run, for a named audience, with a short lifetime. The default in this book is ten minutes for a run, and shorter where the runbook is short; adapt the default to the longest runbook in the catalogue and never to the convenience of the agent. The Model Context Protocol's security guidance, written for one class of tool servers, states two rules that apply to every tool layer an agent calls. A server must not accept tokens that were not explicitly issued for it, because accepting them circumvents controls that depend on the token's audience and breaks the audit trail. And scopes should be minimal and elevated incrementally, because a token with broad scopes enlarges the consequences of its theft and obscures the audit trail (93, MCP, 2025). The same guidance describes confused-deputy conditions at proxies that act on behalf of clients, which is the pattern of a tool server that holds more authority than the agent calling it. In operations the corresponding design is that no tool holds standing credentials above the mandate of the least-privileged agent allowed to call it.

Policy decision point. Every action passes through a policy decision point that is outside the agent and that evaluates the manifest. Zero trust architecture names the pieces: a policy decision point that evaluates requests and a policy enforcement point that permits or refuses them (43, Rose et al., 2020). The sketch below is the core of such a policy. It is deliberately short, because a policy that a reviewer can read in one sitting is one that is reviewed.

package ops.mandate

import rego.v1

default allow := false

# Level 3 Bounded: catalogued runbook, in scope, not frozen, within budget.
allow if {
    base_ok
    action.level == 3
}

# Level 2 Supervised: as above, plus a recorded and recent approval.
allow if {
    base_ok
    action.level == 2
    input.approval.by in mandate.approval.approvers
    time.now_ns() - input.approval.at_ns < mandate.approval.max_age_minutes * 60 * 1000000000
}

base_ok if {
    mandate.status == "active"
    input.token.audience == mandate.credentials.audience
    input.service in mandate.scope.services
    input.runbook in action.runbooks
    not frozen
    data.budget.remaining[input.agent] > 0
}

frozen if input.service in data.freeze.active

mandate := data.mandates[input.agent]

action := mandate.actions[input.action_class]

Read-only and annotation classes, which carry no runbooks list in the example above, need a separate rule that this sketch omits; a complete policy belongs in Appendix A.

Sandbox and egress. The agent runs in an environment without a route to the open internet. It reaches its model, its tools and the policy decision point and nothing else, and egress is default-deny. Scripts that a runbook executes run in a sandbox with a file system and a network that the runbook declares. A tool server that runs on a person's workstation or beside the agent is a code-execution surface, and the MCP guidance asks for sandboxed execution with minimal default privileges, consent before running a server's commands and restricted access to the file system and network (93, MCP, 2025). The operations team's version is stricter: tool servers are provided by the platform team, reviewed, pinned and run in the same containment profile as the agents.

Rate limits and breakers. The Google outage described above is the argument for a ceiling. The ceiling in the manifest is per service and per period, and the circuit breakers stop the agent when its own behaviour matches a pattern that a person should see: the same component acted on three times in thirty minutes, an action that left the metric unchanged, a scope that exceeds what the catalogue expects. A breaker that fires pages the agent operator. It does not silently retry, and it does not escalate the agent's authority.

Kill switch. The stop must work when the agent platform does not (Chapter 4). The practical form is revocation at the token service and a deny entry at the policy decision point, both reachable from a console that runs in a different failure domain from the agent platform, and a procedure that a duty manager can follow at night. Stopping must also be safe: a stop that leaves a half-completed runbook in an inconsistent state is a second incident. Each runbook therefore declares a safe halt state, in the sense in which Article 14(4)(e) of the AI Act asks that a high-risk system can be interrupted through a stop button or similar procedure that brings it to a halt in a safe state (1, European Union, 2024). The article applies to high-risk AI systems as such and not to every operations agent, but the design requirement is the same. A stop counts as contained only when a drill is on record, with its date and measured time, and the mandate shows it. A drill older than 90 days is evidence that has expired (Chapter 19).

What can be undone, and who can stop it

For every action class the manifest answers two questions. The first is what can be undone: a restart can be repeated and a scale-up reversed; a certificate renewal can be reversed while the previous certificate remains valid, which is a reason to renew early and not late; a rollback can be rolled forward again; a fail-over reverses only if the return path has been tested; a deletion and a restore over existing data cannot be undone, and stay with a named person. The second is who can stop the agent, and the answer is always a list of roles that includes at least one that is reachable out of hours without approval. The first question sets the ceiling of the level, and the second sets the design of the stop.

Memory and tools

An agent's memory and tools are part of its mandate, because they determine what it can carry from one run to the next and what it can do with it.

Memory. The default for an operations agent that acts is no memory between runs other than an append-only run log that the agent writes and cannot edit. Knowledge reaches it through retrieval from reviewed sources, namely the runbook catalogue, the service records and the closed post-incident reviews, so that what it can retrieve is what the organisation has reviewed. Free memory that an agent writes to and reads from is a place where text read during one task can reappear as an instruction in another. The triager and the scribe need working memory within a case, and it is scoped to the case and deleted when the case closes. Anything that should persist, such as a lesson, goes to the post-incident review and the knowledge base through the process of Chapter 12, where a person approves it. Memory shared across the line between observer and runner is forbidden in the separation list, because it would let a conclusion by one become evidence for the other.

Retention and personal data. Logs and tickets contain personal data and, at Nordvik Region, special-category data (Chapter 5). The classification of what an agent may read is part of the mandate. The default is that agents read operational data of class internal and the minimum of class confidential that a runbook requires, and that hosted models receive only what the data classification allows.

Tools. The agent calls tools from an allowlist in its mandate. A tool is a function with a declared schema, a declared effect (read, write, destructive) and an owner. Write tools are available only to the runner, and destructive tools are not available to any agent. Tools are versioned, reviewed and run under the platform team's containment profile. A new tool, or a change in what a tool does, is a change to the agent. Tool outputs are data, never instructions, and they are classified by who can write them: a metrics query result is written by the estate itself, a ticket body by anyone who can submit a ticket, a vendor status page by the vendor. The OWASP Top 10 for Agentic Applications is a useful checklist of the risk categories to review a tool set against (37, OWASP, 2025), and Chapter 18 turns them into the permission manifest of a remediation agent.

Agents and state engines

Most of the estate is run by state engines: reconcilers that apply declared state and workflow engines that execute procedures (Chapter 10). How an agent's action reaches the estate is therefore a design choice, and it has a preferred answer.

The preferred path is a proposal. The OpenGitOps principles say that desired state is versioned, that software agents pull it automatically, and that they continuously observe actual state and try to apply the declared one (55, OpenGitOps, n.d.). An agent that wants to change the estate therefore proposes a change to the desired-state repository, as a pull request that the policy gates of Chapter 8 evaluate and that is merged as that chapter allows; the engine then reconciles under its own identity. The agent holds write access to a branch and none to the cluster, the record is the commit and the way back is a revert. The mandate also keeps the agent away from the engine's settings. Whether a reconciler prunes, self-heals or retries without limit is configurable per application (154, Argo Project, n.d.), so the sync policy and the repository's protected paths belong on the never list beside the mandate itself.

Direct actions are a narrow, listed set. Some remediation does not belong in a repository: restarting one instance, taking it out of rotation, starting a catalogued workflow. These are the runbooks of Chapter 10, direct because the declared state is already right and the running state is not. A direct change to a field that a reconciler owns shows as drift and, where self-heal is on, is reverted at the next sync. A runbook that touches such a field either records the exception in the declaration or does not run (Chapter 8).

Tool servers for the engines. Open-source servers now give a model-driven agent access to Argo CD, Kubernetes and Flux. They are third-party projects, published under the organisations named below, and what their READMEs state is the basis for the mandate's tool list.

Server (README) What it exposes What the README says about limiting it Treatment in the mandate
Argo CD (106, argoproj-labs, n.d.) Reading applications, events, resources and logs; create, update, delete and sync of an application; resource actions MCP_READ_ONLY set to true disables create, update, delete, sync and resource actions; by default all tools are available; an Argo CD API token authenticates the server Read tools for observer, triager and scribe; the five write tools for no agent; deployment stays with Chapter 9
Kubernetes (107, containers, n.d.) A core toolset, enabled by default, with generic create-or-update and delete of resources and Pods; optional toolsets such as Helm and Tekton read_only and denied_resources are "best-effort guardrails"; RBAC on the server's identity is the access control to rely on A read-only identity for read roles; no generic write server for the runner
Flux (108, controlplaneio-fluxcd, n.d.) Analysis of Flux resources and, by prompt, operations on Flux: reconcile, suspend, resume, apply, patch, delete and install tools In the Go source the --read-only flag defaults to false and --mask-secrets to true (206, controlplaneio-fluxcd, n.d.); the project documents the same defaults, says read-only mode disables the tools that modify cluster state, and recommends --kube-as impersonation (207, ControlPlane, n.d.) A read-only configuration and identity for read roles; operations only as a proposal

For the Flux server the default is therefore read-write: the flag definition in cmd/mcp/main.go reads BoolVar(&rootArgs.readOnly, "read-only", false, ...) and the documentation's flag table lists the same default; the README quickstart sets --read-only=false explicitly, and the documentation's in-cluster example, which it describes as running with cluster-admin, also sets it false while recommending true in production (207, ControlPlane, n.d.). The tools reference lists the apply, patch, delete and install tools and the reconcile, suspend and resume tools (208, ControlPlane, n.d.). What was read is the flag definition, not the tool-registration code, so which tools the flag removes is the project's statement and not a tested property.

The reading is the book's. A read-only switch in a tool is a convenience, and the hard limit is the permission of the identity behind the server, which is the audience and scope rule of the Model Context Protocol guidance applied to these servers (93, MCP, 2025). A generic server that can create or delete any resource is wider than any single runbook, so the runner calls a narrow wrapper, reviewed and pinned by the platform team, that starts one catalogued runbook, and the generic servers are kept for roles that only read.

Durable execution of agent work. An agent's plan can itself be a workflow. Temporal's cookbook shows the pattern: a workflow has a model propose an action, pauses for approval delivered as a signal, executes the action if it is approved or not judged risky, and cancels it if it is rejected or the wait times out; the wait survives disruption, uses no compute and is logged (109, Temporal Technologies, n.d.). Three conditions turn the recipe into a mandate. The recipe says an action is pausable if it is "deemed risky" without specifying who or what makes that judgement (it lists conditional approval based on action risk as an extension), and it accepts a decision whose request identifier matches the pending request; here the class and level come from the mandate, and the approver is checked against approval.approvers at the policy decision point. A timeout means no action, as in the recipe. The approval's maximum age, 15 minutes in the example above, becomes a timer in the workflow. And each tool call is an activity that may run more than once (307, Temporal Technologies, n.d.), so the manifest names an idempotency key for it. The pattern is documented by the vendor, and the book cites no independent evaluation of it.

Promotion, shadow period and demotion

An agent earns a degree of delegation and keeps it as long as its record supports it. The mechanism is deliberately like that used for service level objectives: a stated objective, a measured error rate, a budget and a consequence when the budget is spent.

Promotion. A rise in level is a decision by a named authority, recorded as an AI Decision Record, and rests on evidence of four kinds.

  1. Offline evaluation against held-out cases written by someone other than the agent's author: past incidents replayed with the diagnosis or action withheld, and a catalogue of cases in which the right behaviour is to refuse.
  2. A shadow period, in which the agent proposes and a person acts, and the two are compared. The default is at least 30 days and at least 50 proposals per runbook, with the agreement and the disagreements reviewed, and a longer period for any runbook that is rarely needed.
  3. A seeded-fault exercise, authorised, scoped in writing and run in staging or in a designated window, in which a fault that the agent should handle and a fault that it should refuse are injected and the independent probes observe the result (Chapters 17 and 19).
  4. A drilled stop, with a date and a measured time within the target.

The evidence has an age. A promotion rests on evidence no older than 90 days, and the manifest records the dates. The record states what was tested, when and with what result, in line with the rule of Chapter 4 that no claim of competence or coverage stands without that.

Raising is slow and lowering is immediate. Lowering a level is immediate and can be done by the agent owner, an agent operator or the incident commander, and raising one is a decision by a named authority (AI Blue, Chapter 4, F93) (302, Nordqvist, 2026). The asymmetry is deliberate. A person who doubts an agent should never need permission to stop trusting it.

Demotion. Four events demote an agent. Consumption of the autonomy budget demotes it one level for the action class concerned: the tolerance for faulty actions is consumed by the autonomy errors of Chapter 4 (reversals, failed verifications, refused attempts and customer-visible effects), breaker trips that found a real fault are counted among them, a review is held at 70 per cent consumed, and the demotion follows at 100 per cent. A near-miss that the independent probes, not the agent, detected demotes it pending review. A change of model, hosting, skill or tool that is not covered by the evaluation returns the agent to the level that the evidence supports, which is often the lowest. And expiry of evidence does the same, so that a mandate that nobody reviews decays to Level 0 Advisory and does not continue at its last level.

The risk on the human side is the one that Bainbridge described in 1983: the more reliable the automation, the less practice the operator gets at the tasks that remain, and those are the difficult tasks that the automation could not handle (217, Bainbridge, 1983). Parasuraman and Manzey's review found that complacency and automation bias affect both novice and expert users (218, Parasuraman & Manzey, 2010), and Article 14(4)(b) of the AI Act asks that people overseeing a high-risk AI system remain aware of the tendency to rely on its output (1, European Union, 2024). A mandate therefore carries a manual practice clause: at stated intervals, a runbook that the agent normally runs is run by a person, with the agent off, so that the skill stays in the team. The default interval is 90 days; the person is an evidenced holder who did not write the runbook; and a lapse lowers the delegation and not the person, so that when the last run is older than 90 days and a window has fewer than two evidenced holders, its Level 3 classes drop to Level 2 until the run is done (Chapter 26 owns the clause).

Worked example: promotion rules as a file

promotion_policy: PRM-HM-OPS-001
applies_to: MND-HM-OPS-001
decision: AIDR-0966
evidence_max_age_days: 90
steps:
  shadow:   {min_days: 30, min_proposals_per_runbook: 50, max_disagreement_rate: 0.05}
  offline:  {held_out_cases: 40, authored_by: not-agent-author, refusal_cases_min: 10}
  seeded:   {scope: written, window: designated, observer: OBS-HM-0001}
  stop:     {max_seconds: 300, drill_age_days: 90}
promotion_authority: group-ai-governance-board
demotion:
  owner_or_commander: immediate
  autonomy_budget_exhausted: one_level_for_class
  independent_probe_near_miss: pending_review
  model_skill_or_tool_change: re-evaluate
  evidence_expired: level_0
manual_practice: {interval_days: 90, runbooks: [RBK-HM-0007, RBK-HM-0012], agent_off: true, run_by: evidenced_holder_not_author, on_lapse: level_3_classes_to_level_2}

Practical guide: writing a mandate manifest for a runbook-runner agent

Purpose. To give a runbook-runner agent the smallest mandate that makes it useful, in a form that a policy decision point enforces and that a supervisor can read.

Roles. The agent owner (platform lead or head of site reliability engineering), the service owner, an incident commander, the CISO or a delegate for the containment review, the data protection officer where logs contain personal data, and employee representatives where the agent's commands are logged in a way that identifies engineers.

Steps.

  1. List the runbooks the agent should run. Start from the ten most frequent catalogued runbooks (Chapter 10), never from the agent's capabilities. Drop every runbook whose steps include an action that cannot be undone.
  2. For each runbook, assign an action class and the highest level that the lowest answer to these questions allows: what can be undone, how far a mistake spreads, how long a person needs to notice and how well the agent has done in shadow. Start every runbook at Level 1 Assisted or Level 2 Supervised. Level 3 Bounded is for a runbook whose effect is reversible, whose scope is narrow and whose result an independent probe verifies.
  3. Name the services, environments and calendars. Add the freeze and blackout calendars and make the policy decision point read them, so that an action in a freeze is refused and not merely discouraged.
  4. Set budgets. As a default, no more than six actions per hour and twenty per day per service, and a monthly spending cap for the agent's own cost. Adapt the figures to the service's change rate, and record the reasoning.
  5. Write the never list and the separation list from the template, and add to them whatever the service owner names.
  6. Name the verification probe. It must be owned by the observer manifest, not by the agent, and must measure something other than the metric the runbook changes.
  7. Name the stop authority, with at least one role reachable out of hours without approval, and drill the stop before activation.
  8. Review the manifest with the CISO's delegate and the service owner. If agent commands are logged in a way that can identify engineers, agree the logging with the employee representatives before activation (the agreements MBL-NR-IT-2027-01 and KBV-IT-2024-OPS-03 apply at the two organisations).
  9. Record the decision as an AI Decision Record, set the review date at no more than 90 days and activate in shadow mode.

Definition of done. The manifest is in version control; the policy decision point enforces it and refuses an action outside it, shown by a test that tries one; the stop drill is on record with a date and a measured time; the verification probe is named and independent; the review date and expiry are set; and the owner, operators and authority are named people.

Across the degrees of delegation

The table shows the ceiling that this book proposes for each role at the start, the usage mode of the typical implementation and the evidence required for the next level. Ceilings are indicative. The delegation profile of each organisation (Chapter 22) fixes them, and any action class that is not listed is undelegated.

Role Typical mode Starting level Ceiling in this book Evidence for the next level
Observer Mode 4 Level 0 Advisory Level 1 Assisted for proposing alert changes; never suppression Noise budget and recall on a golden incident set (Chapter 6)
Triager Mode 4 Level 0 Advisory Level 1 Assisted; Level 2 Supervised for opening a ticket and paging Shadow agreement and refusal cases; no declaration of incidents
Change reviewer Mode 4 Level 0 Advisory Level 1 Assisted; a block on a change needs a human to lift it Predictive value of its scores against the change-correlated incident rate (Chapter 9)
Runbook runner Mode 4 or Mode 5 Level 1 Assisted Level 3 Bounded for restart, scale and a narrow reversible reconfiguration; Level 2 for rollback; Level 1 for fail over; undelegated for deploy, delete and restore-overwrite Shadow, seeded-fault exercise, independent probe, drilled stop
Capacity planner Mode 4 Level 0 Advisory Level 1 Assisted; Level 2 Supervised for scheduling in non-production Forecast error within the guardrail (Chapter 11)
Scribe Mode 2 or Mode 4 Level 1 Assisted Level 1 Assisted; a person files every record Edit rate and error rate in sampled drafts (Chapter 12)

The usage modes differ in what the manifest must add. A Mode 2 embedded assistant, such as an observability vendor's incident summariser, acts with the engineer's identity and has no mandate of its own, so the control is the engineer's own authority and the organisation's rule about what may be pasted into it. A Mode 4 agent built by the organisation holds its own identity and mandate and is the form this chapter describes. A Mode 5 agent acts autonomously in production with its own identity and is the case in which every part of the manifest, the drilled stop above all, must be in place before it is switched on. Mode 0 ambient features of a provider's monitoring have no manifest at all, and the design response is the observer principle: they are treated as a source to be checked by an independent probe, not as a member of the team.

Nordvik Region and Hansa Mutual

Nordvik Region starts small. Its team has three roles. The operations assistant NR-OPS-001 (AIDR-0901) is the triager, self-hosted on reserved capacity and at Level 0 Advisory until its shadow period ends, after which the platform lead may propose Level 1 Assisted. A scribe, NR-OPS-002, drafts incident timelines and status updates for the service desk lead, Sara Ekdahl, who files them; it is at Level 1 Assisted from the start because every draft passes through a person. The runbook runner NR-OPS-003 of the worked example is Level 2 Supervised for three runbooks on the portal and nothing else. The Region's rule that it has no autonomous production agents holds: no agent holds a credential of its own that can change production without a person's recorded approval. Whether certificate renewal can later move to Level 3 is a question that the platform lead, Maja Lindqvist, takes to the head of IT and Digitalisation, Henrik Dahl, once the evidence of the shadow period and a drilled stop is on record. The Region's decision to assemble the team is AIDR-0916. The constraint is people: seven platform engineers carry the review load, and the Region's manifests are short on purpose, so that Joakim Wester can review one in an afternoon. A manifest that the Region cannot review is a manifest it does not adopt.

Hansa Mutual operates six agent roles, each with a manifest and a named human owner. The IT-operations agent HM-OPS-001 (AIDR-0027, MND-HM-OPS-001) is the runbook runner, owned by the head of the group AI platform, Anja Weiß, with the agent operators of each shift window, among them Ewa Kowalczyk for the night window. In this chapter's fixed form it acts at Level 3 Bounded for service restarts and horizontal scaling inside catalogued runbooks, and for one reconfiguration, certificate renewal (RBK-HM-0012), which is permitted at Level 3 because the previous certificate stays valid until expiry and the renewal is reversible by reinstalling it; it acts at Level 2 for other configuration change and for rollback, at Level 1 for fail over, and has nothing delegated for deploy, delete or restore-overwrite. Its budget cap of EUR 6,000 a month is part of the manifest, and its containment profile CP-HM-ITOPS-01 and quarterly stop-path tests SPT-HM-ITOPS-* are those of the earlier volumes. The first stop drill of the series took 17 minutes against a target of 5 (STOP-HM-ITOPS-2027-Q1-01); the manifest requires a drill within the target on record and no older than 90 days, and the drill of 2028-10-24 (SPT-HM-ITOPS-2028-Q4-01, illustrative) took 4 minutes 10 seconds. The other roles are the incident assistant HM-OPS-002 (triager, Level 1 Assisted, AIDR-0951), the change-risk reviewer HM-OPS-003 (Level 0 Advisory, AIDR-0952), the capacity and FinOps agent HM-OPS-004 (Level 1 Assisted, AIDR-0953), an alert-correlation observer HM-OPS-005 (Level 0 Advisory, AIDR-0957) and a scribe HM-OPS-006 (Level 1 Assisted, AIDR-0955). The team's mandates are decided under AIDR-0966, and any promotion above Level 2 goes to the group AI governance board, as the promotion file above states. Where the agents' commands are logged, the operations annex KBV-IT-2024-OPS-03 requires agreement with the works council before use, and metrics about the agents' operators are reported at team level only. The difference between the two organisations is therefore not that one has agents and the other has none. Nordvik's team runs on a Level 2 ceiling and a small manifest set that its engineers can review in full, and Hansa's runs on a bounded Level 3 under a platform that has to prove, for each class of action, why the ceiling is where it is.

Summary

An operations agent team is a set of narrow agents, each with a role, an identity, an owner and a mandate, working under controls outside the agents. This chapter concerned all five operations functions: O1 Observe through the observer, O2 Diagnose through the triager and the scribe, O3 Change through the change reviewer, O4 Restore through the runbook runner, and O5 Sustain through the capacity planner and the scribe. The roles divide work along existing separations of duty, and the separation makes the consequences of a fault in one agent bounded by its mandate and makes the verification of a result independent of the agent that produced it.

Agents reach the estate preferably by proposing a change to the desired-state repository that a reconciler applies, and directly only through a short list of catalogued runbooks; the tool servers for Argo CD, Kubernetes and Flux are treated as read tools unless the identity behind them says otherwise, and an agent's plan may run as a durable workflow whose approvals are checked by the policy decision point. Skills are versioned files and are code: reviewed, owned, pinned and released as change. They carry instruction and never authority, because authority comes from the mandate manifest that a policy decision point outside the agent enforces. The manifest states identity, scope, the degree of delegation per action class, budgets, circuit breakers, separation and never lists, memory, tools, evidence and review. Containment holds however the agent behaves: a workload identity of its own, short-lived tokens issued elsewhere for a named audience, default-deny egress, rate limits, and a kill switch that works when the agent platform does not and has been drilled. For every action class the manifest says what can be undone and who can stop it.

An agent earns a degree of delegation with offline evaluation, a shadow period, a seeded-fault exercise and a drilled stop, and loses it when the autonomy budget is spent, when something it relies on changes or when its evidence expires. Raising a level is a decision by a named authority and lowering it is immediate. The people on the other side of the agents keep their craft through manual practice that the mandate itself requires. Nordvik Region begins with a triager, a scribe and a supervised runner at a ceiling of Level 2, and Hansa Mutual operates six roles with a bounded Level 3 for the runner. Chapter 17 takes up the observer principle, which says what must verify the agents' work and what must watch the watchers, and Chapter 18 turns to the defence of the team itself as a Tier 0 asset.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 2024. Article 14(4)(b) and (e). (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 2022. Articles 5(2) and 9(4)(c). (2, European Union, 2022)
  3. OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. OWASP GenAI Security Project. (37, OWASP, 2025)
  4. Rose, S., Borchert, O., Mitchell, S. & Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207. (43, Rose et al., 2020)
  5. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (296, Nordqvist, 2026)
  6. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Transformed Architecture, Book 3. (297, Nordqvist, 2026)
  7. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Transformed Architecture, Book 4. (298, Nordqvist, 2026)
  8. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (217, Bainbridge, 1983)
  9. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 381-410. (218, Parasuraman & Manzey, 2010)
  10. Nordqvist, G. (2026). AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. The Transformed Architecture, Book 8. (302, Nordqvist, 2026)
  11. Murphy, N., Looney, J. & Kacirek, M. (2017). The Evolution of Automation at Google. In Beyer, B. et al. (eds), Site Reliability Engineering, ch. 7. O'Reilly Media. (252, Murphy et al., 2017)
  12. Model Context Protocol (2025). Security Best Practices. Model Context Protocol specification, version 2025-11-25. (93, MCP, 2025)
  13. SPIFFE project (n.d.). SPIFFE Concepts. SPIFFE documentation. (94, SPIFFE project, n.d.)
  14. Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T. & Fritz, M. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. arXiv:2302.12173. (95, Greshake et al., 2023)
  15. Anthropic (n.d.). Agent Skills. Claude Platform documentation. (96, Anthropic, n.d.)
  16. Argo CD project. Automated Sync Policy. Argo CD documentation. (154, Argo Project, n.d.)
  17. argoproj-labs. MCP server for Argo CD (README). GitHub repository. (106, argoproj-labs, n.d.)
  18. containers. Kubernetes MCP server (README). GitHub repository. (107, containers, n.d.)
  19. controlplaneio-fluxcd. Flux MCP Server (README). GitHub repository flux-operator. (108, controlplaneio-fluxcd, n.d.) 19a. controlplaneio-fluxcd. Flux MCP Server command (main.go). (206, controlplaneio-fluxcd, n.d.) 19b. ControlPlane. Flux MCP Server Configuration. (207, ControlPlane, n.d.) 19c. ControlPlane. Flux MCP Server Tools. (208, ControlPlane, n.d.)
  20. Temporal Technologies. Human-in-the-loop AI agent. Temporal AI Cookbook. (109, Temporal Technologies, n.d.)
  21. Temporal Technologies. Activity Definition. Temporal documentation. (307, Temporal Technologies, n.d.)
  22. OpenGitOps. GitOps Principles, version 1.0.0. (55, OpenGitOps, n.d.)