Use this guide before enabling recurring work or changing its limits. The owner or a specifically authorised admin must make the relevant management change. Mind settings explains where personal and workspace controls differ.
Bound what an installed agent can use
An installed agent is a program with its own identity. Review its declared record access, permitted actions, service connections and model route. Its grant can expire independently of its budget. A program that lacks a required route or connection cannot solve that by asking for a larger spending cap.
Choose access explains human access; an installed program also needs its own approved scope. Install an approved agent covers the review and installation steps.
Understand the model budget window
Installed app model caps cover input tokens, output tokens and accounted cost over a rolling seven-day window. The Mind checks the amount already spent before admitting another call. A final admitted call can take the total past a cap; this is not a reservation of an exact maximum for an in-flight request.
An authorised operator can set explicit app caps or restore the bundle's declared caps. A zero cap can prevent scheduling. Increasing a cap is permission to spend more within the existing authority, so agree it for a stated job rather than treating it as a routine retry.
Subscription-backed routes can account for a call with zero monetary cost while still consuming tokens. Keep the token caps meaningful; the displayed cost alone cannot bound that route's work. Personal account usage displays and provider billing are separate from these per-app controls.
Set loop case limits separately
A loop case has its own limits, including maximum steps, wall-clock duration and model-check spending. The definition can also bound simultaneously open cases and outstanding escalations. These are separate from an installed action's app budget. One healthy meter cannot establish that every limit has headroom.
When a limit stops work, inspect the named reason and case state before changing it. Waiting for the rolling window to reopen, correcting the workload and explicitly changing a cap are different decisions.
Separate limits answer separate questions
Check the reason attached to the work that stopped.
Record and service access decides which information and actions are allowed. An app’s model caps bound already-accounted input tokens, output tokens and cost over a rolling seven-day window. A loop’s case budget separately bounds steps, wall-clock duration, judge spend and open-case capacity. Earned autonomy decides whether a particular action waits for a person within its approved ceiling. One healthy limit does not override another refusal.
Earn and reduce autonomy for specific actions
A loop can define a ladder from shadow to draft to automatic execution within an approved effect ceiling. Its earned level belongs to a particular action in a particular loop, not to the whole agent. Qualifying approvals can build a clean streak; corrections and rejections can reduce that action’s autonomy. Some case failures and escalations reset the loop’s earned levels.
Owner-approved ceilings and daily action limits still apply. Financially material actions cannot reach unattended automatic execution. An authorised person can intervene through the supported operator controls. Do not infer an action may run unattended merely because another action in the loop does. Inspecting a case shows what actually occurred.
Related
Practical guides for people and agents