OASF and Agent Connect Protocol (AGNTCY)

AGNTCY is an open-source infrastructure project under the Linux Foundation that defines how AI agents are described, discovered, connected, and observed across frameworks and vendors.

Posted Apr 14, 2026

11 min read

AGNTCY (pronounced “agency”) is an open-source infrastructure project – now under the Linux Foundation – that defines how AI agents are described, discovered, connected, and observed across frameworks and vendors. Its two core specifications are OASF (Open Agentic Schema Framework) for agent description and ACP (Agent Connect Protocol) for agent invocation over network APIs.

What is AGNTCY?

AGNTCY is a consortium-driven initiative originally launched by Cisco’s Outshift group in March 2025, with LangChain and Galileo as co-maintainers. By July 2025, over 75 companies had joined, and the project was donated to the Linux Foundation with Cisco, Dell Technologies, Google Cloud, Oracle, and Red Hat as formative members.

The project’s stated goal is building the “Internet of Agents” (IoA) – infrastructure that enables multi-agent applications to discover, compose, deploy, and evaluate agents regardless of the framework or vendor that built them. AGNTCY is not a single protocol but a suite of interrelated components:

Component	Purpose
OASF (Open Agentic Schema Framework)	Standardized schema for describing agent capabilities, identity, and metadata
ACP (Agent Connect Protocol)	REST API specification for invoking and configuring agents over a network
SLIM (Secure Low-Latency Interactive Messaging)	Transport layer providing encrypted, low-latency messaging between agents
Agent Directory	OCI-compliant registry for publishing, discovering, and verifying agent records

The Problem AGNTCY Solves

The multi-agent interoperability problem has multiple layers, and AGNTCY addresses ones that A2A and MCP do not:

Discovery: How does an orchestrator find the right specialist agent among thousands? A2A assumes you already know the agent’s URL. AGNTCY provides a registry and schema for searchable agent descriptions.
Identity and verification: How do you know an agent is what it claims to be? AGNTCY uses OCI-based cryptographic addressing to verify agent records.
Schema standardization: Every framework describes agent capabilities differently. OASF provides a single schema that works across A2A agents, MCP servers, and framework-specific agents.
Network-level communication: A2A defines the application protocol but not the underlying transport security. SLIM provides end-to-end encrypted messaging using the MLS (Messaging Layer Security) protocol.

In short: A2A tells agents how to talk to each other. AGNTCY tells the ecosystem how to find, trust, describe, and securely connect agents at infrastructure level.

Architecture

OASF (Open Agentic Schema Framework)

OASF is the data model layer. It defines a JSON schema for describing everything about an agent that another system would need to discover, evaluate, and invoke it.

An OASF agent record contains:

Identity: Name, version, authors, creation timestamp, unique identifier
Skills: Hierarchical capability taxonomy (e.g., natural_language_processing/natural_language_generation/text_completion)
Locators: URLs pointing to source code, Docker images, or API endpoints
Schema version: Semantic version of the OASF spec the record complies with
Extensions: Framework-specific metadata (A2A agent cards, MCP server descriptors, custom fields)

OASF Record Example

        
      
{
  "name": "https://agents.mms.de/service-desk-router",
  "version": "v2.1.0",
  "description": "Routes customer service requests to appropriate specialist agents based on intent classification and customer tier",
  "schema_version": "1.0.0",
  "skills": [
    {
      "id": 301,
      "name": "natural_language_processing/intent_classification"
    },
    {
      "id": 402,
      "name": "workflow/task_routing"
    }
  ],
  "authors": [
    "MMS AI Platform Team"
  ],
  "created_at": "2026-03-15T10:30:00.000Z",
  "locators": [
    {
      "type": "docker_image",
      "urls": [
        "registry.mms.de/ai-platform/service-desk-router:v2.1.0"
      ]
    },
    {
      "type": "api_endpoint",
      "urls": [
        "https://agents.mms.de/service-desk-router/acp"
      ]
    }
  ],
  "extensions": {
    "a2a": {
      "agent_card_url": "https://agents.mms.de/service-desk-router/.well-known/agent.json"
    }
  }
}

The key design choice: OASF is framework-agnostic. The same schema can describe a LangGraph agent, a CrewAI crew, a plain Python service, or an A2A-compliant agent. The extensions field allows each framework’s native metadata to be embedded without polluting the core schema.

ACP (Agent Connect Protocol)

ACP is the communication layer. It defines a REST API (specified in OpenAPI format) for how systems invoke agents over the network. ACP is deliberately simpler than A2A – it focuses on the mechanical act of calling an agent, not on multi-turn negotiation between peers.

ACP organizes around three primary resources:

Resource	Purpose
Agents	List and describe available agents, retrieve their ACP descriptors
Threads	Conversation/session context. A thread groups related interactions with an agent.
Runs	A single invocation of an agent within a thread. You create a run, provide input, and retrieve output.

ACP Invocation Flow

GET  /agents                          # Discover available agents
GET  /agents/{agent_id}               # Get agent descriptor and configuration schema
POST /threads                         # Create a conversation thread
POST /threads/{thread_id}/runs        # Start a run with input
GET  /threads/{thread_id}/runs/{id}   # Poll for status and output

ACP also supports:

Streaming: SSE-based streaming of run output for real-time UIs
Interrupts: Agents can pause execution and request input from the caller
Configuration: Each agent declares its configuration schema; callers pass config at run creation
Multi-turn: Multiple runs within a thread maintain conversational context

ACP vs. A2A

Aspect	ACP (AGNTCY)	A2A (Google)
Spec format	OpenAPI (REST)	JSON-RPC 2.0
Primary verb	Invoke an agent (client-server)	Collaborate between agents (peer-to-peer)
Discovery	Via OASF registry + Agent Directory	Via Agent Cards at well-known URLs
State	Thread-based sessions	Task lifecycle with state transitions
Streaming	SSE	SSE
Maturity	Experimental, active development	Production-ready, Google-backed
Governance	Linux Foundation (AGNTCY)	Google-led with industry partners

These protocols are complementary, not competing. ACP is closer to “how do I call this agent as a service” while A2A is “how do two autonomous agents collaborate on a task.” An enterprise could use ACP internally (simpler REST-based invocation) and A2A for cross-organization agent communication.

SLIM (Secure Low-Latency Interactive Messaging)

SLIM is the transport layer for scenarios where REST/HTTP is insufficient – high-frequency agent-to-agent messaging that needs low latency and strong security guarantees.

SLIM has two components:

SLIM Messaging Layer (Data Plane): Handles message routing and delivery. Uses the MLS (Messaging Layer Security) protocol for end-to-end encryption. Provides session management, group messaging, and efficient message distribution.
SLIM Controller (Control Plane): Manages node configuration, monitors network health, and provides admin interfaces.

SLIM matters for enterprise deployments where agents process sensitive data (PII, financial records, health information) and HTTP-level TLS is considered insufficient. The MLS-based encryption ensures that even if the transport infrastructure is compromised, message contents remain encrypted end-to-end.

Agent Directory

The Agent Directory is an OCI-compliant registry for publishing and discovering OASF agent records. Think of it as Docker Hub for agents – you push an agent record to the directory, and other systems can search for agents by capability, framework, or metadata.

Key properties:

OCI-based: Uses the same container registry standards as Docker, enabling integration with existing container infrastructure
Cryptographic verification: Agent records are content-addressed, so consumers can verify integrity
Searchable: Query by skill taxonomy, framework, author, or custom metadata
Federated: Organizations can run their own Agent Directory instances and federate with others

How It Works: End-to-End

A concrete scenario using AGNTCY components together:

Publish: An AI platform team builds a specialist agent and pushes an OASF record to their Agent Directory, describing its skills, API endpoint, and configuration schema.
Discover: An orchestrator agent queries the Agent Directory: “Find me an agent with natural_language_processing/summarization skill that supports ACP invocation.”
Evaluate: The orchestrator retrieves the OASF record, inspects the agent’s skills, configuration requirements, and locators.
Invoke: The orchestrator calls the agent via ACP: creates a thread, starts a run with input, and streams the response.
Secure: If the agents communicate frequently in real time, they establish a SLIM session for encrypted, low-latency messaging.
Monitor: Observability data flows through standard telemetry channels for performance tracking and debugging.

Key Concepts

Skill Taxonomy

OASF uses a hierarchical skill taxonomy to categorize agent capabilities. Skills follow a path-like format:

natural_language_processing/
  natural_language_generation/
    text_completion
    text_summarization
  intent_classification
  sentiment_analysis
images_computer_vision/
  image_segmentation
  object_detection
workflow/
  task_routing
  scheduling

This enables semantic search across agent registries – an orchestrator can find “any agent that does summarization” without knowing the specific agent name or vendor.

OCI-Based Agent Distribution

AGNTCY uses OCI (Open Container Initiative) standards for agent record distribution. This is a pragmatic choice: enterprises already have OCI registries (for Docker images), OCI tooling, and OCI security policies. By making agent records OCI artifacts, AGNTCY avoids requiring new infrastructure – agent discovery rides on existing container registry infrastructure.

Framework Bridging via OASF Extensions

The extensions field in OASF records is how AGNTCY bridges between ecosystems. An agent that supports both A2A and ACP can declare both in its OASF record:

        
      
{
  "extensions": {
    "a2a": {
      "agent_card_url": "https://agent.example.com/.well-known/agent.json"
    },
    "acp": {
      "endpoint": "https://agent.example.com/acp",
      "config_schema": { ... }
    },
    "mcp": {
      "server_url": "https://agent.example.com/mcp"
    }
  }
}

This makes OASF a meta-schema that unifies agent descriptions across protocols.

Aspect	AGNTCY (OASF + ACP)	A2A (Google)	ANP (Agent Network Protocol)
Primary focus	Agent description, discovery, invocation infrastructure	Agent-to-agent task collaboration	Decentralized agent networking
Discovery	Registry-based (Agent Directory + OASF)	Well-known URL Agent Cards	DID-based decentralized identity
Communication	REST (ACP) + encrypted messaging (SLIM)	JSON-RPC 2.0	HTTP + DID authentication
Schema	OASF (OCI-based, extensible)	Agent Card JSON	Agent description documents
Governance	Linux Foundation, 75+ companies	Google-led consortium	Community-driven
Transport security	MLS end-to-end encryption (SLIM)	Standard TLS	Standard TLS + DID verification
Maturity	Experimental, active development	Production-ready	Early stage

AGNTCY vs. A2A: Complementary Layers

The easiest way to think about the relationship: A2A defines the conversation protocol between agents (how they exchange messages, manage tasks, negotiate). AGNTCY provides the infrastructure layer underneath: how you find agents (Agent Directory), how you describe them (OASF), how you invoke them as services (ACP), and how you secure the transport (SLIM).

A production multi-agent system might use OASF to describe all agents in a unified registry, ACP for simple service-style invocations within a trusted network, A2A for complex multi-turn agent collaboration, and SLIM for encrypted agent communication in sensitive contexts.

AGNTCY vs. ANP

ANP focuses on decentralized, open-internet agent networking using DIDs and verifiable credentials. AGNTCY focuses on enterprise infrastructure using established standards (OCI, OpenAPI, MLS). They target different deployment models: ANP for the open web, AGNTCY for organizational and consortium-level agent infrastructure.

Current Adoption and Maturity

Status: Experimental with Strong Institutional Backing

AGNTCY is not yet production-ready in the way A2A or MCP are. The specs are actively evolving, APIs may change, and tooling is early. However, the institutional backing is significant:

Linux Foundation governance (donated July 2025) provides long-term stability
Formative members: Cisco, Dell Technologies, Google Cloud, Oracle, Red Hat
Core maintainers: Cisco (Outshift), LangChain, LlamaIndex, Galileo, Glean
75+ supporting companies as of mid-2025

What Works Today

OASF schema and Agent Directory are functional for agent registration and discovery
ACP spec is published in OpenAPI format with Python and TypeScript SDKs
SLIM has a reference implementation for encrypted messaging
Integration examples exist for LangGraph and other frameworks

What to Watch

Whether ACP converges with or diverges from A2A (Google is an AGNTCY formative member, suggesting eventual alignment)
OASF adoption as a universal agent description format – if it becomes the standard way to describe agents across protocols, its value compounds
SLIM adoption for enterprise scenarios requiring end-to-end encryption beyond TLS

Honest Assessment for Enterprise Adoption

For an enterprise AI platform today: use A2A for agent-to-agent communication (it is more mature and has broader adoption). Watch AGNTCY for its registry and discovery capabilities – OASF’s approach to unified agent description is genuinely useful and not replicated elsewhere. ACP may be worth adopting internally if your team prefers REST/OpenAPI over JSON-RPC for agent invocation. SLIM is worth evaluating if you handle sensitive data that requires encryption beyond transport-level TLS.

Spec Links

AGNTCY documentation: https://docs.agntcy.org
OASF schema: https://schema.oasf.agntcy.org
OASF GitHub: https://github.com/agntcy/oasf
ACP specification: https://spec.acp.agntcy.org
ACP GitHub: https://github.com/agntcy/acp-spec
ACP SDK: https://github.com/agntcy/acp-sdk
SLIM GitHub: https://github.com/agntcy/slim

References

AI & Agents, Protocols

agent-patterns

This post is licensed under CC BY 4.0 by the author.