Give each business request a bounded allowance for model calls, tool attempts and elapsed time. Stop work that cannot progress, preserve its state and hand it to an owner.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Define the request that deserves another attempt
A scheduling assistant asks for available appointments, receives an incomplete result and asks again. Then it changes the wording and repeats the same lookup. Each attempt can consume resources while the customer remains no closer to an answer. A monthly usage dashboard may reveal that pattern after the work has already happened.
AI agent cost control starts with the individual business request. Define what counts as a useful completed result, what information is missing and when the application should stop trying automatically. A request that ends with an honest, actionable handoff can be preferable to more reasoning over the same unavailable facts.
This guide proposes a planning exercise with invented limits and records. It describes neither an AgenticShip customer deployment nor a universal spending guarantee. Implementation pricing is a separate question; here the decision is how much automatic work one request is allowed to initiate before someone must review it.
Separate an execution limit from a spending estimate
LangGraph documents a GRAPH_RECURSION_LIMIT error when a graph reaches its maximum steps before a stop condition. A loop is one possible cause; a complex legitimate graph can also reach a limit. That framework-specific control does not establish a monetary budget for an entire business workflow.
Graph steps, model requests, tool attempts and tokens are different units. One step may call several services, while a tool or its client library may retry internally. Record the units the selected implementation actually consumes. Include input and output usage, separately billed tools and any other relevant provider charges when estimating spend.
Treat an estimate as an estimate. Usage reporting can arrive late, and calls already in flight may finish after a stop decision. Ask which limits prevent new work, which only raise an alert and what exposure remains. A monthly account limit also serves a different purpose from the allowance for a single customer request.
Work through a small budget for request Q-88
In our fictional exercise, Q-88 asks for two available appointment times. The assistant may read availability and prepare a draft; it may not change a booking or send a message. We propose a maximum of three model calls, two availability-tool attempts and 45 seconds from acceptance of the request. These numbers are illustrative acceptance inputs, not recommended defaults or provider quotas.
The first model call selects the lookup. The first tool attempt fails transiently; a second permitted attempt returns no usable times. A second model call can prepare a handoff explaining the missing availability. A third lookup must be refused even though one model call remains. Each boundary applies independently: spare allowance in one category does not replenish another.
If the deadline expires before the second lookup, no new lookup should start. Preserve the request reference, last known result, consumed allowance and stop reason. Assign the unresolved scheduling task to the agreed owner rather than presenting unavailable times as a completed answer. The customer-facing wording should explain the next step without exposing internal diagnostics.
Write down what enforces each boundary
Use this proposed worksheet during discovery. The enforcing component must check eligibility before dispatching more work; a prompt asking the model to be economical is not the enforcement mechanism. For parallel work, reserve allowance consistently before starting calls so several workers cannot each consume the same remaining slot.
| Boundary | What to count or check | What happens at the boundary |
|---|---|---|
| Model allowance | Every dispatched model call, including failed attempts | Refuse another call and preserve the unresolved task |
| Tool allowance | All attempts, including known nested retries | Stop dispatching the affected operation |
| Elapsed time | One deadline across waiting, retry and resume | Move overdue work to an explicit pending or review state |
| Estimated spend | Applicable usage plus reserved work in flight | Block new work when the agreed estimate policy requires it |
| Progress and ownership | Repeated result, missing fact and responsible owner | Record why automation stopped and who takes the next step |
Keep the same budget through retries and resume
Microsoft’s Retry pattern distinguishes transient faults from failures unlikely to improve through repetition. It also warns that retry policies nested inside other retry policies can extend delays. Inspect the actual client and worker configuration rather than assuming the outer counter sees every attempt.
For Q-88, refreshing the screen, restarting a worker or resuming a saved conversation should not silently create a fresh allowance for the same unresolved request. Keep the consumed counters and original deadline with its durable state. A separately authorized new attempt needs an explicit policy and record; relabelling the same task is not a cost-control strategy.
Stopping new reasoning does not undo an earlier business action. If a different workflow may already have written a booking before losing its response, reconcile that destination state before retrying. Our read-only Q-88 exercise avoids that write, but the delivery scope still needs to identify uncertain outcomes and a responsible recovery path.
Test exhaustion as carefully as successful completion
Run an isolated exercise with synthetic inputs and consequential writes disabled. First show a normal request completing within its allowance. Then force repeated incomplete results, tool failure and deadline expiry. Inspect the actual dispatched calls and final task state, not only a log saying that the limit was reached.
Resume the exhausted request and launch two eligible workers together near the remaining limit. Verify that the intended counters survive and the agreed reservation mechanism prevents extra dispatch. Test what happens when usage telemetry or the counter store is unavailable; the chosen fallback should be explicit and should not silently grant unlimited work.
Confirm that the handoff contains enough information for its owner to act without restarting the whole loop. Record consumed calls, elapsed time, unresolved facts and any work still in flight. A failure case passes when the agreed boundary and next action are demonstrated, not when the assistant merely apologizes. Keep this case in the workflow’s evaluation set.
Agree on useful limits before expanding the workflow
Ask an implementation partner to show the budget owner, counted units, enforcement point, retry configuration and recovery behavior for one representative request. Include any provider-reporting delay and unresolved dependencies in the scope. A cheaper model alone does not establish that the surrounding loop is bounded.
After launch, review how many eligible requests complete, stop or reach an accepted handoff, and why. Compare actual usage with useful outcomes while keeping failed attempts in the totals. If legitimate requests repeatedly exhaust the budget, investigate the missing facts or workflow design before raising every limit. The aim is controlled, useful work with a clear next step.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.