Deadline Propagation for AI Agents: Make Every Tool Know When Time Is Up

The user gives an agent 30 seconds. The planner spends 18 seconds thinking, retrieval uses 10, and a payment tool begins with two seconds left. The user sees a timeout. The payment completes anyway. The agent retries on the next run.

This is how a latency bug becomes a duplicate charge.

A timeout at the HTTP gateway does not control the work beneath it. Deadline propagation gives every model call, tool, queue, and retry the same view of how much useful time remains.

Send an Absolute Deadline Down the Tree

Represent the limit as an absolute timestamp plus a monotonic local budget. Relative timeouts accumulate drift as requests cross processes and queues. An absolute deadline lets each component calculate remaining time when work actually begins.

At every boundary, derive a smaller child budget:

child deadline = min(parent deadline - reserve, local maximum)

The reserve covers response serialization, state persistence, compensation, and a truthful final status. A component should reject work immediately when the remaining budget cannot cover its minimum useful execution time.

Propagate the deadline through trace context, queue metadata, tool-call envelopes, and provider-specific timeout settings. Log both the inherited deadline and the effective local timeout. This makes it possible to distinguish a slow dependency from a call that started too late.

Clock skew matters across machines. Translate incoming absolute deadlines into a local monotonic duration at the service edge, and cap unreasonable values.

Budget the Plan, Not Only Individual Calls

Agents create dynamic call graphs, so static per-tool timeouts are insufficient. The planner needs a budget policy.

Reserve capacity for required steps first. If the user asks to retrieve a record, transform it, obtain confirmation, and submit it, do not spend 90% of the budget on retrieval. Allocate expected and maximum durations by stage, then revise after each observation.

Parallel calls share wall-clock time but consume connection, token, and provider quotas. Start only branches whose results can still influence the answer. Cancel speculative work as soon as another branch makes it irrelevant.

Retries must fit inside the original deadline. Before retrying, include backoff, expected service time, and cleanup reserve. A retry that cannot finish before the deadline is load without value.

Use jitter to prevent synchronized retry storms. Keep retry ownership at one layer; nested retries multiply attempts invisibly.

Make Cancellation Cooperative

Cancellation is a signal, not time travel. Pass an abort token through the runtime and require adapters to check it before expensive work, between pages, and before mutation.

For read-only calls, abandoning a late response may be enough. Mutations require stronger semantics. Use idempotency keys, transactional boundaries, and operation-status endpoints. If a timeout occurs after a provider accepted the request, the state is unknown, not failed.

Persist the operation ID and reconcile later. The final answer should say that completion is unconfirmed and should not invite an automatic duplicate attempt.

Some providers do not support cancellation. Mark those tools as non-cancellable and account for that in planning. Do not place a non-cancellable, high-impact mutation at the edge of the deadline.

Test Deadline Behavior Under Load

Inject delay before a request, during processing, after mutation, and during response delivery. Verify the agent’s behavior in each phase. The last case is the most important because the effect may exist even though the caller never saw confirmation.

Track deadline-exceeded counts by stage, work started with insufficient budget, cancellation latency, orphaned operations, retry attempts, and unknown outcomes. Trace visualizations should show the parent deadline alongside every child span.

Set service-level objectives for useful completion, not merely gateway response time. A fast 202 Accepted that leaves an untracked job is not reliable completion.

Deadlines turn patience into distributed data. When every component receives that data, the agent can stop starting doomed work, protect cleanup time, and describe ambiguous outcomes honestly. Without propagation, the top-level timeout is only the moment the user stops watching.