Who writes the evals, who carries the pager

Lesson 4 of 5 in AgentOps Org Patterns: Maturity, Team Shapes, and Gates That Scale.

Four questions expose whether an agent has an owner. Ask them out loud, in a room, and write down the names:

Who writes and maintains the golden set?
Who approves a change to the system prompt?
Who approves a new tool and its scope?
Who gets paged when the agent is wrong?

If the answer to all four is “the AI team,” the agent has no owner — it has a hobby. And the fourth question is the one that decides the others, because the person holding the pager is the only one with a durable incentive to keep the other three honest.

Whose statement is it? Moffatt v. Air Canada, February 2024

British Columbia’s Civil Resolution Tribunal held Air Canada liable for its website chatbot’s incorrect advice about retroactive bereavement fares. Tribunal member Christopher Rivers called the airline’s defence — that the chatbot was “a separate legal entity that is responsible for its own actions” — a “remarkable submission,” ruling: “It makes no difference whether the information comes from a static page or a chatbot.” Air Canada was ordered to pay Jake Moffatt $812.

Pre-agentic, small money, and the most useful org-design precedent available: the organisation owns what its AI says and does. Ownership is not a question you get to leave unanswered, so it is better answered on an org chart than in a tribunal. Source: CBC News, 2024-02-15, reporting Moffatt v. Air Canada, 2024 BCCRT 149.

Ownership that works, ownership that fails
Artifact or duty	Owner that works	Owner that fails	Why
Golden set content	The domain expert who can say “this answer is wrong, and here is why” — the support lead, the underwriter, the senior engineer — with platform providing the runner.	A platform or ML engineer authoring cases alone.	Eval content encodes judgment, not infrastructure. Generic cases pass while real customers fail.
System prompt changes	The product team that owns the agent’s job description, reviewed like code, with the diff in version control.	“Whoever is closest to the incident,” editing production live.	Untracked prompt drift makes regressions unattributable — you lose the ability to say what changed.
Tool and MCP scope	Platform and security own the gate; the requesting team owns the justification and the narrowest workable scope.	Individual developers adding servers per project.	Unreviewed additions run with the agent’s privileges and are invisible to the inventory during an incident.
The autonomy dial per action	The product owner who accepts the blast radius, with a security veto.	The engineer who is tired of clicking approve.	Autonomy drift happens by convenience unless someone with the consequences signs for each raise.
Kill switch operation	Whoever is on call, with standing authority to flip it and no obligation to ask first.	A director whose approval is required.	Containment competes with the clock. Any approval step converts the switch into a decoration.
The pager	The product team for behaviour; platform for runtime. Two rotations, explicit split, documented escalation between them.	One shared rotation, usually the platform team, for everything.	Platform on-call cannot judge whether an output was wrong, and the product team never learns its own failure modes.
Cost per successful task	A named budget owner with veto over model and routing changes.	“Finance will notice.”	Agent cost is discovered at invoice time and attributed to nothing without per-agent tagging and an owner.
Postmortem follow-through	The incident owner, tracking whether the eval case, guardrail, or scope change actually merged.	The document itself, filed and closed.	Without verified follow-through the same incident recurs — and the flywheel that defines the optimized tier never spins.

The pager is two pagers

Agent incidents split cleanly into two kinds, and they need different humans.

“The runtime is broken” — the worker queue has stalled, the provider is returning errors, the cost guardrail tripped, checkpoints are not resuming. Platform on-call, with the usual SRE playbook.

“The agent is confidently doing the wrong thing” — success rate fell, escalations stopped happening, an action was wrong. Only the product team can judge that, because judging it requires knowing what right looks like for the task.

Get this split wrong in the popular direction — one rotation, platform carries it — and the platform engineer paged at 2am about a refund agent has no basis to decide whether the refund was correct. They will do the only thing available: page someone else, slowly. Write the split into the runbook, along with which signals belong to which rotation and how each escalates to the other.

The skills, honestly — five duties, mostly for people you already have

These are duties added to existing roles, not five new job postings. Teams that create a standalone “AI unit” to hold them usually end up with a group that owns no production system and therefore no consequences.

Eval author / trace reader. Can read a trace and say where the run went wrong, and turn that into a permanent case. Usually a senior engineer or the domain expert, not a data scientist.
Prompt and context engineer. Owns the job description and the context budget. Often a PM–engineer pair; the PM supplies escalation rules, the engineer supplies the retrieval and token discipline.
Agent SRE. Owns timeouts, retries, idempotency, breakers, and the kill switch. This is your existing SRE plus one new intuition: the agent can be up and wrong.
Tool and supply-chain reviewer. Owns the registry and the scope conversation. Security, part-time, with a checklist rather than an opinion.
Cost engineer. Owns cost per successful task. Usually the same person who owns the latency budget, because the trade-offs are the same trade-offs.

The one genuinely new skill: reading a trace like a witness statement

Everything above maps onto existing craft except this. Debugging an agent means reconstructing what the model saw at each step — which retrieved chunk, which tool output, which truncated history — and asking whether the decision was reasonable given that view. It is closer to reading a witness statement than to reading a stack trace: the run may never repeat, so the recorded evidence is all you get.

Teams that build this skill fix root causes (the retrieval returned the wrong document; the tool description was ambiguous). Teams that do not fix symptoms by adding sentences to the prompt, which is how prompts reach 4,000 tokens of accumulated superstition.

Should you hire an “AI engineer”?

Sometimes — for the platform, where the work is genuinely specialised: runtime, guardrail implementations, eval harnesses, gateway and cost attribution. Rarely for the product teams, where the scarce input is domain judgment about what a correct outcome looks like, and that is already sitting in your org.

The failure to avoid: an AI team that owns all the agents. It becomes a bottleneck, it never learns any domain deeply enough to write a good golden set, and it inherits a pager for behaviour it cannot evaluate.

Interactive sorting exercise: Nine signals arrive at 02:00. Route each to the rotation that can actually act on it — or decide it is not a page at all.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.