After a failed multi-agent checkout flow, support engineers can see each microservice log stream but cannot reconstruct which orchestrator decision led which subagent to call which payment tool for that one customer order. What observability design should they implement in Foundry and related services?
Select an answer to reveal the explanation.
Short Explanation
When one order fans out across an orchestrator, subagents, models, and tools, you need one correlation ID threading the whole path plus structured spans that keep prompts, tokens, and tool payloads so you can replay what happened. Final-message-only logs hide the decision trail. Cost recommendations and periodic portal screenshots aren't request-scoped tracing.
Full Explanation
The correct design is to propagate a single correlation identifier across the orchestrator, subagents, model calls, and tool invocations, and to capture structured traces including prompts, token usage, and tool payloads needed for replayable debugging. Foundry multi-agent observability requires cross-service trace correlation and structured logging of agent reasoning paths, including tokens, prompts, correlation IDs, and execution tracking. That combination lets engineers reconstruct one order's path across independent invocations and support reproducible debugging or replay. Logging only final customer-visible messages is wrong because customer-visible messages omit intermediate tool calls and orchestrator choices that caused the failure. Relying exclusively on Azure Advisor cost recommendations as the incident timeline is wrong because Advisor cost guidance does not reconstruct per-request agent execution order or tool arguments. Storing screenshots of the Azure portal metrics blade for each agent at five-minute intervals is wrong because periodic portal screenshots lack request-level correlation and cannot capture prompts or tool payloads for a specific order.