UHP vs OpenSharing

The one-sentence difference

OpenSharing is an asset-sharing protocol for discovering and obtaining controlled access to data and AI assets across organizations; UHP is an execution protocol for driving a complete agent harness once a client has reached a UHP server.

OpenSharing can deliver material that an agent or harness later uses. UHP can execute work that consumes such material. Neither function implies adoption of the other.

Status first

• UHP remains the 2026-09-12 Draft, with runnable conformance coverage for the client↔complete-harness execution contract.
• The Linux Foundation announced OpenSharing on 10 June 2026 as a Linux Foundation AI & Data project contributed by Databricks and derived from Delta Sharing.
• The checked OpenSharing repository main is ca251c87cd9e1bd741b3d81882b603788ab90d2f. Its README identifies the project as an LF AI & Data project, but also says OpenSharing is being submitted as a sandbox project and calls the specification a community proposal with several AI asset designs still early. Those maturity statements should be preserved rather than silently upgraded to a finalized standard.
• OpenSharing specifies Table, Volume, AgentSkill and Model asset types. Agent and Page remain community proposals in the checked repository.
• The repository says existing Delta Sharing clients remain compatible with OpenSharing, while also stating that current connectors support Table sharing and that support for Volumes, Models and Agent Skills is in progress.
• No reviewed OpenSharing source names UHP, defines a UHP invocation protocol value, or establishes native UHP adoption or a HarnessRouter integration.

Architectural comparison

Dimension	UHP	OpenSharing
Primary problem	Execute work through a complete agent harness	Share data and AI assets across organizational/platform boundaries
Main object model	Harnesses, tasks, sessions, events, files, artifacts, optional plugins	Share → Schema → asset
Typical assets	Inputs/outputs attached to an execution lifecycle	Tables, volumes, Agent Skills, models; proposed live agents and semantic pages
Access model	UHP server authentication/authorization plus runtime object scope	Sharing-server bearer access plus temporary, asset-scoped storage credentials
Data path	Client communicates with the UHP server for harness execution	For zero-copy assets, sharing server vends credentials and recipient reads provider storage directly
Agent Skills	Optional Harness Plugins use Agent Plugins packaging; UHP does not itself define cross-org skill storage	AgentSkill is a first-class share asset following the AgentSkills directory format
Live agent invocation	Core purpose is complete-harness task/session execution	Separate community proposal; invocation protocol is declared independently
Conformance maturity	Published UHP suite	No reviewed OpenSharing conformance suite comparable to UHP’s was identified at this cutoff

The most important boundary is that asset distribution is not execution. A protocol can securely expose a skill directory without deciding how a local harness authorizes its scripts, tools, filesystem access, model calls or side effects.

What OpenSharing adds to the agent stack

OpenSharing extends the Delta Sharing lineage from structured tables into broader AI assets. Its current hierarchy is:

Share
 └── Schema
       ├── Table
       ├── Volume
       ├── AgentSkill
       ├── Model
       ├── Agent   (community proposal)
       └── Page    (community proposal)

A recipient authenticates to the sharing server, lists or retrieves assets, and for zero-copy assets obtains short-lived access to the provider’s storage. The server can vend AWS STS credentials, Azure SAS, GCP OAuth tokens, Cloudflare R2 credentials or pre-signed access depending on the asset type and implementation. The sharing server therefore coordinates discovery, policy and credential issuance without becoming the bulk-data path.

That is materially different from UHP’s task/session lifecycle. UHP does not define a cross-enterprise asset catalogue, cloud-storage credential vending, or a Share/Schema namespace.

Agent Skills: OpenSharing and Skills Over MCP solve different distribution problems

OpenSharing’s AgentSkill proposal follows the separate AgentSkills directory specification. A skill has a root SKILL.md and can include scripts, references and assets. OpenSharing models that directory as a first-class asset with its own storageLocation, list/get APIs and a temporary-skill-credentials endpoint so the recipient can read the files directly from cloud storage.

Skills Over MCP / SEP-2640 uses a different carrier. It discovers and serves Agent Skills through an already-established MCP connection using skills/list, skills/get, MCP resources and optional resources/directory/read. The two approaches therefore differ at the transport and trust boundary:

Question	OpenSharing AgentSkill	Skills Over MCP
Distribution setting	Cross-organization/shared asset catalogue	Existing MCP client↔server connection
File transport	Direct provider storage after scoped credential vending	MCP resources
Namespace	Share / Schema / AgentSkill	MCP extension + skill/resource URIs
Skill format	Delegates to AgentSkills	Delegates to AgentSkills
Runtime tool authority	Not granted by storing or downloading the skill	Must remain host-controlled; MCP-served skill content does not automatically widen permissions
Primary purpose	Share governed assets without copying them through the catalogue server	Discover/read skills over MCP

A deployment could use both, but that would be an application architecture, not a standardized bridge. For example, an organization could use OpenSharing to grant access to a skill catalogue and separately expose MCP tools that the skill expects. Nothing in either protocol makes those identities, approvals or permissions automatically equivalent.

allowedTools metadata is not runtime authorization

The checked OpenSharing AgentSkill object includes optional allowedTools metadata inherited from the skill description model. That field should not be interpreted as a cross-harness authorization grant.

OpenSharing controls who can discover and access the shared skill files. The executing harness still controls whether a tool exists, whether the user/session may invoke it, what filesystem/network scope applies, and whether downloaded scripts can execute. Treating remote metadata as an automatic elevation of local tool authority would collapse the asset-trust boundary into the runtime-policy boundary.

This is especially important when combining OpenSharing with MCP, UHP or a local coding harness: access to instructions is not permission to perform every action those instructions request.

The live Agent proposal is adjacent to UHP, but not UHP

OpenSharing also contains an early Agent Sharing community proposal for provider-operated live agents. Unlike an AgentSkill, the recipient does not download the implementation. The sharing server issues a short-lived invocation token and endpoint, and the recipient calls the provider’s service using the declared invocationProtocol.

At the checked commit, the proposal lists these invocation-protocol values:

• mcp
• a2a
• openai
• anthropic
• rest

UHP is not listed. The proposal itself says its design is early and specifically calls out open questions around invocation, sessions and governance. It would therefore be inaccurate to describe OpenSharing as a UHP discovery layer today or to infer a UHP binding from the general Agent concept.

A future OpenSharing extension could theoretically describe a UHP endpoint, but interoperability would require a documented identifier and shared semantics rather than a private string convention.

Security and ownership boundary

OpenSharing’s zero-copy design moves an important part of the security boundary into cloud-storage credentials. The sharing service grants access; the recipient then reads from the provider’s storage with short-lived, scoped credentials. A correct implementation therefore needs at least three ownership domains to remain aligned:

1. Share authorization — which recipient can see the asset.
2. Credential scope — which storage location and operations the temporary credential permits.
3. Runtime authorization — what the recipient’s agent/harness may do after obtaining the bytes.

UHP primarily addresses the third domain once execution begins. It does not validate that an OpenSharing credential was least-privilege, and OpenSharing does not standardize UHP session/tool authorization. Combining the systems safely requires preserving those ownership boundaries rather than translating one permission into another by assumption.

Where this fits beside Agent Plugins

Agent Plugins package portable agent capabilities for installation, including Agent Skills and optional integration metadata. OpenSharing instead focuses on controlled cross-organization sharing and access to assets that stay with the provider.

A useful distinction is:

• Agent Plugins: what is in an installable capability bundle?
• OpenSharing: how can an organization expose an asset and grant scoped access to it?
• Skills Over MCP: how can an MCP server publish an Agent Skill through MCP?
• UHP: how can a client execute work through a complete harness?

These layers can be composed, but their security and versioning contracts remain independent.

Practical decision rule

Use OpenSharing when the problem is governed cross-organization distribution of data or AI assets, especially when the provider wants assets to remain in its storage and prefers temporary scoped credentials over copying payloads through a central catalogue service.

Use Skills Over MCP when the client already has an MCP connection and needs to discover/read Agent Skills from that MCP origin.

Use Agent Plugins when the unit of portability is an installable capability bundle.

Use UHP when the endpoint is a complete agent harness and the client needs portable task submission, streaming, continuation, cancellation, sessions, files and artifacts.

Evidence limits

The Linux Foundation launch announcement and the repository’s maturity language are not identical signals. The project can be publicly launched under foundation branding while its repository still describes the specification as a community proposal and its sandbox status as being submitted. This page preserves both facts instead of converting organizational launch language into a claim that every AI asset type is finalized or widely implemented.

Likewise, Delta Sharing connector compatibility should not be read as shipped support for OpenSharing’s AI-specific asset types. The repository explicitly says the currently listed connectors support tables while Volume, Model and Agent Skill support is still in progress.

Primary sources

• Linux Foundation — OpenSharing launch, 10 Jun 2026
• OpenSharing repository
• Checked OpenSharing main — ca251c87
• OpenSharing protocol overview
• OpenSharing Agent Skills specification
• OpenSharing Agent Sharing community proposal
• OpenSharing roadmap
• AgentSkills specification
• UHP protocol source at checked HarnessRouter main