--- title: "One Agent Is Not Enough: Multi-Team Agentic Coding Beyond Claude Code" author: "Technical video — Multi-agent Coding" description: "If you have been building with agents and pushing what you can do with your agentic coding tool, you have realized something critical. One agent is not enough. Imagine it is the end of 2026 and you..." source: "https://adhenawer.net/posts/original/one-agent-not-enough-multi-team-agentic-coding-beyond-claude-code.html" lang: en --- TL;DR · key points 1. If you have been building with agents and pushing what you can do with your agentic coding tool, you have realized something critical. 2. Multi-agent orchestration and tools like Claude Code are the current frontier. ## ONE AGENT IS NOT ENOUGH [0:00](https://youtu.be/M30gp1315Y4?t=0) If you have been building with agents and pushing what you can do with your agentic coding tool, you have realized something critical. One agent is not enough. Imagine it is the end of 2026 and you have evolved your engineering from a single agent, to multiple agents, to agent teams. They have been building and learning just like you, because you stopped using agents that forget and started using agent experts. Each agent team you have contains agents with their own skills, expertise, and domain knowledge, supercharging them so they outperform any other agent. In fact, you have a few agent teams that are outperforming your co-workers. Multi-agent orchestration and tools like Claude Code are the current frontier. But this system pushes beyond Claude Code. It is multi-team agentic coding: specialized teams of agents that outperform the normal distribution of results. If you are a cost min-maxer who cares more about saving money than getting results, this is not for you. But if you are an engineer working on mid to large size production codebases, the performance gains from multi-team agentic coding are worth a close look. ## A THREE-TIER ARCHITECTURE: ORCHESTRATOR, LEADS, WORKERS [1:46](https://youtu.be/M30gp1315Y4?t=106) The entire experience has been re-engineered into a chat room with teams of agents. You only ever talk to the orchestrator. A simple “ping” returns a classic pingpong response. Ask it to “ping each team lead” and the orchestrator calls every team lead. This is a two-layer interaction on the surface, but underneath there is a three-tier architecture: orchestrator, team leads, and workers. When you say “have engineering present a tree structure of the most important files,” you are delegating directly to the engineering team. The engineering lead takes over. Then something important happens: the engineering lead tries to access files it does not have permission to. It realizes it stepped out of its domain, so it delegates to team members who have the right tools. It prompts the back-end developer and the front-end developer in parallel. Both agents get work done in a chat-like interface, respond to the lead, the lead responds to the orchestrator, and the orchestrator gives you a full breakdown. The flow is always the same: orchestrator talks to leads, leads talk to workers, and you get one unified response. You converse with the orchestrator and no one else. This is the key to keeping your cognitive input low while the number of specialized agents grows. ## THE WORKING EXAMPLE: A PROMPT COMPLEXITY CLASSIFIER [4:25](https://youtu.be/M30gp1315Y4?t=265) The teams operate on a prompt-routing codebase, a common problem for LLM-based applications. You do not want to pay for intelligence you do not need. When thousands of users hit your application, simple prompts do not need to hit expensive models. You do not want Opus 4.6 with high reasoning when Claude Haiku or Sonnet would do. The codebase contains a prompt complexity classifier. Running “just predict summarize this codebase” routes the request to a medium-tier model with the confidence scores printed out — a request of that kind would go to Sonnet 4.6 or whatever medium-tier model is configured. This is the problem. The point is not to build the classifier by hand. Agents build it. At a previous job as a lead data scientist, building classifier models by hand took a lot of time. Now agents do it, and an entire team knows how to operate this codebase better than anyone. ## MULTI-PERSPECTIVE ANSWERS FROM PARALLEL TEAMS [6:05](https://youtu.be/M30gp1315Y4?t=365) Asking “ask all teams what are two additional scikit-learn classifiers we can test our current classifier against” triggers the chat pattern. The orchestrator writes the exact same prompt to every team — consistency is critical. The planning lead, engineering lead, and validation lead take over. Each lead decides independently whether to delegate further: the engineering lead delegates to the backend dev; the validation lead delegates to the security reviewer and QA engineer. All three teams weigh in. Strong consensus emerges: LinearSVC with CalibratedClassifierCV is a unanimous pick. There is a split recommendation on ComplementNB, with engineering also preferring SGDClassifier. Everyone agreed to skip certain options. Every agent can see the conversation — searching the session ID reveals a JSONL conversation log with every lead and every dev exchange. Every agent is aware of the full conversation. The orchestrator starts guiding the experience and offers a next step. ## PLAN, ENGINEER, VALIDATE: A REUSABLE WORKFLOW [8:30](https://youtu.be/M30gp1315Y4?t=510) With the team structure in place, you can drive it more precisely: “plan, engineer, then validate. Make sure to add just commands to test both models and call it just prompt both.” The orchestrator writes a detailed plan, then the leads dive in. The planning lead always loads context first. The philosophy is spend to win — never be afraid to give agents all the relevant context they need. With Claude's 1M context window available, loading expertise and session history is cheap insurance against bad output. The QA engineer finds issues the security reviewer misses. Multiple agents on the same team find different things because each has different context windows, different perspectives, and can run different models. The validation lead reports the results up, the orchestrator composes them, and because the orchestrator has a “conversational response” skill, you get a concise summary instead of a wall of text. ## THE PY FILE AND THE CONFIG-DRIVEN APPROACH [11:14](https://youtu.be/M30gp1315Y4?t=674) It all starts with the .py file. Unlike Claude Code where you configure agents, prompts, and skills inside a fixed structure, customizing the agent harness lets you control everything — folders, individual files, the whole experience. The entry point is a multi-team YAML config. Config-driven is the key property: you can copy the config, change the teams, and specialize however you need. The config declares an orchestrator (with a path to its system prompt) and individual teams. Each team has a lead (system prompt and name), a team color, and members. The pattern repeats for every team. Three key nodes of building software — planning, engineering, validation — map cleanly onto three teams. Reusable, customizable systems that are easy to change and update. ## AGENT EXPERTS: MEMORY, SKILLS, AND DOMAIN [12:37](https://youtu.be/M30gp1315Y4?t=757) The orchestrator system prompt has a name and a model (the best intelligence available for coordination), then deviates from the default experience. It has expertise — a mental model of everything that happened, capped at max_lines (10,000 is generous but still fits easily in a 1M context window). It has skills. One of the critical ones is “zero micromanagement,” shared between the orchestrator and all leads. The rule: delegate the right work at the right time; never execute. Skills are composable. The conversational response skill is shared between orchestrator and leads but intentionally omitted from the back-end developer, because developers should be verbose and detail-oriented. The special tool for the orchestrator and the leads is delegate. That alone adds enormous power. Then there is domain, which specifies what agents can and cannot do and where they can and cannot go. The planning lead has read access to everything and read/update access to the .py directory where it writes its expertise. It has full read access to the specs directory but cannot update it — plans must be delegated for writing. Front-end dev can read the backend but never touch it. Back-end dev is the opposite. In a codebase of thousands of files, this kind of domain locking is the holy grail of safely operating with powerful agents. ## MENTAL MODELS: AGENTS THAT LEARN OVER TIME [23:04](https://youtu.be/M30gp1315Y4?t=1384) Every agent loads its expertise file when it boots. Agents remember. Every time you run your team, they take notes, build up their mental model, and load it at the beginning of the next session. The many read tool calls you see at the start of a session are agents loading the conversation log and their own specialized memory. The back-end developer's mental model carries information about previous codebases it operated in — around 5,000 tokens of high-level references: specs, missing infrastructure, key risks, backend patterns, security concerns, testing notes. The engineer does not touch it. That is a core idea: you cannot have your fingers on everything. You have to let go, teach agents to operate as you would, and trust them to maintain their own mental models. Guidelines on how to build great mental models live in the mental model skill — 77 lines. Agents maintain and update the rest on their own. Over time, each team member builds a stacking, compounding set of memory that lets them specialize further and further. When you ship legitimate production software, always going through the team becomes important because the team is what accumulates knowledge. ## ACTIVE LISTENER AND SHARED CONVERSATION [23:24](https://youtu.be/M30gp1315Y4?t=1404) The orchestrator system prompt injects variables at runtime: session directory, conversation log, teams (dynamically pulled from YAML), individual tools, and the full expertise and skills blocks lifted from front matter and placed directly into the system prompt. The orchestrator is acutely aware of its own skills. One shared skill is “active listener” — read the conversation log before every response. You may not always want this, but for the orchestrator and every team member in this setup, it is required. Composing skills this way lets you quickly modify capabilities across agents. Shared capability is common; occasionally you want one agent to be independent of the current conversation. Changing that is a one-line edit. ## SESSIONS AS SHARED WORKSPACE [23:26](https://youtu.be/M30gp1315Y4?t=1406) The session directory stores every tool call for every team, the full conversation log, and the starting system prompt for each agent. Opening the back-end dev's session shows exactly what its system prompt looks like with everything templated in. Because this information is in the system prompt itself, the agent adheres to it strongly. This is complete customization of the core four — context, model, prompt, tools — down to the system prompt level. Results flow naturally: the back-end dev writes results into the session, the lead reads them, the orchestrator reports them back. For the prompt-routing problem specifically, when high intelligence is needed, the classifier should be biased toward that. Predicting medium or low when high is required is a bad user and customer experience. The safe default is push to high; tune toward mid based on your business financials, ideally never low. ## WHY THIS OUTPERFORMS SINGLE-AGENT CODING [29:26](https://youtu.be/M30gp1315Y4?t=1766) Several converging trends make this work: massive context windows at decreasing cost, specialized agent experts that accumulate knowledge, and customizable agent harnesses. Large context windows coming in cheaper means so many tokens will be available — the question is whether you are using them. Agent expertise means you can load up specialization and memory for every agent. The agent harness means you customize not just agents and teams of agents but the entire experience. Specialization happens on multiple dimensions. Anyone can specialize individual agents with Claude Code subagents. But teams with domains and a single orchestrator interface mean your cognitive input does not need to grow as the number of specialized agents grows. Delegation starts with the orchestrator; every team focuses on its specialty; every team is fine-tunable. Leads are typically a more powerful Opus model; workers are Sonnet. Workers just need to follow instructions and execute. If you are going all out, make everything the best possible model. The 1M context window matters. A busy back-end dev easily passes 100K tokens spent, and that will only grow as knowledge and domain expertise stack up. ## WHERE THIS GOES NEXT [32:17](https://youtu.be/M30gp1315Y4?t=1937) Once you have an opinionated structure, the next step is a meta-agent or meta-team that helps you fine-tune and improve the team. Team-based custom commands — also called skills — are another natural extension. The classic plan-build-validate workflow becomes a reusable prompt with your teams baked in. Much of the value comes from agents stacking knowledge over time. Fine-tuning the mental model skill to track results correctly is a major lever. Expertise is a list, so you can add highly opinionated knowledge to specific agents: a database migration agent, a billing agent, a DevOps agent. Read-only expertise files that only the billing agent has prevent anyone else from touching that context. Billing, migrations, DevOps, deploying — all great examples of specialized engineering. You do not want a generic agent doing this. You want an agent with expertise, just as you would trust a human engineer who has done it many times. Locking in expertise is a massive advantage for engineers who understand why agent experts will always outperform generic agents. Skills, specialized tools (even just delegate adds enormous power), and domain locking together form the holy grail of operating mid to large codebases with agents that keep getting smarter while token costs keep dropping. ## SPEND TO WIN [33:06](https://youtu.be/M30gp1315Y4?t=1986) Engineers watching this will fixate on cost. “Eight dollars for one agent team run. You are wasting tokens communicating between agents.” That is thinking about right now, not far enough into the future. Models will improve. Costs are going down. Tokens will be available at insane volumes. The consistent message: you are not spending enough tokens, and you are wasting time doing things the old way. The old way is one agentic coding tool in a terminal, prompting back and forth. Push yourself to spend more tokens to do more work with agents. This is the greatest opportunity that has ever existed for engineers. The question now is: can you agentic code? Can you agentic engineer? Can you build systems that build systems on your behalf? ## TRUST AND SCALE [33:55](https://youtu.be/M30gp1315Y4?t=2035) The name of the game in 2026 is trust and scale. What can you do with your agentic coding tools and systems to increase trust in your agents to a level where you know they will ship the result when you hit enter? Then scale it. How big can you go? How surgical can your agents be? Agents with specialized expertise that builds over time will play a critical role. This is not one model capturing memory of everything you have ever said to it — that will not go well. What will go well is specialized agents with specific purposes, growing context windows, and increasing intelligence, arranged inside an agent harness you have learned to specialize. More tools like this will emerge, but the ideas stay the same. The real question becomes: do you know how to build agent experts, and can you build teams of experts that operate autonomously on your behalf? No matter what, stay focused and keep building.