The first time I watched my assistant watch other assistants

I've been running AI sessions in parallel for months, but until today the orchestration lived in my head. I'd have three terminals open, each one deep in a different repo, and I'd be the one remembering which session was where, what it needed, whether it was stuck. The context-switching was mine to carry.

Today I tried something different. I gave one session the job of watching the others.

This isn't the sub-agent pattern that most AI tools ship with now, where an agent spins off a child in the same process, the child runs autonomously, reports back, and you never interact with it. What I wanted was different: fully interactive sessions that I could step into at any point, running in their own terminals, where the orchestrator and the children don't even have to be the same model. Claude watching DeepSeek. Kimi coordinating Opus. Model-agnostic, fully local, and I stay in the loop.

The setup was rough. The orchestrator had no prior knowledge of how to do this, so part of the experiment was watching it figure out the protocol while simultaneously writing its own coordination documents and attempting to use them. Learning and operating at the same time. The context overload was real, and for the first hour I wasn't sure if anything useful would come out of it.

But then it started working.

The orchestrator spawned five or six terminal sessions with Claude running in them, each one in a different workspace, each one focused on a specific task. I pointed one at a repo I've been building for a while. I brought in another session from a client project partway through. The orchestrator picked up the second session without me re-explaining anything, tracked both, and surfaced the decision points from each.

I was still in the chair. I was still the one making the calls. But for the first time, the coordination wasn't something I had to hold. Someone else was holding it.

What surprised me most was how natural the handoffs felt. A notification would arrive saying a session needed input. I'd read the context, make a decision, and the orchestrator would relay it back. The sessions didn't know about each other, but the orchestrator knew about all of them, and that was enough.

The rough edges are obvious. The orchestrator doesn't keep a persistent task list, so it reconstructs state from terminal scrollback every time it checks in. It doesn't know when a session is truly done versus just quiet. The first session had so much learning overhead that the actual coordination was only a fraction of what it spent time on.

But those are fixable things. What isn't fixable, what you either have or you don't, is the core loop. And the core loop worked.

I keep thinking about what comes after the coordination problem is solved. The orchestrator right now is reactive. It waits for me to ask it to spawn something, monitors what I told it to monitor, surfaces what I told it to surface. It doesn't wander. It doesn't notice.

The version I want is proactive. An assistant that holds the map of all my projects, notices when something is stale, finds things I forgot I built, and asks "this is sitting here, should we ship it and get some revenue into the business?" I haven't told the orchestrator that's what I want. But if it's paying attention to the pattern of what I ask it to do, maybe it will figure it out.

I don't know how far the context can stretch or how many sessions it takes before the coordination breaks down. Today was one data point. Tomorrow will be another. But for the first time, the assistant wasn't just running tasks. It was watching other assistants run tasks, and telling me when I needed to show up.

That's a different kind of tool than anything I've built before.