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
The correct answer is B. When a single 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 are not an incident timeline. Portal screenshots every five minutes are not request-scoped tracing.
Full Explanation
Option B is correct. 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.
Option A is incorrect because customer-visible messages omit intermediate tool calls and orchestrator choices that caused the failure.
Option C is incorrect because Advisor cost guidance does not reconstruct per-request agent execution order or tool arguments.
Option D is incorrect because periodic portal screenshots lack request-level correlation and cannot capture prompts or tool payloads for a specific order.