A2A Is For UI

A2A Is For UI

There’s a lot of skepticism around A2A, Google’s Agent-to-Agent protocol. A lot of that is well earned. I mean, they launched a protocol with zero implementations. But a lot’s changed, and it’s worth taking a look again.

I’d like to convince you that you should be thinking about A2A as a protocol for giving agents a UI. And that UI is a bridge into a more complex multi-agent world. Gotta start somewhere!

It’s Just HTTP

The protocol is just a single HTTP endpoint and an agent card (can be statically served). Inside that single endpoint are JSON RPC methods:

  • message/send & message/stream — Both send messages, one returns a stream of events (SSE). The first message implicitly creates a task.
  • tasks/resubscribe — For when you were doing message/stream but your connection broke.
  • tasks/get — If you want to poll. SSE isn’t for everyone, I guess. cURL works too.
  • tasks/pushNotifications/set & .../get — for webhooks, if that’s your thing

So basically, you create a task, and then you exchange messages with it. That’s it.

Tasks are Actors

Uh, if you don’t know what actors are, this analogy might not help, but I’m going with it anyway.

Tasks are actors (think Erlang actors or Akka). The first time you send a message to an actor, a task (an actor) is implicitly created.

flowchart TD client((client)) client--send msg-->box[implicit mailbox] box-->task--"also
queued"-->client

Messages are processed one-at-a-time, in the order they were received. Messages can mutate task state. But it doesn’t get crazy because the interaction is very single threaded (well, I guess you could process messages in parallel, but why?)

UIs are Agents

I think of a UI as being an agent that happens to have a human behind it. Not an AI agent, but a human agent. The UI application code handles the computer part, the human handles the intelligence part.

Yes, A2A was designed for sending messages between AI agents, but we don’t currently live in a world where open-ended multi-agent systems are pervasive. We do live in a world where humans talk to agents. And that won’t ever really change, because agents aren’t super valuable if their work never makes it to a human.

A2A supports any data

Each message, in either direction, contains multiple parts, each of one of these types:

  • TextPart — plain text, think unprocessed LLM outputs
  • DataPart — think JSON or binary. The format is specified by the mime type
  • FilePart — like DataPart, but can be at a URL

So an agent can do things like mix plain LLM outputs with JSON outputs.

Delegate state to Prefect or Temporal

One subtly difficult part of A2A is that it requires keeping state, potentially over long periods of time.

For example, an agent realizes the initiating user didn’t say enough, so it asks for clarification. People aren’t very good computers and while we sometimes respond quickly, sometimes we take minutes or hours, or even years. Or never.

How do you deal with that?

I’ve dealt with this by using systems like Temporal and Prefect. Both are sometimes called “workflow” systems, but can also be thought of as providing durable function execution.

Both are more interesting than most workflow systems because they also provide suspend & resume functionality. For example, in prefect you can call await suspend_flow_run() and the flow will be completely shut down and occupy zero memory or CPU while the user is twiddling their thumbs.

The Shim

I pulled this diagram directly from FastA2A docs:

flowchart TB Server["HTTP Server"] <--> |Sends Requests/
Receives Results| TM subgraph CC[Core Components] direction RL TM["TaskManager
(coordinates)"] --> |Schedules Tasks| Broker TM <--> Storage Broker["Broker
(queues & schedules)"] <--> Storage["Storage
(persistence)"] Broker --> |Delegates Execution| Worker end Worker["Worker
(implementation)"]

Note: I like FastA2A because it implements the HTTP endpoints as a Starlette app that you can easily mount right into your API alongside everything else. Also, it has basically nothing to do with Pydantic or Pydantic AI other than it happens to be collocated inside the same Github repository.

FastA2A clearly realizes there’s a state problem and so they created interfaces for dealing with it. Not only that, but these interfaces are a fairly standard architecture for workflow systems.

I’ve created simple shims for both Temporal and Prefect that use the workflow systems to implement the TaskManager, Storage and Broker. The idea being you could use either Prefect or Temporal, whichever you prefer, to quickly create a robust A2A-compatible agent.

They’re each ~100 lines of code, yet implement just about everything you’d want from a stateful system, from retries and deployments to observability and a management UI.

Where does this fit into your agent?

Say you’re following the Plan-Act-Verify flow that’s become popular:

flowchart TD client((client)) client-->clarify[Clarify Question]-->Plan-->Act["Act (Query)"]-->Verify-->Plan Verify-->prepare[Prepare Report]-->client2((client))

All those boxes are things that need to happen once and only once (well, in a loop). Every agent has a slightly different take on this, but many boil down to some variant of this architecture. The workflows don’t have to be complicated (but by all means, they can be).

The point is, yes, A2A is stateful and statefulness can be hard. But it can be solved simply and cleanly by delegating to other hardened distributed systems that were designed to do this well.

A2A Versus MCP

Simply, MCP is for tools (function-like things with inputs and outputs). A2A is for when you need free-form communication. Hence why tasks look more like actors.

They also solve similar fan-out problems. MCP enables many tools to be used by few AI applications or agents. A2A enables many agents to be used by few user interfaces and other agents.

flowchart TD subgraph c[A2A Clients] teams[MS Teams] agentspace[Google
AgentSpace] ServiceNow end subgraph m[MCP Servers] comp[Computer
Use] search[Web
Search] APIs end teams-->Agent[A2A-compatible
Agent] agentspace-->Agent ServiceNow-->Agent Agent-->comp Agent-->search Agent-->APIs

Side note: AI Engineering has become incredibly complex. You have to master not just AI tech, but also be a full-stack engineer and a data engineer. The emergence of A2A & MCP dramatically reduces the scope of an AI engineer, and that’s exciting on it’s own.

Implementation is picking up quickly

I’m going to finish this post by linking to a ton of products that are using A2A or soon will. My hope being that you’ll realize that now is a good time to get in on this.

A2A-compatible agents you can launch (server side)

Commercial / SaaS agents – live today

  • Google-built agents inside Vertex AI Agent Builder & Agentspace – e.g., Deep Research Agent, Idea Generation Agent; all expose an A2A JSON-RPC endpoint out of the box. (cloud.google.com, cloud.google.com, cloud.google.com)
  • SAP Joule Agents & Business Agent Foundation – Joule delegates work to SAP and non-SAP systems via A2A. (news.sap.com, architecture.learning.sap.com)
  • Box AI Agents – content-centric agents (contract analysis, form extraction) advertise themselves through A2A so external agents can call them. (developers.googleblog.com, blog.box.com)
  • Zoom AI Companion – meeting-scheduling and recap agents are now published as A2A servers on the Zoom developer platform. (instagram.com, uctoday.com)
  • UiPath Maestro agents – healthcare summarization, invoice triage, etc.; natively speak A2A for cross-platform automation. (uipath.com, itbrief.com.au)
  • Deloitte enterprise Gemini agents – 100 + production agents deployed for clients, exposed over A2A. (venturebeat.com)

Open-source agents & frameworks

  • LangGraph sample Currency-Agent, Travel-Agent, etc. (a2aprotocol.ai, github.com)
  • CrewAI – “crews” can publish themselves as remote A2A services (#2970). (github.com)
  • Semantic Kernel travel-planner & “Meeting Agent” demos. (devblogs.microsoft.com, linkedin.com)
  • FastA2A reference server (Starlette + Pydantic AI) – minimal A2A turnkey agent. (github.com)
  • Official a2a-samples repo – dozens of runnable Python & JS agents. (github.com)

Announced / on the roadmap

  • Salesforce Agentforce will “incorporate standard protocols like A2A” in upcoming releases. (medium.com, salesforce.com)
  • ServiceNow, Atlassian, Intuit, MongoDB, PayPal, Workday, Accenture and ~40 other partners listed by Google as “founding A2A agents.” (venturebeat.com)

Products that dispatch to A2A agents (client/orchestrator side)

Cloud platforms & orchestration layers

  • Azure AI Foundry – multi-agent pipelines can send tasks/send & tasks/stream RPCs to any A2A server. (microsoft.com, microsoft.com)
  • Microsoft Copilot Studio – low-code tool that now “securely invokes external agents” over A2A. (microsoft.com, microsoft.com)
  • Google Agentspace hub – lets knowledge workers discover, invoke, and chain A2A agents (including third-party ones). (cloud.google.com, cloud.google.com)
  • Vertex AI Agent Builder – generates dispatch stubs so your front-end or workflow engine can call remote A2A agents. (cloud.google.com)

Gateways & governance

  • MuleSoft Flex Gateway – Governance for Agent Interactions – policy enforcement, rate-limiting, and auth for outbound A2A calls. (blogs.mulesoft.com, docs.mulesoft.com)
  • Auth0 “Market0” demo – shows how to mint JWT-style tokens and forward them in authentication headers for A2A requests. (auth0.com)

Open-source dispatch tooling

  • Official A2A Python SDK (a2a-python) – full client API (tasks/send, SSE streaming, retries). (github.com)
  • a2a-js client library (part of the A2A GitHub org). (github.com)
  • n8n-nodes-agent2agent – drop-in nodes that let any n8n workflow call or await A2A agents. (github.com)

Coming soon

  • UiPath Maestro orchestration layer (already works internally, public A2A client API expanding). (linkedin.com)
  • Salesforce Agentforce Mobile SDK – upcoming SDK will be able to dispatch to external A2A agents from mobile apps. (salesforceben.com)
  • ServiceNow & UiPath cross-dispatch partnerships are in private preview. (venturebeat.com)