An agent logs every reasoning step, every tool call input and output, and every intermediate decision at the same log level. After one week, the log volume has reached 50 GB and the team cannot find relevant failure information quickly during incidents. Searching the logs during a production incident takes 20 minutes. What tracing design was missing?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Logging everything at the same level is like putting every text message, email, and meeting note in a single unsorted pile — by week two, finding anything useful is archaeology. Structured leveled logging lets operators see only ERROR during incidents, see INFO for monitoring, and see DEBUG only when deep-diving a specific issue.
Full explanation below image
Full Explanation
Leveled, structured logging is a fundamental observability practice that is especially important in agentic systems, which generate high volumes of events across reasoning, tool calls, and decisions.
The standard levels and their appropriate use cases are: - DEBUG: granular step-by-step traces (every reasoning step, full tool call inputs/outputs). Only enabled in development or when diagnosing a specific problem. - INFO: normal operational events (task started, task completed, tool invoked, result summary). Always on in production. - WARN: unexpected but recoverable conditions (tool call retried, partial result used, context truncated). - ERROR: failures that require attention (tool call failed after all retries, task failed, escalation triggered).
During a production incident, operators set the log filter to WARN or ERROR, immediately surfacing only the events that matter. When diagnosing a specific task, DEBUG can be enabled for that task's trace without polluting the entire log stream.
Structured logging (JSON format with typed fields rather than unstructured strings) enables fast filtering and searching even in high-volume streams.
Option A (log only errors) would lose the operational visibility that INFO and WARN levels provide. Without INFO logs, there is no way to understand normal agent behavior or detect when behavior deviates.
Option C (fewer tool calls) addresses agent efficiency, not observability. Reducing log volume by reducing agent capability is the wrong trade-off.
Option D (larger storage) does not help with search speed or incident response time. More storage accommodates more volume but does not make the relevant events easier to find.