A multi-agent booking solution has a contractual SLA: 99.9% successful completion of the booking workflow within 45 seconds for interactive sessions. Platform CPU is healthy, but customers report timeouts when the orchestrator waits on a slow third-party MCP tool. What monitoring design addresses SLA adherence?
Select an answer to reveal the explanation.
Short Explanation
B is right. SLA monitoring for multi-agent solutions is about solution-level availability, performance, reliability, and adherence—not just VM health. You need workflow success ratio and E2E latency with per-agent/per-tool spans so a slow MCP dependency shows up in error-budget burn. CPU-only green dashboards miss user pain. Tokens-per-second is not the booking SLA. Third-party tools still count toward customer-facing SLA unless the contract excludes them—and you still must monitor them. Instrument the orchestration path end to end.
Full Explanation
Correct Answer — B
You must design monitoring for solution and platform availability, performance, reliability, and SLA adherence. Contractual workflow SLAs require end-to-end success and latency metrics with span-level breakdowns (agents and tools), plus alerting on error-budget burn—even when host metrics are healthy.
Why A is wrong: Infrastructure metrics can be green while workflow SLA is red due to tool waits.
Why C is wrong: Model throughput is not the same as booking completion within 45 seconds.
Why D is wrong: Dependencies that block the workflow affect customer SLA and must be monitored.
Exam tip: Multi-agent SLA = workflow success + E2E latency, not CPU alone.