Architects must specify observability so on-call engineers can reconstruct why five agents produced a wrong refund decision. Which observability components should be included?
Select an answer to reveal the explanation.
Short Explanation
When five agents touch a refund, you need a flight recorder: shared correlation IDs, structured logs of reasoning and tool paths, and replay capture. Node CPU charts alone won't explain a bad decision.
Full Explanation
Technology component specification includes observability: cross-service trace correlation with shared correlation IDs, structured logging of agent reasoning and tool paths, and agent replay capture for reproducible debugging, plus metrics for failures and latency. The option specifying those components supports multi-agent incident response and reconstructs why five agents produced a wrong refund decision. The option with only CPU and memory metrics on Kubernetes nodes is insufficient because infrastructure metrics lack agent reasoning and tool-level causality. The option relying on manual Foundry portal screenshots after each incident is not systematic or scalable observability. The option disabling production logs to reduce token costs and privacy risk, relying on customer complaints, undermines reliability and auditability. Exam tip: Multi-agent observability answers should mention correlation IDs, reasoning/tool logs, and replay—not only host metrics.