You can't monitor an agent the way you monitor an API

Your API observability stack tells you when a request is slow and when it errors. That's enough information to diagnose most service failures.

It's not enough for agents. An agent can respond in 2 seconds with a 200 status code and still be completely wrong. It can call a tool 15 times when the task needed 4. It can succeed at the wrong task — the one the user didn't ask for. None of these show up as errors in your monitoring dashboard.

Agent observability requires a different model.

What you need to trace

Every LLM call, with its full context. The input prompt (system prompt + conversation history + current message), the model version, the temperature, the token counts (input and output), and the response. When something goes wrong, you need to be able to replay what the model saw. If you don't store the full prompt, you're debugging blind.

Every tool call, in sequence. The function name, the arguments, the response, the latency, and whether validation passed. Store tool calls in order — the sequence matters as much as the individual calls. An agent that calls get_user then update_user tells a different story than one that calls update_user without a preceding get_user.

The reasoning chain. If the model produces intermediate reasoning (think-step outputs, chain-of-thought), store it. Reasoning traces are the primary diagnostic artifact for wrong outputs. They tell you where the agent's logic went sideways — which premise was incorrect, which inference was invalid, which tool output was misinterpreted.

State transitions. If you've implemented a state machine (you should), log every transition: from state, event, guard result, to state, timestamp. State transition logs let you reconstruct exactly what the agent did in what order.

Outcome classification. Did the agent complete the task? Did it fail? Did it produce output but output the wrong thing? Did the user need to correct it? Outcome classification is the metric that tells you whether the agent is actually working, not just running.

The span structure

Use OpenTelemetry spans following the GenAI semantic conventions. Each agent execution is a root span. Within it:

agent_execution (root span)
├── llm_call (span)
│   ├── attributes: model, token_counts, latency
│   └── events: prompt, response
├── tool_call: get_account_data (span)
│   ├── attributes: function_name, validated, latency
│   └── events: arguments, response
├── llm_call (span)
│   └── ...
└── tool_call: update_account (span)
    └── ...

Every span gets a trace ID that links it to the root execution. Every LLM call and tool call is a child span. The full execution is reconstructible from the trace.

Metrics to track

The standard set (necessary but not sufficient):

• agent.execution.duration_ms — total time per execution
• agent.llm_call.count — number of LLM calls per execution
• agent.tool_call.count — number of tool calls per execution
• agent.tool_call.error_rate — fraction of tool calls that fail
• agent.llm_call.input_tokens / output_tokens — token usage (cost proxy)

The quality set (this is the work):

• agent.outcome.success_rate — fraction of executions that complete correctly
• agent.outcome.correction_rate — fraction where user corrected the output
• agent.tool_schema_validation.failure_rate — tool calls that fail validation
• agent.goal_drift_detected — executions where output diverged from stated goal (see below)
• agent.retry_count — how often the agent had to retry steps

The cost set:

• agent.token_cost_usd — estimated cost per execution
• agent.execution_cost_usd — total cost including API calls and compute

Automated quality assessment

You can't manually review every agent output at scale. You need automated quality assessment.

LLM-as-judge: Use a separate LLM call (with a structured evaluation prompt) to score agent outputs against a rubric. The rubric is specific to your use case: did the agent complete the stated task, did the output match the user's intent, were there hallucinations?

def evaluate_output(user_request: str, agent_output: str) -> EvaluationResult:
    prompt = f"""
    User request: {user_request}
    Agent output: {agent_output}
    
    Evaluate on a scale of 1-5:
    1. Task completion: Did the agent complete what was asked?
    2. Accuracy: Is the output factually correct?
    3. Relevance: Does the output address the request?
    
    Respond with JSON: {{"task_completion": N, "accuracy": N, "relevance": N, "issues": [...]}}
    """
    return llm.evaluate(prompt)

Run this evaluation on a sample of production outputs daily. Track the scores as metrics. Alert when scores drop.

Regression testing: Maintain a set of golden test cases — user requests with known correct outputs. Run the agent against these test cases on every deploy. Compare outputs (via LLM judge or exact match where possible). A deploy that drops test case pass rate by more than N% should block.

Anomaly detection: Track the distribution of tool call counts, execution times, and token usage per request type. Executions that fall outside normal distribution are candidates for manual review. An agent that normally makes 4 tool calls suddenly making 15 for a similar request is a signal.

What to alert on

Immediately (P1): Tool call error rate > threshold. Execution failure rate spike. Token cost spike (runaway agent). Schema validation failure rate > 0 on a tool that was previously clean.

Daily review: LLM judge quality score below baseline. Retry count increase. Novel tool call sequences not seen in testing.

Weekly trend: Correction rate trend. Goal drift rate. Cost per execution trend.

The dashboard that shows you p99 latency and 5xx rate is monitoring your infrastructure. The dashboard that shows you tool call error rate, LLM judge score, and correction rate is monitoring your agent. You need both. You probably only have the first one.

Build the second dashboard before you ship to production.