Você pede ao seu assistente de IA para pesquisar o produto de um concorrente, resumir as descobertas, redigir um documento comparativo e enviá-lo por email para sua equipe. Um único agente consegue fazer cada uma dessas etapas — mas fazê-las bem, em sequência, mantendo contexto entre todas as quatro tarefas, empurra contra os limites do que uma sessão de agente lida com elegância. A janela de contexto enche. O agente perde o fio das etapas anteriores. A qualidade do resultado final degrada porque o modelo está fazendo malabarismo com preocupações demais simultaneamente.
Esse é o problema que enxames de agentes resolvem. Em vez de um agente fazer tudo, um agente coordenador divide a tarefa em subtarefas e delega cada uma para um agente especialista. O agente de pesquisa busca na web e retorna descobertas estruturadas. O agente de escrita pega essas descobertas e redige o documento. O agente de email envia o resultado. Cada agente opera no seu próprio container, com sua própria janela de contexto, focado em uma coisa.
A ideia não é nova — CrewAI e AutoGen vêm explorando padrões multi-agente há mais de um ano. O que é diferente na abordagem do NanoClaw é que cada agente no enxame roda no seu próprio container isolado, o que significa que as garantias de segurança e isolamento que se aplicam a conversas de agente único se estendem automaticamente para fluxos de trabalho multi-agente.
Como Enxames Funcionam no NanoClaw
A arquitetura de enxame do NanoClaw é construída sobre uma primitiva simples: um agente pode criar outros agentes. Quando o Claude Code roda dentro de um container, uma das ferramentas disponíveis é a delegação de agente — a capacidade de descrever uma subtarefa e fazer o NanoClaw criar um novo container para lidar com ela. O agente pai recebe o resultado quando o agente filho completa.
A orquestração acontece naturalmente através do próprio raciocínio do Claude. Você não define um grafo de fluxo de trabalho nem configura papéis de agentes em um arquivo YAML. Você descreve o que quer, e o Claude decide se lida diretamente ou delega partes para sub-agentes. A decisão é baseada no mesmo raciocínio que torna o Claude bom em decompor problemas complexos — ele reconhece quando uma tarefa tem componentes independentes que se beneficiariam de atenção focada.
Na prática, isso se parece com uma árvore de containers. O container raiz recebe sua mensagem, decide que precisa de pesquisa web e escrita de documento, cria dois containers filhos, espera seus resultados e sintetiza uma resposta final. Cada container filho tem seu próprio contexto CLAUDE.md, seu próprio workspace montado e seu próprio conjunto de ferramentas. O agente de pesquisa tem navegação web habilitada; o agente de escrita tem acesso de escrita ao workspace compartilhado. Nenhum consegue acessar o contexto ou ferramentas do outro. ## Por Que o Isolamento por Container Importa para Enxames
A maioria dos frameworks multi-agente roda todos os agentes no mesmo processo. Os agentes do CrewAI compartilham um runtime Python. Os agentes do AutoGen compartilham uma thread de conversa. Isso funciona para demos, mas cria problemas em escala que são difíceis de corrigir depois.
O primeiro problema é o raio de explosão. Se um agente em um enxame encontra uma injeção de prompt — um site malicioso que tenta sequestrar o comportamento do agente — a injeção fica contida naquele único container. Ela não pode afetar o agente pai, não pode acessar os contextos de outros agentes filhos e não pode ler o histórico de conversa do usuário original. O container comprometido é destruído quando completa, e o agente pai recebe qualquer saída que ele produziu (que o pai pode avaliar quanto à qualidade antes de usar).
O segundo problema é contenção de recursos. Agentes em um processo compartilhado competem pela mesma janela de contexto, a mesma memória e a mesma CPU. No NanoClaw, cada container tem seus próprios recursos. Um agente de pesquisa que está navegando páginas web pesadas não desacelera um agente de escrita que está redigindo um documento. Os containers rodam concorrentemente em threads separadas, e o gerenciamento de recursos do host cuida do agendamento.
O terceiro problema é delimitação de credenciais. Um agente de pesquisa precisa de acesso web mas não deveria ter permissões de escrita em arquivo. Um agente de gerenciamento de arquivos precisa de acesso a disco mas não deveria ter acesso web. Em um framework de processo compartilhado, aplicar esses limites exige verificações de permissão no nível da aplicação que podem ser contornadas. No NanoClaw, os limites são montagens de container — o agente de pesquisa literalmente não consegue escrever em disco porque nenhum caminho gravável está montado no seu container.
Padrões Práticos de Enxame
Os padrões que emergem do uso real são mais interessantes que a arquitetura teórica. O mais comum é o padrão pesquisa-e-síntese: um agente pai cria 3-5 agentes de pesquisa para investigar diferentes aspectos de uma questão em paralelo, coleta suas descobertas e produz uma resposta sintetizada que é mais completa do que qualquer agente único poderia produzir em uma passada. O segundo padrão comum é rascunho-e-revisão. Um agente escreve um primeiro rascunho, depois cria um agente revisor com instruções para criticá-lo. O feedback do revisor volta para o agente original (ou um novo agente de redação) para revisão. Isso produz resultados notavelmente melhores que geração em passada única, porque o agente revisor tem uma janela de contexto limpa e pode avaliar o rascunho sem a carga cognitiva de tê-lo escrito.
O terceiro padrão é especialização de ferramentas. Algumas tarefas exigem ferramentas que são caras ou arriscadas — navegação web, execução de comandos shell, modificações no sistema de arquivos. Um agente pai pode delegar essas operações para agentes filhos com acesso específico a ferramentas, mantendo seu próprio contexto limpo e suas próprias permissões mínimas. O pai nunca toca diretamente o sistema de arquivos ou a rede; ele apenas processa os resultados que os agentes filhos retornam.
Os Limites dos Enxames
Enxames não são de graça. Cada agente filho é uma chamada separada à API do Claude, o que significa custos de tokens separados. Um enxame que cria cinco agentes de pesquisa custa aproximadamente cinco vezes mais que um único agente fazendo toda a pesquisa. Para perguntas simples — "como está o tempo?" ou "traduza essa frase" — enxames são puro overhead.
A latência também se acumula. Mesmo com execução paralela, o agente pai tem que esperar o filho mais lento completar antes de poder sintetizar resultados. Um enxame de cinco agentes onde um leva 30 segundos para navegar um site lento significa que o usuário espera 30 segundos mais o tempo de síntese, independentemente de quão rápidos os outros quatro foram.
O NanoClaw lida com isso pragmaticamente. O Claude decide quando usar enxames baseado na complexidade da tarefa — perguntas simples recebem respostas diretas, requisições complexas de múltiplas partes são delegadas. O usuário não configura o comportamento de enxame; ele apenas faz perguntas, e o sistema escala sua abordagem para corresponder à complexidade. O objetivo não é usar enxames em todo lugar — é usá-los onde genuinamente produzem resultados melhores do que um único agente conseguiria.
O futuro multi-agente não é sobre substituir agentes únicos. É sobre dar a agentes únicos a capacidade de pedir ajuda quando precisam, de uma forma que é segura, isolada e transparente. O modelo container-por-agente do NanoClaw torna isso possível sem os compromissos de segurança que vêm de rodar múltiplos agentes em um ambiente compartilhado.