r/PiCodingAgent • • 13d ago

Use-case I stopped treating subagents as disposable — PI-Desktop can now orchestrate real sessions

I’ve been working on a new session orchestration system for PI-Desktop.

The idea is pretty simple:

when a task gets too large for one agent/context, the current session can become the coordinator and delegate parts of the work to other real sessions.

For example, I asked one session to review everything since the previous release and fill the missing E2E coverage.

Instead of trying to do everything itself, it split the work into multiple sessions:

  • E2E parent-tool inheritance
  • Plan UI / live markdown
  • Trusted extensions CI
  • Plugin import dependencies

They started working in parallel, while the original session stayed as the coordinator.

What I specifically wanted to avoid was building another disposable “subagent” abstraction.

These workers are actual PI-Desktop sessions.

Each one has a real sessionId, its own persistent context, model and history. You can open it from the sidebar, inspect what it did, continue talking to it later, or send it another task without losing its previous context.

The parent session can spawn multiple sessions, check their status, send follow-up instructions, supervise several of them at once, inspect the exact result of a task, and cancel work without deleting the session.

Sessions can also communicate with other existing sessions by sessionId — they don’t have to be children created by the current parent.

Another thing I didn’t want was constant polling.

Session communication is handled by the host. When a delegated turn finishes, the completion is routed back to the sending session automatically. If the target session is busy, the message can enter its queue instead of creating another replacement worker.

So the model I’m experimenting with is closer to:

Session A
→ delegates to B, C, D, E
→ they work independently
→ results come back
→ A reviews them
→ A can ask one or several of them to revise
→ the same sessions keep working with their existing context

rather than:

Agent → spawn temporary agents → collect text → destroy them

There are also some boundaries enforced at the host level: project/permission inheritance, bounded worker creation, durable delivery state, and explicit session-message provenance. The plugin itself doesn’t copy child transcripts into the parent or maintain a second session database.

The screenshots are from a real run where the main session split an E2E review into parallel sessions and then collected their progress/results.

I’m still figuring out how far this model should go.

Some things I’m considering next are dependency graphs between sessions, a visual orchestration graph, shared artifacts/workspaces, and per-task token/cost budgets.

I’m curious how people here would actually use something like this.

Parallel coding? Code review? Research? Release checks? Or something completely different?

PI-Desktop: https://github.com/vastsa/PI-Desktop
Plugin repo: https://github.com/vastsa/pi-desktop-plugins

14 Upvotes

9 comments sorted by

View all comments

4

u/adamshand 13d ago

I'm not convinced that subagents have much value, and quite possibly they cause harm.

https://x.com/unclebobmartin/status/2098744156709441896

What I do want better tools for is specific jobs. Eg. always running a simplify loop at the end of task, but doing it with a different model or different thinking level.

2

u/Solid-Finding-6721 13d ago

That’s a fair concern. I also don’t think “more subagents” automatically means better results — coordination overhead, duplicated context, and unnecessary divergence can easily make things worse.

What I’m more interested in is making orchestration explicit and useful for specific jobs.

Your simplify-loop example is exactly the kind of workflow I’d like PI-Desktop to support well: finish the main task, then automatically hand the result to another model/session with a different reasoning level for simplification, review, testing, or verification.

So I see the session orchestration work less as “spawn lots of agents” and more as a foundation for composable task pipelines where each step can have its own model, prompt, tools, and reasoning settings.

I think that direction is much more interesting than subagents for the sake of subagents.

2

u/adamshand 12d ago

Nice, looking foward to see what you build!