Agent Tools & Interoperability

Day 1 established the paradigm shift: from hand-written code to Agentic Engineering, where the developer operates as a Factory Model — designing the production line, not tightening every bolt. The central equation from that paper remains the foundation for everything that follows:

The harness — the scaffolding of tools, memory, transport and security around the model — only reaches its potential when it connects to the world through open standards. Without standards, every integration is a custom-machined part: it works in your garage, breaks at the first change. With standards, the harness becomes a plug-and-play modular platform.

The paper presents five protocols as the "industry standards" — the uniform threads and sockets of the agentic ecosystem. Click each one to explore:

Two more pieces complete the picture: the OpenResponses & Interactions API works as 'Power Plugs' — modern API approaches to LLM inference that support long-running tasks, blurring the line between a stateless single turn and a stateful agent. And Skills are 'Playbooks' — very simple markdown instructions with scripts or tools ready to run in a sandbox environment like a terminal.

Vibe coding removed the friction of writing code — and with it, some of the structure that guaranteed predictability. Speed remains the primary engine, but now harnesses and protocols carry the weight of trust: they define clear contracts between the agent and the external world.

Without open standards, every API becomes a "standard-of-one": a custom parser, a custom error format, a custom auth flow. The result is technical debt that accumulates silently — and a list of low-leverage tasks that consume the developer's time:

The paper was designed for software engineers, engineering managers, architects and technical leaders who recognize that the shift to Agentic Engineering requires strict adherence to protocols to maintain fidelity and reliability of results. It serves as a practical guide for "vibe coders" who prioritize speed and visual output, showing how to build a virtual data and execution team.

In traditional enterprise, connecting an agent to a tool means bespoke wiring: custom REST wrappers, manual API key management, OAuth token refresh, hand-written JSON parsers for every response format. Every new tool is a project. MCP (Model Context Protocol) replaces that friction with a standardized socket — discover, configure, connect.

Every agentic platform faces the same math: N models × M tools. In the traditional approach, each model-tool pair requires a bespoke integration — O(N×M) integration points. With 5 models and 10 tools, that's 50 integrations to maintain. If one tool's API changes, multiple parser loops break at once.

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

With MCP, each model implements the protocol once and each tool implements the protocol once — total cost drops to O(N+M), linear scale. Drag the controls and watch the difference explode:

Because tool definitions are standardized, MCP can be plugged directly into the harness via standard transports — no custom integration layers. Two transports cover virtually all cases. Click each one:

In both cases, the vibe coder gains the same superpower: connecting tools without writing multiple layers of custom integration — the transport is handled by the protocol, not by you.

When the agent hallucinates parameters, calls the wrong tool, or fails to parse a payload, the instinct is to rewrite the system instructions. Resist. The problem is almost always in what the agent sees — and the right way to diagnose it is to inspect the transport pipes directly, without starting the agent's main workflow.

AI systems are evolving from isolated applications into distributed networks of domain specialists. In this reality, standardized communication is not a convenience — it is a prerequisite for scale. A2A (Agent-to-Agent) is the foundational layer that resolves ecosystem fragmentation: it lets developers discover, orchestrate, and monetize a globally interoperable virtual workforce.

The evolution of agentic architectures

There is a recurring pattern in the history of computing: the manual and low-level gives way to the declarative and intent-based. The user says WHAT, not HOW. This trajectory has repeated three times — and now it is happening with agents:

“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 ….”

Early vibe coding naturally produces the Single Agent Monolith: a "Swiss Army knife" with a sophisticated prompt, one agent wearing multiple hats, and dozens of tools. You can prototype it in a weekend — but it soon hits the Monolithic Ceiling:

The solution follows the blueprint that ML and software engineers already know. AutoML proved its business value and was then decomposed into observable stages — data versioning, feature stores, drift detection. The same happens with the monolithic agent: specialization is the scaling mechanism.

Reduced search space: restricting each sub-agent's tools reduces errors and hallucinations. Attention-dilution mitigation: a single-domain prompt produces sharper reasoning. Contextual-load optimization: the orchestrator routes the task and each sub-agent receives context with a high signal-to-noise ratio.

The ecosystem is migrating to distributed multi-agent architectures: industry leaders (Google, Salesforce, ServiceNow, Workday) already publish specific domain agents. The orchestrator delegates across network boundaries — no longer within a single process.

The real world has ambiguous data structures, misleading requirements, and conflicting user preferences — the "digital equivalent of crooked walls". It is rarely possible to specify every detail without multi-turn clarification. It is this need to negotiate, pause, and resume that separates an agent from an API.

An agent's domain is unbounded. Forcing it into a synchronous tool wrapper is equivalent to resurrecting GOTO: the control flow abandons the expected structured context and can do anything — reach an interrupted state, ask for more information, never return the expected output, or be abandoned when the user changes their mind halfway through.

We need a paradigm that isolates the messy multi-turn state — a protocol that allows pausing execution → returning to the Orchestrator → negotiating → resuming without losing conversational state. A2A fills exactly that gap. By isolating collaborative routing in the A2A layer, the tools layer (MCP) stays clean, predictable, and strictly structured.

A2A + specialization are the foundation of new marketplaces of expertise. Without A2A, each agentic application fights rising complexity alone. With A2A, a developer can focus on a high-value niche — for example, "Real-Time Regulatory Compliance" — and have their specialist discovered and "hired" by orchestrators around the world.

The A2A core is the transport and negotiation backbone. Rich transactional applications require higher-order capabilities — and the A2A Extensions framework standardizes them: advertise, negotiate, and execute optional functionality. Three foundational frameworks live as native extensions:

Monetizing A2A agents — the Agent-as-a-Service model

Following the SaaS paradigm, AaaS is a consumption-based model, sold through multiple channels. Google Cloud Marketplace serves as the monetization engine, and Gemini Enterprise acts as the agentic platform — with Agent Registries and a native A2A client, serving simultaneously as an AaaS platform (Assistant API) and a host for remote agents. A common hybrid pricing model: "fixed fee plus usage" — predictable base + overages per token/compute.

The communication gap: ask a colleague "how did Q4 go by region?" and they draw a bar chart, circle the highlights, and add context. An agent returns raw JSON — and you build the chart yourself: import libraries, configure axes, manage state. That context switch breaks the vibe coding flow. A2UI changes the game: agents generate complete interactive UIs as output, not just JSON blobs.

Generative UI is the LLM creating interfaces dynamically at runtime, based on user intent and context. Instead of hardcoding every UI state, the model composes the right interface on demand: "compare Q4 sales by region" → the system assembles an interactive layout with cards, filters, and controls. The central challenge is security: code injection, XSS, and uncontrolled side effects.

The agent doesn't need to know the target (web, mobile, wearable, appliance) — it only knows the catalog and the examples. The catalog defines what's available, the agent decides the arrangement, the client assembles.

Table 1 of the paper lists 18 components ready for use. In v0.8 the catalog was called "standard"; in v0.9 it was renamed to "basic" — a deliberate signal that, in production, you should bring your own catalog: map your existing components (buttons, charts, and maps from your design system) to A2UI types. The agent doesn't change; only the renderer mapping does. (And ChoicePicker was MultipleChoice in 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" }
    ]
  }
}

Components form a flat adjacency list referenced by id — easy for the LLM to generate incrementally and easy for the client to update without re-rendering everything. A separate createSurface message tells the client which id is the root. The client assembles the complete interactive interface: no React code required.

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

Data values arrive in a parallel updateDataModel message that resolves {path: "/title"} references — clients re-render on data updates without resending the structure. And the LLM only sees the tool's structured response (not the rendered UI), so context stays focused.

Traditional chat is linear: each response is static. The Canvas is a persistent workspace that agent and user edit together — a living document where the agent modifies sections and you edit manually, in real time. Combined with A2UI, persistence meets interactivity: the UI isn't just rendered — it's a communication medium. The agent observes your interactions and responds accordingly.

Best practices — let the LLM generate A2UI

Writing A2UI JSON by hand is tedious. Use the official SDK (pip install a2ui-agent-sdk): the A2uiSchemaManager builds the system prompt with the catalog schema + worked examples; the catalog ships its own JSON-Schema validator; the SDK provides a parser for <a2ui-json> blocks and validates and retries on schema errors.

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

Hybrid output for flexibility

Provide data and UI together — each consumer chooses. API clients ignore the ui field and use data; human-facing clients render the A2UI message.

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

The previous sections covered "read" operations (MCP, A2A, A2UI). The natural evolution: agents need to perform "actions" with real-world financial implications. Prioritizing commerce protocols + a robust operational harness is what turns them into industry standards for transactions.

Key characteristics and benefits of the protocols: typed schemas, security and open source — the combination that directly tackles integration debt and guarantees vendor neutrality.