Superagent and crews
One director in front of every agent you use
You describe an outcome. The superagent works out how many agents the job needs, which vendor fits each part, what each of them is allowed to touch, and how their work joins back together. You keep the decisions that carry consequence, and you stop being the message bus between four terminals.
One mission, laid out the way the runtime holds it
The coordinator receives the mission, writes a role contract for each lane, allocates the context each lane gets, and holds the gate at the end. Select any part of it to read what that piece does.
Selected record: The coordinator holds the plan and the gates
The coordinator holds the plan and the gates
It decides how many lanes the work needs, writes each role contract, allocates context to each lane and stops the run at the points a person has to decide.
Claude Code · coordinate class
Connected records
Crew planning
The crew is assembled for the mission rather than fixed in advance
A one file fix does not need four agents. A migration across a payment path does. The superagent sizes the crew against the work, and it can resize while the work is still running.
- Spawn, steer, pause, interrupt, resume, fork, reassign, replace and archive agents while a mission is live
- Resize the crew when the work turns out larger or smaller than the plan assumed
- Choose the context and memory budget each agent gets for each turn
- Ask you for more agents, more time or more money when the approved envelope is not enough
- Verify packets, checks, reviews and coverage before letting the mission move on
You can pin the crew exactly
You can name an exact crew, an exact count, a maximum, preferred vendors or required roles. Exact instructions are binding. Recommendations are weighted. Automatic mode only operates inside the concurrency, vendor, authority, time and cost envelope you approved.
If the crew you asked for is impossible, MUON tells you which capability or budget fails instead of quietly substituting a different crew.
Role contracts
Dynamic roles inside three fixed safety classes
A role contract declares its purpose, the scope it owns, the capabilities it needs, its authority class, its tool boundary, its sandbox, the evidence it owes, its communication duties and its budget. Roles are composed per mission. The safety classes underneath them never move.
coordinate
Plans the mission, dispatches and steers other agents, holds the gates. It cannot write to the repository itself.
write
Holds a worktree and a file claim, edits code, runs the tools its role allows. It cannot widen its own scope or merge.
read-only
Explores, traces, reviews and reports. It can propose memories and raise findings, and it can never change a file.
A dynamic role may narrow a lane. It can never manufacture authority that its lane or its parent does not already hold. This is the rule that lets the superagent be genuinely creative about crew design without any of that creativity reaching your permissions.
Recursive crews
No hidden second organisation
Most agents can spawn their own subagents. Left alone, that creates a shadow team nobody records and nobody governs. MUON either disables vendor native subagents for a governed run, or creates them through a child broker.
- Every child records its identity, its parent, its scope, its budget, its session, its worktree, its messages, its evidence and its terminal state
- Depth, active concurrency, lifetime issuance, wall clock reservation and cost policy are independent limits
- A child can never hold authority its parent does not hold
- Your topology constraints apply to descendants exactly as they apply to the first level of the crew
The limits on the superagent
The superagent cannot confirm its own claim as company truth, raise its own budget, widen its own permissions, expose a secret, or merge without the policy that applies to the repository. Those are the boundaries that make everything above them safe to automate.
Context allocation
Each agent gets the context its role actually needs
The reviewer needs the constraints and the diff. The implementer needs the file, the callers and the decision history. The explorer needs breadth. Giving all three the same prefix wastes the window and buries the part that matters.
Context allocated for one turn
200,000 TOKEN WINDOW · IMPLEMENTER ROLE
- Authority and role contract8%
- Mission and task brief12%
- Standing canon14%
- Task relevant memory18%
- Code and decision evidence22%
- Live coordination state9%
- Conversation continuity7%
- Response headroom10%
The shares move with the role, the phase of the mission, the risk of the change and how much the crew already knows. Every turn records what was eligible, what was included, what was left out and the reason for each.