Eu assisti a uma aula sobre arquiteturas de agentes de IA e tive uma reação muito específica: meu olho de engenheiro ajoelhou.
Não porque a ideia de agentes seja ruim. Pelo contrário. Coordenar capacidades diferentes, acionar ferramentas, dividir tarefas e voltar com uma resposta mais completa é uma direção natural para a IA.
O problema é outro.
O que hoje está sendo vendido como arquitetura sofisticada muitas vezes parece, em produção, um mapa de fragilidade: um agente chama outro agente, que chama uma ferramenta, que consulta outro sistema, que devolve texto para um juiz, que decide se a resposta volta, se tenta de novo ou se chama mais um módulo.
No slide, isso parece bonito.
Em produção, cada seta é um contrato que pode quebrar.
A tese
A minha tese é simples: a complexidade exposta das arquiteturas multiagente é um andaime. Ela existe porque as capacidades ainda estão separadas. Conforme os modelos e as plataformas ficarem mais completos, esse andaime será absorvido para dentro do próprio sistema.
Não é o fim dos agentes.
É o fim do agente como organograma desenhado à mão.
O futuro mais coeso não é uma pilha de pequenos agentes costurados por prompts, MCPs, árbitros e callbacks. O futuro mais coeso é um agente residente dentro do sistema, capaz de entender o contexto inteiro, decidir sozinho quando precisa dividir trabalho e voltar para conversar com o usuário.
Menos arquitetura exposta.
Mais orquestração interna.
Complexidade acidental vs. complexidade essencial
Complexidade essencial é o problema real: entender contexto, consultar dados, executar tarefas, respeitar permissões e devolver algo útil. Complexidade acidental é o custo extra da solução: prompts intermediários, passagens frágeis entre agentes, logs incompletos e estados espalhados.
O problema técnico: LLMs não são determinísticos
Um pipeline tradicional de machine learning pode ser complexo, mas costuma ter fronteiras mais claras. Você mede entrada, saída, latência, erro, drift, taxa de acerto e comportamento por etapa.
Com LLMs encadeados, a história fica mais escorregadia.
Um modelo recebe contexto, produz texto, outro modelo interpreta esse texto, uma ferramenta transforma aquilo em ação, outro agente julga o resultado e um último agente sintetiza a resposta. Quando algo falha, a pergunta vira arqueologia.
Um agente isolado pode parecer confiável.
Quatro agentes em sequência multiplicam o risco.
0,95 x 0,95 x 0,95 x 0,95 = 0,81.
E isso antes de considerar latência, timeout, contexto perdido, API quebrada, autorização vencida ou mudança de comportamento do modelo.
Isso não é só engenharia bonita. Isso é observabilidade. E observabilidade em sistema multiagente ainda é muito mais difícil do que os diagramas sugerem.
Por que isso parece frágil para produção
O problema não é usar ferramentas. O problema é transformar ferramenta em arquitetura principal.
Quando vejo um desenho com muitos agentes, subagentes, juiz, roteador, memória, avaliador e várias conexões pequenas, eu penso no time que vai manter isso em produção.
Alguém vai precisar descobrir por que a tarefa falhou.
Alguém vai precisar reproduzir um bug que talvez dependa de uma resposta probabilística.
Alguém vai precisar explicar para o cliente por que ontem funcionou e hoje não.
Alguém vai precisar versionar prompts, traces, modelos, ferramentas, permissões, contexto e saídas intermediárias.
Esse alguém normalmente é engenharia.
MCP não some, mas muda de lugar
MCP e protocolos parecidos podem sobreviver muito bem. Mas eu não vejo MCP como o centro da experiência do usuário comum. Vejo como ponte para o resíduo: sistemas que a plataforma não possui, não pode possuir ou não quer internalizar.
O canibalismo das plataformas
O movimento das grandes plataformas é óbvio: tudo que for horizontal, repetível e valioso será absorvido.
Imagem virou recurso.
Busca virou recurso.
Código virou recurso.
Voz está virando recurso.
Vídeo vai pelo mesmo caminho.
Design, apresentação, automação, navegação, análise, deploy, e-mail, reunião, CRM, suporte: tudo que puder ficar dentro do mesmo ambiente tende a ficar dentro do mesmo ambiente.
Isso não acontece por maldade. Acontece por gravidade econômica. Cada minuto que o usuário passa fora da plataforma é receita que escapa. Cada ferramenta externa é uma fronteira de falha.
Canibalismo de plataforma
Canibalismo de plataforma é quando uma capacidade que antes era produto separado passa a existir dentro de uma plataforma maior. A pergunta deixa de ser "qual ferramenta eu abro?". Vira: "por que eu sairia daqui?".
O exemplo do design
Durante anos, o Canva foi a resposta simples para quem não queria abrir a Adobe para tudo. Ele reduziu fricção. Deu velocidade. Virou ferramenta de massa.
Agora a camada de IA começa a pressionar até esse tipo de produto.
Se eu consigo pedir uma arte, uma página, um layout, uma variação visual ou uma peça de campanha dentro do ambiente onde já estou trabalhando, a pergunta muda.
Não é se uma ferramenta especializada é melhor. Muitas vezes ela é.
A pergunta é se ela é melhor o suficiente para justificar sair do fluxo.
O que sobrevive
Eu não acredito em apocalipse de 100%.
O que é vertical, profundo, regulado ou cheio de dados proprietários continua tendo espaço. Empresas que conhecem um domínio melhor do que a plataforma genérica podem sobreviver e prosperar.
Saúde, bancos, indústria, jurídico, governo, pesquisa científica e sistemas internos complexos não viram recurso tão facilmente.
Mas wrappers genéricos, orquestradores superficiais e ferramentas que existem apenas porque a plataforma principal ainda não incorporou aquela função estão em terreno perigoso.
Eles vivem numa janela. E janela fecha.
O andaime não é o prédio
Eu não acho que frameworks de agentes sejam burrice.
Eles fazem sentido agora.
Quando uma capacidade está fora do modelo, você cria uma ferramenta. Quando uma tarefa é grande demais, você divide. Quando o modelo erra, você coloca um juiz. Quando o contexto é longo, você cria memória. Quando a empresa precisa integrar sistema legado, você cria ponte.
Isso é racional.
Mas racional não significa permanente.
Muita arquitetura que hoje parece inevitável é apenas a forma temporária de lidar com a imaturidade dos modelos e a fragmentação das plataformas.
O andaime ajuda a construir.
Mas ninguém quer morar no andaime.
Orquestração emergente
O sistema não precisa receber um organograma fixo de agentes. Ele entende o problema, lê o contexto, decide se precisa dividir tarefas, cria sub-rotinas ou subagentes quando necessário e depois consolida o resultado.
O agente residente
O horizonte que me parece mais provável é este: um agente residente por sistema.
No repositório, ele entende o código, os testes, os padrões, os históricos de erro, as dependências e os objetivos do time.
No CRM, ele entende cliente, funil, comunicação, contrato e próxima ação.
No hospital, ele entende protocolo, prontuário, limite regulatório e contexto clínico.
A pessoa conversa. O agente trabalha por dentro. Se precisar consultar uma ferramenta, consulta. Se precisar dividir trabalho, divide. Se precisar chamar uma capacidade especializada, chama. Mas isso não aparece como um carnaval de módulos para o usuário.
A interface final é conversa.
A arquitetura interna é decisão do sistema.
Minha leitura
Quando vejo diagramas cheios de agentes, MCPs, juízes e submódulos, eu não vejo o destino final.
Vejo uma fase.
Uma fase importante, talvez necessária, mas ainda assim uma fase.
O mercado está desenhando arquiteturas para compensar o fato de que as capacidades ainda estão fragmentadas. Só que as plataformas estão trabalhando exatamente para eliminar essa fragmentação.
E quando elas conseguem eliminar uma fronteira, aquela parte da arquitetura deixa de ser produto e vira recurso.
O futuro não é menos agente.
É menos agente exposto.
Menos conexão pequena.
Menos prompt costurado.
Menos árbitro no meio do campo.
Mais sistema coeso, mais contexto compartilhado, mais orquestração interna e mais responsabilidade de engenharia sobre o que realmente importa: confiabilidade, segurança, avaliação e observabilidade.
O andaime vai existir enquanto o prédio estiver subindo.
Mas o prédio não será feito de andaime.