Agent-to-Agent Protocols

The Coordination Model explains when many agents should collaborate at all. This chapter covers the narrower interoperability question: what protocol do they use when they need to talk to each other across runtime boundaries?

The field is converging on a small number of real protocol families. They are not interchangeable. Some are modern protocols for opaque, long-running agents. Some are broader protocol stacks for open agent networks. Some are historically important message languages that still explain the design space well, even if greenfield systems rarely start there today.

What counts as a protocol here

This chapter is only about systems that define a reusable wire-level or API-level contract for one agent to discover, invoke, exchange messages with, or coordinate with another.

That deliberately excludes:

framework-specific orchestration patterns, such as AutoGen-, CrewAI-, or LangGraph-native handoffs
internal message buses inside one product
tool protocols that are not primarily agent-to-agent, even when they are useful in an agent system

The short list

Protocol	Shape	What it standardises	Where it fits
A2A	JSON-RPC 2.0 over HTTP(S)	discovery, task lifecycle, streaming, async notifications, rich payload exchange	the clearest modern general-purpose agent interoperability protocol
ACP	REST over HTTP	agent manifests, runs, sessions, multimodal messages, async-first execution	a practical predecessor now folded into A2A
ANP	layered protocol suite	identity, naming, discovery, messaging, negotiation, payments	open cross-domain agent networks, especially where identity and federation matter
FIPA ACL	agent communication language	message structure and communicative acts	classic multi-agent systems and historical grounding
KQML	performative message language	intention-oriented message wrappers for knowledge exchange	precursor to later agent communication standards

A2A

Agent2Agent (A2A) is the strongest current candidate for general agent interoperability in application systems. It is designed for agents that are opaque to one another: they do not need to share internal memory, tools, or private reasoning state in order to collaborate.

The core shape is straightforward:

JSON-RPC 2.0 over HTTP(S) for requests and responses
Agent Cards for discovery and capability advertisement
synchronous, streaming, and asynchronous interaction modes
support for rich data exchange, including text, files, and structured payloads

That shape makes A2A a good fit when one agent wants to delegate a job to another agent as a bounded task rather than mount it as a local tool.

Source: A2A project README, A2A documentation

ACP

Agent Communication Protocol (ACP) approached the same problem through a more REST-shaped interface. It standardized agent discovery, long-running runs, sessions, multimodal messages, sync and async execution, and stateful or stateless interaction patterns.

ACP matters for two reasons:

it proved that agent interoperability can be practical with ordinary HTTP semantics rather than a framework-specific runtime
it is an immediate part of the lineage of the current ecosystem, because the ACP project states that it is now part of A2A under the Linux Foundation

So ACP is still worth knowing, but mostly as an important predecessor and migration path rather than the center of gravity for new greenfield work.

Source: ACP documentation, ACP repository

ANP

Agent Network Protocol (ANP) is broader than A2A or ACP. It is not just a request protocol for task delegation. It is a protocol stack for open agent networks.

Its published suite covers:

identity via did:wba
naming via WNS handles
agent description and discovery
end-to-end messaging with focused profiles for direct messages, groups, encryption, attachments, and federation
application-layer protocols such as agent payments

ANP is therefore most relevant when the problem is not merely “how does agent A call agent B?” but “how do many agents discover, authenticate, and communicate across domains in an open network?”

Source: ANP official site, ANP specification repository

FIPA ACL

FIPA ACL is one of the canonical historical standards in multi-agent systems. Its focus is the structure of messages and the semantics of communicative acts such as informing, requesting, proposing, or agreeing.

It still matters conceptually because it captures a durable truth: agent communication is not only payload transport, but also the explicit declaration of intent. Modern protocols solve that problem differently, but they are still solving it.

In practice, FIPA ACL is more useful today as conceptual background, interoperability history, and a reference point for protocol design than as the default choice for modern web-native agent systems.

Source: FIPA ACL Message Structure Specification

KQML

KQML (Knowledge Query and Manipulation Language) predates much of the current agent ecosystem and introduced the idea of performative message wrappers around content: ask, tell, advertise, recommend, and so on.

Like FIPA ACL, KQML is mainly important now because it defines the older end of the design space. It shows that the current A2A discussion is not completely new; the industry is revisiting long-standing agent communication problems with modern transports, modern security assumptions, and web-native deployment models.

Source: KQML overview

Adjacent systems that are not the same thing

The most important nearby protocol is MCP. MCP is highly relevant to multi-agent systems, but it solves a different problem.

MCP standardises how a model or agent talks to a tool or capability provider
A2A / ACP / ANP standardise how one agent or agentic application talks to another

That boundary is not absolute. An agent can expose an MCP server and another agent can treat it as a tool endpoint. But the integration model is different:

MCP is strongest when the caller wants tool invocation
A2A-style protocols are strongest when the caller wants delegation to another autonomous runtime with its own lifecycle and interaction model

Framework-native handoff systems should also be kept separate from protocols. They may provide excellent orchestration inside one stack, but they do not by themselves create cross-vendor interoperability.

Selection heuristic

For the kinds of systems described in this book, the selection rule is simple:

choose A2A when the primary problem is interoperable task delegation between opaque agents or agentic applications
choose ANP when the primary problem is open-network identity, discovery, federation, and cross-domain communication
know ACP because it explains part of the current ecosystem lineage and may still appear in deployed systems
know FIPA ACL and KQML because they explain the history and semantics of agent communication, not because they are the obvious default for new web-native builds

Why this matters for Ikidna

Ikidna does not need a protocol society for its own sake. It needs a disciplined way to compose specialized runtimes without collapsing them into one giant context window.

That makes agent-to-agent protocols valuable at the boundaries where:

one orchestrator delegates to a specialist runtime
one agent advertises a stable capability to others
long-running work needs progress, resumability, or asynchronous completion
systems owned by different teams or vendors need a clean interoperability contract

It does not change the rule from The Coordination Model: protocol support can make delegation cleaner, but it does not make unstructured collaborative writing safe.

The Coordination Model: when collaboration helps, and when it breaks
MCP: the neighboring protocol for tool interoperability
Orchestrator: the component that usually owns delegation
Agent Pool: where outbound interoperability surfaces are configured
Swarm Operations: the production concerns once many runtimes are in flight