Mehdi Akiki
Published on

Give Every Agent Tool Call a Deadline

Authors
  • Mehdi Akiki avatar
    Name
    Mehdi Akiki
    Twitter

Reference · Interrupted execution

When an agent calls a tool, it stops and waits for the answer.

Most of the time the tool is fast, so you never think about it. Then one day the tool is slow. A network call hangs, a database is busy, another service is down. The tool does not come back, so your agent does not come back either. The user is still waiting, looking at nothing.

A tool you call is a dependency you do not control. And in an agent, every tool call sits on the hot path: the line between the user's message and the answer. If the tool hangs, the turn hangs.

The naive version

You await the tool and trust it to return.

const result = await tool.run(args) // waits as long as the tool wants

This is fine in the demo, because the demo tool is fast. It breaks in production, on the slowest day, for the most important user. In orchestration it is worse: if one agent waits on a tool, and another agent waits on that agent, a single slow tool deep in the tree freezes the whole thing.

This is the failure that keeps showing up in 2026. Studies of multi-agent systems find that most failures come from the orchestration around the model, not the model itself (MAST, 2025), and a tool call you cannot bound is a classic example. It is also why durable, async execution for agents (Temporal, DBOS, Google's ADK) is having a moment.

The single fix

Give every tool call a deadline, and decide what happens when the deadline passes.

const result = await withTimeout(tool.run(args), 3000) // 3s, then stop waiting

A slow tool is a failed tool, from the point of view of a person who is waiting. So treat the timeout like any other failure: answer with what you already have, say the rest is pending, or hand the tool work to the background and report back later. Whatever you choose, the hot path is free again at the deadline, no matter what the tool decides to do.

One thing to be careful about

A timeout does not mean the tool did nothing. For a tool that only reads, this is fine. For a tool that writes, sends, or charges, the work may still go through after you stopped waiting. Those tools must be safe to retry (an idempotency key) and reconciled later, not just timed out and forgotten.

So pick a deadline per tool. A quick read gets a short one. A heavy action probably does not belong on the hot path at all.


Related: What an Idempotency Key Is · How to Keep Two Systems in Sync