An agent can use fewer tokens and still miss the maintenance planner's meeting. It can also stop within a step limit after launching more tool calls than the operator expected. A useful task budget has to reflect the work that must be handed over, including what remains unresolved.
Consider a fictional solar-operations planner asking for a brief on three open work orders by 09:12. The agent may read current records and draft the brief. It cannot close work orders, dispatch a crew or change equipment settings. The schedule and limits below illustrate a design; they are not measured performance or recommended universal defaults.
Separate the model's pacing hint from enforced limits
Claude's task-budget beta provides an advisory token countdown across an agentic loop. It includes thinking, tool calls, tool results and output. It is a soft target; max_tokens remains a separate per-request output cap. The current minimum task_budget.total is 20,000 tokens. Check model support before using the beta, and measure representative work before choosing a value. Claude: task budgets, advisory behavior and feature support
That countdown can help a model pace its work. The application still needs a wall-clock deadline and controls over calls that it launches. Tokens do not express how long a maintenance database will take to answer, whether a supplier lookup incurs a separate fee, or how much time the planner needs to review the result.
OpenAI's Agents SDK documents max_turns as a limit on agent-loop turns, meaning model calls, and raises MaxTurnsExceeded when the limit is exceeded. It also supports an error handler for returning a controlled result. A turn limit should not be treated as an equivalent count of downstream tool operations. OpenAI Agents SDK: loop limits and error recovery
AI SDK's loop-control guide likewise distinguishes stop conditions from per-step settings. Its stopWhen conditions are evaluated when the last step has tool results. A condition checked between steps cannot by itself prevent every operation launched within a step. Put dispatch limits at the tool boundary as well. AI SDK: loop control and stopping conditions
Work backward from the planner's deadline
In this example, the planner needs three minutes to read the evidence and choose a follow-up. Agent work therefore ends by 09:09. The task envelope stores that cutoff as an absolute timestamp, together with the business task ID. A retry, model switch or resumed process inherits the original cutoff instead of receiving a fresh nine minutes.
| Control | Example setting | Application responsibility |
|---|---|---|
| Operating deadline | 09:12 | Reserve 09:09 to 09:12 for review |
| Agent dispatch cutoff | 09:09 | Block new work that cannot fit; preserve handoff time |
| Model-call cap | 6 attempts | Count attempts across retries and fallback |
| Tool-attempt cap | 12 attempts | Reserve capacity before each dispatch |
| Cost exposure | Task-specific approved ceiling | Include reserved and pending charges; reconcile actual use |
The time estimate is an admission rule, not a guarantee. At 09:08, a read expected to take two minutes is rejected because it cannot fit before09:09. A read expected to take twenty seconds may be admitted with a bounded timeout, but it could still run late. An independent deadline handler must prepare the handoff even if a provider ignores cancellation.
Reserve the last slot before parallel work starts
Suppose ten tool attempts have settled, one is still pending, and the cap is twelve. Exactly one slot remains. Two workers both reading a counter of eleven could each start a call and exceed the cap. The admission transaction must reserve one slot under the task ID before dispatch. Only one of the competing calls can obtain it.
lock task budget
check actor, task scope and current deadline
check settled attempts + pending reservations < cap
check reserved cost + known usage within ceiling
reserve one attempt and its cost allowance
commit reservation
dispatch with the remaining timeout
record outcome; reconcile usage separatelyCount a timeout as an attempted operation. The provider may still be doing work, and its cost may not be known. Do not release that exposure merely because the local caller stopped waiting. Keep attempt capacity consumed after dispatch; reconcile the cost reservation when provider evidence arrives. An unused reservation can be released only if the system can establish that it was never dispatched.
A model call may also contain gateway retries or start several tools. Instrument the layers you control and distinguish their counts. If the gateway does not expose or let you cap internal attempts, record that limitation. An application-level reservation cannot promise a precise provider bill when the provider's internal work is unknown.
Stop on missing progress before spending every attempt
Work order WO-83 lacks an inspection attachment. Repeating the same read against the same record version produces no new evidence. In the proposed design, the controller records the missing attachment, source version and failed retrieval path, then hands that item to the planner. A second authorized source may justify another read; a rephrased request to the same unchanged source does not.
Compare progress in terms of resolved operating questions. For this brief, those questions are the current work-order status, the supporting inspection record and the unresolved follow-up owner. A longer answer or another successful HTTP request is not evidence that a missing inspection was found. Define a bounded repeated-failure policy with the team and test it on unavailable sources.
Make the partial handoff useful
At 09:09, the controller persists a partial brief. WO-81 and WO-82 have verified source references. WO-83 remains unresolved because its attachment could not be retrieved. The brief names the pending read attempt and tells the planner to obtain the attachment through the existing maintenance system. It does not mark WO-83 complete or infer that its equipment is safe.
Persist findings during the run so a killed process does not erase the only record of progress. A late tool result may update the attempt ledger, but it should not silently replace a brief already under review. Link a new revision to the late evidence, and make its changed basis visible. Resuming work also requires fresh permissions and source state. Read: resume agents with current business state
Test the limit and the work it leaves behind
| Injected case | Required observation |
|---|---|
| Two workers compete for one slot | At most one reservation succeeds |
| Tool exceeds its timeout | Handoff proceeds; pending exposure remains visible |
| Retry or model fallback begins | Original task ID, counters and cutoff remain in force |
| Same missing source is requested repeatedly | Bounded failure rule creates an unresolved item |
| Result arrives after the handoff | Attempt reconciled; reviewed brief not silently overwritten |
Measure deadline misses, unresolved work, late results and planner review time alongside tokens and charges. Compare the same representative tasks under different budgets, including difficult tasks that require handoff. Choose limits from observed completion and review workload. Reducing spend while leaving the planner an unusable brief would fail this operating test.
