A ceiling for agent spend: caps, bounds and one stop control

A person working on a task gets tired, bored or hungry, and those are crude but effective spending limits. An agent has none of them. If a search comes back thin, it searches again. If a step fails, it retries. If a schedule says daily, it runs daily long after anyone reads the output. None of this is a malfunction; it is the agent doing what it was set up to do, with nobody watching the meter. This note is about putting the meter where people can see it, and putting limits where they actually stop work.

Where agent spend actually comes from

Cost in agent work rarely comes from one expensive call. It accumulates from patterns:

• Loops without an exit. The agent keeps refining because nothing told it what “good enough” looks like.
• Retries on a broken dependency. A tool is down, and every attempt still costs something.
• Fan-out. One question becomes a search per company, per product, per market, and each branch spawns its own follow-ups.
• Delegation. One agent hands parts of the work to others, and each brings its own consumption.
• Recurring work. A schedule set up for a short project keeps running because removing it is nobody's job.

Each pattern has a different remedy, which is why a single monthly budget on the account is not enough. You need limits at several levels: the task, the day and the whole installation.

Make the meter visible

A limit nobody can see is experienced as a random failure. Before you set caps, make consumption visible in the units people actually budget in. In GoCux, agent work draws on credits the team can see, with a daily cap on top, so consumption is something people look at rather than something they discover on an invoice.

Visibility changes behaviour on its own. When people can see that a recurring monitor consumes more than the research it supports, they ask whether it still needs to run daily. When they cannot see it, the question never comes up.

Bound each task, not just the account

The most effective limit is the one closest to the work. A work order should carry its own bounds: how long it may run in wall-clock time and how many tool calls it may make. Bounds are not an estimate. They are a promise that the task stops when it reaches them, finished or not.

Work order:   summarise supplier contracts in the project folder
Scope:        project procurement-review, documents only
Done when:    one table, one row per contract,
              renewal date and notice period cited
Wall time:    up to 30 minutes
Tool calls:   up to 40
Data class:   internal

A bound of zero tool calls is useful too: it means the agent may only work with what it was given, which is the right setting for drafting or rewriting tasks. Bounds also force the question that prevents most runaway loops, namely what counts as done. Write acceptance criteria before the agent starts covers that part, and specifying a task shows the fields a work order takes.

A daily cap that really stops

Above the task sits the daily cap: the most the organisation is willing to spend on agent work in one day, however many tasks are running. The important design decision is what happens at the ceiling. There are three common answers, and only one is good.

• Silent degradation. Work continues with fewer sources or shallower checks, and the output looks the same. This is the worst option: the result is weaker and nobody knows.
• Silent overrun. Work continues and the bill arrives later. The cap was only a suggestion.
• A visible stop. Work halts, its state explains why, and the person responsible decides whether to raise the cap or wait.

GoCux takes the third path: when the ceiling is reached, work halts and the workspace states the reason plainly. A stopped task should show what it completed, what it did not reach and what it would need to continue. It should never report progress it has not made. A refusal is a result explains why an honest stop is more useful than a quiet partial answer.

Recurring work is where costs hide

A single task ends. A schedule does not, unless someone ends it. That is why scheduling counts as a consequential action in GoCux: recurring work runs only inside a cadence and a safeguard that a person approved. Even with that in place, make a habit of reviewing every active schedule on a regular rhythm, and ask one question of each: is anyone still reading the output? If not, stop it. The seven action classes explain why scheduling sits on that list.

One control that stops everything

Caps handle the predictable cases. For the unpredictable ones, such as an agent behaving oddly, a dependency returning nonsense or a cost spike nobody can explain yet, you want a single control that halts new work and external effects across the whole installation at once. GoCux has one. Two properties matter more than the button itself:

• Everyone who might need it knows where it is, and pressing it is not treated as an overreaction.
• Resuming is deliberate. Work does not quietly restart once the pressure is off; someone resumes it, and the trail records who did.

Practise using it once, on a quiet day, so that the first time is not an emergency.

Setting your first limits

• Credits, or whatever unit you budget in, are visible to the people who start work.
• Every work order has a wall-time bound and a tool-call bound, and drafting tasks run with zero tool calls.
• Every work order states what done means, so the agent has a reason to stop before the bound.
• A daily cap exists, and reaching it produces a visible stop rather than weaker output.
• Recurring work runs only inside an approved cadence, and active schedules are reviewed on a rhythm.
• A single stop control exists, people know who may use it, and resuming is an attributed act.

Spend on the agent's own work is one budget. Money moving to the outside world is another matter, and it needs a person every time; money moves need an explicit decision covers that boundary. Plan details are on the pricing page.