Answer
How do you give an agent a budget and a deadline?
Enforce them outside the agent, and tell it what to do as it approaches them rather than only what the limit is.
Enforce the limit outside the agent, because a limit it enforces itself can be exceeded by the same reasoning that exceeded the task. Then tell it what to do as the limit approaches, so being cut off leaves something usable.
The first requirement is that the limit is not the agent's to keep. An instruction to stay under a step count or a spend is subject to the same judgement as everything else, and the run that is going to exceed it is the run where that judgement has already gone wrong. A cap enforced by the runtime stops the run regardless of what it concluded, which is the only construction that binds in the case it exists for.
The second requirement is less obvious and is what separates a useful cap from a blunt one: the agent should know the limit and what to do as it nears. A run terminated at a hard boundary leaves whatever state it was in, which may be a half-finished operation and an unwritten record. A run that knows it is approaching a limit can finish the current stage, write its state, and produce a report of where it got to, which turns a termination into a stopping point.
That gives a two-layer arrangement. A soft threshold, at which the agent wraps up, writes its state and reports. And a hard cap somewhat beyond it, enforced externally, which stops the run whatever it is doing. The gap between them is the space to land in, and it needs to be large enough for the wrap-up to complete, which is usually a small fraction of the total.
Deadlines behave differently from budgets in one respect worth stating. A budget is consumed by what the run does and is roughly predictable per stage; elapsed time additionally includes waiting — a slow tool, a rate limit, a retry backoff — which the agent does not control. A run that is out of time because a dependency was slow has a different remedy from one that spent its budget exploring, and the report should distinguish them.
What to spend the budget on is worth stating alongside the amount. An agent told it has a limited number of steps and nothing else will allocate them as it goes; one told to prioritise coverage over depth, or to establish the foundation before elaborating, allocates differently. This matters most on tasks where a partial result is useful, because the shape of the partial result is determined by that allocation.
Finally, treat a run that hit its cap as information rather than as a failed run. Either the task was larger than estimated, or something went wrong and consumed the budget, or the limit was set too low. Those three have different responses and the run's own report usually distinguishes them, which is the argument for the soft threshold: a run that was cut off without wrapping up cannot tell you which of the three it was.
A limit the agent is trusted to observe is a target it is aware of, which is a different thing entirely.
Siddharth Sharma, Context Theory
Related questions
What is a reasonable cap?
Comfortably above a normal run for that task, which you know only after a few normal runs. Before that, set something generous and treat the first runs as the measurement. The cap's purpose is bounding the abnormal case rather than optimising the normal one, so precision is not what makes it valuable.
Should the limit be per run or per period?
Both, and they catch different things. A per-run cap bounds a single runaway; a per-period cap catches the case where a workflow is triggered far more often than expected, which no per-run limit prevents. The second is the one businesses discover from a bill.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Realistic monthly lead-gen software spend | $1,500–$5,000 | Category-wide |
2026 speed-to-lead benchmark · verified
2026 real estate operating cost survey · plus $1,000–$8,000 variable · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Constraint | A limit the agent enforces is subject to the same judgement that produced the overrun, so only a runtime-enforced cap binds in the case the cap exists for. | Comparing behaviour when a step limit is stated in the brief against when it is enforced by the harness. |
| Workflow | A run terminated at a hard boundary leaves whatever state it was in, so a soft threshold at which the agent finishes its stage, writes state and reports converts a termination into a resumable stopping point. | Terminating a run at a hard cap and inspecting what state survives. |
| Software | Elapsed time includes waiting the agent does not control — slow tools, rate limits, retry backoff — while budget is consumed by its own decisions, so exhausting each has a different remedy and the report must distinguish them. | Comparing the proportion of elapsed time spent waiting against acting in a completed run. |
| Buying behaviour | A per-run cap bounds a single runaway while a per-period cap catches over-triggering, which no per-run limit prevents and which is typically discovered from a bill. | Checking whether the workflow's trigger rate is bounded independently of its per-run cost. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one