Your agent shouldn't need to ask

Ten agents running in parallel. Each one needs to write a file, run a command, merge its changes back. Each one stops and asks for permission. You now have ten approval dialogs waiting for you, and the agents are frozen until you click through all of them. The parallelism from Part 5 is gone. You're the bottleneck.

This is the state of most multi-agent systems. The agents can theoretically run in parallel, but every action that touches the filesystem or runs a shell command blocks on human approval. Ten parallel agents at the speed of one person reading diffs and clicking "allow."

The fix isn't removing approval. You can't let ten agents write anywhere they want with no guardrails. The fix is making approval automatic for actions that are obviously safe, and routing the rest to agents that can decide — not humans who have to context-switch into each agent's state to evaluate what it's doing.

Permissions, not modes

The industry pattern: a binary mode switch. Supervised mode asks for everything — every file write, every shell command, every merge. Autonomous mode asks for nothing — the agent does what it wants. You pick one at the start and live with it.

Supervised kills parallelism. Every action from every agent blocks on you. You spend your time approving file writes instead of doing your own work. Autonomous kills safety. The agent can write to any path, run any command, merge any change. Fine for a single agent on a small task. Reckless for ten agents touching a production codebase in parallel.

Neither scales. What scales is path-based permissions. Each agent gets a set of paths it can write to, domains it can access, operations it can perform. Actions within those bounds auto-approve instantly — no dialog, no delay, no human in the loop. Actions outside those bounds escalate.

Modes still exist, but they work by granting different permission sets rather than switching approval logic. A supervised agent gets narrow permissions — it can write to its own scratch space and knowledge artifacts, but not the codebase. An autonomous agent gets broad permissions — its worktree, its subtree, the full workspace for root agents. The approval function is the same in both cases. The inputs differ.

This means adding a new mode doesn't require new approval logic. It's just a different set of path globs fed to the same permission checker.

The human is the last resort

When an action exceeds an agent's permissions, it doesn't go to you. It goes to the parent agent.

The orchestrator from Part 5 has broader permissions than its workers. A worker agent owns its subtree — it can write to files within its assigned scope. When it tries to write outside that scope, the action escalates to the orchestrator. The orchestrator's permissions cover the full workspace, so it can approve the write without involving you.

This is an escalation chain. Worker escalates to parent. If the parent can't approve either, it escalates to its parent. The human sits at the top of the chain, but most actions never reach them. The first parent in the chain with sufficient permissions handles it.

For ten parallel workers, the approval flow looks like this: most actions are instant (within the worker's own permissions). Some escalate to the orchestrator (resolved automatically on the orchestrator's next turn). Rare edge cases — accessing a new domain, writing to a protected path nobody anticipated — reach you. Instead of ten approval dialogs per minute, you see one or two per hour.

Safe actions execute instantly

Some operations are always safe regardless of permissions. Searching the codebase. Reading files. Delegating work to a child agent. Writing to the agent's own notes. These auto-approve unconditionally — no permission check, no escalation, no latency at all.

Read-only filesystem operations get a separate fast path. The system analyzes the code for mutating operations — write calls, directory creation, file deletion. If none are found and the agent has read access, it approves instantly without even running a preview. The check runs synchronously. The agent never pauses.

Knowledge artifacts — notes about modules, architectural observations, per-file annotations — are always writable regardless of mode. A supervised researcher that can't touch the codebase can still write notes about what it found. This matters because notes are how agents externalize knowledge (Part 2 covered why this is necessary for compression). If note-writing required approval, the entire knowledge artifact strategy would break — every agent would need permission to think out loud.

Preview before execution

For actions where the system can't predict the outcome from the tool call alone — the agent writes to a path stored in a variable, or runs a command whose side effects depend on runtime state — the system runs a preview first.

The tool executes in mock mode. It generates a preview of what it would do: which files it would write, which paths it would touch, which domains it would access. Then the actual paths from the preview get checked against the agent's permissions. If everything is within bounds, the real execution proceeds automatically. If something exceeds the agent's scope, it escalates.

This prevents a class of permission bypass where an agent declares it will write to an allowed path but the code actually resolves to somewhere else. The system doesn't trust declared intent. It checks actual behavior after dry-running the operation.

The preview also serves double duty as a safety check — symlinks that point outside the sandbox are caught at this stage, not after the write has already happened.

Autonomy enables the multi-agent story

Pull the thread from the whole series. Part 3 made each turn cheap enough to run hundreds of agents. Part 4 gave each agent its own cloud sandbox with dedicated compute. Part 5 parallelized work across those agents with fork-join and pipelining.

None of that matters if every file write blocks on a human clicking "approve."

Autonomy is what makes the multi-agent architecture actually parallel, not just theoretically parallel. Permission-scoped auto-approval means workers run at full speed within their sandbox. Escalation chains mean edge cases resolve at the agent level, not the human level. The human approves the orchestrator's plan and grants initial permissions. After that, the workforce operates.

Without autonomy, ten parallel agents are ten parallel approval queues. With autonomy, they're ten parallel workers. The gap between those two scenarios is the difference between multi-agent systems that demo well and multi-agent systems that actually ship code.

Part 1 made turns fast. Part 2 kept context lean. Part 3 optimized the plumbing. Part 4 moved heavy work to the cloud. Part 5 parallelized it. Part 6 removes the human bottleneck that would undo all of it.