Monitoring AI Agent Failures in Production

Create a failure taxonomy

Agents can fail even when every API returns successfully. Common classes include wrong intent, unsupported claim, missed evidence, incorrect tool or arguments, authorization denial, harmful approval bypass, repeated action, false completion, loop exhaustion, and poor escalation. Separate these from provider timeout, rate limit, malformed response, and downstream service failure because owners and remedies differ.

Define severity from impact, scope, reversibility, and exposure. One unauthorized disclosure or financial duplicate may outrank hundreds of formatting defects. Identify leading signals such as rising retries or denied calls and lagging signals such as complaints, corrections, reversals, and repeat contact. Document what normal variation looks like for each workflow and user group.

Instrument the complete trajectory

Assign a trace identifier that connects the user request, workflow version, model configuration, retrieved source identifiers, model decisions, validated tool calls, approvals, tool results, final state, and response. Record duration, token or usage measures, retries, and stop reason by step. Stable identifiers let investigators reconstruct sequence without relying on one large transcript blob.

Minimize captured content. Store structured fields and hashes or references where possible, redact secrets, restrict trace access, and define retention by purpose. Logs must not become a second ungoverned store of private prompts, account data, credentials, or source documents. Preserve enough protected evidence for security and high-impact incidents according to organizational requirements.

Alert on actionable signals

Create alerts for outcomes that require timely response: prohibited tool attempts, unexpected destinations, cross-tenant denial, unusual write volume, duplicate-effect signals, runaway cost, sustained latency, and elevated failures by workflow version. Use rate and absolute thresholds appropriate to traffic. Group related events so responders can see one incident rather than hundreds of isolated symptoms.

Every alert needs an owner and a playbook. The first action may disable a tool, reduce autonomy, switch to read-only mode, route all cases to people, revoke a credential, or roll back a version. Test that these controls work before an incident. Do not depend on asking the same malfunctioning agent to diagnose or stop itself.

Learn from reviews and incidents

Sample successful and failed traces by risk and workflow class. Compare agent outcomes with reviewer edits, customer follow-up, reversals, and audited external state. Watch for drift after prompt, model, tool, policy, data, or interface changes. A stable average may hide a sharp regression for one language, tenant, request type, or rare action.

For each material incident, preserve a minimized reproduction, identify the failed control, assign corrective work, and add a repeatable evaluation. Verify monitoring itself through synthetic failures and alert-delivery tests. Current provider telemetry and agent tooling change, so check official documentation quarterly while keeping your incident taxonomy and response ownership provider-independent.

Detect repeated ticket creation

A service agent starts creating duplicate escalation tickets when the ticket system returns a slow confirmation.

1. Correlate each customer request, create-ticket attempt, idempotency key, downstream response, and resulting ticket identifier in one trace.
2. Alert when one task records multiple create attempts or more than one resulting ticket, with severity based on customer impact.
3. Use the playbook to disable automatic ticket creation and fall back to a reviewed queue while preserving read-only support.
4. Inspect whether timeout handling ignored an ambiguous success and whether the downstream system honored the idempotency key.
5. Add slow and lost-response cases to evaluation, repair the contract, and confirm the alert and fallback before restoring writes.

Agent monitoring specification

Use this specification to tie each production signal to meaning, ownership, and response.

• Outcome: completion evidence, prohibited results, severity, and affected user or resource.
• Trace: request, versions, source identifiers, decisions, calls, approvals, results, and stop reason.
• Signal: metric or event, baseline, threshold, segmentation, aggregation window, and privacy rule.
• Response: owner, notification, containment, fallback, evidence access, and communication path.
• Learning: review sample, incident record, reproduction, evaluation case, fix, and closure evidence.

Common mistakes

• Monitoring only HTTP errors even though an agent can complete the wrong action with successful responses.
• Saving every prompt, document, secret, and account record indefinitely because it might aid later debugging.
• Creating alerts without an owner or tested containment control, leaving responders to improvise during impact.

Try one

Sources

• OpenAI agents guideOfficial guidance for building agent workflows with current OpenAI platform capabilities.
• OpenAI evaluation best practicesOfficial methods for defining evaluation criteria and testing model behavior.