Protocolos agente a agente em resumo: Agent Cards do A2A, tarefas e o lugar do MCP

O que é

O protocolo Agent2Agent (A2A) é uma especificação aberta para a comunicação entre sistemas de agentes independentes, possivelmente opacos, criados por fornecedores diferentes e sobre frameworks diferentes; o objetivo declarado é oferecer uma linguagem comum e um modelo de interação sem que os agentes compartilhem estado interno, memória ou ferramentas. A versão 1.0.0 é a release atual, publicada sob a Linux Foundation, tendo a definição em protocol buffers como fonte normativa. Seus blocos de construção são: o Agent Card, um documento JSON que o servidor publica (obtido em /.well-known/agent-card.json) e que descreve identidade, capacidades, skills, o endpoint do serviço e os esquemas de segurança que o cliente deve usar (API key, autenticação HTTP, OAuth 2.0, OpenID Connect ou mutual TLS), além de um card estendido opcional, acessível mediante autenticação; as tarefas, a unidade de trabalho, com os estados submitted, working, input-required, auth-required, completed, failed, canceled e rejected, sendo que os dois estados de interrupção devolvem o controle ao cliente; as mensagens trocadas durante uma tarefa e os artefatos produzidos por ela, ambos compostos por parts, que podem ser texto, arquivos ou dados estruturados; e as operações para enviar uma mensagem, enviá-la em streaming, consultar, listar, cancelar ou assinar uma tarefa, e para gerenciar as configurações de notificações push destinadas a webhooks. São especificados três bindings: JSON-RPC 2.0 sobre HTTP, gRPC e HTTP com JSON; as chamadas bloqueantes esperam por um estado terminal ou de interrupção, as não bloqueantes retornam imediatamente, e o cliente faz polling, recebe streaming ou recebe webhooks.

Por que importa

Um agente que delega trabalho a outro agente precisa de descoberta (o que o outro sabe fazer e como me autentico), de uma identidade de tarefa que sobreviva a trabalhos longos e à intervenção humana, e de uma forma de receber resultados sem manter uma conexão aberta. Os princípios orientadores da especificação tratam exatamente dessas questões: reaproveitamento de HTTP, JSON-RPC e Server-Sent Events, design assíncrono desde a origem para tarefas longas com uma pessoa no circuito, e execução opaca. O apêndice sobre o MCP traça a fronteira com a qual os dois projetos concordam: o MCP padroniza como um modelo ou agente se conecta a ferramentas, APIs e fontes de dados; o A2A padroniza como os agentes se descobrem, negociam a interação e gerenciam tarefas compartilhadas como pares, e um servidor A2A pode usar o MCP internamente para realizar seu trabalho.

Como aplicar

• Publique um Agent Card apenas para capacidades que você realmente oferece, e mantenha as descrições das skills concretas o bastante para que um cliente consiga fazer o roteamento com base nelas.
• Modele o trabalho longo como tarefas e use input-required para pedir esclarecimentos, em vez de fazer a tarefa falhar; os clientes devem tratar os dois estados de interrupção.
• Escolha um binding por implantação e documente-o no card; não espere que os clientes tentem vários.
• Trate as parts recebidas como dados, exatamente como se tratam resultados de ferramentas: o protocolo transporta conteúdo, não confiança.

Armadilhas

A versão 1.0.0 mudou estruturas em relação às releases anteriores (o apêndice de migração da especificação lista breaking changes, como a remoção do discriminador kind e a mudança de lugar do campo do card estendido), portanto bibliotecas escritas para a 0.2 ou a 0.3 precisam ser verificadas. Um card descreve o que um agente declara; verificar o comportamento continua sendo tarefa do cliente.