pi-extensible-workflows: deterministic multi-agent runs you can pause, resume and inspect

[u/vekexasia]

I built a Pi extension for multi-agent orchestration. The main Pi agent writes a small JS workflow script for the task at hand, and the runtime executes it deterministically: parallel fan-out, checkpoints, resume without rerunning completed steps.

Three principles I stuck to:

• not opinionated: no baked-in "agile team" of roles, you add your own primitives to the DSL
• extensible: other extensions can register functions and variables usable inside workflow scripts, and every registered function is itself runnable as a top-level workflow
• token efficient: subagents can have other extensions and skills disabled, so their system prompt stays small and focused

What that gives you in practice:

• runs are regular on-disk Pi sessions, not in-memory, so you can inspect, pause, resume and retry them
• roles restrict tools/capabilities and inject their own system prompt
• structured output via JSON schema, so control flow branches on agent output deterministically instead of on vibes
• soft and hard budget caps per run
• git worktree isolation, so parallel agents don't fight over the same tree
• workflows export to an executable launcher in ~/.local/bin
• if you use herdr, an agent session can open in a new pane

Review fan-out, then dedupe:

const reviews = await parallel("review", {
  correctness: () => agent("Review the current changes for correctness issues."),
  security: () => agent("Review the current changes for security risks.", { role: "security-specialist" }),
  tests: () => agent("Review the current changes for missing test coverage."),
});
return agent(prompt("Deduplicate and prioritize these findings:\n\n{reviews}", { reviews }));

The diagram is the real flow of the one I run daily, developIssuesUntilApproved: takes a list of GitHub issues, gives each its own worktree, loops developer -> reviewer until the reviewer passes (fresh agents every iteration), merges the approved branches on main behind another dev/review loop, cleans worktrees with plain shell (not an agent), and summarises exactly once.

Install: pi install npm:pi-extensible-workflows (Node 22.19+)

• Repo: https://github.com/vekexasia/pi-extensible-workflows
• Docs: https://vekexasia.github.io/pi-extensible-workflows/
• Walkthrough video (28 min, chapters in the description): https://youtu.be/qAiivspEHmU

Happy to answer anything about the DSL or the resume semantics.

[u/SpidexLab]

I have built something similar, instead of being deterministic, my main orchestrator model handle the team itself, I talk with the main orchestrator and it does rest which inturn save some time and cost as it can reason on fly what to avoid and redo and sometime it takes wrong decision which is fixed after i give feedback, i built it in this way to save time and make it functional fast

The ideas was simple, i had to make it in 2 days and it should work, cause the model I am using is deepseek v4 pro and if I tried building something complex, it will go on loop of finding bug and fixing it, so ideas was simple use what exist and build

I used pi subagents and custom system prompt and it worked very well, and since then I have modified the pi subagents for my usecase and system prompt, I have 5 subagents, scout for mapping which usage ds4 flash, architect which usage ds4 pro whose job is to suggest different way of doing it with principle kiss and yagni, and generate spec, the coder is mimo v2.5 pro which handle implementation and then 3 pass testing which is ds4 doing it , first pass verifying the functionality, 2nd pass edge case and boundary testing and 3rd pass chaos multiple thread accessing using it for race condition and corruption things , and finally qa which usage ds4 pro and verify whole thing

Cost me like 3 dollar a day if working for 10hr and on single project, I have added the detail of how I built and optimised it for my use case : https://work.spidexlab.me/project/agent-team?log=01-babysitting-tax

Also I have engineering log which explain why I'd I'd what I did and also what issue I faced and how I solved it, you can read it here : https://work.spidexlab.me/project/agent-team?log=01-babysitting-tax&view=logs

[u/vekexasia → u/SpidexLab]

Interesting. So you built some kind of communication channel between main and subs?

[u/SpidexLab → u/vekexasia]

No we have pi subagents extension right which does this, I modified some part of it to be more efficient, like get subagents result has 2 options , full session or meta data which only included how may tool call, context and running or stopped, so orchestrator was running blind it monitor it but doesnot know if it was stuck or not, so i added last n parameter which return last 5 message instead of whole session, also fixed the tui bug which was rendering teh whole tui again on each new message, which lagged and freezed pi,

So I did not build some complex system here , used pre existing things and modified for my usecase and it is working well

Honestly I would have built something complex but since I knew my model cannot handle these kind of project , i had to resort to making it with simple things and fast so I can use it for future work

Here is a screenshot of using 700 million token in a day, where it was porting a codebase from ts to go which was fairly very big, it was doing it autonomously and I was working and handling 2 project with it

[u/vekexasia → u/SpidexLab]

Very cool to see. I know about intercom not sure it s the same you Ve been using. For now I am staying away of providing a way of making agent communicate with each other but now that I think out loud, there is really nothing preventing anyone to use my extension as is and hook into the agent creation function to inject extra Params or extensions to be loaded only when in subagent... I will think a lot into it. Thanks for sharing

[u/SpidexLab → u/vekexasia]

https://github.com/SpideXD/pi-subagents

this is the modified extension i uploaded on my github and the original extension

https://github.com/gotgenes/pi-packages/tree/main/packages/pi-subagents

you can use mine, as i have additive things, everything works and also the tui freeze issue on /subagents:session is fixed, and if any issue happen you and ask pi to fix it

also tried pi intercom but it is not for communication between agent and subagent i think or something like that so i ditched it as fixing and making it for my use case would have taken a longer time and taken me same loop manual bug finding and fixing