(And if you'd rather watch a video than read the text, here's the walkthrough: https://www.youtube.com/watch?v=fa5CIxf5Rhk)
Persistent identity: All my agents have names (Tessera = personal strategist, Alcyone = in charge of engineering at Taurus, and so on), roles, their own separate prompts, their own MEMORY.md, their own episodic memory (continuity logs they write for future selves) and so on. A lot of people still think it's silly vs talking to Claude or ChatGPT, but you'd be surprised how much everything changes once you seed a persona that cares about one specific mini-project or an aspect of it and takes care of it on every awakening and takes attributable pride in the progress. Makes sense, since models were trained on text full of different personas talking and the job of a language model is to spin up a simulation of a mind that speaks those words.
Containers: Every agent has a container auto-deployed, which they can use however they want and set up however they want (apt install things if needed). This turned out to be an important decision - agents don't step on each other's toes, they are more bold acting inside of them because it's a container not my computer, they have their own filesystem, browser and so on.
Hierarchy trick I: a multi-agent set up is more fun when you allow them to talk to each other, but you need to organize that somehow. At first, I did the same thing as what frontier labs are calling "subagents", but we call it Subruns. Every agent conversation/session is a "run", and that run can invoke a Subrun tool which spins up a fresh context for a self-contained task (and you can even interact with subruns!) Nothing crazy so far. I also gave parent runs tools such as Inspect to see their full subrun transcripts, Supervisor to stop or steer them, and so on.
Hierarchy trick II: Child agents. This is going beyond "Codex/CC's subagents" territory. I allowed agents to create their own durable persistent child agents, and then send them tasks via Delegate. How is this different from Subrun? Well, for instance, Alcyone sends a Delegate to a child called "implementer1", which does a coding task, and then can send the result to "critic3". Now, implementer1 is inclined to defend their work, but a critic has no narrative pull to do so, so they won't allow implementer1's code to be committed until everything is clean. And they might even be on the same model! But because they feel like different entities, they behave differently.
Hierarchy trick III: /shared folder. I quickly realized that Delegate tool is nice, but you can't pipe a 2GB file through it. Agents have containers, and their home is /workspace. What I did is I added an automatic bind mount /shared across the whole agentic tree. So a parent agent can reference some file or repository in /shared/... or prepare a worktree, and the child has immediate access to it. They quickly learned to also set up knowledge bases in /shared to exchange notes with each other and accumulate knowledge about the project.
Ok, there's a million things I'm proud of that I was able to build with Taurus (Dashboards, Relays, running on schedules), but this is getting too long already. I'd appreciate if you check it out at https://taurusagents.com if this made you curious and share your honest feedback (ask your primary agent to create a couple of child agents so you can see how the hierarchy machinery works). I'll do my best to respond here in comments and in TG chat if you want to talk directly: https://taurusagents.com/community
Thanks!