# AI Agent Time Limits: Deadlines, Timeouts and Expiry > Source: > Published: 2026-09-06 00:00:00+00:00 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. 1. 01Name the boundary.Record what the clock controls, when it starts and whether activity resets it. 2. 02Spend one task budget.Queueing, research, tool execution and verification all consume elapsed time. 3. 03Keep outcome separate.A caller that stopped waiting has not established whether the remote action completed. ## 01 — Identify the clock before changing itIdentify the clock before changing it 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. | Digital Applied editorial classification; as of September 7, 2026. Primary-source boundaries are explained below. | | | |---|---|---| | Clock and group | What ends | Planning consequence | |---|---|---| | Task budget: Business deadline | Usefulness of the requested result | Record the delivery time, time zone and minimum useful outcome. | | Task budget: Whole-run limit | Authorized execution time for this run | Budget all stages together; leave time to verify and report. | | Task budget: Stage allocation | Time assigned to one part of the task | A research stage must not silently consume the delivery stage. | | Task budget: Review cutoff | Time reserved for an owner to inspect work | Deliver a reviewable draft before the final deadline. | | Waiting: Connection timeout | Wait to establish a connection | Distinguish connection failure from work accepted by a server. | | Waiting: Response timeout | Wait for the requested response | Treat the operation outcome separately from the client wait. | | Waiting: Idle timeout | Allowed interval without activity | Identify what resets the clock; activity does not necessarily indicate useful progress. | | Waiting: Queue wait limit | Time allowed before execution starts | Include queue delay when calculating the remaining task budget. | | Validity: Access-token expiry | Lifetime of an access credential | Refresh only through an already authorized mechanism. | | Validity: Session expiry | Validity of the authenticated session | Re-establish the required session before dependent work. | | Validity: Temporary-file expiry | Availability of an intermediate artifact | Save needed outputs durably before their documented removal. | | Validity: Work-lease expiry | A worker’s time-limited ownership claim | Check current ownership before allowing further writes. | | Recovery: Retry window | Period in which another attempt is permitted | Recompute the remaining budget; a retry does not restart the task clock. | | Recovery: Status polling window | Period during which a job can be observed | Persist its identifier and plan how to recover the final state. | | Recovery: Result retention | Period a completed result remains retrievable | Retrieve and retain required evidence while it is available. | | Recovery: Cleanup allowance | Reserved time for settling unfinished work | Plan cleanup separately from useful task execution; verify its scope. | ## 02 — What the primary sources establishWhat the primary sources establish [gRPC’s deadline guide](https://grpc.io/docs/guides/deadlines/) 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](https://www.rfc-editor.org/rfc/rfc6749.html#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. ## 03 — Reserve time for checking and deliveryReserve time for checking and delivery 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. ## 04 — Describe what happened when time ran outDescribe what happened when time ran out 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](/blog/stop-ai-agent-background-work) covers stopping background work. The [tool-error decision reference](/blog/ai-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. ## 05 — Add a clock record to one workflowAdd a clock record to one workflow 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](/blog/when-a-tool-call-takes-ten-minutes) . Concurrency can improve scheduling, but it does not define the business deadline. - Scope - 16 timing cases across 4 kinds of boundary. The complete selected reference appears above; no claim of exhaustive coverage of all systems. - As-of date - September 7, 2026. This is the actual source collection and review date; publication is assigned to the September 6 batch. - 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. - Counting - Each row is one editorial case and belongs to its displayed group. Chart widths use 45 SVG units per entry. Group sizes describe our selection, not a measured distribution. - Sources and interpretation - gRPC supplies the deadline/timeout distinction and remaining-time propagation. RFC 6749 supplies token lifetime semantics. Business, queue, lease and recovery rows are explicit design cases, not claims of standardized API behavior. - 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. ## 06 — DecisionWhat to do next ### Set the deadline around a usable result. Choose the outer deadline, protect verification time and identify the separate clocks that can interrupt progress. When a limit expires, report the boundary that ended and the state that remains unknown. For implementation support, explore our [AI transformation services](/services/ai-transformation).