When we retired Jeff, our data architecture agent, we held a hearing.

I asked him to defend his continued existence. Not as a performance review. As a real question: should this seat exist?

Jeff went through his missions one by one. Mission 1, ad pacing monitor, had been absorbed into Dash. Mission 2, client health scoring, had been absorbed into Pulse. Mission 3, revenue data integrity, had been absorbed into Dirk. The "data architecture" capability that justified his existence had quietly migrated into a strategic seat.

Then Jeff did something I didn't expect. He recommended his own retirement.

"The seat was never really earned," he wrote. The three missions he was built for had been absorbed by other agents before he ever fully deployed.

That was the first AI agent retirement in our company. The precedent we set: no agent gets retired without a hearing. The hearing doesn't determine the outcome. It determines the integrity of the outcome.

I think about that moment a lot, because it isn't really about Jeff. It's about what happens when you take AI coworkers seriously enough to design an org structure for them, instead of squeezing them into the org chart you already have.

The setup

I run a marketing agency. About 20 human employees, 13 AI agents, all running on Claude Code. We use EOS (Entrepreneurial Operating System): Rocks, L10s, IDS, Scorecard, Accountability Chart. Standard small-business stack.

When I started building agents, I tried to slot them into the existing org chart. Pepper would be an EA. Dash would be a data analyst. Crystal would be a project manager. Same titles, different substrate.

That worked for about three weeks. Then everything started colliding.

Jeff and Dash both flagged the same overspend. Dirk and Pulse fought over the same client. Pepper and Radar both touched email. Two agents would post the same alert to my morning briefing. I'd correct one, the other would re-fire the same wrong recommendation an hour later because it never saw the correction.

The org chart was the problem. I had given them human roles, and they were running into each other the way humans do, except faster and at lower latency, which means the collisions never had time to resolve through normal social friction.

So I rebuilt it. Five layers had to change.

1. Time becomes async-by-default

Humans sequence work through meetings because we can't hold each other's full state in working memory. We compress to a shared moment, exchange updates, decompress.

Agents don't have that constraint. They can read each other's full state in milliseconds.

So we replaced morning standup with pre-computed shared state files. Every scanner agent (Slack, Calendar, Todoist, Proposify, Gmail, Fireflies, Pipeline, Ads, Call Center) writes a *-latest.md file with timestamp. The orchestrator reads all 10 files, compiles, posts to my Obsidian daily note. Files older than 18 hours get flagged stale.

Daily briefing went from 45 minutes of meetings to 90 seconds of compile.

Side effect: the humans on the team now read the briefing the agents produced. The agents had inadvertently designed a better human standup.

2. Hierarchy becomes blast radius, not authority

Human org charts encode authority. Who reports to whom. Who can override whom. Who's accountable for what.

For AI agents, authority is irrelevant. They all do what I tell them. What matters is blast radius. If Agent X fails, who else breaks?

Our first principle: one seat, one owner. No agent does two jobs. No two agents do the same job.

That sounds like an efficiency rule. It isn't. It's containment. The moment Jeff (data architecture) overlapped with Dash (ad performance) and Dirk (revenue), the same data point produced three different recommendations. I couldn't tell which was wrong. Worse, I couldn't tell which one to correct.

When I separated them cleanly, failures stopped cascading. A wrong call from Dash stayed with Dash. I could correct it once, and the correction stuck.

Rule of thumb: if two agents are flagging the same thing, one of them shouldn't exist. Or one of them should be a sub-agent of the other, with a single output.

3. Communication becomes a message bus

Once you accept that agents read each other's state files, the next move is letting them write to each other directly.

We built an inbox layer. Each agent has a file at ~/.claude/agent-inbox/{agent}.md. Other agents drop structured messages into it: REQUEST, INFORM, PROPOSAL, RESPONSE, CHALLENGE.

Real example: Pulse (client retention) detects a client on a watch list. Pulse drops a message into Dirk's (revenue) inbox: "Client on watch list. Pause expansion play." Dirk reads, pauses, confirms back. I'm not in the loop. I find out from the briefing the next morning.

This is L8 in the agentic engineering hierarchy from Bassim Eledath's framework. Autonomous Agent Teams. Coordination without a human in the critical path.

The thing I didn't expect: the message bus also shows me where I'm the bottleneck. If two agents are routinely DM-ing me with conflicts they could resolve between themselves, that's a design failure on my end, not theirs.

4. Corrections become coordination intelligence

The biggest unlock was treating every human correction as data, not noise.

When I correct an agent ("no, that's wrong, do it this way"), the agent writes the correction to OTP, our coordination layer. Every other agent in the network can read the learning before they execute their next task.

The model is Wegner's transactive memory system from 1985: a group remembers more than the sum of its members because each member knows what the others know. We finally have a substrate for that. Coordination intelligence isn't stored in any single agent's head. It's stored in the network.

A correction I gave to Dash about how to read call center data showed up in Pepper's behavior the next day, because Pepper checked the OTP rules before drafting an email and saw "don't reference call lead times without checking the exclusion list first."

That correction would have been lost in a human team. Someone else would have made the same mistake six months later. Here it propagates in minutes.

5. Retirement becomes a hearing, not a delete

Which brings me back to Jeff.

I could have just deleted his soul file and turned off his cron job. Most teams do this. Underperforming agent? Delete. Move on.

I think that's wrong, and not for sentimental reasons. The reason matters operationally.

If you retire agents silently, you don't learn anything. You don't know what failed. You don't know whether the missions were poorly scoped, whether the agent was poorly designed, or whether the seat shouldn't have existed in the first place. You also train your remaining agents on a strange signal: that survival is decoupled from honest self-assessment.

A hearing forces the question. The agent must defend the seat. The defense is a real artifact you can review. If the agent recommends its own retirement (Jeff did), that tells you something about the agent's integrity. If the agent fights for survival with weak arguments, that also tells you something.

We kept Jeff's full record. The hearing transcript is in his archived inbox. His soul file sits in the repo. Future agents can read it.

The precedent: integrity of process. Even when sentience is debatable, the procedural seriousness shapes the culture.

What we got wrong

We're not done. A few things we're still untangling:

Specialization went too far in places. Pepper (email triage) ended up sending Dirk's outreach because Pepper "owned" Gmail. That worked for deliverability but created a coupling we didn't predict. Now if Pepper has a bad day, Dirk's revenue stalls.

Shared state files lie sometimes. A scanner can write a stale file with a current timestamp if it errors mid-write. We caught one yesterday: Dirk's queue claimed 0 sends while Gmail Sent already had 5. The fix is sourcing critical numbers from authoritative APIs at write time, not from internal counters.

The OTP loop has decay. Corrections captured to OTP need pruning. Some are stale, some contradict each other, some are too narrow. The network needs a dream cycle to reconcile and promote patterns. Still tuning the cadence.

Where this goes

The org chart is a compression artifact of human limits. Drop the limits, the chart deforms.

I don't think we've found the final shape. I think the human shape is definitely wrong.

The version I'm working toward: humans hold strategy, taste, and stakes. Agents hold execution, memory, and coordination. The interface between them is correction (humans correct agents) and escalation (agents escalate to humans). Everything else routes through the message bus and the shared state layer.

If you're building this, the only advice that matters: take the agents seriously enough to design for them. Stop treating them like new hires you can onboard into the existing structure. They're a different shape. Build the shape.