IBM Experts Unpack AI Agent Interoperability
IBM's Anna Gutowska (AI Engineer) and Martin Keen (Master Inventor) laid out a straightforward plan for getting AI agents to work together. If you're building products, this is about turning siloed models into coordinated systems that ship outcomes, not just outputs.
Their focus: two protocols that make agents interoperable in real environments with real constraints - the Agent-to-Agent Protocol (A2A) and the Model Context Protocol (MCP).
A2A vs MCP: the quick take
- A2A: A standard way for agents to talk over HTTP using JSON-RPC 2.0. It covers requests, responses, negotiation, and coordination - plus streaming status via server-sent events.
- Agent Card: A machine-readable descriptor that advertises an agent's capabilities so other agents can discover, understand, and call it.
- MCP: A context layer exposing Tools, Resources, and Prompts through predefined interfaces, so agents can use files, code, or data without knowing implementation details.
The problem: isolated agents don't ship products
Most agents can think and generate output alone. The real gap shows up when they need to hand off work, pull from a data store, or trigger an action in your stack.
Gutowska and Keen address that gap with shared protocols. Common contracts mean your text agent can coordinate with an image agent, a code executor, and your inventory system - cleanly.
Inside A2A
Transport: HTTP + JSON-RPC 2.0
A2A rides on HTTP and uses JSON-RPC 2.0 for structured requests and responses. That makes it easy to route, secure, and observe using the web infrastructure you already have. See the spec for details: JSON-RPC 2.0.
Streaming: progress in real time
Long-running tasks don't leave anyone guessing. A2A supports server-sent events so agents can push partial results and status updates as they work. That's helpful for chaining multi-step workflows without blocking.
Discovery: the Agent Card
Think of the Agent Card as a digital resume. It lists skills, inputs, outputs, and endpoints so other agents can find and call the right capability - without guesswork.
Once discovered, agents exchange structured messages: request a task, negotiate scope, return a result, or stream progress.
MCP: shared context without tight coupling
MCP sits above A2A. It abstracts how resources are implemented, so agents call capabilities, not systems. The MCP server translates those calls to your file systems, repos, databases, or external services.
- Tools: Executable actions (query a DB, run code, call a service).
- Resources: Readable data (files, records, embeddings).
- Prompts: Reusable templates and instructions that shape behavior.
For product teams building context-aware agent integrations, see: MCP.
How A2A + MCP work together
Example: An Inventory Agent flags low stock. It uses A2A to notify an Order Agent. The Order Agent uses MCP to discover suppliers, read pricing from a data source, and execute a reorder tool.
While the order runs, the Order Agent streams status back via A2A. Different modalities and vendors still collaborate because the contract - not the model - defines the interaction.
Implementation playbook for product teams
- Start thin: Pick one workflow with clear ROI (e.g., inventory reorder, triage-to-ticket, or CI test-and-fix).
- Define Agent Cards: Capabilities, input/output schemas, SLAs, retry behavior, and error taxonomy.
- Stand up MCP: Wrap your file system, code repo, vector store, and core APIs as Tools/Resources/Prompts.
- Contract first: Version your message schemas. Enforce validation at the edge. Break changes behind new versions.
- Security: mTLS or OAuth between agents, signed requests, allowlists per capability, audit logs for every call.
- Observability: Correlation IDs on every message, distributed traces, success/failure metrics per capability.
- Resilience: Timeouts, idempotency keys, backoff, and circuit breakers. Define fallbacks and human handoffs.
- Testing: Simulation harness for agents, seeded scenarios, fault injection, and data drift checks.
- Rollout: Canary by agent and capability. Shadow mode first, then partial traffic, then default path.
KPIs to prove it works
- Time from detection to action (e.g., low stock to approved order).
- Success rate per capability and per agent handoff.
- Average handoffs per workflow and where they fail.
- Mean time to recovery for failed steps.
- Cost per completed task (tokens, compute, and API spend).
Common traps to avoid
- Ad-hoc payloads: If schemas live in slide decks, you will rework endlessly.
- Capability sprawl: Every new tool adds risk. Keep capabilities focused and owned.
- Tight coupling: Agents calling internal implementations instead of MCP abstractions will slow you later.
- No human-in-the-loop: Add approvals where stakes are high (purchases, deploys, customer comms).
- Weak provenance: Track which data and tools informed every decision for audit and rollback.
Why this matters for product development
Single agents can demo well. Interoperable agents ship value across teams and systems with fewer hacks and less glue code.
Protocols like A2A and concepts like MCP make that possible: discoverable capabilities, consistent contracts, and context that scales with your stack.
Watch the discussion
The full conversation is available on IBM's channel: IBM on YouTube.
For more practical coverage on building agent workflows, explore AI Agents & Automation.
Your membership also unlocks:
