Build an AI Agent, Stage 15: Monitoring That Demotes the Agent, Proven by Seeded Drift
Monitoring is finished when every way the agent can drift has a signal that catches it in time and an action that takes effect without a meeting. Tie each signal to a demotion the gateway enforces, page a person to decide what comes next, and prove the whole set by seeding the drift into a replay before trusting any of it.
The example in this series is a composite scenario, built from patterns common to requirements intake in regulated organisations. It is not a single real organisation, and its figures are illustrative: the replay in this stage is composite, not measured. The code is real: every output block below was produced by running it.
The Requirements Agent had monitoring from the first day of its pilot. A page if cost per request rose 20% above the last five days. A page if more than 15% of requests were handed over in a day. A daily check that the model alias in the agent's configuration matched the release. And the blueprint's own detection for invented scope: a weekly sample of twenty question drafts, judged by an analyst.
None of it caught the problem that mattered. When question skill 2.3 started producing leading questions in September, the story Stage 12 told, it was the analysts who noticed, two weeks later, because they were editing more questions than before. No alert fired. And if one had, it would have paged someone, and the agent would have gone on drafting leading questions while people decided what to do.
What Is AI Agent Management? puts the missing half plainly: "Autonomy should also go down." An agent whose inputs change, or whose evidence stops holding, should drop a level until the evidence is rebuilt. The pilot's monitoring could tell people something was wrong. It could not move the agent down.
This is Stage 15, the last stage of Build an AI Agent From Scratch. Stage 14 released the agent with a rollback that had been rehearsed. This stage keeps it honest once it is live: drift signals, the demotions they trigger, and the seeded drift that proves both work.
Why a dashboard full of green isn't monitoring
The pilot's signals were the ones that were easy to compute, and each had a blind spot. A weekly sample of twenty can only report multiples of 5%: it sees a slow rise in leading questions when the true rate is well past the bar, and only on the day the sample is taken. A check of the model alias can't see a provider move that alias to a new snapshot, because the alias doesn't change. And nothing at all measured how long analysts took to approve a draft, though the agent management anchor names approval time as the sign of whether review is real: when approvals take seconds, Level 2 is already working as Level 3.
The deeper gap was the response. Every signal was a page. The Google SRE book's rule for pages is that "Every page should be actionable", and it adds: "If a page merely merits a robotic response, it shouldn't be a page" (Beyer et al., 2016). When the agent's output quality falls, the first response is the same every time: stop the action that is going wrong. That response is robotic, so it should be automatic. What needs a person is the next decision: why it drifted, and what evidence would justify restoring it.
The test: for each alert your agent has, write down what someone does in the first ten minutes after it fires. If the answer is the same every time, that step should happen without them, and the page should ask for the decision that follows.
Four drifts, four signals, four demotions
The discovery move is to go through the blueprint's failure modes and the autonomy ladder's reasons to go down, and ask two questions of each: what would we see first, and what should the agent stop doing when we see it? For the Requirements Agent, that produced four drifts, each written as data in requirements-agent.monitoring.v2.json:
Drift | Signal | Detect within | Demotion | Owner paged |
Inputs change | Share of requests from a template the golden set has never seen, above 10% in a day | 2 days | Those requests drop to Level 0: handed over until the golden set covers the template | Senior BA on duty |
Question quality falls | Leading-question rate on every draft, judged by the calibrated judge, 3-day mean above 8% | 7 days | Question drafts drop to Level 2 → 1: shown as suggestions, not saved | BA practice lead |
Review stops being real | Median approval time on question drafts under 30 seconds, 2 days running | 3 days | Question drafts drop to Level 2 → 1 until review is real again | BA practice lead |
Model changes | Resolved model snapshot differs from the one the release pinned | Same day | Every draft action drops to Level 1 until the suite and evaluation pass on the new snapshot | Agent team |
Each demotion is per action, not per agent, in the way Where Human Approval Belongs sets autonomy per action: a drift in question quality withdraws the question draft and leaves relation proposals and hand-overs alone. And each is enforced where the agent can't argue with it. The gateway withdraws the scope, triage.draft.create for question drafts, so a demoted action is refused whatever the model decides, and Stage 13's run record shows the refusals as refusals.
The quality signal is affordable because Stage 12 built a calibrated judge. Judging every draft daily costs minutes; the weekly sample of twenty it replaces cost an analyst's afternoon and saw less. The model signal needed one change to the release manifest. Stage 14 pinned the model by its alias; the release now pins the snapshot, and the run record carries the snapshot the provider reports for each call.
NIST's AI Risk Management Framework asks for exactly this pairing: that "the functionality and behavior of the AI system and its components" are "monitored when in production" (MEASURE 2.4), and that post-deployment monitoring plans include "appeal and override, decommissioning, incident response, recovery, and change management" (MANAGE 4.1) (NIST, 2023). A demotion is an override that the monitoring performs itself.
The test: for each failure mode in your agent's blueprint, name the signal that would show it first and the action that stops when it fires. A failure mode with no signal is one you will hear about from the people affected.
Seeding the drift
A monitoring spec is a claim until something drifts. Waiting for a real drift to test it is how September happened. So the checker for this stage, monitor_check.py, replays 20 working days of the agent's daily aggregates: once as a clean baseline, which must raise no alarm at all, and then once for each of four seeded drifts, each on its own, starting on a known day. A seed passes only if a signal fires within its deadline and at least one signal that fired by then demotes the agent. A page alone doesn't pass.
The pilot's monitoring first:
$ python monitor_check.py v1
monitoring spec pilot: 4 signals, 0 with a demotion
baseline, 20 days: 0 alarms PASS
input day 6, deadline 2d: detected day 6 (lag 0) by cost per request; hand-over rate; page only, no demotion FAIL
quality day 9, deadline 7d: detected day 20 (lag 11) by leading questions, weekly sample of 20; page only, no demotion FAIL
rubber_stamp day 13, deadline 3d: not detected in the replay FAIL
(median approval time on question drafts falls to 12 s)
model day 16, deadline 1d: not detected in the replay FAIL
(provider moves the model alias to a new snapshot)
seeded drift: 1/4 caught within deadline, 0/4 demoted; baseline false alarms: 0: FAIL
The pilot caught one drift in time, and that one by accident. The new broker template made requests longer and pushed scope into attachments the agent couldn't read, so cost and hand-overs both jumped on the first day. But both were pages, so the agent kept drafting questions on the new-template requests it could read. The slow rise in leading questions, one point a day, was seen by the weekly sample eleven days after it began. The fall in approval time and the model change were not seen at all.
The rebuilt spec on the same replay:
$ python monitor_check.py v2
monitoring spec 2.0: 6 signals, 4 with a demotion
baseline, 20 days: 0 alarms PASS
input day 6, deadline 2d: detected day 6 (lag 0) by cost per request; hand-over rate; inputs from unknown templates; demote requests from unknown templates: Level 2 -> 0, senior BA on duty paged PASS
quality day 9, deadline 7d: detected day 14 (lag 5) by leading questions, every draft, 3-day mean; demote save_question_draft: Level 2 -> 1, BA practice lead paged PASS
rubber_stamp day 13, deadline 3d: detected day 14 (lag 1) by median approval time, 2 days running; demote save_question_draft: Level 2 -> 1, BA practice lead paged PASS
model day 16, deadline 1d: detected day 16 (lag 0) by resolved model snapshot; demote every draft action: Level 2 -> 1, agent team paged PASS
seeded drift: 4/4 caught within deadline, 4/4 demoted; baseline false alarms: 0: PASS
restore: back to Level 2 only by a person, after the Stage 11 suite says RELEASE and the Stage 12 verdict is PROMOTE on a golden set that includes the drifted inputs, and 5 working days at the lower level
(Both from stage15-output.txt. The replay is composite and illustrative; every detection day and lag is computed by the script.)
All four seeds are caught within their deadlines, each with a demotion, and the clean baseline raises no alarm. The baseline line is the other half of the test. A threshold tight enough to catch everything early also fires on ordinary days, and a signal that fires on ordinary days gets muted. A test in the suite sets the leading-question threshold inside the baseline's normal range and confirms it fails on false alarms.
The test: pick the drift you most fear, seed it into a replay of last month's traffic on a known day, and run your monitoring over it. Measure the lag, check that something stopped, and run the clean replay too, to count the false alarms.
Coming back up is a person's decision
Demotion is automatic; restoring the level is not. The spec's rule is that an action goes back to Level 2 only when a person decides it should, after the Stage 11 suite says RELEASE and the Stage 12 verdict is PROMOTE on a golden set that now includes the drifted inputs, and after five working days at the lower level. That last condition gives the lower level time to show what the drift cost: how many requests were handed over, how many suggested questions the analysts used.
Restoring needs fresh evidence because the old evidence is what failed. A golden set built before the new broker template can't say whether the agent handles it. A judge calibrated before a model change can't be trusted after one; Stage 12 said calibration expires, and a model change is one of the ways it does. A demotion that ends when the alert clears would restore the agent on the same evidence that just stopped holding.
The test: for each demotion your monitoring can trigger, write down what evidence would justify restoring the level and who decides. If the answer is "when the alert clears", the agent will climb back on the evidence that just failed.
Keeping it honest: a method
List the drifts. Every failure mode in the blueprint, plus the ladder's reasons to go down: changed inputs, falling quality, review that isn't real, a changed model. Done when each drift has a signal that would show it first.
Give each signal a deadline and a demotion. Done when every signal names how soon it must fire, the action it demotes and to which level, and the owner it pages.
Enforce demotions at the gateway. Done when a demoted action is refused at the tool layer, and the run record shows it as refused.
Seed the drift. Done when a replay with each drift seeded on its own catches every seed within its deadline with a demotion, and the clean replay raises no alarm.
Write the way back up. Done when restoring each level needs a named person and fresh evidence, never the alert clearing.
Tradeoffs and exceptions
Approach | Gains | Costs | Best suited for | Warning signs |
Pages only | Simple; a person always decides | The agent keeps acting while people talk | Read-only agents | An alert whose first response is always the same |
Sampled human review | Real judgement | Coarse and slow on gradual drift | Calibrating the judge; spot checks | Detecting trends from 20 items a week |
Every output judged, demotion on threshold | Fast; consistent; scales | A calibrated judge to keep calibrated | Agents with a high volume of drafts | A judge nobody has re-calibrated since release |
Seeded drift in a replay | Proves detection and response before you need them | Building the replay and the seeds | Any agent with autonomy above Level 1 | A spec nobody has ever seen fire |
Some drifts can't be seeded in advance, because nobody imagined them. Seed what the blueprint's failure modes and the ladder name, and add a seed after every incident, so the drift that surprised you once is in the replay the next time the spec changes. Thresholds are a trade: each one sits between the lag the deadline allows and the false alarms the baseline shows, and the replay is where that trade is made, with both numbers in front of you.
How Stage 15 goes wrong
Every alert is a page. The agent keeps acting while people decide. Make the robotic first response automatic, and page for the decision that follows.
The signal can't see the drift. A model alias hides a new snapshot; a weekly sample of twenty hides a slow rise. Measure what actually changes, on every output you can afford to.
Nobody measures the reviewers. Approvals in seconds mean Level 2 is working as Level 3. Monitor approval time, and treat a rubber stamp as a drift.
The spec is trusted without ever firing. Seed every drift you name into a replay, and keep the clean replay to count false alarms.
What to do next
Pick the one drift you most fear for your agent, seed it into a replay of last month's traffic, and run your monitoring over it. If nothing fires, or something fires and nothing stops, you have found your next piece of work. For the mechanics of watching a prompt over time, Monitor for Prompt Drift and Continuous Evaluation in Production go deeper.
That is the last stage. Fifteen stages built one agent, from a six-field problem definition to a monitoring spec that demotes it on its own, and every stage closed with a test that runs: the series suite now has 109, and all pass.
Final takeaway
Monitoring is finished when every drift you can name has a signal that catches it in time and a demotion the gateway enforces, and when seeded drift has proved both. Make the first response automatic, page a person for the decision after it, and let the agent climb back only on fresh evidence. The series ends where it began: no stage is finished until it names its test and the test passes.
Sources
National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023. MEASURE 2.4 (functionality and behaviour monitored in production) and MANAGE 4.1 (post-deployment monitoring plans, including appeal and override, decommissioning, incident response, recovery and change management).
Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy (eds.), Site Reliability Engineering, Chapter 6: Monitoring Distributed Systems, O'Reilly, 2016. "Every page should be actionable"; "If a page merely merits a robotic response, it shouldn't be a page."
Series navigation. Previous: Stage 14: Rehearse the Rollback Before the Canary Starts. This is the last stage; the full stage list is on the Build an AI Agent From Scratch hub.
Frequently Asked Questions
How do you monitor an AI agent in production?
Give each way the agent can drift a signal, a threshold and a deadline for detecting it: changed inputs, falling output quality, reviewers who stop really reviewing, and a model that changes underneath you. Tie each signal to an action, and prove the whole set by replaying traffic with the drift seeded in.
What is seeded drift?
A replay of real or representative traffic with a known change injected on a known day, such as a new input format or a slowly rising error rate. Because you know when the drift started, you can measure whether your monitoring caught it, how late, and whether it did what it should.
When should an AI agent be demoted to a lower autonomy level?
When the evidence that justified its level stops holding: its inputs change, the quality of its output falls, the people approving its work stop reviewing it properly, or the model it runs on changes. The demotion should be automatic and enforced at the tool gateway, and going back up should be a person's decision based on rebuilt evidence.
Part of the Agent Engineering curriculum: eight paths from prompts and context to testing, evaluation and governance.
