The five levels, as workflows
A level is not a setting. It is a shape you can see.
Every canvas below is a real ClusterCode workflow definition, drawn by the same renderer the product itself uses — not a diagram of one. They walk the same four stops, and the only thing that changes from one to the next is how many approval gates are left standing. Drag to pan, scroll to zoom, click any node to read what it does.
Level 1 — Operator
0 approval gatesYou direct the planning. The agent supports on demand.
One run node, and no gates — because at this level the rest of the workflow is a person in their own terminal, not something the graph is holding back. This is the only rung where zero gates means the opposite of level 5.
Level 2 — Collaborator
3 approval gatesYou and the agent plan and execute together.
The whole path is in the graph for the first time, and a person answers at three of its four stops. Only the plan runs unattended.
Level 3 — Consultant
2 approval gatesThe agent leads. You give feedback and guidance.
The verification gate goes first. Once the suite is the thing you trust, a person confirming that a green suite is green adds nothing — so the decision node keeps it and the human stop disappears.
Level 4 — Approver
1 approval gateYou approve consequential actions. Otherwise minimal involvement.
One stop left, at the pull request. Everything up to it — plan, build, the loop back on a red suite — happens without you.
Level 5 — Observer
0 approval gatesYou monitor only, with no intervention except an emergency stop.
No approval node left. The last gate did not vanish, it became a deterministic check the agent runs itself, and a failed one routes back into the loop instead of to a person.
Moving between levels
A level you cannot reverse is a bet.
This one is a graph you edit.
The reason the gate count matters more than the label is that it is the thing you can actually change. Your position on the scale is not a plan tier, a support contract or a setting in our admin panel. It is the shape of a workflow your own architects drew, which means moving is an edit and moving back is the same edit in reverse.
You remove one gate, and only one.
A level is not a plan you upgrade to. Open the workflow, take out the gate that has stopped surprising you, and leave the rest. Most teams take out the plan gate first, because after a few dozen runs the plans stop being the thing they worry about.
You put the gate back, the same afternoon.
This is the part that makes the whole thing adoptable. Nothing about a higher level is a commitment: a gate goes back into the graph in a minute, and it applies to the next run. A level you cannot reverse is a bet, and nobody signs off on a bet.
The evidence is the run history, not our word.
Every run keeps its ticket, its diff, its transcript, the machine it ran on, and the gate events. When you argue internally for moving a row up a level, that history is the argument. We do not publish a success rate, because the only one that matters is yours.
Why nobody adopts a level company-wide
The question is never whether you trust the agent. It is whether you trust it with this. A dependency bump and a change to the billing path are not the same bet, and a single setting cannot be right for both. Because a level is just the gates left in a workflow, and each kind of work has its own workflow, each carries its own level.
In practice a team ends up spread across the scale: routine maintenance sitting high, anything touching customer data sitting at one, and one row in the middle that they are actively arguing about. That spread is the honest picture, and it is the one your risk function can sign.
The five levels are from Kevin Feng, David McDonald and Amy Zhang, “Levels of Autonomy for AI Agents”, Knight First Amendment Institute at Columbia University, 2025, also available on arXiv. We did not invent the scale and we do not control it, which is the point of using it. The gate counts under each level are ours.