I've had something like this in my personal pi for a few weeks. The difference is I've tuned it for low context use because my priority is to get work done, not sell tokens.
I'm not saying my one would be able to handle a Rust rewrite of Bun. It's designed for plans where the maximum scope is what I can keep in mind and thoroughly test in ~ 1 day.
One of the major breakthroughs I had was having the executor agent (or manager agent, whatever you call it) split the technical plan into a DAG of small, subagent sized tasks, usually red waves then green waves. Sometimes there'll be 10 or 20 subagents in flight, especially for highly parallelizable red waves which is satisfying to watch. Usually I'm using xhigh for the executor and medium for the workers, GPT5.5.
Besides the DAG organization, other critical pieces were tuning the executor to minimize it's context use. Because it's Pi I'm starting a session at about 10k of instructions and I can let a plan run for a couple of hours before I have to compact. And the other one was having the executor fully responsible for git management, otherwise workers would frequently clash and stall.
It's just subagents, although agent teams on tmux chatting to each other looks cool I think it's just overhead in practice. Give workers clear, narrow scope and review when they're done.
Besides that it's a fairly standard workflow: brainstorm to PRD -> technical plan -> execute -> audit.