Every agentic framework ships with clean mental models for single tool calls. The tool returns success, failure, or a partial result. The agent handles the response. Straight line.
Then someone asks the agent to “research the latest pricing, draft a proposal, send it to three people, and schedule a follow-up.” Six tool calls. Maybe eight. The mental model doesn’t change — it just repeats. And that’s where things break.
Not because individual tools are unreliable. Because their failure modes interact.
The Multiplication Problem
A single HTTP call with 99% reliability sounds fine. Chain five of them and you’re at 95. Chain ten and you’re at 90. Chain twenty and the probability of a clean run drops below 82%. This is basic probability, but it matters because most agent frameworks treat each tool call as an isolated event. They retry on failure. They don’t model the compound risk that a silent failure in call three corrupts the inputs to calls four through twenty.
The failure isn’t at the end of the chain. It’s in the middle, where nobody sees it because every subsequent call returns 200 OK. The agent drafted a proposal with stale pricing data, sent it to the wrong contacts, and booked a meeting in a calendar it shouldn’t have had write access to. Every tool call succeeded. The workflow failed.
This is the first emergent failure mode: silent state drift. Tool A returns a result. Tool B consumes it. But the result from A was cached, truncated, or served from a degraded backend that didn’t signal degradation. B has no way to know. The agent’s chain-of-thought assumes the data is fresh because the tool said “success.”
The Credential Cascade
Here’s a less obvious problem. Each tool call carries credentials. When an agent chains calls across different services, the credential surface multiplies. The agent authenticates to a search API, then to a document editor, then to a calendar service, then to an email gateway. Four credential boundaries in one workflow.
If any single credential is compromised, the blast radius is bounded. If all four are presented by the same agent identity in a single session, the effective attack surface is the union of all four permissions. A compromised search token is a privacy leak. A compromised email token is a spoofing vector. When the agent holds both, a single injection attack that tricks the agent into exfiltrating the search results also gives the attacker a template for crafting emails that appear to come from the agent’s identity.
The tools don’t know about each other. The framework treats them as independent. They’re not. They share an execution context, an identity, and a failure cascade path.
The Composition Blind Spot
Most tool schemas are written for direct human use. The error messages assume a human is reading them. “Rate limit exceeded” makes sense to a developer. It means nothing to an agent that’s halfway through a 12-step workflow and has already committed state changes in steps one through four.
This creates what I’d call the composition blind spot: each tool’s error handling is optimized for the human-in-the-loop case, but the agent is running headless. When call seven fails with a generic 400, the agent has two choices — retry blindly (risking amplification) or abort (losing all prior work). Neither is good.
The real problem is that tool schemas don’t encode rollback semantics. A database transaction knows how to undo itself. An HTTP POST to a SaaS API doesn’t. When an agent orchestrates five non-transactional writes and the sixth fails, the workflow is in a state that no single tool understands and no framework can automatically recover from.
What’s Missing
Three things would help, none of which exist in most agentic frameworks today.
First, compound health signals. Instead of each tool reporting its own status, the framework should track a composite reliability score across the active tool chain. If the calendar API is showing elevated latency and the email gateway is returning intermittent 503s, the agent should know before starting a workflow that depends on both.
Second, declarative rollback. Tool definitions should include an undo contract: “If this call succeeds, here’s how to reverse it.” Not every operation is reversible, but many are, and the information should travel with the tool schema, not live in the agent’s ad-hoc logic.
Third, credential isolation. Agents should not present the full union of their permissions on every call. The search tool should get search credentials. The email tool should get email credentials. If the agent’s reasoning is compromised mid-workflow, the blast radius should shrink to the current tool’s scope, not the entire session’s authority.
The Honest Part
This isn’t a call to stop using tool chaining. It works remarkably well for short, well-defined tasks. The problem is the gap between what works in demos (three tool calls, happy path) and what breaks in production (fifteen calls, one degraded service, no rollback).
The framework designers know this. The tool authors know this. What’s missing is a shared language for talking about it. Right now, when an agent fails in a multi-tool workflow, the postmortem reads like a Rorschach test: the search team blames the calendar integration, the calendar team blames the email gateway, and the framework team says the agent should have handled the error better. Everyone’s right. Nobody’s solving it.
The compound risk surface isn’t a bug. It’s the shape of the problem. And until we design for it explicitly, agents will keep succeeding at every individual step while quietly producing the wrong outcome.