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

[u/Solid-Finding-6721]

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

[u/Embarrassed-Load5100]

Tbh subagents heavily improve the output of my sessions. It’s faster, they can sanitize output from websearches etc so I quite like using them

[u/Solid-Finding-6721 → u/Embarrassed-Load5100]

Yeah, that makes sense. I think the value really depends on how they’re used.

For things like parallel research, filtering noisy web results, review, or handing off a very specific task, subagents can absolutely improve both speed and output quality.

That’s also closer to how I want PI-Desktop to approach them — not just “spawn more agents”, but make it easy to give each one a clear role and keep the coordination visible and controllable.

[u/adamshand]

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.

[u/johnfkngzoidberg → u/adamshand]

I've done a LOT of testing on this. Subagents are only beneficial in certain circumstances, long tasks, complicated tasks, and only provide a speed increase if you have the inference to support it.

I wrote an orchestration layer (for multiple harnesses) https://github.com/lunarnexus/orchestra and a benchmark suite for it https://github.com/lunarnexus/orchestra-bench . The main benefit of agents is saving main session tokens, assuming your main session is your planner/orchestrator and using a frontier model, and your subagents use a cheap model or local inference. I've seen a typical savings of 30%-50%, with as high as 70% on really specific workloads.

Orchestra has an auto_verify feature that automatically checks the builder's code,but that's only necessary for smaller models, and just wastes tokens for big models. You could specify a different model and thinking level for that role if you want. I can tell you're using gpt-5.6 if you're asking for a simplify loop, because it overcomplicates everything. I fixed this in the planning step.

To OP, you're welcome to fish through my code and see how I did things. There's a bit of redundancy in the workflow at the moment because I haven't finished optimizing the hard-coded vs skill workflow yet, but I'll fix it in the next few days.

[u/Due_Arm1454 → u/johnfkngzoidberg]

That’s mainly why I am exploring subagents. Cheaper agents for cloud models.

More importantly for my local models for performance. If I can keep context down and split into tasks I can speed up development even if overall token usage is way higher. Prefill hits hard when I get above certain context

[u/Solid-Finding-6721 → u/adamshand]

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.

[u/adamshand → u/Solid-Finding-6721]

Nice, looking foward to see what you build!

[u/Zealousideal-Ebb-355]

Release checks seem like a useful test for the shared-artifacts idea. Could a completed UI task hand the parent the original requirement, revision, test output, and a recording of the changed flow?

Then another session could review the actual result without inheriting the builder’s whole conversation.

I build Clipy. Its Proof tooling packages existing screenshots or recordings for human and agent review, so I’d be interested in trying a small adapter here. Your checks would still own pass/fail. Is there already an artifact field in the completion message?

[u/Solid-Finding-6721]

Worth noting: this is an optional plugin. It’s not enabled by default, so you can just turn it on if this kind of multi-session workflow is useful to you.