A permitting-office Bedrock agent calls a Lambda tool to check permit status, and the tool intermittently times out, causing the agent to return incomplete answers to applicants. Which monitoring approach directly surfaces this coordination problem?
Select an answer to reveal the explanation.
Short Explanation
An agent handing work off to a tool is a lot like a relay race; if the baton drop happens mid-handoff, the finish-line clock won't tell you which runner fumbled it. Monitoring built for agent tool invocations watches that specific handoff, tracking the Lambda tool's timeout and failure rate directly. That's what turns 'answers feel incomplete sometimes' into a specific, fixable signal.
Full Explanation
Tool-invocation monitoring tracks the outcome of each call the agent makes to its Lambda tool, success, failure, timeout, and latency, which pinpoints exactly where the coordination breaks down between the agent's reasoning and the external system it depends on. Token-consumption dashboards describe how much the foundation model is being used, a cost and usage signal, not a signal about whether a downstream tool call succeeded. A load-balancer 5xx alarm catches failures visible at the HTTP layer of the overall application, and a Lambda timeout inside an agent's tool call may not surface as an HTTP 5xx if the agent catches it and returns a degraded answer instead. A weekly success-count report aggregates too coarsely and too slowly to catch an intermittent timeout pattern that applicants are experiencing right now. Scope caveat: tool-invocation monitoring tells you a call failed, but diagnosing why the Lambda tool times out, cold starts, downstream API latency, throttling, still requires digging into that Lambda function's own logs and metrics. A concrete operational check: graph the tool's timeout rate against the agent's overall incomplete-answer rate to confirm they move together before prioritizing a Lambda-side fix.