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.

Use this reference to identify the clocks your workflow actually exposes, who controls them and what expiry means. It is a planning vocabulary, with durations left to the task and the documented system behavior.

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.

gRPC’s deadline guide (read September 9, 2026) documents an important default: no deadline is set automatically. When an explicit deadline expires, the client stops waiting and the RPC is cancelled on the server, but the server application remains responsible for stopping activity it spawned. Ending the wait is therefore a separate check from ending the work.

For an agent calling such a service, record the client deadline and how the server notices cancellation and stops child work. Reserve time to report or reconcile an unresolved result before the business deadline; do not give a retry the original full allowance.

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.

Scope. Task budgets, waiting limits, resource validity and recovery windows.

As-of date. September 7, 2026. This is the actual source collection and review date; the article is dated September 6.

Collection. Read gRPC deadline guidance and RFC 6749 section 5.1. Select distinct clocks encountered in task planning, waiting, resource access and recovery. Assign each case to the thing its clock directly controls; record the required evidence, without assigning universal durations.

Sources and interpretation. gRPC documents deadlines, remaining-time propagation and responsibility for spawned work. RFC 6749 defines token lifetime. Queue, lease and business-deadline rows are editorial planning cases.

Exclusions. No vendor census, model benchmark, search-volume estimate or observed failure rate. Examples are hypothetical; no customer operations were tested.

Gaps and limitations. UNVERIFIED means the supporting evidence has not been inspected. Similar cases can overlap in practice; classify the particular claim or operation, and retain uncertainty when the distinction cannot be established.

Refresh. Review when source guidance or the classification changes.

The table separates clocks by what each one controls because they are easily swapped. The illustrative workflows below each treat one clock as if it were another. They are patterns the rows describe, not observed runs.

Each confusion is resolved by the first column of the table: name what the clock controls before changing its duration or acting on its expiry.

The budget section asks for verification and delivery time to be reserved, and the clean way to do that is to plan from the business deadline backwards rather than from the first stage forwards. Start with the delivery time, time zone and minimum useful outcome, which the task-budget rows ask to be recorded. Reserve the time to check the result and deliver it, and the time to report or reconcile an unresolved operation if a stage ends badly. What remains is the execution budget, and it is divided across stages with only the time remaining passed to each next stage, which is the propagation behavior gRPC documents.

An illustrative budget for a report due at a stated hour: reserve the final portion for opening the delivered file and reconciling any export that did not confirm; give the research and drafting stages the rest, with each stage receiving the remaining time rather than a fresh allowance; and list beside the plan the clocks that are not budget at all, such as the lifetime of the access token and the retention period of an intermediate download, each with its owner and expiry consequence. The durations are the task’s to set; the structure is what the table supplies.

The budget is also where the clock record from the apply section lives. Each clock gets its owner, start event, duration or absolute deadline, reset behavior and consequence, with a note of whether the application enforces it or a prompt merely states it. Walk the plan through a delayed start, a slow dependency and an interrupted lookup, as the apply section asks, and check that every downstream stage still inherits the time actually remaining.

Take one workflow with a real delivery time and write its budget backwards, reserving the checking and delivery time first. The stages that turn out to have no remaining time are the ones currently borrowing it from verification.