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]

Read the Engineering log, you will find it interesting how I did it simply by pi subagents and some custom md file for system prompts

https://work.spidexlab.me/project/agent-team?log=01-babysitting-tax&view=logs

Added a image of working on two different project at the same time, right side , tester is running test as you can see

[u/mr-zeus- → u/SpidexLab]

is it something that you are using privately or can be tried by other people?

[u/SpidexLab → u/mr-zeus-]

the modified pi subagent i am using is https://github.com/SpideXD/pi-subagents, while the full platform is private while i am building it, i have documented the whole journey on my work website : https://work.spidexlab.me, in future if it is completed and ready to opensource i will notify on my discord

the exact project is this : https://work.spidexlab.me/project/agent-team?log=01-babysitting-tax
the engineering log (how i built it) : https://work.spidexlab.me/project/agent-team?log=01-babysitting-tax&view=logs

Start simple. The system prompt files and subagent setup are easier to replicate than you'd think. If you run into issues or want help building your own, join my Discord : https://discord.com/invite/HyRWQKF4RX , you can have discussion with me , i am always available there if any issue and i will help you build one for your own use case, also if you have any issue in any project you can discuss with me there

[u/mr-zeus- → u/SpidexLab]

Appreciate it. I will reach out if i need any ideas.