Jeffrey JohnsonRSS

The Operator Problem

By Jeffrey Michael JohnsonPublished: July 11, 20268 min read

The essay that names the control-plane gap between AI coding tools: state, memory, approval, and output handoff. Three projects, six months, one recurring shape.

The shape of the problem

Claude Code is great at one thing at a time. The moment you need it doing two things, you become the scheduler, the router, and the memory store.

That sentence is the whole problem, so I will say it slower. One agent has a terminal, a working directory, and your attention. Two agents have two terminals, two working directories, and half your attention each, plus a new job that did not exist a minute ago: deciding who works on what, noticing who is stuck, remembering what each one knows that the other does not, approving the dangerous steps, and merging the output. That job has a name in every other field that runs fleets. In aviation it is the controller. In manufacturing it is the line supervisor. In agentic AI it is currently you, tabbing between terminals.

I call it the Operator Problem: the gap between what N agents can produce and what one human can safely operate. The models get better every quarter. The operator does not scale at all. Everything interesting in multi-agent tooling lives in that gap.

Three generations of hitting it

I have run into this wall three times, and each time it moved.

MCP-WP (Nov 2025): file-based coordination. Agents wrote their status to disk and read each other's files. It worked, 96 autonomous commits logged to disk, and it taught me the first lesson: coordination without observation is abandonment. The commits were on disk. Nobody was watching them land. An agent that had gone sideways looked identical, from the outside, to an agent that was almost done.

Autonomous Agent System (Apr 2026): ten subagents sharing a Supabase pipeline. Now the state was queryable, which felt like progress, until two agents needed the same file and the pipeline had no opinion about it. Shared state is not coordination. It is a place for collisions to become visible after they happen.

Mother (Apr 2026, in progress): the current attempt, and the first one shaped like an answer instead of a workaround. One Rust trait, AgentDriver, with spawn, send, approve, and stop, that every agent CLI implements, so Claude Code, OpenClaw, Hermes, Codex, and a plain shell all normalize into one SessionEvent stream: Working, WaitingForApproval, Done, Error. Five first-party drivers behind that trait today (counted at the boot registration site, not on a marketing page). A dockview terminal grid that knows the difference between an agent that is thinking and an agent that is waiting on me, because those two states cost the operator completely different things.

What the control plane actually has to do

Naming the states was the easy third. The rest of the operator's job decomposed into things I did not expect to have to build:

Contention. Two agents editing one file is not a merge problem, it is a scheduling problem, and it has to be solved before the edit. Mother uses advisory file leases with TTLs, acquired in sorted path order, the same deadlock-avoidance rule databases have used for decades, applied to coding agents. Boring, old, correct.

Policy. Which model tier does a task deserve? What may this agent touch? What does it cost before someone asks a human? Every one of those answers used to live in my head, which means they were applied inconsistently and audited never. Now they are code: each task class deterministically fixes its model tier, cost ceiling, tool allowlist, and approval mode, and a conformance test fails the build if a definition drifts. The policy is not what I intend. It is what the test enforces.

Attention. An agent that dies loudly is easy. The dangerous one is the agent that stops sending anything at all. The fleet's monitor alerts on the absence of heartbeats, a missing signal is the signal, because silence is what an abandoned lane actually sounds like.

The brakes. Off-switches at global, department, and playbook scope, cooldowns, and circuit breakers that trip after three faults (the threshold is a constant in the source, not a tuning legend). The halt switch was drilled live before it was trusted. Autonomy without a tested brake is not autonomy; it is momentum.

What operating actually looks like, right now

The control plane above describes the machinery. It does not describe Tuesday.

On a real build day I am running six terminals at once, each on its own workstream, and I am watching all six the way a line supervisor watches a floor, not the way you watch a video. When a session claims a fix, I do not take the claim. I ask for the one experiment that would prove it wrong, the cheapest disconfirming test available, and I wait for that result before the next terminal gets my attention. When a session drifts toward a hunch instead of a root cause, a reminder timed to land before the wrong fix ships is worth more than a longer prompt would have been. And when a problem is actually hard, worth the tokens, I say so directly: think harder, build it right, the kind of instruction a model does not reach for on its own but responds to immediately once asked.

None of that is automated yet, and this essay does not pretend otherwise. The leases, the policy tests, the heartbeat alerts: they buy back the parts of operating that were mechanical. What is left is the part that was never mechanical: knowing which of six terminals needs you next, and asking the one question that actually tests the claim instead of accepting it.

What's still unsolved

Mother is mid-build. This is an investigation, not a victory lap.

The leases stop file collisions; they do not stop two agents from making contradictory decisions in different files. The workflow engine that would let the control plane sequence long jobs end-to-end is built and not yet user-reachable, that gap is written down in the repo's own inventory rather than smoothed over here. And the hardest resource is untouched by all of it: the operator's judgment still gates every approval, and judgment does not shard.

The reframe

Most of the public conversation is still about which model is best, as if the model were the product. Run more than one agent for a week and you learn what the product actually is. The model is the engine. The thing that is missing is the cockpit.

The Operator Problem does not get solved by a smarter agent. It gets solved by admitting that "operator" is a real role with real tooling, state you can see, approvals you can queue, policy that enforces itself, and a brake you have actually pulled.

Occasional updates when I publish. No spam.