Agentes como Colegas de Equipe: Hierarquia, Papéis e o que 2025 Nos Ensinou

O Ano em que Multiagentes Ficaram Reais

Durante a maior parte de 2024, a conversa sobre multiagentes foi pura sensação. As pessoas postavam demos de "enxames de agentes" planejando casamentos ou tocando empresas fictícias, e quase nada disso sobrevivia ao contato com a produção. A promessa era enorme. A evidência, escassa.

Isso mudou em abril de 2025, quando a Anthropic publicou o relato de engenharia do seu sistema multiagente de pesquisa. A arquitetura era simples no formato: um agente Claude Opus 4 líder atua como orquestrador, divide uma pergunta de pesquisa em subtarefas, dispara subagentes para investigar em paralelo e depois monta as saídas. Na avaliação interna de navegação da Anthropic, essa configuração superou o baseline de Opus 4 de agente único em 90,2 por cento. (Anthropic engineering, "How we built our multi-agent research system")

Esse é o destaque. As letras miúdas importam mais. O mesmo relato observa que sistemas multiagentes usam cerca de 15 vezes mais tokens que um chat normal. O consumo de tokens explicou cerca de 80 por cento da variância de desempenho no framework de avaliação deles. Você não está conseguindo esses 90,2 por cento de graça; você está comprando.

Então agora a pergunta para qualquer fundador, CTO ou engenheiro sênior que esteja projetando uma funcionalidade de IA não é mais "multiagente é um padrão real?". É "multiagente é o padrão certo para esta tarefa, e a que custo?". 2025 e a primeira metade de 2026 produziram dados suficientes para responder a isso com mais do que intuição. Os padrões que venceram, os que perderam e os modos de falha que se repetem parecem muito com design organizacional clássico. Esse é o fio condutor deste texto.

---

A Taxonomia de Modos de Falha: O que Cemri et al. Documentaram

Em março de 2025, Mert Cemri e colaboradores em Berkeley publicaram "Why Do Multi-Agent LLM Systems Fail?" (arXiv 2503.13657). O artigo analisou cinco frameworks multiagentes populares em mais de 150 traços conversacionais e produziu algo de que a área precisava muito: uma taxonomia.

Quatorze modos de falha distintos, agrupados em três famílias.

Falhas de especificação e design de sistema. Agentes desobedecem à especificação de seu papel. Desobedecem à especificação da tarefa. Perdem o histórico da conversa. Etapas são repetidas. Condições de término nunca disparam. O sistema "sabe" a tarefa, mas o agente individual diante de você não se comporta como se soubesse.

Desalinhamento entre agentes. Agentes redefinem o progresso e começam do zero. Retêm informações uns dos outros. Saem do assunto em trocas fora do tópico. Fazem suposições sobre o que outro agente já fez e agem com base nessas suposições sem checar. É a clássica falha do "achei que você estava cuidando disso" de qualquer equipe.

Falhas de verificação e término de tarefa. A verificação é incompleta ou inexistente. O sistema declara sucesso quando a saída está errada. Nenhum agente assume a checagem final de aceitação. Humanos só notam o problema lá na frente, quando a saída ruim já se propagou.

Leia a lista e o formato fica óbvio. Estas não são falhas de modelo no sentido restrito. São falhas de coordenação. São as mesmas falhas que uma equipe novinha de cinco pessoas comete no primeiro mês, antes que alguém tenha escrito quem é dono de quê.

Agrupe os 14 modos de outro jeito e o paralelo com design organizacional fica mais nítido:

• Ambiguidade de papéis. Posse vaga das tarefas. Dois agentes tentam o mesmo passo, ou nenhum tenta.
• Ambiguidade de estado. Sem fonte única da verdade para o que foi feito, o que está pendente, o que está bloqueado.
• Lacunas de responsabilização. Quem é responsável pela saída ruim? Em sistemas peer-to-peer, frequentemente ninguém.
• Sobrecarga de coordenação. O "problema da reunião". Agentes gastam tokens negociando em vez de produzir.
• Desvio de especificação. A mesma instrução é interpretada de forma diferente por agentes e ao longo dos turnos.

Se você já reconstruiu uma equipe que não estava entregando, viu todos os cinco. A solução em equipes humanas é a mesma que em sistemas de agentes: escolha um modelo operacional, registre os papéis, defina as transferências, instrumente o trabalho.

---

Por que Agentes Peer-to-Peer Não Funcionam

O erro arquitetural mais comum de 2024 e início de 2025 foi a colaboração peer-to-peer: criar uma "equipe" de agentes com prompts de papéis diferentes (CEO, pesquisador, programador, revisor), deixá-los conversar entre si num chat em grupo e torcer para que a coordenação emerja. Chats em grupo no estilo AutoGen, demos iniciais do CrewAI e uma onda de projetos "startup de IA em uma caixa" se apoiaram nesse padrão.

Falhou em produção, de forma consistente. Todos os modos de falha da taxonomia de Cemri se amplificam em uma configuração P2P. Sem um orquestrador, os limites dos papéis se embaralham porque pode-se pedir qualquer coisa a qualquer agente. O estado se espalha pelo histórico da conversa porque nenhum agente é dono do registro canônico. A responsabilização some porque o sistema como um todo produz a saída e o sistema como um todo não tem um nome nele.

A sobrecarga de coordenação é a vilã. Em um grupo de cinco agentes pares, cada ação significativa gera quatro observadores que se sentem obrigados a comentar. O custo de tokens explode. A relação sinal-ruído desaba. Cemri et al. descobriram que o reset conversacional, em que um agente reinicia um tópico já concluído porque não consegue perceber que ele acabou, foi uma das falhas mais comuns e caras do corpus deles.

Um exemplo concreto. Uma equipe de pesquisa com quem conversei no fim de 2025 montou um sistema de agentes P2P para redigir uma análise competitiva. Cinco agentes: analista de mercado, analista de produto, analista financeiro, redator, editor. A primeira execução levou 90 minutos e gerou um documento de 14.000 palavras. Cerca de 11.000 dessas palavras eram os agentes discutindo o que o documento deveria conter. As 3.000 restantes eram o documento em si, e elas se contradiziam. Na semana seguinte, a equipe reconstruiu como uma configuração orquestrador-trabalhador. Mesma tarefa, 22 minutos, 4.200 palavras, internamente consistentes. Cerca de metade do gasto em tokens.

P2P não falhou porque os agentes não fossem inteligentes o bastante. Falhou porque pediu que eles fizessem a coisa mais difícil que um grupo pode fazer: se organizar sem uma cadeira.

---

Orquestrador-Trabalhador: O Padrão que Venceu

O sistema de pesquisa da Anthropic é uma configuração orquestrador-trabalhador de manual. Um agente coordenador é dono da tarefa de alto nível. Ele decompõe a tarefa em subtarefas, entrega cada subtarefa a um agente trabalhador com um briefing específico, coleta resultados e decide o próximo passo. Os trabalhadores não conversam entre si. Eles conversam com o orquestrador.

Isso se encaixa nitidamente no design organizacional humano, e é exatamente por isso que funciona. Uma pequena startup com um fundador e quatro contratados opera assim. O fundador detém a especificação, o orçamento, o cronograma e o contexto compartilhado. Os contratados executam tarefas delimitadas a partir de um briefing. A informação sobe pelo fundador; as tarefas descem do fundador. Não se espera que os contratados coordenem entre si, exceto em pareamentos cuidadosamente delimitados.

O padrão tem quatro propriedades que importam para a confiabilidade.

Um único dono do estado compartilhado. O orquestrador detém o registro canônico. Não há ambiguidade sobre o que foi feito.

Contextos delimitados para os trabalhadores. Cada trabalhador recebe apenas o que precisa. Isso mantém as janelas de contexto gerenciáveis e reduz a chance de contaminação entre tarefas.

Transferências definidas. As saídas dos trabalhadores voltam em um formato estruturado que o orquestrador consegue verificar. Sem negociação livre.

Superfície única de responsabilização. Quando a saída está errada, a responsabilidade é do orquestrador. Você depura em um único lugar.

O relato da Anthropic é explícito sobre quanto do trabalho de confiabilidade aconteceu dentro do orquestrador: o prompt do agente líder é a parte mais longa e mais cuidadosamente ajustada do sistema, porque é ali que vivem as definições de papéis, as heurísticas de decomposição e a lógica de término. (Anthropic engineering)

Colaboração delimitada é uma variante útil. Dois trabalhadores podem ter permissão para conferir algo em uma transferência específica, mas só por um canal estruturado e só sobre um tópico definido. Pense nisso como uma reunião de status agendada, não como um canal do Slack. O limite é o ponto.

---

O Framework de 5 Níveis de Autonomia

A outra peça do andaime de 2025 que vale a pena conhecer é o framework de autonomia de "Levels of Autonomy for AI Agents" (arXiv 2506.12469, com um texto de governança complementar em Knight Columbia). Os autores definem cinco níveis, vagamente análogos à automação de direção da SAE, mas para agentes de IA.

Nível 0: Assistivo. O modelo sugere; o humano age. Autocompletar, sugestões inline de código, redação de rascunho de email.

Nível 1: Operador. O humano ainda dispara cada ação, mas o agente monta chamadas de ferramentas e passos compostos sob instrução direta.

Nível 2: Revisor. O agente propõe um plano e o executa sob revisão. O humano aprova nos checkpoints principais.

Nível 3: Colaborador. O agente é dono de tarefas inteiras de forma autônoma dentro de um limite delimitado. O humano revisa as saídas, não os passos.

Nível 4: Especialista. O agente opera independentemente em trabalhos complexos de múltiplos passos, com o humano intervindo só em exceções sinalizadas.

Nível 5: Agente. Autonomia plena em um domínio. O agente define metas, planeja, executa e se autocorrige com supervisão mínima.

O trabalho complementar da Anthropic "Measuring AI agent autonomy in practice" faz um ponto relacionado: em implantações reais, o nível operacional raramente é uniforme ao longo de um sistema. Um sistema de "nível 3" normalmente contém subcomponentes de nível 1 (ações de alto risco) e subcomponentes de nível 4 (trabalho de fundo, baixo risco). O que importa é casar o nível com a tarefa, não elevar o nível globalmente.

O nível que você mira molda toda decisão de design de papéis depois disso. No nível 2, seus agentes trabalhadores precisam de affordances claras de revisão de plano. No nível 4, precisam de sinalização de exceções e tracing rico. No nível 5, precisam de verificação formal dos critérios de aceitação, porque nada mais pega uma resposta errada. Construtores que pulam essa etapa escolhem a arquitetura primeiro e descobrem, em produção, que o nível que a arquitetura implica não é o nível que a tarefa tolera.

---

Níveis na Prática: O Caso Devin

O Devin, da Cognition, virou o conto cautelar mais citado de 2025. Lançado em março de 2024 como "o primeiro engenheiro de software de IA", o Devin atingiu 13,86 por cento no SWE-bench Verified, o que à época era o estado da arte. O marketing implicava autonomia de nível 4 ou nível 5: entregue um ticket, receba um PR funcionando de volta.

Em meados de 2025, várias revisões independentes colocaram a taxa de sucesso real do Devin em cerca de 15 por cento, o que significa uma taxa efetiva de falha em torno de 85 por cento em tarefas que não eram instâncias curadas de benchmark. Uma revisão amplamente citada da Answer.AI percorreu 20 tentativas reais e relatou que 14 falharam abertamente, com várias produzindo saídas confiantemente erradas que levaram mais tempo para depurar do que escrever o código do zero.

O que aconteceu é a lacuna benchmark-versus-produção, ainda mais nítida. Tarefas do SWE-bench Verified são limpas: um repositório, uma issue bem descrita, um sinal de teste claro, uma área de superfície restrita. Tickets reais de engenharia são bagunçados: specs ambíguas, preocupações cruzadas, premissas não documentadas, decisões que dependem de conhecimento tribal. O mesmo agente que rendeu nível 3 no benchmark caiu para um nível 2 cambaleante no mundo real, às vezes pior.

Devin não é uma história sobre um agente ruim. É uma história sobre um descompasso de nível. A arquitetura mirava confiabilidade de nível 5; a capacidade subjacente sustentava no máximo nível 2 em trabalho não curado. O marketing forçou os usuários a operar o sistema no nível anunciado, onde ele falhou. Os giros posteriores da Cognition, casos de uso mais delimitados, mais affordances com humano no loop, um enquadramento mais honesto, são uma tentativa de alinhar o nível operacional com a capacidade.

A lição é concreta. Escolha o nível de autonomia que seu sistema consegue sustentar na sua tarefa real mais difícil, não no seu benchmark mais fácil. Projete os papéis, a supervisão e os caminhos de escalonamento para esse nível. Se você quer marketing de nível 5, construa um sistema de nível 5; se você tem um sistema de nível 3, divulgue-o como tal.

---

Cursor 2.0 e o Fluxo de Trabalho Apoiado por Hardware

O Cursor 2.0 foi lançado em fevereiro de 2026 e resolveu silenciosamente um dos problemas mais persistentes da programação multiagente: o conflito de workspace. Os agentes em segundo plano do Cursor agora rodam em VMs de nuvem, cada um em seu próprio git worktree, com a IDE capaz de coordenar até oito em paralelo.

O detalhe arquitetural que importa: cada agente tem seu próprio sistema de arquivos. Sem worktree compartilhado, sem conflitos de merge no meio da edição, sem "agente A sobrescreveu as mudanças do agente B", sem execuções de teste instáveis porque dois agentes mexiam nos mesmos arquivos. Quando um agente termina, sua branch pode ser revisada e mesclada como qualquer outro PR. Quando dá errado, você joga o worktree fora.

Isso é isolamento apoiado por hardware no mesmo sentido em que máquinas virtuais deram isolamento de processo nos anos 2000. As cercas dos agentes não são mais "prometemos não pisar uns nos outros"; são "o sistema operacional literalmente não nos deixa".

Por que isso importa para a taxonomia de Cemri: o isolamento de hardware remove toda uma classe de falhas de desalinhamento entre agentes. O estado fica dentro do worktree. Efeitos colaterais ficam dentro da VM. O orquestrador (o próprio Cursor, ou o usuário) vê só o diff que cada agente produz. A checagem de aceitação é estrutural (o PR passa no CI?) em vez de conversacional (este agente afirma que o trabalho está feito?).

Praticantes que rodam o Cursor 2.0 ao lado do Claude Code da Anthropic, do Codex CLI da OpenAI e de outras ferramentas de agentes paralelos chegaram a um padrão: disparar de três a oito agentes em tarefas independentes, monitorar o progresso por um dashboard unificado, mesclar os vencedores, descartar os perdedores. O modelo de custo é mais próximo de "alugar um contratado júnior por uma hora e meia" do que de "fazer uma pergunta a um chatbot". O modelo de saída é mais próximo da revisão de PR no GitHub do que da conclusão de chat.

Anysphere (Cursor), Bolt, Lovable e v0 dentro da Vercel agora rodam variantes desse loop internamente. As empresas que mais entregam código dirigido por agentes são as que construíram primeiro o isolamento de workspace.

---

Projetando Papéis para Colegas de Equipe de IA

Uma vez aceito que falha multiagente é um problema de design organizacional, os movimentos de design que você faz começam a parecer gestão clássica. Todo papel de agente precisa de quatro artefatos.

Uma responsabilidade delimitada. Uma frase: o que este agente possui e o que não possui. Um agente "pesquisador" que também escreve prosa são dois agentes em um sobretudo. Separe-os.

Um briefing de entrada estruturado. Não "vá pesquisar X". Um template que preenche: a pergunta, o contexto prévio que o agente deve assumir, o formato da saída esperada, as restrições (tempo, tokens, ferramentas), as preferências de fontes. É o equivalente em agente de um briefing de projeto.

Critérios de aceitação definidos. Como é "feito"? Muitas vezes isso é um schema (a saída precisa validar contra este tipo Zod) ou uma checagem determinística (o PR precisa passar nestes três arquivos de teste). Onde checagens determinísticas não estão disponíveis, um agente revisor separado roda contra uma rubrica explícita.

Um caminho de escalonamento. Quando o agente trava, o que ele faz? Padrões razoáveis: fazer ao orquestrador uma pergunta estruturada de esclarecimento, expor uma exceção sinalizada para um humano, abortar com um erro tipado. O padrão errado é "continue e improvise". É daí que vem o sucesso alucinado.

Aplique os modos de falha de Cemri um a um e esses quatro artefatos cobrem a maioria deles. Ambiguidade de papéis morre na responsabilidade delimitada. Ambiguidade de estado morre no briefing estruturado. Lacunas de responsabilização morrem nos critérios de aceitação. Sobrecarga de coordenação cai porque o agente não precisa negociar; tem um briefing e uma rubrica. Desvio de especificação cai porque a spec está capturada no schema, não em vibrações.

A parte não óbvia: escreva o papel como você escreveria a descrição de uma vaga para um contratado, não como um prompt para um chatbot. Contratados são o modelo mental certo. Eles têm um briefing, entregam uma saída, não precisam conhecer todo o contexto da sua empresa e você os dispensa se eles seguirem fugindo da spec.

---

O Manual Multiagente do Fundador

Aqui está a versão prática, destilada do relato da Anthropic, do artigo de Cemri, dos postmortems do Devin e dos dados de fluxo de trabalho do Cursor 2.0.

Comece no nível 2 ou 3, não no nível 5. A capacidade é frágil sob mudança de distribuição. Mesmo que seu benchmark diga nível 4, sua tarefa real mais difícil costuma ser um nível abaixo. Mire o nível que sua tarefa mais difícil consegue sustentar.

Use orquestrador-trabalhador, não peer-to-peer. Um agente possui o estado compartilhado. Os trabalhadores recebem briefings delimitados. Colaboração delimitada só em junções cuidadosamente projetadas. Sem chats em grupo.

Defina um papel de agente por vez. Resista à vontade de projetar um sistema de cinco agentes em um quadro branco antes de qualquer parte ir para produção. Entregue um orquestrador e um trabalhador. Observe por uma semana. Adicione o próximo trabalhador quando você tiver visto o primeiro falhar e tiver corrigido.

Escreva o briefing como uma descrição de vaga. Responsabilidade, entradas, critérios de aceitação, escalonamento. Se você não consegue descrever o papel em quatro seções curtas, o papel não está pronto para ir para produção.

Instrumente com traces completos. Cada ação de agente, cada chamada de ferramenta, cada saída intermediária. Você não consegue depurar sistemas multiagentes lendo a saída final. O bug está quase sempre a montante.

Orce 15x o custo em tokens. O sistema de pesquisa da Anthropic usou cerca de 15 vezes os tokens de um baseline de agente único. Planeje conforme isso. Se sua economia unitária quebra em 15x, multiagente é o padrão errado para essa funcionalidade.

Mantenha um humano no loop em ações de consequência. "De consequência" normalmente quer dizer: escreve em um sistema voltado ao cliente, envia uma comunicação externa, gasta dinheiro, apaga dados, modifica um recurso de relevância para segurança. A revisão humana custa segundos; a ausência dela pode custar meses.

Construa o isolamento de workspace antes da frota de agentes. A lição do Cursor se generaliza. Git worktrees para código, transações de banco delimitadas para dados, VMs dedicadas para trabalho que toca em ambiente. Isolamento é mais barato que coordenação.

Faça um postmortem em cada falha nos primeiros 90 dias. Tague cada falha contra a taxonomia de Cemri. Padrões emergem rápido. A terceira falha de "agente refez trabalho concluído" é o sinal de que suas condições de término precisam apertar.

Nada disso é exótico. É o mesmo manual que uma liderança de engenharia competente usa para integrar uma nova equipe de contratados. A razão de multiagentes funcionar é que é o mesmo problema com um loop de feedback mais apertado.

---

Para Onde Isso Está Indo

Os próximos 12 a 18 meses tratam de transformar esses padrões em infraestrutura. Alguns fios a observar.

Protocolos agente-para-agente. O protocolo A2A do Google, a convenção AGENTS.md que está emergindo nas IDEs e CLIs, e vários rascunhos de interoperabilidade em grupos de trabalho são uma tentativa de padronizar como agentes se descobrem, trocam descrições de capacidades e se autenticam. (O panorama da Anthropic sobre construção de agentes acena nessa direção.) O ponto é tornar padrões orquestrador-trabalhador componíveis entre fornecedores, em vez de presos ao SDK de um provedor.

Autorização por capability tokens. Hoje, a maioria dos agentes herda as credenciais completas do usuário que os iniciou. É uma má ideia para nível 3 e acima. Capability tokens, estreitos, com janela temporal, escopados para chamadas e recursos específicos de ferramentas, são como os agentes vão obter as permissões de que realmente precisam sem as que não precisam. Espere que isso chegue aos SDKs de produção em 2026.

Identidades de agente verificadas. Quando agentes começam a chamar outros agentes através de fronteiras organizacionais, o lado receptor precisa saber o que está chamando. Identidades de agente assinadas, atestação de treinamento e configuração, e formatos de identidade entre fornecedores estão sendo prototipados agora. O modelo é mais próximo de transparência de certificados do que de OAuth.

Avaliação melhor. SWE-bench, MLE-bench, GAIA e suítes similares se esticaram o bastante para que modelos de fronteira os saturem. A próxima geração de avaliações vai medir coisas que benchmarks historicamente evitaram: conclusão de tarefa de longo horizonte, cumprimento sustentado de políticas, recuperação de falhas, custo por sucesso. Espere que "confiabilidade de agente" se torne uma propriedade mensurável do mesmo jeito que "uptime" se tornou para serviços.

Tagueamento padronizado de falhas. Cemri et al. deram à área uma taxonomia. O próximo passo natural é a tooling que tagueia traces contra essa taxonomia automaticamente, do jeito que o Sentry tagueia exceções. Fundadores que configurarem isso cedo vão depurar seus sistemas de agentes uma ordem de magnitude mais rápido do que aqueles que não o fizerem.

O trabalho ainda está em pleno voo. Nenhum desses fios está consolidado. Mas o formato da próxima fase é visível: menos artesanato de prompt, mais engenharia de sistemas; menos "o que o modelo consegue fazer?", mais "que papel preciso preencher, e como é o feito?". As equipes que vão prosperar serão as que tratam agentes como colegas de equipe, com o mesmo rigor que aplicariam a qualquer nova contratação. Papéis, briefings, critérios de aceitação, caminhos de escalonamento. Os artefatos entediantes de organizações competentes.

---

Perguntas Frequentes

Toda equipe deveria construir sistemas multiagentes?

Não. A maioria das funcionalidades de IA em produção ainda funciona melhor como configurações de agente único com boas ferramentas. Multiagente ganha seu sustento quando a tarefa é genuinamente decomponível (subtarefas independentes que podem rodar em paralelo), o valor por tarefa justifica o custo de 15x em tokens, e a confiabilidade foi comprovada primeiro na camada de agente único. Um sistema de agente único que falha não se torna um sistema multiagente que funciona. Costuma se tornar um sistema que falha mais caro.

Qual é o padrão multiagente pronto para produção mais simples?

Orquestrador com dois trabalhadores, ambos com critérios de aceitação determinísticos. O orquestrador possui o estado compartilhado. Os trabalhadores recebem briefings delimitados. Saídas validam contra um schema antes de o orquestrador aceitá-las. Isso é o suficiente para capturar a maior parte do benefício da decomposição sem a sobrecarga de coordenação de equipes maiores. Aumente a quantidade de trabalhadores só depois que esse baseline estiver confiável.

O custo de 15x em tokens vale a pena?

Depende do valor da saída. O sistema de pesquisa da Anthropic faz sentido econômico porque a alternativa é um pesquisador humano gastando horas na mesma tarefa. Para trabalho de baixo valor e alto volume (classificação de intenção, sumarização simples, extração rotineira), o custo de 15x em tokens quase nunca vale a pena; use uma configuração de agente único ou um modelo menor. Para trabalho de alto valor e baixo volume (pesquisa profunda, tarefas complexas de programação, análise multi-fonte), a conta muitas vezes fecha.

Como saber quando disparar um subagente versus usar um prompt mais longo?

Dispare um subagente quando o trabalho tiver um requisito de contexto diferente da tarefa pai. Se a subtarefa precisa de ferramentas diferentes, de um system prompt diferente, ou de contexto que poluiria a janela do pai, dê a ela seu próprio agente. Se a subtarefa é "só faça essa próxima coisa" e compartilha o contexto do pai, um prompt mais longo ou uma chamada de ferramenta é mais barata e mais confiável. A pergunta decisiva costuma ser sobre contexto: eu gostaria de ter esse contexto na memória do meu orquestrador depois que a subtarefa terminar?

Qual é a diferença entre um agente e uma ferramenta de IA?

Uma ferramenta é uma única capacidade determinística que o modelo pode chamar (uma busca web, uma consulta a banco, um formatador de código). Um agente é um loop: ele observa, planeja, chama ferramentas, avalia o resultado e decide o próximo passo, frequentemente ao longo de muitos turnos. Ferramentas são substantivos; agentes são verbos. Um agente bem construído usa muitas ferramentas. Uma "ferramenta" que chama um modelo internamente e roda seu próprio loop é, na prática, um agente.

---

Considerações Finais

O enquadramento mais útil que ouvi para o momento atual veio de uma liderança de engenharia tocando um rollout de programação multiagente: "Paramos de pensar nos agentes como inteligentes e começamos a pensar neles como juniores com estamina infinita". Juniores precisam de papéis claros, briefings escritos, critérios de aceitação definidos e um caminho de escalonamento. Eles cometem erros previsíveis. Melhoram com feedback. Falham quando ninguém é dono do trabalho deles.

Essa é a virada de design organizacional escondida dentro da conversa sobre multiagentes. Os problemas difíceis de 2025-2026 já não são problemas de capacidade. Os modelos estão bons o bastante. Os problemas difíceis são os mesmos que sempre fizeram equipes humanas serem difíceis de tocar: quem é dono de quê, quem segura o estado, quem confere o trabalho, quem é responsável quando algo dá errado. A taxonomia de Cemri, o framework de autonomia, o padrão orquestrador-trabalhador, o postmortem do Devin, o modelo de isolamento do Cursor: todos são respostas a versões da mesma pergunta.

Se você é um fundador entregando um produto dirigido por agentes em 2026, os artefatos entediantes são a alavancagem. Escreva os papéis. Escreva os briefings. Defina o feito. Construa o isolamento de workspace. Instrumente os traces. Mantenha o humano no loop onde importa. As equipes que fizerem isso vão parecer mais lentas por dois meses e mais rápidas por dois anos. As equipes que pularem isso vão passar o resto do ano tagueando modos de falha contra uma taxonomia que outra pessoa já escreveu.

Os agentes agora são colegas de equipe. Gerencie-os como tais.