Exploring Agntcy Agent Connection Protocol (ACP), a contender to MCP and A2A?

Written By Madjid Nakhjiri

Having spent a lot of time looking multi-agentic AI system and their communications mechanisms, such as Model Context Protocols and Agent to agent (A2A) over the last few weeks, someone referred me to yet another framework called Agent Connect Protocol (ACP) from AGNTCY.

AGNTCY is a collaborative open-source project with contributions from companies including Cisco, LangChain, LlamaIndex, Galileo, and Glean that have supported the launch of AGNTCY.

Interesting terms:

  • Internet of Agents (IOA): similar to IoT, but for agents

  • MAA: Multi-agent applications

  • MAS: Multi-agent systems; includes internal agent-to-agent communication using local APIs. IOA refers to agents built by different parties communicating across MAS boundaries.

Core Components

Documentation and introduction are available here.

  • Agent Identity: Enables decentralization, allowing agents from any provider to be (hopefully uniquely) identified.

  • Open Agent Schema Framework: Extensible data model describing agents and their attributes. Supports unique agent identification for content discovery and consumption.

  • There is a GitHub repository for a schema server (HTTP server) that hosts schemas and provides schema validation services.

  • A taxonomy of AI agent skills is available, listing skills like NLU/NLG, classification, summarization, similarity, tone/styling, etc. (around 20-30 skills currently).

  • There is contribution guideline on how to add to the schema list and only time will tell how this will grow.

Agent Directory

Any organization can host its own agent directory and collaborate with other organizations to build an IOA inventory. These directories may assist other orgs' clients with agent discovery.

Noteworthy: although I have not seen the notion of directory in MCP, I did not see an agent naming convention or agent identity, credential scheme. There is current ongoing proposals for MCP to include tool identification and description schemas that are signed to avoid tool spoofing and allow origin authentication. 

Agent Manifest

A standard format for describing agent capabilities, supported schemas, and data structure definitions (input/output/configuration). Manifests are stored in agent directories. Examples are available here.

Noteworthy: I would hope manifest signing will be included in the framework in the future to allow verification of the agent identity and behavior by the consumers outside provider organization.

Agent Connect Protocol (ACP)

Detailed in the Syntactic SDK, this protocol defines how to:

  • Authenticate callers to agents. Each agent advertises supported authentication methods via a public endpoint (no authentication required to access this info). Authorization is out of scope. There's no mechanism for the caller to trust the agent (unlike MCP tool identification).

  • Configure a remote agent via a separate control endpoint. This is done through a separate “control” endpoint that is different from invocation endpoint. Configuration is done using specific schemas and can return errors. 

  • Invoke: Define how to invoke (trigger execution) a remote agent providing input for its execution. How the agent takes input (per schema definitions), optional invocation-specific configuration (just for that invocation), optional execution identifier (in case execution was interrupted go back to the execution using this identifier)

  • Retrieve Output: Synchronous (agent completed execution but had to interrupt to ask for more input), asynchronous (via callback), or streaming (partial output because agent is still running).

  • Describe Capabilities and Schemas: Referenced from the agent manifest.

  • Error Handling: Structured error messages with codes and descriptions.

A diagram on the ACP page illustrates client-server interaction, with similarities to MCP (client calls server to discover and invoke agents/tools).

Agent Gateway Protocol (AGP)

This is offered as the "Messaging SDK" and is used for agent-to-agent communication across networks. Each organization runs one agent gateway which communicates with others via AGP.

This resembles a VPN/router design (surprise coming from Cisco!), where each org operates its own gateway and directory. Org A's gateway talks to Org B's over AGP.

Credit: AGNTCY AGP page, picture showing agents from two orgs with different set of agents interacting with each other.

Security Considerations

  • Agent ensemble security is mentioned but not detailed.

  • There is currently no robust agent identity, naming, or credential scheme.

  • No discussion of spoofing or origin authentication, which upcoming MCP proposals will be addressing with signed tool identifiers.

Summary

Bottom line, when it comes down to protocol, this is very similar to MCP, there are client and servers. ACP calls executing components agents, MCP calls them tools. Still client interacts with agent through server.

Having agent gateways sounds a little weird and it kinds of gives away that this protocol is coming from a routing company:)

I like the notion of agent directory but the details on identification and security is thin at the moment.

there is mention of Agent ensemble security but not much details here.  When it comes to identifying agents in a unique way, authenticating agents and their users with cryptographic credentials, avoiding agent spoofing and poisoning (discussions that are taking place around MCP, I did not see anything here.


Madjid Nakhjiri
Next

Secure GPU Virtualization: Saving AI Inference Costs and Staying Ahead of Attackers with AMTD