MCP or A2A

AI
1

As organizations build agentic solutions with Pega Infinity 26, a common question is whether they should use Model Context Protocol (MCP) or Agent2Agent Protocol (A2A).

The answer depends on what is being connected.

MCP: Connecting agents to capabilities

MCP enables an AI application or agent to access approved tools, data, and workflows through a standardized interface.

With Pega Infinity 26, MCP can be used to expose capabilities such as case types, data pages, automations, flow actions, and other business functions to compatible AI clients. Pega agents can also use MCP to access external tools and information.

Think of MCP as agent-to-capability communication.

Use MCP when:

  • An external AI assistant needs to create or update Pega cases
  • A Pega agent needs access to an external database, API, or business tool
  • A coding agent needs governed access to Pega application capabilities
  • You want reusable business functions to be discoverable as tools

A2A: Connecting agents to agents

A2A enables autonomous agents from different platforms or frameworks to discover one another, delegate work, exchange results, and coordinate toward a goal.

Pega supports bidirectional A2A communication, allowing a Pega agent to invoke an external agent or an external agent to delegate work to Pega.

Think of A2A as agent-to-agent collaboration.

Use A2A when:

  • A Pega agent needs to delegate a specialized task to another agent
  • An external agent should hand a business process to Pega
  • Multiple agents need to coordinate across platforms
  • The remote system has its own reasoning, skills, and task lifecycle

Which should you choose?

A simple rule is:

If you are connecting an agent to a tool, workflow, or data source, use MCP.

If you are connecting one autonomous agent to another, use A2A.

In many enterprise architectures, the correct answer will be both.

A2A can coordinate work between agents, while MCP gives each agent governed access to the tools and data it needs to complete that work. For example, a Pega agent might use A2A to delegate a fraud review to a specialized external agent, while both agents use MCP to access approved enterprise systems.

The distinction matters because not every API should be presented as an agent, and not every agent should be reduced to a collection of tools.

Pega Infinity 26 provides support for both patterns. The architectural decision should therefore be based on the nature of the interaction—not on choosing one protocol as the universal answer.

MCP connects capabilities. A2A coordinates intelligence. Pega provides the workflow and governance around both.

2

Aaron,

I’m finding this conversation really resonates with teams developing in Pega day to day, but it often gets overlooked in conversations with folks who don’t deal with the technical details. I try diligently to explain how our ability to leverage both methods is key to our predictable AI approach, and am curious if you have any insight on how you explain about the value of this when showing Pega as a truly Agentic platform. Thoughts? Successes? Failures? I’d love to hear any and all!

3

Hi Jake!

That’s how I tend to explain the value. MCP allows Pega to act as the control and tool-distribution layer for agents across the enterprise, whether those agents are built in Pega or elsewhere.

Agents can handle reasoning and interaction, while Pega governs which tools and data they can access, applies business rules, routes the work, and maintains the audit trail.

When speaking to those that don’t deal with technical details, I make certain to call out that is what makes Pega truly agentic; governing how agents across different systems get real work done.

4

Great article , simple and hits key points . @winda

5

Aaron, Nice post. Following the logic in your post it seems Pega, the leading workflow solution software, will almost always invoke agents via MCP because we will almost always operate as the workflow or orchestrator. A2A would only be used when Pega invokes and agent and that agent needs to work with another agent to achieve the outcome. A hypothetical example might be claims fraud workflow in Pega calls a fraud analysis agent and shares claim information with it. The fraud agent need to call another agent which analyzes external sources that contain past fraud issues looking for patterns that may match the one in focus. Then A2A would be used. Seems like Pega would not setup the A2A between agents and the enterprise handling the claims would setup the A2A integration. Agree?

6

Aaron, nice framing, simplicity is a strength here! Agent-to-capability (agent-to-tool is my preferred one) vs agent-to-agent is the version I use for client conversations.

One thing I’d flag from the field: a lot of customers are defaulting to an MCP-server architecture for everything, including things that are actually agents. And it works, until it doesn’t. When you wrap an agent behind an MCP tool call you flatten it into stateless request/response. No task lifecycle, no back-and-forth, no clarifying questions from the remote side. You’ve paid for an agent and you’re consuming it as a stored procedure.

The test I use: does the remote system have its own reasoning loop, and does the interaction benefit from a conversation rather than a call? If yes, direct A2A. If it executes and returns, MCP, even if there’s an LLM inside. “AI-powered” doesn’t make it an agent from an integration standpoint.

The part that worries me is that most teams are debating the protocol when the harder problem is keeping context intact across the chain. The protocol is the easy part. And your article points in the right direction.