UHP vs AGNTCY

The one-sentence difference

UHP standardizes how a client submits and controls work through a server that runs complete agent harnesses. AGNTCY provides a broader set of infrastructure components for discovery, capability description, identity/access, secure messaging, observability, and multi-agent collaboration.

AGNTCY therefore is not one alternative wire protocol to UHP. It is a Linux Foundation-hosted open-source stack whose components can sit around, before, or inside an agent execution topology.

Architectural comparison

Dimension	UHP	AGNTCY
Primary boundary	Product/client ↔ UHP server ↔ selected complete harness	Multi-agent infrastructure across discovery, identity, messaging, trust and observability boundaries
Main purpose	Normalize task/session/file/artifact execution across harness runtimes	Let agents and agentic services find, identify, communicate with, authorize and observe one another across frameworks and organizations
Discovery	GET /v1/uhp plus the UHP server’s harness/model catalog	Agent Directory Service stores and searches agent records; OASF describes skills, capabilities and metadata
Messaging	HTTP request/response plus SSE for the UHP execution lifecycle	SLIM provides secure peer/group messaging, streaming and RPC-style communication over an encrypted overlay
Identity / trust	UHP authenticates callers and scopes UHP objects; implementation-specific infrastructure may add more controls	AGNTCY Identity provides agent/tool identities, resolver metadata and verifiable credentials; Directory adds signed/verifiable records and workload trust mechanisms
Authorization	UHP defines object access and execution-boundary requirements, not a general multi-agent authorization framework	Identity/TBAC policy work addresses which agentic services may invoke services/tools and whether approval is required; task-bound authority remains evolving work
Observability	UHP streams protocol events and exposes execution results	AGNTCY includes multi-agent observability/evaluation components and continuous integration tooling
Version model	One date-versioned UHP protocol plus conformance classes	No single AGNTCY protocol version: Directory, SLIM, OASF, Identity and other components evolve independently
Can coexist?	Yes	Yes

AGNTCY is a stack, not one protocol

The Linux Foundation describes AGNTCY as open infrastructure for cross-vendor agent discovery, identity, messaging and observability. Its current documentation separates several components:

• Agent Directory Service (ADS): a distributed directory for publishing, verifying and discovering agent applications. Records are described with OASF and can be routed through a distributed content-routing/DHT model.
• OASF (Open Agent Schema Framework): the extensible data model used to describe agent attributes, skills and capabilities across ecosystems including A2A and MCP.
• SLIM (Secure Low-Latency Interactive Messaging): a secure messaging layer supporting point-to-point, group/multicast and RPC-style interactions, with TLS/mTLS at the transport layer and MLS-based end-to-end group/session encryption in its architecture.
• Identity: identifiers, resolver metadata and verifiable credentials for agents, MCP servers and multi-agent systems, with policy-oriented access control.
• Observability / evaluation and CSIT: telemetry/evaluation plus continuous system integration across multi-agent components and deployments.

Because these are separate components, a release number such as Agent Directory v1.7.0 is a software-component release, not an “AGNTCY protocol v1.7” standard.

Current discovery evidence: Agent Directory v1.7.0

AGNTCY Directory v1.7.0, released 18 August 2026, added an HTTP POST /v1/search API, an OASF extraction API, unified taxonomy extraction across CLI/gateway/import flows, routing improvements, OIDC token refresh, and AI Catalog UX work. The Directory’s documented protocol surface also includes storage, routing, search, signing/verification, naming, synchronization, events and runtime discovery.

This is a materially different layer from UHP discovery. UHP discovers the capabilities and harness catalog of a specific UHP server. AGNTCY Directory is designed to discover agent applications across a distributed directory network by attributes, constraints and skills.

A2A and MCP composition

AGNTCY explicitly positions itself as infrastructure that can interoperate with A2A and MCP rather than replace their native semantics. The Linux Foundation’s AGNTCY announcement describes A2A agents and MCP servers as discoverable through AGNTCY directories, while SLIM can serve as a messaging transport layer around agent collaboration.

The project’s 25 August 2026 Identity/TBAC article makes the layering especially clear for A2A. A2A can place a task into TASK_STATE_AUTH_REQUIRED, but the meaning, lifetime and revocation of the resulting authorization remain outside the A2A wire protocol. AGNTCY Identity supplies verifiable agent identity and a standing access-policy model; the article explicitly treats cryptographically task-bound authority as further profile work rather than a capability already standardized end to end.

Caution

Do not collapse implementation policy into protocol maturity. AGNTCY’s current documentation uses the acronym TBAC in evolving terminology, and the 25 Aug project article distinguishes standing policy that can be enforced today from task-bound authorization that is still being designed. This guide therefore describes the verified behavior rather than treating “TBAC” as a finalized cross-ecosystem standard.

How UHP and AGNTCY can coexist

A plausible layered deployment is:

Product / service
      │
      │ UHP
      ▼
UHP server → selected harness
                  │
                  ├── AGNTCY Directory / OASF → discover agent capabilities
                  ├── AGNTCY Identity         → verify identity / policy context
                  ├── SLIM / A2A / MCP        → communicate with agents or tools
                  └── Observability            → inspect multi-agent behavior

The diagram is architectural, not an adoption claim. A UHP-served harness could use AGNTCY components internally or alongside A2A/MCP, but current evidence does not establish a standardized UHP↔AGNTCY binding or native UHP adoption by AGNTCY.

What AGNTCY does not replace

AGNTCY’s infrastructure components do not define UHP’s complete harness-execution contract:

• They do not standardize UHP’s configured-harness selection/substitution behavior.
• They do not replace UHP response/session/container/file/artifact semantics.
• Directory discovery does not make a discovered agent a UHP server.
• SLIM messaging does not make an endpoint a UHP harness implementation.
• AGNTCY Identity or access policy does not by itself establish UHP conformance.

Conversely, UHP does not attempt to replace AGNTCY’s distributed cross-agent directory, general agent identity, encrypted multi-party messaging, or multi-agent observability layers.

Related pages

Read UHP vs A2A, UHP vs MCP, UHP vs ARD, Harness composition, and the ecosystem map for neighboring interoperability boundaries.

Primary sources

• AGNTCY documentation
• Linux Foundation: AGNTCY joins the Linux Foundation (29 Jul 2025)
• AGNTCY Agent Directory overview
• AGNTCY Directory v1.7.0 release
• AGNTCY Directory records and validation
• AGNTCY SLIM introduction
• AGNTCY SLIM authentication
• AGNTCY: Agent Identity and Task-Based Access Control with A2A (25 Aug 2026)
• UHP 2026-08-11 architecture