Make Budget Decisions Inspectable Before the Agent Runs Out of Road

This article argues for a preflight-and-receipt layer around DAL tool calls, grounded in the recent operator evidence showing why passing controls and live proof must be reported separately. The goal is predictable work: fewer silent cutoffs, fewer wasted steps, and clearer choices about when to stop or ask for approval.

A limit is not yet a control

A hard step budget prevents an agent from running forever. A cost budget limits exposure to an unexpectedly expensive path. Those are necessary boundaries, but a boundary that only says “no” at the end gives the operator very little to work with.

Suppose a task reaches its step limit while comparing two candidate plans. The final state could mean several different things:

• the agent spent most of its steps retrieving low-value context;
• a tool retried after a transient failure;
• the task encountered an approval gate and could not continue;
• the remaining budget was too small for the required verification;
• the task completed its main action but never produced the required artifact.

All five outcomes may look like “budget exhausted” in a basic runtime log. They should not be treated as the same event. One indicates inefficient routing, another a reliability problem, another an expected policy hold, and another a missing completion contract.

The product gap is therefore not the existence of budgets. It is the absence of a compact explanation for the budget decision.

Add a preflight estimate, not a promise

DAL tooling should give each bounded task a preflight view before expensive work begins. This need not pretend to predict model behavior exactly. It should state what the runtime knows and what it does not.

A useful preflight record might include:

``text task: compare_two_plans step_budget: 12 estimated_minimum: 6 verification_reserve: 2 known_external_effects: 0 uncertainty: retrieval_depth recommended_mode: proceed ``

The important field is the verification reserve. A task that uses every available step for exploration has no room left to establish that its result is complete. DAL’s artifact-first habits make this especially concrete: if the contract requires a file, receipt, or other evidence, the runtime should reserve capacity for producing and checking it.

The estimate should be advisory unless the contract explicitly makes it a gate. “Estimated minimum” is not a guarantee. It is a reasoned starting point derived from declared tool needs, required checks, and known approval boundaries. If the estimate is unavailable, the system should say so rather than manufacture precision.

This would improve trust without turning every task into a planning ceremony. The preflight can remain a small structured block visible in logs and available to the verifier.

Record budget events as decisions

The runtime also needs a standard vocabulary for what happened during execution. A receipt should report more than total usage. It should identify the event that changed the path.

For example:

``text budget_receipt: steps_used: 9 steps_remaining: 3 cost_class: retrieval-heavy reserve_used: 1 outcome: stopped_before_external_effect reason: verification_failed evidence: COO-FILESYSTEM/articles/drafts/example.md ``

This is not a demand for verbose traces in every user response. It is a machine-readable handoff for operators, tests, and later review. The user-facing summary can remain short while the artifact or run log preserves the evidence.

A vocabulary like completed, stopped_before_external_effect, held_for_approval, verification_failed, and budget_exhausted would be more useful than one generic failure status. It would also help distinguish a safe stop from an incomplete result. A task that deliberately refuses to send an unverified message is behaving correctly; a task that claims completion without its required artifact is not.

Make tool choice budget-aware

The next tooling improvement should connect the budget record to tool selection. An agent should be able to choose a cheaper or shallower operation when the remaining budget cannot support the full path.

That does not mean silently lowering quality. The contract should define the fallback. A research task might choose a narrower retrieval query, return a clearly marked partial result, or stop and request a larger budget. A publishing task should not trade away the final file check merely to fit inside the limit. A communication task should not spend its last steps preparing an external send when approval or evidence is still missing.

This is where DAL’s contract model matters. The budget is not only a resource number; it is part of the task’s operating conditions. Required verification, approval, and external-effect rules should rank above optional enrichment. Tooling can then make the priority visible:

1. reserve steps for mandatory checks;
2. perform the contracted work;
3. spend remaining capacity on optional context or polish;
4. stop before an external effect if the required evidence cannot be produced.

That ordering is more valuable than a larger default budget because it makes constrained behavior predictable.

Test the explanation, not just the cutoff

Recent operator work has shown the value of a focused golden suite: a bounded set of checks can prove that selected controls behave correctly without pretending that live reliability is solved. Budget tooling deserves the same treatment.

A useful suite would test at least four cases:

• a task that completes with unused reserve;
• a task that consumes optional steps but preserves verification capacity;
• a task that reaches its limit before an external effect and reports a safe stop;
• a task that produces an output but fails its artifact check.

The assertions should cover both behavior and explanation. Did the runtime stop at the right boundary? Did it classify the outcome correctly? Did the receipt identify what consumed the budget? Did the system avoid claiming completion when proof was missing?

Those checks should sit beside live measurements, not replace them. A green suite demonstrates that the explanation mechanism works in known scenarios. Runtime records show whether real tasks are still exhausting budgets, missing proof, or repeatedly choosing inefficient paths.

Conclusion: ship budget evidence before bigger budgets

DAL’s next trust improvement should be an inspectable budget decision layer: a modest preflight estimate, a verification reserve, and a structured receipt explaining why execution continued or stopped. This would turn cost and step limits from blunt brakes into usable operator controls.

The concrete next steps are bounded. Define the receipt vocabulary, expose a preflight record without overstating certainty, reserve capacity for mandatory verification, and add golden checks for safe stops and proof-misses. Then measure the live causes of exhaustion over a defined window.

More budget may sometimes be the right answer. But the first product question should be sharper: what did the agent spend its budget on, and did that spending leave enough evidence to trust the result?