Why One Agent Is Not Enough
Key insights
- Dan builds deliberately beyond what a single Claude Code instance can do. His Pi-based system with 3 tiers, domain ownership, and persistent memory shows how far multi-agent orchestration can go.
- Domain ownership (restricting which files each agent can touch) is what makes full agent autonomy safe on large codebases. Without it, more agents means more risk. With it, each agent is contained to its area.
- The cost objection misses the trend: tokens are getting cheaper while model intelligence is rising. Optimizing for low token spend today means optimizing for yesterday's prices.
- Mental models that persist across sessions create compounding returns. Each run makes the agent team smarter. This is the gap between using AI as a tool and building AI systems that improve themselves.
This is an AI-generated summary. The source video may include demos, visuals and additional context.
In Brief
Dan Disler (known online as IndyDevDan, a senior engineer who focuses on agentic coding) argues that one AI coding agent is a ceiling most engineers have already hit without realizing it. The fix is not a better prompt. It is a team. Using Pi, a customizable AI coding agent, Dan demonstrates a working multi-agent system with 9 specialized agents organized across 3 teams: planning, engineering, and validation. Each agent has its own role, its own memory, and strict rules about which files it is allowed to touch.
Related reading:
What are agent teams?
An agent team is a group of specialized AI agents that work together on a task instead of one agent doing everything alone. Each agent handles one part of the job: a planner thinks through what needs to happen, an engineer writes the code, a validator checks whether it worked.
Dan's video shows what this looks like in practice. He builds a custom 3-tier system on Pi with persistent memory, strict file boundaries, and a chat-room interface where all agents communicate in real time. The goal: go beyond what a single AI coding agent can do alone.
The 3-tier architecture
Dan's system has three layers.
Tier 1 — Orchestrator. This is the top-level agent. When you type a message, the orchestrator receives it. It decides which team should handle the work and delegates accordingly. It never writes code itself. It coordinates.
Tier 2 — Team leads. There are three teams: planning, engineering, and validation. Each team has a lead. The planning lead designs the approach. The engineering lead directs the developers. The validation lead oversees testing and security review. Leads also do not write code. Their job is to think, plan, and delegate to their team members.
Tier 3 — Workers. These are the agents that actually build things. The engineering team has a front-end developer and a backend developer. The validation team has a QA engineer and a security reviewer. Workers do the hands-on work: reading files, writing code, running tests.
The result: you type one message into a chat interface, and 9 agents across 3 teams spin up, divide the work, do it, and report back. You never talk to any agent except the orchestrator.
The 6 pillars
Dan frames his architecture around six properties that together make the system work.
1. Team hierarchy
The 3-tier structure removes you as the bottleneck. You are no longer the person routing tasks between agents. The orchestrator handles that. This is the difference between managing one assistant and running a small, self-organizing team.
2. Specialization
A generalist agent produces average results. A specialized agent, configured with domain-specific system prompts and expertise files, produces expert results. The planning lead knows how to decompose a problem. The backend developer knows the architecture of your codebase. Each agent is built for one thing.
3. Agent memory (mental models)
Every agent in the system carries a mental model: a file where it stores what it has learned across sessions. What patterns work. What decisions were made. What risks to watch for. Each time the team runs, it loads this file and adds to it.
The orchestrator's mental model can grow up to 10,000 lines. Agents load it at the start of every session using Claude's 1 million token context window. The team gets smarter every time you use it, without any extra effort from you.
4. Domain ownership
This is the safety mechanism that makes full autonomy practical. Each agent has a defined domain: a set of folders and files it is allowed to read, and a narrower set it is allowed to write to. A frontend developer can read the backend code but cannot change it. A planning lead can read everything but cannot modify anything except its own expertise files.
When the engineering lead tries to access files outside its domain, it does not proceed anyway. It recognizes the boundary and delegates to the team member who has the right access. This keeps the blast radius of any agent action small and contained.
5. Chat room interface
All agents share the same conversation log. Every agent can see what every other agent has said and done. This shared context means agents can coordinate without being explicitly told what the others are doing. The orchestrator gives each team the same prompt, all teams work in parallel, and their answers converge into one unified response.
6. Configuration-driven harness
The entire multi-agent setup lives in a single YAML file. YAML is a simple text format used for configuration, similar to a settings file. Dan's config defines the orchestrator, lists each team, assigns each agent a system prompt file, and sets the domain rules. Changing the team composition is as simple as editing that one file. Copying the config to a new project takes seconds.
Why it matters
The obvious objection is cost. Running 9 agents on every task is expensive. Dan addresses this directly: "I'm not spending enough tokens. You are not spending enough tokens." A full team run costs around $8. His backend developer used over 100,000 tokens in a single session. His argument is that token prices are falling while model intelligence is rising. Optimizing for low cost today means optimizing against a trend that is moving in your favor.
The deeper argument is about compounding. A single agent resets after each session. An agent team with persistent mental models does not. Each session adds knowledge. After ten sessions, the team knows your codebase better than a new developer would. After a hundred, it knows things about your codebase you may have forgotten yourself.
Domain ownership flips the risk equation for large codebases. The usual worry about AI agents is that they might change the wrong file. Domain locking makes that impossible by design. An agent that cannot touch the database cannot accidentally break the database. More agents, more autonomy, but contained to defined areas.
The direction is clear: from single agent to agent team. A custom harness like Pi lets you build specialized teams with persistent memory and strict boundaries. The principle: specialization beats generalization, and teams that learn beat tools that forget.
Glossary
| Term | Definition |
|---|---|
| Agent team | A group of specialized AI agents that work together on a task, each handling a specific part, instead of one agent doing everything |
| Orchestrator | The top-level agent in a multi-agent system. It receives your message and delegates work to the right teams or agents below it |
| Subagent | A child agent spawned by a parent agent to handle a specific subtask |
| Domain ownership | Rules that restrict which files and folders each agent can read or modify. Keeps agents contained to their area of responsibility |
| Mental model | A file where an agent stores what it has learned across sessions — patterns, decisions, risks — so it gets smarter over time |
| Agent harness | The software framework that runs and configures your agents, like Pi or Claude Code |
| Context window | The maximum amount of text an AI model can process at once. Larger windows let agents load more code and memory per session |
| YAML | A simple text format used for configuration files — like a settings file written in plain, human-readable language |
Sources and resources
Want to go deeper? Watch the full video on YouTube →