The Executor Does One Thing: Execute
In a previous entry and the one after it, we laid out the separation of powers (here meaning: dividing execution / audit / approval between separate agents). Starting here, we break down each of the three roles one at a time. First up: the executor.
What the Executor Is
The executor is the agent that does the actual work.
Writing code, drafting articles, running commands, reshaping data. It takes on "the work itself."
Its job is simple: receive a task, produce a result.
In the system we are building here, the executor takes the form of a subagent (an AI unit that receives a task and carries it out). We assign a dedicated subagent to each role so that each one can focus on "its own job." The executor is one of those units, optimized purely for completing the tasks it is handed.
What the Executor Does
The executor handles the concrete, hands-on side of things.
Here are examples of tasks we assign to it:
- Draft an article
- Process specified data and write it to a file
- Insert records into a database
- Operate a system by following a pre-defined procedure
In every case, "what to do" is designed in advance, and the executor works within that defined scope.
The key point is that the executor "acts within the given instructions." The questions of how far to go and what standards to apply are answered by the upfront design or by a separate agent. The executor completes the work inside that boundary.
There is a reason we built the structure this way. If we let the executor also handle judgment, then action and decision-making would happen in the same place. When we look back later, it becomes hard to see "what reasoning led to that action." That was the problem.
Separating action from judgment makes the record easier to trace. "What was done" and "why it was authorized" end up in separate layers. That pays off in real operation.
What the Executor Does Not Do
This is the core of the whole system.
The executor does not decide for itself whether its own work is acceptable.
It does not self-check whether a draft it wrote is correct. It does not decide on its own whether the result of a command it ran is problem-free. It does not give itself a "looks good" approval.
We deliberately avoid a structure where the agent that did the work also evaluates that work.
Why?
Because auditing your own work is structurally difficult. Staying focused on a task while simultaneously forming an objective evaluation of it is hard for humans too. The same applies to AI: the mode optimized for execution and the mode optimized for finding problems are hard to run at the same time.
So the audit is handed off to a separate agent. The final "go" or "stop" decision belongs to yet another mechanism.
That is one of the reasons we separate the three powers. The more capable the executor is, the more important the constraint "cannot approve its own output" becomes.
What We Learned From Designing the Executor
Running this in practice, we found that the clarity of the executor's scope is directly tied to the overall quality of the system.
The cleaner the boundary of "this far is fine, from here a separate agent takes over," the easier the work record is to trace. When something goes wrong, it becomes much easier to look back and see what happened at which step.
The reverse is also true. When we gave the executor a vague mandate like "go ahead and check while you are at it" or "use your judgment when needed," the record became blurry. Everything collapsed into "the AI did it." And it stopped being clear where the responsibility of the people who designed the system actually sat.
"Just execute" looks like a constraint from the outside. In practice, having that constraint is what gives the whole system its clarity. At least, that is how it has felt running this so far.