A courts docket-summarization agent occasionally fails to retrieve case details from a case-management API tool, and staff need automated alerting when this tool-call failure rate rises. What should the team configure?
Select an answer to reveal the explanation.
Short Explanation
When an agent's problem is specifically 'the tool it calls sometimes fails,' the fix isn't a general health check; it's watching that one handoff directly. Monitoring scoped to the agent's tool-invocation calls tracks the case-management API's failure rate as its own signal, separate from everything else the agent does. That's what turns intermittent, hard-to-pin-down failures into something staff can alert on.
Full Explanation
Tool-invocation monitoring isolates the specific call the agent makes to the case-management API as its own tracked event, capturing success rate, failure rate, and latency independent of the rest of the agent's behavior, exactly the granularity needed to catch and alert on this intermittent tool failure. Overall foundation-model response latency measures how quickly the model generates text, but a tool call failing or timing out is a separate dependency the model latency metric doesn't capture on its own. A daily summary-count dashboard shows throughput, not failure detail, and a failed tool call the agent quietly works around might not even reduce the summary count, hiding the problem entirely. A quarterly system-prompt review is a periodic governance check on the agent's instructions, unrelated to whether an external API dependency is failing on a given day. Scope caveat: tool-invocation monitoring flags that the call failed, but diagnosing why, API throttling, network issues, case-management system downtime, still requires looking at that system's own logs. A concrete operational check: confirm the alert threshold accounts for the case-management API's normal baseline error rate, so routine noise doesn't trigger constant paging.