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
Logging every reasoning step, tool call, and decision at one level buries you in noise. You need structured, leveled tracing so you can filter to WARN or ERROR during incidents and turn on DEBUG only when digging into a specific trace.
Full Explanation
The missing design was a structured, leveled tracing system where different categories of events are logged at different severity levels (DEBUG, INFO, WARN, ERROR), allowing operators to filter to relevant information without wading through verbose debug output. Leveled, structured tracing 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, such as every reasoning step and full tool call inputs and outputs. It should be enabled only in development or when diagnosing a specific problem. - INFO: normal operational events, such as task started, task completed, tool invoked, and result summary. It should always be on in production. - WARN: unexpected but recoverable conditions, such as a tool call retried, a partial result used, or context truncated. - ERROR: failures that require attention, such as a tool call failed after all retries, a task failed, or escalation was 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, such as JSON format with typed fields rather than unstructured strings, enables fast filtering and searching even in high-volume streams.
The proposal to log only errors and suppress all non-error output 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.
The proposal to redesign the agent to make fewer tool calls addresses agent efficiency, not observability. Reducing log volume by reducing agent capability is the wrong trade-off.
The proposal to purchase a larger log storage solution 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.