Por que o Protocolo A2A será o Arquiteto das Empresas em 2026 e 2027 | Codenity

Tem um momento específico em qualquer revolução tecnológica onde a coisa para de ser promessa e vira infraestrutura. A internet passou por isso. O cloud passou por isso. Os LLMs estão passando por isso agora — e a maioria das pessoas ainda não percebeu.

O A2A (Agent-to-Agent Protocol) é um dos primeiros sinais concretos dessa virada. Não estou falando de hype de Twitter ou de paper acadêmico. Estou falando de algo que coloquei em produção, num projeto real, com dados reais — e que mudou completamente a forma como eu penso sobre arquitetura de sistemas com IA.

Deixa eu te contar como foi.

Quando a explosão dos LLMs começou a bater nas portas das empresas de verdade, surgiu uma necessidade que ninguém tinha resolvido direito: como fazer múltiplos agentes de IA trabalharem juntos, de forma segura, sem virar um espaguete de integrações impossíveis de manter?

A resposta mais popular foi o MCP — Model Context Protocol. Gerou muito barulho, muita gente implementou, e muita gente também descobriu que o custo de manutenção era alto demais pra maioria dos contextos: projetos caros, difíceis de evoluir e frágeis nas bordas.

O A2A aparece como uma alternativa mais enxuta. A ideia central é simples: cada agente publica um “cartão de apresentação” — o Agent Card, um arquivo JSON que descreve o que aquele agente sabe fazer, quais tipos de tarefa ele aceita, quais protocolos de autenticação suporta e onde estão seus limites. Quando um agente encontra outro na rede, ele lê esse cartão e já sabe como e quando acionar aquele agente. Sem hardcode, sem configuração manual — o ecossistema se auto-descreve.

Parece simples. E é — mas as implicações dessa simplicidade são enormes.

Comecei estudando pelo curso gratuito da DeepLearning.AI sobre o protocolo, enquanto vasculhava o repositório oficial. Minha primeira impressão foi que seria “mais um protocolo de comunicação”. Mudei de ideia rápido quando vi a quantidade de possibilidades que a arquitetura abre. Logo depois, tive a chance de aplicar tudo isso num projeto real dentro de uma empresa — e é aí que a história fica interessante.

O modelo base escolhido foi o Gemini, via Google AI Studio. Decisão pragmática: o limite de tokens generoso antes da cobrança começar permite iterar rápido nos primeiros ciclos sem ansiedade com custo. Para validar arquitetura, isso vale muito.

A primeira decisão crítica foi a autenticação. E aqui aprendi uma regra que vou carregar pra sempre: se os seus agentes comunicam só entre si numa rede interna, vai de M2M — Machine-to-Machine. Esquece OAuth, JWT e qualquer outro modelo mais complexo pra esse cenário.

O M2M entrega, nesse cenário: custo de implementação menor, gerenciamento de secrets mais simples e uma superfície de ataque muito mais controlada.

É o padrão-ouro pra redes fechadas.

No meu caso, o desafio era outro: precisávamos conectar um agente externo aos agentes internos da empresa. Aí o OAuth fez todo o sentido — é o padrão esperado por terceiros, garante escopos de permissão bem definidos e mantém o fluxo auditável. A lição não é “use X ou Y”, é: existe o protocolo certo pra cada contexto, e confundir os dois te custa semanas.

A espinha dorsal da arquitetura foi a combinação de gRPC Streaming com LangGraph — e foi um dos casamentos mais elegantes que já vi na prática.

O LangGraph assumiu o controle do estado da conversação: os loops entre os agentes, as condicionais, o grafo de execução. É exatamente pra isso que ele existe. Já o gRPC Streaming resolveu um problema que eu não esperava ser tão crítico: quando um agente precisa esperar outro processar um nó complexo do grafo, a requisição não pode simplesmente dar timeout. O canal de comunicação precisa continuar vivo, os dados precisam fluir conforme ficam disponíveis. O streaming nativo do gRPC garante exatamente isso — e foi a primeira vez que vi essa feature fazer sentido não como curiosidade técnica, mas como necessidade real de arquitetura.

Mas o ponto que quase inviabilizou o projeto inteiro não foi o protocolo.

Foi a latência.

As buscas via API externa levavam minutos.

Minutos.

Quando você coloca isso na ponta do usuário, o projeto morre antes de nascer. E foi aqui que entrou a parte mais interessante da solução: uma camada de busca e indexação com Elasticsearch, combinada com RAG — Retrieval-Augmented Generation.

Em vez de o agente consultar a API em tempo real, o fluxo passou a ser diferente. Os dados da API são ingeridos previamente, processados e indexados no Elasticsearch com enriquecimento semântico. Quando o agente precisa de informação, o Elasticsearch já entrega o contexto via busca híbrida — misturando busca vetorial semântica com busca tradicional por termos. Os parâmetros são enriquecidos via JSON-RPC 2.0 antes de chegarem ao modelo. O Gemini recebe só o que é relevante, mastigado, estruturado.

O resultado: o tempo de resposta caiu de minutos pra milissegundos. E como bônus, paramos de injetar ruído no contexto do modelo — o que economizou uma quantidade absurda de tokens e melhorou a qualidade das respostas.

Tem um erro muito comum em projetos com LLM em produção: jogar todo o contexto bruto no prompt e esperar que o modelo filtre sozinho o que importa. Funciona em demos. Em produção, você paga caro por isso — em tokens, em latência e em qualidade. O RAG resolve isso na raiz: em vez de passar cinquenta páginas de documentação pro modelo decidir o que é relevante, você usa o Elasticsearch pra já trazer os três trechos mais importantes pra aquela consulta específica. O modelo recebe só o que precisa.

Mais rápido, mais barato, mais preciso.

Uma coisa que me poupou dias de trabalho foi descobrir que o Postman já tem suporte nativo pra JSON-RPC 2.0. Eu estava cogitando construir uma GUI customizada pra monitorar o processo — e quase perdi horas nisso. Ver os agentes trabalhando no enriquecimento de dados em tempo real, acompanhando as chamadas estruturadas direto pelo Postman, foi uma das melhores surpresas do projeto.

O projeto avançou rápido. Semanas, não meses. Mas há uma coisa que eu faria diferente se tivesse mais tempo e orçamento — e que considero hoje quase obrigatória em qualquer projeto A2A sério: um sistema de retenção de conversas entre agentes.

Parece detalhe.

Não é.

Quando múltiplos agentes se comunicam numa rede, cada troca entre eles é dado.

É contexto. É histórico de decisão.

E se você não está salvando isso, está jogando fora uma das coisas mais valiosas que a sua arquitetura produz.

A estrutura que implementaria usaria MongoDB como camada de persistência, e o raciocínio por trás dessa escolha é simples: as conversas entre agentes são naturalmente documentos semi-estruturados. Cada interação tem agente de origem, agente de destino, timestamp, payload trocado, estado do grafo naquele momento e resultado produzido.

Isso não cabe bem numa tabela relacional — cabe perfeitamente num documento JSON armazenado no Mongo.

Cada conversa seria salva como uma sessão com ID único, contendo o histórico completo de mensagens trocadas entre os agentes naquele fluxo. Dentro de cada mensagem, você guarda o papel de quem enviou, o conteúdo, o nó do LangGraph que estava ativo, e metadados como tokens consumidos e tempo de resposta. Com isso, você consegue reconstruir exatamente o que aconteceu em qualquer execução — o que é ouro na hora de debugar um comportamento inesperado.

Mas o valor vai muito além do debugging. Com esse histórico acumulado, você começa a enxergar padrões: quais fluxos os agentes percorrem com mais frequência, onde ocorrem os gargalos, quais perguntas o orquestrador recebe que nenhum agente especialista consegue resolver bem. Isso vira insumo direto pra evoluir a arquitetura — e eventualmente, pra fazer fine-tuning do modelo com exemplos reais de uso em produção.

Tem outro benefício que subestimei no começo: o keep-alive de contexto entre sessões. Hoje, sem retenção, cada sessão começa do zero. O agente não lembra o que foi discutido ontem, não sabe que aquele fluxo já foi executado antes com parâmetros similares, não consegue reaproveitar contexto de uma conversa anterior. Com MongoDB guardando o histórico, você pode injetar sessões anteriores relevantes no contexto do agente antes de uma nova execução — uma forma de memória de longo prazo que muda completamente o que é possível construir.

Abrimos mão disso pra avançar mais rápido no projeto. Foi a troca certa naquele momento. Mas é a primeira coisa que entra num projeto de segunda fase — sem discussão.

Agora vem a pergunta que me incomoda de verdade: por que o Brasil ainda não está usando isso em peso?

Temos mercado enorme. Temos empresas com processos complexos que se beneficiariam imensamente de redes de agentes. Temos comunidade técnica capaz de implementar. O A2A não é ciência de foguete — é um protocolo bem documentado, com repositório aberto, com cursos gratuitos disponíveis. E ainda assim o assunto praticamente não existe em português além da camada de “o que é”.

Minha hipótese é que ainda estamos presos no ciclo de hype sem prática suficiente. É mais fácil publicar um post sobre “o futuro dos agentes de IA” do que sentar e construir um. É exatamente por isso que escrevi esse texto.

O que estou construindo agora é um servidor pessoal com múltiplos agentes, cada um com uma responsabilidade específica e privilégios restritos ao seu próprio Agent Card — como departamentos de uma empresa real. A divisão atual: um agente para pagamentos, com acesso à API do banco apenas para débitos autorizados; outro para emissão de notas fiscais, com privilégios mínimos no mesmo sistema financeiro; e um orquestrador central que recebe um prompt meu e distribui as tarefas.

A ideia de ter uma rede fechada gerenciada por um único prompt pessoal é o que me motivou a começar este blog. E conforme esse projeto evolui, vou documentar tudo aqui — os acertos, os erros e as decisões de arquitetura que nenhum tutorial cobre.

No horizonte mais longo, o que me parece mais provável — e mais transformador — não é um marketplace separado de agentes. É o A2A sendo embutido diretamente nos sistemas que as empresas já usam: CRMs, ERPs, plataformas de cobrança e módulos financeiros.

Não como substituto, mas como uma camada de inteligência que vive dentro da ferramenta.

Deixa eu tornar isso concreto.

Imagina um analista de cobrança abrindo o ERP da empresa — o mesmo que ele já usa todo dia. Só que agora tem um chat no canto da tela. Ele digita:

“me traz os pagamentos recusados do cliente Empresa X nos últimos 90 dias, gera um relatório de inadimplência e manda pro departamento de cobranças.”

Parece simples. Por baixo, é uma orquestração inteira acontecendo.

O agente orquestrador recebe o prompt, interpreta a intenção e decompõe a tarefa em três ações distintas. Ele consulta os Agent Cards disponíveis na rede e descobre que tem um agente especialista em dados financeiros, um agente de geração de documentos e um agente de comunicação interna. Cada um com seus privilégios mínimos declarados no card: o agente financeiro só lê, não escreve; o de documentos só cria no módulo autorizado; e o de comunicação só envia para destinatários pré-aprovados.

A busca pelos pagamentos recusados não vai direto na base de dados crua do ERP. Passa primeiro pela camada de Elasticsearch — a mesma lógica do RAG que descrevi antes. Os dados financeiros do cliente já estão indexados com enriquecimento semântico: histórico de transações, status de cada cobrança, datas, valores, motivos de recusa. O agente financeiro faz uma busca híbrida, retorna só o que é relevante pro período solicitado, e passa o contexto já estruturado pro orquestrador via JSON-RPC.

O orquestrador repassa esse contexto limpo pro agente de documentos, que usa um template do próprio módulo de documentos do ERP pra gerar o relatório — sem sair do sistema, sem exportar nada manualmente. O documento criado fica vinculado ao cadastro do cliente automaticamente.

Por último, o agente de comunicação pega o ID do documento gerado e envia a notificação pro departamento de cobranças, com o link e um resumo do que foi encontrado.

Todo esse fluxo acontece em segundos.

O analista não abriu uma aba nova, não exportou planilha, não mandou e-mail manualmente.

Ele descreveu o que queria em linguagem natural e o sistema orquestrou o resto.

O que torna isso possível não é mágica — é arquitetura. São quatro engrenagens que fazem isso acontecer: o A2A garante que cada agente conhece o que o outro pode fazer e respeita os limites declarados no Agent Card; o Elasticsearch garante que a busca é rápida e o contexto que chega no modelo é limpo; o MongoDB guarda o histórico de cada execução, então se o mesmo fluxo for solicitado amanhã com outro cliente, o orquestrador já sabe o caminho mais eficiente; e o LangGraph mantém o estado de tudo isso coeso — se algum agente falha no meio, o grafo sabe exatamente onde retomar.

O que muda pra empresa não é a interface. É o que a interface consegue fazer. O ERP continua sendo o ERP. Só que agora ele tem inteligência operando por baixo, conectando os pontos que antes dependiam de um humano fazendo trabalho manual e repetitivo.

Não creio que isso vá eliminar decisões humanas em breve — ações críticas ainda precisam de aprovação. Mas a fronteira entre o que precisa de um humano e o que pode ser delegado pra uma rede de agentes está se movendo rápido. E as empresas que já tiverem essa infraestrutura montada vão sentir essa diferença antes dos outros.