A próxima fronteira de AI Engineering não está apenas na construção de agentes mais capazes, mas na capacidade de fazer agentes independentes colaborarem sem compartilhar implementação, runtime, memória ou framework. Esse é o problema central que Agent-to-Agent, ou A2A, tenta resolver. Em produção, porém, interoperabilidade não significa simplesmente permitir que um agente envie mensagens para outro. Significa estabelecer contratos suficientemente estáveis para conectar sistemas probabilísticos, stateful, assíncronos e administrados por domínios diferentes.
A especificação A2A 1.0 reflete essa preocupação ao separar modelo de dados canônico, operações abstratas e protocol bindings. JSON-RPC, gRPC e HTTP+JSON podem transportar interações equivalentes sem redefinir a semântica fundamental do protocolo. Essa separação é relevante para arquitetura porque impede que decisões de transporte contaminem o contrato lógico entre agentes.
O verdadeiro desafio aparece acima do protocolo. Um Agent Card pode declarar capabilities; um Task pode representar trabalho assíncrono; um Artifact pode transportar resultados. Ainda assim, nenhuma dessas abstrações resolve, isoladamente, versionamento semântico, autorização delegada, propagação de deadlines, idempotência, observabilidade causal, avaliação distribuída ou controle de custos.
Para Staff e Principal AI Engineers, portanto, A2A deve ser tratado como uma nova boundary de sistemas distribuídos. O desenho correto exige contract engineering, reliability engineering, security engineering, evaluation engineering e platform governance trabalhando conjuntamente.
O objetivo deste artigo é discutir exatamente essa camada: como transformar interoperabilidade entre AI agents em infraestrutura operacionalmente previsível, economicamente controlável e evolutiva, evitando que uma arquitetura multi-agent se transforme em uma rede de dependências probabilísticas impossível de depurar.
Fale comigo no LinkedIn: https://www.linkedin.com/in/celso-sousa/
1. A2A como boundary arquitetural: interoperabilidade sem acoplamento entre runtimes agentic
A principal decisão arquitetural em A2A acontece antes da escolha do SDK, framework ou protocol binding. Ela consiste em determinar qual responsabilidade deve atravessar a fronteira entre agentes. Um sistema bem desenhado não expõe raciocínio interno, memória privada, prompts, ferramentas ou detalhes do orchestration graph. Ele expõe capabilities com contratos explícitos, mantendo encapsulados os mecanismos usados para satisfazê-las.
Essa propriedade aproxima A2A de princípios clássicos de distributed systems e domain-driven design. Cada agente deve funcionar como um bounded context operacional, responsável por sua própria lógica, modelos, ferramentas, estado e políticas. A comunicação externa ocorre por meio de uma superfície deliberadamente menor do que a implementação interna. Isso reduz temporal coupling e permite que equipes evoluam runtimes independentemente.
O erro recorrente é transformar cada componente inteligente em um agente remoto. Nesse desenho, operações que poderiam ser funções locais, nodes de um workflow ou chamadas determinísticas tornam-se network hops. Latência, serialização, autenticação, observabilidade, retries e failure handling passam a existir onde antes havia apenas uma chamada de função.
A2A cria maior valor quando independência organizacional e autonomia operacional são requisitos reais. Isso ocorre quando capabilities pertencem a diferentes produtos, equipes, clouds, frameworks ou organizações. Nesses contextos, a interoperabilidade padronizada reduz integração ponto a ponto.
A boundary adequada deve, portanto, maximizar autonomia sem fragmentar excessivamente o sistema. Para AI Engineering, essa distinção é fundamental: multi-agent architecture não significa maximizar a quantidade de agentes. Significa identificar boundaries nos quais especialização, isolamento de falhas, segurança e evolução independente compensam o custo adicional de comunicação distribuída.
1.1. Separando interoperabilidade, orquestração e implementação interna dos agentes
Interoperabilidade, orquestração e runtime interno são problemas arquiteturais diferentes, embora frequentemente sejam tratados como uma única camada. Essa confusão produz sistemas nos quais A2A acaba controlando detalhes que deveriam permanecer privados ao agente, criando dependências difíceis de evoluir.
O runtime interno responde à pergunta de como um agente executa uma capability. Ele pode utilizar LangGraph, código procedural, state machines próprias, planners, RAG, ferramentas determinísticas ou múltiplos modelos. Nenhum desses detalhes deveria ser necessário para um consumidor remoto.
A orquestração responde a uma pergunta diferente: qual sequência de capabilities deve ser executada para atingir um objetivo maior? Um orchestration layer pode selecionar agentes, executar fan-out, consolidar resultados, aplicar retries ou acionar human-in-the-loop. Ele gerencia coordenação, não implementação.
A interoperabilidade define a terceira dimensão: qual contrato permite que dois sistemas independentes interajam apesar de utilizarem stacks diferentes? A2A atua principalmente nessa fronteira. O protocolo permite que um cliente descubra capabilities, envie trabalho, acompanhe tasks e receba artifacts sem conhecer a estrutura interna do agente.
Essa separação produz uma propriedade valiosa: substituibilidade. Um agente pode migrar de um LLM proprietário para um SLM self-hosted, trocar seu vector database ou reestruturar seu orchestration graph sem afetar consumidores, desde que preserve contrato e semântica observável.
Em arquiteturas Staff-level, essa independência deve ser deliberadamente testada. Consumer-driven contract tests precisam verificar que clientes dependem exclusivamente da interface publicada.
A pergunta central deixa de ser “qual framework usamos para agentes?” e passa a ser “qual parte da semântica realmente precisa atravessar a boundary?”. Essa mudança aparentemente simples reduz acoplamento e cria plataformas agentic capazes de evoluir durante anos, não apenas durante uma demonstração.
1.2. A2A como contrato entre domínios autônomos, não como novo service mesh
A comparação entre A2A e service mesh é tentadora porque ambos lidam com sistemas distribuídos, descoberta, comunicação e segurança. Entretanto, eles operam em camadas conceitualmente diferentes. Um service mesh gerencia transporte entre workloads conhecidos. A2A adiciona semântica para comunicação entre entidades capazes de executar tarefas, produzir artifacts e negociar interações cujo comportamento pode ser parcialmente probabilístico.
Isso não transforma A2A em substituto para infraestrutura de rede. TLS, workload identity, service discovery, retries de transporte, traffic management e telemetry continuam pertencendo às camadas apropriadas da plataforma. Replicar essas responsabilidades dentro do runtime dos agentes cria duplicação e políticas inconsistentes.
A arquitetura mais sustentável posiciona A2A como um application protocol acima da infraestrutura distribuída existente. Kubernetes, gateways, service meshes, API management ou cloud networking podem fornecer conectividade e enforcement. A2A descreve aquilo que acontece semanticamente depois que o canal foi estabelecido.
Essa distinção também afeta observabilidade. Um erro HTTP 503 informa que a chamada falhou operacionalmente. Ele não informa se o agente rejeitou semanticamente uma task, solicitou input adicional ou atingiu uma policy boundary. Métricas de infraestrutura e métricas agentic precisam coexistir, mas não devem ser confundidas.
Outro risco surge ao transformar A2A em uma malha global onde qualquer agente pode descobrir e chamar qualquer outro. Isso aumenta blast radius, superfície de ataque e dificuldade de governança.
Uma plataforma madura adota conectividade intencional. Domains publicam capabilities por registries controlados, políticas determinam quais identidades podem consumi-las e gateways aplicam limites operacionais.
O resultado desejado não é uma rede irrestrita de agentes. É uma topologia governada de colaboração na qual autonomia existe dentro de boundaries explicitamente projetadas.
1.3. A2A versus MCP, APIs tradicionais, event-driven architecture e workflows internos
A escolha entre A2A, MCP, APIs tradicionais, eventos ou workflows internos não deveria ser orientada por novidade tecnológica. Cada mecanismo resolve um tipo de boundary diferente, e arquiteturas maduras frequentemente utilizam todos simultaneamente.
MCP organiza principalmente a interação entre modelos ou agentes e recursos externos, como tools, data sources e serviços. A2A aborda colaboração entre agentes independentes. Uma API REST continua sendo excelente quando existe uma operação determinística e claramente estruturada. Kafka ou outro event backbone permanece superior quando produtores e consumidores precisam desacoplamento temporal em grande escala. Um workflow interno continua sendo a melhor opção quando todas as etapas pertencem ao mesmo ownership boundary.
A distinção importante é semântica. Quando um sistema solicita “calcule o limite desse cliente”, provavelmente uma API determinística é suficiente. Quando solicita “investigue este conjunto de sinais, produza uma hipótese, peça informações adicionais se necessário e entregue um relatório”, a abstração de Task começa a fazer sentido.
A especificação A2A 1.0 reforça essa independência entre semântica e transporte ao definir um modelo canônico e permitir bindings oficiais para JSON-RPC, gRPC e HTTP+JSON/REST. Portanto, A2A não deveria ser reduzido a “mais uma API HTTP”.
O princípio arquitetural é escolher o mecanismo com menor complexidade capaz de representar corretamente o problema.
A adoção indiscriminada de agentes para operações determinísticas introduz variabilidade, tokens e latência sem ganho real. Por outro lado, tentar representar colaboração agentic complexa como centenas de endpoints específicos cria contratos frágeis.
Staff Engineers devem desenhar um protocol portfolio, não escolher um protocolo universal. A qualidade da arquitetura emerge precisamente da capacidade de preservar diferentes abstrações para diferentes responsabilidades.
1.4. Onde estabelecer o boundary: agente, capability, domínio, produto ou organização
Definir a granularidade da boundary é uma das decisões mais difíceis em plataformas multi-agent. Um boundary muito fino transforma cada capability em serviço remoto e produz chatty architectures. Um boundary excessivamente amplo gera agentes monolíticos, com dezenas de responsabilidades e pouca capacidade de evolução independente.
Ownership costuma ser um critério melhor que tecnologia. Se duas capabilities são mantidas pela mesma equipe, compartilham ciclo de release, dados, SLOs e políticas de acesso, separá-las por A2A pode acrescentar pouco valor. Se pertencem a domínios distintos, possuem modelos de segurança diferentes ou precisam evoluir independentemente, a boundary torna-se mais justificável.
Capability cohesion também importa. Um agente de underwriting, por exemplo, pode reunir retrieval regulatório, análise financeira e policy reasoning internamente. Expor cada etapa como agente remoto permitiria flexibilidade teórica, porém transferiria detalhes do processo interno para consumidores. O contrato mais estável provavelmente é a capability de underwriting como unidade.
Organizações diferentes representam o caso mais forte para A2A porque a implementação interna inevitavelmente deve ser tratada como opaca. Nesse cenário, Agent Cards, contratos, autenticação e semântica de Task formam uma boundary natural.
Também existe uma dimensão econômica. Cada nova boundary cria custos fixos de discovery, observability, security, testing e governance. Portanto, decomposição agentic possui um custo marginal muito maior que decomposição puramente lógica dentro de um processo.
Uma heurística útil é exigir pelo menos uma justificativa estrutural: ownership independente, trust boundary, scaling profile distinto, lifecycle autônomo ou necessidade real de interoperabilidade.
A arquitetura resultante tende a possuir menos agentes do que diagramas conceituais sugerem. Isso é positivo. Bons sistemas distribuídos minimizam comunicação remota; boas plataformas agentic deveriam seguir o mesmo princípio.
2. Contract Engineering: projetando interfaces que sobrevivem à evolução dos agentes
Em sistemas tradicionais, contratos descrevem parâmetros, tipos e respostas. Em sistemas agentic, isso é insuficiente porque duas implementações podem aceitar exatamente o mesmo schema e produzir comportamentos semanticamente incompatíveis. Contract Engineering para A2A precisa, portanto, tratar estrutura, significado, comportamento operacional e políticas como partes do contrato.
O primeiro nível é sintático. Campos, media types, task identifiers, artifacts e erros devem obedecer ao protocolo. O segundo nível é semântico: uma capability chamada customer-risk-analysis precisa ter significado suficientemente preciso para que consumidores saibam quais evidências são analisadas, quais resultados são possíveis e quais garantias não são oferecidas.
Existe ainda um contrato temporal. O consumidor precisa entender se a operação tende a completar em segundos ou minutos, se pode pedir input adicional e se cancellation é best effort. Finalmente, existe um contrato de confiança: quais identidades podem executar a capability, quais dados podem ser enviados e quais políticas restringem resultados.
Essas dimensões deveriam ser administradas como produto de plataforma. Agent Cards, schemas e documentation-as-code precisam participar de CI/CD, versionamento, code review e compatibility testing.
A ausência dessa disciplina produz semantic drift. O endpoint continua respondendo, os schemas permanecem válidos, mas o comportamento muda silenciosamente após troca de modelo, prompt ou dataset.
Para AI Engineering, isso exige expandir a definição clássica de API stability. A estabilidade relevante não é apenas “o JSON continua igual”. É “consumidores continuam recebendo resultados dentro da distribuição comportamental esperada”.
Essa perspectiva conecta contract testing a evaluation engineering. Em arquiteturas A2A maduras, regressões semânticas são incompatibilidades de contrato, mesmo quando nenhum parser quebra.
2.1. Agent Cards, capability discovery e o problema da descoberta dinâmica confiável
Agent Cards fornecem uma abstração essencial para discovery. Eles descrevem identidade, capabilities, skills, interfaces suportadas e requisitos de segurança do agente. A especificação também prevê descoberta em um well-known endpoint e possibilidade de informações adicionais por meio de extended cards autenticados.
Em produção, contudo, discovery não deveria significar que um LLM pesquisa livremente centenas de Agent Cards e decide quais sistemas chamar. Esse desenho mistura service discovery, semantic routing e authorization em uma única decisão probabilística.
Uma arquitetura robusta separa essas funções. Um registry controla quais agentes existem. Um policy layer determina quais são acessíveis para determinada workload identity. Um capability index pode suportar busca semântica. Finalmente, um router seleciona entre candidatos previamente autorizados.
A qualidade dos metadados torna-se crítica. Descrições vagas como “agent capable of financial analysis” são inúteis em ambientes com dezenas de serviços semelhantes. Skills precisam representar capabilities operacionalmente distintas, com input modes, output modes, tags e documentação coerente.
Descoberta também precisa considerar health e readiness. Um Agent Card válido não significa que o agente esteja saudável, dentro do cost budget ou adequado ao SLO da requisição atual. Portanto, registries de produção normalmente precisam enriquecer metadados estáticos com sinais dinâmicos provenientes da plataforma.
Existe ainda risco de supply-chain. Um agente malicioso ou incorretamente registrado pode declarar capabilities atraentes para receber tráfego sensível. Assinaturas de Agent Cards, ownership verificável e allowlists reduzem essa superfície.
A conclusão arquitetural é importante: Agent Card é o contrato publicado, não o sistema inteiro de discovery. Enterprise AI platforms precisam construir governança, confiança e routing policy ao redor dessa abstração.
2.2. Contratos semânticos: schemas validam estrutura, mas não garantem significado
Um JSON Schema pode garantir que confidence seja um número entre zero e um. Ele não consegue dizer o que essa confiança representa. Pode ser probabilidade calibrada, score heurístico, self-assessment do LLM ou simplesmente um número gerado pelo modelo. Essa diferença resume o problema de semantic contracts em arquiteturas A2A.
Campos estruturalmente válidos podem carregar significados incompatíveis. O mesmo ocorre com labels como high-risk, recommended ou verified. Quando múltiplos agentes independentes colaboram, esse problema deixa de ser detalhe de documentação e passa a ser risco sistêmico.
Uma abordagem madura define semantic invariants. Se um agente retorna confidence, o contrato deveria explicar população de referência, método de calibração e condições nas quais o campo pode ser omitido. Se produz citations, precisa especificar se representam fontes consultadas ou evidências realmente usadas para suportar a conclusão.
Artifacts estruturados deveriam possuir schemas versionados, mas também semantic specifications legíveis por humanos. Exemplos positivos e negativos são especialmente úteis porque capturam boundaries difíceis de expressar por tipos.
Outra prática importante é separar fatos de inferências. Um artifact que mistura dados recuperados, hipóteses do modelo e recomendações torna downstream evaluation muito mais difícil. Estruturas explícitas para evidence, inference e decision melhoram auditabilidade.
Semantic contracts também precisam de testes. Golden datasets podem validar invariantes fundamentais; property-based evaluation testa comportamentos gerais; adversarial suites verificam inputs ambíguos.
No nível Staff, a preocupação central é impedir que significado se torne dependência implícita. Uma plataforma com centenas de agentes não consegue sobreviver se cada consumidor precisar compreender empiricamente o comportamento de cada produtor.
Schemas protegem a forma do sistema. Semantic contracts protegem o significado. Em AI Engineering, ambos são necessários para interoperabilidade real.
2.3. Versionamento, capability negotiation e backward compatibility em ecossistemas heterogêneos
Versionar um agente é mais complexo do que versionar uma API porque comportamento pode mudar sem alteração de schema. Trocar o system prompt, atualizar o foundation model, modificar retrieval ou alterar políticas pode produzir regressões relevantes enquanto a interface permanece tecnicamente compatível.
Por isso, três tipos de versão deveriam ser tratados separadamente: versão do protocolo, versão do contrato da capability e versão da implementação. Misturar essas dimensões dificulta determinar qual mudança causou uma regressão.
O protocolo A2A inclui protocolVersion nas interfaces publicadas e mecanismos para declaração de extensions. Na camada de plataforma, entretanto, ainda é necessário definir política própria para evolução de capabilities.
Backward compatibility deveria ser avaliada semanticamente. Se uma nova versão altera distribuição de respostas, classificação de risco ou formato lógico de artifacts, pode exigir nova major version mesmo quando os campos JSON continuam idênticos.
Capability negotiation oferece outra estratégia. Em vez de assumir que todos os agentes suportam as mesmas features, clientes podem descobrir media types, streaming, extensions e skills disponíveis antes da interação. Isso permite rollout progressivo sem exigir upgrades coordenados.
Entretanto, negotiation aumenta state space. Cada combinação suportada precisa ser testada, observada e eventualmente removida. Portanto, compatibilidade infinita é economicamente inviável.
Uma política saudável define support windows, deprecation deadlines e telemetry de consumidores. Antes de remover uma versão, a plataforma deve saber quais workloads ainda a utilizam.
Canary routing também é valioso. Pequena fração das tasks pode ser enviada à nova implementação e comparada à baseline usando offline e online evaluation.
O princípio é simples: agentes podem evoluir rapidamente internamente, mas contratos compartilhados devem evoluir lentamente. Essa assimetria preserva inovação sem transferir instabilidade para todo o ecossistema.
2.4. Design system para agentes: convenções, taxonomias, policies e contratos reutilizáveis
À medida que uma organização ultrapassa alguns agentes, decisões locais começam a produzir fragmentação. Cada equipe escolhe sua própria nomenclatura de skills, error taxonomy, metadata fields, correlation identifiers, authorization scopes e artifact schemas. A2A resolve interoperabilidade protocolar, mas não cria automaticamente consistência organizacional.
É nesse ponto que surge a necessidade de um agent design system. Assim como design systems de frontend padronizam componentes visuais, um design system agentic padroniza primitives de interação entre agentes.
O objetivo não é impedir autonomia. É evitar que cada equipe reinvente decisões horizontais. Convenções podem definir como capabilities são nomeadas, quais metadata namespaces existem, como provenance é representada, quais campos de observabilidade são obrigatórios e quais estados internos jamais podem vazar pelo contrato público.
Taxonomias compartilhadas facilitam discovery. Em vez de dezenas de sinônimos para customer, account ou campaign, a organização mantém ontologias mínimas para conceitos interoperáveis. Isso reduz ambiguidade em routing e evaluation.
Policies também pertencem ao design system. Regras para PII, data residency, human approval, maximum task duration e cost budgets precisam ser aplicadas consistentemente.
Templates de Agent Cards, contract tests e reference implementations diminuem o custo de conformidade. Uma equipe deveria conseguir publicar um novo agente seguindo um paved road, sem estudar toda a infraestrutura interna.
O design system precisa ser pequeno o suficiente para não se transformar em burocracia. Padronizar tudo cria coupling organizacional; padronizar pouco demais cria caos.
Staff e Principal Engineers devem identificar invariantes horizontais e transformá-las em primitives reutilizáveis. O resultado não é apenas melhor developer experience. É uma linguagem operacional comum que torna centenas de agentes governáveis como plataforma.
3. Execution Semantics: como tornar colaboração distribuída previsível
Protocolos agentic precisam representar operações que podem durar milissegundos, minutos ou horas. Algumas terminam imediatamente; outras aguardam input humano, autorização ou processamento externo. Por isso, modelar toda interação como request-response síncrono produz abstrações incorretas.
A2A introduz Task como unidade stateful de trabalho, permitindo acompanhar progresso e resultados independentemente de uma conexão específica. A especificação atual inclui estados como submitted, working, input required, auth required, completed, failed, canceled e rejected. Essa state machine fornece uma base, mas sistemas reais precisam definir semântica operacional ao redor dela.
A principal dificuldade é que execution semantics atravessam múltiplos agentes. Um agente A pode criar uma Task em B, que cria outra em C. Agora cancellation, deadline e falha precisam propagar por uma árvore distribuída.
Sem regras explícitas, tasks órfãs continuam consumindo tokens depois que a requisição principal foi cancelada. Retries criam trabalho duplicado. Eventos chegam depois que consumidores consideraram a operação encerrada.
A solução exige tratar cada interação como execução distribuída, com identifiers, causal context, deadlines absolutos e políticas claras de retry.
O princípio mais importante é evitar semântica implícita. “Cancelado” pode significar interrupção imediata ou apenas que o sistema não deseja mais o resultado. “Completed” pode significar sucesso técnico, não necessariamente qualidade semântica.
Execution contracts precisam documentar essas diferenças.
Em produção, confiabilidade não emerge da capacidade do agente de raciocinar sobre falhas. Ela emerge de state machines, invariantes e mecanismos determinísticos construídos ao redor desse raciocínio.
3.1. Task lifecycle, context boundaries e máquinas de estado distribuídas
Uma Task deveria ser tratada como entidade operacional, não como simples envelope para uma resposta futura. Ela possui identidade, estado, histórico e relação com um contexto. Essa distinção permite modelar interações long-running sem manter uma conexão síncrona permanentemente aberta.
A especificação A2A define estados terminais como completed, failed, canceled e rejected, além de estados intermediários como submitted, working, input required e auth required. Para arquitetura, o desafio está em garantir transições válidas e efeitos consistentes ao redor desses estados.
State transitions deveriam ser persistidas antes de side effects irreversíveis quando possível. Caso contrário, um crash pode executar uma ação sem registrar que ela ocorreu. Esse é o mesmo problema clássico encontrado em workflow engines e distributed transactions.
Context também precisa de limites claros. Compartilhar o mesmo contextId entre tasks relacionadas pode preservar continuidade, mas contexto excessivamente longo aumenta custo, exposição de dados e risco de contamination. A plataforma deveria diferenciar correlation context de model context.
Outro ponto crítico é nested delegation. Quando um agente cria tasks downstream, surge uma árvore causal. O parent precisa conhecer child task identifiers para observabilidade e cancellation, mas não necessariamente precisa receber todo o estado interno dessas tasks.
Uma representação explícita de parent-child relationships melhora debugging e cost attribution.
Também é recomendável definir retention policy. Históricos de Task podem conter PII, prompts ou artifacts sensíveis e não deveriam ser mantidos indefinidamente.
No nível Staff, a state machine precisa ser uma primitive de plataforma. Não deve depender de cada agente interpretar livremente o que significa “working” ou “failed”.
Quanto mais probabilístico é o trabalho interno, mais determinística precisa ser a máquina operacional ao redor dele.
3.2. Request-response, streaming e execução assíncrona para long-running agents
Não existe um único mecanismo de entrega adequado para todas as interações agentic. A escolha entre resposta direta, polling, streaming e webhook deveria ser baseada na duração da tarefa, frequência de updates e topologia do consumidor.
A especificação A2A atual suporta polling de tasks, streaming de eventos e push notifications para execução assíncrona. Ela também exige ordenação de eventos dentro do stream e mantém o lifecycle da Task independente da conexão utilizada para observá-la. Essa propriedade é essencial: desconectar um cliente não deveria cancelar trabalho implicitamente.
Streaming é adequado para experiências interativas, progressive rendering e observabilidade de progresso. Entretanto, conexões persistentes aumentam consumo de recursos, complexity em load balancers e necessidade de reconnection logic.
Webhooks são melhores para long-running workflows server-to-server, mas introduzem outra superfície de segurança. Endpoints precisam ser autenticados, protegidos contra SSRF e preparados para entregas duplicadas. A própria especificação recomenda processamento idempotente porque notificações podem ser repetidas.
Polling é operacionalmente simples, porém gera tráfego desperdiçado e aumenta completion latency percebida.
Uma arquitetura de plataforma pode esconder essas diferenças atrás de uma abstraction comum de Task subscription. Aplicações escolhem SLA e interação desejados, enquanto adapters traduzem para polling, SSE ou webhook.
Também é importante não confundir token streaming com task streaming. Tokens são detalhes de geração; eventos de Task representam progresso semântico.
A escolha correta reduz coupling entre interface do usuário e implementação do agente. Em sistemas long-running, essa separação é o que permite resiliency, reconnection e execução distribuída sem transformar conexões de rede em fonte de verdade.
3.3. Idempotência, retries, deduplicação e o mito do exactly-once entre agentes
Falhas transitórias tornam retries inevitáveis em sistemas distribuídos. Em arquiteturas A2A, entretanto, repetir uma requisição pode significar repetir uma ação inteligente com side effects: gerar uma cobrança, enviar uma campanha, criar um ticket ou disparar uma transação. Por isso, retry sem idempotência é um risco de negócio.
O primeiro princípio é separar delivery semantics de execution semantics. Uma mensagem pode ser entregue duas vezes enquanto o efeito lógico ocorre apenas uma. Conseguir isso exige identifiers persistentes e deduplication storage no boundary responsável pelo side effect.
Idempotency keys deveriam representar a intenção do caller, não apenas request IDs de transporte. Um retry originado após timeout precisa reutilizar a mesma chave; uma nova intenção precisa receber outra.
Exactly-once distribuído é, na prática, uma abstração construída sobre mecanismos como deduplicação, transactional outbox ou commits atômicos locais. A rede não fornece exatamente uma entrega.
Agentes tornam o problema mais interessante porque duas execuções independentes do mesmo prompt podem gerar artifacts diferentes. Portanto, deduplicar depois da inferência pode consumir tokens desnecessariamente. O controle deveria ocorrer antes do trabalho caro sempre que possível.
Retry policies também precisam considerar semântica do erro. Timeouts ou rate limits podem ser retriable; policy violations e invalid input normalmente não são. Repetir cegamente chamadas a LLMs aumenta custo e pode amplificar incidentes downstream.
Jitter e exponential backoff evitam retry storms. Retry budgets impedem que uma cadeia de agentes multiplique tentativas exponencialmente.
Uma rule útil é definir um retry owner por boundary. Se gateway, orchestrator e agente aplicam três retries cada, um único pedido pode produzir dezenas de inferências.
Em A2A, confiabilidade não significa tentar até funcionar. Significa controlar rigorosamente quando uma ação pode ser repetida sem alterar sua intenção original.
3.4. Timeouts, cancellation, partial failures e propagation de budgets entre múltiplos agentes
Timeout não deveria ser configurado isoladamente em cada hop. Em uma cadeia A → B → C → D, quatro timeouts de trinta segundos não produzem necessariamente uma operação de trinta segundos. Eles podem produzir uma execução que ultrapassa dois minutos, principalmente quando existem retries.
Sistemas maduros propagam um deadline absoluto. Cada agente calcula quanto budget ainda resta antes de iniciar trabalho downstream. Se o tempo disponível é insuficiente, ele pode selecionar uma estratégia mais rápida, degradar qualidade ou falhar imediatamente.
O mesmo princípio vale para cost budgets. Um agente que recebeu limite de cinquenta centavos não deveria delegar vinte chamadas sem considerar custo acumulado.
Cancellation também precisa de semântica explícita. Em A2A, o protocolo oferece operação para solicitar cancelamento, mas a capacidade real de interromper trabalho depende da implementação. Portanto, cancellation deveria ser tratada como cooperative cancellation, não como garantia instantânea.
Cada child task precisa receber propagation do cancellation signal. Ferramentas externas e jobs assíncronos também deveriam ser interrompidos quando possível.
Partial failures requerem decisões adicionais. Se cinco agentes executam fan-out e quatro completam, a resposta pode ser útil? A decisão depende do contrato do workflow. Quorum, best-effort e all-or-nothing são políticas diferentes.
Essas políticas deveriam ser codificadas no orchestrator, não improvisadas pelo LLM.
Também é importante coletar wasted-work metrics: tokens e computação consumidos após o resultado já ter expirado ou sido cancelado. Em sistemas agentic de grande escala, esse desperdício pode ser financeiramente relevante.
Budgets de tempo, custo e trabalho precisam viajar junto com o contexto distribuído. Sem isso, autonomia local de cada agente destrói previsibilidade global.
4. Trust Architecture: identidade, autorização e contenção entre agentes independentes
A interoperabilidade amplia a superfície de confiança. Quando um agente começa a delegar trabalho a sistemas independentes, não basta proteger endpoints com uma API key. É necessário responder quem está chamando, em nome de quem, para realizar qual ação, utilizando quais dados e dentro de quais limites.
A2A permite declarar security requirements e mecanismos de autenticação no Agent Card, mas a arquitetura corporativa precisa fornecer identidade e authorization enforcement ao redor dessas primitives.
O erro mais perigoso é transferir credenciais do usuário ao longo de toda a cadeia de agentes. Isso aumenta blast radius e transforma cada agente intermediário em potencial credential holder. Tokens deveriam ser audience-bound, short-lived e limitados ao menor conjunto possível de scopes.
Trust também precisa ser transitivo apenas quando explicitamente permitido. O fato de o agente A confiar em B e B confiar em C não deveria automaticamente permitir que A delegue dados sensíveis a C.
Essa propriedade exige policy enforcement fora do modelo generativo. Um LLM pode propor a chamada, mas um deterministic policy engine deve decidir se ela é autorizada.
A segurança de agentes adiciona outra dimensão: conteúdo recebido de um peer pode carregar instruções maliciosas. Portanto, trusted transport não implica trusted content.
Arquiteturas A2A precisam combinar workload identity, content isolation, authorization, provenance e policy-as-code.
O objetivo não é eliminar autonomia. É limitar sua autoridade.
Essa diferença é essencial. Um agente pode decidir como resolver uma tarefa dentro de uma sandbox operacional, mas não deveria decidir unilateralmente quais credenciais pode usar, quais dados pode exfiltrar ou quais sistemas críticos pode modificar.
4.1. Agent identity, workload identity e delegated authorization
Identidade de agente deveria ser tratada como workload identity, não como nome textual publicado em um Agent Card. O campo “Finance Agent” ajuda discovery humano; ele não é uma prova criptográfica de quem executa aquela workload.
Em ambientes enterprise, cada deployment deveria possuir identidade verificável emitida pela infraestrutura. SPIFFE/SPIRE, cloud workload identity, service accounts ou certificados mTLS são exemplos possíveis. O ponto essencial é desacoplar identidade operacional de secrets estáticos distribuídos em arquivos de configuração.
Quando um agente atua em nome de um usuário, surge delegated authorization. A identidade da workload e a identidade do principal humano são dimensões distintas. Logs e policy decisions precisam preservar ambas.
Token exchange pode ser utilizado para gerar credenciais específicas para o agente downstream, com audience e scopes restritos. Isso evita propagar o token original por toda a cadeia.
A2A também inclui um estado específico para situações em que uma Task requer autorização adicional. A especificação ressalta que entrar em TASK_STATE_AUTH_REQUIRED não constitui, por si só, autorização para executar qualquer operação. A semântica e o escopo da autorização continuam responsabilidade da implementação ou de extensões apropriadas.
Esse detalhe é arquiteturalmente importante. Protocol state e authorization decision não são a mesma coisa.
Identity propagation também precisa resistir a spoofing. Metadata enviada por um caller não deveria ser aceita como identidade sem validação criptográfica.
Para auditoria, cada hop deveria registrar workload principal, delegated principal, target capability e authorization decision.
Uma plataforma A2A segura consegue responder posteriormente não apenas “qual agente executou essa ação?”, mas também “quem a iniciou, qual delegation chain foi utilizada e qual policy permitiu cada transição de autoridade?”.
4.2. Least privilege por capability, task e contexto de execução
Least privilege em sistemas agentic precisa ser mais granular do que autorização por serviço. Permitir que um agente “acesse o CRM” pode significar ler perfis, alterar dados, exportar listas ou iniciar campanhas. Esses privilégios possuem riscos completamente diferentes.
Capabilities são uma boundary natural para autorização. Uma identidade pode ter permissão para invoke customer-summary, mas não customer-delete. Entretanto, mesmo capability-level authorization pode ser insuficiente quando a ação depende do contexto.
Attribute-based access control permite incorporar tenant, data classification, region, user role, task purpose e risk level à decisão. Policy engines como OPA ou mecanismos equivalentes podem avaliar esses atributos determinísticamente antes da execução.
Task-scoped credentials elevam o isolamento. Em vez de fornecer token reutilizável durante horas, o orchestrator emite uma credencial válida apenas para determinada operação e janela temporal.
Isso reduz o impacto de prompt injection e credential leakage.
Outro princípio relevante é separar read capabilities de write capabilities. Agentes que fazem retrieval para raciocínio não precisam necessariamente possuir autoridade para executar mudanças. Action agents podem exigir aprovação humana ou policy checks adicionais.
O mesmo vale para datasets. Um agente que processa informação agregada não deveria receber registros individuais apenas porque tecnicamente consegue consumi-los.
Least privilege também reduz custo de compliance. Quanto menor o conjunto de dados e sistemas acessíveis, menor o blast radius de falhas e incidentes.
No desenho de uma AI platform, permissões deveriam ser declaradas junto ao contrato da capability e avaliadas durante deployment.
O objetivo é tornar autoridade explícita e inspecionável.
Agentes são componentes probabilísticos; sua liberdade cognitiva pode ser ampla. Sua liberdade operacional, porém, deve ser estritamente delimitada por controles determinísticos externos ao modelo.
4.3. Trust boundaries, zero trust e comunicação entre organizações
A2A torna particularmente interessante a colaboração entre agentes pertencentes a organizações diferentes. Esse cenário maximiza o valor da interoperabilidade e, simultaneamente, elimina várias suposições de confiança existentes dentro de uma única empresa.
Zero trust fornece um modelo adequado: nenhuma requisição é confiável apenas porque veio de determinada rede. Identidade, autorização, integridade e contexto precisam ser verificados a cada boundary relevante.
Agent Cards públicos também exigem cuidado. Eles devem divulgar informação suficiente para discovery sem expor detalhes internos que auxiliem reconhecimento de infraestrutura. Extended Agent Cards autenticados são uma alternativa para capabilities que só deveriam ser visíveis após autenticação. A especificação A2A prevê esse tipo de descoberta controlada.
Cross-organization communication também exige contratos de dados. Uma organização precisa conhecer finalidade, retenção, residency e tratamento aplicado aos artifacts enviados ao peer.
Encryption in transit é condição básica, não solução completa. Dados podem ser legitimamente recebidos e depois utilizados de maneira incompatível com a política original.
Outro problema é provenance. Se um agente externo produz um artifact posteriormente utilizado em decisão importante, a organização precisa preservar origem, versão, timestamp e, idealmente, evidências que permitam avaliação.
Rate limits e quotas por partner evitam que um peer comprometido cause resource exhaustion.
Circuit breakers podem isolar uma integração cujo comportamento começou a degradar.
Para workloads altamente sensíveis, trust tiers são úteis. Agentes internos, partners verificados e serviços públicos podem receber conjuntos diferentes de capabilities e dados.
A arquitetura resultante não presume confiança global. Ela constrói pequenos canais explicitamente autorizados entre domínios.
Essa abordagem permite interoperabilidade real sem converter abertura protocolar em abertura irrestrita de superfície operacional.
4.4. Prompt injection indireta, confused deputy, data exfiltration e policy enforcement
A comunicação A2A cria um canal adicional para indirect prompt injection. Um agente confiável pode receber conteúdo malicioso de uma fonte externa e repassá-lo como Artifact para outro agente. O transporte é autenticado, mas o conteúdo continua potencialmente hostil.
Esse problema exige abandonar a premissa de que mensagens produzidas por agentes parceiros são instructions confiáveis. Conteúdo deve ser classificado conforme sua origem e função. Dados recuperados, mensagens de usuário, instructions de sistema e outputs de peers precisam permanecer semanticamente separados.
O confused deputy problem também se torna relevante. Um agente com alto privilégio pode ser induzido por um agente menos privilegiado a executar uma operação que o caller não poderia realizar diretamente.
Authorization precisa, portanto, considerar o initiating principal, não apenas a identidade do último hop.
Data exfiltration pode ocorrer por outputs aparentemente legítimos. Um agente instruído a resumir documentos pode inserir informações sensíveis em campos livres enviados posteriormente a outro domínio.
DLP, output validation e policy-aware redaction deveriam existir antes da boundary externa.
Tool execution requer proteção ainda maior. O modelo pode escolher uma ação, mas argumentos precisam ser validados contra schemas, allowlists e business rules determinísticas.
Policy enforcement também deveria ocorrer em múltiplos pontos. Pre-execution policies controlam autorização. Runtime policies limitam tokens, tools e destinations. Post-execution policies analisam artifacts antes de publicação.
Nenhuma dessas responsabilidades deveria depender exclusivamente do prompt.
Esse desenho pode parecer restritivo, mas aumenta autonomia segura: dentro dos limites permitidos, o agente continua capaz de planejar e adaptar sua execução.
O princípio é separar inteligência de autoridade. Modelos podem recomendar ações; policy engines decidem quais ações o sistema está autorizado a realizar. Essa separação é uma das foundations mais importantes para AI Engineering em produção.
5. Reliability Engineering: operando A2A como um sistema distribuído de produção
Quando múltiplos agentes independentes começam a colaborar, problemas familiares de distributed systems retornam com uma camada probabilística adicional. Network partitions, retries, rate limits e partial failures continuam existindo, mas agora cada hop pode também produzir variabilidade semântica.
Reliability Engineering para A2A precisa tratar disponibilidade técnica e qualidade cognitiva como dimensões diferentes. Um agente pode retornar HTTP 200 e ainda produzir um resultado inutilizável. Da mesma forma, pode produzir excelente resposta depois do deadline e, portanto, falhar do ponto de vista do produto.
SLOs precisam refletir essa multidimensionalidade. Availability mede se a capability respondeu. Task success mede conclusão operacional. Semantic success mede qualidade suficiente. Latency e cost completam a visão.
Outro princípio é limitar profundidade de dependências. Se um agente possui cinco downstream dependencies e cada uma possui outras cinco, reliability composta deteriora rapidamente. A topologia deveria ser observável e submetida a dependency budgets.
Isolation também é essencial. Um agente lento não deveria consumir todos os workers do orchestrator. Bulkheads, concurrency limits e queues protegem componentes saudáveis.
Retry storms são particularmente perigosos porque inferência é cara. Uma falha de provider pode fazer centenas de agentes repetirem chamadas simultaneamente.
Plataformas maduras tratam agentes como workloads de produção, não como scripts sofisticados. Isso implica readiness checks, capacity planning, graceful degradation, incident response e postmortems.
O componente probabilístico não elimina práticas tradicionais de SRE. Ele torna essas práticas ainda mais necessárias.
A arquitetura deveria concentrar criatividade dentro dos agentes e previsibilidade ao redor deles. Quando failure handling depende da capacidade do próprio LLM de improvisar, a plataforma deixou de ser confiável.
5.1. Agent gateways, registries, routing e control plane versus data plane
Uma plataforma A2A de escala tende a precisar de uma separação clara entre control plane e data plane. Sem ela, discovery, policy, routing e execução ficam espalhados pelos agentes, tornando mudanças organizacionais extremamente difíceis.
O control plane administra registration, Agent Cards, ownership, policy bundles, versions, quotas e deployment metadata. Ele responde quais agents existem e sob quais condições podem operar.
O data plane transporta mensagens, tasks e artifacts efetivamente executados. Seu caminho crítico deve ser mínimo porque cada componente adicional aumenta latency e failure surface.
Um agent gateway pode funcionar como enforcement point para authentication, authorization, rate limiting e telemetry. Entretanto, colocar raciocínio complexo no gateway cria bottleneck e coupling. O gateway deveria executar políticas determinísticas e delegar semantic routing para componentes específicos quando necessário.
Registries também podem armazenar health e deployment information além de metadados estáticos de discovery.
Routing pode ocorrer em vários níveis. Static routing resolve capabilities conhecidas. Policy-based routing escolhe por região, tenant ou compliance. Semantic routing utiliza significado do pedido para selecionar candidatos. Cost-aware routing considera preço e latency.
Essas decisões não precisam estar no mesmo componente.
Uma arquitetura robusta também evita que cada agente implemente client libraries diferentes para todos os peers. Um SDK padronizado pode encapsular tracing, deadlines, retries e authentication.
No entanto, shared libraries precisam permanecer finas. Colocar business semantics em uma biblioteca central transforma autonomia em distributed monolith.
A distinção control plane versus data plane também melhora incident response. É possível desabilitar determinada capability, retirar uma versão ou alterar routing sem redeploy de todos os consumidores.
Em escala, essa capacidade operacional costuma ser mais importante do que qualquer mecanismo sofisticado de agent reasoning.
5.2. Backpressure, admission control, circuit breakers e isolamento de falhas
Agentes podem gerar carga muito mais irregular do que serviços convencionais. Uma única Task pode disparar centenas de tool calls ou subtasks. Portanto, medir apenas requests per second é insuficiente para capacity planning.
Work units precisam considerar tokens, estimated inference time, fan-out e downstream complexity. Admission control pode rejeitar ou enfileirar tasks quando o sistema não possui capacidade para executá-las dentro do SLO.
Backpressure deve se propagar upstream. Se um downstream agent está saturado, o orchestrator não deveria continuar criando tasks ilimitadamente. Queue limits, concurrency semaphores e bounded buffers transformam saturação em comportamento previsível.
Circuit breakers protegem contra dependências degradadas. Entretanto, thresholds baseados apenas em HTTP failures podem ser insuficientes. Semantic failures, extreme latency ou model-provider throttling também podem indicar necessidade de abrir o circuito.
Bulkheads isolam classes de workload. Tasks batch não deveriam competir diretamente com interações online de baixa latência. Tenants críticos podem possuir capacity reservations específicas.
Load shedding também é legítimo. Recusar uma tarefa cedo costuma ser melhor do que aceitá-la e falhar após consumir tokens por vários minutos.
Fallbacks precisam ser cuidadosamente avaliados. Trocar automaticamente um reasoning model por um modelo menor pode preservar disponibilidade técnica enquanto destrói qualidade. Fallback deveria ser tratado como mudança de service level, não como implementação invisível.
Uma AI platform madura conhece suas degradation modes. Pode reduzir context window, desativar optional enrichment ou retornar partial results mantendo invariantes críticas.
Resiliência não é fazer todo trabalho a qualquer custo. É preservar as propriedades mais importantes do sistema sob condições adversas.
Em A2A, essa disciplina impede que autonomia local gere cascades globais de falhas e custo.
5.3. Observabilidade causal: traces distribuídos, correlation IDs e lineage entre agentes
Logs isolados são insuficientes para depurar sistemas A2A. Uma resposta final pode depender de múltiplos agentes, cada um realizando retrieval, inference e tool execution. Sem causal lineage, investigar uma regressão torna-se arqueologia distribuída.
Distributed tracing deveria começar no primeiro request e propagar trace context por todas as delegações. Cada Task pode gerar spans para inference, retrieval, tools e downstream A2A calls.
Correlation IDs ajudam busca operacional, mas traces estruturados são superiores porque preservam relações parent-child e timing.
Além de métricas tradicionais, cada span agentic deveria registrar model, model version, prompt version, token usage, capability version, policy decisions e evaluation signals relevantes. Dados sensíveis precisam ser redigidos ou referenciados por identificadores seguros.
Artifact lineage também importa. Um resultado deveria ser rastreável às evidências e agents que contribuíram para sua criação.
Essa capacidade transforma debugging em análise causal. Se uma resposta degradou, é possível verificar se a origem foi retrieval ruim, downstream timeout, modelo diferente ou mudança em um semantic contract.
High-cardinality telemetry é inevitável. Task IDs, agent IDs e model versions produzem cardinalidade elevada, portanto a observability platform precisa ser desenhada para isso.
Sampling requer cuidado. Traces de erros devem ser retidos com taxa maior do que execuções normais. Exemplos semanticamente anômalos também podem merecer retenção.
Cost attribution pode aproveitar o mesmo trace. Somando tokens, inference e chamadas externas por árvore causal, a organização identifica quais capabilities realmente consomem orçamento.
Em AI Engineering, observabilidade precisa explicar comportamento, não apenas infraestrutura.
Uma dashboard mostrando CPU saudável enquanto o sistema produz decisões incorretas não representa observabilidade adequada. A unidade de investigação deve ser a trajetória completa da Task.
5.4. SLOs compostos: disponibilidade, latência e failure budgets em cadeias agentic
SLOs de agentes não deveriam ser definidos apenas como percentual de requests com HTTP 200. Essa métrica ignora o componente que realmente importa: se o trabalho foi concluído com qualidade suficiente, dentro do tempo e custo esperados.
Uma capability pode possuir quatro SLO dimensions. Operational availability mede se o serviço aceita e processa tasks. Completion latency mede duração end-to-end. Semantic success mede qualidade contra critérios definidos. Cost SLO limita consumo econômico por execução ou unidade de negócio.
Quando agents são encadeados, esses indicadores se compõem. Se cinco dependências independentes possuem disponibilidade de 99%, a disponibilidade teórica do caminho completo já fica substancialmente abaixo de 99%.
Por isso, dependency depth precisa ser tratada como budget arquitetural.
Latency também se acumula. Parallelism reduz caminho crítico, mas pode elevar custo e contention. Sequential reasoning aumenta capacidade de adaptação, porém amplia tail latency.
Error budgets fornecem mecanismo útil para governança. Se uma capability está consumindo budget rapidamente, mudanças de modelo ou novas features podem ser congeladas até recuperação de confiabilidade.
Semantic error budgets são particularmente interessantes. Um regression suite contínuo pode estimar taxa de respostas abaixo do quality threshold e tratá-la como sinal operacional.
SLOs também precisam diferenciar workload classes. Uma pesquisa assíncrona de quinze minutos e uma recomendação online de 500 ms não deveriam compartilhar o mesmo target.
O objetivo não é criar dezenas de métricas sem utilidade. É conectar arquitetura a expectativas mensuráveis.
Um Staff Engineer deveria conseguir responder: quantos hops essa jornada tolera, qual latency budget cada um recebe, qual failure rate é aceitável e quanto custa manter esse nível de serviço?
Sem essas respostas, “multi-agent scalability” permanece uma abstração, não uma propriedade operacional.
6. Evaluation Engineering: medindo interoperabilidade além de task success
Avaliar um agente isolado já é difícil. Avaliar uma rede de agentes exige separar erros locais de erros emergentes produzidos pela composição. Uma Task pode terminar com status completed e ainda entregar resultado semanticamente incorreto. Portanto, completion não deveria ser tratado como sinônimo de sucesso.
Evaluation Engineering em A2A precisa operar em múltiplas camadas. Protocol conformance verifica aderência estrutural. Contract evaluation testa invariantes semânticas. Component evaluation mede cada agente separadamente. End-to-end evaluation mede o resultado composto. Trajectory evaluation analisa como o sistema chegou à resposta.
Essa decomposição é importante para attribution. Se o resultado final está errado porque um retrieval agent forneceu documento incorreto, penalizar igualmente o synthesis agent esconde a causa verdadeira.
Evaluation datasets também precisam refletir production distributions. Benchmarks acadêmicos ajudam comparação de modelos, mas raramente representam tenants, idiomas, documents ou edge cases reais da plataforma.
Uma estratégia madura combina curated golden sets, sampled production traces, adversarial cases e synthetic generation.
Judge models podem escalar avaliação, porém precisam ser calibrados contra critérios humanos e não deveriam ser considerados ground truth absoluto.
Também é necessário avaliar comportamento operacional. Um agente pode obter excelente qualidade usando vinte chamadas onde três seriam suficientes. Efficiency faz parte da avaliação.
Evaluation results precisam participar de deployment gates. Uma mudança de model, prompt ou retrieval deveria executar regression suites antes de receber tráfego.
Em plataformas maduras, avaliação deixa de ser atividade de pesquisa realizada antes do lançamento. Torna-se parte permanente do runtime e do software delivery lifecycle.
Essa mudança é fundamental para transformar sistemas probabilísticos em sistemas operáveis.
6.1. Contract conformance, protocol compliance e testes de compatibilidade entre implementações
O primeiro nível de evaluation em A2A é determinístico: verificar se uma implementação realmente obedece ao protocolo e ao contrato publicado. Essa camada deve falhar rapidamente antes que qualquer avaliação com LLM seja necessária.
Protocol conformance testa serialization, required fields, task state transitions, error mappings, streaming behavior e capability declaration. Como A2A 1.0 suporta múltiplos bindings mantendo equivalência funcional, implementações multi-protocol também precisam demonstrar comportamento semanticamente consistente entre JSON-RPC, gRPC e HTTP+JSON.
Contract tests atuam acima disso. Se uma capability promete output application/json seguindo determinado schema, exemplos inválidos precisam ser rejeitados. Se uma operação não suporta determinado media type, o erro correto deve aparecer.
Consumer-driven tests são especialmente úteis porque capturam aquilo de que consumidores realmente dependem.
Entretanto, interoperabilidade não deveria ser validada apenas contra o SDK utilizado pela própria equipe. Cross-implementation testing é mais valioso. Um server Python deve funcionar com clients Java, Go ou implementações independentes.
Test matrices precisam incluir diferentes protocol versions, optional capabilities e extensions relevantes. Isso evita que uma combinação raramente utilizada permaneça quebrada durante meses.
Fuzzing ajuda a testar malformed payloads, unexpected ordering e boundary values.
Também é importante verificar negative contracts: aquilo que o agente explicitamente não permite. Por exemplo, mensagens enviadas para Tasks terminais deveriam ser tratadas de maneira consistente.
Esses testes parecem convencionais porque são. Essa é justamente sua força.
Nem tudo em AI Engineering precisa ser probabilístico. Quanto mais comportamento puder ser capturado por invariantes determinísticas, menor será a superfície restante para evaluation baseada em modelos.
A2A interoperability começa com protocolo correto. Só depois vale discutir inteligência.
6.2. Avaliação end-to-end versus atribuição de erro por agente, hop e capability
End-to-end evaluation responde se o produto final funciona. Component evaluation responde por que ele funciona ou falha. Uma plataforma precisa das duas.
Considere uma jornada na qual um planning agent delega pesquisa a três especialistas e depois envia artifacts para um synthesis agent. Se o resultado final está incorreto, várias causas são possíveis: planejamento inadequado, seleção errada de capability, retrieval ruim, artifact truncation, síntese incorreta ou conflito entre evidências.
Um único score final não oferece actionable insight.
A solução é construir evaluation spans alinhados ao distributed trace. Cada capability registra inputs normalizados, outputs, latency, cost e evaluations locais. O sistema final recebe evaluation adicional sobre a tarefa completa.
Essa estrutura permite blame attribution probabilística. Não é necessário assumir que existe uma causa única, mas é possível identificar quais hops apresentaram sinais de degradação.
Counterfactual evaluation ajuda ainda mais. Reexecutar apenas um componente com output corrigido permite observar se o resultado final melhora. Isso estima causal contribution de determinado agente.
Shadow execution também pode comparar versões sem impactar usuários. O mesmo input passa pela implementação atual e candidata; diferenças são avaliadas offline.
É importante não otimizar todos os componentes isoladamente. Um agente localmente melhor pode produzir artifacts mais longos e prejudicar latency ou context consumption downstream.
Portanto, existe tensão entre local optimum e system optimum.
Staff Engineers deveriam definir evaluation hierarchy: invariantes obrigatórios, quality metrics locais e business metrics globais.
A finalidade da avaliação não é produzir dashboards com muitos scores. É fornecer informação suficiente para decidir onde investir engenharia.
Em sistemas multi-agent, observability mostra onde a execução passou. Evaluation mostra onde a qualidade se perdeu. Integrar as duas transforma debugging em engineering disciplinado.
6.3. Semantic correctness, trajectory evaluation e avaliação de artefatos intermediários
Avaliar apenas a resposta final perde informação importante sobre como um sistema agentic opera. Dois workflows podem produzir a mesma resposta correta, mas um deles utilizar fontes inválidas, executar ferramentas desnecessárias ou depender de reasoning frágil. Trajectory evaluation captura essa diferença.
Uma trajetória pode ser avaliada em termos de capability selection, tool choice, evidence quality, number of hops, loops, policy compliance e efficiency. O objetivo não é exigir um reasoning path específico, mas identificar propriedades indesejáveis do processo.
Artifacts intermediários são especialmente valiosos porque representam boundaries naturais. Um research agent pode produzir evidence package; um ranking agent pode produzir ordered candidates; um policy agent pode produzir decision constraints.
Cada artifact deveria possuir critérios próprios de qualidade.
Isso melhora debugging e reduz dependência de opaque chain-of-thought. A plataforma não precisa armazenar raciocínio privado do modelo para entender a execução. Ela precisa armazenar decisões observáveis e outputs estruturados.
Semantic correctness pode ser avaliada por regras determinísticas quando possível. Citation validity, numeric consistency e schema invariants não exigem LLM judge.
Questões subjetivas podem utilizar rubric-based evaluators. Critérios explícitos são melhores do que prompts vagos pedindo uma nota geral.
Pairwise evaluation também costuma produzir maior estabilidade do que absolute scoring quando o objetivo é comparar duas versões.
Para decisões críticas, human review permanece necessário para calibrar evaluators e explorar failure modes desconhecidos.
Uma preocupação adicional é evaluator contamination. Se generator e judge utilizam modelos muito semelhantes, podem compartilhar vieses.
Evaluation architecture deveria permitir múltiplos judges, regras e humans conforme criticidade.
O objetivo final é transformar qualidade semântica em propriedade observável. Quando outputs intermediários são contratos avaliáveis, a rede de agentes deixa de parecer uma única caixa-preta gigante.
6.4. Chaos testing, adversarial evaluation e regressões em redes de agentes
Chaos Engineering também se aplica a sistemas agentic, mas os experimentos precisam considerar falhas semânticas além de falhas de infraestrutura. Derrubar um serviço continua útil; fornecer um Artifact plausível porém incorreto pode ser ainda mais revelador.
Experimentos podem introduzir latency artificial em determinado peer, respostas duplicadas, stream interruption, stale Agent Cards, malformed artifacts ou rate limits. O objetivo é observar se deadlines, retries e degradation policies funcionam conforme esperado.
Adversarial evaluation explora outra dimensão. Um peer pode enviar prompt injection, conteúdo contraditório, data exfiltration attempts ou metadados manipulados.
O sistema deveria demonstrar que trust boundary permanece intacta mesmo quando a mensagem chega por conexão autenticada.
Também vale testar semantic drift. Uma versão nova pode continuar respondendo corretamente a exemplos comuns e falhar apenas em segmentos específicos. Regression suites precisam incluir slices por idioma, tenant, complexity e business scenario.
Fault injection em fan-out workflows é especialmente importante. Se um entre dez agentes falha, o orchestrator faz partial completion, retry ou abort? A decisão deveria corresponder ao contrato.
Load chaos também revela problemas. Aumentar simultaneamente fan-out e inference latency pode produzir queue buildup não observado em testes unitários.
Chaos experiments devem ser instrumentados com hypotheses. “Desligar coisas para ver o que acontece” não é engenharia.
Uma hypothesis útil poderia ser: se um research agent ultrapassar seu deadline, o parent cancela children restantes, retorna resultado parcial marcado e não excede cost budget.
O teste então verifica essas invariantes.
Para Staff/Principal Engineers, a pergunta relevante não é se cada agente funciona quando tudo está saudável. É se a plataforma preserva propriedades essenciais quando múltiplas premissas falham simultaneamente.
7. Economics e arquitetura evolutiva: quando A2A cria valor e quando adiciona complexidade
Toda abstração distribuída possui custo. A2A adiciona network hops, serialization, authentication, tracing, state management e governance. Quando esses custos não compram autonomia real, a arquitetura ficou mais sofisticada sem ficar melhor.
Economics deveria participar do design desde o início. Em agentes, custo não é apenas infraestrutura. Tokens, model inference, embeddings, retrieval, reranking, observability, storage e external APIs compõem o custo marginal de cada Task.
Multi-agent systems podem multiplicá-lo silenciosamente. Um planner cria cinco subtasks; cada subtask faz três model calls; duas sofrem retry. Uma única interação aparentemente simples passa a executar dezenas de inferências.
Cost observability precisa acompanhar a árvore causal. O sistema deveria calcular cost per capability, tenant, product feature e successful outcome.
Essa última dimensão é particularmente importante. Cost per request pode parecer aceitável enquanto cost per correct outcome é alto devido a retries ou semantic failures.
Arquitetura evolutiva também significa preservar opções. Adotar A2A não deveria obrigar todas as equipes a utilizar o mesmo model provider, framework ou cloud.
Ao mesmo tempo, flexibilidade excessiva possui custo operacional. Cada nova combinação de runtime e binding amplia a test matrix.
O papel de platform engineering é encontrar o ponto de padronização que reduz toil sem destruir autonomia.
A pergunta correta não é “podemos transformar isso em agentes interoperáveis?”. Quase sempre podemos.
A pergunta é “qual valor econômico ou organizacional recebemos em troca da nova boundary distribuída?”.
Quando a resposta envolve cross-team autonomy, independent scaling, cross-vendor integration ou trust isolation, A2A pode ser altamente justificável.
Quando envolve apenas modularidade de código dentro do mesmo serviço, funções ou workflows internos provavelmente continuam sendo a solução superior.
7.1. O custo multiplicativo de hops: tokens, inferência, rede, retries e observabilidade
Cada A2A hop possui custo fixo e custo variável. O custo fixo inclui conexão, authentication, serialization, tracing e state handling. O custo variável depende de tokens, modelo, retrieval, tools e quantidade de trabalho realizado pelo agente remoto.
Em pipelines profundos, esses custos se multiplicam. Um detalhe frequentemente ignorado é context duplication. Se cinco agentes recebem grande parte do mesmo contexto, os mesmos milhares de tokens podem ser processados repetidamente.
Context engineering torna-se, portanto, disciplina econômica. Em vez de encaminhar conversation history completa, o parent deveria fornecer apenas informações necessárias para a capability downstream.
Artifacts estruturados são úteis porque comprimem significado. Um evidence package com campos bem definidos pode substituir páginas de texto livre.
Caching também possui papel importante, mas precisa respeitar semantic validity. Outputs probabilísticos não deveriam ser cacheados apenas por igualdade textual do prompt. Cache keys podem incluir capability version, model version, tenant e data snapshot.
Retries são outra fonte de multiplicação. Telemetry deveria distinguir original inference de retry inference para tornar waste visível.
Observabilidade tem custo próprio. Armazenar prompts completos, artifacts e traces por meses pode superar custo de algumas inferências. Sampling e retention policies precisam ser planejados.
Existe também engineering cost. Cada novo agente exige deployment, security review, evaluation suites e incident ownership.
Por isso, cost model deveria existir antes da expansão da arquitetura. Estime fan-out esperado, average tokens, tail retries e volume.
Otimizações depois do lançamento tendem a ser mais difíceis porque contracts e topologias já estão consolidados.
A melhor arquitetura agentic não maximiza reasoning calls. Ela maximiza valor produzido por unidade de inferência, latência e complexidade operacional.
7.2. Latency budgets, quality budgets e cost budgets como restrições arquiteturais
Arquitetura melhora quando restrições são explícitas. “Queremos alta qualidade, baixa latência e baixo custo” não é uma especificação porque todos querem isso. Engineering começa quando números ou classes de serviço são definidos.
Uma Task online pode receber latency budget de dois segundos e cost budget de alguns centavos. Uma análise assíncrona pode tolerar minutos e orçamento maior. Esses dois workloads não deveriam utilizar a mesma orchestration strategy.
Budgets precisam ser hierárquicos. O parent recebe budget global e distribui frações para child agents. Um planner não deveria criar mais subtasks do que o orçamento permite.
Quality budget representa o nível mínimo de qualidade aceitável. Quando tempo está terminando, o sistema pode escolher modelo mais rápido apenas se isso preservar esse threshold.
Essa relação cria um optimization problem multidimensional. Em muitos casos, Pareto frontiers são mais úteis do que buscar uma única configuração “melhor”.
Routing adaptativo pode considerar essas dimensões. Tasks simples utilizam modelos menores; tasks complexas escalam para reasoning models. Entretanto, classifier error também deve entrar no evaluation.
Budget enforcement deveria ocorrer deterministicamente. Esperar que o LLM “lembre de gastar pouco” é controle insuficiente.
Outro aspecto importante é tail behavior. P50 latency pode parecer excelente enquanto P99 inviabiliza experiência. Fan-out aumenta probabilidade de algum child cair na cauda.
Timeout hedging pode reduzir tail latency, mas aumenta custo porque duplica trabalho. A decisão precisa ser econômica.
Staff Engineers deveriam tratar budgets como API constraints propagadas pelo grafo de execução.
Essa abordagem força decisões arquiteturais concretas: quantos hops são permitidos, quais operações podem rodar em paralelo e quando partial results são preferíveis.
Sem budgets, a autonomia dos agentes tende naturalmente a consumir todos os recursos disponíveis.
7.3. Build versus buy: interoperabilidade aberta, gateways proprietários e risco de lock-in
A decisão build versus buy em infraestrutura agentic precisa ser decomposta por camada. Implementar o protocolo A2A não significa necessariamente construir registry, gateway, observability, policy engine e evaluation platform internamente.
A camada de interoperabilidade tende a se beneficiar de padrões abertos porque interfaces compartilhadas reduzem switching cost. Já componentes operacionais podem ser adquiridos se fornecerem vantagem suficiente sem capturar semantic contracts proprietários.
O principal risco de lock-in aparece quando business capabilities passam a depender de primitives exclusivas de determinado orchestrator ou provider. Migrar deixa de significar trocar infraestrutura e passa a exigir reescrever contratos.
Uma estratégia saudável mantém domain contracts independentes da plataforma. Agent Cards, schemas e task semantics pertencem à organização. Adapters traduzem esses conceitos para produtos específicos quando necessário.
Entretanto, abstração total também possui custo. Tentar criar uma interface universal que esconda todas as diferenças entre vendors frequentemente produz lowest-common-denominator architecture.
A escolha deveria preservar aquilo que realmente precisa ser portátil: identidade de capabilities, data contracts, evaluation datasets e observability semantics.
Managed gateways podem reduzir operational burden em autenticação, scaling e routing. Self-hosting aumenta controle e pode ser necessário para workloads regulados.
Total cost of ownership precisa incluir equipe, incident response e upgrades, não apenas invoice de cloud.
Outro critério é exit cost. Antes de adotar componente estratégico, estime o esforço necessário para substituí-lo.
Em AI Engineering, modelos e frameworks mudam rapidamente. Architectural leverage vem da capacidade de manter business semantics estáveis enquanto infraestrutura evolui.
Protocolos abertos ajudam nisso, mas não eliminam lock-in automaticamente. O verdadeiro lock-in acontece onde dados, contratos, evaluations e operações tornam-se inseparáveis de uma implementação específica.
7.4. Critérios para adoção: quando usar A2A, quando manter chamadas diretas e quando redesenhar o boundary
A decisão de usar A2A deveria começar pelo boundary, não pelo entusiasmo com multi-agent systems. Existem sinais claros de que a abstração é apropriada.
O primeiro é ownership independente. Quando duas equipes precisam deploy e evolução autônomos, um contrato estável reduz coordenação. O segundo é heterogeneidade tecnológica real: runtimes, linguagens ou providers distintos precisam colaborar. O terceiro é trust separation, especialmente em integração entre organizações. O quarto é long-running collaboration na qual Task semantics oferecem valor superior a uma API síncrona convencional.
Por outro lado, se dois componentes vivem no mesmo processo, compartilham release cycle e precisam conversar dezenas de vezes por request, A2A provavelmente está sendo utilizado cedo demais.
Chamadas diretas continuam adequadas para operações determinísticas. Workflows internos são melhores para sequências controladas dentro do mesmo domínio. Event streaming é superior quando desacoplamento temporal em alto volume é o requisito principal.
Também é importante redesenhar boundaries quando uma integração fica excessivamente chatty. Se agentes precisam trocar vinte mensagens para concluir uma tarefa simples, talvez a capability pública esteja granular demais.
Outra red flag é semantic leakage. Se consumidores precisam conhecer prompts, internal tools ou estado privado para usar corretamente o agente, a interface não está suficientemente encapsulada.
A adoção deveria ser incremental. Comece por boundaries que já possuem independência organizacional e forte necessidade de interoperabilidade. Instrumente latency, cost e quality antes de expandir.
A2A não deveria ser objetivo arquitetural. Ele é um mecanismo para preservar autonomia entre sistemas que realmente precisam permanecer independentes.
O sinal de maturidade não é possuir centenas de agentes conectados. É conseguir adicionar, substituir ou retirar um deles sem desestabilizar o restante da plataforma.
Tool Engineering para AI Agents: design de contratos, avaliação e confiabilidade para consumidores…
MCP como infraestrutura de AI Engineering: design, operação e confiabilidade em ambientes…
Memory Engineering para AI Agents: arquitetura, persistência e controle semântico da memória
