Understand OAN

OAN is easiest to understand if we start from the experience of using agent resources on the open Internet. A developer, enterprise user, or autonomous agent can already find many things that look useful: an MCP server, a tool API, a downloadable skill, an agent service endpoint, a prompt package, or a demo published by a third party. The hard question is no longer only “can I find something?” It is “can I verify what I found before I connect to it?”

The OAN slide deck frames this as the move from wild-growth trust to rule-based trust. Agent ecosystems are expanding quickly, but the evidence around many resources is still thin. A resource may have a URL, a README, or a marketplace listing, yet still leave unanswered questions: who controls it, whether the current version is the accepted version, whether the infrastructure node exposing it is authorized, whether it has been revoked, and whether another agent can check the same evidence automatically.

OAN exists to make that pre-connection trust layer explicit.

OAN framework overview

OAN trust stack

The Short Version

OAN is open governance infrastructure for trusted agent-resource interconnection. It combines several roles that are often scattered across separate systems:

portable did:oan identity for resources and infrastructure nodes;
governance-backed authority for nodes such as Registrar and Discovery;
Registrar-assisted onboarding for resource providers;
Root-verified publication and package proof;
CDN distribution of Root-verified package material;
authorized Discovery that returns evidence-carrying candidates;
client-side verification before native invocation.

A normal directory says that a resource exists. A search engine ranks it. A marketplace may review it inside one platform. OAN focuses on a different layer: whether the resource has a governed identity and verifiable publication path that another party can check before using it.

What Problem OAN Solves

The white paper describes several gaps in open agent ecosystems. Identity is often too local: an endpoint or repository name does not prove who controls the resource. Lifecycle is often vague: users may not know whether a resource is current, revoked, superseded, or stale. Discovery is often policy-blind: a result may match the query but still come from infrastructure that is not authorized to expose that domain. Invocation is often rushed: a tool or service is called before the relying party checks identity, package integrity, or lifecycle state.

OAN addresses these gaps by placing evidence before use. A resource should be identifiable before interaction, current before directory exposure, authorized before Discovery visibility, and verifiable before invocation.

What OAN Does Not Replace

OAN is not trying to become the universal runtime protocol for agents. It does not replace MCP, A2A, ANP-like systems, HTTP APIs, OpenAPI, enterprise gateways, or domain-specific workflows. Those systems still define how an agent calls a tool, exchanges context, delegates work, authenticates a request, or executes a business task.

OAN sits before that step. It helps answer whether the candidate resource should be approached at all. Once the resource is verified, the actual interaction can continue through its native protocol.

This is why OAN can support heterogeneous resource forms. An MCP server can remain an MCP server. A Skill can remain a manifest or package. A Tool/API can remain an HTTP or OpenAPI surface. An Agent Service can keep its own protocol binding. OAN gives them a common trust envelope.

The Main Actors

OAN separates roles so one component does not silently become the source of every trust fact.

Registrar is the onboarding gateway. It helps resource providers prepare DID material, metadata, capability tags, authorized domains, and package information, then submits Root-bound material through an authorized path.

Root is the trust anchor inside an OAN trust domain. It consumes governance-derived infrastructure state, verifies submissions, accepts resource versions, records package facts, produces Root proof, and drives publication.

CDN distributes Root-verified package material. It improves availability, but it is not itself the trust authority. Clients and Discovery nodes still verify hashes and Root proof.

Discovery synchronizes verified package material, applies authorized-domain scope, builds indexes, and returns candidates with evidence. It may add semantic ranking, but ranking does not replace verification.

Clients and SDKs verify what Discovery returns before invoking the native protocol.

Why Governance Matters

OAN treats infrastructure authority as a current, scoped, revocable state. A Discovery node should not be trusted merely because it is online. A Registrar should not be trusted merely because it exposes an API. They need identity, governance-recognized status, Root-issued authorization, and an explicit domain scope.

This matters for open ecosystems. If every group can publish its own resources, there must also be a way to decide which infrastructure nodes may register or expose which domains. OAN uses authorized domains to make that scope visible and enforceable.

The Industry Shift OAN Responds To

The agent ecosystem is moving from single-product assistants toward resource-rich networks. In that network, value is not only inside one model or one application. It is distributed across callable services, domain tools, installed skills, MCP servers, APIs, workflow components, data interfaces, and agent services operated by different parties. The more this ecosystem opens, the less realistic it becomes to rely on private platform review alone.

OAN is a response to that shift. It treats trusted discovery as infrastructure, not as a feature buried inside one marketplace. This is why the architecture separates resource identity from runtime protocol, governance from search ranking, and publication proof from endpoint availability. A broad Agent Internet needs shared trust semantics that survive across products and operators.

A Useful Way to Classify Adjacent Projects

Many adjacent systems solve valuable but different problems. MCP helps models and tools exchange context and tool calls. A2A-like protocols help agents communicate. Marketplaces help users browse curated resources. Search systems improve retrieval. DID/VC systems provide identity and credential primitives. OAN’s role is to combine the pieces needed before a resource is safely used: governed infrastructure authority, portable resource identity, Root-verified publication, authorized Discovery, and client verification.

That positioning is important for readers evaluating OAN. OAN should not be judged by whether it replaces every agent protocol. It should be judged by whether it supplies the trust layer those protocols usually assume or leave to each platform.

Where to Go Next

Read “What Is OAN” for the compact definition, “Why Agent Trust Matters” for the motivation, and “What OAN Is Not” for the boundary with other protocols and marketplaces. If you already know the high-level idea, move to Core Concepts for the vocabulary: did:oan, trusted resources, ResourcePackage, Root proof, authorized domains, and capability tags.