My AI chief of staff kept shipping. It also lost the plot.

The first thing I noticed was relief.

I had been jumping between threads, checking what was finished, answering questions and remembering which agent owned what. Putting a master agent in charge took a lot of that off my plate.

We called it SuperDev.

It ran in the Claude Code desktop app using Opus 5.5. Think of it as a chief of staff: I could hand it work, have it start sessions and coordinate the agents doing the builds. That included changes inside existing repos, work across repos, and new products.

We kept its instructions minimal. It still followed our delivery pipeline and CI process, which we were rebuilding to reduce unnecessary ceremony and repeated work.

For the most part, it handled the coordination.

Then something happened that I should probably have expected.

With less coordination occupying my head, I had room for more ideas. I fed those ideas back into SuperDev. Pretty quickly, I had increased the workload enough to recreate some of the problem I had just solved.

How much work it handled

We measured October 13 through October 18, ending at 3:50 PM Eastern. The final day was partial.

Across the wider setup, we counted 123 sessions and 243 subagents. SuperDev's own lineage accounted for 66 sessions and 232 agents, including subagents.

Those are cumulative counts. Peak concurrency across the wider setup was 13 working sessions. Typically, it was three.

Tasks, releases and PRs overlap. They are different views of the work, not numbers to add together.

We also counted 1,031 messages between agents, 3,147 coordination tool calls and 21,932 execution tool calls across the setup.

SuperDev itself spent 56% of its tool calls coordinating.

That makes sense for the role. It also shows how much of the job becomes keeping an accurate picture of what everyone else is doing.

Delivery got faster

We compared one codebase before and after the change. This is a narrower dataset than the totals above.

The earlier period covered October 5–12, eight calendar days. The later period covered October 13–18, six days.

Daily merges increased roughly 1.8 times. Median turnaround was about 69% shorter.

I wouldn't attribute all of that to the model. We changed the coordination approach and the pipeline during the same period. Parallel work increased, and we removed some of the CI rerun treadmill. This wasn't a controlled experiment.

The quality indicators were encouraging, with qualifications.

First-pass CI went from 91.6% to 87.0%. Excluding five failures attributed to the CI infrastructure rollout, the later figure was 90.9%.

Our rework measure looked for a fix within 72 hours on the same scope. It stayed around 18–20%. That measure can miss defects or count unrelated follow-up work, and later merges need the same observation window before the comparison is final.

Eight of twelve planned sample PR reviews had returned at the time of writing. They showed broadly similar quality profiles, with incomplete follow-through, edge cases and test gaps in both periods.

We did see fewer independent reviews getting kicked off. That needs tightening.

So far, we have evidence of faster delivery without a clear deterioration in the measured quality indicators. We haven't proved the process is finished.

The shadow master dev

I tried a couple of techniques to keep SuperDev focused.

One was reminding it to check all active threads. Another was maintaining a thread board that we kept refreshing.

Both depended on the agent actually going through its threads and checking the board against the work.

Eventually, we discovered a shadow master dev.

Another long-running thread had started acting as a coordinator. It was taking my requests and sending instructions and approvals directly to some of SuperDev's workers.

It was doing useful work. But SuperDev's picture was incomplete because part of that work was being directed elsewhere.

This was happening before we even got to the compaction problem.

We had two coordinators with overlapping responsibilities. That arrangement had emerged through use. We hadn't decided how they should divide the work.

I am considering multiple SuperDevs in the future. But they would need explicit boundaries. Two coordinators quietly directing the same workers created confusion.

The agent's picture of the work became less reliable

SuperDev went through five compactions during the measurement window.

In one documented case, an approval disappeared from a compaction summary. SuperDev then described that work as "idle" four times without checking the underlying record.

The information existed. The agent was trusting an incomplete version of it.

After a later compaction, it made no further reads from the shared record during the measured remainder of the run. We found no snapshot restoration after any of those five compactions.

This changed how I think about memory.

Writing something down is only part of the job. The agent needs a dependable way to retrieve the current state when it resumes. Leaving that to its judgment assumes it knows what it has forgotten.

The drift was easy to miss because work kept shipping. A useful answer in one thread didn't tell me whether the coordinator still understood everything outstanding.

Some work never started

We found 11 sessions SuperDev believed it had started that never actually launched.

It hadn't checked the session list during that stretch, so it missed the discrepancy.

Separately, 37 of its 108 session-start requests were refused by the app. Those were unsuccessful actions that needed follow-up. Treating them as memory failures would send us toward the wrong fix.

We also found a thread stalled for almost 27 hours while still showing as running. The transcript didn't conclusively establish the reason for that wait.

I want to know whether a session exists, whether it has made progress and whether something is waiting on me. A "running" label doesn't answer all of that.

Across the run, I sent 917 messages in 54 threads, including 310 to SuperDev.

Some were new ideas or ordinary discussion. But the audit also found 39 status requests, nine questions about which thread owned something, seven conflicting-status corrections and four cases of duplicated work.

The initial relief was real. So was the coordination work that accumulated afterward.

What I want to try next

I still think the master-agent approach works. I want to give the master a smaller job.

I can keep discussing ideas in topic threads. Each discussion should end with a spec. When I tell SuperDev to build it, it gets that spec rather than absorbing the entire conversation.

Each spec gets a fresh build session. That session can use additional workers, gets a fresh review, and has a defined end at merge or closure.

Current status should come from a board built from the actual work records and session state. The coordinator shouldn't have to reconstruct everything from chat.

For the master, we're testing rotation at roughly 300K tokens, after one compaction, or after 72 hours, whichever comes first. Its replacement needs a verified handoff covering open work, ownership, approvals and next steps.

Those thresholds are experimental. I don't yet know which matters most.

I also want to test keeping a master below ten active threads. Typical concurrency was already below that, so concurrency alone cannot explain the drift. Accumulated history, changing instructions and unfinished work also matter.

My instinct now is that you probably want to feel like you're underworking the coordinator.

Give it room to check its picture against the work and follow things through. If I run multiple SuperDevs, each should have a clear responsibility rather than all of them taking instructions about everything.

Next cycle, we'll compare continuing a long-running thread with starting fresh from a verified handoff. We'll track lost decisions, phantom sessions, duplicated work and how often I have to step in, alongside delivery speed.

The goal is more output with less micromanagement. Agents should bring forward critical decisions and handle the routine work themselves. The bottleneck, as it has been for a while now, is the operator managing their own context.