After a production incident, engineers must reconstruct why a supervisor agent approved an incorrect subagent tool call. Logs exist in several microservices, but they cannot link one user session across the orchestrator, tool gateway, and model calls. Which observability design should they implement in Microsoft Foundry?
Select an answer to reveal the explanation.
Short Explanation
Correct answer: B. Multi-agent debugging dies without cross-service glue. You need one correlation ID threaded from the user session through the orchestrator, tool gateway, and model calls, plus Foundry tracing for tokens, prompts, and execution paths. Structured reasoning logs make replay possible so you can see why a supervisor approved a bad tool call. Daily token spreadsheets (A) help finance, not root cause. Portal screenshots (C) are not an observability strategy. Logging API keys (D) is a security failure and does not reconstruct agent decisions. Trace first, then alert on failures and quality drops.
Full Explanation
The correct design specifies observability components required for multi-agent production systems: end-to-end correlation IDs, Foundry tracing of prompts/tokens/execution, and structured logging of agent reasoning for reproducible debugging. Without correlation, logs in separate microservices cannot reconstruct a single session path from supervisor approval to subagent tool call. Option A addresses coarse cost reporting, not incident reconstruction. Option C is ad hoc and non-queryable. Option D is unsafe and out of scope for tracing; secrets must stay in Key Vault, never in logs. Implement alerting on failed workflows and attach the same correlation ID to remediation tickets so on-call engineers can open a full trace.