An autonomous agent spends tokens on its own, with no human looking over its shoulder — so it needs brakes. The weekly token budget guards the wallet. Two locks — the owner's switch and the admin's sticky lock — stop the agent entirely: both must be open for a run to start. And the owner lifecycle keeps a departed employee from leaving background agents behind to burn budget. The fewest levers possible — yet enough to close the main risks.
Every lever on this page converges into one condition. A run starts — on schedule or by hand — only if all four are open; any one closed shuts the launch down entirely.
A fifth condition — owner active — is not a separate
axis: deactivation writes the same enabled=false
(lifecycle), so
effectively there are four axes of control. Any lock gates the
start; a run already underway finishes to the end — instant
abort (kill switch) is
v2.
An empty store is not a fifth condition. When there
is nothing to search
(is_empty), the agent still starts: the KS core is
withheld as a derived consequence
(tools), and it
either degrades onto external tools or exits honestly. This is a data
state, not a control lock — once the store fills, the core returns
without intervention.
The admin sets a weekly token cap per user — one cap
across all of their agents at once. Spend is
summed from the run journal for the current week
(agent_runs.tokens_used); there is no dedicated
counter table — the cap is derived. Before a run starts, the engine
checks the sum against the limit: within it, go ahead; over it, the
run does not start.
Beyond the cap, runs are marked skipped with the reason
“limit exceeded” and wait for the weekly reset: spend zeroes out on
Sunday 00:00 in the organization's timezone (the
week is calendar, not rolling), and the agents come back to life on
their own. The cap guards against bankruptcy; the
iteration cap
insures a single run against looping — different brakes.
The limit is a platform setting on the
AI usage
screen
(platform_settings.agent_weekly_token_budget), one per
organization; the same screen shows spend by person and the reference
chat budget. Monetary budgets, alerts on approaching the cap, and an
instant kill switch are v2.
A run is driven by a chat model
the owner picked from the list the admin allowed for agents
(agent_models). The choice is stored in
model_id —
a reference to a row in the list. As long as the model is in the list,
the agent starts; once the admin removes it,
SET NULL clears the reference, and
model_id IS NOT NULL in the gate turns false.
A removed model stops the agent like a lock: next_run_at
is cleared, the scheduler does not scan the row, and no
skipped record piles up. On the agent's screen a banner
reads “model not supported, choose another”; the owner brings the
agent back by picking a model from the current list. There is no
implicit fallback to a default — NULL means “no model,”
not “take the default.”
For a run to start, both locks must be open: the owner's switch and the administrator's lock. Either one closed stops the agent entirely — neither on schedule nor by hand. The first is the agent owner's lever, the second is oversight's lever over someone else's agent.
A closed lock stops the agent silently: its
next_run_at
is cleared, the scheduler does not scan the row, and the manual-run
button is disabled — a durable stop breeds no skipped
records; it shows through the agent's status. Only a runtime refusal
is journaled, invisible from the agent's settings: the chosen
budget and overlap onto a
run still in progress. So the stop is not mute, the owner learns of a
pause or a removed model through a personal
notification
(targeted at them) — the handler that sets the flag raises an event.
enabled. On, and the
agent is live: it runs on schedule and the “Run now” button is
available. Off, and it is dormant: the schedule is silent, the
manual run is disabled. The owner is free to flip it however they
like.
admin_paused,
sticky: the admin halts a specific agent without
waiting for the owner and without deleting it. The owner cannot
release it — a banner “paused by administrator” stays on the agent's
screen. This is the only lever the admin has over someone
else's agent.
Full oversight of others' agents — bulk actions, editing, fine-grained policies — is v2. The admin has exactly a lock: blunt, but enough to shut a problem down.
An agent lives on the owner's rights and wallet — so its fate is tied to the account. Two events decide everything: deletion of the account and deactivation (the account row stays). The main risk both close: a departed employee must not leave background agents behind that silently burn budget and read the store under their rights.
ON DELETE CASCADE), nothing is orphaned.
enabled=false) on all of their agents: the account
and history are intact, but runs freeze. The scheduler does not
wake them and accrues no skipped journal — a
switched-off agent sleeps silently. Reactivation does
not flip the switch back — the returning employee
switches their agents on themselves.
The cascade is described in the
data model: the
FKs from runs to agent and from agent to owner carry
ON DELETE CASCADE. Deactivation introduces no separate
state of its own — it writes that same enabled switch,
and only the owner may flip it back.