![Imagem de capa de [Contexto de IA #5] Subagentes: isolamento e delegação](/assets/images/posts/6f12e091-1d37-4258-b659-1070e39916f1/1.jpg)
Nos capítulos anteriores, vimos como economizar contexto: limpar o histórico a cada limite de trabalho (parte 3) e manter os custos fixos curtos (parte 4). Ainda assim, há tarefas grandes demais para serem absorvidas. Um exemplo típico é: “Descubra como a lógica de pagamentos flui nesta base de código.” Um agente diligente leria dezenas de arquivos e, como vimos na parte 1, tudo o que ele lê se acumula no contexto. Quando a investigação termina, já não resta contexto para fazer o que esse conhecimento permite: alterar o código.
Este capítulo aborda os subagentes, que resolvem o problema de forma estrutural. O ponto principal é simples: você não precisa ter apenas uma janela de contexto.
Trabalhe em outro contexto e traga apenas a conclusão
Um subagente é uma instância separada de agente criada pelo agente principal. O essencial é que essa instância recebe uma nova janela de contexto limpa e própria.
O fluxo é o seguinte. O agente principal envia uma única instrução a um subagente: “Investigue e resuma como a lógica de pagamentos flui.” O subagente lê dezenas de arquivos em seu próprio contexto, pesquisa e rastreia as relações entre chamadas. Dezenas de milhares de tokens se acumulam nesse processo, mas todos pertencem ao contexto do subagente. Ao terminar, ele retorna um relatório organizado e desaparece. No contexto principal, restam apenas uma instrução e um relatório: algumas centenas ou poucos milhares de tokens.
É uma estrutura organizacional familiar. Em vez de fazer uma pesquisa de mercado pessoalmente, um gerente delega o trabalho a um pesquisador e recebe um relatório de uma página. O ponto é que as cem fontes consultadas pelo pesquisador não se acumulam na mesa do gerente. A mesa do gerente—ou seja, o contexto principal—mantém apenas as informações necessárias para tomar decisões.
Que tipo de tarefa deve ser delegada?
As tarefas que se beneficiam da delegação têm algo em comum: o processo é pesado, mas a conclusão é leve.
Primeiro, exploração e investigação. Tarefas como “todos os lugares que usam esta função” ou “entender o código relacionado a este bug” exigem muita leitura, mas a resposta final é apenas uma lista ou um resumo. São tarefas típicas para subagentes. O Claude Code mantém agentes dedicados à exploração pelo mesmo motivo.
Segundo, tarefas que podem ser divididas em paralelo. Se cinco módulos precisarem ser analisados, cinco subagentes poderão trabalhar simultaneamente, cada um em seu próprio contexto. Isso reduz o tempo e também evita que os resultados intermediários se misturem em um único contexto e causem confusão.
Terceiro, de natureza um pouco diferente, tarefas que precisam de uma perspectiva nova. Revisão de código é o exemplo mais claro. O contexto do agente principal que acabou de escrever o código está cheio de suposições de implementação e tentativas. Ao revisar o próprio código nesse estado, ele pode ficar preso às próprias suposições e ser indulgente demais. Se você passar apenas o código a um subagente sem contexto, ele o verá pelos olhos de um revisor desconhecido. Aqui, o isolamento não economiza tokens; ele funciona como um mecanismo de qualidade.
Por outro lado, delegar algumas tarefas é desvantajoso. Em trabalhos leves, como ler um ou dois arquivos, o custo da ida e volta da delegação é maior. Tarefas que dependem fortemente do contexto acumulado na conversa também não são adequadas. O motivo vem a seguir.
O custo do isolamento: subagentes não sabem nada
O contexto limpo de um subagente não é gratuito. Estar limpo também significa não saber nada sobre a conversa até então.
As premissas acumuladas durante uma hora na sessão principal—o projeto precisa manter uma API legada, os testes não podem ser alterados e esta é a abordagem preferida pelo usuário—são totalmente desconhecidas pelo subagente. Se não estiverem escritas na instrução, elas não existem. Por isso, a qualidade da delegação converge para a qualidade da instrução. É preciso incluir em uma única instrução o contexto necessário, as restrições e o formato desejado do resultado para evitar receber um relatório baseado em premissas equivocadas.
O caminho de retorno funciona da mesma forma. O agente principal recebe apenas o relatório final do subagente, então qualquer descoberta que não esteja no relatório desaparece quando o subagente vai embora. Por isso, é útil especificar o formato do relatório na instrução, por exemplo: “Inclua as evidências que influenciaram sua avaliação e a lista de arquivos verificados.” O context poisoning discutido na parte 2 também reaparece aqui. Se o relatório do subagente estiver incorreto, o erro é transplantado para o contexto principal de forma compactada, e o agente principal tende a acreditar nele porque não tem o original para verificar. Quanto mais importante a conclusão, mais necessário é recebê-la com suas evidências.
Resumo
- Um subagente trabalha em um contexto separado e limpo e retorna apenas a conclusão. O ponto principal é impedir que dezenas de milhares de tokens do processo entrem no contexto principal.
- Tarefas com processos pesados e conclusões leves—exploração, investigação e análise paralela—são boas candidatas à delegação. Em tarefas como revisão, o isolamento também é útil para a qualidade, pois oferece uma perspectiva nova.
- O custo do isolamento é a ruptura de contexto. Como o subagente não conhece o histórico da conversa, a instrução deve incluir todo o contexto e as restrições relevantes, e o relatório deve exigir as evidências que o sustentam.
Resta uma última peça da série. /clear faz a conversa desaparecer, e o subagente desaparece quando a sessão termina. Mas o projeto continua. Onde deve ficar o conhecimento que precisa sobreviver ao fim de uma sessão? O próximo capítulo aborda o armazenamento fora do contexto—ou seja, memória e externalização.