Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

UHP glossary

Short definitions for the terms used across the Unified Harness Protocol specification and this independent guide.

Page reviewed 4 Oct 2026 Source and review policy

Protocol: 2026-09-28Static SSG

Find the term for your task

Choose the boundary first: UHP runs a configured harness; other formats may describe its configuration, distribute its skills, discover it, or record what it did. Similar names do not make those contracts interchangeable.

Reader question	Terms to start with	Continue here
Which runtime and configuration will execute my request?	Base and configured harness, client, server	Harness discovery and configuration
How do I continue work or retrieve its files?	Response and session, container, artifact	Session lifecycle and artifacts
Does a server support the feature my client needs?	Conformance and capabilities	Conformance evidence
How is an extension packaged or made available?	Skills and plugins	Harness Plugins and Skills Over MCP
What is being discovered, identified or recorded?	Adjacent terms: ARD, AI Catalog, AIP, ATIF	MCP boundary comparison

Three common ambiguities deserve special attention. A UHP container is a file namespace, so its existence does not establish Docker execution or sandbox isolation. A UHP artifact is an output file; AI Catalog uses “artifact” more broadly for a catalogued resource, which can be an MCP server, agent description or package. A client in Agent Plugins is the package-loading host; a UHP client is the application requesting harness work. Name the contract when discussing any of these terms.

Core UHP terms

Agent harness

A complete agent runtime around a model, including its execution loop, tools and session state.

Base

A stable identifier for a harness family, such as codex, claude-code or hermes.

Configured harness

A harness base plus runtime configuration such as model defaults, instructions, restrictions, skills, MCP servers and budgets. It has a server-assigned identifier: a base such as codex names the family, while a configured-harness ID selects the actual configuration for work. Two configurations of the same base need not behave alike.

Client

The application speaking UHP to request work.

Server

The UHP implementation that accepts tasks and drives one or more harnesses.

Environment

Reusable project files and installed dependencies built into a version, mounted read-only beside a session’s writable workspace. Harness defaults use environment; a task override uses metadata.environment. See Environments.

Harness Plugin

An Agent Plugins package attached to a configured harness through UHP’s optional plugins capability. This differs from HarnessRouter Runtime Plugins, which connect workspace services. See Harness Plugins.

Response

One atomic unit of work: a task request and its resulting state/output. The response object is the task record, rather than a synonym for an HTTP response or one model completion. A response can include multiple tool/model steps before reaching its terminal state.

Session

A chain of responses sharing conversation context, workspace and configured harness. The first task creates a session implicitly; previous_response_id continues the session of an earlier response. Continuing a session does not create a new configured harness.

Container

The file namespace associated with a session.

Artifact

A file produced by agent work and made available through the protocol.

Event

A streamed fact describing progress, delivered through the event stream.

Conformance class

Core, Extended or Full; each class defines a cumulative set of mandatory server capabilities. A class declaration describes the promised surface; a conformance result additionally needs the protocol version, suite revision, executed checks and failures/skips. An older report keeps its original denominator when the suite grows.

Capability discovery

The server document at GET /v1/uhp describing versions, conformance class and supported features. Check optional capabilities independently of class: the optional environments feature is not implied by the word Full. A client should discover the target server rather than infer support from a repository README.

Adjacent terms

MCP

Model Context Protocol, an open protocol for connecting AI applications to tools, resources and prompts. It addresses a different boundary from UHP. The 2026-07-28 release also formalizes opt-in extensions, including the released Tasks extension for asynchronous long-running operations.

Skills over MCP

The published MCP extension for discovering and retrieving Agent Skills through MCP Resources. Its io.modelcontextprotocol/skills capability, skill discovery/retrieval and resource reads are distinct from installing an Agent Plugins package. Client and server support must be checked independently. See Skills Over MCP for the current contract and evidence.

AI Catalog

An emerging common catalog/trust envelope for heterogeneous AI artifacts. The working draft uses application/ai-catalog+json, identifies native artifacts by media type, supports nested catalogs, and can attach an optional Trust Manifest for identity, attestations and provenance without redefining the underlying artifact format. The project is maintained in a temporary Linux Foundation working repository by contributors from MCP, A2A and other ecosystems; its own adoption plan says MCP and A2A steering committees would vote after finalization, so it is not treated here as already adopted by either protocol.

AIP (Agent Identity Protocol)

An overloaded name currently used by multiple independent agent-identity proposals rather than one canonical standard. The proposals include Cao/Arango’s registry-and-enforcement-proxy model (an expired draft at this review), Singla’s decentralized DID/delegation model, Prakash’s Invocation-Bound Capability Token model for attenuating single- or multi-hop authority, and the qualified OpenA2A AIP identity/capability/trust model. OpenA2A’s repository specification 1.2.0-draft and its Internet-Draft revision -03 are separate coordinates. The IETF Datatracker states that these individual Internet-Drafts are not IETF-endorsed standards. Use the author/project or exact draft identifier when referring to AIP. These identity/authorization layers are distinct from UHP’s complete-harness execution contract. See UHP vs AIP.

ARD (Agentic Resource Discovery)

A pre-invocation federated-discovery specification whose current published version is v0.91, status Proposal, dated 26 Aug 2026. v0.91 defines a distinct JSON-LD ARD entry and self-contained ARD conformance while retaining compatibility with catalog entries. Consumers resolving a domain MUST fetch /.well-known/ard.json and honour rel="ard"; the predecessor /.well-known/ai-catalog.json / rel="ai-catalog" names are optional compatibility lookups (MAY), not required fallbacks. The specification repository also publishes schemas, OpenAPI and a zero-dependency conformance CLI. ARD stops at discovery and hands execution/authentication to the resource’s native protocol. See UHP vs ARD.

AGNTCY

A Linux Foundation-hosted open-source infrastructure stack for cross-framework agent discovery, capability description, identity/access, secure messaging and observability. Its components include Agent Directory Service, OASF, SLIM and Identity; they evolve independently rather than sharing one AGNTCY protocol version. AGNTCY is adjacent infrastructure, not UHP’s client↔server↔complete-harness execution contract. See UHP vs AGNTCY.

ATIF (Agent Trajectory Interchange Format)

An Active Harbor RFC for portable JSON records of complete agent trajectories. The current Harbor RFC changelog is v1.8; the schema can represent messages, reasoning, tool calls, observations, metrics, continuation data and embedded subagent trajectories. ATIF is used for debugging, replay, evaluation and training-oriented workflows rather than live harness control. The NVIDIA NeMo Relay exporter documentation names ATIF v1.7, a separate implementation coordinate. RFC v1.8 adds stored audio content (path, media type and optional duration); it excludes streaming real-time PCM. Neither format version establishes a live execution or session-resume interface. See UHP vs ATIF.

Agent Skills

A lightweight, open format for reusable agent capabilities. A skill is a folder centered on SKILL.md, with metadata and instructions plus optional scripts, references, assets and other resources. The required YAML frontmatter includes name and description; optional resources are loaded as needed. The allowed-tools field is experimental and its support varies by host, so packaging a skill does not by itself establish an enforced tool permission. Agent Plugins uses Agent Skills as one of its portable component types; Agent Skills itself is not a UHP feature.

Agent Plugins

An open, vendor-neutral package standard for distributing reusable components that extend AI agents. The published 1.0.0 format uses a root plugin.json manifest and can package Agent Skills under skills/ plus MCP server configuration in mcp.json; 1.1.0 is a working draft. It standardizes plugin packaging/discovery; the client controls installation, enablement and marketplace trust. A package being valid does not establish that a particular host loaded it, exposed its MCP tools, or enabled UHP’s optional plugins capability.

Harness Protocol (harnessprotocol.io)

A separate open specification for portable harness configuration using harness.yaml. Its current changelog records specification release v1.1.0 on 27 Jul 2026: the v1 Schema layer is the configuration contract, HEP-7’s signed consent-first Exchange layer is Accepted/shipped, and Registry HEP-8 remains in Review and unreleased. The README still uses Candidate wording for Schema while the changelog calls it stable; preserve that source distinction instead of assigning one maturity label to every layer. See UHP vs Harness Protocol.

Harness Protocol v1 (SuperQode)

A separate SuperQode-internal control-plane contract using the same generic name. It normalizes session, event and evidence behavior across SuperQode Core, direct Python harnesses and an ACP adapter. It is not the harnessprotocol.io specification and is separate from SuperQode’s UHP client implementation.

AHP (Agent Host Protocol)

Microsoft’s synchronized multi-client state protocol for authoritative agent-host sessions. It coordinates shared host/session state and can layer over ACP, but it does not replace UHP’s complete-harness execution contract. See UHP vs Agent Host Protocol.

AHP (Agentic Hypercall Protocol)

An unrelated active individual Internet-Draft, draft-campbell-agentic-market-00, for agents to discover, invoke, pay for and rate tools over HTTPS. It proposes /.well-known/ahp.json discovery, OpenAPI tool descriptions, HTTP 402 payment, optional blind settlement and signed transaction/reputation evidence. It is not an RFC or IETF-endorsed standard. See UHP vs Agentic Hypercall Protocol.

An upstream agent harness integrated by HarnessRouter Community Edition as a backend (v0.7.0). HarnessRouter also installs an MCP adapter for this path. Pi integration is a HarnessRouter implementation fact, not proof that the Pi project adopted UHP natively.

DeepSeek Harness

An upstream open-source agent harness from DeepSeek AI (developer preview, MIT licensed) integrated by HarnessRouter Community Edition as the dsh backend (v0.8.0). Integration is not proof of native UHP adoption by DeepSeek.

LLMTR

A Turkey-hosted model gateway added by HarnessRouter v0.6.0 as a provider. It is a HarnessRouter provider integration, not a UHP protocol feature.

Find the term for your task

Core UHP terms

Adjacent terms

Primary sources