Skip to content
UHPUHPDeveloper Guide
Independent resource · Not affiliated with HarnessRouter · Site data checked 17 Sep 2026

Comparison

UHP vs Natural Language Interaction Protocol (NLIP)

UHP standardizes how a client asks a server to execute work on a selected complete harness. NLIP is an Ecma standards suite for application-level multimodal communication between AI agents or between a human and an AI agent.

Verified: UHP: 2026-09-12 · DraftNLIP: ECMA-430–434 · 1st edition

The one-sentence difference

Section titled “The one-sentence difference”

UHP standardizes complete-harness task execution behind a server boundary; NLIP standardizes multimodal application-level communication between AI agents, or between a human/client and an AI agent.

The overlap is interoperability, not protocol role. UHP deliberately hides harness execution details behind a server-owned task/session/file model. NLIP standardizes messages exchanged across an agent communication boundary and supplies transport bindings and mandatory security-profile requirements for conforming implementations.

Current status

Section titled “Current status”

Ecma International’s 130th General Assembly approved the first NLIP standards suite on 10 December 2025. The currently published suite is:

  • ECMA-430, 1st edition — the core Natural Language Interaction Protocol. Ecma defines NLIP as an application-level communication protocol between AI agents or between a human and an AI agent.
  • ECMA-431, 1st edition — binding over HTTP/HTTPS.
  • ECMA-432, 1st edition — binding over WebSocket, using CBOR for compact multimodal communication with UTF-8 JSON text frames as a compatibility fallback.
  • ECMA-433, 1st edition — binding over AMQP.
  • ECMA-434, 1st edition — Agent Security Profiles. Ecma states that conformance to ECMA-434 is mandatory for any implementation claiming NLIP conformance.
  • ECMA TR/113, 1st edition — an informative implementation/explanatory guide rather than a standard; where it conflicts with the standards, the standards take precedence.

Ecma’s publication summary describes the core NLIP message model as multimodal, covering text, structured data, binary content and location information. Its bindings place that model on web, bidirectional socket and enterprise messaging transports rather than tying NLIP to one transport.

UHP’s current published protocol remains 2026-09-12 Draft with conformance package 2026.9.12 and 74 checks. UHP defines a Client → Server → Harness architecture: the client speaks UHP to a server, and the server owns how a complete harness is executed. No reviewed primary source at this cutoff establishes a standardized UHP↔NLIP binding, native NLIP support in HarnessRouter, or native UHP support by the NLIP project.

Architectural comparison

Section titled “Architectural comparison”
DimensionUHP 2026-09-12NLIP ECMA-430–434, 1st edition
Primary boundaryProduct/client ↔ UHP server ↔ complete harnessAI agent ↔ AI agent, or human/client ↔ AI agent
Primary purposeExecute work through interchangeable configured harnessesExchange application-level multimodal messages across agent communication boundaries
Main abstractionServer-owned Responses, Sessions, Files/Containers and EventsNLIP messages/envelopes carried through standardized bindings
Harness semanticsHarness is a complete runtime with its own loop, tools and session state; server execution details are hidden from the clientAgent internals and harness execution are not standardized as UHP-style server/harness lifecycle objects
TransportHTTP/1.1 or later over TLS; JSON bodies; SSE streaming; file-specific media typesCore protocol plus separate HTTP/HTTPS, WebSocket and AMQP binding standards
Transport encodingJSON for ordinary protocol objects; SSE for event streamingBinding-specific; WebSocket uses CBOR with UTF-8 JSON fallback
Task/session modelResponse is one task; Session chains responses and working-directory continuityCommunication/session behavior belongs to NLIP’s message and binding semantics rather than a UHP Response/Session object model
Execution portabilityClient can change configured complete harnesses without learning harness-specific execution detailsCommunicating peers can use a common agent interaction protocol without sharing internal implementation technology
Security boundaryBearer authentication plus principal-scoped protocol objects; execution isolation remains server responsibilityECMA-434 defines mandatory Agent Security Profiles for an implementation claiming NLIP conformance
MaturityDraft protocol with runnable conformance suitePublished Ecma standards suite, 1st edition December 2025

The protocols solve different substitution problems

Section titled “The protocols solve different substitution problems”

UHP’s substitution target is the complete harness behind a server. A product can submit the same class of task to a configured codex, claude-code, hermes or other harness without embedding each harness’s native CLI/session/tool contract into the product. The server converts the selected harness into UHP’s task, event, artifact and continuation model.

NLIP’s substitution target is the communication contract between participants. The standard is designed so human-facing clients and AI agents, or multiple AI agents, can exchange natural-language and structured/multimodal content through a common application-level protocol across standardized transports.

Those goals can coexist. An agent hosted behind UHP could also communicate externally through NLIP, or an NLIP-facing agent could internally delegate work to a UHP server. That would be an implementation composition, not an implied mapping between NLIP messages and UHP Responses/Sessions. Neither standards suite currently defines such a bridge.

Transport overlap does not make the protocols equivalent

Section titled “Transport overlap does not make the protocols equivalent”

Both UHP and NLIP can use HTTP, but transport reuse is not protocol equivalence.

UHP defines a specific server API around harness discovery, task execution, continuation, cancellation, files/artifacts and session lifecycle. HTTP is the carrier for that execution contract, with SSE for its event stream.

NLIP separates its core application protocol from transport bindings. ECMA-431 maps NLIP to HTTP/HTTPS, ECMA-432 to WebSocket and ECMA-433 to AMQP. A conforming NLIP exchange over HTTP is therefore still an NLIP agent-communication exchange; it does not become a UHP harness task simply because both use HTTP.

Security and conformance need separate reading

Section titled “Security and conformance need separate reading”

ECMA-434 is a notable structural difference from many adjacent agent-protocol projects: Ecma explicitly says its security-profile standard is mandatory for any implementation claiming NLIP conformance. The security document defines Agent Security Profiles and mandatory requirements for an NLIP agent, while leaving detailed implementation techniques outside the standard.

UHP has a different conformance model. Its conformance classes test the UHP server contract, including capability discovery, task execution, continuation, cancellation and progressively larger file/session/lifecycle surfaces. UHP also requires server-side principal scoping of protocol objects. A passing UHP suite result is therefore not evidence of NLIP security-profile conformance, and NLIP conformance is not evidence that an implementation satisfies UHP’s harness execution contract.

Why NLIP belongs in the interoperability map

Section titled “Why NLIP belongs in the interoperability map”

NLIP is not merely another repository-level proposal. The core protocol, three transport bindings and security-profile document are published Ecma standards under TC56, with a separate explanatory Technical Report. That gives it a different standards status from experimental drafts and project-specific adapters covered elsewhere in this guide.

It also occupies a boundary that can be confused with UHP when both are described broadly as “agent interoperability.” Keeping the distinction explicit prevents three category errors: treating agent-to-agent messaging as harness execution, treating a common transport as a common protocol, or treating support for one standards suite as adoption of the other.

What not to infer

Section titled “What not to infer”
Section titled “Related pages”

See UHP architecture, UHP vs A2A, UHP vs ACP, UHP vs MCP and UHP vs AG-UI for neighboring execution, agent-communication, client-integration, tool/context and event/UI boundaries.

Primary sources

Section titled “Primary sources”