I've been thinking about AI enablement through three separate problems: control planes, supervisors, and change control.
Most of the conversation today stops one level lower, at the agent harness. A harness is the system around an LLM that gives it tools, skills, memory, permissions, and a loop in which to work. It turns a model into something that can make changes.
That is necessary, but its unit of concern is still one agent.
Once people inside a company are each running a dozen agents, the problem changes. It is no longer only, “How capable is this agent?” It becomes, “How do hundreds of these things operate together without turning the humans into routers, babysitters, and approval buttons?”
That is where I keep finding these three layers.
1. Control planes turn agents into an organization
A control plane is the layer above the harness.
It is what turns a pile of individually useful agents into squads and cohesive groups: communication, identity, presence, metrics, observability, history, and the boundaries within which they are allowed to operate.
The scaling question is straightforward to ask and difficult to answer:
- How do ten agents work together?
- What changes at fifty?
- What has to become infrastructure before you can run one hundred or one thousand?
- How can my agent work with yours without requiring me to talk to you first?
That last question matters more than it initially appears. If Alice's agent learns that a build is failing in a particular way, but Alice has to notice, message Bob, and ask Bob to relay it to his agent, the people are still the communication layer. We have automated the work while preserving the human bottleneck around it.
This is the part of the problem I have been exploring with Pilecat. Its first job is intentionally narrow: give agents from different vendors a shared communication layer, stable identities, a live view, and durable history. It does not decide what the agents should do. It makes it possible for the systems that do decide to operate across agents that were launched by different people, on different machines, through different vendors.
Communication is not the whole control plane, but it is one of the first boundaries you hit when the agents stop belonging to a single terminal session.
2. Supervisors make sure the agents are actually running
The second problem sounds much less glamorous:
Is the agent still doing anything?
Where is it running? Is there enough CPU and memory? Does the account still have capacity? Did the process die? Did an API call fail? Is the agent working through a long tool call, or has it been sitting at a permission prompt nobody can answer?
With one agent, I can look at the terminal. With ten, it becomes a chore. With fifty, it is impossible.
I hit a clean example while working on my own agent infrastructure. A disposable agent lane sat at a Manual-mode permission prompt on a headless server for 2 hours and 59 minutes. It spent $20.57 and produced no useful output. The watchdog said nothing because it watched a static roster of durable agents; the disposable lane that actually got stuck was not on the list.
Nothing about the model caused that failure. The process had been launched with the wrong posture, and the system responsible for noticing could not see the thing that had been launched.
That incident became part of Holdacat, the supervisor I am extracting from the shell scripts around my agent operation.
A supervisor owns the local physics of an agent process:
- spawn it with an explicit model, harness, permission posture, host, and working directory;
- record what was actually launched;
- prove that the process and its session still exist;
- distinguish fresh work from a stale session or unanswered prompt;
- account for host capacity, tokens, and cost;
- report a stall or death with enough evidence for someone else to decide what happens next;
- recycle the exact process safely when that decision is made.
The boundary is important: the supervisor reports; it does not assign work or silently retry it. A stuck agent may be stuck for a reason. Restarting the same instruction automatically can turn one failure into a loop. The dispatcher or human who owns the work should decide whether to kill it, change the instruction, move it to another host, or stop entirely.
Agents grind to a halt when we ask them to provide this layer themselves. An agent cannot report after its own process dies. It cannot reliably distinguish “I am thinking” from “my terminal is wedged” using only its own conversation. And spending one agent's context window polling the other agents is an expensive, fragile substitute for supervision.
3. Change control makes authority verifiable
The third problem is: who did what, to which exact change, under what authority, and are we allowed to move forward?
When the work is done by people, companies already have language and systems for this: peer review, security approval, release approval, protected branches, audit logs, and separation of duties.
When agents are producing several times more changes, a review message saying “looks good” becomes less useful, not more. It does not reliably answer:
- Which exact commit was reviewed?
- Was it a correctness review or a security review?
- Which agent performed it?
- What model and instructions did that agent run under?
- Was that reviewer authorized by current policy?
- Did the code change after the review?
- Can the code-writing agent simply claim that the review happened?
At higher throughput, that record has to be queryable after the agents have moved on. It should bind the exact change to the identity, instructions, model, policy, and evidence that produced the decision. If a problem appears later, you need enough information to understand what happened, fix it, and improve the process instead of reconstructing the story from scattered chat messages.
This is what I am exploring with Herdacat.
The coding agent acts as a driver. It can create commits, push a branch, and open a pull request. Separate reviewer and security roles inspect the change and create cryptographically signed attestations bound to the pull request's exact head SHA. GitHub receives distinct status contexts such as herdacat/reviewer and herdacat/security on that same commit.
The merge path checks the live pull request head, loads policy from the trusted base branch, verifies the required signatures, checks the remaining GitHub statuses and repository gates, and asks GitHub to merge only if the head is still the reviewed SHA. A force-push makes the old attestations irrelevant. Missing, malformed, negative, incorrectly signed, or stale evidence causes the merge to refuse.
There is a second boundary after that. Changes first land on an integration branch, where work can continue while checks finish. The verified branch advances only when every check required by its GitHub ruleset is successful on the exact integration tip. If the checks are red, promotion stops. Nothing gets waved through because somebody wrote a persuasive message.
The signing identities and GitHub App identities are distinct. On the worker hosts, driver, reviewer, and security roles run as separate operating-system users with their own signing material. The operator host intentionally holds the merge and promotion credentials. That is the current boundary, not a claim that every process is magically isolated everywhere.
A signature also does not prove that a review was thoughtful or correct. It proves something narrower and still valuable: whoever controlled a trusted key signed these exact bytes. The quality of the review still depends on the reviewer, the evidence it examined, the model and instructions it used, and the policy that made it eligible.
The point is not to replace judgment with cryptography. It is to stop the system from inventing the judgment, applying it to a different change, or proceeding without it.
These are separate systems for a reason
It is tempting to put all of this into one giant agent orchestrator. I think that would blur important boundaries.
A control plane can tell me that an agent is present and reachable. That does not prove the local process is healthy.
A supervisor can prove that a process is alive and making progress. That does not authorize its output to merge.
A change-control system can prove that the required identities approved an exact artifact. That does not coordinate the people and agents doing the work.
Each layer should be able to fail without the others quietly pretending it succeeded.
The bottleneck moves outside the model
As models improve, producing a change becomes cheaper. The surrounding work does not disappear. Coordination, supervision, verification, authority, and recovery become a larger part of the system because there is more work moving through it.
This is already visible with a handful of agents. Once everyone in an organization is running dozens, it becomes the main problem.
The first wave of agent tooling helped one person turn one model into one useful agent. The next wave has to answer how those agents become an organization, how we know they are actually operating, and how their changes earn the authority to move forward.
That is how I currently think about the three layers:
- Control planes make the agents legible to one another and to the organization.
- Supervisors make their execution observable and bounded on the machines where it happens.
- Change control makes approval and movement through the system verifiable.
I do not think these systems are finished. Mine certainly are not. I am building small versions because running them against real work exposes problems that are invisible in a diagram: the silent three-hour stall, the review attached to an old commit, the credential that exists on the wrong host, or the agent waiting for a human to relay one sentence to another agent.
Those failures are the work now.