What OAN Is Not

OAN is easier to understand when its boundaries are clear. It is not trying to replace every agent protocol, every marketplace, every directory, every search engine, or every enterprise control system. OAN’s role is narrower and more important: it provides trust-governed identity, publication, Discovery, and verification for agent resources before they are used.

That boundary is deliberate. The Agent Internet will not be built from one protocol or one platform. It will include MCP servers, A2A-style agent communication, ANP-like network ideas, HTTP APIs, skills, tool registries, enterprise gateways, marketplaces, and domain-specific systems. OAN is designed to complement those systems.

Protocol stack

Not an Invocation Protocol

OAN does not define how every agent conversation or tool call must happen. It does not replace MCP initialization, A2A task exchange, HTTP request signing, API authentication, workflow execution, or domain-specific business protocols.

After OAN verification, the resource still uses its native protocol. An MCP server still speaks MCP. A Tool/API still uses its API semantics. A Skill still follows its manifest or package format. An Agent Service still exposes its chosen interaction model.

OAN is the step before invocation: identity, publication, Discovery, and verification.

Not a Closed App Store

OAN is also not meant to be a closed app store. A marketplace can provide curation, payments, rankings, installation flows, user reviews, billing, or policy review. OAN does not need to own that entire experience.

A marketplace could use OAN underneath to verify resource identity and package evidence. An enterprise catalog could use OAN to ingest trusted resource facts. A public website could provide simple registration and Discovery pages. The trust layer remains portable across these different surfaces.

The key difference is that OAN evidence should be inspectable outside one platform’s private database.

Not Search Alone

Discovery is part of OAN, but OAN is not just search. A ranking engine can find relevant candidates. Semantic search can improve recall. GRAIL-like methods can improve matching quality. None of that replaces Root acceptance, package proof, lifecycle state, or authorized-domain filtering.

This matters because a semantically excellent match can still be unsafe or out of scope. OAN requires trust first and ranking second. Discovery should rank candidates only after the package is verified and the Discovery node is authorized to expose that resource domain.

Not a Universal Semantic Ontology

OAN uses capability tags and authorized domains, but it is not trying to freeze every possible capability, industry concept, or semantic category forever. Capability tags help search and explanation. Authorized domains provide governance scope. These should stay separate.

As the ecosystem grows, communities can improve tags, schemas, examples, and semantic profiles. OAN’s core model does not require every resource in the world to fit a single universal ontology before it can be identified and verified.

Not a Replacement for Security Controls

OAN improves pre-connection trust, but it does not replace all downstream security. A verified resource can still require API keys, OAuth, enterprise approval, sandboxing, rate limits, input validation, data-loss prevention, model evaluation, or legal review.

For example, OAN can verify that a Tool/API resource is the accepted current package for a DID. It cannot decide whether a particular user is allowed to send confidential data to that API. OAN gives the relying party a better starting point; it does not eliminate local policy.

Not a Single-Operator Trust Monopoly

OAN has official services today, but the architecture is not limited to one operator forever. The model supports third-party Registrar and Discovery nodes, governed infrastructure authority, authorized-domain scope, and future federation paths.

This is why baseUrl configuration, node authorization, trial-network material, and governance state matter. OAN should grow as open trust infrastructure, not as a single website that everyone must blindly trust.

Not A Centralized Gatekeeper For Every Resource

Official services provide a reference path, but OAN should not become a permanent single gate that all agent resources must pass through. The stronger model is governed plurality: official nodes, recognized third-party nodes, domain-specific operators, enterprise deployments, and later federation can coexist when the trust path remains verifiable.

This matters strategically. If OAN became only a central catalog, it would inherit the bottlenecks and political weaknesses of traditional marketplaces. Its stronger role is to define portable trust semantics that multiple operators can implement under governance.

Not A Substitute For Product Quality

Root proof and Discovery evidence do not certify that a resource is the best choice, legally sufficient, bug-free, or safe for every environment. A verified resource can still have poor UX, weak documentation, runtime vulnerabilities, high cost, or domain-specific compliance issues.

OAN narrows a different risk: whether the resource identity and publication path can be checked. Product evaluation, security review, runtime monitoring, and business approval still belong to the relying party.

The Boundary in One Sentence

OAN does not replace how resources work; it helps decide whether resources are identifiable, current, authorized, and verifiable before they work with you.