Agent Supervisor: Which Limits Belong in the App

A provider can be fine for source-code changes and still not be allowed near production data. Load balancing cannot express that. It hands out shares, and a share does not look at the task.

Two words carry the rest of this article. A fence is a limit the app checks on every call, whatever the agent thinks. A note is advice the agent reads and has to judge. They are this article's words, not menu labels, and the difference between them is the whole job of an agent supervisor.

In AuricIDE, a supervisor is an agent session you start from a tile in Quick Access. It starts other agents in the projects you have allowed, and it never does a project's work itself. The provider problem above got a free-text field in the project settings, the Routing note. The supervisor reads it before it picks a provider. The spawn check does not. A note such as "source changes only, no production data" asks for a judgment about the task. No fixed check can make that judgment. A model can. A model can also be wrong. Nothing in the app checks that call.

Is a better prompt the answer?

A better prompt can help. It cannot grant permission.

The obvious fix is a smarter supervisor: a strong model, a careful prompt, and it will manage the rest. That treats the supervisor like an employee who needs better training. The claim here is the opposite one. What a supervisor may do should be enforced by the app, not written into its prompt, because a prompt is a note, and a model can misjudge a note. Better wording makes the supervisor choose well more often. It does not change who enforces the rule, since the thing being limited is also the thing reading the limit.

A rule on the fridge works while everyone reads it and agrees. A lock on the door still holds when somebody forgets. Rewriting the fridge note never produces a lock. The picture has a limit, though: a lock cannot decide whether a coding task touches production data. That question stays with the supervisor, and the app can only bound what the supervisor is allowed to start.

The same split shows up in AI agent skills. A skill is a prompt plus a model plus a permission mode. The prompt describes the work, and the permission mode sets what the agent may do without asking.

What does the app enforce without asking the model?

Plenty. None of it depends on the model. Before a child agent starts, AuricIDE checks the project. It must be allowed, and so must the provider and the model there. The provider must not run without permission prompts. A project can also be headless only. That rules out interactive runs. Then come the limits, which default to two running agents per project and four per supervisor.

Size is a fence too. A supervisor that leaves the model out gets the smallest allowed one. From the larger sizes on, it has to state a reason, or the spawn is refused. A refusal comes back as an error with its cause. It is not a suggestion the supervisor can weigh.

Nothing is allowed until you allow it. A policy file that is missing or unreadable allows nothing, and a project starts out as not allowed. With no project allowed, the supervisor tile opens Settings instead of starting work. These are agent access controls in the plain sense of the phrase.

The fences also close in on the supervisor itself. It cannot choose a permission mode, because the policy names one per provider. It cannot start another supervisor. It sees only the agents it started, and any other agent looks like one that does not exist. Its file tools reach its own run folder and the workspaces of skills you approved, and its shell accepts timer sleeps and the commands you approved under Settings. Everything else is refused, not asked.

Watching is partly a fence as well. If a child agent shows no real activity for 15 minutes (the default), the app itself sends one status check into an interactive child, and tells the supervisor about a headless one. The supervisor's judgment is not involved. If the supervisor is gone, the notice goes to the human's inbox.

Notes are what is left.

The supervisor reads routing notes, load-balancing shares, your standing instructions and the rule for which questions it may answer for a child. Even its habit of saying which project and model it picked, and why, before each spawn is a note. No check reads any of them.

What does it cost?

Setup takes work. Notes leave a judgment gap. The fences are yours to write, project by project.

A child agent can stop on a question or a permission prompt. AuricIDE lets the supervisor type into its own interactive children, because otherwise a person carries every answer from window to window. Which questions the supervisor may answer itself is a note. Read-only commands, the project's tests and edits in the child's own folder fall inside it. Anything destructive, outward-facing or costly goes to the human.

AuricIDE trades a human click per question for fewer interruptions, and the design record states the price. A supervisor that ignores that note can approve whatever its child asks within the child's permission mode. The mode is a fence. The damage has a ceiling. Whether this particular question deserved a human is a note. Nothing guarantees that call. A strict mode lowers the ceiling. It cannot make the judgment.

A smaller price: there is no built-in second chance. Nothing in the supervisor's rules tells it to retry a failed child. It reports the failure, and any retry is a new spawn that passes the same fences.

Where does a Project Manager fit?

A Project Manager is a supervisor with a name and a memory. You promote a run from the Supervisor Runs rail, or create one in Settings. It keeps its folder. It gets an INSTRUCTIONS.md and starts keeping notes under knowledge/.

The same two layers apply. INSTRUCTIONS.md belongs to the human. The manager's prompt says so, and its launch also denies the manager's Edit and Write tools on that file. The note tells the manager how to behave, and the tool limit still holds if it ignores the note. The rule that a wrong fact is marked deprecated and never deleted lives only in the manager's prompt, so it is a note.

A schedule can open a Project Manager on its own, if you pick Start by itself, in the background and with a task you wrote. A task written by a model is never handed to a manager. The schedule decides when. The fences still decide what that manager may start, and the schedule runs only while the app is open.

Which of your rules should be fences?

Sort every rule you give an agent into two piles. If breaking it cannot be undone, it needs a fence. If it has good exceptions and a wrong call is cheap, a note is fine, because a fence bends for no one.

Some rules sit in between, and the production-data case is one. The app cannot check what a task touches. So the only fence is blunt: leave the provider out of that project's list. The routing note buys the middle ground: that provider, for source changes only. The price is trusting a judgment. Take that trade only where a wrong call can be undone.

Never rely on a note for anything you could not undo. That holds in any tool where one agent can start another.