An AI agent is not a feature. It is a production system that calls APIs, writes to databases, costs money on every invocation, and can be wrong in ways no software bug is wrong. By the middle of 2026, the teams that have agents running well in production have stopped treating them like deployed code and started treating them like deployed services — with on-call rotations, change-management processes, named owners, and a governance function that signs off on what the agent can touch. The teams that have not done this are paying for it. They are paying in late-night incidents nobody owns, in stakeholder anger about hallucinated record writes, in cost surprises that show up two weeks after the fact, and in the slow erosion of trust that happens when an agent quietly degrades and the team only finds out at the QBR. This lesson is the operating model. The four roles. The RACI. The on-call. The change-management gate. The incident response framework. Borrowed from Site Reliability Engineering, adapted for the fact that the system being operated is probabilistic and the failure modes are continuous, not binary.

Why Agent Ops Is a Distinct Function

The first instinct of every engineering team that ships an agent is to treat it like any other service. The team owns the code. Whoever pushed the change is on the hook. If something breaks, page the on-call. If costs spike, file a ticket. The team did this for the monolith, did this for the microservices, and assumes they can do this for the agent.

It does not work. Agents fail differently. The failure modes are not the failure modes traditional on-call rotations were designed for.

The three new categories of failure

A traditional service fails in three categories: it returns errors, it is slow, or it is unavailable. The on-call playbook for each category has been refined over thirty years of operations practice. There are dashboards. There are runbooks. There are well-understood diagnostic flows.

Agents add three categories that the existing playbook does not cover:

• Confidently wrong outputs. The agent returned a 200. The latency was fine. The output was syntactically valid JSON. The output was substantively wrong — wrong field value, wrong record matched, wrong recommendation made. The user trusted the output because the agent sounded confident. Damage is done by the time anyone notices. No traditional alert fires.
• Cost runaways. A tool the agent calls returns a recursive structure. The agent reasons about the structure, calls the tool again, gets more recursive data, reasons more, calls more. By the time the team notices, the run has consumed forty dollars instead of forty cents and ten thousand tokens has become four million. No HTTP error fires. No latency alert fires. The cost dashboard is the only signal — and the dashboard is usually checked weekly, not real-time.
• Quiet platform drift. Nothing in the team's code changed. The provider silently upgraded a model behind their API. A platform like n8n shipped a minor LangChain-node update. The agent's behavior changed measurably. There was no deploy. There was no commit. There is no obvious thing to roll back. The classical "what changed?" question has no answer at the team level.

These three categories do not map onto the existing on-call playbook. The team that tries to handle them with the existing on-call rotation will fail to handle them. Not because the on-call engineer is incompetent, but because the runbook was written for a system that does not behave the way agents behave.

Agent ops is not a re-skinning of DevOps. It is a distinct operating model that inherits the SRE patterns where they apply (SLOs, error budgets, blameless postmortems) and adds new patterns where SRE has no answer (eval-based regression detection, behavior contracts, model-version-aware change management, prompt-injection incident response). The teams that pretend otherwise are losing the trust war one stakeholder complaint at a time.

The Four Roles

Production agent teams in 2026 converge on four named roles. Sometimes the roles are full-time positions; more often they are hats worn by people whose primary job is something else. The point is not the org chart. The point is that every production agent must have someone accountable for each of these four functions, by name, in a document, with a backup also named.

The Builder

The builder owns implementation. They write the prompt. They wire the tools. They author the eval set. They ship the changes. In a small team, the builder is the person who first prototyped the agent and grew with the system. In a larger team, builder is a job description — usually called Agent Engineer, Applied AI Engineer, or AI Product Engineer in 2026 job postings.

The builder is responsible (R in the RACI) for the day-to-day quality of the system. They write the postmortem when something breaks. They drive the regression eval. They make the calls about whether to swap models. They are the single human who knows the most about how the agent currently behaves.

Anti-pattern: the builder is also the on-call, also the reviewer, also the owner, also governance. One person playing all four roles means no role is being played well. The first hire to make on a production agent team is the second person — not because the work is too much for one person, but because the role separation is.

The Reviewer

The reviewer is a second set of eyes on every change that touches the agent. Prompt change? Reviewer signs off. Tool added? Reviewer signs off. Eval set updated? Reviewer signs off. Model swap? Reviewer signs off. The reviewer is consulted (C) on day-to-day implementation and approves (A) the change-management process.

In small teams, the reviewer is a peer on the same team — the second engineer who knows the system well enough to spot a problematic change. In larger teams, the reviewer role formalizes: a designated AI Engineering Lead, or a member of a centralized Agent Platform team who reviews changes across multiple agent projects.

Two non-obvious responsibilities: the reviewer enforces the eval gate (no merge without a passing smoke eval) and the reviewer is the human who applies the "eval-regression-acknowledged" label when the regression is intentional. The reviewer cannot be the PR author. Self-approval is not a code review.

The Owner

The owner is the business stakeholder accountable (A) for the agent's outcomes. They funded the project. They will be held accountable at the QBR if the agent's metrics slide. They are not technical. They do not write prompts. They do read the weekly score-up ticket, they do approve the cost budget, and they do make the call when the agent has to be paused for business reasons.

In a sales context, the owner is the VP of Sales. In a customer support context, the owner is the VP of Customer Success. In an ops context, the owner is the COO or the Director of Operations. The owner is the human whose career depends on the agent doing what it was funded to do.

The owner role is what most teams forget. They have a builder, they have a reviewer, but they do not have a named business owner who knows the agent is theirs. When the inevitable incident happens, no one is sure who has the authority to make the call about whether to pause the agent or keep it running. The decision drifts. The team waits. The damage compounds.

Governance

Governance is the role that sets the rules the other three operate within. What tools is the agent allowed to call? What data can it touch? What level of autonomy is acceptable for which class of action? What is the audit trail requirement? What is the incident-response SLA? Governance does not write prompts and does not approve daily changes. Governance writes the policy under which prompts are written and changes are approved.

In small organizations, governance is informal — a periodic conversation between legal, security, the builder, and the owner. In organizations with more than a handful of agents in production, governance formalizes: an Agent Governance Council, a member of a Risk and Compliance team with AI in scope, or a fractional CIO who reviews the agent portfolio quarterly.

The 2026 governance landscape is shaped by the EU AI Act risk classifications, the SEC AI disclosure expectations, NIST AI RMF profiles, and the rising body of state-level AI-specific regulations. Governance translates those external requirements into internal rules: what the agent can do, what it must log, what controls must be in place, who must approve what. A governance role that does not have direct authority to pause an agent is not a governance role.

The RACI for a Production Agent

The four roles map onto a Responsible / Accountable / Consulted / Informed matrix. The matrix is not theoretical — it goes in the runbook, it goes in the on-call onboarding, and it is the document that resolves who-decides-what when an incident is in flight at 11pm and three people are typing in the same Slack channel.

Day-to-day implementation activities

Activity	Builder	Reviewer	Owner	Governance
Prompt change	R	A	I	I
Tool addition	R	A	C	C
Tool removal (deprecation)	R	A	C	I
Model swap	R	A	C	C
Eval set evolution	R	A	I	I
Cost budget change	C	C	A	I
New data source integration	R	C	C	A
Audit-trail policy change	C	C	I	A
Pause/kill switch invocation	R	C	A	I
Incident postmortem	R	C	A	I
Stakeholder reporting	R	I	A	I
Quarterly portfolio review	I	I	R	A

How to read the matrix in practice

The RACI is not a bureaucratic instrument. It is a question-resolution table for the most common decisions a production agent team makes weekly. When the builder pushes a prompt change, who signs off? Reviewer. When the agent has to be paused at 9pm on a Tuesday because it just wrote a wrong invoice, who has authority? Owner — and the builder executes. When a new tool is being added that gives the agent access to a new data source, who has the policy say? Governance.

The most contested cell is "model swap." In practice the builder proposes, the reviewer approves the technical decision, the owner is consulted because cost and latency may change, and governance is consulted because the new model may have different data-handling guarantees. A model swap without all four functions weighing in is the model swap that introduces an incident no one anticipated.

The On-Call Rotation

The on-call rotation is the operational backbone. It is the answer to "who responds when something fires?" Without an on-call, the team's alerts go into a void and incidents drag on for hours instead of being acknowledged in minutes.

Who is on call

The on-call rotation is the builder pool, full stop. The reviewer is not on-call (review is not a 24/7 function). The owner is not on-call (they are escalated to, not paged). Governance is not on-call (they set policy, not respond to pages).

Two builders minimum to start a rotation. Below two builders, the rotation is fragile and the on-call burnout is guaranteed. Three builders is the practical floor for sustainable rotation. The 2026 teams that have one builder running a production agent are running on borrowed time.

The escalation chain

The on-call playbook defines a three-tier escalation:

1. Tier 1: On-call builder. Acknowledges within 5 minutes. Drives the first 30 minutes of incident response. Decides whether to pause the agent, roll back the most recent change, or continue investigating. Has the authority to invoke the kill switch unilaterally for safety-critical incidents.
2. Tier 2: Reviewer or senior builder. Paged after 30 minutes if the incident is not resolved or if the on-call is uncertain. Provides architectural context. Often the person who knows the original design decisions that explain why the agent is behaving a particular way.
3. Tier 3: Owner. Paged for incidents with stakeholder visibility, regulatory implications, or strategic decisions about the agent's continued operation. The owner does not debug. The owner authorizes business decisions — pause for a day, communicate to customers, defer the fix to the next quarter.

Governance is informed (not paged) for incidents that have compliance implications: data exfiltration, PII handling violations, audit-trail gaps. Their involvement comes in the postmortem and policy revision, not the live response.

The page criteria

What actually pages the on-call? The 2026 production agent team converges on five page-worthy signals:

1. p95 latency above SLO for 5 consecutive minutes. The 8-second p95 latency SLO breach. Indicates either model-provider degradation or a runaway loop.
2. Cost-per-run two-sigma alert. The cost-per-run distribution has shifted; an individual run cost more than two standard deviations above the baseline. Indicates a runaway loop or a pricing model change at the provider.
3. Error rate above 1% for 5 consecutive minutes. Either the model API is returning errors, a downstream tool is failing, or the agent has gotten stuck in a parse-error loop.
4. Eval regression on production-traffic shadow eval. A continuous eval running on a sample of production traffic has regressed below threshold. Indicates silent drift even if no team code changed.
5. Manual escalation from operator. A human in the operations channel paged the rotation because the agent did something they cannot ignore. The most common page-source in early-stage production.

What does not page: an individual user complaint, a single output the operator disagreed with, a cost overrun for a single run. Those become tickets, not pages. The discipline of distinguishing a page-worthy signal from a ticket-worthy signal is the discipline that keeps the on-call rotation sustainable.

The Slack-and-PagerDuty stack

The mechanical implementation in 2026 is typically PagerDuty (or Opsgenie, Incident.io, FireHydrant, Rootly) wired to dashboards in Datadog, Honeycomb, Grafana, or the eval/observability platform (Langfuse, LangSmith, Arize Phoenix, Helicone, Braintrust). The first responder gets the page, acknowledges, joins a Slack channel pattern like #inc-agent-2026-05-16-001, runs the runbook, and updates the channel as they go.

For incidents that escalate, the channel becomes the source of truth. The owner, the reviewer, and any other named responder join the channel rather than spawning side conversations. The postmortem will reference the channel transcript. Channel discipline saves the postmortem.

Change Management: The Gate

Change management is the discipline that prevents the agent from getting worse on Tuesday because somebody pushed something on Monday. Without a change-management gate, the agent quietly accumulates regressions that no one catches until they compound into an incident.

The four classes of change

Not every change carries equal risk. The change-management policy classifies changes into four tiers:

• Class 1: Routine. Documentation updates, dashboard tweaks, eval-set comment changes. Reviewer-approved via standard PR review. No additional gate.
• Class 2: Quality-affecting. Prompt changes, eval-set additions, tool description edits. Reviewer approval plus passing smoke eval required. Most agent changes fall here.
• Class 3: Behavior-changing. Tool additions, tool removals, model swaps, retry-policy changes, schema modifications. Reviewer approval plus passing full eval required, plus an owner notification at the time of merge.
• Class 4: Governance-relevant. New data source integration, new tool with write authority, audit-trail policy change, autonomy-level escalation. Reviewer approval plus full eval plus governance sign-off plus owner approval. Changes in this class are batched into a weekly or biweekly release, not pushed ad-hoc.

The release calendar

Class 1 and Class 2 changes ship continuously. Class 3 changes ship daily but never on a Friday afternoon. Class 4 changes ship in scheduled windows: a Tuesday 10am release after weekly governance review on Monday.

The Friday-afternoon rule is borrowed from SRE and applies doubly to agents. The cost of an incident over a weekend, with the on-call learning the system under fire, is enormous. The discipline of not shipping behavior-changing changes after 2pm Friday is the discipline that prevents Monday-morning emergencies.

The change log

Every change to a production agent is logged. The log records: timestamp, change author, change class, summary of what changed, prompt version before and after, model version pinned, tool schema version pinned, eval delta. The change log is queryable. When an incident hits, the first question is "what changed in the last 48 hours?" The change log answers it in seconds, not hours.

Teams that skip the change log spend the first hour of every incident reconstructing the change history from Git commits, Slack messages, and people's memory. By the time they have the history, the incident is at hour two and the damage has compounded.

The Incident Response Framework

Incident response is what happens when something has gone wrong and the team has to stabilize, diagnose, mitigate, and recover. Lesson 4 covers the playbook in detail. This section covers the framework that makes the playbook possible.

The four-phase model

1. Detect. The page fires, the operator escalates, the cost dashboard turns red. Detection is a function of the alerting and observability investments made before the incident. Bad detection means the incident is hours or days old before it is acknowledged.
2. Contain. The first action after detection. Stop the bleeding. Pause the agent if needed. Roll back the most recent change. Throttle the request rate. Containment does not have to be the fix — containment has to stop the damage from compounding while the fix is found.
3. Diagnose. Find the cause. Read the traces. Compare prompt versions. Check the change log. Reproduce in staging if possible. Diagnosis is where most of the time in a production incident goes.
4. Recover. Apply the fix. Restore the agent to operation. Verify with a targeted eval run. Communicate to stakeholders. Open the postmortem.

The four-phase model is borrowed directly from SRE. The adaptation for agents is in the containment options (pause, roll back prompt, swap model, disable tool, route to human queue) and in the diagnosis steps (trace replay, prompt diff, eval reproduction, behavior contract review).

The three named incident types

Production agent teams in 2026 see three incident types often enough to write named playbooks for each:

• Hallucinated record write. The agent wrote bad data to a system of record — wrong CRM field, wrong invoice amount, wrong status update. Containment: pause writes, identify affected records, plan rollback or correction. Often the most damaging incident type because the bad data persists after the agent is paused.
• Runaway cost loop. The agent has entered a loop that is consuming tokens or tool calls faster than expected. Cost-per-run is a multiple of baseline. Containment: kill the run, throttle the rate, identify the loop condition. Often caused by a recursive tool response or an ambiguous goal that the agent keeps trying to refine.
• Indirect-prompt-injection exfiltration. A document, email, or piece of retrieved content contained an instruction that the agent followed, exfiltrating data or triggering an action the user did not authorize. Containment: pause the agent for that data source, isolate the malicious content, audit recent runs for similar injections. The most strategically severe because it is a security incident, not a quality incident.

Each incident type has its own decision tree. Lesson 4 walks through the tabletop exercise for each.

Borrowing from SRE Where It Applies

The teams running agent ops well in 2026 are not inventing operations practice from scratch. They are reading Google's SRE Book, internalizing the patterns, and adapting them.

SLOs and error budgets

The SRE concept of Service Level Objectives — measurable promises about reliability — translates directly to agents. The 2026 production agent has four SLOs: latency, accuracy, cost-per-run, and escalation rate. Lesson 2 covers them in detail.

The error budget concept also translates. The error budget is the inverse of the SLO: if the SLO is 99% accuracy, the error budget is 1% of runs allowed to be wrong before alerting fires. When the error budget is exhausted, no new behavior-changing changes ship until the budget is replenished. The discipline is the same as classical SRE; the unit of error is "agent gave a wrong answer" instead of "service returned a 500."

Blameless postmortems

The SRE blameless postmortem is the cultural foundation. The question is not "who screwed up?" The question is "what in our system allowed this to happen, and how do we change the system?" Lesson 5 covers the postmortem template, adapted for agents — adding version-drift and eval-gap as the two new fields that classical SRE templates do not capture.

Toil reduction

SRE's toil concept — repetitive manual work that does not scale with the system — applies doubly to agents. The team that manually reviews every agent output is doing toil. The fix is automated eval, sampling-based human review, and tooling that surfaces only the runs that need attention. Toil reduction is what makes the on-call rotation sustainable.

The on-call documentation discipline

SRE on-call rotations live or die on runbook quality. The 2026 agent on-call inherits the discipline: every alert points to a runbook page. Every runbook page has the diagnostic flow, the containment options, the escalation criteria, and the postmortem entry expectations. The on-call who is paged at 2am does not have to think; they execute the runbook.

What SRE Does Not Cover

Some patterns are net-new for agent ops. They have no SRE equivalent.

Eval-based regression detection

SRE has integration tests, smoke tests, canary deploys. None of those catch a 7% regression in agent tone or a 4% regression in factuality. The eval set is the agent-ops equivalent — and it has no real analog in classical SRE. Building, maintaining, and enforcing the eval is a discipline that has to be invented for each team because there is no decades-deep playbook to inherit.

Behavior contracts

Classical services have API contracts: this endpoint returns this schema. Agents have behavior contracts: this agent will refuse this category of request, will escalate when uncertain, will produce outputs in this tone. Behavior contracts are not a thing in SRE. They are a thing in agent ops. They have to be written down, versioned, and enforced — typically through the eval set and through guardrail-style runtime checks.

Model-version-aware change management

SRE knows how to version software. Versioning a model — particularly when the model is hosted by a third party that may silently upgrade it behind their API — is new territory. The discipline of pinning model versions explicitly, treating version bumps as model changes, and re-evaluating on every bump is an agent-ops innovation that the team has to write into the change-management policy.

Prompt-injection incident response

SRE has security incident response. It has data-exfiltration playbooks. It does not have a playbook for "the agent followed an instruction embedded in a document we retrieved from a trusted vendor." The indirect-prompt-injection vector is novel. The response framework is novel. Lesson 4 walks through it.

Staffing the Function

The number-one question from teams trying to set up agent ops: how many people do we actually need?

The 1-3-5 staffing model

For a single production agent with modest traffic (under 5,000 runs/day, a single use case, a single business owner), the practical minimum is one builder, with a designated reviewer borrowed from another team. The reviewer can be the team lead, a senior engineer in an adjacent function, or a member of a centralized AI platform team if one exists. Owner and governance are part-time roles played by people whose primary job is something else.

For a small portfolio (2-5 production agents, mixed use cases, 10,000-50,000 runs/day combined), the practical minimum is three builders forming an on-call rotation, a dedicated reviewer (could still be team-lead with explicit budget), an owner per agent (not pooled — each agent has a business owner accountable for its outcomes), and a part-time governance role.

For an enterprise portfolio (5+ production agents, regulated industry, 100,000+ runs/day combined), the model converges on five-plus builders across two or three teams, a dedicated AI Platform team with reviewer responsibilities and shared tooling, an Agent Governance Council meeting weekly or biweekly, and named business owners for each agent.

The fractional-CIO and AI-Platform-team patterns

In 2026 two patterns have emerged for organizations that are not yet large enough for a dedicated Chief AI Officer but are running enough agents to need centralization. The fractional-CIO pattern: a contracted senior AI leader who reviews the portfolio quarterly, sets governance, and weighs in on major decisions. The AI-Platform-team pattern: a small (3-6 person) centralized team that owns shared tooling — eval platforms, observability, MCP servers, the guardrails layer — and provides reviewer capacity for builder teams across the company.

Both patterns work. The choice depends on whether the leadership investment is needed (fractional-CIO) or the tooling investment is needed (AI-Platform-team). Most organizations need both eventually.

The First 90 Days of Standing Up Agent Ops

A practical sequencing for teams setting up the operating model for the first time.

Days 1-30: name the roles

Write down who is the builder, who is the reviewer, who is the owner, and who is governance. Get sign-off in a document. Get backup names in the same document. Publish the document to the team. This step is administrative, not technical. Skipping it is the most common reason agent ops never gets established — the roles are never named, so accountability never lands.

Days 31-60: build the on-call rotation

Set up PagerDuty (or equivalent). Define the five page-worthy signals. Wire the alerts. Write the first three runbook pages — one for latency breach, one for cost-per-run breach, one for eval regression. Schedule the first three weeks of on-call. Run a tabletop exercise on the first incident type (hallucinated record write — Lesson 4 covers).

Days 61-90: ship the change-management gate

Define the four classes of change. Wire the eval gate to the CI pipeline. Write the change log. Schedule the first weekly governance review. Run the first real postmortem (probably for a near-miss caught by the new alerting). The 90-day mark is the inflection point where agent ops stops being an aspiration and starts being a function.

Anti-Patterns to Avoid

The one-person agent ops team

One builder owning everything is the most common failure mode. Burnout is guaranteed. The bus factor is one. The role separation is impossible. Even if the second person is part-time and borrowed from another team, the second person must exist.

The unnamed owner

The agent has a builder, a reviewer, and unspecified "business stakeholders." When the incident hits, no one knows who has authority to pause the agent. Decisions drift up to whoever happens to be on Slack at the time. The agent runs longer than it should because no one feels empowered to stop it. Name the owner. Get their commitment in writing.

The pretend-it-is-just-DevOps approach

The team folds agent operations into the existing on-call rotation. The on-call engineer is not trained on agent failure modes. The runbook is generic. The first agent incident is mismanaged because the responder is treating it like a classical service incident. The team eventually rebuilds agent ops as a distinct function — but the rebuild costs more than the original investment would have.

The skip-the-RACI mistake

The team has the four roles named but never writes down the RACI. Every decision becomes a conversation. Every conversation takes longer than it should. The bureaucracy of the missing RACI is worse than the bureaucracy of the explicit RACI.

The governance-as-afterthought trap

Governance is "we will figure it out when we get there." Then the agent is in production, the EU AI Act audit request lands, the security review surfaces a data-handling concern, and there is no policy framework to anchor responses to. Governance has to be present from day one — even if part-time — because retrofitting governance onto a deployed agent is much harder than building it in.

Key Takeaways

• Agents fail in three categories DevOps does not cover: confidently wrong outputs, runaway cost loops, and quiet platform drift. Treating an agent like a classical service guarantees mismanaged incidents.
• Four named roles: builder (responsible for implementation), reviewer (accountable for change quality), owner (business accountability), governance (policy authority). Every production agent has all four, by name, with backups.
• The RACI matrix is the question-resolution table. It goes in the runbook and in on-call onboarding. The most contested cells are model swap (all four consulted) and new data source integration (governance accountable).
• The on-call rotation is the builder pool. Two-builder minimum to start; three-builder floor for sustainability. The escalation chain runs builder → reviewer/senior builder → owner. Governance is informed, not paged.
• Five page-worthy signals: p95 latency breach, cost-per-run two-sigma alert, error rate above 1%, production-traffic eval regression, manual operator escalation. Single user complaints and one-off cost runs are tickets, not pages.
• Change management classifies changes into four tiers. Class 4 (governance-relevant) ships in scheduled windows, never Friday afternoon. The change log is queryable in seconds — incidents start with "what changed?" and the log answers.
• Borrow from SRE: SLOs, error budgets, blameless postmortems, toil reduction, runbook discipline. Invent the new parts: eval-based regression detection, behavior contracts, model-version-aware change management, prompt-injection response.
• Staffing follows 1-3-5: one builder + part-time reviewer for a single agent; three builders + dedicated reviewer + owner-per-agent for a small portfolio; five+ builders + AI Platform team + governance council for enterprise portfolios.
• The first 90 days: name the roles (days 1-30), build the on-call (days 31-60), ship the change-management gate (days 61-90). The 90-day mark is when agent ops becomes a function instead of an aspiration.
• The five anti-patterns: one-person agent ops, unnamed owner, pretend-it-is-just-DevOps, skip-the-RACI, governance-as-afterthought. Each one costs measurably more to retrofit than to build correctly the first time.