Your AI agent needs an allowance before it gets a schedule

Google’s July 28 update adds several controls around long-running AI work. Managed Agents can use Gemini 3.6 Flash by default, run custom checks before or after tool calls, start from scheduled triggers, and accept a max_total_tokens setting for a complete interaction.

The schedule and the limit matter together. A scheduled trigger can reuse the same cloud work environment, so files persist between runs. The token ceiling keeps one complex run from continuing indefinitely. When it is hit, Google returns an incomplete status and preserves the environment so the job can continue later with a fresh budget.

Tokens are not dollars, and they do not capture every possible tool or infrastructure charge. Model choice also changes cost. But a per-run ceiling is much more useful than discovering the problem in a monthly bill after a recurring task has repeated the same expensive mistake twenty times.

Google also added pre- and post-tool hooks. Those can block a risky action, lint a file or audit what happened. Cost limits answer how long the agent may keep trying. Hooks answer what it may do while trying. Neither is exciting demo material. Both belong in the product before unattended work does.

If you are shopping for an AI agent rather than building one, you may never see max_total_tokens. Ask for the same idea in ordinary terms: What can one run spend? How long can it work? How many times can it retry? What happens when it runs out?

There are at least three budgets hiding inside a background task. The money budget covers model and tool charges. The time budget stops a morning cleanup from becoming an afternoon mystery. The attention budget limits how many questions, warnings and partial results come back to the person who thought the work had been handed off.

A system can respect the first budget and still fail the other two. A cheap agent that asks six questions during dinner is not cheap. A fast agent that leaves eleven half-finished drafts for Monday review did not finish eleven jobs. It manufactured a queue.

The useful stop state is not a red error and an invitation to try again. It should say what finished, what did not, what was spent, whether any outside system changed, and the smallest decision needed to continue. A limit without that handoff merely moves the confusion to the edge of the limit.

Google’s new setting is described as a cap: the managed interaction pauses when total input, output and thinking tokens reach the configured limit. Anthropic’s Task Budgets take a softer approach. Claude sees a running token countdown and uses it to pace the work, but Anthropic calls the budget advisory and recommends a separate max_tokens ceiling when a hard stop is required.

The difference is not a reason to declare a winner. It is a reason to read the control label. ‘Budget’ can mean a hard stop, a pacing hint, a per-request output ceiling or an organization-wide spend limit. Those are not interchangeable.

For long tasks, a graceful finish can be better than a crude cutoff halfway through a file change. For bills, compliance boundaries or customer-facing actions, an advisory nudge is not enough. The product should make clear which limit is soft, which is enforced, and which costs sit outside the meter.

OpenAI’s API also exposes organization spend-limit controls. That protects a larger account boundary, but it does not replace a sensible allowance for each scheduled job. If the whole organization has to hit its ceiling before one bad recurring task stops, the granularity is wrong.

Mina Torres would keep the language out of the engine room. A person should not need to know what a token is to understand that the weekly task paused. Her stop card has four lines: finished, still open, money used, and what happens if you do nothing. If the last line is missing, the assistant has handed uncertainty back to the user.

Noah Park would test the schedule before trusting it. Run the task manually three times with a deliberately small allowance. One run should have enough room, one should approach the edge, and one should hit it. Check whether the result closes cleanly or leaves files, drafts and notifications in a strange half-state.

Mina’s view protects the tired person reading the result. Noah’s catches the failure before it repeats at 7 a.m. every weekday. Both are better than treating a monthly usage graph as the first line of defense.

Start with one task that has a visible finish: reconcile a small set of records, prepare a research brief, sort a known batch of files or draft a report from fixed sources. Do not begin with ‘keep an eye on everything.’ That has no natural stopping point.

Then answer five questions before turning on the schedule: What is the per-run limit? What ends the run besides success? Which actions are blocked even when budget remains? What survives after a stop? Who sees the unfinished work?

Set the first allowance low enough that the stop behavior will probably appear during testing. A limit you never reach is just a decorative number. You want to see whether the agent preserves useful work, avoids duplicate actions on restart, and explains the remaining choice without demanding a forensic review.

Only then add recurrence. Check the first few runs for cost, completion and human cleanup. If the assistant keeps reaching the ceiling, do not automatically raise it. The task may be too broad, the source set may be noisy, or the agent may be repeating a failed step. More allowance can hide a bad job design.

AI agents are becoming easier to leave running. Good. The mature version is not the one that works longest without you. It is the one that spends within a boundary, stops without making a mess, and makes it easy to decide whether the unfinished part deserves another dollar or another minute.