Agent drift is what happens when a system still appears to be running, but the quality of its decisions has quietly changed. The model may be the same. The world around it is not.

Documents change, APIs return different shapes, users ask new questions, and a small prompt edit can change which tools the agent prefers. Monitoring drift means looking for those changes before they become a support queue or a security incident.

Watch the work, not only the uptime

A green health check tells you that a server answered. It does not tell you whether the agent found the right source, took too long, escalated appropriately, or started making confident guesses.

• Sample conversations by workflow, not just by date.
• Track retrieval failures, empty results, and citations to stale sources.
• Record tool calls, approvals, retries, and human corrections.
• Measure cost and latency alongside task success.

Keep a small evaluation set alive

Maintain a set of real questions with an expected answer, expected source, and expected escalation behaviour. Include easy questions, ambiguous questions, recently changed policies, and requests the agent must refuse.

Run it after model, prompt, source, permission, or tool changes. A test set does not need to be huge to be useful. It needs to represent the work that matters and to be updated when the business learns something new.

Look for slow, human-shaped signals

Some of the best drift signals are not model scores. They are people copying the same correction into replies, abandoning a conversation after the agent answers, reopening a ticket, or routing an issue to a specialist more often than before.

Give the support team a quick way to mark “wrong source,” “wrong action,” “missing context,” and “should have escalated.” These labels help you fix the right layer instead of endlessly rewriting the system prompt.

Make recovery ordinary

Keep a known-good prompt and configuration, make source versions visible, and have a way to disable a tool without taking the whole agent offline. When a change causes drift, roll back first and investigate second.

ChatNexus exposes the practical settings that usually participate in drift—knowledge, prompts, memory, limits, model selection, and deployment. Treat each change as something to evaluate, not something to assume is harmless.

Use the ChatNexus introduction as the configuration map, then pair it with your own small, living evaluation set.