1. Why classic drift monitoring doesn't transfer to agents
Traditional monitoring assumptions do not transfer cleanly to agents. Classic ML drift monitoring was built around a function that takes a feature vector and returns a label or score. Feature and label drift compare static distributions. An agent instead chooses tools and changes course over a trajectory, so monitoring needs to observe the policy over actions as well as input and output distributions.
An agent is not that function. A fraud-triage agent, a credit-memo drafting agent, a client-servicing agent that fields a request and decides how to satisfy it, all of these take a request and then execute a sequence of decisions: which tool to call, which skill to invoke, which sub-agent to delegate to, in what order, with what parameters, and when to stop.
The input-output pair that classic drift monitoring wants to compare is only the visible tip of a trajectory that might involve six, ten, or twenty intermediate actions. Two agents can produce the identical final answer to the identical request while taking completely different paths to get there, and two agents can take the identical path while landing on different final answers because a downstream tool returned different data. The static single-hop comparison simply has nowhere to attach itself.
This is not a semantic quibble. It has direct consequences for what you can detect and when. A feature-drift monitor on the fraud-triage agent's inputs would tell you if the mix of incoming case types shifted, more mule-account referrals, fewer card-present disputes, and that is worth watching. But it tells you nothing about whether the agent itself started behaving differently in response to those cases. The agent's behaviour lives in the sequence of tool calls it makes: querying the sanctions list, pulling device telemetry, calling the case-history skill, escalating to a human reviewer, closing the case as false positive. None of that sequence is a feature of the input in the traditional sense. It is a policy, and the policy is what drifts.
Three useful engineering patterns follow from this distinction: calibrated cascade routing to choose a permitted model tier, a private skill-model foundry to keep narrow capabilities current, and trajectory assurance based on observable tool, evidence and policy events. Each treats the trajectory, not only the answer, as the unit of behaviour. Drift monitoring has to operate on the same unit.
The practical implication is that you cannot bolt a feature-drift dashboard from your classic fraud model onto your new fraud-triage agent and call the monitoring problem solved. You need a monitoring layer that treats the sequence of tool invocations as the primary signal, with the final output as a secondary, lagging confirmation. That reframing is the subject of the rest of this piece.
Disclosure. Every institution, engagement, incident, baseline, case count, rate, threshold, duration, cost and outcome in this article is illustrative or modelled unless a public source is linked. The worked fraud narrative is a synthetic control scenario, not client history. Local owners must estimate lags, losses, sample sizes and alert performance from their own systems.
2. Why output accuracy lags the underlying shift
Incident retrospectives can misplace the start of a failure. A chart may show resolution accuracy, false-positive rate or customer satisfaction dipping on one date even though the causal change occurred earlier. The metric catches up only after cases complete, labels arrive and normal variation clears. The size of that lag is an empirical property of the local feedback process, not a universal interval.
Consider the mechanics. An output accuracy metric, whether it is a human-labelled quality score, a downstream conversion rate, or an automated correctness check against a reference answer, requires cases to complete, requires ground truth to become available, and often requires enough volume to clear ordinary variance. In fraud triage, confirmation may depend on a customer dispute, a card-network outcome or investigator adjudication. That loop can take weeks. If behaviour shifts on day one, the accuracy metric may not show a credible deviation until much later.
During that entire window the agent has been executing a different policy than the one that was validated. It has been calling a different tool more often, skipping a verification step it used to take, or leaning on a fallback skill that was never meant to carry that much volume. None of that shows up in the final answer distribution early, because plenty of wrong-process trajectories still land on the right answer by coincidence or because the error is small enough to sit inside the tolerance of a downstream human reviewer who quietly corrects it before it is ever logged as a miss. The output metric is measuring the composition of many hidden steps, and composition is a lossy operation.
Twenty per cent of a trajectory going wrong does not reliably turn into twenty per cent of outputs going wrong; it might turn into two per cent, or it might turn into thirty five per cent depending on how the downstream steps interact, which makes the accuracy signal both delayed and unreliable as an early warning.
There is a second, more subtle reason output metrics lag: they are aggregated across intent categories that behave differently. A shift concentrated in, say, mule-account fraud cases, which might be twelve per cent of total volume, gets diluted inside an aggregate accuracy figure computed across all case types. The blended metric can sit inside its normal band for weeks while the affected sub-population is already badly out of control, because the healthy eighty-eight per cent of volume is masking the sick twelve per cent. Any monitoring strategy that only watches the aggregate is structurally blind to exactly the kind of concentrated drift that causes the worst incidents, because concentrated drift is disproportionately likely to be systemic rather than random, and systemic issues compound.
The fix is not to demand faster ground truth, which is usually impossible, nor to over-aggregate less, which only pushes the noise problem back a step. The fix is to stop treating the final output as the primary signal and instead treat the intermediate decisions, which are available immediately, with no confirmation lag whatsoever, as the primary signal. That is what tool-selection distributions give you.
3. Tool selection distributions as a leading indicator
Every invocation records which tools were called, in what order and how often for a given intent. Aggregate that record and two related objects appear. The first is a vector of per-trajectory call propensities: transaction lookup in 98% of cases, device fingerprinting in 74%, sanctions checking in 12% and human escalation in 6%. Those percentages need not sum to 100 because one trajectory can call several tools. The second is a true categorical distribution over normalised call events or ordered transitions. Keep the two representations separate in the statistics.
The statistical machinery for comparing categorical distributions is well understood. Population stability index computes a weighted log-ratio across bins. The familiar 0.10 and 0.25 boundaries are conventions inherited from other monitoring contexts, not universal significance levels. Apply PSI to mutually exclusive, normalised call-event or transition bins. For the multi-label propensity vector, compare each tool's called-versus-not-called counts and control the family of tests.
Kullback-Leibler divergence supplies a directional comparison of normalised distributions, but zero-probability bins require a documented smoothing rule. Chi-squared testing uses raw contingency counts and needs adequate expected cell counts; sparse tools may require category pooling or an exact method. A p-value measures compatibility with a null model. It does not measure consequence or operational materiality.
The measures answer different questions. PSI offers a conventional effect-size view; KL highlights directional divergence; a count test helps quantify sampling uncertainty. Running all three does not create independent confirmation because they use the same events. The alert policy should predeclare its primary statistic, materiality floor, sparse-bin treatment and multiple-comparison correction. Agreement can support diagnosis, but it is not three separate pieces of evidence.
The key design decision is the unit of analysis: you do not compute one tool-selection distribution for the whole agent. You compute one per intent category, because intent categories have structurally different tool profiles, and blending them destroys exactly the signal you are trying to preserve, for the same reason that blended accuracy metrics mask concentrated failures. A fraud-triage agent handling twelve intent categories needs twelve separate distributions, each compared against its own rolling baseline, each with its own PSI, KL, and chi-squared statistic computed independently.
This is more instrumentation work than a single dashboard tile, but it is the only way the leading-indicator property actually holds, because drift that concentrates in one intent category at eleven per cent of volume will wash out to near-zero in a blended distribution across ninety per cent healthy traffic.
Tool-selection distributions can be leading rather than merely different because they sit closer to the causal change. A schema, skill, instruction or routing change can alter observable actions before delayed outcomes are labelled. That creates a testable hypothesis: for a defined failure family, the tool-event sentinel should cross its predeclared boundary before the corresponding outcome metric. Historical replay must measure the actual lead time and also record cases where the hypothesis does not hold.
4. Designing a behavioural sentinel
A behavioural sentinel is the piece of infrastructure that turns the idea in section three into something that pages an engineer at three in the morning, which means the design choices that seem academic on paper, sampling window, baseline refresh cadence, threshold calibration, are the choices that determine whether the sentinel is trusted or muted within its first month of operation.
Start with trajectory capture. Each invocation should log, at minimum, the assigned intent, ordered tool and skill events, evidence references, policy decisions, structured self-check results, outcome state and timestamp. An optional concise rationale may connect an action to exposed evidence, but the monitor neither needs nor should request private chain-of-thought. This event schema is lighter than retaining full content and can support broad coverage, subject to privacy, cost and volume constraints.
Sampling window is consequential. Too short, and daily or weekly seasonality creates noise; too long, and drift compounds before detection. The composite compares a rolling seven-day current window with an approved, non-overlapping thirty-day reference for intents above 500 trajectories a day. It recomputes the comparison daily but does not silently move the reference. Lower-volume categories use a fourteen-day current window or pooled bins, subject to a minimum-count rule.
Threshold calibration follows the PSI convention described above, but local variance still matters. The illustrative operating design uses a 60-to-90-day silent burn-in, then models two tiers: PSI 0.15 for a low-priority ticket and PSI 0.25 combined with a chi-squared p-value below 0.01 for an urgent page. These are candidate parameters for backtesting and consequence review, not observed deployment performance.
The two-statistic gate on the high-priority tier matters: PSI alone above 0.25 on a low-volume tool bin can be an artefact of small-sample noise, but PSI above 0.25 confirmed by a chi-squared test that accounts for sample size is a much harder signal to argue away.
The pipeline itself is straightforward to describe and worth drawing rather than narrating, because the value of a sentinel is largely in how unglamorous and repeatable each stage is.
The sentinel belongs beside, not instead of, output metrics. Placing tool-selection PSI next to accuracy and latency lets an operator compare leading and lagging signals. High-priority alerts should route to the relevant on-call rotation with a runbook attached, because an alert without a runbook is unlikely to produce a consistent response.
One design point is easy to skip: the baseline needs a deliberate refresh policy. If it silently rolls forward every day, slow drift can pull the baseline along with it, a form of baseline chasing. The illustrative design reviews a monthly baseline candidate only after an authorised owner confirms the period is suitable. A real cadence should follow demand seasonality, release frequency and the evidence needed to establish a known-good state.
5. From alert to remediation: the triage flow
An alert on its own resolves nothing. It needs a triage process that distinguishes material drift from noise and directs the responder to a bounded remediation path. A sound operating hypothesis is that response discipline matters as much as detection quality: a sentinel that starts vague, undocumented investigations will lose trust even if its mathematics are sound. Alert acceptance, time to diagnosis and closure quality should test that hypothesis locally.
The reference triage starts with root-cause classification. Three useful hypotheses are an upstream contract change, a component release and a genuine shift in demand. Under the first, a renamed or deprecated field changes an observable routing condition or produces malformed tool responses. The call pattern then shifts even though the task mix is stable. Diagnosis uses schema versions, tool errors, route events and replay results rather than hidden model reasoning.
The second bucket is a skill-model update: a component in the private skill-model foundry was refreshed, retrained, or repointed at a new base model, and its behaviour on edge cases shifted even though its aggregate benchmark scores looked fine at release. The third bucket is a genuine seasonal or exogenous shift in the intent mix itself: end-of-quarter transaction patterns, a public holiday cluster, a marketing campaign that changed the volume of one case type, none of which are drift in the agent's policy at all, but which will still move a tool-selection distribution because the categories underneath it changed shape.
Rollback is the correct path when the root cause is a schema change or a bad skill-model release, and it should be the default first move rather than the last resort, because a rollback restores a known-good state within minutes while a forward fix, patching the integration or retraining the skill, takes days and should happen in parallel rather than blocking recovery. Retrain is the correct path when the skill-model update itself is sound in direction but under-calibrated for a case type it had not seen enough of, and the fix is targeted additional training data for that case type rather than a full retrain of the base skill.
Threshold review is the correct path when the triage concludes the shift was seasonal and genuine, in which case the fix is not to touch the agent at all but to update the baseline, and often to add a seasonal adjustment factor to the sentinel so the same calendar-driven shift does not re-trigger next quarter.
Failure modes
Three failure modes deserve explicit pre-production tests because each can undermine the sentinel before the underlying mechanism is diagnosed.
The first failure mode is an over-sensitive threshold that produces alert fatigue. The illustrative warning pattern is several weekly pages that close as noise, followed by slower acknowledgement. For low-volume categories, extend burn-in, pool sparse bins where defensible and require a predeclared effect-size and uncertainty rule. Backtest any proposed two-statistic gate against labelled historical or synthetic episodes. Its acceptance criterion must include both false-alert and missed-event costs; no reduction or zero-miss claim should be assumed.
The second failure mode is a sampling window too short to catch slow drift. The symptom here is subtler and more dangerous: the sentinel shows healthy week-over-week comparisons throughout a quarter, yet a slow linear drift accumulates underneath, three or four percentage points of tool-call share moving each month, small enough each week to sit under the alert threshold, large enough over a quarter to represent a genuinely different agent policy.
The fix is to run a second, longer-horizon comparison in parallel with the primary weekly sentinel, a ninety-day window compared against a baseline from a year prior, specifically designed to catch exactly this class of creeping shift that a short window structurally cannot see, since a short window by construction only compares adjacent periods and has no mechanism for accumulating a trend.
The third failure mode is a genuine seasonal or business-driven shift in intent mix being misclassified as drift, wasting a triage cycle and, worse, training the team to distrust the sentinel's positive alerts. The symptom is an alert that traces cleanly to an external, well-documented cause, a marketing campaign, a regulatory reporting deadline that shifted the mix of case types, a public holiday cluster, and the fix is to build a calendar of known seasonal events directly into the sentinel's baseline logic, so that the comparison automatically accounts for the expected seasonal mix rather than flagging it fresh every time the calendar repeats, and to keep a running log of confirmed seasonal explanations so the triage team can check that log first before opening a full investigation.
6. The fraud-triage case: a modelled silent-drift scenario
The synthetic composite uses a fraud-triage agent for first-line disposition of flagged card and account transactions before the residual caseload reaches investigators. For each case it calls transaction lookup, device fingerprinting, sanctions and watchlist checks and customer history, then proposes closure or escalation. Any suspicious-activity reporting decision remains subject to human and compliance controls. All dates, rates, lags and financial values below are model inputs chosen to illustrate the control logic.
The modelled thirty-day baseline uses the following call-propensity vector for the “card-not-present dispute” intent: transaction lookup in 99% of cases, device fingerprinting in 81%, customer history in 94%, sanctions check in 9%, human escalation in 7% and referral to a human-led SAR assessment process in 2%. The agent does not file a suspicious-activity report. A separate synthetic transition distribution supplies the scenario's PSI, set below 0.04 across its reference windows.
The modelled upstream cause is a device-fingerprint schema change. A device-recognised field is renamed and its default changes from false to null during an API version bump. An observable routing condition classifies null as confirmed absence, so the agent skips the fingerprint skill instead of calling it and receiving an error. Contract-version records, branch telemetry and replay make that cause testable without asking for hidden chain-of-thought.
Within eleven days of the modelled schema change, the call-propensity vector shifts to: transaction lookup at 99%, device fingerprinting at 58%, customer history at 93%, sanctions check at 15%, human escalation at 13% and SAR-assessment referral at 2%. The sentinel's normalised transition distribution crosses PSI 0.10 on day six and 0.25 on day eleven; its predeclared count test gives p=0.003 on day eleven.
In the scenario, triage identifies the schema change after four hours because the per-tool breakdown points to the falling fingerprint-call rate. The model then assumes an explicit null-handling correction after eighteen hours and a return to within 0.03 PSI of baseline within three days. Those timings are illustrative response targets, not a production incident record.
The scenario then poses a counterfactual for a risk committee. Assume a weekly false-negative metric cannot show a credible deviation until day 34 because confirmed outcomes arrive late, followed by eight to ten days for validation. Under those model inputs, a sentinel crossing its boundary on day 11 creates a 31-to-33-day analytical lead. A real committee should replace every input with observed label latency, volume and decision rules, then backtest whether the sentinel would actually have fired.
The composite estimates that the shift under-escalates four to six fraud cases a day that should reach an investigator and, where warranted, the separate human-led SAR assessment process. It assigns 18,000 USD of loss exposure to a missed case. Both inputs are sensitivity assumptions, not public claims about a bank's losses or reporting decisions.
Under the stated sensitivity assumptions, the exposure calculation is 19 days multiplied by five cases per day multiplied by USD 18,000, or USD 1.71 million. That is a scenario output, not an avoided-loss claim. Its purpose is to show how detection lead time can enter an investment case. A real decision must use locally evidenced loss distributions, remediation time and uncertainty ranges.
7. Sentinel metrics at a glance
The table below summarises a modelled baseline package for a regulated or customer-facing workload. Its windows and thresholds are candidate settings for burn-in and replay, not values calibrated from disclosed deployments. Every system's volume, seasonality and consequence profile is different.
| Metric | Statistical test | Sampling window | Alert threshold | What it catches |
|---|---|---|---|---|
| Tool-call share per intent | Population stability index | 7-day rolling vs 30-day baseline | PSI 0.10 low, 0.25 high | Sudden shifts in which tool an agent prefers within an intent category |
| Tool-call share, rare tools | KL divergence | 7-day rolling vs 30-day baseline | KL 0.05 low, 0.15 high | Low-frequency tool drift masked by PSI's coarser binning |
| Tool-call sequence order | Chi-squared on sequence pairs | 14-day rolling vs 60-day baseline | p < 0.01 | Reordering of steps, such as skipping a verification step before escalation |
| Slow drift accumulation | PSI, long horizon | 90-day rolling vs 365-day baseline | PSI 0.20 | Creeping shifts too small per week to trip the short-window test |
| Escalation rate by intent | Chi-squared proportion test | 7-day rolling vs 30-day baseline | p < 0.01 | Behavioural shift in how often the agent defers to a human |
| Skill-model version mix | Categorical PSI | Per deployment event | PSI 0.15 | Unintended traffic split across skill-model versions after a rollout |
| Intent category mix | Chi-squared goodness of fit | 7-day rolling vs seasonal calendar baseline | p < 0.01 outside known seasonal window | Genuine change in the volume mix of intents, flagged separately from tool-policy drift |
A sentinel system watches behaviour before outcomes arrive
Many business outcomes arrive late. Complaints, losses and control findings may lag by weeks. Route choices, tool calls, retrieval failures and escalations arrive immediately. They are leading indicators when their meaning is defined in advance.
| Sentinel | Leading question | Necessary slice | False-positive risk |
|---|---|---|---|
| Tool-selection share | Is the agent solving cases by a different path? | Task, tenant and model version | Legitimate change in demand mix |
| Refusal rate | Has policy interpretation shifted? | Policy reason and user cohort | New prohibited requests |
| Retrieval-empty rate | Is evidence access failing? | Corpus, connector and permission | Planned source retirement |
| Escalation rate | Is uncertainty or consequence routing changing? | Case type and reviewer team | Temporary staffing policy |
| Trace length | Is planning becoming unstable or inefficient? | Workflow and route | A newly complex case population |
Separate population shift from policy shift
The same aggregate movement can have two causes. Users may submit different work. The system may behave differently on unchanged work. Mixing those causes produces bad remediation.
| Diagnostic comparison | Holds constant | Varies | Interpretation |
|---|---|---|---|
| Reference-case replay | Cases and expected policies | System build | Behavioural regression |
| Current mix on old build | System build | Live cases | Population change |
| Version A/B shadow run | Case stream | System version | Causal version signal |
| Cohort decomposition | Within-cohort behaviour | Cohort weights | Aggregation effect |
| Human adjudication sample | Review rubric | Agent outcome | Real quality or safety change |
Make drift response proportional
Not every change deserves rollback. Some need more samples. Others cross a permission or customer-harm boundary and demand immediate containment.
Baselines require versioning and approval. Otherwise each rebaseline erases part of the history. Tool distributions are diagnostic, not self-interpreting. A rising database-call share may indicate better routing, a failing cache or prompt injection. Context decides.
The NIST AI RMF places measurement inside a continuing management cycle. The NIST Generative AI Profile identifies risks that may change after release. NIST SP 800-137 gives a broader continuous-monitoring frame. The original ADWIN work is useful for adaptive-window thinking. The Federal Reserve’s 2026 revised model-risk guidance offers risk-based monitoring practices for covered models, but expressly leaves generative and agentic AI outside its formal scope.
A useful operating standard follows. Every sentinel must have an owner, a diagnosis playbook and a bounded response. Every material model or policy change must carry a new baseline candidate. Each material incident should trigger a documented review of sentinel coverage and any missing earlier signal.
Sentinel readiness review
Before a sentinel enters production, walk through each item with the service owner:
- Name the behaviour being watched.
- Define its expected direction.
- Record the reference window.
- Version the baseline population.
- State the smallest meaningful shift.
- State the shortest valid window.
- Separate warning and containment levels.
- Assign one accountable owner.
- Name the responding team.
- Link the triage runbook.
- Test alert delivery.
- Test weekend ownership.
- Preserve the triggering traces.
- Preserve the comparison data.
- Decompose the signal by intent.
- Decompose it by user cohort.
- Decompose it by model version.
- Check recent policy changes.
- Check recent corpus changes.
- Check recent permission changes.
- Replay stable reference cases.
- Compare the previous build.
- Sample outcomes with human adjudication.
- Estimate queue impact.
- Define the safe narrowed mode.
- Test rollback authority.
- Require approval to rebaseline.
- Record why an alert closes.
- Link incidents to the sentinel.
- Review missed incidents quarterly.
These checks make the alarm explainable. They also stop a monitoring team from treating every shift as a modelling problem. A sentinel is complete only when detection, diagnosis and response meet in one operating record.
Notes for practitioners
When outcome labels arrive late, do not rely on output accuracy as the only primary signal. Tool, skill, evidence and policy-event distributions are available when a trajectory completes and require no outcome label. Treat their earlier movement as a hypothesis to validate through replay, not as a guaranteed property of every failure.
Build the sentinel with the discipline of a governance-grade control. Use a burn-in period before paging, a predeclared materiality and uncertainty rule, a human-approved baseline refresh policy and a triage runbook with bounded response paths. A second statistic can help diagnose small-sample noise, but two tests on the same event data are not independent confirmation.
Instrument by intent category because a blended distribution can hide concentrated drift. Use PSI for an effect-size view, KL divergence for directional comparison and a count test for sampling uncertainty when assumptions hold. Predeclare one primary alert statistic; use the others for diagnosis, and do not count agreement on the same events as independent evidence.
Keep a running log of confirmed seasonal and business-driven explanations for past alerts, and feed that log back into the sentinel's baseline logic, because the fastest way to lose a team's trust in a sentinel is to make them re-investigate the same quarter-end pattern four times a year. Finally, when you present the case for this investment to a risk committee or a budget owner, lead with the time gap between detection and the point where the equivalent output metric would have forced the same conclusion, and translate that gap into a cost figure using the institution's own historical loss data rather than an industry benchmark, because that comparison, made concrete in the institution's own numbers, is what turns a monitoring upgrade from a nice-to-have into a funded programme.