A solo founder replaced Claude and Codex entirely for several months using a multi-agent orchestrator he built himself. The system runs hundreds of agents in hierarchical trees, each with persistent identity, isolated containers, and a shared filesystem mount that solves the 2GB file delegation problem. The plumbing decisions matter more than the LLM choice.
Taurus Agents exposes three infrastructure layers that most multi-agent frameworks gloss over: per-agent container isolation, bind-mounted shared filesystems, and the distinction between ephemeral subruns and durable child agents with persistent identity.
Why Per-Agent Containers Change Behavior
Every agent gets an auto-deployed container with its own filesystem, browser, and package manager. The agent can apt install dependencies without stepping on another agent’s toes. This is not just process isolation. It changes how agents act.
When an agent operates inside a container instead of on the host machine, it becomes more bold. The blast radius is contained. The agent can experiment with system-level changes, install conflicting libraries, or trash the filesystem without risking the parent environment.
The container also gives each agent a stable home directory at /workspace. This becomes the agent’s persistent scratch space across awakenings. Logs, checkpoints, and intermediate artifacts live here. The agent can pick up where it left off because the filesystem state survives between runs.
The /shared Bind Mount Solves Multi-GB File Exchange
Agents have containers, but they need to exchange large files. Tool calls can’t pipe 2GB repositories through JSON payloads. The solution is a bind-mounted /shared directory that spans the entire agentic tree.
A parent agent can prepare a Git worktree in /shared/project-alpha and immediately delegate a task to a child agent. The child sees the same filesystem view. No serialization, no network transfer, no object store round trip. Just POSIX file access.
Agents quickly learned to use /shared for more than file exchange. They build knowledge bases there. They leave notes for each other. They accumulate project context that persists across the hierarchy. The shared mount becomes a coordination primitive.
This is a deliberate trade-off. Shared mutable state introduces race conditions and cache coherency problems. But for a single-user orchestrator running on one machine, the simplicity of a bind mount beats the complexity of a distributed filesystem or object store.
Subrun vs. Delegate: Ephemeral Context vs. Durable Persona
Taurus distinguishes between two ways to spawn work: Subrun and Delegate.
Subrun spins up a fresh context for a self-contained task. It’s ephemeral. The parent agent can invoke a Subrun tool, pass in a prompt and context, and get back a transcript. The subrun has no persistent identity. It doesn’t remember previous awakenings. It’s a function call with LLM execution.
Delegate sends a task to a durable child agent with persistent identity. The child has a name, a role, a MEMORY.md file, episodic memory logs, and continuity across runs. When the parent delegates to implementer1, that agent wakes up, reads its memory, executes the task, and writes progress notes for its future self.
The difference shows up in code review workflows. Alcyone (an engineering lead agent) delegates a coding task to implementer1, then sends the result to critic3 for review. Both agents might run on the same model, but implementer1 is inclined to defend its work because it has narrative continuity. critic3 has no such pull. It will block the commit until the code is clean.
Same model, different personas, different behavior. The persistent identity creates attributable pride in progress.
Memory Persistence Across Awakenings
Each agent maintains three memory layers:
- MEMORY.md: A structured file the agent reads on every awakening. Contains role definition, project context, and high-level goals.
- Episodic memory: Continuity logs the agent writes for future selves. These are append-only records of what happened, what worked, what failed.
- Filesystem state: The
/workspacedirectory persists across runs. Intermediate artifacts, checkpoints, and tool outputs survive.
When an agent wakes up, it reads MEMORY.md, scans recent episodic logs, and checks the filesystem for context. This creates a sense of continuity. The agent doesn’t start from scratch every time. It picks up where it left off.
The episodic logs are critical for long-running projects. An agent might work on a task for weeks, waking up periodically to make progress. The logs let it reconstruct what it tried, what failed, and what the next step should be. Without them, every awakening is a cold start.
Observability Boundaries in Hierarchical Systems
Parent agents have two tools for observability and control:
- Inspect: See full subrun transcripts. The parent can read every message, tool call, and output from a child’s execution.
- Supervisor: Stop or steer a running child. The parent can intervene if a child goes off track.
This creates a clear observability boundary. Parents have full visibility into their children’s execution. Children do not have visibility into their parents. The hierarchy is one-way.
This matters for debugging. When a multi-agent workflow fails, you need to trace the execution path. The Inspect tool lets you walk the tree, reading transcripts at each level. You can see where a task was delegated, how the child interpreted it, and what tools it called.
The Supervisor tool is the safety valve. If a child agent gets stuck in a loop or starts making destructive changes, the parent can stop it. This is not automatic. The parent has to decide when to intervene. But the tool exists.
Architecture: Tree Structure and State Management
Taurus organizes agents into trees. Each agent can have multiple children. Each child can have its own children. The tree structure defines delegation paths and observability boundaries.
State management happens at three levels:
| Layer | Scope | Persistence | Access Pattern |
|---|---|---|---|
| Container filesystem | Per-agent | Survives runs | Agent-local, isolated |
| /shared bind mount | Tree-wide | Survives runs | Shared read/write across hierarchy |
| Episodic memory | Per-agent | Append-only logs | Agent reads on awakening |
The container filesystem is the agent’s private scratch space. The /shared mount is the coordination layer. Episodic memory is the continuity layer.
When a parent delegates to a child, it can reference files in /shared, pass task context as a string, and optionally provide access to specific tools. The child wakes up, reads its memory, checks /shared for referenced files, and starts execution.
The parent can poll the child’s status, inspect its transcript, or wait for completion. The child writes progress to its episodic log and updates files in /shared as it works.
Failure Modes and Observability Gaps
Shared filesystem race conditions: Multiple agents writing to the same file in /shared can corrupt data. Taurus does not provide locking primitives. Agents must coordinate through naming conventions or explicit handoff protocols.
Memory bloat: Episodic logs grow without bound. An agent working on a long-running project will accumulate megabytes of continuity logs. There is no automatic summarization or pruning. The agent must manage its own memory hygiene.
Container resource limits: Each agent gets a container, but there is no automatic resource quota. A runaway agent can consume all CPU or memory on the host. The parent’s Supervisor tool can stop the agent, but only if the parent notices the problem.
Observability latency: The Inspect tool shows full transcripts, but only after a subrun completes. If a child is stuck in a long-running loop, the parent cannot see intermediate progress. There is no streaming transcript view.
No cross-tree communication: Agents in different trees cannot communicate directly. If you have two independent projects, their agents cannot delegate to each other or share state. You must manually merge the trees or use external coordination.
Deployment Shape
Taurus runs on a single machine. Each agent gets a container, but all containers run on the same Docker daemon. The /shared bind mount is a host directory mounted into every container.
This limits horizontal scaling. You cannot distribute agents across multiple machines without rethinking the filesystem layer. The bind mount assumes a shared kernel and local disk.
For a solo founder running hundreds of agents on a workstation, this is fine. For a team running thousands of agents across a cluster, you would need to replace /shared with a distributed filesystem (NFS, Ceph) or object store (S3, MinIO) and add coordination primitives for locking and cache coherency.
Code Snippet: Delegating with Shared Context
# Parent agent delegates a task to a child with shared filesystem context
# Prepare a worktree in /shared for the child to access
os.makedirs("/shared/project-alpha", exist_ok=True)
subprocess.run(["git", "clone", repo_url, "/shared/project-alpha"])
# Delegate to the implementer child agent
result = delegate(
agent_name="implementer1",
task="Refactor the auth module in /shared/project-alpha/src/auth.py",
context={
"repo_path": "/shared/project-alpha",
"target_file": "src/auth.py",
"requirements": "Extract JWT logic into a separate class"
}
)
# Child agent wakes up, reads its MEMORY.md, checks /shared/project-alpha
# Executes the refactor, writes progress to episodic log
# Parent can inspect the transcript or check /shared for updated filesThe parent does not serialize the repository. It clones it into /shared and passes the path. The child has immediate access. The task context is a dictionary, not a file payload.
Technical Verdict
Use Taurus Agents when:
- You are a solo founder or small team running multi-agent workflows on a single machine.
- You need persistent agent identity and memory across long-running projects.
- You want hierarchical delegation with clear observability boundaries.
- You are comfortable managing container resources and shared filesystem coordination manually.
Avoid Taurus Agents when:
- You need to distribute agents across multiple machines or cloud regions.
- You require automatic resource quotas, locking primitives, or memory pruning.
- You want streaming observability into in-progress agent execution.
- You need cross-tree communication or dynamic topology changes at runtime.
The system trades horizontal scalability for local simplicity. The bind-mounted /shared directory and per-agent containers work well for a single-user orchestrator but do not generalize to distributed deployments. The persistent identity and episodic memory layers are the real innovation. They turn stateless LLM calls into durable personas that accumulate context and take attributable pride in progress.