Operate

Guardrails are the limits you put on an agent so that when something goes sideways it stops for a reason you can read, rather than running all night.

You'd give a new hire a company card with a limit on it. Same idea. Not because you expect trouble, but because a stuck agent at 2am should cost you nothing and leave a clear note about what happened.

The two-minute version

If you read nothing else on this page, do these three things before an agent works without a person watching:

1. Give it only the actions it needs. This is the strongest control on this page, and the one most often skipped.
2. Put an approval in front of anything that leaves the building. See interactions.
3. Set the routine's spending ceilings deliberately when you approve one, rather than accepting whatever was proposed.

The rest of this page is what each of those does, and where you see it working.

What each guardrail is for

One thing worth internalising: a guardrail stop is not a failure. When work stops because it reached a ceiling you set, the limit did exactly its job. Read it as good news about the limit, then go find out why the work needed more than you expected.

Bound what the agent can reach

An agent can only call the actions you granted it. That grant is the guardrail that operates before anything else, because a capability an agent does not have is a capability it cannot misuse under any prompt.

Give an agent the narrowest set that lets it do its job, with the narrowest provider permissions behind each one. An action's Read-only, Idempotent, and Destructive annotations describe expected behavior; they do not turn a mutating endpoint into a safe one.

When you find yourself reasoning about whether the agent will use a dangerous action carefully, that is the signal to withhold it instead. See tools and skills.

Put a person in front of the irreversible part

For anything that sends, deletes, purchases, or changes something outside Mobius, instruct the agent to open an approval interaction and wait. Be specific about which operations require it, who to ask, and what to show them:

Before you send anything to a client, open an approval interaction targeting
the service desk lead, with the exact text you intend to send. Send it only
after the request is approved. If it is rejected or expires, stop and say so.

Give every interaction a deadline, and decide what should happen when nobody answers. Approval is not a rollback: it protects the call that comes after it, never one that already happened.

Warning: Retrying a failed tool call does not make a destructive action safe. Mobius can call again; it can't unsend the email. Use the provider's duplicate protection where it exists, or put an approval in front.

Ceilings on a routine

A routine is where unattended spend actually happens, so it carries two ceilings and you approve both:

The proposal card shows both, plus the largest amount the routine could spend over the next 30 days and how many times it would fire in that window. Read the 30-day figure before approving. That is the number that turns out to be surprising, not the per-occurrence one.

Ceilings are enforced between operations, not in the middle of one. Mobius won't kill a model call halfway through and leave you with a half-finished mess. In practice that means an occurrence can finish slightly above its ceiling, by whichever call was already in flight, so don't set one so tight that a single extra call matters.

A clock on every turn

Every agent turn has a wall-clock limit: 10 minutes by default, raisable to 30. Set it on the agent under Advanced > Turn timeout.

The clock counts time the agent spends working, not time it spends waiting on you, on an approval, or on an event. A turn that waits overnight for an approval has used none of its limit and cost nothing while it waited. See agent time limits for the full behavior.

Organization-wide limits

Ceilings bound one routine. The organization's credits bound everything.

Open Organization > Billing. Owners and Admins can set a default current-period credit limit for each person, and see per-person usage against it. When the organization's included allowance and wallet are both exhausted, work stops rather than continuing to bill.

Set a per-person default before you widen access to agents, not after. See billing and usage.

The repeat-call breaker

An agent that keeps making the exact same tool call with the exact same arguments is stuck, not working. Mobius stops that turn automatically after ten identical calls, and the transcript says why.

This one you do not configure. It exists so a loop of identical calls costs you ten calls rather than a night's worth.

What to keep an eye on

• Routines that hit their ceilings. Once is informative; every day means the ceiling is wrong or the routine is.
• Interactions sitting open far longer than the decision should take. Usually a person who never saw the request.
• Failed turns, grouped by agent. A single agent producing most of them usually has an instruction or a tool problem, not a platform problem.
• Your artifact storage, before you let an agent generate big files unsupervised.

Before you leave an agent unattended

1. Grant it only the actions it needs, with the narrowest provider permissions.
2. Instruct it to ask for approval before anything irreversible, and name who to ask.
3. Set a deadline on every approval, and decide what silence means.
4. Set the turn timeout to what the work actually needs, and no more.
5. Set the routine's two ceilings from the 30-day figure, not the per-occurrence one.
6. Set a per-person credit limit for the organization.
7. Read the first few real occurrences in the transcript before widening scope.

FAQ

Why can an occurrence spend slightly more than its ceiling?

Mobius enforces ceilings at checkpoints: before the next model call, after a metered action records usage, and between tool iterations. The call already in flight is allowed to finish, so final spend can include one extra call.

Should the agent check something, or ask a person?

Have it check when the answer is in evidence it can fetch: an exit code, a returned record, a file that exists. Have it ask a person when the decision needs judgment or authority.

Prefer evidence the agent did not produce. "The test action exited 0" is a real check. "Ask the agent that did the work whether it went well" is not; it is a poor judge of its own work, and it is not lying when it says yes.

What's a sensible starting ceiling?

For a routine with one agent turn and a couple of actions, a few credits per occurrence is generous. Approve that, let it fire a few times, then look at what it actually cost and tighten toward reality.

Too tight is a nuisance; too loose defeats the point. Erring loose for the first week and then tightening is the usual approach.

Next

• Choose the right deadline with agent time limits.
• Approve schedules and ceilings in routines.
• Decide what an agent may reach in tools and skills.
• Understand plan charges and credit records in billing and usage.
• Put a person in the decision with interactions.