A team starts with two agents and observes them effectively using structured logs per agent. They then scale to 20 agents across five repositories. Which observability design change is MOST critical to maintain diagnostic capability at 20-agent scale?
Select an answer to reveal the explanation.
Short Explanation and Infographic
At 2 agents it's like following two people through a mall — easy. At 20 agents running concurrently across 5 repos, without a shared trace ID it's like trying to reconstruct one person's path from 20 different surveillance cameras with no timestamps that match. Distributed trace IDs are the thread that stitches one workflow's events together across all agents, enabling root-cause analysis when something goes wrong mid-chain.
Full explanation below image
Full Explanation
Observability design must scale with the complexity of agent coordination, not just the count of individual agents. The shift from 2 to 20 agents introduces concurrency, multi-repo spans, and cascading dependencies that make per-agent logs insufficient.
Option A (longer retention) addresses storage duration, not diagnostic capability. You can retain logs for a year and still be unable to correlate a failure in Agent 14 with the upstream context provided by Agent 3 if those logs have no shared identifier.
Option B is correct. A distributed trace ID — sometimes called a workflow ID or correlation ID — is injected at the point where a workflow begins (e.g., a GitHub event trigger) and propagated to every agent invocation, tool call, and sub-task within that workflow. This enables engineers to filter all observability systems (logs, metrics, traces) by a single ID and reconstruct the complete causal chain: which agent received what input, what it decided, what tools it called, what it produced, and how that output flowed to the next agent. Without this, debugging a failure at Agent 17 in a 20-agent chain requires manually correlating timestamps across 17 separate log streams — an exponentially hard problem.
Option C (dedicated runners) prevents log interleaving within a single runner but does not address cross-agent correlation. You would still have 20 clean but disconnected log streams.
Option D (per-agent dashboards) improves individual agent visibility but creates the inverse problem: it makes it easy to see each agent in isolation but impossible to see the cross-agent workflow as a whole. When a downstream failure needs to be traced to an upstream agent, siloed dashboards actively hinder diagnosis.