Pi Multi Agent Orchestration Extension
TLDR
I have built an extension for the Pi coding agent that allows it to call other agentic harnesses
via my agent-shell library.
quick start with if you want to check it out
npm
pi install npm:@scottrbk/pi-agentshell-extension
from source
pi install git:github.com/ScottRBK/pi-agentshell-extension
I have recently been working on implmenting agent-shell in more projects over the past few weeks. Most noticeably was the inclusion of it as part of my evaluation harness application that I put together for evaluating agent harnesses + models.
I spent a lot of time writing the actual code for eval harness by hand, utilising the agent as a glorified search engine and code reviewer. I have vibe coded a few projects myself, but anything critical for my workflows or more importantly that other people will be using I have never been at
a stage where I would be comfortable having something written by the AI.
That being said though, I do not just use agents to write code or produce software that needs to be to a high standard. In my day to day role I use agents to perform a multitude of tasks.
From fetching information across large complex enterprise scale repositories, writing, editing and
managing Azure DevOps work items and wikis, produce presentations and organise To Do's and activity based on meeting notes and e-mails.
All this I manage using the CLI, with my tmux workflow and various CLI agents. Outside of work I have fun little projects going on, vibe coded apps I am building, some exploratory ideas for my moonshot SaaS that will let me retire early. All this leaves me with working with many tmux windows (I haven't made the jump to herdr yet) and a lot of cognitive overload.
Reducing cognitive load
One of the things that I identified early on was that I needed to just be speaking to one Agent for most of my stuff and that agent should be responsible to delegating tasks to other agents on this
workflow. I think many others quickly realised this also, and the most elegant example of this is an excellent repository called First Mate, which goes in a
slightly different direction that I want to end up at but has a similar principle. I encourage people to check out Kun Chen's YouTube Channel and his videos around
Agentic Workflows as well if you have not already, he has a lot of great ideas and practices in how to adopt the principle of reducing cognitive load.
Where to start? Pi of course
I had previously fluttered between Claude Code, Codex and OpenCode (including their Go subscription and my own locally hosted models). I think all of these are great apps, but once I discovered Pi
I was immediately hooked. The minimalistic and customisable aspect to it I found compelling, it felt like an agentic equivalent to Neovim.
I felt like whatever agent I was going to use for the orchestration layer, I needed to have a lot of control over and given Pi's adaptable nature it seemed an obvious choice. At least for me to start with, I may decide later to build more of a deterministic wrapper around any orchestrator agent but for right now I don't think that is necessary.
First building block
After I had the obvious extensions included, such as web fetch/search/screenshots, I realised the key thing was for me to build out the ability for my Pi agent to call a sub agent. Now there are other Pi agent extensions that already exist for calling sub agents, but given various circumstances I prefer to use certain models and harnesses for certain tasks, what I wanted was the ability to call agents inside of other harnesses. I find the RL of certain models on their own provider harnesses can lead to different behaviour and as such I think it's useful to take advantage of that in certain
situations.
So taking advantage of agent shell felt like an obvious choice.
Python <-> TypeScript
Well it seemed like the obvious choice but with one glaring issue. Pi is written in TypeScript as are it's extensions and agent-shell is a Python application.
I have limited TypeScript experience, save for the Angular Tour of Heroes walkthrough I did a few years ago when I was flirting with front end development and my JavaScript experience I had for front end for client side validation I used to write on ASP.NET apps almost twenty years ago. So for something this fundamental to my future workflows, I didn't want to hand over to AI and re-write agent shell in a language I do not really feel comfortable with, nor did I want to undertake the task myself.
So I decided to work with AI and build a TypeScript to Python bridge via subprocess. At least for now while I dogfood it and to get me going. This involved a simple runner.ts file that would relay tool calls registered in index.ts to a Python handler to translate the commands to agent-shell requests.
Extension Behaviour
As of right now I have not wrapped any skills or anything beyond just exposing the tools. This is a building block for a something that will get more opinionated but as of right now, this extension on it's own should not look to enforce any such opinions on when and which sub agents should be called, that is up to the consumer of the extension. I've obviously done this to try and fit in with the overall philosophy of Pi itself I feel. Simply asking a model to call a sub agent and they will call
the tool, which will display the harness (agent_type), the model and effort (if specified)
Silent Mode
Another idea I took from Kun Chen's Agentic Workflow was his use of a 'Calm Mode' that reduced the output for First Mate. I thought this was a nice feature and as such incorporated it into the agent-shell extension /agentshell-silent will trigger the subagents response to not include the output.
Next Steps
For me, I am going to add in commands and skills and start trying to adopt the single agent orchestrator approach that Kun Chen has inspired in First Mate. I had already been building towards such a concept for sometime, with the likes of agent-shell and other tools like forgetful that I have put together for agentic workflows. I have built out my own agentic framework as well, but Pi has really given me everything I was already planning with that so I am happy to mothball it somewhat while I am not short of side projects.
As for the extension itself, I am still undecided on the next steps of the architecture of it. I may opt to leave it as well, but maybe a TypeScript bridge might be interesting in other applications as well. As such there are two possible next steps in that area:
- Separate the bridge into it's own library or move it into the Agent Shell library if it proves stable 2. Re-write Agent Shell in TypeScript. Given I use Agent Shell in a lot of Python libraries already this is not an attractive option, unless I want to maintain two instances of the library (in the age of AI this may not be that big of a deal).
So there you have it, thanks for reading if you made it this far. If you end up using the extension any feedback is welcome and if you enjoy using it feel free to give it a star.
If you are interested in the kind of topics discussed here, I please feel free to come join the forgetful Discord and chew the fat with like minded individuals.
Top comments (0)