# Scaling agent systems with Apache Kafka and Agent2Agent (Part 2): Understanding the A2A object model [Blog](/blog/)>[Technology](/blog/category/technical/)>Scaling agent systems with Apache Kafka and Agent2Agent (Part 2): Understanding the A2A object model Scaling agent systems with Apache Kafka and Agent2Agent (Part 2): Understanding the A2A object model ==================================================================================================== July 21, 2026 | By [ Paul Brebner](https://www.instaclustr.com/blog/author/paul-brebner/) [ ](https://x.com/intent/tweet?text=Scaling%20agent%20systems%20with%20Apache%20Kafka%20and%20Agent2Agent%20(Part%202):%20Understanding%20the%20A2A%20object%20model&url=https://www.instaclustr.com/blog/scaling-agent-systems-with-apache-kafka-and-agent2agent-part-2-understanding-the-a2a-object-model/) [ ](https://www.linkedin.com/shareArticle?mini=true&url=https://www.instaclustr.com/blog/scaling-agent-systems-with-apache-kafka-and-agent2agent-part-2-understanding-the-a2a-object-model/&title=&summary=Scaling%20agent%20systems%20with%20Apache%20Kafka%20and%20Agent2Agent%20(Part%202):%20Understanding%20the%20A2A%20object%20model&source=) 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](https://a2a-protocol.org/latest/) (agent-to-agent) and [MCP](https://modelcontextprotocol.io/) (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. ![A2A object model diagram]() *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](https://a2a-protocol.org/latest/), 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](https://a2a-protocol.org/latest/), and more on [GitHub](https://github.com/a2aproject/A2A). 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. ProtocolScopeTypical useMCPAgent ↔ tools/resourcesCalling databases, APIs, file systems, IDE integrationsA2AAgent ↔ agentDelegating work, collaborating across runtimes and teamsWhy the A2A object model matters for multi-agent systems -------------------------------------------------------- [In Part 1](https://www.instaclustr.com/blog/scaling-agent-systems-with-apache-kafka-and-agent2agent-part-1-the-evolution-of-agent-systems/), I argued that interoperability has been a recurring challenge in distributed systems — addressed over decades through technologies like [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol), [CORBA](https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture), the [Web](https://en.wikipedia.org/wiki/History_of_the_World_Wide_Web), [SOA](https://medium.com/@lj794968/the-impact-of-soa-on-software-architecture-and-design-5915c5d0e63a), and event streaming platforms such as Apache [Kafka](https://kafka.apache.org/). 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](https://a2a-protocol.org/latest/topics/key-concepts/) documentation describes three primary roles: RoleDescriptionUserThe 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: 1. **Decoupling dialogue from deliverables** — if everything were a message, extracting final results would mean mining conversation logs. 2. **Streaming and incremental construction** — artifacts composed of parts can be delivered piece by piece during long-running work. 3. **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](https://modelcontextprotocol.io/docs/getting-started/intro)/[OpenAI](http://developers.openai.com/api/reference/overview)/[OpenAPI](https://www.openapis.org/) all treat tool outputs as addressable resources (they name the output, but in different ways); older integration stacks ([BPEL](https://en.wikipedia.org/wiki/Business_Process_Execution_Language), [WS-Addressing](https://www.w3.org/submissions/ws-addressing/), [ebXML](https://en.wikipedia.org/wiki/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](https://www.instaclustr.com/blog/netapp-instaclustr-for-mcp-gateway-is-here-smarter-ai-data-access-starts-now/) 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. ### About the author **[Paul Brebner](https://www.instaclustr.com/blog/author/paul-brebner/)** | Technology Evangelist at Instaclustr Paul has extensive R&D and consulting experience in distributed systems, technology innovation, software architecture, and engineering, software performance and scalability, grid and cloud computing, and data analytics and machine learning. [ Add Instaclustr as a preferred source on Google ](https://google.com/preferences/source?q=instaclustr.com) ![mail icon]()#### Get the latest articles for open sourceIn your inbox Sign up now ### Related content [ Zero Downtime Migration to Instaclustr Yes, we can migrate existing Cassandra clusters to Instaclustr without any downtime. Here's what to expect from the process... ](https://www.instaclustr.com/blog/zero-downtime-migration-to-instaclustr/) [ Workflow Comparison: Uber Cadence vs Netflix Conductor When choosing what’s right for your company’s opensource workflow needs it is important to know the difference and similarities ... ](https://www.instaclustr.com/blog/workflow-comparison-uber-cadence-vs-netflix-conductor/) [ Will Your Cassandra Database Project Succeed?: The New Stack Open source Apache Cassandra® continues to stand out as an enterprise-proven solution for organizations seeking high availability... ](https://www.instaclustr.com/blog/will-your-cassandra-database-project-succeed-the-new-stack/) ×Sign upto ourNewsletter -----------------------