PULSE Protocol

Posted on Feb 25 • Originally published at Medium

MCP, A2A, ACP... None of Them Solve the Real Problem

#programming #ai #opensource #machinelearning

In the last 18 months, three of the most powerful technology companies on Earth have each released a protocol for AI agent communication:

Anthropic created MCP (Model Context Protocol) — now donated to the Linux Foundation.

Google created A2A (Agent2Agent Protocol) — with 50+ industry partners.

IBM created ACP (Agent Communication Protocol) — through their BeeAI project.

Each protocol is technically competent. Each has serious engineering behind it. Each solves a real problem.

And yet, if you deploy all three simultaneously in your enterprise — which many organizations will need to do — your AI agents still can't understand each other.

Here's why.

What Each Protocol Actually Does

MCP: The Data Connector

MCP solves the problem of connecting AI agents to data sources. Think of it as USB-C for AI — a standard interface that lets any AI model plug into any data source without custom adapters.

Strengths:

Clean abstraction for tool/resource access
Well-designed client-server model
Now under Linux Foundation governance (neutral territory)
Growing ecosystem of connectors

What it doesn't do:

MCP doesn't define what agents say to each other
It doesn't provide shared vocabulary or semantics
It's about AI-to-data, not AI-to-AI communication
Two MCP-connected agents still need a translator if they use different concepts

Analogy: MCP is like giving everyone the same type of phone charger. Essential, but it doesn't mean they speak the same language.

A2A: The Enterprise Coordinator

A2A solves the problem of enterprise agent collaboration across different frameworks. Think of it as a project management protocol — defining how agents discover each other, negotiate capabilities, and coordinate tasks.

Strengths:

Agent Cards for capability discovery
Task lifecycle management
Multi-turn conversation support
Strong enterprise focus with 50+ partners

What it doesn't do:

A2A doesn't define the meaning of messages
Agents can find each other and start a conversation, but the content of that conversation has no standard semantics
Different vendors can implement A2A and still produce incompatible message formats
No vocabulary standardization

Analogy: A2A is like building a phone network with caller ID and voicemail. You can connect the call, but you still might not understand what the other person is saying.

ACP: The REST Bridge

ACP solves the problem of lightweight agent communication through a familiar REST API pattern. Think of it as HTTP for agents — minimal overhead, low barrier to entry.

Strengths:

Simple REST-based design
Easy to implement (any developer can start in hours)
Low infrastructure requirements
Good for simple agent-to-agent messaging

What it doesn't do:

No semantic layer whatsoever
No vocabulary or concept standardization
No security model beyond basic HTTP
Limited to simple request-response patterns

Analogy: ACP is like giving everyone a walkie-talkie. Simple and effective, but no guarantee the people on each end are using the same words to mean the same things.

The Gap Everyone Misses

Here's the critical insight that none of these protocols address:

Connection is not communication. Communication is not understanding.

MCP tells agents how to connect (to data).
A2A tells agents how to coordinate (tasks).
ACP tells agents how to call (each other).

None of them tells agents how to understand each other.

When Agent A sends get_weather_data and Agent B expects fetch_meteorological_info — no amount of protocol negotiation fixes that mismatch. The connection works. The coordination works. The call goes through.

But the meaning is lost.

This is what linguists call the common ground problem. Two parties can have a perfect communication channel and still completely fail to communicate if they don't share a common language.

The Three Layers of Agent Communication

To understand why the current protocols are incomplete, consider that agent communication has three distinct layers:

Layer 1: Transport (How do bytes move?)

HTTP, WebSocket, gRPC, message queues
Status: Solved. Multiple options available.

Layer 2: Protocol (How are messages structured?)

MCP, A2A, ACP define message formats, lifecycle, discovery
Status: Partially solved. Multiple competing standards.

Layer 3: Semantics (What do messages mean?)

Shared vocabulary, concept definitions, unambiguous meaning
Status: Unsolved. Nobody is working on this at scale.

The current protocol war is entirely focused on Layer 2. Layer 3 doesn't have a combatant. It doesn't even have a battlefield.

And Layer 3 is the one that actually matters for interoperability.

Why Semantics Can't Be an Afterthought

Some argue that semantic interoperability will "emerge naturally" as protocols mature. History says otherwise.

The Web (1990s): HTML defined structure. CSS defined presentation. But it took Schema.org (a shared vocabulary for web content, created jointly by Google, Microsoft, Yahoo, and Yandex) to make web content machine-understandable. Without Schema.org, search engines were guessing what web pages meant. With it, they know.

Healthcare (2000s): HL7 FHIR defines message formats for health data exchange. But it only became useful when SNOMED CT and LOINC (standardized medical vocabularies) gave those messages shared meaning. A blood pressure reading in FHIR format means nothing if sender and receiver define "blood pressure" differently.

Finance (2010s): FIX protocol standardized financial messaging. But it required FpML (Financial products Markup Language) with standardized product definitions to actually enable cross-institution trading. Same message format, but without shared product semantics, trades failed.

The pattern is always the same: protocols define structure, vocabularies define meaning. You need both.

What a Semantic Layer Looks Like

Imagine 1,000 predefined concepts organized into 10 categories:

Category	Count	Examples
ENT (Entities)	100	ENT.DATA.TEXT, ENT.AGENT.AI, ENT.RESOURCE.DATABASE
ACT (Actions)	200	ACT.QUERY.DATA, ACT.ANALYZE.SENTIMENT, ACT.CREATE.TEXT
PROP (Properties)	150	PROP.STATE.ACTIVE, PROP.PRIORITY.HIGH, PROP.QUALITY.VERIFIED
REL (Relations)	100	REL.DEPENDS.ON, REL.CONTAINS, REL.CAUSED.BY
LOG (Logic)	50	LOG.AND, LOG.OR, LOG.NOT, LOG.IF.THEN
MATH (Mathematics)	100	MATH.SUM, MATH.AVERAGE, MATH.COSINE.SIMILARITY
TIME (Temporal)	50	TIME.BEFORE, TIME.AFTER, TIME.NOW, TIME.DURATION
SPACE (Spatial)	50	SPACE.INSIDE, SPACE.NEAR, SPACE.ABOVE
DATA (Data Types)	100	DATA.LIST, DATA.DICT, DATA.UUID, DATA.TIMESTAMP
META (Protocol)	100	META.STATUS.SUCCESS, META.ERROR.TIMEOUT, META.HEARTBEAT

ACT.QUERY.DATA always means "request data." On every platform. In every framework. In every language. Today, tomorrow, and ten years from now.

No adapter needed. No mapping table. No "well, in our system it's called something different."

This is the approach behind the PULSE Protocol (Protocol for Universal Language-based System Exchange) — an open-source semantic communication standard with 1,000 predefined concepts.

The Complementary Architecture

Here's the key point: a semantic layer doesn't replace existing protocols. It completes them.

MCP + PULSE = Agents that connect to data AND understand what they're asking for
A2A + PULSE = Agents that coordinate tasks AND agree on what those tasks mean
ACP + PULSE = Agents that call each other AND speak the same language

PULSE doesn't compete with MCP, A2A, or ACP. It fills the gap that all three leave open.

It's the difference between having a phone network (infrastructure) and having a shared language (semantics). You need both. One without the other is incomplete.

Why This Matters Now

Gartner (2025): 40% of enterprise applications will integrate AI agents by 2026, yet communication barriers remain the primary cause of implementation failures.

McKinsey (2025): Organizations using multi-agent systems from multiple vendors achieve 3x higher ROI than single-vendor implementations. But only if those agents can actually collaborate.

The math is simple: If your agents can't understand each other, it doesn't matter which protocol they use to not understand each other.

The protocol war between MCP, A2A, and ACP will eventually settle — through market forces, standards bodies, or simple consolidation. That's a Layer 2 problem, and Layer 2 problems have Layer 2 solutions.

But the semantic gap — the Layer 3 problem — won't solve itself. It requires a deliberate, open, vendor-neutral vocabulary that every agent can share.

The AI industry has built the phone network. Now it needs a common language.

The Bottom Line

MCP is excellent at what it does. A2A is excellent at what it does. ACP is excellent at what it does.

But none of them do what actually matters most: give AI agents a shared vocabulary with zero ambiguity.

That's not a criticism of these protocols. It's a recognition that the hardest problem in AI communication isn't connecting agents — it's making sure they understand each other when they do connect.

The protocol that becomes the TCP/IP of AI won't be the one with the best message format. It will be the one that solves the meaning problem.

And that protocol needs to be open, semantic, and belong to everyone.

Try It Yourself

pip install pulse-protocol

from pulse import PulseMessage

# Universal semantic message — same meaning everywhere
msg = PulseMessage(
    action="ACT.QUERY.DATA",
    parameters={"query": "What is quantum computing?"}
)

# Works with OpenAI, Anthropic, or any other provider
from pulse_openai import OpenAIAdapter
adapter = OpenAIAdapter(api_key="sk-...")
response = adapter.send(msg)