Northwind’s multi-agent underwriting system fails intermittently when three specialist agents collaborate. Engineers need to reconstruct which agent reasoned what, which tools ran, and how tokens were consumed across services. Which observability components should the architect specify?
Select an answer to reveal the explanation.
Short Explanation
D is what production multi-agent observability looks like. You need distributed trace correlation so a single request can be followed across orchestrator, agents, tools, and model calls; structured logs of reasoning/tool paths; token and prompt telemetry; and replay capture so failures are reproducible. CPU charts alone won’t explain a bad tool choice. Screenshots aren’t traces. Turning off production tracing guarantees blind spots. For AI-500, specify observability that supports reliability monitoring, quality debugging, and Foundry-style execution tracking—not just infrastructure metrics.
Full Explanation
D is correct because multi-agent architectures should include observability components for cross-service trace correlation, structured logging of agent reasoning paths, and agent replay capture for reproducible debugging, plus token/prompt and execution tracking. A is incorrect: host CPU metrics do not reveal reasoning errors, tool failures, or coordination bugs. B is incorrect: UI screenshots lack correlation IDs, spans, and structured tool results. C is incorrect: production-only failures require production telemetry; disabling traces increases mean time to recovery. Design correlation IDs that flow through orchestrator → agents → MCP/tools → model endpoints, and retain replay artifacts under access control.