Anna Gutowska and Martin Keen compare two protocols for connecting AI agents, models that run multi-step tasks with tools. In this twelve-minute IBM Technology dialogue, Gutowska explains communication between agents while Keen describes access to software and data. Their retail example shows how the two interfaces can serve different parts of one workflow.
A2A advertises capabilities and passes tasks (00:53–03:27)
- A2A, the Agent2Agent protocol, gives agents a standard way to exchange messages and task requests. Gutowska describes collaboration across different vendors and frameworks.
- An agent card advertises an agent’s capabilities. Other agents can discover what services it offers and decide where to send work.
- The exchange can include requests, responses, and coordination steps. This is the part of the architecture where one agent asks another to handle a task.
- Messages can carry more than text. Gutowska includes images, files, and structured data, using a design mockup that passes through generation, review, and client approval as an example.
- A2A addresses cooperation between those agents. The conversation then separates that role from an individual agent’s access to a database.
Web infrastructure carries progress updates (03:34–05:19)
- Gutowska describes an HTTP-based setup that can use existing web servers and API gateways. Ordinary web infrastructure supplies routing, logging, and load balancing.
- The illustrated request-and-response format uses JSON-RPC 2.0, structured messages for calling remote operations. Its language-neutral format lets implementations written in different programming languages exchange requests.
- Long-running work also needs more than a final response. The explainer introduces server-sent events, a way for a server to stream updates to a client.
- An agent can report status or partial results while it works. The caller can follow progress without treating the task as an immediate, one-shot answer.
MCP gives one agent a reusable software interface (05:26–07:30)
- MCP, the Model Context Protocol, standardizes connections to tools and data. Keen’s examples include reading files, interacting with a code repository, and writing database records.
- Custom code could connect these systems. His argument for a protocol is reuse: avoid rebuilding a separate integration whenever the surrounding application changes.
- The MCP host is the AI application where the agent runs. An MCP server provides the interface to the underlying files, repository, database, or service.
- The server handles the system-specific interaction while presenting a common interface to the application. That separates the agent’s request from the details of a particular backend.
Separate actions, readable data, and templates (07:30–09:59)
- Tools are functions the model can invoke, such as searching a database or committing a repository change.
- Resources expose readable information, including files, database records, or application state.
- Prompts provide reusable templates for interactions. These three categories describe different things a server offers through MCP.
- Keen describes JSON-RPC messages with transport chosen for the server’s location. A local connection can use standard input and output; a remote server can use HTTP with streaming support.
- His reuse example is a customer relationship management system. A compatible host can connect through its MCP server without rebuilding the backend integration for each new model or application.
Combine the protocols in an inventory workflow (10:07–11:25)
- An inventory agent uses MCP to read and update product and stock information in databases.
- When stock runs low, it notifies an internal ordering agent. That agent communicates with external supplier agents.
- MCP covers the connection to business systems. A2A covers the messages and task exchanges among the participating agents.
- The presenters end by treating the protocols as complementary. One workflow can need both access to data and cooperation with other agents.
Caveat: This is a conceptual walkthrough of the protocols as presented in March 2026, not a versioned implementation guide or a tested integration.