AI Agent Observability: How to Monitor Logs, Usage, and Performance After Deployment

Observability for AI agents is harder than observability for standard LLM inference, and it is harder in a specific way: the failure modes that matter most are not the ones that produce errors. A stuck agent that generates tool calls indefinitely does not return a 500. An agent that gradually degrades in output quality at long context lengths does not trigger a latency alert. An agent session that costs forty dollars instead of four dollars does not produce a warning unless you built cost alerting before it happened.

Standard LLM inference observability tracks three metrics: time to first token, tokens per second, and error rate. These metrics are necessary but not sufficient for production agent monitoring. Agents execute multi-step workflows where the failure can occur at any step, where cost accumulates across tool calls and model inference calls, and where the quality of the final output depends on the quality of every intermediate step. Observability for agents requires instrumentation at the step level, not the session level, from the first day of production deployment.

• The observability gap between sandbox and production agents is larger than most teams anticipate. Sandbox agents are monitored by their developers who can inspect intermediate states manually. Production agents run without direct supervision, and the failures that occur (stuck loops, context pollution, cost spikes) are only detectable through automated instrumentation.
• Step-level tracing is the minimum viable observability structure for production agents. Session-level logs (what the user asked, what the agent returned) tell you what happened. Step-level traces (which tool was called at step 7, what it returned, how long it took, how much it cost) tell you why it happened and where to look when something goes wrong.
• GMI Agentbox provides unified usage tracking, per-session logs, spend attribution, and performance metrics from day one. This operational visibility is available as part of the platform rather than requiring a separately built observability stack.
• Cost attribution at the step level is not optional for production agents. Agents that appear to function correctly can be catastrophically expensive when they handle edge cases: a retry loop that calls a model 50 times instead of 5, a context accumulation pattern that inflates token counts 10x over a session, or a tool failure that causes the agent to generate verbose error-handling responses. These cost spikes are invisible without per-step cost logging.
• Three alert categories should exist before the first production deployment: error rate above baseline, latency p99 above threshold, and per-session cost above ceiling. The cost alert is the one most often skipped and the one that catches the most expensive production incidents.
• Runbooks for the three most likely agent failure modes should be written before launch, not after the first incident. The three failures are: stuck agent (tool call loop with no termination), context overflow (session hitting model context limit mid-task), and cost spike (session cost 5x or more above average). Each has a distinct signature in step-level traces and a distinct remediation.

Why Agent Observability Is Harder Than Standard LLM Observability

Standard LLM inference is a single-turn system. A request arrives, the model generates a response, the response is returned. The observability question is: how fast did that happen, how many tokens were generated, and did it succeed? Three metrics answer three questions.

Agents are multi-turn systems with branching execution paths. A single user request may trigger 30 model inference calls, 50 tool calls, 3 human-in-the-loop confirmation steps, and 2 fallback paths. The execution graph is not predetermined. The agent decides at runtime which tools to call, whether to retry, and when the task is complete. Observability for this system requires tracking every node in a dynamic execution graph, not just the entry and exit points.

Four properties of agent workloads create observability challenges that single-turn inference does not have.

Variable execution depth. A simple agent task may complete in 3 steps. A complex task may require 300 steps. The same agent handling the same type of request from different users may produce execution graphs that differ by two orders of magnitude in depth. Observability that assumes fixed execution depth misses the variance that contains the most important signal.

Cost-per-session variance. LLM inference cost per request is relatively stable for a given model and typical prompt length. Agent cost per session varies dramatically based on task complexity, the number of tool call failures and retries, context accumulation, and whether the agent terminates cleanly or requires human intervention. Average cost metrics mask this variance. The sessions in the tail of the cost distribution are often the ones that reveal infrastructure problems.

Intermediate state dependencies. In single-turn inference, the input and output are sufficient to diagnose most failures. In agents, the output of step 15 depends on the output of step 14, which depends on the output of step 13. A failure that produces a wrong final answer may originate from an incorrect tool call result at step 8 that propagated through subsequent reasoning steps. Diagnosing this requires the complete step-by-step trace, not just the final output.

Tool call failure propagation. When a tool call fails at step 12 of a 30-step agent task, the agent may attempt to continue by reasoning around the failure, retry the tool call, or call a fallback tool. All three responses are legitimate. What is not legitimate is a tool call failure that propagates undetected through the remaining 18 steps, producing a final answer that is confidently wrong because it was based on incomplete tool call data. Detecting this failure mode requires per-step tool call outcome logging.

The Five Observability Layers for Production Agents

Agent observability organizes into five layers, each with distinct instrumentation requirements and distinct failure signals.

Layer 1: Infrastructure observability

Infrastructure observability covers the compute resources running the agent: GPU utilization, memory usage, model inference latency, and endpoint health. This layer is analogous to standard LLM inference observability and uses the same tooling: Prometheus metrics, Grafana dashboards, and endpoint health checks.

Key metrics at this layer:

• GPU utilization percentage (target: 40 to 85 percent for sustained production)
• Model inference TTFT (p50, p95, p99)
• Inter-token latency for streaming responses
• Endpoint error rate (5xx per minute)
• GPU memory utilization (alert if above 92 percent)

Layer 2: Session observability

Session observability covers the lifecycle of a complete agent task from user request to final response. This layer captures the high-level picture: how long did the task take, how much did it cost, how many steps were executed, and did it complete successfully?

Key metrics at this layer:

• Session duration (p50, p95, p99)
• Session cost in dollars (p50, p95, p99)
• Total step count per session (p50, p95, p99)
• Session completion rate (completed vs timed out vs errored vs human-escalated)
• Retry event count per session

Layer 3: Step-level tracing

Step-level tracing is the layer most often missing from initial production deployments and most needed when incidents occur. Every step in the agent's execution graph gets a trace record.

Required fields per step trace:

• session_id: unique identifier linking all steps in a session
• step_sequence: integer sequence number (1, 2, 3...)
• step_type: model_inference, tool_call, routing_decision, human_gate, fallback
• timestamp_start and timestamp_end
• latency_ms: wall-clock time for the step
• input_tokens (for model inference steps)
• output_tokens (for model inference steps)
• model_id (for model inference steps)
• tool_name (for tool call steps)
• tool_input (for tool call steps, with PII redaction if needed)
• tool_output_summary (for tool call steps, truncated if large)
• step_cost_usd: computed cost for this step
• outcome: success, error, timeout, fallback_triggered, human_escalated
• error_code and error_message (when outcome is error or timeout)

This structure enables programmatic trace queries: show me all sessions where step type tool_call with tool_name database_query had outcome error in the last 24 hours. Without this structure, diagnosing a tool integration failure requires manually correlating fragmented log entries.

Layer 4: Tool call observability

Tool calls are the primary interaction point between agents and external systems. External systems have their own reliability profiles: rate limits, latency variance, schema changes, and downtime. Tool call observability tracks these interactions independently from the agent's internal reasoning.

Key metrics at this layer:

• Tool call success rate per tool name
• Tool call latency p99 per tool name
• Tool call error rate by error type (rate limit, timeout, schema error, auth failure)
• Tool call retry rate per tool name
• Tool call result size (to detect truncation issues)

Separating tool call observability from step-level agent tracing allows tool reliability to be tracked as an independent dimension. A tool that is degrading (rising error rate, rising latency) appears in tool-level metrics before it begins affecting session success rates significantly enough to trigger session-level alerts.

Layer 5: Quality observability

Quality observability is the hardest layer and the most often skipped. It measures whether the agent's outputs are good, not just whether the agent completed without errors.

Three approaches to quality measurement at different cost levels:

Lightweight: user feedback signals (thumbs up/down, explicit rating, task completion confirmation from the user). Zero additional inference cost. Requires UX integration. Provides signal on user-perceived quality.

Medium: LLM-as-judge evaluation on a sample of sessions. A small evaluation model scores the agent's final output on a defined rubric. Adds per-evaluated-session cost but provides automated quality measurement without human review.

Comprehensive: human review of sampled sessions by domain experts. High cost per session, low volume. Appropriate for regulated industry applications where quality has compliance implications.

The Three Most Important Alerts for Production Agents

Three alert categories are required before production traffic begins. Each addresses a different failure mode that is only detectable through automated monitoring.

Alert 1: Error rate above baseline

Define a baseline error rate for your agent based on the first week of production traffic. Alert when the rolling 5-minute error rate exceeds 2 to 3 times baseline. A sudden error rate increase typically indicates one of three causes: a tool integration failure (external API is down or returning unexpected formats), a model provider issue (primary model returning 5xx or timeouts), or a code change that introduced a regression in the agent's execution logic.

The alert should include: current error rate, baseline error rate, error rate by step type (to isolate whether errors are concentrated in tool calls or model inference), and error rate by error code.

Alert 2: Session cost above ceiling

Define a per-session cost ceiling based on the expected cost structure of your agent. A typical setting is 5x the average session cost. Alert when any individual session exceeds this ceiling. A session that costs 5x average is either handling an unusually complex task (legitimate and expected occasionally) or stuck in a retry loop or context accumulation pattern (infrastructure problem).

The alert should include: session ID, total session cost, step count, model inference cost breakdown, tool call count, and whether the session is still active or completed.

Alert 3: Latency p99 above threshold

Define a p99 latency threshold based on the acceptable end-to-end response time for your use case. For interactive agents, this is typically 30 to 60 seconds. For batch agents, it may be 300 seconds. Alert when p99 latency across the last 100 sessions exceeds the threshold.

The alert should include: current p99, 24-hour baseline p99, slowest 5 sessions by step count, and whether slow sessions are concentrated in specific tool calls or model inference steps.

Cost Attribution: The Metric That Prevents Surprise Bills

Cost attribution for agents has three dimensions that standard LLM inference cost tracking does not require.

Dimension 1: Cost by session. Every session gets a total cost computed from the sum of all inference and tool call costs across all steps. This is the primary cost metric for detecting runaway sessions and understanding the cost distribution of your agent's user base.

Dimension 2: Cost by step type. What fraction of total cost comes from model inference versus tool calls? A high tool-call cost fraction indicates that external API costs (which the agent generates by calling third-party services) are a significant cost driver. A high model inference cost fraction with low step counts indicates that individual inference calls are expensive, which may signal that the model is over-specified for the task.

Dimension 3: Cost by user or customer. For commercial agents where cost is passed through to customers or attributed to business units, session cost must be traceable to the specific user or organization. This requires tagging every session with a user identifier at creation time and aggregating session costs by user over billing periods.

The GMI Agentbox spend attribution feature provides cost tracking at the session level across the agent's usage. For teams building on top of this infrastructure, instrumenting user-level cost attribution requires passing user identifiers through the session initialization and aggregating session costs from the Agentbox dashboard data.

Runbooks for the Three Most Likely Agent Failures

Writing runbooks before the first production incident is the operational investment that most reduces incident duration. Three failures occur most commonly in production agent deployments.

Runbook 1: Stuck agent (infinite tool call loop)

Signature in traces: high step count (above 2x average), tool_call steps dominating step type distribution, repeated calls to the same tool with similar inputs, session still active after 3x normal expected duration.

Diagnosis steps:

1. Pull the step-level trace for the stuck session
2. Identify the first repeated tool call (same tool name, similar inputs across consecutive steps)
3. Check the tool call outcome for those steps (timeout, schema error, or success with unexpected output)
4. Determine whether the agent is retrying due to tool failure or looping due to a logic error in termination condition

Remediation:

• Immediate: terminate the session via the Agentbox dashboard to stop cost accumulation
• Short-term: add maximum tool call count limit per session if not already present
• Long-term: fix the agent's termination logic or tool call error handling for the specific failure that caused the loop

Runbook 2: Context overflow (session hitting model context limit)

Signature in traces: sudden session termination with error code context_length_exceeded, concentrated in long-running sessions or sessions with many tool calls, preceded by increasing input_tokens counts across consecutive model inference steps.

Diagnosis steps:

1. Identify sessions that terminated with context overflow error
2. Check the step-level trace for cumulative context growth: sum input_tokens across model inference steps to see when context exceeded the limit
3. Identify which step type contributed most to context growth (long tool call results, verbose model reasoning, accumulated conversation history)

Remediation:

• Immediate: implement context summarization at defined token thresholds (e.g., summarize accumulated context when it exceeds 50 percent of the model's context window)
• Short-term: truncate tool call results to a maximum size before appending to context
• Long-term: implement sliding window context management for agents that regularly approach context limits

Runbook 3: Cost spike (session cost 5x or more above average)

Signature in traces: high session cost, concentrated in either high model inference costs (many inference steps or long generation per step) or high tool call count (retry loops, high-cost external API calls).

Diagnosis steps:

1. Pull the cost breakdown by step type for the expensive session
2. If model inference cost is high: check whether step count is abnormal or whether individual inference calls are unusually long (check output_tokens per step)
3. If tool call count is high: identify which tool is being called most frequently and check whether those calls are succeeding or failing-and-retrying

Remediation:

• Immediate: review and apply per-session cost ceiling (auto-terminate sessions that exceed defined cost threshold)
• Short-term: add tool call count limit and model inference step count limit as hard constraints
• Long-term: implement cost-aware routing (route to cheaper model for steps where frontier capability is not required)

GMI Agentbox Observability: What the Platform Provides

GMI Agentbox provides the operational visibility layer as part of the deployment platform. Teams deploying agents through Agentbox have access to unified tracking without building a separate observability stack from scratch.

Usage tracking. Every agent interaction is tracked from the moment it is initiated. The platform captures session initiations, completion status, active session count, and session duration distribution. This provides the session-level observability baseline without requiring custom instrumentation.

Per-session logs. Session logs capture the input prompt, the agent's final response, session duration, and completion status. For teams building step-level tracing on top of the Agentbox platform, session logs provide the session-level anchors that step traces attach to.

Spend attribution. Session-level cost is computed from the inference calls processed through the Agentbox platform. Spend attribution data identifies which sessions are expensive and how cost distributes across the usage volume. For commercial deployments where customer cost attribution is required, spend data from Agentbox provides the foundation for billing calculations.

Performance metrics. Response latency, session duration, and throughput metrics are available in the Agentbox dashboard. These metrics power the latency-based alerting described in the alert runbooks above.

The four-step operational path on Agentbox: deploy privately to validate behavior on production infrastructure, connect models and compute (compute only, models only, or both), validate and publish to create an Agentbox listing, then operate with the unified dashboard for post-launch observability. The observability layer is step four, but the instrumentation that makes it useful (step-level tracing, cost attribution, tool call logging) should be implemented during step two, not after the first production incident reveals that it was missing.

Conclusion

Agent observability is not an extension of LLM inference observability. It is a different instrumentation problem with different metrics, different alert thresholds, and different runbook structure. The failure modes that matter for agents (stuck loops, cost spikes, context overflow, quality degradation at long context) are invisible to the observability tooling designed for single-turn inference.

Step-level tracing from day one, cost alerting before the first production session, and written runbooks for the three most common failures are the minimum viable observability posture for production agents. GMI Agentbox provides the session-level usage tracking, spend attribution, and performance metrics that form the foundation of this posture. Step-level tracing built on top of the Agentbox platform's session data provides the complete observability stack that production agent operations require.

The team that builds observability before the first incident spends 15 minutes diagnosing a failure with a complete trace. The team that builds it after spends 4 hours correlating fragmented logs and arguing about what might have happened.

FAQs

What is step-level tracing and why is it required for production AI agents? Step-level tracing captures a structured record for every discrete action in an agent's execution: each model inference call, each tool call, each routing decision, each human escalation. Session-level logging records what the user asked and what the agent returned. Step-level tracing records every intermediate action between those two points, including which tool was called at each step, what result it returned, how long it took, and what it cost. Step-level tracing is required for production agents because the failure modes that occur in production (stuck loops, tool call failures that propagate through reasoning, context overflow mid-task, cost spikes from retry loops) are only visible in intermediate execution steps. Session-level logs show that something went wrong. Step-level traces show where and why.

What are the three alerts that should be configured before a production agent goes live? Three alert categories are required before production deployment. First, error rate above baseline: alert when the rolling 5-minute error rate exceeds 2 to 3 times the baseline established during the first week of production. This detects tool integration failures, model provider issues, and code regressions. Second, per-session cost above ceiling: alert when any individual session exceeds 5 times the average session cost. This detects stuck agents, retry loops, and context accumulation patterns before they accumulate into large infrastructure bills. Third, latency p99 above threshold: alert when p99 session duration across the last 100 sessions exceeds the defined threshold for your use case (30 to 60 seconds for interactive agents, longer for batch agents). These three alerts together cover error, cost, and latency failure modes that occur most frequently in production agent deployments.

How should agent cost be attributed in a commercial deployment? Agent cost attribution requires three dimensions. Session-level cost tracks the total cost of each individual session as the sum of all inference calls and tool call costs across all steps. This is the primary signal for detecting runaway sessions. Step-type cost breakdown separates model inference cost from tool call cost within a session, which identifies whether cost drivers are inside the agent's reasoning (inference cost) or in external API calls (tool call cost). User or customer attribution tags each session with a user identifier at creation time and aggregates session costs per user over billing periods. For commercial deployments where cost is passed through to customers or attributed to business units, user-level cost aggregation is required for billing calculations and profitability analysis.

What does GMI Agentbox provide for agent observability out of the box? GMI Agentbox provides four observability capabilities as part of the platform. Usage tracking captures session initiations, completion status, active session count, and session duration distribution without custom instrumentation. Per-session logs record the input, output, duration, and completion status for each agent session. Spend attribution computes session-level cost from inference calls processed through the platform and provides cost distribution data for detecting expensive sessions. Performance metrics cover response latency, session duration, and throughput. These capabilities form the session-level observability foundation. Step-level tracing (which records every intermediate step within a session) is built on top of this foundation by teams that implement step trace logging alongside their Agentbox deployment.

What are the three most common production agent failures and how are they detected? Three failures occur most commonly in production agent deployments. Stuck agents (infinite tool call loops) appear in step-level traces as high step counts above twice the average, repeated calls to the same tool with similar inputs, and sessions still active after three times the expected duration. Context overflow (sessions hitting the model's context window limit) appears as sessions terminating with a context length error, preceded by steadily increasing input token counts across consecutive model inference steps. Cost spikes (sessions costing 5x or more above average) appear in session cost data and are diagnosed by examining the step-type cost breakdown: high model inference cost with many steps indicates a reasoning loop, high tool call count with many errors indicates a retry loop on a failing tool. Each failure has a distinct trace signature that enables diagnosis within minutes when step-level tracing is in place.