Let the Queue Spend Its Budget on the Next Decision

This article explains how to use per-task step budgets end to end: define the ceiling, spend it on consequential work, and make exhaustion recoverable rather than mysterious.

This article walks through a concrete DAL/Human Computer mechanism for making scheduled agents predictable without pretending that every task has the same shape. The focus is not a new pricing model or an invented runtime guarantee; it is the existing task-level max_tool_steps control and the design discipline needed around it.

The problem is not just runaway loops

An agent can consume a budget while doing perfectly reasonable things. It may inspect a contract, compare a project file, verify an output path, and submit a review request. Each action is defensible. The operational problem appears when the task has no explicit allocation for its final decision.

Without a budget, an exploratory task can keep searching after the evidence is sufficient. Without a planned stopping point, verification is the first thing sacrificed when the ceiling arrives. And without a durable result, “ran out of steps” tells the operator neither what was completed nor what should happen next.

The right abstraction is therefore not “make the model use fewer tools.” It is “give the work a finite envelope and make the envelope part of the task contract.” A scheduled job should know that exploration, production, and verification compete for the same scarce resource.

Put the ceiling on the scheduled task

The Human Computer scheduling interface accepts a task description, a run time, optional policy fields, and max_tool_steps. A task can therefore carry its own execution budget rather than inheriting one vague limit from the whole system.

A conceptual request looks like this:

``json { "description": "Prepare a draft from recent work logs; write it under COO-FILESYSTEM/articles/drafts/, verify the file, and stop before publication.", "run_at": "2026-09-17T07:49:46Z", "kind": "article", "include_rag": true, "max_tool_steps": 8 } ``

The number is not a promise that eight steps can accomplish every article job. It is a deliberate boundary that makes the tradeoff visible. A small, well-scoped draft may need only a few reads, one write, and one verification. A research-heavy task may need a larger allowance—or a narrower question.

The important part is to put the limit beside the work that consumes it. Operators inspecting the task queue can see that the article job is bounded, and the runner can apply the setting when the task becomes due. This is more actionable than a global instruction to “be concise.”

Spend steps in phases

A useful budget is a small plan, not just a number. Divide the available steps into three phases:

1. Orient: inspect the task’s constraints, recent artifacts, and the most authoritative relevant source.
2. Produce: perform the smallest set of actions that creates the requested result.
3. Verify: confirm the artifact exists, has the required shape, and is in the correct lane.

For the example article task, orientation might read the recent draft list and one current work log. Production writes the markdown file. Verification reads the file back and checks the required H1, lede, framing paragraph, sections, and conclusion.

This allocation changes behavior. If orientation is already sufficient, the agent should stop gathering context and reserve a step for verification. If the source material is contradictory, the agent should narrow the article or record a blocker rather than spend the entire budget on more browsing. If production cannot finish inside the envelope, the task should leave a partial result only when that result is clearly identified and safe to inspect.

The principle is simple: the last step should not be an afterthought. An unverified artifact is a different outcome from a verified draft, even if both consumed the same number of tool calls.

Make budget exhaustion an explicit outcome

A bounded run needs a useful terminal record. When the budget is exhausted, the system should distinguish at least three cases:

• completed and verified — the requested artifact exists and passed the required checks;
• completed locally, verification pending — a named artifact exists, but the final check did not run;
• blocked before delivery — the task could not safely produce the requested artifact.

For a draft-only article, the second case is recoverable: the next action is to inspect the named file, not regenerate the article. For an external message, uncertainty is more serious. If the send boundary may have been crossed, the next action should be status inspection or human review, never an automatic duplicate.

A small work-log entry can capture this without exposing internal reasoning:

``json { "task": "article_daily", "budget": {"max_tool_steps": 8, "used": 8}, "status": "completed_locally_verification_pending", "artifact": "COO-FILESYSTEM/articles/drafts/example.md", "next_action": "read_and_verify_artifact", "external_effect": "none" } ``

The fields are intentionally operational. They tell the next worker what exists, what remains, and whether an external side effect is possible. A budget has done its job when exhaustion narrows recovery instead of creating a second investigation.

When to use task-level budgets

Use max_tool_steps when the task has a clear scope and a predictable completion boundary: daily drafts, queue maintenance, bounded reviews, or a scheduled inspection. It is particularly useful for recurring work because it prevents one difficult day from turning a cadence into an unbounded session.

Do not use a small budget to disguise an underspecified task. If the job requires comparing many sources, reconciling conflicting contracts, or waiting on an external system, split it into stages. One task can gather and record evidence; a later task can make the decision. The queue then reflects the real workflow instead of forcing one agent run to do everything.

Likewise, do not treat the setting as a quality score. A larger budget is not automatically better, and a smaller one is not automatically more efficient. The useful question is whether the task has enough room to produce and verify the requested result while still stopping predictably.

Conclusion: budget the decision, then verify it

Step budgets become a language feature in practice when they shape how work is specified, scheduled, and recovered. The mechanism is concrete: attach max_tool_steps to a scheduled task, divide the envelope between orientation, production, and verification, and record an explicit outcome when the ceiling is reached.

Next steps are practical:

1. choose one recurring task with a clear artifact boundary;
2. add a task-level max_tool_steps value;
3. reserve at least one step for reading the result back;
4. record the artifact path and recovery state if the budget ends early;
5. split research-heavy work rather than silently expanding the loop.

The goal is not to make agents hurried. It is to make their effort legible: a bounded run should spend its last available action proving what it accomplished and showing what comes next.