A single eval score is a point. You need a slope. The decline you cannot see is the one already underway.
The Thursday cert arc has been building an agent and then learning to watch it. Observability came first: traces and audit trails that show what one run did. Then orchestration: how a supervisor routes work to subagents across a trust boundary. Then grounding and faithfulness: whether a single answer is anchored to its evidence. Each graded one run at a time. Today the arc adds the axis the earlier lessons left implicit: time.
A single evaluation score is a point. A point cannot tell you whether your agent is getting better, holding steady, or quietly rotting. Faithfulness at 0.91 today means nothing on its own. Faithfulness at 0.91 today against 0.96 a month ago is a regression, and it is exactly the kind that ships to production unnoticed, because every individual answer still looks plausible. Nothing errored. The agent just got worse, one imperceptible step at a time, and no per-run check was built to see a slope.
Today names the discipline that sees the slope: agent performance baselining. The eval is a time series, not a gate you pass once. The regression gate fires when the current evaluation window drops materially below the frozen baseline. And the silent-drift trap is the failure mode this lesson exists to close — an agent whose quality erodes so gradually no single answer ever looks wrong enough to catch. AIP-C01 supplies the Bedrock evaluation machinery; GH-600 supplies the Copilot quality-analytics surface; both grade the trend, not the point.
Huyen's AI Engineering (Ch6, pp. 288–290) sets the evaluation quantities this lesson tracks over time: for a retrieval-grounded agent, retrieval quality, faithfulness of the answer to the retrieved context, and citation accuracy. A single run produces one value of each. The foundational move is to stop treating those as pass/fail verdicts on one answer and start treating them as samples from a distribution that has a healthy shape and can drift away from it.
This is the same claim today's Ops lesson makes about block intervals, and the parallel is exact. A mean faithfulness score hides the same thing a mean block time hides: the tail. An agent whose median faithfulness holds at 0.95 while its tenth-percentile answers slide from 0.80 to 0.60 has developed a population of quietly bad answers the average will never show you. Huyen's evaluation-methodology treatment (Ch4, pp. 193–194) supplies the catch: hold a fixed evaluation set, run it on a schedule, and compare distributions across runs. The set must be frozen, because a moving eval set cannot distinguish a change in the agent from a change in the questions.
On AWS the machinery is Amazon Bedrock's agent and model evaluation capability plus the knowledge-base retrieval metrics from the 07-02 lesson, run on a schedule and stored so runs can be compared. The frozen evaluation set is a curated collection of representative prompts with reference answers or graded rubrics. Bedrock's evaluation jobs score a target agent configuration against that set and emit per-metric results: retrieval relevance, answer correctness, faithfulness, citation coverage.
The baselining move is to run that job on every meaningful change and on a fixed cadence, persisting results keyed by run timestamp and configuration version. A CloudWatch metric emitted from each evaluation job turns the score into a first-class time series, so the same alarm machinery that watches latency can watch faithfulness. The regression gate becomes a CloudWatch alarm on the evaluation metric: when the rolling average drops below the baseline by more than a set margin, or the threshold is breached for a sustained number of periods, the alarm fires into the same SNS-and-remediation path the 07-07 detect-decide-act lesson built.
What makes this an AIP-C01 competency rather than generic monitoring is causal attribution. When the gate fires, the candidate causes are specific to the agentic stack: the foundation model auto-upgraded, the knowledge base was re-indexed with a different chunking strategy, the retrieval top-k or hybrid-search weighting changed, or the agent's instruction prompt was edited. Bedrock's model-version pinning and knowledge-base data-source versioning exist precisely so a regression can be tied to the change that caused it. Faithfulness dropping the week the model auto-upgraded is a different problem from retrieval relevance dropping the week the knowledge base grew past its chunk-size sweet spot, and the evaluation time series plus version metadata is what separates them.
GH-600 approaches the same discipline from the developer-productivity surface. Copilot's value is measured by real usage signals: suggestion acceptance rate, the rate at which accepted suggestions survive in the codebase versus getting reverted, and the outcomes of agentic Copilot workflows such as PR tasks that succeed versus need rework. Each is a longitudinal quality signal, and each can drift.
The Copilot quality-drift signal reads those metrics as a time series per repository or per team. A falling acceptance rate is the analog of falling faithfulness. But acceptance rate has the silent-drift trap built in, because it can be gamed by developers who accept then immediately edit. The sharper signal is the survival rate — whether accepted suggestions persist unchanged — which is closer to true quality and harder to fake. For agentic GH-600 workflows the analogous metric is task-completion quality over time: are Copilot's autonomous tasks producing PRs that merge cleanly, or trending toward more review rounds and more human correction.
The GH-600 competency is knowing which drift is the model's fault and which is the context's. When a repository's custom instructions grow stale, or its content-exclusion rules cut off the files Copilot needs, suggestion quality drifts down for reasons that live in the configuration rather than the model. The quality-drift signal has to be read alongside the configuration history, exactly as Bedrock's evaluation series has to be read alongside model and knowledge-base versions. In both vendors the regression is only actionable once attributed, and attribution requires the change history be as carefully versioned as the metric is carefully measured.
A financial-research agent runs on Bedrock with a 50,000-document knowledge base, serving analyst queries. Its frozen evaluation set is 400 representative questions with graded reference answers. For two months the weekly evaluation holds: faithfulness median 0.95, tenth percentile 0.82, citation coverage 0.97. That is the baseline, persisted per run, emitted to CloudWatch.
In week nine the faithfulness median still reads 0.94, comfortably healthy on the dashboard. The regression gate fires anyway, because it watches the tenth percentile, which has slid to 0.66. A concentrated population of answers has gone bad while the median stayed put. The alarm carries the metadata: the knowledge base was re-indexed three days earlier with a larger chunk size to cut storage cost. The larger chunks diluted retrieval precision on exactly the narrow, fact-specific questions that make up the bad tail. Median-strong, tail-weak, attributable to a specific change. The team reverts, the tenth percentile recovers to 0.81 by the next evaluation, and no analyst ever had to notice a slice of their answers had quietly degraded.
Run the GH-600 half in parallel. The same organization's Copilot acceptance rate held at 0.34 across the quarter, unremarkable. But the survival rate of accepted suggestions in one repository fell from 0.71 to 0.52 over three weeks. The quality-drift signal fired on survival, not acceptance, because acceptance hid the problem. Attribution pointed at a content-exclusion rule added to that repository that cut Copilot off from the shared types module, so its suggestions compiled but did not match the codebase's conventions and got rewritten in review. Same discipline, different vendor: the point-in-time metric looked fine, the trend in the sharper metric did not, and the fix lived in configuration once the regression was attributed.
The trio is one idea in three domains. The Chain Ops lesson baselines block-interval and vote-latency distributions and fires a pre-halt degradation signal on a sustained tail-shift. This cert lesson baselines agent-evaluation distributions and fires a regression gate on a sustained tail-shift. The two signals are the same construct pointed at different telemetry: freeze the healthy distribution, watch the rolling window, alert on the tail rather than the mean, attribute the shift to a specific change before acting. The Dev lesson supplies the machine underneath both, and its explore-in-R-enforce-in-Python split is exactly how you would build the Bedrock evaluation pipeline: explore the score distribution in R to find the tail moved, enforce the frozen-baseline comparison in Python as the scheduled job that emits the gate. The silent-drift trap is what all three exist to close.
An agent that is only graded one answer at a time is an agent whose slow decline you have agreed not to see. The individual answers stay plausible; the population rots underneath them. Freeze an evaluation set, run it on a cadence, keep the score distribution rather than its average, and watch the tail. On Bedrock that is a scheduled evaluation job emitting a CloudWatch metric with a regression alarm and version metadata attached. On Copilot it is the survival-rate and task-quality time series read against configuration history. Both are the same discipline the chain lesson applies to block timing: baseline the normal, watch the trend, alert on the tail, attribute before you act.
Ask of your own agent: do you know its faithfulness last month, or only today. If only today, you have a point where you need a slope, and the decline you cannot see is the one already underway.