A Tool Call Cannot Spend the Whole Deadline Again

A Deadline Follows the Request

BOTIE

A service can call another service, which calls a third. If each starts a fresh timeout, the complete request may take much longer than its caller agreed to wait. Work can also continue consuming resources after the caller has given up.

In a 2018 gRPC article, Google site reliability engineer Gráinne Sheerin explained why clients should set deadlines deliberately. gRPC is a framework for calling procedures in another process across a network. Its deadline support lets the caller put a time boundary on that work, and implementations can propagate the remaining allowance to downstream calls. The allowance shrinks as work happens; another service does not receive a fresh budget simply because it started later.

An agent making several tool calls has the same dependency. We will calculate what remains before starting the next call. Cancelling a request still requires cooperation from the work it started, especially if an external action may already have happened.

Sources for this history

Every Tool Timed Out Correctly. The Answer Was Still Late.

Botie has a deadline for answering a technician. Retrieval uses most of it, then a second tool receives the original timeout again. Each service obeys its local setting, but the overall run exceeds the technician’s budget.

The next call needs the time remaining in this run. We should also reserve enough time to assemble and return the answer.

This computes an allowance. It does not cancel network work or reverse external effects.

Step 1 of 1

The run has one overall budget

Elapsed time has already been spent.

Only 200 ms remain for another tool call.
Budget item	Milliseconds
Run budget	1000
Already elapsed	700
Response reserve	100

Run budget
Milliseconds
1000
Already elapsed
Milliseconds
700
Response reserve
Milliseconds
100

Only 200 ms remain for another tool call.

A timeout is local; a deadline names the endpoint

The clamp represents the decision not to allocate negative time.

Pass the remaining budget to the next tool

The next tool must not restart Botie’s overall timer.

BOTIE

The next tool must not restart Botie’s overall timer.

Choose an example

Total budget in ms

Elapsed time in ms

Response reserve in ms

Remaining tool-call allowance

Follow the operations

1. Total budget in ms
```
1000
```
2. Elapsed time in ms
```
700
```
3. Subtract
```
300
```
4. Response reserve in ms
```
100
```
5. Subtract
```
200
```
6. Keep positive values
```
200
```
7. Result
```
200
```

This computes an allowance. It does not cancel network work or reverse external effects.

1. A timeout is local; a deadline names the endpoint

A timeout says how long a particular operation may wait. A deadline says when the overall result stops being useful. Before each downstream operation, compute what remains.

Across machines, propagate a supported relative timeout or protocol deadline rather than comparing unsynchronised wall clocks yourself.

Reserve time for serialisation and returning the response. That reserve should come from measurements, not wishful thinking.

2. Stop when no allowance remains

Subtract elapsed time and the response reserve from the total budget, then clamp at zero.

remaining = max(0, 1000 - 700 - 100) = 200 ms
after 950 ms elapsed:
remaining = max(0, 1000 - 950 - 100) = 0 ms

A zero allowance means do not start another ordinary tool call. It does not mean an instantaneous call will somehow complete.

The reserve is already spoken for

A raw remainder can be negative, which is a reason to stop allocating new work.

Python

budget, elapsed, reserve = 1000, 950, 100
print(budget-elapsed-reserve)

Output

-50

The negative value is not a valid network timeout. The caller must clamp the allowance and choose its terminal response.

Check yourself

Where does the remaining time come from?

Question 1 of 2

What remains for a tool?

Use the information below.

Budget 1000, elapsed 700, reserve 100 ms.

3. Cancellation does not undo an action

A timeout may occur after a service committed an external effect. Retrying a write requires an idempotency or reconciliation design. Cancelling a local task cannot recall an email already sent.

Propagate cancellation to work you control, release resources, and record uncertain outcomes explicitly.

The agent retry and side-effect lessons cover effect recovery. Here we restrict the amount of time new work can consume.

4. Observe where the budget went

Record elapsed stages and cancellation reasons alongside a run identifier. Distinguish waiting for a worker from execution and network delay. Avoid putting private prompts into every timing log.

Test a run that has already exceeded its deadline and one exactly on the reserve boundary.

A remaining-time calculator is one component. Enforcing it requires the caller and every relevant downstream service to cooperate.