Agent Tools & Interoperability

O Dia 1 estabeleceu a mudança de paradigma: do código escrito à mão para a Agentic Engineering, onde o desenvolvedor opera como um Factory Model — projetando a linha de produção, não apertando cada parafuso. A equação central daquele paper continua sendo a fundação de tudo o que vem a seguir:

O harness — o andaime de ferramentas, memória, transporte e segurança ao redor do modelo — só atinge seu potencial quando se conecta ao mundo por padrões abertos. Sem padrões, cada integração é uma peça usinada sob medida: funciona na sua garagem, quebra na primeira mudança. Com padrões, o harness vira uma plataforma modular plug-and-play.

O paper apresenta cinco protocolos como os "padrões da indústria" — as roscas e tomadas uniformes do ecossistema agêntico. Clique em cada um para explorar:

Duas peças completam o quadro: a OpenResponses & Interactions API funciona como 'Power Plugs' — abordagens modernas de API para inferência de LLM com suporte a tarefas de longa duração, borrando a fronteira entre um turno stateless e um agente stateful. E os Skills são 'Playbooks' — instruções markdown simples, com scripts ou ferramentas prontos para rodar num ambiente sandbox como um terminal.

O vibe coding removeu o atrito da escrita de código — e com ele, parte da estrutura que garantia previsibilidade. A velocidade continua sendo o motor principal, mas agora os harnesses e protocolos é que carregam o peso da confiança: eles definem contratos claros entre o agente e o mundo externo.

Sem padrões abertos, cada API vira um "padrão-de-um": um parser custom, um formato de erro custom, um fluxo de autenticação custom. O resultado é dívida técnica que se acumula silenciosamente — e uma lista de tarefas de baixo leverage que consomem o tempo do desenvolvedor:

O paper foi desenhado para engenheiros de software, engineering managers, arquitetos e líderes técnicos que reconhecem que a mudança para a Agentic Engineering exige adesão estrita a protocolos para manter fidelidade e confiabilidade dos resultados. Ele serve como guia prático para "vibe coders" que priorizam velocidade e resultado visual, mostrando como construir uma equipe virtual de dados e execução.

No enterprise tradicional, conectar um agente a uma ferramenta significa fiação bespoke: wrappers REST customizados, gestão manual de API keys, refresh de tokens OAuth, parsers JSON escritos à mão para cada formato de resposta. Cada ferramenta nova é um projeto. O MCP (Model Context Protocol) substitui esse atrito por um soquete padronizado — descubra, configure, conecte.

Toda plataforma agêntica enfrenta a mesma matemática: N modelos × M ferramentas. Na abordagem tradicional, cada par modelo-ferramenta exige uma integração bespoke — O(N×M) pontos de integração. Com 5 modelos e 10 ferramentas, são 50 integrações para manter. Se a API de uma ferramenta muda, múltiplos loops de parser quebram de uma vez.

TRADICIONAL — O(N×M): cada par precisa do seu próprio conector

  gemini ──┬── calendar   5 modelos
  claude ──┼── gmail      ×
  llama ───┼── bigquery   10 ferramentas
  gpt ─────┼── maps       = 50 integrações bespoke
  mistral ─┴── drive      (e 50 lugares para quebrar)

COM MCP — O(N+M): todos falam o mesmo protocolo

  gemini ─┐              ┌── calendar
  claude ─┤              ├── gmail
  llama ──┼── [ MCP ] ──┼── bigquery
  gpt ────┤              ├── maps
  mistral─┘              └── drive
           5 + 10 = 15 adaptadores

Com o MCP, cada modelo implementa o protocolo uma vez e cada ferramenta implementa o protocolo uma vez — o custo total cai para O(N+M), escala linear. Arraste os controles e veja a diferença explodir:

Como as definições de ferramenta são padronizadas, o MCP pode ser ligado diretamente ao harness por transportes padrão — sem camadas de integração custom. Dois transportes cobrem praticamente todos os casos. Clique em cada um:

Nos dois casos, o vibe coder ganha o mesmo superpoder: conectar ferramentas sem escrever múltiplas camadas de integração custom — o transporte é resolvido pelo protocolo, não por você.

Quando o agente alucina parâmetros, chama a ferramenta errada ou falha ao parsear um payload, o instinto é reescrever as system instructions. Resista. O problema quase sempre está no que o agente vê — e a forma correta de diagnosticar é inspecionar diretamente os canos do transporte, sem iniciar o workflow principal do agente.

Os sistemas de IA estão evoluindo de aplicações isoladas para redes distribuídas de especialistas de domínio. Nessa realidade, comunicação padronizada não é conveniência — é pré-requisito de escala. O A2A (Agent-to-Agent) é a camada fundacional que resolve a fragmentação do ecossistema: ele permite que desenvolvedores descubram, orquestrem e monetizem uma força de trabalho virtual globalmente interoperável.

A evolução das arquiteturas agênticas

Há um padrão recorrente na história da computação: o manual e de baixo nível dá lugar ao declarativo e baseado em intenção. O usuário diz O QUÊ, não COMO. Essa trajetória se repetiu três vezes — e agora acontece com os agentes:

"One way we hope to make AI more accessible is by simplifying the creation of machine learning models called neural networks. Today, designing neural nets is extremely time intensive... That's why we've created an approach called AutoML, showing that it's possible for neural nets to design neural nets. We hope AutoML will take an ability that a few PhDs have today …."

O vibe coding inicial produz naturalmente o Single Agent Monolith: um "canivete suíço" com um prompt sofisticado, um agente vestindo múltiplos chapéus e dezenas de ferramentas. Dá para prototipar num fim de semana — mas ele logo bate no Teto Monolítico:

A solução segue a planta baixa que engenheiros de ML e de software já conhecem. O AutoML provou seu valor de negócio e depois foi decomposto em estágios observáveis — versionamento de dados, feature stores, detecção de drift. O mesmo acontece com o agente monolítico: especialização é o mecanismo de escala.

Redução do espaço de busca: restringir as ferramentas de cada sub-agente reduz erros e alucinações. Mitigação da diluição de atenção: um prompt de domínio único produz raciocínio mais nítido. Otimização da carga contextual: o orchestrator roteia a tarefa e cada sub-agente recebe contexto com alta razão sinal-ruído.

O ecossistema está migrando para arquiteturas multi-agente distribuídas: líderes da indústria (Google, Salesforce, ServiceNow, Workday) já publicam agentes de domínio específicos. O orchestrator delega através de fronteiras de rede — não mais dentro de um único processo.

O mundo real tem estruturas de dados ambíguas, requisitos enganosos e preferências de usuário conflitantes — o "equivalente digital de paredes tortas". Raramente é possível especificar todos os detalhes sem clarificação multi-turno. É essa necessidade de negociar, pausar e retomar que separa um agente de uma API.

O domínio de um agente é unbounded. Forçá-lo dentro de um wrapper de ferramenta síncrona equivale a ressuscitar o GOTO: o fluxo de controle abandona o contexto estruturado esperado e pode qualquer coisa — atingir um estado interrompido, pedir mais informação, nunca retornar o output esperado, ou ser abandonado quando o usuário muda de ideia no meio do caminho.

Precisamos de um paradigma que isole o estado multi-turno bagunçado — um protocolo que permita pausar a execução → voltar ao Orchestrator → negociar → retomar sem perder o estado conversacional. O A2A preenche exatamente essa lacuna. Ao isolar o roteamento colaborativo na camada A2A, a camada de ferramentas (MCP) permanece limpa, previsível e estritamente estruturada.

A2A + especialização são a fundação de novos marketplaces de expertise. Sem A2A, cada aplicação agêntica luta sozinha contra a complexidade crescente. Com A2A, um desenvolvedor pode focar num nicho de alto valor — por exemplo, "Conformidade Regulatória em Tempo Real" — e ter seu especialista descoberto e "contratado" por orchestrators do mundo inteiro.

O núcleo do A2A é o backbone de transporte e negociação. Aplicações transacionais ricas exigem capacidades de ordem superior — e o framework de A2A Extensions as padroniza: anunciar, negociar e executar funcionalidades opcionais. Três frameworks fundacionais vivem como extensões nativas:

Monetizando agentes A2A — o modelo Agent-as-a-Service

Seguindo o paradigma do SaaS, o AaaS é um modelo baseado em consumo, vendido por vários canais. O Google Cloud Marketplace funciona como motor de monetização, e o Gemini Enterprise atua como plataforma agêntica — com Agent Registries e um cliente A2A nativo, sendo ao mesmo tempo plataforma AaaS (Assistant API) e hospedeiro de agentes remotos. Um modelo de preço híbrido comum: "taxa fixa com uso" — base previsível + excedentes por token/computação.

O gap de comunicação: pergunte a um colega "como foi o Q4 por região?" e ele desenha um gráfico de barras, circula os destaques e adiciona contexto. Um agente devolve JSON puro — e você constrói o gráfico sozinho: importa bibliotecas, configura eixos, gerencia estado. Essa troca de contexto quebra o fluxo do vibe coding. O A2UI muda o jogo: agentes geram UIs interativas completas como output, não apenas blobs de JSON.

Generative UI é o LLM criando interfaces dinamicamente em runtime, com base na intenção e no contexto do usuário. Em vez de hardcodar cada estado de UI, o modelo compõe a interface adequada sob demanda: "compare as vendas de Q4 por região" → o sistema monta um layout interativo com cards, filtros e controles. O desafio central é a segurança: injeção de código, XSS e efeitos colaterais descontrolados.

O agente não precisa saber o alvo (web, mobile, wearable, eletrodoméstico) — só conhece o catálogo e os exemplos. O catálogo define o que está disponível, o agente decide o arranjo, o cliente monta.

A Tabela 1 do paper lista 18 componentes prontos para uso. Em v0.8 o catálogo se chamava "standard"; em v0.9 foi renomeado para "basic" — um sinal deliberado de que, em produção, você deve trazer seu próprio catálogo: mapeie seus componentes existentes (botões, gráficos e mapas do seu design system) para os tipos A2UI. O agente não muda; só o mapeamento do renderer muda. (E ChoicePicker era MultipleChoice em v0.8.)

{
  "version": "v0.9",
  "updateComponents": {
    "surfaceId": "main",
    "components": [
      { "id": "root",         "component": "Column", "children": ["title", "summary", "export"] },
      { "id": "title",        "component": "Text",   "text": "Q4 Sales", "variant": "h1" },
      { "id": "summary",      "component": "Text",   "text": "Revenue grew 12% QoQ" },
      { "id": "export",       "component": "Button", "child": "export-label",
        "action": { "event": { "name": "export_csv" } } },
      { "id": "export-label", "component": "Text",   "text": "Export CSV" }
    ]
  }
}

Os componentes formam uma lista de adjacência plana referenciada por id — fácil para o LLM gerar incrementalmente e fácil para o cliente atualizar sem re-renderizar tudo. Uma mensagem createSurface separada informa ao cliente qual id é a raiz. O cliente monta a interface interativa completa: nenhuma linha de React necessária.

from google.adk.agents import LlmAgent
from google.adk.models import Gemini

def get_sales_dashboard(region: str) -> dict:
    """Build a data-bound sales dashboard for `region`."""
    data = fetch_sales(region)
    return {
        "version": "v0.9",
        "updateComponents": {
            "surfaceId": "sales",
            "components": [
                { "id": "root",  "component": "Column", "children": ["title", "total", "drill"] },
                { "id": "title", "component": "Text",   "text": { "path": "/title" }, "variant": "h1" },
                { "id": "total", "component": "Text",   "text": { "path": "/total" } },
                { "id": "drill", "component": "Button", "child": "drill-label",
                  "action": { "event": { "name": "expand_details" } } },
                { "id": "drill-label", "component": "Text", "text": "Drill Down" },
            ],
        },
    }

agent = LlmAgent(
    name="sales_agent",
    model=Gemini(model="gemini-flash-latest"),
    tools=[get_sales_dashboard],
)

# Conecte o conversor no setup do executor para que a resposta desta
# ferramenta vire uma parte A2UI:
#   from a2ui.adk.send_a2ui_to_client_toolset import A2uiPartConverter
#   A2aAgentExecutorConfig(event_converter=A2uiPartConverter(catalog, bypass_tool_check=True))

Os valores de dados chegam numa mensagem paralela updateDataModel que resolve referências {path: "/title"} — os clientes re-renderizam nos updates de dados sem reenviar a estrutura. E o LLM só vê a resposta estruturada da ferramenta (não a UI renderizada), então o contexto permanece focado.

O chat tradicional é linear: cada resposta é estática. O Canvas é um workspace persistente que agente e usuário editam juntos — um documento vivo onde o agente modifica seções e você edita manualmente, em tempo real. Combinado com o A2UI, a persistência encontra a interatividade: a UI não é só renderizada — é um meio de comunicação. O agente observa suas interações e responde de acordo.

Boas práticas — deixe o LLM gerar A2UI

Escrever JSON A2UI à mão é tedioso. Use o SDK oficial (pip install a2ui-agent-sdk): o A2uiSchemaManager constrói o system prompt com o schema do catálogo + exemplos trabalhados; o catálogo traz seu próprio validador JSON-Schema; o SDK fornece parser para blocos <a2ui-json> e valida e tenta de novo em erros de schema.

from a2ui_agent_sdk import A2uiSchemaManager

manager = A2uiSchemaManager(catalog="basic")
system_prompt = manager.build_prompt()   # schema + exemplos

try:
    ui = manager.parse(llm_output)        # valida o JSON
except SchemaError:
    ui = fallback_text(llm_output)        # nunca vaze payload malformado

Output híbrido para flexibilidade

Forneça dados e UI juntos — cada consumidor escolhe. Clientes de API ignoram o campo ui e usam data; clientes voltados a humanos renderizam a mensagem A2UI.

{
  "data": { "avg": 42.7, "regions": ["…"] },                                  // para APIs
  "ui":   { "version": "v0.9",
           "updateComponents": { "surfaceId": "main", "components": ["…A2UI…"] } }, // para humanos
  "ui_available": true                                                    // sinaliza a UI
}

As seções anteriores cobriram operações de "leitura" (MCP, A2A, A2UI). A evolução natural: agentes precisam executar "ações" com implicações financeiras no mundo real. Priorizar protocolos de comércio + um harness operacional robusto é o que os transforma em padrões da indústria para transações.

Características-chave e benefícios dos protocolos: typed schemas, segurança e open source — a combinação que ataca de frente a dívida de integração e garante neutralidade de vendor.