Claude Code is getting rid of SUB-AGENTS?

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Claude Code is getting rid of SUB-AGENTS? · Channel: AICodeKing · 10:57 · Watch on YouTube

Topics: AI agents, Task and workflow automation, Claude Code, Software engineering with AI

Summary

The video explains an article arguing that teams often overuse sub-agents by mirroring organizational structures, adding cost, latency, and information loss. It recommends keeping connected, sequential work in one agent loop and using skills, tools, and knowledge lookups for different kinds of capability and information. Separate agents remain useful for measurable context isolation, parallel work, and independent verification, with changes evaluated one at a time. The presenter applies these ideas to Panda Coder, comparing single-agent chat with team mode and outlining when each is worthwhile.

Key points

Sub-agents can be overused when agent architecture copies an organization chart rather than the needs of the work.
Progressive disclosure lets a main agent load skills and tools only when they are needed.
Sub-agents can help with independent verification, parallel tasks, and narrowly scoped permissions.
Too many agents can create overlapping responsibilities, conflicting prompts, lossy handoffs, and additional latency.
Keep steps in one loop when they build on each other, share data, or are usually used together.
Use skills for domain judgment, tools for actions or live data, and knowledge-base lookups for occasional facts.
Keep a sub-agent separate when its context measurably helps, its work runs independently in parallel, or the main agent struggles with tool choice or conflicting instructions.
The presenter describes Panda Coder teams as an architect delegating bounded tasks to workers, with options for different models, dependencies, and follow-ups.
Team mode is useful for parallel research, divided feature work, fresh reviews, model comparisons, bulk edits, and tasks that exceed one context window.
The presenter recommends defaulting to one chat and choosing a team only when there is a clear reason, while measuring changes rather than restructuring on intuition.

Chapters

Start	Chapter	Summary
00:03	Why simpler agent loops can be better	The video introduces the article’s case against overusing sub-agents and explains progressive disclosure, common failure modes, and when work belongs in one loop.
02:38	Choosing what stays in the main loop	The presenter outlines how to distinguish skills, tools, and knowledge lookups, then recommends folding sub-agents back gradually and evaluating the results.
05:17	How Panda Coder team mode works	The video describes the architect-and-worker setup, including bounded assignments, model choices, file scopes, dependencies, and the single-agent alternative.
07:50	When to use a team or a single chat	The presenter compares team-mode use cases with tasks better handled in one chat and notes the costs of extra model runs and handoffs.
09:54	Default to one chat and measure	The video closes with the presenter’s recommendation to start with one agent, use teams for a named reason, and change setups incrementally.

Quotes

The article calls this progressive disclosure — 01:05

There is the telephone game, where each handoff between agents loses a little detail — 02:08

The rule under all three is to split by context, not by problem type. — 04:46

Default to one chat and earn the team with a reason you can name. — 09:54

Concepts and entities

When to Fold Sub-Agents into Your Main Agent Loop, Diane Sarkis, Anthropic, Claude Code, progressive disclosure, Conway’s Law, Panda Coder, Codex

Full transcript (original language)

00:03 Hi, welcome to another video. So, Claude published an article that tells a lot of us we have been building agents the wrong way. It is called when to fold sub agents into your main agent loop. It is by Diane Sarkis and it came out on the 22nd of October 2026. In this video, I will first walk you through what the article says in plain words and then I will show you how the same idea works in Panda code, which gives you both a normal single chat and a proper team mode. By the end, you should know when to use a team and when one chat is the better and cheaper call.

00:34 Now, let’s talk about the article because the main point is simple, but it goes against what most people do right now. So, the article says companies over use sub agents because they copy their org chart into the agent. The billing team gets a billing sub agent, the support team gets a support sub agent and an orchestrator sits on top and routes work between them. The article calls this Conway’s law at work. The old idea that a system ends up shaped like the teams that built it. It looks organized on a diagram, but the article argues it often hurts quality while it adds cost and latency. What does it want instead? One main agent

01:05 loop that loads skills and tools only when the task needs them. The article calls this progressive disclosure, which just means the agent starts with short descriptions and pulls in the full skill or tool only at the moment it needs it. One agent can then cover a lot of work without dragging every rule into every run. And this is not just theory. The article says Anthropic cut the Claude code system prompt for the more advanced models by over 80% in part by disclosing skills and tools this way instead of loading everything up front. So, there is that. Now, to be fair, the article does not say sub agents are always bad

01:37 and that balance is why I like it. Sub agents still help for verification where a fresh agent checks work it did not make and can catch mistakes the maker talks itself out of. They help for parallel work where pieces do not depend on each other and they help for modular permissioning where you give a narrow piece of work only the narrow access it needs instead of giving one big agent the keys to everything. But split too much and you get the failure modes the article names. And to be honest, I have seen all of them. There is sub-agents brawl, where every

02:08 team ships its own overlapping sub-agent, and nobody owns the set. There is the Frankenprompt, where every team adds one more sentence to the system prompt until the rules fight each other. There is the telephone game, where each handoff between agents loses a little detail, so the last agent works from a faded copy of what the first one knew. And every nested loop adds latency because each sub-agent is another full agent run. The article puts a number on that latency. In one customer case, a single agent loop ran roughly two times faster than the multi-agent setup it replaced.

02:38 Take it with a grain of salt, since it is one case, but the direction makes sense when you count how many extra runs a deep chain burns. So, how do you decide what stays in the main loop? The article’s test is clean. Keep work in the main loop when each step builds on the step before it, when the steps share the same data, or when you almost always call them together. If two pieces always travel together, splitting them just adds a handoff in the middle for no gain. Then pick the right container inside that one loop. Domain judgment, like how an expert handles a case, belongs in a skill. An action, live data from a system, or a hard limit belongs in a tool. And a fact you only need now

03:10 and then does not belong in the prompt at all. It belongs in a knowledge base lookup the agent calls when it needs it. Judgment in a skill, action in a tool, occasional facts in a lookup, that one split cleans up most messy setups. The article also says you can fold back the separate routers, planners, and narrow specialists that many of us built last year because the main model now does much of that routing, planning, and categorizing itself as part of its normal reasoning. Its example is a setup with a classifier, a pipeline, separate branches, and an orchestrator on top,

03:42 all replaced by one clear prompt, four or five thin tools that work with data, and firm guardrails. Same job, far fewer moving parts. One warning sits next to this, though. The article says tool choice degrades once you pass roughly 30 to 50 tool definitions in the prompt. So, folding work into one loop does not mean dumping everything into one loop. It means one loop, a small set of well-named tools grouped by what the user wants to do, and the rest disclosed only when needed. So, how do you make the change without breaking a working system? Fold one sub-agent at a time, starting with the

04:13 pair you use most or the pair that is most tightly coupled. Turn that sub-agent’s prompt into a skill and its API calls into tools, then measure before you touch the next one. And the measuring can start small. The article says even 10 golden examples is enough to start, which means a small set of real tasks where you know what a good result looks like. Run the old setup and the folded setup on the same examples and compare. And run each eval more than once because the article describes a support chain where folding silently broke the flow and the break showed up in only one run out of two. Run it once

04:46 and pass by luck and you have shipped a coin flip. When do you keep a sub-agent separate after all that? The article gives three reasons. And this is the checklist worth keeping. Keep it separate only if you can measure that its context makes the main agent worse. If the work runs well in parallel in fresh contexts you can throw away when they finish. Or if a single agent keeps struggling with tool choice or with instructions that conflict. The rule under all three is to split by context, not by problem type. Give a separate agent work that needs little from the rest of the system and let it

05:17 hand back one compact result like independent research or a black box check on finished work. If I boil the article down to one line, it is this: measure, change one thing at a time, and keep what holds up. Do not restructure on vibes in either direction. Now, let’s come to the second half because this is where it gets practical. Let me show you how the same choice looks in Panda code, which is the app I use on this channel to run coding agents and which gives you both a single agent mode and a team mode for the same task. One honest note before I start, Panda

05:47 code’s own docs never say fold. That word is the articles. What I do here is my interpretation, taking the articles principle and pointing at the Panda Coder option that does the same job. It is important to keep those two things separate in your mind. So, here is what a Panda Coder team actually is. You have one architect and that is the agent in your main chat. The architect plans the work, splits it into assignments, dispatches several workers in parallel in one batch, and then reviews what comes back. Each worker runs in a fresh context of its own. A worker is not a copy of your

06:18 main chat and it does not see your whole conversation. It gets its own bounded assignment, does that job, and reports back. >> And if you look here, you can see that each worker can run on a different harness and model with its own effort setting. Whether that is Claude Code, Codex, Kimmy, Open Code, GLM, Muse, or another supported option. You can also save team profiles. So, a setup you like, say a strong architect with a couple of cheaper workers, is one pick next time instead of something you rebuild by hand, which is pretty good for sure if you watch your spend,

06:49 because you control where the expensive model time goes. Let me show you how the workers divide the work. Read-only workers inspect and review code without changing it and they can run alongside workers that write. Writing workers declare a narrow file scope before they start. So, one worker owns the data code, another owns the interface, another owns the tests. If two writing scopes overlap, Panda Coder runs those workers one after the other instead of at the same time. That scope is advisory, not a sandbox. So, treat it as a strong convention that keeps workers out of each other’s way, not as a wall. You can also chain

07:20 workers with dependencies, so a review worker starts only after the writing worker it reviews has finished. And when a worker is close but not right, a follow-up sends your correction into that same worker’s context. That matters more than it sounds. A follow-up keeps what the worker already learned instead of paying for a brand new worker that starts from zero. In the articles language, that is a handoff you just avoided. And what is the main loop in this picture? It is the simple option. Use a single agent in a normal chat or let the architect just answer and edit directly without delegating at all. That in my interpretation is the fold back

07:50 and move. No workers, no handoffs, full context in one place. The choice you make at the start of a task in PandaCode is exactly the choice the article describes, which is why I wanted to show them side by side. So, where does the team genuinely win? Let me walk you through the cases where I reach for it. If we send out several read-only workers, you can see them research different parts of a code base at the same time and each one hands back a short report while the main chat stays clean. For a bigger feature, one worker builds the data side, one builds the interface,

08:21 one writes the tests, and a separate review worker checks the result with fresh eyes. That is exactly the verification case from the article. A team also wins when you want the same prompt run across different models so you can compare the results side by side. And when you have bulk edits that a cheaper worker model can do while the strong model only plans and reviews. And it wins on long tasks that would fill one context window because each worker carries only its own slice and the architect holds the thread. But now the other side, because there is always another side. For a one-file typo or a

08:52 small config fix, a team is pure overhead. Use a single chat. For interactive tweaks where you need to look at every step, one chat keeps you in the loop instead of reviewing finished work after the fact. For debugging one failing test where every attempt builds on the last, keep that shared state in one place. The same goes for a quick question about code already in your context and for edits that hit the same file one after another. In the article’s words, that work chains on prior steps and shares data, so it belongs in the main loop. Let me also be honest about the costs

09:23 because I do not want to sell you the team mode as free speed. Every worker is another model run, so a wide team burns tokens faster than one chat, especially if you put strong models on every seat. Workers report back in bounded summaries, so some Some is lost in every handoff, just like the telephone game the article warns about. >> And all the workers share the same checkout on your machine, which is why those narrow file scopes matter. The team buys you parallel time and fresh eyes, and you pay for that in tokens and in a bit of lost detail. Know the trade before you pick it. My own rule after reading the article is

09:54 simple, and it matches its advice. Default to one chat and earn the team with a reason you can name. Parallel research, a clean split, a separate check, a job too long for one context. If I cannot name the reason, I stay in the main loop. And most days that is the faster and cheaper answer anyway. Overall, I think this article is worth your time, even if you never build an agent for anyone but yourself, because most of us have copied our own habits into agent setups that are bigger than the task. And I like that Panda code keeps both options one decision apart,

10:25 so folding back to a single agent is just how you start the task, not a rewrite. Start simple, measure, change one thing at a time, and keep what holds up. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. [music] If you like this video, consider donating through the Super Thanks option or becoming a member by clicking the join button. Also, give this video a thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye.

10:57 >> [music]