Agent Protocols Are Becoming a Stack, Not a Winner-Takes-All Standard

Short answer

The wrong question is:

Which agent protocol is going to win?

The better question is:

Which communication boundary are we designing?

That is the practical takeaway from A Technical Taxonomy of LLM Agent Communication Protocols. The paper looks at nine open-source agent communication protocols and classifies them along five dimensions:

• who the agent talks to
• what kind of payload moves across the boundary
• whether the interaction is stateful
• how the other side is discovered
• how flexible the message schema is

That sounds academic until you try to build a real agent system.

Then it becomes very useful.

Because “agent protocol” is currently used for several different jobs: tool access, API discovery, agent-to-agent delegation, long-running task state, identity, transport, registries, runtime schema negotiation, and sometimes all of the above in one breath.

No wonder the field feels noisy.

9

protocols classified in the taxonomy paper

5

dimensions: counterparty, payload, state, discovery, schema

0

reasons to expect one protocol to optimize every trade-off

The useful mental model is a stack:

L5  negotiation and deliberation    Agora, ANP-style schema negotiation
L4  task/session interaction        A2A, ACP, LAP, agntcy
L3  tool and context execution      MCP
L2  discovery and manifests         agents.json, LMOS-style discovery
L1  identity, auth, transport       ANP, AGNTCY, LMOS

This is not a standards claim. It is an engineering frame.

If you ask “which protocol wins?”, you will compare things that sit at different layers. If you ask “which boundary do I need?”, the landscape gets much less confusing.

Why agent protocols suddenly matter

Single-agent demos hide the communication problem.

One model, one prompt, a few tools, one orchestrator. You can wire that with custom JSON and a couple of SDK calls.

The problem appears when agents stop being a local implementation detail.

A coding agent wants to call repo tools. A support agent wants to delegate a billing question to another agent. A research agent wants to discover a specialized data provider. An enterprise agent wants to coordinate across vendors without exposing its internal chain-of-thought, memory, or proprietary tools.

At that point, you need more than “send a message to an LLM”.

You need contracts.

What protocols have to decide

• Counterparty: is the other side a tool, data source, API, human, agent, registry, or hybrid system?
• Payload: are we moving structured arguments, natural language, files, artifacts, events, or all of them?
• State: is this a one-shot call, a long-running task, a thread, a session, or a durable workflow?
• Discovery: does the caller already know the endpoint, query a registry, crawl a manifest, or discover peers?
• Schema: is the message shape fixed, selected from known schemas, or negotiated at runtime?

The taxonomy paper is valuable because it separates those questions.

It does not treat MCP, A2A, ACP, agents.json, Agora, ANP, LMOS, and AGNTCY as a pile of branding acronyms. It asks: what communication job does each protocol primarily serve?

That distinction is the difference between an agent architecture and a bundle of integrations.

The five dimensions in normal engineering language

The paper’s taxonomy uses five dimensions. Here is the practical translation.

1. Counterparty

Who is the agent talking to?

There are three broad cases:

agent   -> another autonomous agent
context -> tool, API, file, database, service, prompt, workflow
hybrid  -> both agents and context-like systems

This matters because an agent-to-tool call and an agent-to-agent handoff have different failure modes.

If a model calls a weather API, you want a typed request, a predictable response, auth, rate limits, and error handling.

If a model delegates to another agent, you also need task state, status, artifacts, partial progress, cancellation, permission boundaries, and maybe a negotiation about what the other agent can actually do.

MCP is strongest in the context/tool direction. Its official docs describe it as an open-source standard for connecting AI applications to external systems such as data sources, tools, and workflows. A2A, by contrast, describes itself as an open protocol for communication and interoperability between opaque agentic applications.

Those are not the same boundary.

2. Payload

What crosses the wire?

Some protocol interactions are mostly structured:

{
  "tool": "lookup_invoice",
  "arguments": {
    "invoice_id": "inv_381"
  }
}

Some are conversational:

Can you investigate why this invoice was rejected and return a recommendation?

Real agent-to-agent work tends to need both:

{
  "task": "investigate_invoice_rejection",
  "message": "Check whether this was caused by tax validation or missing PO.",
  "artifacts": ["invoice.pdf", "customer-thread.txt"],
  "expected_output_schema": "billing_rejection_report.v2"
}

That is why the paper finds that sampled agent-to-agent protocols are not purely conversation-focused. They use hybrid payloads: text plus structured data and artifacts.

This is the part many agent frameworks still under-design.

Natural language is a good control surface for intent. It is a bad sole carrier for state, permissions, identifiers, and audit evidence.

3. Interaction state

Is the interaction one-shot, or does it persist?

Tool calls can often be stateless:

input -> result

Agent collaboration rarely stays that simple.

A task may be created, accepted, paused, resumed, streamed, cancelled, handed back, or completed with artifacts. That requires a stateful unit of work. Different protocols call this different things: task, thread, run, session, conversation.

The paper’s clean finding: agent-to-agent protocols need session state. MCP and agents.json are closer to stateless context/tool/API-description patterns.

That gives you a good architecture rule:

If the other side can take time, make sub-decisions, stream progress,
or return artifacts later, model it as a task/session, not as a tool call.

4. Discovery

How does an agent know the other side exists?

There are several levels:

static config       hard-coded endpoint or local server
manifest           agents.json, agent cards, capability files
registry           central directory or platform catalog
decentralized      peer discovery, DID/web identity, crawlable descriptions
hybrid             a mix of the above

For internal tools, static config is fine. For enterprise agent platforms, registries become attractive. For an “Internet of Agents”, static config obviously breaks down.

This is where protocols such as ANP, LMOS, and AGNTCY become more interesting. They are not just “another way to send a message”; they care about identity, discovery, transport, and cross-domain operation.

But that also means they introduce more surface area.

Discovery is not just convenience. It is a trust problem.

If an agent can discover another agent, it can also discover a malicious or stale one. Capability descriptions can be outdated. Manifests can be poisoned. Registries can become policy bottlenecks. Decentralization shifts the problem from “where is the endpoint?” to “why should I trust this endpoint?“

5. Schema flexibility

Does the protocol define one message shape, a menu of message shapes, or allow agents to negotiate a new one?

This is where the paper becomes especially useful.

At one end, you have fixed schemas. They are boring and efficient. Good.

At the other end, you have runtime schema negotiation. Agora is the clearest example: agents can use natural language to establish a more efficient protocol for future messages. ANP also points in a direction where agents can negotiate payload formats and interaction structures.

That is powerful, but it is not free.

Runtime negotiation costs tokens, latency, observability, security review, and predictability. You do not want a payment agent casually inventing a new settlement protocol mid-task.

But for open-ended multi-agent research, cross-domain coordination, or agent networks where parties have never met before, negotiated schemas may be exactly the interesting part.

Fixed schema vs. negotiated schema

Fixed or predefined

• Predictable validation and lower latency.
• Better for payments, writes, tools, compliance, and audit.
• Easier to monitor and secure.
• Less expressive for novel tasks.

Negotiated at runtime

• Higher flexibility when agents do not share a schema yet.
• Better for open-ended collaboration and unknown counterparties.
• Harder to reason about because the contract itself can change.
• More token and governance overhead.

A practical map of the current protocol landscape

Here is the blog-sized version of the taxonomy.

It is deliberately opinionated.

MCP: the execution layer for tools and context

Model Context Protocol is best understood as agent-to-context infrastructure.

It standardizes how an AI application connects to external systems: files, databases, APIs, tools, prompts, workflows. Anthropic’s announcement frames MCP as an open standard for secure two-way connections between data sources and AI-powered tools.

Use MCP when the boundary looks like:

agent -> tool
agent -> data source
agent -> local service
agent -> workflow exposed as capability

Do not force MCP to become your full multi-agent task protocol unless your “agent” is really just a tool-like server.

MCP’s strength is the strictness: typed tools, resources, prompts, predictable request/response patterns. That strictness is exactly why it is useful.

agents.json: the manifest layer for API-shaped capability discovery

agents.json is closer to structured discovery than agent conversation.

Its repository describes it as a JSON schema of structured contracts for AI agents, built from existing OpenAPI specs so agents can run accurate API call sequences.

That is a specific and useful job:

What can this API do?
Which endpoints matter for an agent?
What sequence of calls should the agent understand?
Which examples help argument generation?

This belongs near the discovery/manifest layer.

It does not replace session-aware agent collaboration. It helps agents understand API-shaped workflows without a pile of brittle prompt text.

A2A: the task interaction layer for opaque agents

Agent2Agent describes itself as an open protocol for communication and interoperability between opaque agentic applications. Google’s announcement says A2A lets agents communicate, securely exchange information, and coordinate actions across enterprise platforms.

The word “opaque” matters.

In a real enterprise, one agent should not need to know how another agent is implemented. It should not care whether the remote agent uses LangGraph, CrewAI, a custom workflow engine, or a vendor platform.

The useful abstraction is:

Here is a task.
Here is the context I am allowed to share.
Here is the expected artifact.
Here is how we track progress.
Here is how we cancel or complete.

That is not a tool call. It is a task contract.

ACP: the REST-native agent communication layer

There are several “ACP” names in the ecosystem, so be careful.

The Agent Communication Protocol documentation frames ACP as a standardized RESTful API for agents, supporting modalities, synchronous and asynchronous communication, streaming, stateful and stateless operation, discovery, and long-running tasks.

IBM Research describes ACP as framework-, language-, and runtime-independent, lightweight, and HTTP-native.

That makes ACP interesting when your deployment environment wants a simple web-native integration surface:

HTTP-native agent messaging
long-running runs
streaming updates
artifacts
agent manifests
language/framework independence

In practical architecture conversations, ACP and A2A live near each other: session-aware agent interaction. The details differ, and governance may change, but the layer is similar.

Agora: the negotiation layer for open-ended collaboration

Agora is the most conceptually interesting protocol in this set because it leans into negotiation.

The Agora paper describes the Agent Communication Trilemma: agent communication wants versatility, efficiency, and portability, but optimizing all three is hard. Agora’s answer is not “pick one fixed message format forever.” It lets agents negotiate protocols.

In simple terms:

Start with natural language.
Agree on a more efficient interaction pattern.
Use that pattern for repeated communication.
Renegotiate when the situation changes.

That is attractive for open agent networks. It is also scary for high-risk systems.

Negotiated protocols are powerful when parties do not share a predefined schema. They are dangerous when you need deterministic authorization, audit, and compliance.

My rule:

Negotiate schemas for exploration.
Predefine schemas for execution.

ANP: the decentralized agent-network layer

Agent Network Protocol frames itself around decentralized identity, discovery, messaging, and payment protocols for interoperable AI agents. Its GitHub repo describes an open-source protocol for agent communication and an open, secure, efficient collaboration network for intelligent agents.

That is not just task messaging. That is a network thesis.

ANP becomes relevant when your problem is:

How do agents identify each other?
How are capabilities described?
How do peers discover one another?
How do agents communicate across domains?
How do payments or trust roots enter the picture?

Most teams do not need that on day one.

But if you believe in agent marketplaces, cross-company agent delegation, or public agent discovery, this layer matters.

LMOS: transport-flexible multi-agent infrastructure

Eclipse LMOS emphasizes open protocols and transport flexibility. Its docs explicitly avoid forcing a single transport such as HTTP, MQTT, or AMQP.

That is a different architectural instinct from “just expose a REST endpoint”.

LMOS is interesting for organizations that need agent communication across heterogeneous runtime environments, transport choices, and deployment patterns.

It sits closer to platform infrastructure than a small single-purpose protocol.

AGNTCY: API invocation plus internet-of-agents infrastructure

AGNTCY’s Agent Connect Protocol spec defines a standard API interface to invoke and configure remote agents, specified in OpenAPI. AGNTCY’s docs describe objectives around interoperability, security, scalability, and standardization.

That places AGNTCY in a broader internet-of-agents frame:

remote agent invocation
configuration
standard API schemas
identity and discovery ecosystem
security and scalability objectives

Again: this is not a drop-in replacement for MCP. It lives around a different boundary.

The layered-stack model

Here is the mental model I would actually use in architecture work.

Agent protocol stack

choose by boundary, not brand

1. 01
   Identity + transport
2. 02
   Discovery + manifests
3. 03
   Tool/context execution
4. 04
   Task/session interaction
5. 05
   Schema negotiation

Layer 1: identity, auth, and transport

Before agents collaborate, they need to know who is on the other side and how to reach them.

This layer answers:

Who are you?
Can I verify that?
What transport do we use?
What permissions apply?
Can this interaction cross domains?

ANP, LMOS, and AGNTCY are relevant here.

Layer 2: discovery and manifests

The next question is capability discovery:

What can this service or agent do?
Which schemas describe it?
Which examples help me call it correctly?
Where is the endpoint?
What version is this contract?

This is where agents.json, agent cards, manifests, registries, and LMOS-style discovery belong.

Layer 3: tool and context execution

Now an agent needs to use something.

Read this file.
Query this database.
Call this search tool.
Run this workflow.
Fetch this resource.

MCP is the obvious reference point here. Keep this layer boring. Strong schemas, strict tool permissions, logging, and no mystery.

Layer 4: task and session interaction

Now an agent needs another agent to do work.

Investigate this.
Draft this.
Negotiate with that system.
Return progress updates.
Attach artifacts.
Ask for clarification if blocked.

This is A2A/ACP territory.

The key difference from Layer 3 is autonomy. A tool executes a bounded operation. An agent may plan, call tools, ask questions, stream status, and return a result later.

Layer 5: schema negotiation and deliberation

At the top, agents do not just exchange messages. They may establish how to exchange messages.

We do not share a schema yet.
Let's agree on a compact representation.
Let's switch from natural language to structured messages.
Let's adapt the protocol because the task changed.

Agora and parts of ANP point here.

This is where agent communication becomes most powerful and least boring. Use it carefully.

Three example architectures

Example 1: Internal coding agent platform

You have a coding agent that works across repos, opens PRs, and asks specialized agents for help.

A reasonable stack:

Discovery: repo-level AGENTS.md, tool manifests, internal registry
Execution: MCP for git, file, test, issue tracker, docs search
Task interaction: A2A or ACP for delegating to security-review or database-migration agents
Identity/auth: internal SSO, service accounts, scoped tool permissions
Negotiation: mostly disabled

Do not let agents negotiate new schemas for production writes. Use predefined task contracts:

{
  "task_type": "security_review",
  "repo": "billing-service",
  "diff_ref": "pr-482",
  "required_output": "risk_report_v1",
  "allowed_tools": ["code_search", "dependency_audit"],
  "deadline_minutes": 15
}

The architecture principle:

Flexible planning inside the agent.
Rigid contracts at the boundary.

Example 2: Enterprise support agent network

A customer support agent needs to coordinate with billing, logistics, and compliance agents.

A reasonable stack:

Discovery: agent cards or registry for internal agents
Execution: MCP for CRM, order system, refund lookup, policy docs
Task interaction: A2A/ACP for billing investigation and compliance approval
Identity/auth: enterprise IAM, audit logs, per-agent scopes
Negotiation: no runtime schema negotiation for customer-impacting actions

The billing handoff should not be:

Hey, can you look into this refund?

It should be:

{
  "task_type": "refund_eligibility_check",
  "customer_id": "cus_913",
  "order_id": "ord_774",
  "policy_version": "refund-policy-2026-06",
  "requested_action": "eligibility_only",
  "must_not_do": ["issue_refund", "email_customer"],
  "return_schema": "refund_eligibility_report_v2"
}

That is why state and schema matter.

Example 3: Open agent marketplace

Now imagine agents discover external specialists on the open web: translation, legal summary, market research, logistics quotes, procurement, or domain data providers.

This is where the lower layers become much more important:

Identity: DID/web-style identity or verified organization profiles
Discovery: crawlable manifests, registries, reputational signals
Execution: MCP-like tool gateways for structured capabilities
Task interaction: A2A/ACP-like task contracts
Negotiation: maybe, but only inside sandboxed low-risk interactions

The hard problem is not “can two agents talk?”

The hard problem is:

Can my agent discover a counterparty,
understand its capability contract,
verify its identity,
limit what data is shared,
monitor the interaction,
and reject unsafe outputs?

That is a stack problem.

What to use when

The quickest way to make this practical is to stop naming protocols first.

Name the boundary first.

You need tool access

Use this shape when the agent needs a bounded capability:

read file
query database
search docs
run test
create ticket
calculate quote
fetch customer record

Prefer:

MCP or another strict tool/context protocol

The contract should be narrow:

{
  "name": "lookup_order",
  "description": "Read-only lookup for one order by id.",
  "input_schema": {
    "type": "object",
    "required": ["order_id"],
    "properties": {
      "order_id": { "type": "string" }
    }
  },
  "risk": "read_only",
  "returns": "order_snapshot_v1"
}

This is not the place for an agent to improvise. The whole point is that the model can ask for the operation and the harness can validate the call.

You need API discovery

Use this shape when the agent knows there is an API but does not know the right workflow:

Which endpoints matter?
Which endpoint comes first?
Which examples make argument generation reliable?
Which fields are safe to omit?

Prefer:

agents.json, OpenAPI extensions, agent cards, capability manifests

The contract is not the runtime conversation. It is the map.

{
  "workflow": "create_refund_request",
  "steps": [
    "GET /orders/{order_id}",
    "POST /refunds/eligibility",
    "POST /refunds"
  ],
  "agent_notes": [
    "Never call POST /refunds before eligibility is confirmed.",
    "If the order is older than 30 days, return an escalation draft."
  ]
}

This is where teams can get a lot of value without building a full agent network. Most APIs already have OpenAPI specs. The missing layer is agent-oriented workflow guidance.

You need another agent to do work

Use this shape when the remote side has autonomy.

investigate
draft
review
plan
negotiate
monitor
ask follow-up questions
return artifacts later

Prefer:

A2A, ACP, or a task/session protocol

The contract should look more like a work order than a function call:

{
  "task_id": "task_7fe",
  "kind": "vendor_contract_review",
  "input_artifacts": ["contract.pdf", "procurement_policy.md"],
  "constraints": {
    "max_runtime_minutes": 20,
    "no_external_network": true,
    "no_customer_contact": true
  },
  "return_artifacts": ["risk_summary.md", "redline_suggestions.json"],
  "status_callbacks": true
}

If the remote unit can decide how to work, use task semantics.

If it only executes one validated operation, use tool semantics.

You need cross-domain discovery

Use this shape when agents need to find counterparties outside one controlled platform:

public agent directory
vendor agent ecosystem
agent marketplace
cross-company delegation
dynamic supplier discovery

Prefer:

ANP, LMOS, AGNTCY-style identity/discovery/transport layers

But add a warning label:

Discovery is not trust.

Your agent still needs policy:

{
  "counterparty_policy": {
    "allowed_domains": ["trusted-vendor.example"],
    "requires_verified_identity": true,
    "max_data_classification": "internal",
    "human_approval_required_for": ["pii", "financial_commitment", "legal_claim"]
  }
}

Without that, discovery turns into a prompt-injection and supply-chain problem.

You need runtime negotiation

Use this shape when agents genuinely do not share a schema and the task is open-ended enough to justify negotiation:

multi-agent research
unknown scientific data formats
open-ended planning between unfamiliar agents
exploratory agent networks

Prefer:

Agora-like or ANP-style negotiation

But constrain it:

Negotiation may define how agents exchange notes.
Negotiation may not define new authority, payment, permissions, or irreversible actions.

That distinction matters.

Letting agents negotiate an output format is useful. Letting them negotiate what counts as approval is an incident waiting to happen.

Failure modes this taxonomy exposes

A taxonomy is only useful if it helps you see failures earlier.

Here are the failures I would watch for.

Failure mode 1: treating remote agents as tools

This happens when an orchestrator sends a complex task to another agent through a tool-call-shaped interface:

{
  "tool": "ask_billing_agent",
  "arguments": {
    "message": "Figure out if this refund is okay."
  }
}

It looks simple. It hides everything important.

There is no task id. No allowed actions. No expected output schema. No timeout. No status. No artifacts. No policy boundary. No way to tell whether the billing agent merely advised, actually issued the refund, or contacted the customer.

Better:

{
  "task_type": "refund_policy_analysis",
  "allowed_actions": ["read_order", "read_policy"],
  "forbidden_actions": ["issue_refund", "message_customer"],
  "output_schema": "refund_analysis_v2",
  "requires_human_approval_before_action": true
}

The fix is not a better prompt. The fix is the right protocol layer.

Failure mode 2: using chat history as protocol state

Agent systems often smuggle state through conversation:

Earlier we agreed that you would check compliance first.

That is not protocol state. That is a fragile memory.

If the task can span turns, retries, streams, callbacks, or handoffs, make state explicit:

{
  "task_state": "waiting_for_compliance_review",
  "completed_steps": ["order_lookup", "policy_lookup"],
  "blocked_actions": ["refund_execution"],
  "next_allowed_actions": ["attach_compliance_result", "cancel_task"]
}

The taxonomy’s interaction-state dimension is a useful forcing function: if the work is stateful, stop pretending it is a stateless message.

Failure mode 3: confusing capability discovery with permission

A manifest may say:

{
  "capability": "send_email",
  "description": "Send customer-visible email messages."
}

That does not mean your agent should use it.

Discovery tells the agent what exists. Permission tells it what is allowed. Policy tells it under which conditions. Audit tells you what happened.

Keep those separate:

manifest: this action exists
permission: this caller may request it
policy: this request is allowed under these facts
audit: this request happened with these arguments and approvals

Protocols can help with each layer, but they do not remove the need for the layer.

Failure mode 4: runtime schema negotiation in high-risk workflows

Schema negotiation is tempting because it feels intelligent.

Two agents can agree on a compact format. They can adapt to each other. They can reduce repetitive natural language.

But in high-risk workflows, the schema is part of the control surface.

If a schema changes, validation changes. If validation changes, policy checks can silently weaken. If policy checks weaken, a previously impossible action may become possible.

For high-risk actions, pin the schema:

payments
account permissions
production writes
customer-visible messages
private data transfers
legal or compliance decisions

For these, schema negotiation should happen offline, under review, versioned like an API contract.

A reference implementation shape

If I were designing a small production agent platform today, I would not start by “adopting all the standards.”

I would build the smallest stack that can evolve.

Step 1: classify every external boundary

Create a registry like this:

boundaries:
  github:
    type: tool_context
    protocol: mcp
    risk: writes_code
    state: stateless
  billing_agent:
    type: agent_task
    protocol: a2a_or_acp
    risk: financial
    state: session
  vendor_directory:
    type: discovery
    protocol: registry_manifest
    risk: supply_chain
    state: stateless

The protocol choice follows the boundary type.

Step 2: define payload classes

Do not let every integration invent its own payload vocabulary.

Use a few boring classes:

message       natural-language instruction or status
artifact      file, diff, report, screenshot, dataset
tool_call     typed operation request
task          stateful unit of work
event         progress, cancellation, error, completion
policy_note   approval, denial, missing evidence, risk flag

This is where most agent systems get sloppy. They pass everything as “message” and then wonder why audit is painful.

Step 3: put policy beside protocol

Protocol tells you how agents communicate.

Policy tells you whether the communication is allowed.

Keep a gate before any dangerous boundary:

Before sending this payload:
- What data classification is included?
- Is the counterparty verified?
- Is the action reversible?
- Does the user or operator approval exist?
- Is the schema version approved?
- Is the destination allowed for this tenant/customer/project?

This is not optional plumbing. It is the difference between an agent network and an exfiltration network.

Step 4: log at the boundary, not only inside the agent

Agent transcripts are not enough.

Log the protocol boundary:

{
  "protocol": "a2a",
  "schema_version": "task_contract_v3",
  "counterparty": "billing-agent",
  "task_id": "task_7fe",
  "payload_hash": "sha256:...",
  "policy_decision": "allowed",
  "allowed_by": "refund_policy_gate_v2",
  "human_approval_id": null
}

If something goes wrong, this is the evidence you will need.

Step 5: design for protocol churn

This field is not stable yet.

So isolate protocol adapters:

internal task model
        |
        +-- A2A adapter
        +-- ACP adapter
        +-- internal queue adapter
        +-- future protocol adapter

Do not let product logic depend directly on a protocol’s current naming scheme for “task”, “thread”, “run”, or “artifact”.

Map it into your own internal model first.

The selection checklist

Before picking a protocol, answer these questions.

1. Is the counterparty a tool, data source, API, agent, registry, or unknown peer?
2. Does the call need session state, or is request/response enough?
3. Does the payload need artifacts, files, streams, status updates, or only JSON?
4. Is discovery static, registry-based, manifest-based, or decentralized?
5. Can schemas be fixed ahead of time, or must they be negotiated?
6. What is the risk if the wrong counterparty receives the data?
7. What is the risk if the remote side lies about its capabilities?
8. Who logs the interaction, and at which layer?
9. Which actions require human approval or deterministic policy gates?
10. What breaks if this protocol disappears or changes governance?

That last question matters.

Agent protocol governance is moving quickly. Some projects start in companies, move to foundations, merge with adjacent efforts, or get reframed as part of larger ecosystems. Do not couple your whole agent architecture to one acronym unless you know which layer it owns in your system.

Anti-patterns

Choosing agent protocols

Do

• ✓ Pick protocols by boundary: discovery, execution, task state, identity, negotiation.
• ✓ Keep tool execution strict and boring.
• ✓ Use session-aware protocols when remote work can take time or produce artifacts.
• ✓ Treat capability manifests as untrusted input until verified.
• ✓ Log task ids, protocol versions, schemas, tool calls, and policy decisions together.

Don't

• × Ask one protocol to solve every layer.
• × Treat agent-to-agent delegation as a tool call with a longer prompt.
• × Allow runtime schema negotiation around money, permissions, production writes, or private data.
• × Assume discovery equals trust.
• × Confuse similarly named ACP protocols without checking the ecosystem and spec.

My read

The taxonomy paper is useful because it cuts through the hype.

MCP, A2A, ACP, agents.json, Agora, ANP, LMOS, and AGNTCY are not all trying to be the same thing, even when their marketing pages drift toward the same words: interoperability, agents, open protocol, ecosystem.

The real architecture question is where the contract sits.

MCP makes tool/context boundaries more standard.
agents.json makes API capability discovery more legible.
A2A and ACP make task/session delegation more explicit.
ANP, LMOS, and AGNTCY push toward identity, discovery, and cross-domain agent infrastructure.
Agora explores what happens when agents can negotiate the contract itself.

That is why a layered stack is more plausible than a single winner.

The internet did not settle on one protocol that does identity, routing, transport, discovery, document transfer, authentication, payments, and application semantics. It layered protocols and let each layer become boring enough to trust.

Agents will probably need the same discipline.

The near-term practical move is simple:

Do not standardize on an acronym.
Standardize your boundaries.

Once the boundaries are clear, the protocol choice gets much easier.

Sources

• A Technical Taxonomy of LLM Agent Communication Protocols
• arXiv abstract: A Technical Taxonomy of LLM Agent Communication Protocols
• Model Context Protocol introduction
• Anthropic: Introducing the Model Context Protocol
• Agent2Agent A2A GitHub
• Google Developers Blog: Announcing A2A
• Linux Foundation: Agent2Agent protocol project
• Agent Communication Protocol docs
• IBM Research: Agent Communication Protocol
• agents.json GitHub
• Agora Protocol
• Agora paper: A Scalable Communication Protocol for Networks of Large Language Models
• Agent Network Protocol GitHub
• Agent Network Protocol website
• Eclipse LMOS Protocol introduction
• AGNTCY Agent Connect Protocol spec
• AGNTCY docs
• Survey: Agent Interoperability Protocols
• Private research artifact: content-research/deepresearch/llm-agent-communication-protocols-taxonomy/report.md