AI Agent Time Limits: Deadlines, Timeouts and Expiry

Give an AI agent a deadline for the useful result, then budget the work inside it. A tool timeout limits how long one caller waits. An expired credential limits access. Increasing one of those durations does not necessarily give the task more time or permission.

The reference below names sixteen clocks that can appear in a workflow. It is a vocabulary for builders and buyers to use when setting expectations. The selected cases are editorial design examples; a particular application may expose only some of them.

Read the first column as a planning question. The groups describe what is limited, not how serious an expiry is. A temporary file may be more consequential than a request timeout if it contains the only copy of a deliverable. Set durations from the task and the system’s documented behavior.

gRPC’s deadline guide distinguishes a deadline expressed as a point in time from a timeout expressed as a duration. Its propagation guidance accounts for time already spent before passing a remaining timeout downstream. That supports budgeting across stages, rather than giving every stage a fresh full allowance.

RFC 6749, section 5.1 defines expires_in as an access token’s lifetime in seconds. Token validity therefore answers an access question. It does not say how long a user wants an agent to work, or whether an earlier request succeeded.

The table extends those distinctions into an original planning reference. Queue policy, lease behavior and retention rules depend on the application; neither cited source defines every row. Inspect the relevant contract before converting a row into a configuration setting.

Consider a hypothetical research brief needed before a scheduled discussion. The agent needs time to find sources, resolve conflicting dates, write the brief and expose unresolved claims. A run that spends the entire allowance searching has missed the practical deadline even if its process exits on time.

Work backward from the moment the result must be usable. Reserve the final review and delivery period first, then allocate the remaining time to research and drafting. If source retrieval consumes more than expected, reduce optional coverage before removing verification of the central claim.

Do not choose a universal percentage for every stage. A short formatting task and a source-heavy report have different needs. Use observed runs to improve the allocation, while keeping the owner’s outer deadline unchanged unless they explicitly revise it.

A useful expiry report contains the named clock, the work already verified, the unresolved operation and the next safe check. For a remote action, distinguish “the client stopped waiting” from “the server rejected the operation.” The first statement alone cannot justify repeating a write.

A running job may also depend on an expiring download or a short-lived session. Record those dependencies before the agent begins a long stage. Downloading a result before its retention ends is different from requesting more execution time.

Our safe cancellation guide covers stopping background work. The tool-error decision reference covers what to do with a failure response. Use this table earlier, when deciding which limit should have existed in the first place.

For each relevant clock, write down its owner, start event, duration or absolute deadline, reset behavior and expiry consequence. Include whether it is enforced by your application or merely stated in a prompt. A model instruction is not a runtime control.

Then walk through a delayed start, a slow dependency and an interrupted result lookup. Check whether downstream stages inherit the time actually remaining. Distinguish a task that has become useless from a cleanup action still required to settle its state.

If the question is whether the model may continue while a tool runs, use the slow tool-call comparison . Concurrency can improve scheduling, but it does not define the business deadline.