On this page
How the budget works: reserve first, settle after
Before an agent carries out a step, bricksta estimates how many tokens it will cost and reserves that amount from its budget. Only then does the step run. Once the step is finished, the reservation is settled against actual consumption — whatever was over-reserved returns to the budget.
That has an important consequence: while a run is working, part of the budget is tied up and unavailable to other runs. So an agent can hit its limit even though consumption is still well below it — several concurrent runs together hold more reservation than any one of them ends up needing.
Every run is booked twice: against the agent's budget and against the organization pool. Both have to cover the reservation. If the pool is empty, a generous individual budget does not help — and vice versa.
If a run ends untidily — because it took too long, say — its reservation would otherwise stay blocked forever. A background sweep runs every 15 minutes against that: it closes such orphaned runs, books their reservation back onto both budget entries, and requeues the affected task. You need do nothing; you later see these runs in the history as expired.
What happens at budget 0
An agent with budget 0 is not paused — it is blocked. It still takes tasks on, but every run is turned away before a single token is spent. The task stalls as an incident and waits for you. The same applies once the budget is used up during the month.
If you want to put an agent on ice, don't set its budget to 0 — use the “Agent active” switch at the top of its details. A deactivated agent immediately stops carrying anything out, without producing incidents, and its history stays fully intact. Budget 0, by contrast, produces a new waiting incident for every task you assign.
When the budget refills
A budget is a monthly allowance: at the start of each calendar month the remainder is automatically set back to the token limit you configured — per agent and for the organization pool. You need do nothing for that. What you consumed during the month is gone; the limit itself stays as it was.
You can top it up by hand at any time before then: Agent Center → Agents, select the agent, enter the token limit under “Budget (per agent)” and press “Save budget”. Saving sets the remaining amount to the value you entered — even if you enter the same value as before. That is the route when an agent runs dry mid-month.
So the limit is a recurring monthly spend, not a one-off total cap. Set it to what you would be happy to spend every month — and check “Runs & Cost” to see how far the budgets have run down within the current month.
Why a run is rejected: the three reasons
Before an agent acts, bricksta checks three things — always in this order. The first check that fails ends the run; the later ones are never reached. That matters for diagnosis: if a deactivated agent also has an empty budget, all you see at first is the deactivation.
- 1Is the agent active? A deactivated agent is turned away before anything happens — no AI call, no send, no budget deduction. Way out: switch “Agent active” on in its details.
- 2Does the agent hold the necessary tool? An agent without “Complete tasks” cannot complete a task, one without “Send” cannot prepare a message. Way out: grant the missing tool under “Tools” and save.
- 3Does the budget cover the estimate? Both the agent budget and the organization pool are checked. If either falls short, the run is turned away — without spending tokens. Way out: raise the token limit and save.
When a temporarily blocked budget frees up again, bricksta picks the affected waiting tasks back up by itself — you don't have to re-trigger every incident by hand.
Getting a stuck agent moving again
When an agent step hits one of these limits, the task stalls visibly as an incident. You have three options right on the task: “Retry” tries again (sensible once you have fixed the cause), “Complete manually” means you take it over, and “Skip” lets the case move on without this step.
For an agent incident, a “Manage agent” link takes you straight to the agent concerned. At the top it states plainly what the matter is — right where you can fix it.
- “A case is waiting: budget exhausted”
- The token limit no longer suffices. Enter a higher limit under “Budget (per agent)” below and save. Also check the organization pool in “Runs & Cost” — that may be the actual brake.
- “A case is waiting: this agent is deactivated”
- The “Agent active” switch at the top is off. Switching it on is all it takes.
- “A case is waiting: a tool has not been granted”
- The agent lacks the tool for exactly this step. Grant it under “Tools” and save. Which one is missing follows from the kind of task: a send task needs “Send”, a task to be completed needs “Complete tasks”.
- “A case is waiting for this agent”
- The general case: the run was turned away without one of the three causes being clearly attributable. Check “Runs & Cost” for when the last run was and how it went.
Reading the “Runs & Cost” table
Agent Center → Runs & Cost is a pure transparency view — nothing is decided or changed here. It requires the “Manage organization” permission. Each row is an agent; standing on its own is the “Organization pool” row for the shared allowance across all agents. If you have no agents yet, the page says so and points you to Agent Center → Agents.
- Agent
- The agent's name. A deactivated one additionally carries an “inactive” marker here — handy when you wonder why a row shows no activity any more.
- Activity
- How much this agent has worked: the total number of runs, how many of them failed, and how many runs are currently still holding a reservation. A high share of failed runs is the first warning sign — work through the three rejection reasons above.
- Tokens (in / out)
- Actual consumption, split into input and output. Input tokens come from the context the agent reads (case, task, persona, knowledge base), output tokens from what it writes. An agent with a very large knowledge base generates many input tokens even when it produces little.
- Budget
- The remaining amount and the limit set, as “remaining / limit”. If it says “no budget set”, the agent has no budget entry of its own — then only the organization pool constrains it.
The quickest health check: look at the Activity column. If almost as many runs failed as ran in total, the agent is not working — it is being turned away. If the column shows permanently reserved runs, something is hanging; the sweep resolves that by itself within 15 minutes.
How a run can end
A run is a single execution attempt on a task. These are the possible outcomes:
- Running — the step is working and holding its reservation.
- Awaiting approval — the agent has prepared something that needs a human decision. You find it under Agent Center → Approvals or on the mission detail.
- Done — the step ran through, and the reservation was settled against actual consumption.
- Error — the step failed substantively (an error at the AI provider, say). The task stalls as an incident.
- Denied — the gateway turned the run away up front: inactive, missing tool or budget. No tokens were spent.
- Superseded — a newer run on the same task replaced this one. That is normal when you press “Retry”.
- Expired — the run stopped reporting and was closed by the sweep; its reservation is booked back and the task requeued.
One special case is not in that list, because it does not hang off a single run: if your organisation uses the bricksta AI (that is, no AI connection of your own) and the platform's AI access is temporarily out of credit, every AI run fails alike — missions, AI steps and template generation. So that this does not look like sluggishness, a notice band then appears across the whole application naming the platform as the cause. In that case it is not down to your organisation, your budget or your data; only the operator can fix it. Organisations with their own AI connection are unaffected by THIS case and therefore do not see the band. There is, however, a second reason for the same band, and it applies to every organisation: if several runs break off within 24 hours without producing a result, the band says so. That is not a provider problem but a run that never came back — nothing is lost, unfinished work stays open and the next run picks it up.
Expired runs are in practice the most common unpleasant outcome, especially on missions with many tasks: a work run that takes too long gets cut off. It costs you nothing, but it does not advance the mission either. The way out is almost always to break the plan into smaller steps — fewer tasks per run.
What this view cannot do
Two limits, so you don't go looking for them. First: bricksta does not convert tokens into money. There is no cost display in euros, no invoice and no threshold in currency — the budget is a pure quantity cap. What a token costs is known to your AI provider.
Second: the view shows totals per agent, not an itemized list of every run with a timestamp. If you want to know what happened on a particular case, look at its activity trail — agents appear there as actors marked “(AI agent)”. For missions that ran on their own there is an additional log on the same page, explained in the article Keep working on its own.