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

UHP vs Agent Plugins

UHP 2026-09-28 retains the optional Harness Plugins binding introduced in 2026-09-12, using Agent Plugins 1.0.0 packages. Execution and package portability remain different boundaries.

Page reviewed 4 Oct 2026 Source and review policy

UHP: 2026-09-28Agent Plugins: 1.0.0 Published

Select the package, binding and host policy separately

Agent Plugins 1.0.0 remains Published in the primary specification reopened 4 October 2026. UHP 2026-09-28 Draft defines an optional Harness Plugins binding around such packages. Neither document makes a package install trustworthy merely because its archive layout is valid.

Your task	Contract to use	What remains your responsibility
Ship reusable skills, commands or MCP configuration	Agent Plugins package format	Content provenance and dependencies
Attach a package to a UHP configured harness	Harness Plugins	Discover support; map host policy and effective configuration
Provide a workspace service such as browser access	Runtime Plugins where implemented	Service lifetime, credentials and runtime authorization
Load a remotely served skill without installing a package	Skills Over MCP	Held manifest, origin and content approval

A practical rollout starts with a package containing one skill and no executable hooks. Check format compatibility, discover the server’s optional plugin support, attach it to a dedicated harness configuration, and inspect the effective skill/tool surface. Add executable components only after their host admission and dependency paths are understood. A package that installs successfully can still be absent from the selected harness or denied by policy.

The Hermes and client case studies below explain specific implementations at their cited commits. Their pins are evidence of those revisions, not a fresh assertion that every host has the same catalog, dependency resolver or memory-provider behavior.

Different portability boundaries, now with a standardized binding

Unified Harness Protocol (UHP) defines a common HTTP execution contract between an agent product and a server that drives complete harness runtimes. Its portable surface includes discovery, tasks/responses, sessions, progress, files/artifacts, cancellation, structured errors and optional higher-class capabilities.

Agent Plugins is a separate open, vendor-neutral packaging standard. Published 1.0.0 defines a plugin directory with a required root plugin.json, optional Agent Skills under skills/, and optional MCP server configuration in mcp.json. Installation sources, registry/marketplace policy, enablement UX, permission prompts and general client sandboxing remain client-managed.

The important change is UHP 2026-09-12: its new optional Harness Plugins sub-protocol says that a UHP plugin is an Agent Plugins 1.0.0 package. UHP does not duplicate the package format; it standardizes how the package is transported, installed into a hosted harness, represented on the harness object, materialized at execution time and exported again.

Question	UHP `2026-09-12`	Agent Plugins `1.0.0`
Primary problem	Drive complete harness execution through one HTTP contract	Package reusable agent extensions portably
Primary artifact	HTTP API plus harness/task/session/event/file semantics	Plugin directory with `plugin.json`, optional `skills/` and `mcp.json`
Runtime task/session lifecycle?	Yes	No; runtime lifecycle remains outside the package standard
Tool/context interoperability?	Drives a selected harness; optional Harness Plugins binds packaged tools/skills into it	Packages Agent Skills and MCP connection configuration; MCP remains authoritative for MCP wire behavior
Plugin installation into a hosted harness?	Yes, optionally, through Harness Plugins	Defines the package consumed by a conforming client/host
Export back to a portable package?	Yes, on the Harness Plugins surface	Defines the package shape UHP exports
Installation/marketplace contract?	UHP transport/binding only, not a marketplace standard	Distribution and marketplace behavior remain client-managed
Permissions/sandboxing?	Server/runtime security plus plugin execution boundary are normative	Package format does not define a universal host sandbox or permission UI
Relationship	Normatively reuses Agent Plugins `1.0.0` for the optional sub-protocol	Remains authoritative for package/component format

The new three-layer composition

The standards now form an explicit stack:

Agent Skills     SKILL.md + folder                 one skill
Agent Plugins    plugin.json + mcp.json + skills/ portable extension package
UHP Plugins      hosted harness binding + API     package installed into a harness

That distinction matters. A UHP server validates and transports an Agent Plugins package, derives its visible manifest/MCP/skill state and combines enabled plugin components with the harness’s direct configuration. The package itself remains governed by Agent Plugins.

MCP is another independent layer: Agent Plugins specifies portable MCP connection configuration; MCP remains authoritative for the MCP wire protocol and lifecycle. UHP does not redefine MCP messages by adding Harness Plugins.

Current Agent Plugins status

The official specification site identifies Agent Plugins 1.0.0 as Published. Its portable core remains deliberately small:

plugin.json is required at the plugin root and declares the target Agent Plugins schema version.
skills/ carries Agent Skills in the separate Agent Skills format.
mcp.json can describe MCP servers using stdio, Streamable HTTP and optionally legacy SSE according to client transport support.
${PLUGIN_ROOT} and ${PLUGIN_DATA} provide defined package/data placeholders in supported MCP configuration fields, with filesystem containment requirements.
Agent Plugins 1.0.0 defines no OAuth configuration or portable credential-reference fields. Authorization discovery, user interaction and credential storage remain client-managed; configured headers and environment values are not a portable secret mechanism.
Reverse-domain client-extension namespaces allow product-specific behavior without expanding the portable core.

The specification repository now identifies 1.1.0 as a working draft. Do not describe that unpublished draft as the current published Agent Plugins release merely because repository main has advanced; UHP 2026-09-12 binds specifically to Agent Plugins 1.0.0.

What UHP adds around the package

The UHP Harness Plugins chapter adds semantics Agent Plugins intentionally does not define:

a plugins array on the harness object;
server-derived manifest, mcpServers, skills and skipped state;
package-file retrieval and optional blob-backed storage;
effective configuration rules combining direct and plugin-derived tools/skills;
plugin enable/disable behavior at harness execution time;
unique plugin-name/conflict handling per harness;
stdio MCP process materialization inside the agent sandbox;
harness export back to an Agent Plugins package, with credentials omitted and omissions recorded;
plugins capability discovery plus plugin_schemas;
plugin-specific UHP error codes;
conformance checks P-01 through P-10.

This is why the previous description — “they can coexist, but no standardized UHP↔Agent Plugins binding is established” — is now stale. The binding is part of UHP 2026-09-12.

Runtime implementation boundary — September snapshot

Protocol publication and reference-runtime support are separate coordinates. UHP 2026-09-12 and package 2026.9.12 define Harness Plugins. The current HarnessRouter conformance source contains 75 checks after PR #210 added Extended check X-09 for standalone POST /v1/files; the package version did not change, so package metadata alone no longer identifies the exact check count. HarnessRouter v0.18.2, published on GitHub 18 September 2026 and resolving to bf3b0c64d24ef83724ded9b3187db5fcc31db1f6, is the current stable Community Edition release and the checked upstream main at this cutoff. It inherits the v0.17.3 plugin transport/runtime correction chain and the Kimi Code CLI 2.0.0 backend from v0.18.1; PR #210 itself fixes self-hosted local-backing file upload and adds X-09 rather than changing Harness Plugins wire semantics.

At the verified cutoff:

UHP specification: 2026-09-12, Harness Plugins defined.
Agent Plugins package version used by UHP: 1.0.0.
HarnessRouter stable/current main: v0.18.2 / bf3b0c64.
Current HarnessRouter conformance source: 75 checks, including Extended X-09; package metadata remains 2026.9.12.
Gateway runtime: v0.18.2 defaults to 2026-09-12, accepts explicit 2026-08-11, advertises plugins: true and the Agent Plugins 1.0.0 schema URI.
HarnessRouter live release evidence: 74/74 Full, 0 failed, 0 skipped, 0 errored, recorded twice in PR #175 during v0.17.2 implementation/adversarial verification. That evidence predates X-09 and is not relabeled 75/75.
Current HarnessRouter checked-in conformance README block: PR #190 records live Community Edition 0.17.3 at 74/74 Full, 0 failed, 0 skipped, 0 errored on 15 September under suite 2026.9.12; PR #177 is the earlier README remeasurement. Both predate X-09, and no checked-in 75/75 Full remeasurement was observed at this cutoff.
HarnessRouter checked-in JSON report: PR #178 adds 2026-09-15T0046Z-full.json for Community Edition 0.17.2, 74/74 Full, zero fail/skip/error, protocol/suite 2026-09-12 / 2026.9.12; it remains the latest observed versioned CE JSON report and predates X-09.
Official protocol/IMPLEMENTATIONS.md card: UHP 2026-09-12; PR #179 makes a measured card’s displayed UHP version derive from its newest checked report, like its measured level/badge.
Stable native-MCP corrections inherited by v0.18.2: PR #180 removes the false Pi/dsh stdio admission restriction and teaches their config writers native stdio shapes; PR #181 maps SSE/Streamable HTTP according to each backend client and, at that intermediate revision, records SSE explicitly in plugin skipped state for Codex/dsh/Goose; PR #182 removes the residual dsh URL-only job filter so a command-based stdio server reaches the compose patch; PR #185 supersedes the transport-specific SSE skip with a runner-owned stdio bridge to the remote SSE server for backend clients without native SSE; PR #188 makes Codex wait each MCP server’s own startup timeout so the bridge does not race the initial tool catalog; PR #189 pins the MCP SDK imported by that bridge in the open-source image and aligns its Pydantic dependency so the release can actually start it. PR #190 changes evidence attribution only.
Kimi release line: PR #191 first adds predecessor Kimi CLI 1.50.0 and becomes stable v0.18.0; PR #206 replaces it with Kimi Code CLI 2.0.0 and becomes stable v0.18.1; v0.18.2 inherits that backend unchanged. PR #191’s 48/48 Harness Plugins matrix and PR #206’s product-path/provider tests are runtime/plugin evidence, not UHP conformance.
PR #208 fixes manual release publication only. PR #210 fixes self-hosted local POST /v1/files, adds X-09 and exposes API Keys in the self-hosted sidebar; neither changes Agent Plugins 1.0.0 or Harness Plugins protocol semantics.

Those runtime corrections are implementation behavior, not package-format or UHP wire changes. The current stable line contains the corrected Pi/dsh admission and SSE bridge/readiness/dependency chain. The existing 74/74 evidence remains version-bounded and should not be interpreted as proving every backend-specific MCP transport/launcher/readiness/packaging path or as a v0.18.2 75-check conformance measurement. In particular, PR #180 alone was not complete dsh end-to-end parity: PR #182 fixes the later-discovered build-stage filter that had still dropped command-only servers. PR #185 does not give Codex, dsh or Goose native SSE; HarnessRouter adapts remote SSE through a local stdio MCP bridge, PR #188 corrects Codex’s readiness timing around that adapter, and PR #189 closes the dependency gap that would have made the open-source image unable to import the bridge. PR #188’s separate terminal-session follow-up fix and PR #189’s separate non-ASCII file-delivery fix are HarnessRouter runtime behavior, not Agent Plugins or Harness Plugins semantics.

The evidence forms must stay separate. PR #175 is release/adversarial live verification for v0.17.2; PR #177 is the earlier dedicated checked-in README remeasurement; PR #178 is a checked structured 0.17.2 report produced by the generic measurement workflow; PR #190 is the current checked-in README remeasurement and identifies live CE 0.17.3; PR #179 consumes report evidence to keep implementation-list metadata aligned. PRs #180–#182, #185, #188 and #189 entered stable in v0.17.3 and remain in v0.18.2. PR #191 is the predecessor v0.18.0 Kimi backend; PR #206 is the v0.18.1 Kimi Code backend inherited by v0.18.2; PR #208 is workflow publication only; PR #210 is the file-upload/X-09 release delta. No newer versioned CE JSON report was observed at this cutoff.

Existing client implementations remain separate evidence

Agent Plugins support inside individual clients is still distinct from UHP support. A client may consume Agent Plugins without implementing UHP, and a UHP server may be conformant while reporting plugins: false.

Cline Desktop v0.0.23, for example, shipped shared-Hub Agent Plugins support independently of UHP. That is direct evidence for Cline’s Agent Plugins path, not native UHP adoption and not evidence that HarnessRouter’s separately pinned Cline backend imports Agent Plugin packages through UHP.

The same evidence discipline applies to every other Agent Plugins-compatible client: registry/client support and UHP protocol support are separate claims unless a primary source connects them.

Host trust and distribution policy are outside the package standard: Hermes example

Agent Plugins deliberately leaves trust, permission prompts, installation sources, distribution policy and general sandboxing to the host. Hermes is a useful concrete implementation example because it documents an Agent Plugins v1.0.0 compatibility adapter that installs portable packages through the normal hermes plugins install workflow, while explicitly treating that support as a subset rather than a claim of complete Agent Plugins conformance.

Hermes PR #108811, merged 14 September 2026 after stable v0.21.3, tightens the installer scanner without changing the Agent Plugins format:

For JavaScript/TypeScript plugin files only, ambiguous interpolated dig/host strings and authorized_keys references are downgraded from critical to high severity. At that PR’s own cutoff they remained visible and required operator confirmation on ordinary installs; current main adds the exact reviewed-catalog-pin exception described below rather than silently weakening the scanner.
Shell payloads, documentation and the Skills scanner keep the existing critical treatment for those patterns.
A new critical rule catches JavaScript reads of literal credential-file paths, including private SSH keys, preserving a hard block for the regression case that reads a private key and interpolates it into a DNS query.
--force still cannot override a dangerous verdict. Scanner-version bumps invalidate old cached results.
Upstream reports 62 targeted plugin/skills guard tests passing on Windows, plus real install/load checks for the RSS and SSH catalog candidates with scanning enabled and force=False.

Hermes PR #112292, merged 15 September 2026 as commit 5d59366010640c1d6b8f170d8a4ee109db2bbdef, demonstrates the same host-owned boundary at the distribution/catalog layer. Hermes added 66 community plugins from a maintainer-curated Discord sweep, with every catalog entry pinned to the exact commit that was reviewed. The PR reports both normal and bare-environment hermes plugins validate passing, no dangerous plugin-guard verdict for the 66 admitted entries, zero hits in its self-updater and vendor-credential-store write checks, 94 catalog files valid, 92 extracted entries (4 official, 88 community), 42 targeted catalog tests passed, and one live install E2E resolving the exact pinned time-gap commit.

The catalog policy is deliberately stronger and more specific than “a package exists”: entries are human-merged, full-SHA pinned, capability-declared and non-self-updating; SHA bumps require fresh review, removals are blocklisted, and PR #112292 expands admission rule 5 to allow maintainer-curated reviewed sweeps alongside owner/major-contributor submissions. Hermes’ own documentation also cautions that catalog review is a point-in-time review, not a security audit. One PR reviewer note is especially useful for the portability boundary: a plugin SHA pin covers the plugin repository code, not necessarily an external dependency version range that the plugin loader may install.

Hermes commit 260da4ef6251b29aa830c8c949dbe7c92d58df5f, committed 16 September 2026, closes a real admission/install mismatch in that trust model. Catalog CI and hermes plugins validate had not been running the same plugin_guard scanner used by installation. As a result, a human-reviewed full-SHA catalog pin could still receive a caution verdict only at install time; CLI could ask for confirmation, but Desktop/dashboard had no decision callback and therefore surfaced the reviewed entry as blocked. The commit records 23 of 71 pinned trees scanned that day in this caution state.

The corrected boundary deliberately preserves the exact artifact identity:

validate_plugin_dir now runs the install-time security scanner during catalog admission; dangerous fails the entry, while caution is emitted as reviewer-visible warnings.
Catalog installation passes the reviewed catalog SHA into the installer. A caution verdict can proceed without an interactive prompt only when the checked-out revision exactly equals that reviewed pin.
dangerous still blocks even for a catalog pin, preserving the install-time backstop.
Raw-URL installs, --ref overrides and any checkout that does not equal the reviewed catalog SHA keep the ordinary confirmation behavior rather than inheriting catalog trust.
Upstream’s live check records dashboard_install_plugin('weather') changing from a pre-fix caution block to a successful reviewed-pin install.

The architectural point is the boundary, not the particular regexes or catalog count: portable package validity does not imply host trust or host distribution approval, and a host must not transfer review trust to a different artifact than the one reviewed. A host can apply static-analysis policy, exact-source pinning, catalog curation, removal/blocklist behavior and either interactive confirmation or reviewed-pin admission without changing Agent Plugins wire/package semantics.

Current-main dependency resolution adds a second host-owned trust boundary

Hermes PR #113851, merged 17 September 2026 after stable v0.21.3, extends that host ownership from source admission into the Python runtime. The latest stable release remains v2026.9.14 / Agent v0.21.3; the dependency behavior below is post-release current-main evidence. Checked current main is d177b119e9c56c9ddc0b7379ffce52341ec06584, downstream of the PR’s merge tip a08dee94c13ec920a55b61b4ca8f3aa8bf155c06 and the memory-provider migration described below.

A directory plugin may declare Python requirements through pyproject.toml [project].dependencies; without project metadata, plugin.yaml python_dependencies is used and pip_dependencies remains an accepted alias. Project metadata wins when both exist.
Install, enable, plugin update, pack install and Desktop install paths now resolve a candidate under constraints derived from Hermes’ own dependency ranges plus enabled peer declarations before the candidate tree moves into place. A proven conflict refuses the candidate without changing the live plugin tree or touching an enabled peer.
The dependency union spans the default home and live named profiles because those plugins share the same Hermes venv. This is intentionally different from credential/configuration isolation: profile-owned plugin enablement feeds one installation-wide interpreter dependency graph.
Environment-marker-excluded requirements and the hermes-agent self-dependency are not installed. Direct URL/path requirements are never auto-installed because arbitrary git/tarball sources sit outside the reviewed-pin trust boundary; they are surfaced for manual handling instead. python_runtime: external lets a sidecar-venv plugin opt out of the shared resolver.
hermes update rebuilds the venv and then re-applies enabled plugin declarations across those homes. If the rebuilt core and the union no longer resolve, Hermes identifies incompatible plugins rather than disabling an unrelated alphabetical peer; remaining plugin-vs-plugin conflicts prefer keeping memory providers because silently losing one can present as data loss. Dropped plugins are disabled through the normal configuration writer and the update itself continues.
Admission validation now fails a plugin tree that has no loadable __init__.py, desktop/plugin.js or portable plugin.json, validates dependency declarations and keeps direct-URL requirements visible as warnings instead of silently fetching them.

This closes part of the gap identified by the earlier catalog review note without erasing the distinction. Exact repository-SHA review and dependency compatibility are separate trust coordinates. The SHA establishes which plugin source tree was reviewed; the resolver constrains indexed requirements against Hermes and enabled peers. A repository SHA still does not become a full transitive lockfile or SBOM merely because dependency installation is host-managed: ordinary indexed version ranges can resolve later artifacts while remaining inside the accepted constraints.

Catalog identity is a third host-owned coordinate

Hermes PR #114261, merged 17 September 2026 at 23:54:06 UTC as 0a8d4caef4650320b31f9c17a906293e680be5df, fixes a catalog/runtime identity collision rather than changing the Agent Plugins package format. The bare mnemosyne catalog key now points to the affiliated mnemosyne-oss/mnemosyne integration, pinned at 95ef3be20d28bd9ee1d517bcb25ed00000eab577 under integrations/hermes-catalog; the unrelated Devs-Foundation/mnemosyne entry was delisted.

The merged catalog policy now makes two distinctions explicit:

Delisting is not security removal. An entry that is unmaintained, superseded or squatting an unaffiliated name is deleted from the catalog without entering removed.yaml; users who already installed it are unaffected, and the project may return under a distinct name. Security/policy removal remains the blocklisted path that prevents reinstall by stale name or repository URL.
Catalog identity and runtime-provider identity must agree. A memory / exclusive catalog entry may not reuse another provider’s name or a well-known upstream project’s name without affiliation. Reviewers check the actual register_memory_provider identity, not only the YAML filename, because two providers registering the same name make memory.provider ambiguous and load order decides which implementation wins.

The replacement catalog entry declares requires_hermes: ">=0.21.4" while Hermes’s latest stable release remains v2026.9.14 / Agent v0.21.3. That means this catalog correction is current-main evidence and must not be presented as behavior available from the latest stable release.

At that catalog layer, portable package name, catalog lookup key, runtime provider key, reviewed source SHA and dependency graph are separate identity/trust coordinates. A host can require them to be mutually consistent without extending Agent Plugins 1.0.0. The same distinction applies to UHP: Harness Plugins standardizes hosted transport/binding of Agent Plugins packages, but it does not standardize Hermes’s catalog namespace, affiliation policy, delist/blocklist semantics or memory-provider registry.

Installed-plugin provenance is a fourth host-owned coordinate

Hermes current-main commit 9dda4332f80c66994fe0e21197a8065a73a88991, committed 18 September 2026 at 01:36:20 UTC, fixes a second same-name collision introduced by the supported pyproject.toml wrapper shape. A catalog-installed directory plugin can depend on a Python package that also publishes a hermes_agent.plugins entry point under the same key. Before this fix, entry points were appended after directory manifests with later-wins discovery, so the entry point could replace the installed directory’s identity in both loading and CLI/RPC listing even though the provider itself still worked.

Current main keeps the installed directory authoritative for a same-key collision:

The loader collects directory manifest keys first and filters out same-key entry-point manifests rather than letting them replace the installed directory.
CLI/RPC discovery uses first-wins insertion for entry points, so an already discovered directory row keeps its install path and catalog provenance.
Distinct entry-point-only plugins remain discoverable; the precedence rule is limited to a key already owned by an installed directory plugin.
Upstream’s live Mnemosyne check changed from source=entrypoint / mnemosyne_hermes:register with no catalog fields to source=user / ~/.hermes/plugins/mnemosyne with catalog 0.7.0 @ 95ef3be2; the provider remained discovered.

The consequence is operational, not cosmetic: the identity used for install/update/remove must remain the artifact the user actually installed and the catalog actually reviewed. Portable package name, catalog lookup key, installed directory key, Python entry-point key, runtime provider key, reviewed source SHA and dependency graph are therefore distinct coordinates that a host may reconcile. Agent Plugins 1.0.0 does not define Hermes’s Python entry-point precedence, and UHP Harness Plugins does not standardize this host-local provenance rule.

Memory-provider extraction adds a fifth host-owned lifecycle coordinate

Hermes current-main commit e21ccdd7dc01e1e37e853a6032765d7d835f7d20 handles a different failure mode created when a built-in memory provider moves out of core and into the plugin catalog. The provider’s durable identity can remain unchanged — provider name, memory.<name> configuration, data directory and tool names — while the code that satisfies that identity moves from bundled source to HERMES_HOME/plugins/<name>.

Hermes now reconciles that transition rather than silently running without the configured provider:

hermes update checks every profile home sharing the rebuilt virtual environment. When memory.provider resolves nowhere but the same provider exists in the live catalog, Hermes installs the catalog entry through the normal reviewed install path.
Agent startup provides a one-attempt-per-process recovery path for Desktop users who do not invoke hermes update manually. Because this path installs code, it honors security.allow_lazy_installs.
Recovery uses the normal catalog installer, so reviewed-pin selection, kill-list enforcement, dependency constraints and enablement remain in force. It does not invent a replacement source merely because a provider is missing.
If the provider is offline, absent from the catalog or cannot be installed, the migration is nonfatal and reports an actionable install command instead of turning the update itself into a hard failure.
The migration preserves the existing provider configuration and data. Tests explicitly verify that memory.honcho settings survive the move and that an unknown catalog provider is not installed.
Plugin source parsing now also accepts owner/repo#subdir, matching the catalog spelling used by providers whose Hermes plugin lives below the repository root.

This adds a lifecycle coordinate to the earlier identity model: a host must be able to preserve a durable configured provider identity while its implementation location changes, without transferring trust to an unreviewed artifact or silently dropping the provider. Portable package name, catalog lookup key, installed-directory key, Python entry-point key, runtime provider key, reviewed source SHA, dependency graph and migration/recovery state are distinct host-owned coordinates.

Hermes main at this cutoff is d177b119e9c56c9ddc0b7379ffce52341ec06584, two commits beyond the prior e83b1d51 site cutoff and downstream of e21ccdd7. The latest stable release remains v2026.9.14 / Agent v0.21.3, so this migration is current-main behavior rather than a latest-stable guarantee.

This is Hermes host, catalog, plugin-runtime and migration policy, not an Agent Plugins 1.0.0 registry requirement, not a UHP Harness Plugins requirement and not evidence that HarnessRouter uses Hermes’s scanner, catalog, dependency resolver, provider registry, loader precedence or migration hooks. UHP’s own plugin security rules govern the hosted-harness boundary — including sandboxing packaged stdio MCP execution — but do not standardize an installer static-analysis engine, catalog admission process, marketplace, Python dependency resolver, provider-name authority, host entry-point precedence, built-in-to-catalog migration, confirmation UX or update policy.

Why this matters architecturally

The new standardized composition is now:

agent product → UHP server → selected harness → UHP Harness Plugin binding → Agent Plugin components → Agent Skill / MCP server

This closes one portability gap without collapsing the layers. Teams can standardize complete-harness execution and portable tool/skill packaging together while keeping package semantics, MCP wire behavior, host trust policy and harness task/session behavior owned by their respective layers.

Read Harness Plugins for the protocol mechanics, the specification guide for the complete UHP release, and Conformance for the measurement boundary.

Select the package, binding and host policy separately

Different portability boundaries, now with a standardized binding

The new three-layer composition

Current Agent Plugins status

What UHP adds around the package

Runtime implementation boundary — September snapshot

Existing client implementations remain separate evidence

Host trust and distribution policy are outside the package standard: Hermes example

Current-main dependency resolution adds a second host-owned trust boundary

Catalog identity is a third host-owned coordinate

Installed-plugin provenance is a fourth host-owned coordinate

Memory-provider extraction adds a fifth host-owned lifecycle coordinate

Why this matters architecturally

Primary sources