You’ve probably heard this famous “quote” about computing standards:
“The wonderful thing about standards is that there are so many of them to choose from.”
Widely attributed to Grace Hopper or Andrew Tanenbaum, it captures a recurring industry pattern: competing guidelines, overlapping specs, and integration fatigue.
In the emerging agent interoperability space, the picture is slightly different. There are not yet many bona fide open protocols purpose-built for agent collaboration. What you mostly find today is a mix of:
- Interop protocols — notably A2A (agent-to-agent) and MCP (agent-to-tools)
- Frameworks and platforms — LangGraph, AutoGen, CrewAI, AGNTCY, vendor SDKs, and similar stacks
- API description formats — OpenAPI, GraphQL, AsyncAPI, and others that teams sometimes adapt for agent handoffs
What is the Agent2Agent (A2A) object model?
The Agent2Agent (A2A) object model defines the core building blocks that enable AI agents to discover one another, exchange messages, execute long-running work, and deliver durable outputs. The primary A2A objects are agent cards, messages, parts, tasks, and artifacts. Together, they provide a standardized foundation for AI agent interoperability across frameworks, platforms, and programming languages
This post focuses on A2A — specifically the nouns of the protocol: who participates, and what data objects carry meaning. Part 3 will cover how agents discover each other, send work, and deliver updates.
The A2A object model provides the foundation for AI agent interoperability. At a high-level agents discover one another through an agent card, coordinate through messages and parts, and collect durable outputs as artifacts on a task.
Diagram showing the A2A object model. A client fetches an Agent Card, sends a Message composed of Parts, which may become a Task that produces Artifacts also built from Parts.
What is Agent2Agent (A2A) protocol?
The Agent2Agent (A2A) Protocol is an open interoperability standard for AI agents that are built on different frameworks, platforms, and languages to discover one another, exchange structured messages, track long-running work, and deliver durable outputs — securely and without sharing internal state.
Initiated at Google and now community-driven under the A2A project, A2A aims to let specialized multi-agent systems pass tasks, context, and generated artifacts across vendor silos. The specification and topic guides are published at a2a-protocol.org, and more on GitHub.
In plain terms, A2A is:
- An open standard protocol
- For communication and interoperability
- Between opaque agentic applications (agents that do not expose their internal reasoning, memory, or tooling)
A2A vs. MCP: Understanding the difference
A common source of confusion is the relationship between the Agent2Agent (A2A) Protocol and the Model Context Protocol (MCP). Although both are important interoperability technologies, they solve different problems.
| Protocol | Scope | Typical use |
|---|---|---|
| MCP | Agent ↔ tools/resources | Calling databases, APIs, file systems, IDE integrations |
| A2A | Agent ↔ agent | Delegating work, collaborating across runtimes and teams |
Why the A2A object model matters for multi-agent systems
In Part 1, I argued that interoperability has been a recurring challenge in distributed systems — addressed over decades through technologies like TCP, CORBA, the Web, SOA, and event streaming platforms such as Apache Kafka. A2A continues that evolution at a new layer: autonomous agents as network-accessible collaborators.
It also targets a challenge I highlighted earlier: complex workflows involving long-running, stateful agents with greater autonomy. A2A introduces asynchronous execution, long-running operations (LROs), streaming, and push notifications — topics we pick up in Part 3. Those patterns will feel familiar if you have worked with distributed workflow engines (Cadence) or event-driven architectures; they are analogies, not native A2A integrations.
Core participants in the A2A protocol
The A2A key concepts documentation describes three primary roles:
| Role | Description |
|---|---|
| User | The end user — human or automated service — who initiates a goal or request. The User is not an A2A wire endpoint, but they are part of the interaction model: a Client Agent acts on their behalf. |
| A2A Client (Client Agent) | An application or agent that initiates communication using the A2A protocol — for example, an orchestrator delegating work to a specialist agent. |
| A2A Server (Remote Agent) | An agent that implements an A2A endpoint: receives requests, executes work, returns messages or tasks, and emits status updates. Internal reasoning and tools remain opaque to the client. |
Key objects in the A2A object model
The A2A object model defines the structure that represents agents, communications, work items, and deliverables. Together they describe who agents are, what is being exchanged, and what gets produced.
Agent Card
An Agent Card is a JSON metadata document — think digital business card, or WSDL for agents — that describes a remote agent’s identity, service endpoint, capabilities, authentication requirements, and skills. Clients fetch an Agent Card before sending work so they know who they are talking to and how to talk to them. Discovery strategies, security, and caching are covered in Part 3.
Task
A Task is the primary stateful unit of work with a unique ID and a defined lifecycle. Tasks are created when a client sends a message and the remote agent determines the work requires ongoing execution rather than an immediate reply. Tasks can be grouped under a contextId to relate multiple interactions in the same session.
Common task states include submitted, working, input-required, and terminal outcomes such as completed, failed, canceled, and rejected. (Exact naming is defined in the spec — use the protocol enums in code, not ad hoc strings.)
Message
A Message represents a single turn in the interaction between client and agent in the A2A protocol. Each message has a role (user or agent), a unique message ID, and one or more parts carrying the actual content — instructions, context, status updates, and so on.
Part
A Part is the typed content container used within messages and artifacts. Each part holds exactly one form of data: plain text, raw bytes, a URI reference to external content, or structured JSON. Parts can include a mediaType, optional filename, and arbitrary metadata. This design keeps A2A modality-independent — a single message can combine text, structured data, and file references without ambiguity.
Artifact
An Artifact is an output generated by an agent during a task — the deliverables you keep after the conversation ends. Artifacts have identifiers, human-readable names, and are composed of parts. They can be built and streamed incrementally, and they remain bound to the task lifecycle: created, updated, and finalised as work progresses.
How messages, parts and artifacts work together in A2A
Here’s a useful way to read the object model:
- Messages coordinate — they are the dialogue between client and agent (or between agents). They drive the work forward, request input, and report interim status.
- Artifacts deliver — they are structured, referenceable outputs: a report, a dataset, generated code, an image, a UI component, or any other work product.
- Parts carry the payload in both cases — the same compositional pattern applies to conversational turns and to durable outputs.
For example, an agent generating a sales analysis might exchange several messages while work is in progress, then produce an artifact named “Sales Analysis Report” (report-456) containing a text summary part and a structured table part. Downstream systems consume the artifact directly instead of parsing chat history.
This separation matters for three practical reasons:
- Decoupling dialogue from deliverables — if everything were a message, extracting final results would mean mining conversation logs.
- Streaming and incremental construction — artifacts composed of parts can be delivered piece by piece during long-running work.
- Persistence and reuse — artifacts are designed to be stored, versioned, and passed to other agents or systems; messages are typically ephemeral coordination traffic.
Similar ideas appear elsewhere: MCP/OpenAI/OpenAPI all treat tool outputs as addressable resources (they name the output, but in different ways); older integration stacks (BPEL, WS-Addressing, ebXML) also distinguished process chatter from business documents. A2A applies the pattern to agent collaboration.
One detail that tripped me up on first read: SendMessage returns a Message or a Task, not a bare Artifact. Artifacts live inside the Task. More on that in Part 3.
Key takeaways: Understanding the A2A object model
Before diving into runtime behavior, it’s useful to summarize the vocabulary:
- Three participants — User (goal), Client Agent (initiates), Remote Agent (serves)
- Agent Card — JSON capability and trust metadata for discovery
- Message + Part — one conversational turn, modality-independent
- Task — stateful unit of work with a lifecycle
- Artifact — durable deliverable, composed of parts, bound to a task
Understanding A2A’s object model is useful because it shows where production agent systems need more than just prompts and model calls. Messages coordinate work, tasks track state, and artifacts preserve outputs — but real enterprise systems also need governed access to data, reliable event flow, durable workflows, observability, and operational controls. That is the layer Instaclustr focuses on: production-ready open source data infrastructure, including Kafka, Cadence, OpenSearch, PostgreSQL, ClickHouse, Cassandra, and Instaclustr for MCP Gateway for controlled agent access to data and tools.
Next: Part 3 explores how agents discover one another, exchange work via SendMessage, track long-running tasks, and receive updates through polling, SSE, or push webhooks.
