Litware's platform team must specify observability for a multi-agent loan underwriting system spanning orchestrator, credit-check agent, and document agent across Azure services. Incidents require reconstructing why an agent chose a tool and replaying runs for debugging. Which observability component set should they specify?
Select an answer to reveal the explanation.
Short Explanation
Multi-agent debugging needs more than CPU graphs. You want distributed traces with correlation IDs across orchestrator and specialists, structured logs of reasoning/tool paths, and replay capture so you can reproduce bad runs. That is option D. Platform CPU only (A) misses agent logic. Printf soup (B) will not scale or correlate. One VM free-text log (C) breaks distributed, multi-service reality.
Full Explanation
AI-500 observability components include cross-service trace correlation, structured logging of agent reasoning paths, and agent replay capture. Option D enumerates exactly those capabilities.
Option A is insufficient for agent quality and decision debugging.
Option B lacks structure, correlation, retention controls, and production operability.
Option C fails in multi-service Azure deployments and prevents joining events across agents.
In Microsoft Foundry and Azure Monitor/Application Insights ecosystems, propagate correlation IDs through orchestrator → subagent → tool calls, log tool names/arguments/results (with redaction), and store replayable run artifacts for offline analysis.
Exam tip: If the stem mentions reconstructing decisions across services, choose tracing + structured reasoning logs + replay.