There's a small design decision buried in the pi2.nvim v1.5.0 release notes that I think a lot of people building agent tooling have gotten wrong, and it's worth pulling apart.
pi2.nvim is a Neovim front-end for the pi coding agent, forked off alex35mil/pi.nvim. The author isn't building a new agent, they're building the harness around one. The v1.5.0 feature that shipped is sub-sessions, and the pitch for why it's different comes down to one line: when a child agent finishes its task, it goes *dormant*, not deleted.
That sounds minor. It isn't.
The gap the release exposed
The post lays out the three options most people have for running several agents in parallel, and all three are described as awkward. One tab per conversation means you're manually playing dispatcher, copying context back and forth and babysitting results. Framework-built-in sub-agents are called headless one-shot worker bees: the process is a black box, and when the task is done it's gone, so resuming a half-finished sub-task is basically off the table. And the template-heavy approach makes you pay a configuration tax before you've done any real work.
The interesting claim is the second one. The reason you can't resume a sub-task in most tooling isn't a hard technical wall. It's that the tooling never bothered to persist the child's lineage and status anywhere durable. The child was a fire-and-forget subprocess. Its history lived in memory, and memory doesn't survive `/new`, a Neovim restart, or a resume.
pi2.nvim fixes that by writing parent-child lineage into a manifest that those events can't scatter. The father agent also gets injected with dispatch discipline: check for a reusable old child first, don't spawn a new one if an existing one fits, send a batch out when you need parallelism, and collect results by `batch_id`. The manual peek-and-take-over controls are described as a fallback, not the main path.
So there are really two things tangled together here. One is the live front-end: the read-only floating window that streams what a child is thinking, the ability to jump in and course-correct. That part is genuinely Neovim-specific. The other is the bookkeeping: who spawned whom, which children are dormant vs active, what a batch dispatch returned. That part is just state, and state doesn't care what editor you're in.
Rebuilding the durable half as a hosted service
The reusable piece worth extracting is the registry, and it maps cleanly onto a small hosted Python backend.
The data model is boring in the good way. A `sessions` table with a session id, a parent id (nullable for roots), a status column that's `dormant` or `active`, the model and thinking tier the child was configured with, a created/updated timestamp, and a blob or path pointer for whatever context you want to rehydrate. A `dispatches` table keyed by `batch_id`, one row per child in the batch, with the task text and the returned result. That's the whole spine of what the pi2.nvim manifest is doing, minus the editor.
You can stand this up as a Python backend and run Python online without provisioning your own server, exposing a handful of endpoints: register a child under a parent, flip a session between dormant and active, record a batch dispatch and its results, and query for a reusable child before spawning a new one. That last query is the one that enforces the "don't rebuild, reuse" discipline the post cares about, and it's a plain `SELECT` against your session table filtered by parent and capability.
The manifest being hand-editable matters, and it's easy to underrate. When a run goes sideways and you've got an orphaned child stuck in `active` because a process died mid-task, you want to open the table and fix the row, not write a migration. A SQLite editor lets you do exactly that: mark the session dormant, correct a bad parent link, clear a stale batch. It keeps the registry honest and debuggable instead of a sealed box you can only poke through the API.
Modeling the dispatch and reuse logic itself is the kind of glue that pairs well with AI agent development, since the client-side agent is the thing deciding whether to wake an old child or send a fresh batch, and the registry is just the source of truth it consults.
Where the platform stops
Be clear-eyed about the boundary, because this is where the extraction gets honest.
The hosted registry is bookkeeping, not orchestration. It records that a session exists, that it's dormant, and what its lineage is. It does not spawn the child agent's OS process, keep it alive, or wake it. In pi2.nvim the *host* pulls up the process when you message a dormant child; the manifest just tells it the history is still there. On the confirmed VicroCode capabilities there's no process supervision, so waking a dormant session still happens wherever your agent actually runs. The service hands back the state; the client rehydrates and resumes.
The Neovim front-end doesn't move either. The streaming read-only window, the take-over-and-correct flow, the context/model/tier readout at the bottom of the pane, those are editor UI and stay in the editor. The platform hosts HTML web apps, so you could build a browser-based dashboard over the registry to see lineage and batch status, but that's a different surface than the in-editor experience, and I'd call any claim that it matches the Neovim UX unverified until someone actually builds and tests it.
So the split is: durable session state, lineage, dispatch records, and the reuse query live comfortably in a hosted Python-plus-SQLite backend with API endpoints. The live process lifecycle and the editor front-end don't, and pretending otherwise would just move the black box somewhere new.
Why this is the signal worth taking
The broader current here is that agents are starting to be treated as things worth keeping, not disposable calls. A dormant-but-resumable child is a small version of that: the work it did has value past the moment it finished, so you store it where a restart can't reach.
If you're building agent tooling, the practical takeaway is to draw the line between the reusable state and the front-end early. Put lineage, status, and batch results somewhere durable and hand-editable from day one. That single decision is the difference between "resume last session" being a feature and being a rewrite.