Agent Tools & Interoperability

El Día 1 estableció el cambio de paradigma: del código escrito a mano a la Agentic Engineering, donde el desarrollador opera como un Factory Model — diseñando la línea de producción, no apretando cada tornillo. La ecuación central de ese paper sigue siendo la base de todo lo que viene:

El harness — el andamiaje de herramientas, memoria, transporte y seguridad alrededor del modelo — solo alcanza su potencial cuando se conecta al mundo mediante estándares abiertos. Sin estándares, cada integración es una pieza mecanizada a medida: funciona en tu garaje, se rompe con el primer cambio. Con estándares, el harness se convierte en una plataforma modular plug-and-play.

El paper presenta cinco protocolos como los "estándares de la industria" — las roscas y tomas uniformes del ecosistema agéntico. Haz clic en cada uno para explorar:

Dos piezas más completan el cuadro: la OpenResponses & Interactions API funciona como 'Power Plugs' — enfoques modernos de API para inferencia de LLM que soportan tareas de larga duración, difuminando la frontera entre un turno stateless y un agente stateful. Y los Skills son 'Playbooks' — instrucciones markdown muy simples, con scripts o herramientas listos para ejecutarse en un entorno sandbox como una terminal.

El vibe coding eliminó la fricción de escribir código — y con ella, parte de la estructura que garantizaba previsibilidad. La velocidad sigue siendo el motor principal, pero ahora los harnesses y protocolos cargan el peso de la confianza: definen contratos claros entre el agente y el mundo externo.

Sin estándares abiertos, cada API se convierte en un "estándar-de-uno": un parser personalizado, un formato de error personalizado, un flujo de autenticación personalizado. El resultado es deuda técnica que se acumula en silencio — y una lista de tareas de bajo leverage que consumen el tiempo del desarrollador:

El paper fue diseñado para ingenieros de software, engineering managers, arquitectos y líderes técnicos que reconocen que el cambio hacia la Agentic Engineering exige adhesión estricta a protocolos para mantener fidelidad y confiabilidad de los resultados. Sirve como guía práctica para "vibe coders" que priorizan velocidad y resultado visual, mostrando cómo construir un equipo virtual de datos y ejecución.

En el enterprise tradicional, conectar un agente a una herramienta significa cableado bespoke: wrappers REST personalizados, gestión manual de API keys, refresh de tokens OAuth, parsers JSON escritos a mano para cada formato de respuesta. Cada herramienta nueva es un proyecto. El MCP (Model Context Protocol) reemplaza esa fricción con un socket estandarizado — descubre, configura, conecta.

Toda plataforma agéntica enfrenta la misma matemática: N modelos × M herramientas. En el enfoque tradicional, cada par modelo-herramienta exige una integración bespoke — O(N×M) puntos de integración. Con 5 modelos y 10 herramientas, son 50 integraciones para mantener. Si la API de una herramienta cambia, múltiples loops de parser se rompen de una 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

Con MCP, cada modelo implementa el protocolo una vez y cada herramienta implementa el protocolo una vez — el costo total cae a O(N+M), escala lineal. Arrastra los controles y observa la diferencia explotar:

Como las definiciones de herramienta están estandarizadas, el MCP puede conectarse directamente al harness mediante transportes estándar — sin capas de integración personalizadas. Dos transportes cubren prácticamente todos los casos. Haz clic en cada uno:

En ambos casos, el vibe coder gana el mismo superpoder: conectar herramientas sin escribir múltiples capas de integración personalizada — el transporte lo resuelve el protocolo, no tú.

Cuando el agente alucina parámetros, llama a la herramienta equivocada o falla al parsear un payload, el instinto es reescribir las system instructions. Resiste. El problema casi siempre está en lo que el agente ve — y la forma correcta de diagnosticarlo es inspeccionar directamente las tuberías del transporte, sin iniciar el workflow principal del agente.

Los sistemas de IA están evolucionando de aplicaciones aisladas a redes distribuidas de especialistas de dominio. En esta realidad, la comunicación estandarizada no es una comodidad — es un prerequisito de escala. A2A (Agent-to-Agent) es la capa fundacional que resuelve la fragmentación del ecosistema: permite a los desarrolladores descubrir, orquestar y monetizar una fuerza de trabajo virtual globalmente interoperable.

La evolución de las arquitecturas agénticas

Hay un patrón recurrente en la historia de la computación: lo manual y de bajo nivel da paso a lo declarativo y basado en intención. El usuario dice QUÉ, no CÓMO. Esta trayectoria se repitió tres veces — y ahora sucede con los 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 ….”

El vibe coding inicial produce naturalmente el Single Agent Monolith: una "navaja suiza" con un prompt sofisticado, un agente usando múltiples sombreros y decenas de herramientas. Se puede prototipar en un fin de semana — pero pronto choca con el Techo Monolítico:

La solución sigue el plano que los ingenieros de ML y de software ya conocen. AutoML probó su valor de negocio y luego fue descompuesto en etapas observables — versionado de datos, feature stores, detección de drift. Lo mismo sucede con el agente monolítico: la especialización es el mecanismo de escala.

Reducción del espacio de búsqueda: restringir las herramientas de cada sub-agente reduce errores y alucinaciones. Mitigación de la dilución de atención: un prompt de dominio único produce un razonamiento más nítido. Optimización de la carga contextual: el orchestrator enruta la tarea y cada sub-agente recibe contexto con una alta relación señal-ruido.

El ecosistema está migrando a arquitecturas multi-agente distribuidas: los líderes de la industria (Google, Salesforce, ServiceNow, Workday) ya publican agentes de dominio específicos. El orchestrator delega a través de fronteras de red — ya no dentro de un único proceso.

El mundo real tiene estructuras de datos ambiguas, requisitos engañosos y preferencias de usuario conflictivas — el "equivalente digital de paredes torcidas". Rara vez es posible especificar todos los detalles sin clarificación multi-turno. Es esta necesidad de negociar, pausar y retomar lo que separa a un agente de una API.

El dominio de un agente es unbounded. Forzarlo dentro de un wrapper de herramienta síncrona equivale a resucitar el GOTO: el flujo de control abandona el contexto estructurado esperado y puede cualquier cosa — alcanzar un estado interrumpido, pedir más información, nunca devolver el output esperado, o ser abandonado cuando el usuario cambia de idea a mitad de camino.

Necesitamos un paradigma que aísle el estado multi-turno desordenado — un protocolo que permita pausar la ejecución → volver al Orchestrator → negociar → retomar sin perder el estado conversacional. A2A llena exactamente ese vacío. Al aislar el enrutamiento colaborativo en la capa A2A, la capa de herramientas (MCP) permanece limpia, predecible y estrictamente estructurada.

A2A + especialización son la base de nuevos marketplaces de experiencia. Sin A2A, cada aplicación agéntica lucha sola contra la complejidad creciente. Con A2A, un desarrollador puede enfocarse en un nicho de alto valor — por ejemplo, "Cumplimiento Regulatorio en Tiempo Real" — y lograr que su especialista sea descubierto y "contratado" por orchestrators de todo el mundo.

El núcleo de A2A es el backbone de transporte y negociación. Las aplicaciones transaccionales ricas requieren capacidades de orden superior — y el framework de A2A Extensions las estandariza: anunciar, negociar y ejecutar funcionalidades opcionales. Tres frameworks fundamentales viven como extensiones nativas:

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

Siguiendo el paradigma del SaaS, el AaaS es un modelo basado en consumo, vendido por múltiples canales. Google Cloud Marketplace funciona como motor de monetización, y Gemini Enterprise actúa como plataforma agéntica — con Agent Registries y un cliente A2A nativo, siendo al mismo tiempo plataforma AaaS (Assistant API) y hospedaje de agentes remotos. Un modelo de precios híbrido común: "tarifa fija más uso" — base predecible + excedentes por token/cómputo.

La brecha de comunicación: pregúntale a un colega "¿cómo fue el Q4 por región?" y dibuja un gráfico de barras, rodea los destacados y agrega contexto. Un agente devuelve JSON puro — y tú construyes el gráfico solo: importas bibliotecas, configuras ejes, gestionas estado. Ese cambio de contexto rompe el flujo del vibe coding. A2UI cambia el juego: los agentes generan UIs interactivas completas como output, no solo blobs de JSON.

Generative UI es el LLM creando interfaces dinámicamente en tiempo de ejecución, basado en la intención y el contexto del usuario. En lugar de hardcodear cada estado de UI, el modelo compone la interfaz adecuada bajo demanda: "compara las ventas del Q4 por región" → el sistema ensambla un layout interactivo con cards, filtros y controles. El desafío central es la seguridad: inyección de código, XSS y efectos secundarios descontrolados.

El agente no necesita saber el destino (web, móvil, wearable, electrodoméstico) — solo conoce el catálogo y los ejemplos. El catálogo define lo que está disponible, el agente decide la disposición, el cliente ensambla.

La Tabla 1 del paper lista 18 componentes listos para usar. En v0.8 el catálogo se llamaba "standard"; en v0.9 fue renombrado a "basic" — una señal deliberada de que, en producción, debes traer tu propio catálogo: mapea tus componentes existentes (botones, gráficos y mapas de tu design system) a los tipos A2UI. El agente no cambia; solo cambia el mapeo del renderer. (Y ChoicePicker era MultipleChoice en 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" }
    ]
  }
}

Los componentes forman una lista de adyacencia plana referenciada por id — fácil para el LLM generar incrementalmente y fácil para el cliente actualizar sin re-renderizar todo. Un mensaje createSurface separado informa al cliente cuál id es la raíz. El cliente ensambla la interfaz interactiva completa: ninguna línea de React necesaria.

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))

Los valores de datos llegan en un mensaje paralelo updateDataModel que resuelve referencias {path: "/title"} — los clientes re-renderizan en las actualizaciones de datos sin reenviar la estructura. Y el LLM solo ve la respuesta estructurada de la herramienta (no la UI renderizada), así que el contexto permanece enfocado.

El chat tradicional es lineal: cada respuesta es estática. El Canvas es un workspace persistente que agente y usuario editan juntos — un documento vivo donde el agente modifica secciones y tú editas manualmente, en tiempo real. Combinado con A2UI, la persistencia se encuentra con la interactividad: la UI no solo se renderiza — es un medio de comunicación. El agente observa tus interacciones y responde en consecuencia.

Buenas prácticas — deja que el LLM genere A2UI

Escribir JSON A2UI a mano es tedioso. Usa el SDK oficial (pip install a2ui-agent-sdk): el A2uiSchemaManager construye el system prompt con el schema del catálogo + ejemplos trabajados; el catálogo trae su propio validador JSON-Schema; el SDK proporciona un parser para bloques <a2ui-json> y valida y reintenta en errores 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 flexibilidad

Proporciona datos y UI juntos — cada consumidor elige. Los clientes de API ignoran el campo ui y usan data; los clientes orientados a humanos renderizan el mensaje 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
}

Las secciones anteriores cubrieron operaciones de "lectura" (MCP, A2A, A2UI). La evolución natural: los agentes necesitan ejecutar "acciones" con implicaciones financieras en el mundo real. Priorizar protocolos de comercio + un harness operativo robusto es lo que los convierte en estándares de la industria para transacciones.

Características clave y beneficios de los protocolos: typed schemas, seguridad y open source — la combinación que ataca de frente la deuda de integración y garantiza neutralidad de vendor.