An AI agent can produce a correct final answer while taking a dangerous route. It may call an unnecessary tool, read excessive data, repeat an action or spend far more than expected.
Production monitoring therefore needs the full execution path, not only uptime and the last message.
Trace one business run from start to finish
Assign a correlation ID to the incoming request and carry it through model calls, retrieval, tools, approvals and the final result. The trace should show sequence, duration, status and responsible identity.
OpenTelemetry describes traces, metrics and events as complementary signals for GenAI observability. Content logging can expose sensitive data, so store prompts and tool results only when the purpose, access rules and retention policy justify it.
Log every tool decision
Record the tool offered, arguments proposed, permission used, approval received, execution result and any retry. Separate the model's proposal from the system action.
OWASP warns about excessive agency: excessive functionality, permissions and autonomy expand impact. Use the least-privilege design from the prompt-injection guide.
- actor and request ID
- model and workflow version
- tool name and validated arguments
- approval or policy decision
- result, error and retry count
- downstream record changed
Measure quality after launch
Track accepted outcomes, material corrections, escalations, overrides and false actions. Sample ordinary successful runs as well as failures; otherwise monitoring sees only obvious incidents.
Reuse the golden dataset and thresholds from pre-launch AI testing. Run scheduled evals and compare results by model, prompt, language and workflow version.
Control latency and cost
Measure time to first useful output, full workflow duration, model usage, external API cost and human-review time. Apply per-run and daily limits.
An agent caught in a tool loop should not be allowed to consume until a provider limit stops it. Cap steps, tokens, retries and parallel calls; alert on changes in cost per accepted case.
Design alerts around actionability
Alert on events that require a decision: unauthorised tool attempts, schema failures, repeated actions, error-rate changes, cost spikes, backlog growth and quality falling below threshold.
Every alert needs an owner, severity, expected response time, a runbook and a way to suppress a known duplicate. A dashboard without response ownership is not control.
Keep fallback and a manual stop
Fallback may mean a simpler deterministic workflow, read-only mode, a queued human task or a previous verified version. Define the condition and test the transition.
Consequential actions require an external stop that does not depend on the agent agreeing. Human-in-the-loop controls should include approval, cancellation, rollback and an audit trail.
Review incidents and near misses
Preserve the trace, configuration, inputs, tool results and downstream effects. Determine whether the cause was data, model, prompt, permission, integration, monitoring or human process.
Turn the finding into a test case, control change and owner. Production monitoring improves the system only when lessons enter the evaluation suite.
How I monitor a publishing agent
In my publishing workflow, the model does not receive a generic 'publish' capability. The process records a draft, checks 21 fields, verifies language pages and internal links, and only then performs a full update to published status.
The trace separates generated content, uploaded cover, stored record and public page. If any stored field differs, the workflow stops before publication. This makes a successful final URL insufficient on its own; I can see which step produced it and what was verified.
Questions and answers
What should be monitored first?
Start with business outcome, tool actions, errors, latency, cost and human overrides. Add detail where it changes a decision.
Should prompts be stored?
Only when needed and authorised. Prompts can contain personal or confidential data, so minimise content, restrict access and define retention.
How do I detect a tool loop?
Set maximum steps, repeated-call detection, time and cost budgets, then alert and stop when a boundary is reached.
Is a dashboard enough?
No. Each important signal needs an owner, threshold, notification path and tested response procedure.
How often should quality be evaluated?
Continuously through production samples and on a schedule, plus after any material model, prompt, data, tool or policy change.
Operational worksheet
Before approval, put every control into a worksheet with an owner, evidence, threshold and next review date. A statement such as “monitor quality” is not actionable. “Operations owner reviews the material-correction rate each Monday and pauses the workflow above the agreed threshold” can be tested.
Link every control to a business consequence. If a schema failure can corrupt a customer record, specify containment and reconciliation. If a cost alert only indicates harmless seasonal volume, define the context that prevents false escalation.
Keep versions of prompts, schemas, policies, tools and external dependencies. A result without its configuration cannot be reproduced. Record exceptions and their expiry dates so that temporary workarounds do not become permanent invisible policy.
Finally, rehearse the human path. The named owner should be able to find the evidence, stop or restrict the workflow, move cases to fallback and explain the current state without asking the AI system to diagnose itself.