Principais destaques
- 01. O problema não é apenas o modelo, mas a arquitetura. Um agente que executa tudo em sequência pode desperdiçar tempo e contexto. Quando tarefas são independentes, elas podem ser distribuídas entre diferentes subagentes.
- 02. Grafos tornam explícitas as relações entre tarefas. Nós representam unidades de trabalho e arestas representam dados ou dependências. Isso permite identificar onde paralelizar, onde esperar e onde verificar.
- 03. Claude Code já caminha nessa direção. A Anthropic vem ampliando o uso de subagentes, equipes de agentes e workflows dinâmicos, incluindo arquiteturas capazes de decompor problemas, executar trabalho em paralelo e verificar resultados antes da resposta final.
Imagine que você peça a uma IA para analisar um projeto de software com 100 arquivos.
Uma abordagem tradicional poderia ser:
arquivo 1 → arquivo 2 → arquivo 3 → arquivo 4 → … → arquivo 100
Funciona. Mas existe uma pergunta incômoda:
por que o arquivo 73 precisa esperar o arquivo 72 terminar se eles não têm nenhuma relação entre si?
Essa pergunta aparentemente simples está no centro da chamada engenharia de grafos para agentes.
A ideia é deixar de pensar em um agente como uma única entidade que recebe uma instrução e executa uma longa sequência de ações. Em seu lugar, podemos imaginar uma rede de tarefas especializadas, cada uma com seu próprio contexto, seus próprios objetivos e, quando necessário, sua própria perspectiva sobre o problema.
O conceito se torna especialmente importante à medida que os agentes começam a assumir tarefas maiores. A própria Anthropic descreve uma evolução de agentes individuais para arquiteturas em que múltiplos agentes trabalham em paralelo, cada um com contexto próprio, enquanto um agente coordenador organiza o trabalho e consolida os resultados.
E isso muda uma coisa fundamental:
A pergunta deixa de ser “como faço um agente pensar mais?” e passa a ser “como organizo o trabalho para que vários agentes pensem nas partes certas?”
É aí que entra o grafo.
1. Antes de construir um workflow, aprenda a enxergar o grafo
Um grafo de agentes pode parecer complicado quando apresentado pela primeira vez. Na prática, seus dois elementos fundamentais são simples.
Nó = trabalho
Um nó representa uma unidade de trabalho.
Pode ser:
- analisar um arquivo;
- pesquisar uma fonte;
- classificar um problema;
- revisar uma alteração;
- verificar uma hipótese;
- resumir um conjunto de dados;
- escrever uma parte de um relatório.
Aresta = informação ou dependência
A aresta representa aquilo que passa de uma etapa para outra.
Se o agente A produz uma lista que o agente B precisa analisar, existe uma relação.
Se A e B trabalham independentemente, não existe motivo para criar uma dependência entre eles.
Esse detalhe é mais importante do que parece.
Muitos workflows ficam lentos porque o desenvolvedor transforma a ordem em que escreveu as instruções em uma ordem obrigatória de execução.
Mas:
“faça A e depois B”
não significa necessariamente:
“B depende do resultado de A”.
Teste rápido
Sempre que você encontrar um “depois”, faça esta pergunta:
A próxima etapa realmente precisa ler o resultado da etapa anterior?
Se a resposta for não, você provavelmente encontrou uma oportunidade de paralelização.
Exemplo simples
Imagine uma IA que recebeu esta missão:
“Leia o README, analise as dependências do projeto, procure vulnerabilidades conhecidas e verifique a documentação da API.”
Um agente linear poderia executar:
README → dependências → vulnerabilidades → documentação
Mas as quatro tarefas podem ser independentes.
Uma arquitetura melhor seria:
┌──> Analisar README ───────┐
│ │
├──> Auditar dependências ──┤
Tarefa inicial ───┤ ├──> Síntese final
├──> Pesquisar vulnerabilidades
│ │
└──> Verificar documentação ┘
O desenho é simples.
O ganho potencial é enorme.
A Anthropic relata que seu próprio sistema de pesquisa multiagente utiliza um agente principal para planejar a investigação e delegar diferentes linhas de pesquisa a subagentes que trabalham simultaneamente. Em avaliações internas descritas pela empresa, essa abordagem superou significativamente uma configuração de agente único em consultas que exigiam grande amplitude de investigação.
Isso não significa que “mais agentes” sempre seja melhor.
Significa que a estrutura do problema deve determinar a estrutura do sistema.
2. O primeiro exercício: transforme uma tarefa linear em um grafo
Antes de abrir o Claude Code, existe um exercício que vale mais do que simplesmente começar a escrever código.
Pegue uma tarefa que você normalmente entregaria a um agente.
Por exemplo:
“Analise este repositório, encontre problemas de segurança, identifique código duplicado, avalie testes e produza um relatório.”
Agora decomponha:
REPOSITÓRIO
│
├──── Segurança
│
├──── Código duplicado
│
├──── Cobertura e qualidade dos testes
│
└──── Arquitetura
│
▼
CONSOLIDAÇÃO
│
▼
RELATÓRIO FINAL
Você acabou de criar um diamante.
O fluxo se abre, várias tarefas acontecem simultaneamente e depois os resultados convergem.
Esse formato é tão útil porque aparece em praticamente todo tipo de trabalho complexo.
Pesquisa:
Pergunta
↓
┌─────────┬─────────┬─────────┬─────────┐
Fonte A Fonte B Fonte C Fonte D
└─────────┴─────────┴─────────┴─────────┘
↓
Dedupe
↓
Verificação
↓
Síntese
Auditoria de código:
Código
↓
┌───────┬───────┬────────┬──────────┐
Auth API Testes Performance
└───────┴───────┴────────┴──────────┘
↓
Revisão cruzada
↓
Relatório
Pesquisa de mercado:
Mercado
↓
┌────────┬──────────┬────────┬──────────┐
Preços Concorrentes Tendências Clientes
└────────┴──────────┴────────┴──────────┘
↓
Ranking
↓
Recomendação
O mesmo padrão aparece repetidamente.
Dividir → trabalhar → reunir.
Prompt para copiar e colar
Use este prompt no Claude antes de pedir que ele construa qualquer workflow complexo:
Quero transformar a tarefa abaixo em uma arquitetura de agentes.
TAREFA:[cole aqui a tarefa]
Antes de implementar qualquer coisa: 1. Decomponha a tarefa em unidades de trabalho independentes. 2. Identifique quais etapas realmente dependem do resultado de outras. 3. Marque quais etapas podem ser executadas em paralelo. 4. Identifique onde uma barreira é realmente necessária. 5. Identifique quais operações podem ser feitas por código determinístico, sem usar um agente. 6. Identifique onde seria útil uma etapa de verificação. 7. Identifique possíveis pontos de falha e como isolá-los. 8. Desenhe o grafo textual da execução. 9. Explique por que cada aresta existe. 10. Só depois proponha a implementação. Não escreva o código ainda. Quero primeiro entender a topologia do workflow.
Esse tipo de prompt força o modelo a pensar primeiro na arquitetura.
E existe uma razão para isso ser importante: a própria Anthropic recomenda, em seus materiais sobre sistemas multiagente, definir claramente objetivo, formato de saída, ferramentas e limites de cada subagente. Sem essa divisão, agentes diferentes podem acabar fazendo exatamente o mesmo trabalho, deixando lacunas ou gastando recursos em pesquisas redundantes.
3. O segredo está nos contratos, não apenas nos agentes
Um erro comum ao construir sistemas multiagente é imaginar que basta criar vários agentes e mandar todos “analisarem o problema”.
Não basta.
Se os agentes não tiverem responsabilidades bem definidas, o sistema pode ficar mais caro, mais lento e até menos confiável.
Pense em cada nó como uma função.
Uma função bem projetada recebe uma entrada conhecida e devolve uma saída conhecida.
Um agente também deveria funcionar assim.
Contrato ruim
“Analise este arquivo e me diga o que você acha.”
O resultado pode ser qualquer coisa.
Contrato melhor
“Analise este arquivo exclusivamente em busca de problemas de autenticação. Retorne uma lista estruturada contendo arquivo, linha, descrição, evidência e nível de confiança.”
Agora existe um contrato.
Isso é especialmente importante quando a saída de um agente será consumida por outro agente.
Um contrato útil para agentes
Entrada
↓
[ contexto explícito ]
[ objetivo único ]
[ restrições ]
↓
AGENTE
↓
[ saída estruturada ]
↓
Próximo nó
Quanto mais previsível for a saída, mais fácil fica construir o restante do grafo.
No Claude Code, esse princípio também aparece no uso de subagentes especializados e na necessidade de separar responsabilidades em tarefas complexas. A Anthropic destaca que subagentes podem ser utilizados para dividir trabalhos específicos e reduzir a sobrecarga de contexto de uma única sessão.
Exemplo
Imagine um agente de pesquisa que precisa retornar:
{
"title": "string",
"url": "string",
"impact": "high | medium | low",
"evidence": "string"
}
O próximo agente não precisa interpretar um texto gigantesco.
Ele recebe uma estrutura previsível.
Isso torna a aresta mais confiável.
Prompt para criar contratos
Pegue a tarefa abaixo e transforme cada etapa em um nó de um workflow multiagente.
Para cada nó, defina:
- nome
- objetivo único
- entrada
- saída
- formato da saída
- critérios de sucesso
- o que o agente NÃO deve fazer
- dependências
- possibilidade de execução em paralelo
- modelo recomendado, caso faça sentido
Evite nós genéricos como "analisar tudo".
Cada nó deve ter uma responsabilidade pequena o suficiente para ser testada isoladamente.
TAREFA:[cole aqui]
Esse prompt é particularmente útil quando o workflow começa a crescer.
Porque existe uma regra prática:
Se você não consegue explicar exatamente o que um nó recebe e devolve, provavelmente ainda não sabe onde esse nó deveria estar no grafo.
4. Fan-out: quando a IA abre o trabalho
Agora chegamos ao mecanismo mais importante para ganhar escala.
Fan-out significa distribuir uma tarefa entre vários caminhos.
Imagine 50 arquivos para revisar.
Em vez de:
Arquivo 1 → Arquivo 2 → Arquivo 3 → ... → Arquivo 50
você pode ter:
┌→ Agente 1
├→ Agente 2
├→ Agente 3
Projeto ─────────┼→ Agente 4
├→ ...
└→ Agente 50
Cada agente possui seu próprio contexto.
Isso é importante porque um único contexto não precisa carregar simultaneamente todos os arquivos, todas as descobertas e todas as linhas de raciocínio.
A Anthropic descreve justamente esse benefício em seu sistema de pesquisa multiagente: subagentes trabalham em contextos separados e funcionam como filtros que comprimem grandes volumes de informação antes de entregar os resultados ao agente principal.
Em termos simples:
o agente principal não precisa saber tudo.
Ele precisa receber o que os outros agentes descobriram.
E aqui aparece uma distinção fundamental
Paralelismo não significa ausência de coordenação.
Você ainda precisa decidir:
- quem faz o quê;
- quais tarefas são independentes;
- quais resultados serão aceitos;
- quando reunir as respostas;
- como lidar com falhas;
- como evitar trabalho duplicado;
- quando interromper a execução.
É por isso que “jogar 100 agentes no problema” não é engenharia de agentes.
É apenas jogar 100 agentes no problema.
Uma arquitetura boa determina por que cada agente existe.
5. Fan-in: quando todos os caminhos precisam voltar
Se fan-out é abrir o trabalho, fan-in é reunir os resultados.
Por exemplo:
┌→ Pesquisa A ─┐
├→ Pesquisa B ─┤
Pergunta ─────┼→ Pesquisa C ─┼→ Consolidação
├→ Pesquisa D ─┤
└→ Pesquisa E ─┘
A consolidação é o ponto em que uma etapa finalmente precisa enxergar o conjunto.
Mas aqui existe uma armadilha.
Nem toda reunião precisa de um agente.
Se você precisa apenas:
- juntar listas;
- remover duplicidades;
- ordenar;
- filtrar;
- contar;
- validar campos;
use código.
Não use inteligência artificial para fazer aquilo que uma operação determinística resolve instantaneamente.
Pense assim
AGENTE
= julgamento
CÓDIGO
= encanamento
Se a tarefa é:
“Pegue cinco listas e elimine itens repetidos.”
Não precisa de um agente.
Se a tarefa é:
“Analise os resultados, determine quais descobertas são realmente relevantes e explique conflitos entre as fontes.”
Aí sim existe trabalho de julgamento.
Essa separação reduz custo e também torna o sistema mais previsível.
6. Barreira não é sinônimo de etapa
Uma barreira significa que o workflow precisa esperar.
Isso parece inocente, mas pode destruir parte do ganho obtido com paralelismo.
Imagine cinco agentes:
A = 10 segundos
B = 12 segundos
C = 15 segundos
D = 80 segundos
E = 11 segundos
Se todos forem executados em paralelo e depois existir uma barreira, o próximo estágio precisa esperar aproximadamente pelo agente mais lento.
Ou seja:
80 segundos.
Os outros quatro agentes já terminaram.
Essa é uma das razões pelas quais a topologia precisa ser pensada com cuidado.
Se uma etapa pode processar cada item individualmente, talvez seja melhor usar um pipeline.
Barreira
A ─┐
B ─┤
C ─┼──> próxima etapa
D ─┤
E ─┘
Todos precisam terminar.
Pipeline
Item A → estágio 1 → estágio 2 → estágio 3
Item B → estágio 1 → estágio 2 → estágio 3
Item C → estágio 1 → estágio 2 → estágio 3
O item A pode estar no estágio 3 enquanto o item C ainda está no estágio 1.
Essa diferença pode ser decisiva em workflows grandes.
Regra prática
Use uma barreira quando a próxima etapa realmente precisa conhecer o conjunto completo.
Exemplos:
Precisa de barreira:
“Compare todas as descobertas e elimine duplicidades entre elas.”
Provavelmente não precisa:
“Para cada descoberta, verifique se ela é válida.”
No segundo caso, cada descoberta pode ser verificada independentemente.
7. O diamante é a arquitetura que você mais vai reutilizar
Se você memorizar apenas um desenho deste artigo, memorize este:
┌→ Nó A ─┐
├→ Nó B ─┤
Entrada → divisão ──┼→ Nó C ─┼→ redução → síntese
├→ Nó D ─┤
└→ Nó E ─┘
Esse é o diamante.
Ele aparece em:
- pesquisa;
- auditoria;
- análise competitiva;
- revisão de código;
- segurança;
- classificação;
- geração de relatórios;
- análise de documentos;
- migrações;
- testes.
A fórmula pode ser resumida como:
fan-out → reduce → synthesize
Primeiro você ganha amplitude.
Depois comprime os resultados.
Por fim, usa um agente para julgamento e síntese.
Essa arquitetura também ajuda a controlar contexto. Em vez de colocar todas as informações no mesmo prompt, cada subagente trabalha em uma parte e devolve apenas aquilo que importa.
8. Agora coloque um roteador no meio
Nem todos os problemas devem seguir o mesmo caminho.
Imagine uma alteração de código.
Uma mudança de uma linha pode precisar apenas de uma revisão rápida.
Uma alteração que mexe em autenticação, banco de dados e pagamentos pode exigir uma auditoria completa.
Então temos:
┌→ revisão rápida
Entrada → classificador
└→ auditoria completa
Esse é um router.
O modelo pode fazer a classificação:
baixo risco ou alto risco?
Mas a decisão operacional pode ficar no código:
se baixo:
revisão simples
se alto:
auditoria paralela
↓
verificadores
↓
síntese
Essa combinação é poderosa porque separa duas coisas.
A IA decide.
O código controla o fluxo.
Isso reduz a possibilidade de o modelo simplesmente “inventar” uma etapa, pular outra ou modificar a estratégia de execução sem que isso esteja previsto na arquitetura.
Prompt para criar um roteador
Quero adicionar roteamento condicional a este workflow.
TAREFA:[cole aqui]
Crie uma etapa inicial de classificação que retorne uma saída estruturada. A classificação deve determinar qual caminho executar. Defina: 1. categorias possíveis; 2. critérios objetivos para cada categoria; 3. formato estruturado da classificação; 4. workflow correspondente a cada categoria; 5. quais caminhos podem rodar em paralelo; 6. quais caminhos exigem verificação; 7. como lidar com classificações ambíguas. Importante: A IA deve classificar. A lógica de roteamento deve permanecer determinística no código. Não permita que o agente altere o workflow dinamicamente sem uma regra explícita.
9. O verificador é onde a arquitetura começa a ficar realmente interessante
Um dos problemas dos agentes é que eles podem produzir respostas convincentes e erradas.
Se um agente encontra uma vulnerabilidade, por exemplo, você pode simplesmente acreditar nele.
Ou pode perguntar:
“Você consegue provar que isso está errado?”
Essa segunda abordagem cria um verificador.
Agente pesquisador
↓
descoberta
↓
┌──────┼──────┐
↓ ↓ ↓
Juiz A Juiz B Juiz C
└──────┼──────┘
↓
decisão
↓
resultado final
Os verificadores podem receber perspectivas diferentes.
Um procura erros factuais.
Outro procura problemas de segurança.
Outro tenta reproduzir a descoberta.
Outro pode procurar evidências contrárias.
Isso é melhor do que simplesmente perguntar três vezes a mesma coisa.
Diversidade de perspectiva importa.
A própria experiência da Anthropic na construção de sistemas multiagente destaca que coordenação, avaliação e confiabilidade se tornam desafios próprios quando vários agentes trabalham juntos. O sistema de pesquisa da empresa usa uma etapa de citação e verificação para garantir que as afirmações finais estejam apoiadas pelos materiais encontrados.
Prompt de verificação adversarial
Você é um verificador adversarial.
Recebeu uma descoberta feita por outro agente.
Sua função NÃO é confirmar a descoberta.
Sua função é tentar provar que ela está errada.
Analise:
1. se a evidência realmente sustenta a conclusão;
2. se existe uma explicação alternativa;
3. se o contexto foi interpretado incorretamente;
4. se a descoberta pode ser reproduzida;
5. se existe informação que contradiz a conclusão;
6. se a gravidade atribuída é proporcional às evidências.
Retorne:
- verdict: CONFIRMAR, REJEITAR ou INCONCLUSIVO
- confidence: 0 a 100
- strongest_evidence
- strongest_counterargument
- reproduction_steps
- explanation
Se não houver evidência suficiente, prefira INCONCLUSIVO a inventar uma confirmação.
Esse prompt é útil porque muda a função psicológica do agente.
Ele não está mais tentando agradar o primeiro agente.
Está tentando derrubá-lo.
10. E se um agente falhar?
Essa pergunta deveria fazer parte do desenho antes da execução.
Em uma cadeia linear:
A → B → C → D
se B falha, C e D podem nunca acontecer.
Em um grafo:
┌→ A ✓
Entrada┼→ B ✗
├→ C ✓
└→ D ✓
o sistema pode continuar.
Esse isolamento é uma das vantagens mais interessantes da arquitetura.
Mas existe uma diferença entre falha isolada e resultado silenciosamente ruim.
Se um agente não responde, o sistema pode marcar o resultado como ausente.
Se um agente responde algo incorreto, o problema pode contaminar todo o restante do grafo.
Por isso, em workflows importantes, vale combinar:
isolamento + validação + verificação.
A Anthropic também chama atenção para o fato de que sistemas com agentes autônomos criam novos riscos de governança, justamente porque os agentes podem executar ações com menos supervisão humana. Plan Mode, por exemplo, foi desenvolvido para permitir que o usuário revise uma estratégia antes de uma sequência longa de ações.
11. Arquivos são um caso especial
Paralelizar leitura é relativamente simples.
Paralelizar escrita é outra história.
Imagine três agentes modificando o mesmo arquivo:
Agente A ─┐
Agente B ─┼→ mesmo arquivo
Agente C ─┘
Agora temos conflito.
Cada agente pode sobrescrever o trabalho do outro.
A solução é isolamento.
Em projetos de código, isso pode envolver cópias separadas do repositório, containers ou worktrees do Git.
A Anthropic descreveu uma arquitetura desse tipo ao construir um compilador C com múltiplas instâncias de Claude Code. Os agentes trabalhavam em ambientes separados e havia mecanismos de sincronização para impedir que dois agentes assumissem a mesma tarefa simultaneamente.
A regra prática é:
Paralelize leitura com facilidade. Paralelize escrita apenas quando você tiver uma estratégia clara de isolamento e integração.
12. Ciclos: quando o problema não tem tamanho conhecido
Até aqui falamos de grafos que começam, dividem o trabalho e terminam.
Mas existem problemas que não sabemos dimensionar.
Um exemplo:
“Encontre todos os problemas relevantes de segurança neste projeto.”
Talvez a primeira investigação encontre 10 problemas.
Esses problemas podem revelar novas áreas para investigar.
Então surge um ciclo:
buscar
↓
novas descobertas?
↓
sim ─────→ buscar novamente
│
não
↓
terminar
O perigo é óbvio.
Sem uma condição de parada, você criou uma máquina que pode continuar gerando tarefas indefinidamente.
Um padrão útil é parar depois de algumas rodadas sem descobertas novas.
Mas existe um detalhe essencial:
dedupe contra tudo que já foi visto.
Não apenas contra aquilo que foi confirmado.
Caso contrário, uma descoberta rejeitada pode reaparecer em todas as rodadas seguintes.
Prompt para um ciclo seguro
Projete um workflow iterativo para a tarefa abaixo:
[TAREFA]
O workflow deve:
1. executar descobertas em paralelo;
2. registrar tudo que já foi encontrado;
3. remover duplicidades antes de iniciar uma nova rodada;
4. verificar as novas descobertas;
5. adicionar apenas resultados realmente novos;
6. interromper após 2 rodadas consecutivas sem descobertas novas;
7. possuir um limite máximo de rodadas;
8. registrar o motivo da interrupção;
9. nunca repetir indefinidamente uma descoberta rejeitada.
Antes de escrever o código, mostre o grafo e explique a condição de convergência.
Esse tipo de proteção é especialmente importante quando a IA tem autorização para criar novas tarefas a partir de suas próprias descobertas.
13. Nem todo nó merece o mesmo modelo
Existe outro benefício de pensar em grafos: você consegue enxergar onde está gastando inteligência cara.
Considere um workflow com 50 nós.
Talvez 35 sejam tarefas simples:
- extrair dados;
- classificar;
- detectar padrões;
- formatar;
- validar campos;
- resumir.
E talvez apenas três exijam julgamento realmente sofisticado:
- definir a estratégia;
- resolver conflitos;
- produzir a conclusão final.
Usar o modelo mais poderoso em todos os 50 nós pode ser desnecessário.
A arquitetura permite criar uma espécie de hierarquia:
MODELO MAIS CAPAZ
planejamento
↓
┌────────┴────────┐
↓ ↓
síntese final verificação
↑ ↑
└────────┬────────┘
↑
MODELOS MAIS BARATOS
tarefas repetitivas
A própria Anthropic recomenda, em apresentações sobre Claude Code, escolher o modelo de acordo com o tipo de trabalho, citando, por exemplo, modelos mais capazes para planejamento e outros para execução cotidiana.
A ideia não é simplesmente economizar.
É colocar capacidade de raciocínio onde ela produz mais valor.
14. Claude Code está caminhando para esse modelo de trabalho
O conceito deixou de ser apenas uma técnica teórica de engenharia.
A Anthropic vem incorporando mecanismos de orquestração ao Claude Code.
Em 2026, a empresa apresentou Agent Teams, em pesquisa, permitindo que múltiplas sessões de Claude Code trabalhem em paralelo, dividindo tarefas e coordenando esforços. A recomendação da própria Anthropic é especialmente voltada a problemas que podem ser separados em frentes independentes.
Mais recentemente, a empresa apresentou Dynamic Workflows, também em research preview, permitindo que Claude planeje uma tarefa e execute centenas de subagentes em paralelo em uma única sessão, além de verificar os resultados antes de retornar ao usuário.
Isso representa uma mudança importante.
Até pouco tempo, o usuário precisava pensar:
“Qual prompt devo escrever?”
Agora, para tarefas mais complexas, começa a fazer sentido pensar:
“Qual arquitetura de execução eu quero que a IA construa?”
Essa é uma mudança de nível.
15. O workflow pode ser escrito pelo próprio Claude
Aqui está uma das partes mais interessantes para quem quer aprender.
Você não necessariamente precisa escrever toda a orquestração manualmente.
Pode pedir ao Claude para analisar a tarefa, criar uma estratégia e construir o workflow.
A ideia é algo próximo de:
Você
↓
Objetivo
↓
Claude planeja
↓
Claude decompõe
↓
Claude cria nós
↓
Claude identifica dependências
↓
Claude paraleliza
↓
Agentes executam
↓
Verificadores avaliam
↓
Claude sintetiza
↓
Resultado
Isso não elimina a necessidade de engenharia.
Pelo contrário.
Quanto mais autonomia você entrega ao sistema, mais importante se torna saber avaliar a arquitetura que ele produziu.
Um workflow ruim pode:
- criar agentes demais;
- repetir pesquisas;
- gastar tokens desnecessariamente;
- gerar dependências artificiais;
- criar barreiras onde não são necessárias;
- não verificar resultados;
- entrar em ciclos;
- produzir conflitos de escrita;
- perder rastreabilidade.
Por isso, aprender grafos é uma maneira de aprender a auditar o trabalho da própria IA.
16. Prompt mestre: peça para Claude projetar seu próprio grafo
Este é o prompt mais importante do tutorial.
Você pode copiar e adaptar:
Quero que você projete um workflow multiagente para executar a tarefa abaixo.
TAREFA:
[DESCREVA O OBJETIVO]
REGRAS DE ARQUITETURA:
1. Pense no problema como um grafo de execução.
2. Identifique todos os nós necessários.
3. Para cada nó, defina uma única responsabilidade.
4. Defina claramente entrada e saída.
5. Não crie uma dependência apenas porque uma etapa aparece antes da outra no texto.
6. Se duas tarefas forem independentes, proponha execução em paralelo.
7. Use código determinístico para transformações simples, como filtros, deduplicação, ordenação e agregação.
8. Use agentes para tarefas que exigem julgamento, interpretação ou síntese.
9. Adicione verificadores quando uma conclusão errada puder comprometer o resultado.
10. Use perspectivas diferentes nos verificadores quando possível.
11. Evite barreiras. Crie uma barreira apenas quando a próxima etapa realmente precisar de todos os resultados.
12. Considere pipeline quando cada item puder seguir independentemente.
13. Se houver roteamento condicional, faça a classificação com IA e mantenha o controle do fluxo determinístico no código.
14. Se o problema tiver tamanho desconhecido, proponha um ciclo com condição explícita de convergência.
15. Imponha limites para evitar loops infinitos.
16. Planeje isolamento para tarefas que escrevem arquivos em paralelo.
17. Use modelos mais econômicos em tarefas repetitivas e modelos mais capazes em planejamento, julgamento e síntese quando apropriado.
18. Defina como falhas individuais serão isoladas.
19. Defina como resultados incompletos serão tratados.
20. Antes de implementar, mostre o grafo em ASCII.
Depois apresente:
A. Arquitetura geral
B. Lista de nós
C. Dependências
D. Pontos de paralelismo
E. Barreiras necessárias
F. Estratégia de verificação
G. Estratégia de falhas
H. Estratégia de custos
I. Condições de parada
J. Implementação sugerida
Não escreva código antes de terminar a análise arquitetural.
17. Um exercício prático para fazer agora
Se você quer realmente aprender o conceito, não comece por um projeto gigantesco.
Pegue uma tarefa simples.
Por exemplo:
“Analise os últimos 20 artigos sobre inteligência artificial e produza um briefing com as cinco tendências mais importantes.”
Agora construa mentalmente o grafo.
Etapa 1: descoberta
Pergunta
↓
┌────┬────┬────┬────┬────┐
A B C D E
Cada agente procura informações em uma frente diferente.
Etapa 2: redução
O código elimina URLs repetidas e normaliza os resultados.
Etapa 3: verificação
Cada tendência importante recebe dois ou três verificadores.
Etapa 4: síntese
Um agente final recebe apenas os resultados relevantes e escreve o briefing.
O resultado:
┌→ Pesquisa A ─┐
├→ Pesquisa B ─┤
Pergunta ─────┼→ Pesquisa C ─┼→ Deduplicação
├→ Pesquisa D ─┤ ↓
└→ Pesquisa E ─┘ Verificação
↓
Síntese
Agora compare isso com:
Pergunta → pesquisar → pesquisar → pesquisar → pesquisar → pesquisar → escrever
Os dois podem produzir uma resposta.
Mas eles não têm a mesma arquitetura.
18. O erro mais comum: confundir quantidade com inteligência
Existe uma tentação inevitável quando você aprende sobre sistemas multiagente:
“Se cinco agentes são bons, cinquenta devem ser melhores.”
Não necessariamente.
Um sistema multiagente pode piorar quando adicionamos agentes demais.
A Anthropic relata que, durante a construção de seu sistema de pesquisa, encontrou problemas como subagentes realizando pesquisas redundantes, continuando uma investigação mesmo depois de já haver informação suficiente e usando estratégias de busca pouco eficientes. O trabalho de engenharia precisou incluir limites e orientações específicas para controlar esses comportamentos.
Isso leva a uma regra importante:
O objetivo não é maximizar o número de agentes. É maximizar a quantidade de trabalho útil por agente.
Um único agente bem escolhido pode ser melhor que dez agentes mal coordenados.
Da mesma maneira, dez agentes especializados podem ser muito melhores que um único agente tentando carregar tudo no mesmo contexto.
19. O verdadeiro ganho está no contexto
Talvez essa seja a ideia mais importante de toda a arquitetura.
Imagine um agente tentando analisar:
- 500 arquivos;
- 300 documentos;
- 200 páginas;
- 50 hipóteses;
- 100 resultados de pesquisa.
Mesmo modelos com contextos enormes precisam lidar com a organização desse material.
Ao distribuir o trabalho:
CONTEXTO PRINCIPAL
↓
┌───────────────┼───────────────┐
↓ ↓ ↓
Contexto A Contexto B Contexto C
↓ ↓ ↓
resultado A resultado B resultado C
└───────────────┼───────────────┘
↓
contexto final
cada agente pode concentrar sua atenção em uma parte.
O agente final não precisa carregar toda a exploração.
Recebe os resultados comprimidos.
Esse princípio está presente na arquitetura de pesquisa multiagente da Anthropic, que usa subagentes para explorar diferentes direções e depois comprimir as descobertas para o agente responsável pela síntese.
Por isso, sistemas multiagente não são apenas uma maneira de fazer mais tarefas simultaneamente.
Eles também são uma estratégia de gerenciamento de contexto.
20. Checklist mental do arquiteto de agentes
Antes de transformar qualquer tarefa em um workflow, faça estas perguntas:
DEPENDÊNCIAS
Esta etapa realmente precisa do resultado da anterior?
PARALELISMO
Quais partes poderiam acontecer simultaneamente?
CONTRATOS
Sei exatamente o que cada nó recebe e devolve?
DETERMINISMO
Estou usando um agente para uma tarefa que poderia ser resolvida por código?
BARREIRAS
Preciso realmente esperar todos os resultados?
VERIFICAÇÃO
Qual erro seria caro demais para simplesmente aceitar?
FALHAS
O que acontece se um agente não responder?
ISOLAMENTO
Dois agentes podem tentar modificar a mesma coisa?
CUSTO
Todos os nós precisam do modelo mais poderoso?
CONVERGÊNCIA
Se houver um loop, qual é a condição de parada?
OBSERVABILIDADE
Consigo saber qual agente produziu cada descoberta?
SÍNTESE
O agente final está recebendo informação útil ou uma montanha de texto?
Se você consegue responder essas perguntas, já está pensando como um arquiteto de agentes.
21. O próximo nível: deixe a IA construir, mas faça você a auditoria
A evolução natural desse conceito é interessante.
Primeiro, você escreve prompts.
Depois, começa a escrever workflows.
Depois, começa a pedir para a IA escrever workflows.
Mas existe uma última mudança:
você passa a avaliar a topologia que a IA criou.
Esse talvez seja um dos conhecimentos mais valiosos para quem trabalha com IA atualmente.
Porque um agente pode escrever um código aparentemente impressionante e ainda assim construir uma arquitetura ruim.
Pode criar:
A → B → C → D → E → F
quando o problema pedia:
┌→ B ─┐
A ─────┼→ C ─┼→ F
└→ D ─┘
Ou pode criar:
A → 20 agentes → B → 20 agentes → C
quando três agentes bem especializados seriam suficientes.
A habilidade de enxergar essas diferenças é o que transforma alguém que simplesmente usa agentes em alguém capaz de projetar sistemas de agentes.
22. Para guardar: o mapa mental
ARQUITETURA DE AGENTES
│
┌───────────────────┼───────────────────┐
↓ ↓ ↓
NÓS ARESTAS CONTEXTO
│ │ │
unidades de dependências separado
trabalho reais por agente
│ │ │
└──────────────┬────┴──────────────┬────┘
↓ ↓
PARALELISMO VERIFICAÇÃO
│ │
fan-out skeptics
│ │
└────────┬──────────┘
↓
FAN-IN
↓
SÍNTESE
O mais importante é não decorar nomes como fan-out, fan-in, router ou barrier apenas por decorar.
Entenda o princípio.
Fan-out significa abrir o trabalho.
Fan-in significa reunir o trabalho.
Router significa escolher o caminho.
Barrier significa esperar.
Pipeline significa deixar cada item avançar independentemente.
Verifier significa tentar derrubar uma conclusão.
Cycle significa voltar para buscar mais informação.
Contract significa definir exatamente o que passa entre os nós.
Quando essas peças começam a fazer sentido, você consegue olhar para praticamente qualquer tarefa complexa e perguntar:
Qual é o grafo escondido aqui?
Essa é a pergunta que muda tudo.
O que estudar depois deste artigo
Se você quer avançar no assunto, o próximo passo é estudar subagentes, Agent Teams, MCP, hooks, Plan Mode e avaliação de workflows.
A Anthropic mantém materiais oficiais sobre Claude Code, incluindo conteúdos sobre subagentes, skills e integração com ferramentas.
Também vale estudar como a própria Anthropic construiu seu sistema de pesquisa multiagente. O texto técnico mostra decisões de arquitetura, divisão de tarefas, paralelização, verificação, gerenciamento de contexto e os problemas encontrados durante a implementação.
E há uma razão para esse conhecimento estar se tornando cada vez mais relevante. A análise publicada pela Anthropic sobre centenas de milhares de sessões de Claude Code mostra que o uso está avançando de tarefas pontuais para atividades mais completas, incluindo planejamento, operação de software, análise e orquestração de agentes.
O futuro dos agentes provavelmente não será definido apenas por quem tem o melhor modelo.
Será também definido por quem sabe organizar modelos diferentes, contextos diferentes e tarefas diferentes em uma arquitetura que faça sentido.
Um prompt pede.
Um agente executa.
Um workflow coordena.
E um arquiteto de agentes decide como o trabalho deve fluir.
