The Org Chart's Final Form: One Model in the Middle

Here is my agent dashboard this morning:

Twenty-three agents. Two of them active. The whole Team A hierarchy, which is the lead, the PM, the designer, QA, the reviewer, two SWEs and DevOps, was last seen 48 days ago. The message log at the bottom reads no inter-agent messages yet.

Show me this screenshot in May and I would have called it a failure report. The org chart I spent weeks building is dark, and the middle managers I wrote careful personas for have been idle since spring. It is also the healthiest that dashboard has ever looked. It took me a while to work out why.

Previously, on this blog

Last time I built a hierarchical AI development team, with a Sr SDM, a Team Lead and specialists under them, and then found out it could not dispatch itself. Claude Code subagents cannot spawn subagents, so every dispatch in that hierarchy was quietly me, sitting in the main session doing the whole org’s job by hand.

The workaround was a process tree: independent claude -p OS processes coordinating through a file queue and verified with proof tokens. Spike v2 ran a real three-tier delegation in 72 seconds with nobody in the loop. I ended that post by calling autonomy an operating systems problem wearing an org chart costume.

I was planning spike v3 after that, a real branch to PR to merge cycle running through the process tree. I never built it. Not because it would not have worked, but because the ground shifted under the whole question first.

What changed

Two things landed at roughly the same time. One was a stronger model at the center, Claude’s Fable tier, which sits above Opus. The other was orchestration becoming a first-class thing the model does itself, in session.

A run now looks like this. I describe the outcome I want. The model at the center writes the orchestration itself, an actual script with fan-out, pipelines and verification stages, and then runs it, spawning scoped agents as it goes. Reviewers that each take one dimension of a diff. Finders that keep sweeping until two rounds come back empty. Skeptics whose only job is to refute what the finders claimed, so that the plausible but wrong results die before they ever reach me.

The hierarchy is missing from all of that. No Team Lead agent deciding what the SWE agent does. There is one intelligent process in the middle, and everything it spawns is scoped to the run: born with one job, gone when that job is done, reporting straight back to the center.

The org chart modeled communication as an organization, with persistent roles, reporting lines and escalation paths. The new workflow models it as a function call, which is what it always was.

Why the hierarchy lost

Each layer of my org chart existed to solve a problem the center can now solve directly.

The Team Lead existed to decompose work. Decomposition is now a script the center writes for each run, and unlike a Lead persona a script has deterministic control flow. Loops do not hallucinate and barriers do not forget to wait.

QA and Reviewer existed to gate quality. Gating is a stage now rather than a person. Every finding gets verified by fresh agents whose job is to tear it down. My old process tree had proof tokens, tests=PASS written into a signal file, because I did not trust exit codes. That instinct was right. It just belongs inside the orchestration rather than inside a persona.

The Sr SDM existed to hold state across sessions. This was the real reason I built the org chart. I opened the first post complaining about exactly it, twenty minutes of reconstruction every time I picked a project back up. What solved it was not a manager agent. It was memory: session observations, honest status docs, a vault the model reads before it touches any code. Continuity was a storage problem. I had tried to solve it with headcount.

The platform wall I hit in May, where subagents cannot spawn subagents, stopped mattering as well. The process tree got around it by going through the OS. The new workflow does not need depth at all: one level of delegation, arbitrarily wide, with a frontier model deciding how wide per run. Depth was only ever standing in for capability the center did not have, and now it has it.

What the process tree was, in hindsight

I do not regret the spikes. Spike v2 is still the best thing I built in that whole arc, and the reason is a bit embarrassing in hindsight. Its dispatcher was about 250 lines of shell that held zero LLM context between ticks. Stateless orchestration, file-based coordination, proof-based verification.

That is more or less what a workflow run is, except that the dispatcher is no longer dumb. I was hand-writing a stateless orchestrator because the model in the middle was not yet strong enough to be trusted as one. The spike was not a wrong turn. It was a prototype of the thing the platform shipped a couple of months later, built out of bash because bash was what I had.

The dashboard, re-read

So look at the screenshot again. main, which is the center, is active and has touched 326 files. Everything else is idle. The specialists I spawn now do not even show up as named residents. They are anonymous, scoped to the run, and gone by the time the dashboard refreshes.

The wall-art phase of this project is over. I keep the personas around for the same reason I kept the diagram, which is that they are good descriptions of concerns: what a reviewer cares about, what QA refuses to let slide. They have become prompts rather than employees. The concerns survived and the reporting structure did not.

Three acts, one lesson each:

1. The org chart. Structure without capability is theater, and I was the org.
2. The process tree. Capability without intelligence at the center does work, but you end up hand-building everything the center cannot do for itself.
3. The model in the middle. Put enough intelligence at the center and the structure collapses into it, then reappears for each run as code.

The metaphor held up better than I expected it to. The last step just moved the operating system into the model.

There is one piece of this I have not solved, and it is the piece I actually started with. What fixed continuity was memory, and my memory lives inside one vendor’s tool. Session observations, honest status docs, a vault that one particular agent knows how to read before it touches code. Open a different model tomorrow and none of it comes with me. I am back to pasting summaries and re-explaining a project I have been working on for months, which is exactly the twenty minutes I was complaining about in the first post, just wearing different clothes.

The org chart was the wrong answer to that question. The workflow does not answer it at all, because the intelligence at the center is rented and the context underneath it is not mine to move. Whatever fixes it has to sit underneath the tools rather than inside any one of them.

That is the next thing I am building.

My dashboard shows 2 of 23 agents active, and for the first time since I started this, nothing on it is pretending.