Tool Calls Need Their Own SLA

The short version: tool calls need their own SLA. If an agent system relies on search, retrieval, file access, or third-party actions, you cannot judge it by the final answer alone. A strong answer with a slow or unreliable tool layer is still a weak production system.

This is where many teams confuse model quality with workflow quality. They run a few happy-path prompts, like the result, and conclude the agent is ready. But the real product is not just the text the model produces. It is the chain of calls underneath it: how quickly tools respond, how often they time out, how retries are handled, what happens when structured fields are missing, and whether stale data is surfaced with false confidence. Those are service behaviors, not just prompt behaviors.

I like a compact SLA for the tool layer: median latency, worst-case timeout, retry budget, fallback path, and error visibility. If the workflow cannot answer those five questions, it is not mature enough to own serious work yet. This is also why Every AI Workflow Needs an Eval Before a Seat should be read with The Measurement Layer. The eval scores output quality. The SLA tells you whether the workflow remains usable under load, drift, and partial failure.

There is a trust implication too. A connector with a high blast radius and an unknown latency profile is much harder to govern than one with a clean response budget and a visible fallback. That is why the connector map in MCP Adoption Needs a Trust Index should include reliability, not just permissions. A tool that is occasionally wrong in a silent way can be more dangerous than a tool that is visibly limited.

My operating rule is blunt: if a tool call matters to the workflow, put numbers on it. When the team starts measuring the tool layer like infrastructure, it stops being surprised by failures that were already happening in plain sight.