A budget that three workers can share

The three workers cannot each spend the same balance

The research task has a limit of 100 internal credits and has spent 20. Three workers each see the remaining 80 and ask to reserve 30. Every individual comparison says yes; together they would commit 90 against the same 80. These are invented accounting units, not a supplier tariff. The cap needs one shared decision before dispatch, while the workers are still asking to begin.

A reservation holds allowance while an operation’s final cost is unknown. It is not spending merely because work started, and it is not free capacity merely because the worker stopped waiting. I would keep spent, reserved and available visible as separate quantities. The model can propose the next step; the application needs to decide whether that step can begin, including when a worker repeats its admission request after losing the reply.

Reserve before dispatching

For the 100-credit task, define available as limit minus settled spending minus outstanding reservations. An atomic admission operation checks that at least 30 credits remain and records a unique reservation. The first two workers can reserve 30 each. With 20 spent and 60 reserved, only 20 remain, so the third request is denied or deferred.

A separate read followed by an insert is not enough if concurrent callers can pass the read together. Use a suitable transaction, conditional update or other actual concurrency mechanism for the shared store. The important invariant is that accepted reservations plus settled spending cannot exceed the enforced limit under the system’s defined cost model.

If dispatch never begins, release the reservation through a recorded transition. Distinguish that known non-start from a request whose send or response is uncertain; only the former establishes that no external usage can follow.

Give the reservation an identity tied to the intended operation. If a worker loses the admission response and asks again, the service should return the existing reservation rather than allocate another 30 credits. This is a local accounting identity, distinct from any deduplication mechanism the external provider offers for the actual operation.

Choose an upper bound the operation can actually respect. An average request cost helps planning but does not cap a costly outlier. The application may need provider output limits, bounded tool work or a separately controlled emergency allowance if usage could exceed its reservation. An atomic database update cannot rescue an admission rule that reserved too little. The promised spending boundary depends on both the concurrency mechanism and this cost assumption.

A finishes; B may still be spending

Suppose worker A reserves 30 and finishes using 18 credits. Settlement transfers 18 to spent and releases the unused 12. Worker B still holds its 30 reservation. The task now has 38 spent, 30 reserved and 32 available. The third 30-credit operation can be admitted without violating the 100-credit limit.

Settlement should be repeat-safe. A repeated usage notification must not add another 18 to spent. Keep the reservation’s state and observed usage so a duplicate can be recognised. If a correction arrives, apply a documented adjustment rather than overwriting the history and leaving nobody able to explain why the remaining allowance changed.

A local timeout is not a refund. Suppose B stops waiting while its provider request may still be running and charging. Its 30-credit reservation, or another conservative allowance, still belongs to that uncertain usage. After A’s settlement lets C start, releasing B’s allowance would make another operation appear to fit only because B’s possible cost had disappeared from the local view. Keep that commitment until the outcome can be established.

B’s worker claim can expire before its external usage commitment ends. Withdrawing that claim can stop new work by the worker, while its earlier provider request continues. Recovery needs to distinguish current authority, completion and final usage. Those are the facts that determine whether B’s reserved credits can be spent again; a lease timeout cannot settle them.

Check the other limits around this balance

The shared balance answers whether this task has enough reserved allowance. Keep the following boundaries explicit when they also form part of the product’s promise; none can be inferred from the 100-credit number alone.

• Anthropic’s effective-agents article includes stopping conditions such as a maximum iteration count. That is useful control, but a task can stay within an iteration count while making several parallel calls per iteration. Likewise, a financial allowance does not guarantee the task finishes before a business deadline. Maintain the boundaries that matter rather than assuming one counter represents all of them.
• For the research task, record the deadline, concurrency limit, maximum calls and credit allowance separately. Admission checks the relevant constraints before dispatch. Enough credits do not justify starting a step too late to produce a useful result, and remaining time does not authorise exceeding the call cap. A stopped task can return bounded partial work while leaving each exhausted constraint identifiable to its owner.
• Retries consume the same budget as original attempts where the provider charges for them. Tool discovery, retrieval and validation may also have costs. Define the accounting boundary so the planner cannot appear efficient by moving expensive work into a supposedly free helper. Keep external billing evidence distinct from internal credits if the conversion is approximate.
• A task can stay below 100 credits while several such tasks exceed the organisation’s daily cap. If the product promises both limits, coordinate reservations at both levels before dispatch. For a small installation, a single shared admission service may make those commitments easier to follow than independent counters. Finding the aggregate overspend after the provider starts work is too late to turn the daily cap into an admission rule.
• A practical review can simulate simultaneous reservations, a lost admission response, duplicate settlement, a provider timeout and a dead worker with unresolved usage. Assert the accounting invariant after each event. These scenarios are small enough to inspect by hand and specific enough to expose bugs that a normal single-worker demonstration will never encounter.

What should C receive while it waits?

Budget exhaustion should produce an intelligible result. Show completed work, evidence obtained, unresolved questions and why the next step was not started. A partial answer can be valuable if its boundary is clear. A polished answer that conceals an unperformed check is a poorer outcome than an honest stopping point.

For the third worker denied at the initial 20-credit remainder, the planner might wait for settlement, choose a bounded cheaper operation or refer the outstanding question. The application should permit only routes that remain within policy. Rephrasing the same expensive operation or splitting it into smaller labels should not bypass a shared resource limit.

There is an unavoidable trade-off between conservative reservation and utilisation. Holding 30 credits for an uncertain operation can delay useful work that would fit its eventual cost. Releasing it early improves apparent utilisation by accepting overspend risk. Make that policy visible and choose it according to the consequence, rather than letting timeout cleanup decide it accidentally.

Also decide who can raise the limit. If a person extends the budget, record the new allowance and decision explicitly. Do not let an assistant interpret “please finish” as unlimited spending when the product promised a cap. Conversely, do not keep asking for approval for work already covered by an authorised allowance; admission should make that ordinary work straightforward.