How Much Autonomy Should an AI Agent Have? Make It a Setting, Not a Vibe
The argument about agent autonomy is usually about the wrong thing.
The useful question is narrower: when may a bounded model pass resolve ambiguity while preparing context, and who decides.
Short answer
Make it a setting rather than a vibe, and scope the setting narrowly. In Pathrule it is one control, AI activity, at three levels, and it governs a single thing: how much material ambiguity a bounded model pass may resolve while context is prepared. The budget is the same at every level.
What this covers
- The setting governs one narrow thing: when a bounded model pass may resolve material ambiguity while context is being prepared, not how the coding agent itself behaves.
- The budget does not change between levels. What changes is how much ambiguity preparation is allowed to settle before handing the card to an engine, and usage is shown as model passes today and rolling tokens against their limits.
- A workspace maximum can cap a member's chosen level, and the setting shows the chosen level, the effective level, and the fact that a ceiling reduced it, rather than lowering it silently.
- A ceiling that lowers a setting without saying so is a setting nobody can trust, which is why the visible distinction between chosen and effective matters more than the levels themselves.
Comparison
| Level | What it does | When it fits |
|---|---|---|
| Low, deterministic | Uses the knowledge layer and path coverage with no model calls at all | Regulated work, or a team that wants preparation to be fully reproducible |
| Medium, balanced | Limited model help, only for material blockers | The default for most boards |
| High, proactive | Resolves more ambiguity on its own, inside the same hard budget | A board of well-understood work where you want fewer stops |
The question is narrower than the argument
Discussions about agent autonomy tend to be about whether an AI should be allowed to act at all. That is a real question, but it is not the one a working team has to answer on a Tuesday.
The practical question is smaller and sharper. Before a card runs, its context has to be prepared. Sometimes that preparation hits a genuine ambiguity: two plausible readings of what the card means, or a missing fact that changes the approach. The question is whether a bounded model pass may resolve that ambiguity, or whether it should stop and wait for a person.
That is a setting. It should not be a vibe, and it should not vary by who happened to create the card.
Three levels over one budget
Low is deterministic: it uses the knowledge layer and path coverage, and makes no model calls at all. Medium is the balanced default, allowing limited model help only for material blockers. High resolves more ambiguity autonomously.
The important detail is what does not change between them. High is not a licence to spend more; the hard budget is the same at every level. What moves is how much ambiguity preparation is permitted to settle before the card is handed to an engine.
Usage is shown as it is spent, as model passes today and rolling tokens against their limits, so the setting is not an abstraction you have to trust. You can see what it cost.
The workspace maximum, and why it announces itself
An account default sets the level across your workspaces, and a workspace can set its own maximum on top of it. If a member's personal choice sits above that maximum, the choice is capped rather than overridden in silence.
The setting then shows three things at once: the level you picked, the effective level you are actually getting, and the fact that a workspace ceiling is what reduced it. That is more surface than a single dropdown, and it is worth it. A ceiling that lowers your setting without saying so is a setting you cannot reason about, and the first time you notice will be while debugging why a card behaved differently for you than for a colleague.
This is what makes a shared board predictable: an organisation decides how autonomous preparation may be, and every member sees that decision rather than discovering it.
Autonomy is only acceptable if it is legible
Autonomous preparation earns its place by being inspectable afterwards. A run reports which memories, rules and skills went in, which files were touched, and what it cost. It reports; it does not add another set of buttons to press.
That is the trade the whole design rests on. You get fewer interruptions, and in exchange the system owes you a receipt. If it cannot produce the receipt, it should not have the autonomy.
The [board settings documentation](/docs/studio/board-settings) covers AI activity alongside parallel runs, auto plan and the workspace maximum.