Quase todo sistema multiagente que me mostraram neste ano tem a mesma história por trás. Um agente não fazia bem uma tarefa, alguém propôs dividi-la entre três agentes especializados, e agora há três agentes que também não a fazem bem, mais um problema novo: entrar em acordo entre eles. O diagrama ficou impressionante e o resultado piorou.
A resposta curta: as quatro formas de estender um agente respondem a perguntas diferentes. Não são alternativas nem etapas de maturidade. Escolher a errada não só desperdiça trabalho, adiciona modos de falha que antes não existiam. E a que mais se escolhe cedo demais, multiagente, é justamente a que mais adiciona.
Que pergunta cada uma responde?
Quatro perguntas diferentes. Se você sabe qual é a sua, a escolha é óbvia.
| Extensão | A pergunta que responde | O que NÃO resolve |
|---|---|---|
| Harness | Como o modelo age em vez de apenas responder? | O que ele deve fazer, e com qual informação |
| Skills | Ele sabe como esta tarefa é feita aqui? | Chegar aos sistemas onde o dado vive |
| MCP | Ele consegue tocar os sistemas onde está o dado? | O que fazer depois de chegar lá |
| A2A | Ele consegue delegar a um agente que não é seu? | Coordenar os agentes que são seus |
| Multiagente | Vale a pena dividir o trabalho entre vários? | Que cada parte esteja bem resolvida |
A confusão mais cara do mercado está entre as linhas dois e três. MCP dá ao agente a chave do depósito. Uma Skill diz o que fazer lá dentro. São complementares, e a maioria dos sistemas em produção usa as duas.
O que é o harness e por que quase ninguém o nomeia?
É o laço que transforma um modelo em agente. Sem ele não há agente, há um chat.
Um modelo de linguagem, sozinho, recebe texto e devolve texto. O harness é o que o faz agir: pega a instrução, deixa o modelo decidir, executa a ferramenta pedida, devolve o resultado, deixa decidir de novo, e persiste o estado entre passos para que a volta seguinte saiba o que aconteceu na anterior.
É o conceito menos discutido das listas que circulam, e o que mais determina se o sistema serve. Um harness ruim aparece como sintomas que as pessoas atribuem ao modelo: o agente repete o mesmo passo, não reconhece que já terminou, ou perde no meio do caminho o que já tinha decidido.
Não é coincidência que esses três sintomas apareçam como modos de falha nomeados na literatura, e voltaremos a eles adiante.
Quando você precisa de uma Skill?
Quase sempre, e é a mais barata das quatro.
Uma Skill é uma pasta de instruções que ensina ao agente como fazer uma coisa: o critério, a ordem, o formato de saída, o que checar antes de entregar. Desde dezembro de 2025 é um padrão aberto baseado em arquivos: um SKILL.md com instruções mais os recursos e scripts de que precisar [2].
Seu mecanismo central é a divulgação progressiva: ao iniciar, o agente carrega apenas o nome e a descrição de cada Skill, cerca de 30 a 50 tokens cada. As instruções completas carregam quando a tarefa corresponde, e os arquivos referenciados só durante a execução [2]. Isso importa por um motivo prático: você pode ter cinquenta Skills disponíveis sem gastar contexto com as quarenta e nove que não se aplicam hoje.
Sinal de que você precisa de uma Skill: o agente tem acesso a tudo de que precisa e mesmo assim entrega no formato errado, pula uma etapa de revisão ou aplica um critério que na sua empresa não é o correto.
Sinal de que não é isso que falta: o agente sabe exatamente o que fazer e não consegue, porque não chega ao sistema.
Quando você precisa de MCP?
Quando o agente tem que tocar sistemas de verdade, e são mais de um.
MCP resolve o problema das integrações sob medida: um protocolo padrão em vez de um conector artesanal por ferramenta. Se o seu agente fala com um único sistema e você já tem esse conector escrito, MCP não vai mudar sua vida hoje. Se vai falar com seis, e você espera nove no ano que vem, a diferença é estrutural.
Sinal de que você precisa de MCP: você está escrevendo o terceiro conector à mão e os três se parecem suspeitosamente.
Sinal de que não: um único sistema, estável, com uma API que já funciona. Adotar o protocolo ali é sobrecusto de arquitetura sem retorno.
Quando você precisa de A2A?
Quando o outro agente não é seu. Essa é toda a regra.
A2A existe para que agentes de donos ou fornecedores diferentes se descubram, troquem tarefas e deleguem trabalho com segurança. É uma decisão de interoperabilidade entre organizações, não de arquitetura interna.
Confunde-se com multiagente o tempo todo porque ambos envolvem mais de um agente. A diferença é a fronteira: A2A a cruza, multiagente não.
Sinal de que você precisa de A2A: você vai se integrar com o agente de um fornecedor, cliente ou parceiro, e nenhum dos dois controla o outro.
Sinal de que não: os agentes são todos seus, rodam na sua infraestrutura e foram implantados no mesmo dia. Ali um protocolo de descoberta entre desconhecidos é cerimônia.
Quando você precisa de multiagente?
Bem mais tarde do que a maioria pensa, e há evidência do que custa chegar cedo.
O estudo MAST da UC Berkeley analisou mais de 1.600 traços anotados de sete frameworks multiagente populares e classificou 14 modos de falha distintos [1]. O relevante não é a contagem, é de onde eles vêm.
Dados
| Value | Share | |
|---|---|---|
| Especificação e desenho do sistema | 41.8% | 42% |
| Desalinhamento entre agentes | 36.9% | 37% |
| Verificação da tarefa | 21.3% | 21% |
Quase 37% das falhas são desalinhamento entre agentes. Esse percentual não existe num sistema de um só agente: é um custo que aparece no dia em que você decide dividir o trabalho. E a categoria maior, especificação e desenho, também cresce com a divisão, porque cada fronteira nova entre agentes é uma especificação nova que alguém precisa escrever bem.
Os modos individuais mais frequentes são igualmente reveladores.
Dados
| Modo de falha | Frequência |
|---|---|
| Repetir um passo já executado | 15.7% |
| Não reconhecer a condição de término | 12.4% |
| Desobedecer a especificação da tarefa | 11.8% |
Repetir um passo, não perceber que já terminou, desobedecer a instrução. São exatamente os sintomas de um harness fraco, que é o primeiro item da lista e o que quase ninguém construiu antes de dividir o trabalho entre três agentes.
Sinal de que você precisa de multiagente: você tem subtarefas genuinamente paralelas, ou que exigem contextos incompatíveis entre si, e já tem um agente que resolve bem cada uma.
Sinal de que não: um agente faz a tarefa mal e a proposta é dividi-la. Dividir um problema que você não entende dá vários problemas que você também não entende.
Em que ordem se constrói?
De baixo para cima, e quase nunca se chega ao fim.
| Passo | Extensão | Quando passar ao seguinte |
|---|---|---|
| 1 | Harness | Quando o agente completa a tarefa ponta a ponta e sabe quando terminou |
| 2 | Skills | Quando critério e formato saem certos sem ninguém corrigir à mão |
| 3 | MCP | Quando o agente alcança todos os sistemas de que precisa |
| 4 | Multiagente | Só se houver paralelismo real ou contextos incompatíveis |
| 5 | A2A | Só se o outro agente for de outra pessoa |
A maioria dos projetos que funcionam para entre o 2 e o 3. Isso não é uma limitação, é o resultado esperado: os passos 4 e 5 resolvem problemas que a maioria dos sistemas não tem.
Como aplicamos isso na MasterDragon
Perguntamos o que falta antes de perguntar o que adicionar.
Na prática, quando um agente não rende, revisamos nesta ordem: ele reconhece quando terminou? o critério está escrito ou estamos supondo? ele chega aos dados? Só se as três respostas forem sim e o trabalho continuar saindo errado é que consideramos dividi-lo. Na maioria dos casos a resposta está na segunda pergunta e se resolve escrevendo bem uma instrução, não implantando arquitetura.
Também construímos com um único agente por padrão e o dividimos só quando conseguimos nomear a subtarefa que roda em paralelo. Se não conseguimos nomeá-la, não há paralelismo, há vontade de ter um diagrama mais interessante.
Se você está prestes a se comprometer com uma arquitetura de agentes e quer saber qual dessas quatro está faltando, fale com nossos engenheiros. Você pode começar por como construímos seu software e ver nosso portfólio de produtos AI-native já lançados. As definições completas do vocabulário estão no glossário de IA agêntica, o que está por baixo de um agente que aguenta produção em as 13 camadas de um sistema de IA real, e quanta autonomia dar a cada um em autonomia projetada.
Referências
- Cemri, M., et al. (2025). Why do multi-agent LLM systems fail? UC Berkeley. arXiv:2503.13657. https://arxiv.org/abs/2503.13657
- Anthropic. (2025, dezembro). Agent Skills: formato aberto de empacotamento baseado em pastas (SKILL.md) com divulgação progressiva. https://anthropic.skilljar.com/introduction-to-agent-skills