Claude Code está se livrando dos subagents?

Autoria: AICodeKing · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Claude Code is getting rid of SUB-AGENTS? · Canal: AICodeKing · 10:57 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Claude Code, Engenharia de software com IA

Resumo

O vídeo apresenta as recomendações do artigo da Anthropic “When to Fold Sub-Agents into Your Main Agent Loop”: evitar dividir agentes por áreas como se fossem equipes de uma empresa e preferir um loop principal com skills e tools carregadas quando necessário. Subagents continuam úteis para verificação independente, trabalho paralelo e tarefas com permissões restritas, mas podem aumentar custos, latência e perda de contexto. Em seguida, o apresentador mostra como aplicar essa escolha no Panda Coder, que oferece modos de agente único e de equipe. A recomendação final é começar com um único chat e usar uma equipe quando houver um motivo concreto, medindo os resultados ao mudar a configuração.

Pontos-chave

O artigo alerta que dividir agentes conforme a estrutura organizacional pode adicionar custo e latência sem melhorar a qualidade.
Progressive disclosure carrega skills e tools apenas quando são necessárias, em vez de colocar todas as instruções no system prompt desde o início.
Subagents podem ser úteis para verificação com contexto novo, trabalho paralelo independente e permissões limitadas.
Tarefas cujas etapas dependem umas das outras, compartilham dados ou costumam acontecer juntas tendem a ficar no loop principal.
O artigo recomenda transformar o prompt de um subagent em uma skill e suas chamadas de API em tools, fazendo a mudança uma unidade por vez.
Para comparar configurações, o artigo sugere começar com 10 exemplos reais e executar cada eval mais de uma vez.
No Panda Coder, equipes podem combinar workers de leitura e escrita, atribuir escopos de arquivo e configurar dependências entre tarefas.
Equipes podem acelerar pesquisas paralelas e revisões independentes, mas cada worker adiciona uma execução de modelo e pode consumir mais tokens.
A recomendação prática do apresentador é começar com um único chat e recorrer à equipe quando houver uma justificativa clara.

Capítulos

Início	Capítulo	Resumo
00:03	A recomendação de reduzir a divisão em subagents	O apresentador resume o argumento do artigo contra copiar a estrutura de uma empresa para a organização dos agents e explica quando manter subagents.
05:17	Como a escolha funciona no Panda Coder	O vídeo apresenta o modo de equipe do Panda Coder, seus workers, seus escopos de arquivo e a alternativa de usar um único agent.
07:50	Quando usar uma equipe ou um único chat	O apresentador compara casos favoráveis ao trabalho em equipe, como pesquisa paralela, com tarefas sequenciais que se encaixam melhor em um único chat.
09:23	Custos e regra prática	O vídeo destaca o consumo de tokens e a perda de detalhes nas passagens entre workers e recomenda começar com um único chat, usando equipes por motivos claros.

Citações

As empresas usam subagents em excesso porque copiam sua estrutura organizacional para o agent. — 00:34

Mantenha o trabalho no loop principal quando cada etapa depende da anterior, quando as etapas compartilham os mesmos dados ou quando quase sempre são chamadas juntas. — 02:38

A regra para os três casos é dividir por contexto, não por tipo de problema. — 04:46

Comece com um único chat e justifique o uso da equipe com um motivo que consiga nomear. — 09:54

Conceitos e entidades

When to Fold Sub-Agents into Your Main Agent Loop (conceito): Artigo que recomenda avaliar quando incorporar responsabilidades de subagents ao loop principal de um agent.
Diane Sarkis (pessoa): Autora do artigo discutido no vídeo.
Anthropic (empresa): Empresa citada como responsável por reduzir o system prompt do Claude Code usando a divulgação progressiva de skills e tools.
Claude Code (ferramenta): Ferramenta citada no exemplo de redução do system prompt por meio da divulgação progressiva.
progressive disclosure (conceito): Abordagem em que o agent começa com descrições breves e carrega skills ou tools completas quando precisa delas.
Conway’s Law (conceito): Ideia de que a estrutura de um sistema tende a refletir a estrutura das equipes que o construíram.
Panda Coder (ferramenta): Aplicativo mostrado no vídeo, com modos de agente único e equipe para executar tarefas de programação.
Codex (ferramenta): Uma das opções de harness e modelo mencionadas para executar workers no Panda Coder.

Tradução completa (pt-BR)

00:03 Oi, bem-vindos a mais um vídeo. A Claude publicou um artigo que diz a muitos de nós que estávamos construindo agents do jeito errado. Ele se chama “When to Fold Sub Agents into Your Main Agent Loop”. Foi escrito por Diane Sarkis e publicado em 22 de outubro de 2026. Neste vídeo, primeiro vou explicar em palavras simples o que o artigo diz e, depois, vou mostrar como a mesma ideia funciona no Panda code, que oferece tanto um chat individual normal quanto um modo de equipe completo. Ao final, você deverá saber quando usar uma equipe e quando um único chat é a opção melhor e mais barata.

00:34 Agora, vamos falar do artigo, porque a ideia principal é simples, mas vai contra o que a maioria das pessoas faz atualmente. O artigo diz que as empresas usam subagents em excesso porque copiam seu organograma para dentro do agent. A equipe de cobrança ganha um subagent de cobrança, a equipe de suporte ganha um subagent de suporte, e um orquestrador fica no topo, encaminhando o trabalho entre eles. O artigo chama isso de lei de Conway em ação: a velha ideia de que um sistema acaba tendo o formato das equipes que o construíram. Parece organizado em um diagrama, mas o artigo argumenta que isso muitas vezes prejudica a qualidade, além de aumentar o custo e a latência. O que ele propõe no lugar? Um agent principal

01:05 com um loop que carrega skills e ferramentas apenas quando a tarefa precisa delas. O artigo chama isso de divulgação progressiva, o que significa simplesmente que o agent começa com descrições curtas e carrega a skill ou ferramenta completa somente no momento em que precisa dela. Assim, um agent pode dar conta de muito trabalho sem carregar todas as regras em cada execução. E isso não é só teoria. O artigo diz que a Anthropic reduziu em mais de 80% o system prompt do Claude Code para os modelos mais avançados, em parte divulgando skills e ferramentas dessa maneira, em vez de carregar tudo de uma vez. Então, é isso. Agora, para ser justo, o artigo não diz que subagents são sempre ruins

01:37 e esse equilíbrio é o motivo de eu gostar dele. Subagents ainda ajudam na verificação, quando um agent novo confere um trabalho que não fez e pode detectar erros que quem fez o trabalho acaba se convencendo a ignorar. Eles ajudam no trabalho em paralelo, quando as partes não dependem umas das outras, e também ajudam a modular as permissões, quando você concede a uma parte específica do trabalho apenas o acesso restrito de que ela precisa, em vez de entregar as chaves de tudo a um único agent grande. Mas, se você dividir demais, surgem os modos de falha que o artigo cita. E, para ser sincero, já vi todos eles. Há a briga dos subagents, em que cada

02:08 equipe lança seu próprio subagent sobreposto, e ninguém é responsável pelo conjunto. Há o Frankenprompt, em que cada equipe acrescenta mais uma frase ao system prompt até as regras entrarem em conflito. Há o telefone sem fio, em que cada transferência entre agents perde um pouco de detalhe, de modo que o último agent trabalha com uma versão apagada do que o primeiro sabia. E cada loop aninhado acrescenta latência, porque cada subagent é mais uma execução completa de um agent. O artigo dá um número para essa latência. Em um caso de cliente, um loop com um único agent foi aproximadamente duas vezes mais rápido que a configuração multiagent que substituiu.

02:38 Considere isso com cautela, já que se trata de um único caso, mas a tendência faz sentido quando você conta quantas execuções extras uma cadeia profunda consome. Então, como decidir o que fica no loop principal? O critério do artigo é simples. Mantenha o trabalho no loop principal quando cada etapa se baseia na anterior, quando as etapas compartilham os mesmos dados ou quando quase sempre são chamadas juntas. Se duas partes estão sempre juntas, separá-las só acrescenta uma transferência no meio, sem benefício. Depois, escolha o contêiner certo dentro desse único loop. O julgamento de domínio, como a maneira que um especialista lida com um caso, pertence a uma skill. Uma ação, dados ao vivo de um sistema ou um limite rígido pertencem a uma ferramenta. E um fato de que você só precisa agora

03:10 e que não será necessário depois não pertence ao prompt. Ele pertence a uma consulta a uma base de conhecimento, que o agent faz quando precisa. Julgamento em uma skill, ação em uma ferramenta, fatos ocasionais em uma consulta: essa divisão já organiza a maioria das configurações confusas. O artigo também diz que é possível incorporar de volta os roteadores, planejadores e especialistas de escopo restrito que muitos de nós criamos no ano passado, porque agora o modelo principal faz boa parte desse roteamento, planejamento e categorização por conta própria, como parte do raciocínio normal. O exemplo apresentado é uma configuração com um classificador, um pipeline, ramificações separadas e um orquestrador no topo,

03:42 tudo substituído por um prompt claro, quatro ou cinco ferramentas simples que trabalham com dados e limites de segurança firmes. O mesmo trabalho, com muito menos partes móveis. Mas há um alerta junto disso. O artigo diz que a escolha de ferramentas se deteriora quando se passa de aproximadamente 30 a 50 definições de ferramentas no prompt. Portanto, incorporar o trabalho a um único loop não significa despejar tudo nele. Significa um loop, um pequeno conjunto de ferramentas com nomes claros, agrupadas pelo que o usuário quer fazer, e o restante divulgado apenas quando necessário. Então, como fazer essa mudança sem quebrar um sistema que está funcionando? Incorpore um subagent de cada vez, começando pelo

04:13 par que você mais usa ou pelo par que está mais fortemente acoplado. Transforme o prompt desse subagent em uma skill e as chamadas de API dele em ferramentas; depois, meça os resultados antes de mexer no próximo. E a medição pode começar em pequena escala. O artigo diz que até mesmo 10 exemplos de referência bastam para começar, ou seja, um pequeno conjunto de tarefas reais para as quais você sabe como é um bom resultado. Execute a configuração antiga e a configuração incorporada com os mesmos exemplos e compare. E execute cada eval mais de uma vez, porque o artigo descreve uma cadeia de suporte em que a incorporação quebrou o fluxo sem que ninguém percebesse, e a falha apareceu em apenas uma de duas execuções. Execute uma vez

04:46 e passe por sorte, e você lançou uma cara ou coroa. Em que situações manter um subagent separado, depois de tudo isso? O artigo apresenta três motivos. E vale a pena guardar esta lista de verificação. Mantenha-o separado somente se conseguir medir que o contexto dele piora o desempenho do agent principal; se o trabalho funciona bem em paralelo, em contextos novos que você pode descartar quando terminarem; ou se um único agent continuar tendo dificuldade para escolher ferramentas ou lidar com instruções conflitantes. A regra por trás dos três motivos é dividir por contexto, não por tipo de problema. Dê a um agent separado um trabalho que dependa pouco do restante do sistema e deixe que ele

05:17 devolva um único resultado compacto, como uma pesquisa independente ou uma verificação de caixa-preta de um trabalho concluído. Se eu resumisse o artigo em uma linha, seria: meça, mude uma coisa de cada vez e mantenha o que se mostrar eficaz. Não reestruture com base em intuições, em nenhuma direção. Agora, vamos à segunda metade, porque é aqui que a coisa fica prática. Deixe-me mostrar como a mesma escolha aparece no Panda code, o aplicativo que uso neste canal para executar agents de programação e que oferece tanto um modo de agent individual quanto um modo de equipe para a mesma tarefa. Uma observação sincera antes de começar: o Panda

05:47 code não usa a palavra “incorporar” em sua documentação. Essa palavra é do artigo. O que faço aqui é apresentar minha interpretação: pego o princípio do artigo e aponto a opção do Panda Coder que faz o mesmo trabalho. É importante manter essas duas coisas separadas na sua cabeça. Então, é isto que uma equipe do Panda Coder realmente é. Você tem um arquiteto, que é o agent no seu chat principal. O arquiteto planeja o trabalho, divide-o em tarefas, distribui várias tarefas para workers em paralelo, em um único lote, e depois revisa o que eles devolvem. Cada worker é executado em seu próprio contexto novo. Um worker não é uma cópia do seu

06:18 chat principal e não vê toda a sua conversa. Ele recebe uma tarefa própria e delimitada, executa o trabalho e envia um relatório. >> E, se você olhar aqui, verá que cada worker pode ser executado em um harness e modelo diferentes, com sua própria configuração de esforço. Pode ser Claude Code, Codex, Kimmy, Open Code, GLM, Muse ou outra opção compatível. Você também pode salvar perfis de equipe. Assim, uma configuração de que você gosta — por exemplo, um arquiteto forte com alguns workers mais baratos — fica disponível em uma única escolha da próxima vez, em vez de você ter que montá-la manualmente de novo. Isso é muito bom, sem dúvida, se você estiver de olho nos gastos.

06:49 porque você controla para onde vai o tempo do modelo caro. Deixe-me mostrar como os workers dividem o trabalho. Workers somente de leitura inspecionam e revisam o código sem alterá-lo, e podem trabalhar ao mesmo tempo que os workers que escrevem. Workers de escrita declaram um escopo restrito de arquivos antes de começar. Assim, um worker fica responsável pelo código de dados, outro pela interface e outro pelos testes. Se dois escopos de escrita se sobrepõem, Panda Coder executa esses workers um depois do outro, em vez de ao mesmo tempo. Esse escopo é uma orientação, não uma sandbox. Portanto, trate-o como uma convenção forte que mantém os workers fora do caminho uns dos outros, não como uma barreira. Você também pode encadear

07:20 workers com dependências, de modo que um worker de revisão só comece depois que o worker de escrita que ele revisa terminar. E, quando um worker está quase certo, mas ainda não está, uma continuação envia sua correção para o contexto daquele mesmo worker. Isso é mais importante do que parece. Uma continuação preserva o que o worker já aprendeu, em vez de fazer você pagar por um worker novo que começa do zero. Na linguagem do artigo, isso é uma transferência que você acabou de evitar. E qual é o ciclo principal nesta imagem? É a opção simples. Use um único agent em um chat normal ou deixe o arquiteto simplesmente responder e editar diretamente, sem delegar nada. Na minha interpretação, isso é recuar

07:50 e seguir em frente. Sem workers, sem transferências, com todo o contexto em um só lugar. A escolha que você faz no início de uma tarefa no PandaCode é exatamente a escolha descrita pelo artigo, e é por isso que eu quis mostrar os dois lado a lado. Então, em que situações a equipe realmente leva vantagem? Deixe-me mostrar os casos em que eu recorro a ela. Se enviarmos vários workers somente de leitura, você pode vê-los pesquisar diferentes partes de uma base de código ao mesmo tempo, e cada um retorna um breve relatório enquanto o chat principal continua organizado. Para um recurso maior, um worker cria a parte de dados, outro cria a interface,

08:21 outro escreve os testes, e um worker de revisão separado verifica o resultado com um olhar novo. Esse é exatamente o caso de verificação do artigo. Uma equipe também é vantajosa quando você quer executar o mesmo prompt em diferentes modelos para comparar os resultados lado a lado. E quando você tem edições em lote que um modelo de worker mais barato pode fazer enquanto o modelo mais forte apenas planeja e revisa. Ela também é vantajosa em tarefas longas que preencheriam uma context window, porque cada worker leva consigo apenas a sua parte, enquanto o arquiteto mantém o fio da meada. Mas agora, o outro lado, porque sempre há outro lado. Para um erro de digitação em um único arquivo ou uma pequena correção de configuração, uma equipe é puro custo extra. Use um único chat. Para ajustes interativos, quando você precisa observar cada etapa, um chat mantém você por dentro, em vez de fazer você revisar o trabalho pronto depois. Para depurar um teste que falha, quando cada tentativa se baseia na anterior, mantenha esse estado compartilhado em um só lugar. O mesmo vale para uma pergunta rápida sobre código que já está no seu contexto e para edições sucessivas no mesmo arquivo. Nas palavras do artigo, esse trabalho se encadeia a etapas anteriores e compartilha dados, então pertence ao ciclo principal. Também quero ser sincero sobre os custos

08:52 porque não quero vender o modo de equipe como velocidade grátis. Cada worker é outra execução de modelo, então uma equipe grande consome tokens mais rápido do que um único chat, especialmente se você colocar modelos fortes em todas as posições. Os workers retornam resumos limitados, então alguns detalhes se perdem em cada transferência, assim como no jogo do telefone sem fio sobre o qual o artigo alerta. >> E todos os workers compartilham o mesmo checkout na sua máquina, por isso esses escopos restritos de arquivos são importantes. A equipe oferece tempo em paralelo e olhares novos, e você paga por isso em tokens e com uma pequena perda de detalhes. Conheça essa troca antes de escolher. Minha regra, depois de ler o artigo, é

09:23 simples, e ela segue a recomendação do artigo. Comece com um único chat e só recorra à equipe quando tiver um motivo que consiga nomear. Pesquisa em paralelo, uma divisão clara, uma verificação separada, um trabalho longo demais para uma única context window. Se não consigo nomear o motivo, fico no ciclo principal. E, na maioria dos dias, essa acaba sendo a opção mais rápida e barata. No geral, acho que vale a pena ler este artigo, mesmo que você nunca crie um agent para ninguém além de si mesmo, porque a maioria de nós já copiou nossos próprios hábitos para configurações de agents maiores do que a tarefa exige. E gosto que Panda code mantenha as duas opções a apenas uma decisão de distância,

09:54 então voltar a um único agent é simplesmente uma forma de começar a tarefa, não uma reescrita. Comece de forma simples, avalie, mude uma coisa de cada vez e mantenha o que funciona. No geral, é bem legal. Enfim, conte o que você achou nos comentários. [música] Se você gostou deste vídeo, considere fazer uma doação pela opção Super Thanks ou tornar-se membro clicando no botão de adesão. Além disso, curta este vídeo e inscreva-se no meu canal. Vejo você no próximo. Até lá, tchau.

10:25 >> [música]

10:57 >> [música]

Transcrição original

[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]