A developer is debugging an agent that occasionally generates incorrect test fixtures. The agent runs inside a CI pipeline and the developer cannot interactively prompt it. Which configuration produces the MOST useful inspectable artifacts for diagnosing the root cause?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A black box that only shows its final answer is almost impossible to debug — you need the receipts. A structured trace artifact is like a flight data recorder for your agent: full prompt context, every tool call with its inputs and outputs, intermediate reasoning steps, and schema validation results, all stored and versioned. When a test fixture comes out wrong, you can trace exactly where the reasoning diverged without re-running anything.
Full explanation below image
Full Explanation
Producing inspectable artifacts in standard development tooling means writing durable, structured, versioned outputs from every agent run that can be examined after the fact — particularly important in CI environments where there is no interactive debugging session.
Option B is correct. A structured trace artifact provides the full diagnostic context needed to identify root causes: (1) the full prompt context shows whether the input was well-formed or contained unexpected data; (2) the tool call sequence with inputs and outputs reveals whether the agent called the right tools in the right order and whether tool responses were valid; (3) intermediate reasoning steps (e.g., chain-of-thought or planning steps) show where the agent's logic diverged from expected behavior; (4) the final output alongside a schema validation result immediately indicates whether the fixture was malformed structurally vs. semantically incorrect. Storing this in a versioned artifact store (e.g., GitHub Actions artifacts, S3 with run metadata) means it can be compared across runs to identify regressions.
Option A (stdout log stream) provides some visibility but has significant limitations: unstructured text is hard to query or diff across runs, stdout is ephemeral in many CI systems, and log verbosity without structure makes it hard to isolate specific tool calls or reasoning steps from surrounding noise.
Option C (email last response) captures only the final output, not the reasoning path. It provides no context about tool calls, intermediate steps, or prompt context — the three most likely locations of a bug. It also introduces out-of-band communication rather than keeping artifacts in the development pipeline.
Option D (re-run locally) is a debugging approach, not an artifact configuration. It requires the developer to reproduce the failure, which may not be deterministic (agent behavior can vary by run), and it does not address the root cause of poor instrumentation. The correct fix is to instrument the agent properly so that CI runs are self-documenting.
The exam objective is: 'Configure agent to produce inspectable artifacts within standard development tooling.' The canonical pattern is a structured trace artifact written to a versioned store on every run.