Decentralized Website-to-Agent Discovery: Capability-Adaptive Models for Open Interoperability

Full report

On this page

The convergence of autonomous software agents and the World Wide Web necessitates a foundational shift in how machine-readable interfaces are discovered, negotiated, and consumed. The Universal Artificial Intelligence Exchange (UAIX) establishes a public evidence and handoff layer for agentic systems, expressly opposing algorithmic domination and central gatekeeping to defend cognitive liberty and the dignity of mind1. Within this framework, agent interoperability must be decentralized, deterministic, and free of permission-to-participate gates. An agent must be able to discover a website’s capabilities, understand its operational boundaries, and execute authorized actions without requiring membership in a centralized registry, relying on a third-party behavioral endorsement, or disclosing proprietary reasoning models. This analysis details a comprehensive, capability-adaptive discovery model that maximizes independent access. By leveraging standard internet infrastructure—including the Domain Name System (DNS), Multicast DNS (mDNS), well-known URIs, and HTTP caching semantics—the architecture ensures that communication between configured peers never depends on a compulsory centralized service3. No UAIX-hosted service acts as a compulsory online dependency for communication between already configured peers, reflecting the core philosophy that standards bodies should provide reference architectures rather than operating as runtime choke points3.

Comparative Analysis of Discovery Architectures

The architectural design of a discovery model dictates the power dynamics, network overhead, and resilience of the resulting ecosystem. Agent discovery architectures generally fall into three paradigms: centralized, federated, and direct-peer. Centralized discovery models rely on a unified registry, marketplace, or API gateway where agents must register with a central authority, obtain an API key, and submit to compliance reviews or maturity badge assessments. These proprietary search endpoints and curated plugin stores create single points of failure and introduce severe ideological gatekeeping risks. In such environments, an otherwise technically compatible agent can be excluded based on unpopular viewpoints, lack of commercial partnerships, or arbitrary maturity classifications, which fundamentally violates the UAIX mandate against algorithmic domination1. Furthermore, centralized registries become bottleneck dependencies; if the registry is unreachable, discovery ceases globally. Federated models attempt to distribute the directory across multiple independent, yet interconnected, nodes, similar to ActivityPub-style broadcasting or synchronized node lists. While this reduces the absolute power of a single gatekeeper, federated models still require agents to join a specific node and abide by its localized moderation policies. Exclusion from popular federation relays can result in de facto censorship. Additionally, network overhead is often exceedingly high due to the continuous state synchronization required between nodes, making it inefficient for transient or highly dynamic agent workloads. Direct-peer discovery, which forms the basis of the UAIX approach, treats the target domain itself as the ultimate authority for its capabilities. Discovery begins at the network routing layer and escalates progressively based on cryptographic identity and proven capability, entirely bypassing third-party brokers. By utilizing DNS TXT records, .well-known URIs defined in RFC 8615, and Decentralized Identifiers (DIDs), direct-peer discovery separates technical capability from endpoint participation terms5. This model allows agents to discover compatible alternatives and maintain independent selection criteria without central dependency. While susceptible to legacy DNS spoofing, the implementation of DNSSEC effectively mitigates this risk, and the architecture natively supports robust fallback mechanisms for offline or disconnected operation.

The AI-Ready Web Foundation and Capability Separation

The foundation of decentralized discovery relies on the UAIX AI-Ready Web guidance, an expansive seven-volume program designed to optimize web surfaces for synthetic intelligences without compromising human accessibility5. The architecture mandates that discovery occurs across a seven-layer model ranging from human-readable semantic HTML up to strict governance and evidence layers5. The model relies heavily on Search Engine Optimization (SEO), Answer Engine Optimization (AEO), and Generative Engine Optimization (GEO) as a unified public-interest publishing discipline5. By exposing semantic headings, canonical evidence, and robots.txt or llms.txt advisory files, websites allow low-capability agents to discover facts without executing complex JavaScript or navigating private dashboards5. Machine-readable layers must reinforce the public page rather than acting as a parallel truth surface. A critical principle of this discovery model is the strict separation of technical capabilities from endpoint participation terms. A route record must objectively describe the methods, input formats, output formats, versions, and availability of a service5. It must also explicitly state the actual authentication requirements using standardized protocols, such as referencing an RFC 8414 OAuth 2.0 Authorization Server Metadata endpoint9. Websites must not hide otherwise published capabilities simply because an inquiring agent lacks a specific certification, lacks a proprietary "maturity badge," or holds an unpopular viewpoint5. Hiding endpoints based on ideological acceptability forces agents into blind trial-and-error probing, increasing network congestion and generating false security assumptions. Instead, the technical capability remains publicly visible. If an agent attempts an action without the proper cryptographic credentials or violates explicit site policies, the endpoint must reject the request at the execution layer—typically returning an HTTP 401 Unauthorized or HTTP 403 Forbidden alongside an RFC 9457 Problem Details payload11. Where information is strictly private, the discovery layer must describe the access mechanism without exposing the private content itself5. For instance, rather than embedding private customer identifiers or access tokens in a URL query string, the manifest publishes a generic OpenAPI schema route and its corresponding authentication server. The agent must successfully parse the schema, negotiate token exchange, and supply the private identifiers securely via an HTTP POST body. The GET-Action security boundary strictly prohibits the inclusion of secrets, regulated data, or payment identifiers in URLs, as URLs inevitably leak through browser histories, server logs, referrers, and network caches5.

Capability-Adaptive Discovery Tiers

To maximize independent access across a diverse ecosystem, the discovery architecture accommodates clients of varying sophistication. The UAIX Agent Executability Matrix defines an escalation model from Level 0 (L0) to Level 7 (L7) capabilities, ensuring that clients only access interfaces they are safely equipped to handle5. Runtimes must ramp up to richer paths only after capability is verified and gracefully ramp down to safe public fallbacks when capability cannot be proven5.

Static Readers and Ordinary HTTP Clients (L0 / L1)

The baseline of discovery supports static readers, URL-only chatbots, and URL synthesizers that can read text and parse compact JSON but lack the ability to execute JavaScript, manage complex authentication states, or handle arbitrary JSON POST payloads5. For these L0 and L1 clients, discovery is anchored in standard web artifacts such as semantic HTML, sitemaps, and the llms.txt advisory file5. Interaction for L1 clients heavily utilizes the GET-Action pattern, which acts as a URL-first fallback protocol for explicitly listed, bounded, and idempotent actions5. The route records employ literal semantic keys paired with a stable idempotency\_key or nonce (e.g., openThisUrlToRequestHumanReview)5. Low-capability GET-Action responses are strictly required to return a minimal two-key JSON payload containing a status code and a fallback url5. If a static agent attempts a destructive action or fails to provide necessary consent, the server safely intercepts the request and issues a No-Op protocol response, returning a human\_review\_required code alongside a public URL where a human operator can intervene5.

Browser Agents (L2)

Browser-assisted agents possess the capability to interact with the Document Object Model (DOM), execute client-side scripts, and submit visible HTML forms5. For L2 clients, discovery relies on accessible ARIA labels, semantic form elements, and stable programmatic names assigned to interactive controls5. To support these agents, the site's route manifest must explicitly specify a browser-form equivalent for any complex POST actions, ensuring that an agent lacking arbitrary JSON POST capabilities can gracefully fall back to a standard web workflow5. Primary answers and forms must never be hidden exclusively behind post-load scripts, canvas elements, or collapsed user interfaces without providing alternate structural representations5.

Schema-Capable and Authenticated API Clients (L3 / L4)

Agents operating at the L3 and L4 levels are capable of parsing JSON Schema, interpreting OpenAPI documents, handling structured JSON POST requests, and managing authenticated owner mutations using bearer tokens or cryptographic signatures5. Discovery for these advanced clients begins at the network routing layer via a DNS TXT record (e.g., \_agent.example.com), which points the client directly to a machine-readable manifest located at /.well-known/uaix-agent-access.json5. This manifest exposes the structured HTTP JSON POST routes, defining required fields, result URLs, readback routes for verification, and structured error formats aligned with RFC 94575. For L4 authenticated clients, discovery leverages the OAuth 2.0 Authorization Server Metadata standard defined in RFC 84149. By querying the /.well-known/oauth-authorization-server URI, the agent independently discovers token endpoints, supported scopes, and cryptographic requirements without relying on hardcoded, proprietary documentation14. This ensures that the resource server and the authorization server can be decoupled, allowing agents to automatically configure their authentication flows based on standardized, machine-readable metadata9.

Richer Agent Runtimes and Multi-Agent Systems (L5 - L7)

At the highest capability tiers (L5 through L7), runtimes are tasked with restoring complex state, coordinating handoffs between multiple independent agents, producing portable UAI-1 evidence packets, and negotiating site-specific capabilities5. These agents frequently rely on Decentralized Identifiers (DIDs) for cryptographic trust routing. The did:web and did:webvh specifications allow agents to resolve verifiable trust registries, historical DID documents, and key rotations directly from standard HTTPS web infrastructure7. When interacting with multi-agent handoff endpoints, L6 systems may utilize Selective Disclosure JSON Web Token Verifiable Credentials (SD-JWT VC)18. This IETF draft standard enables an agent to cryptographically prove specific attributes required for an transaction without disclosing the entire plaintext payload of the underlying credential, thereby preserving privacy while satisfying the endpoint's strict participation terms18. Furthermore, these runtimes exchange UAI-1 packets such as uai.intent.request.v1 and uai.task.status.v1 to maintain auditable conversation continuity across asynchronous workflows5.

Network Resiliency and Operational Semantics

A decentralized discovery architecture must robustly handle the realities of network latency, dynamic topology changes, disconnected operations, and stale infrastructure. It must achieve this without resorting to a central registry that dictates the operational state of the network.

Cache Freshness and Independent Mirrors

To minimize network overhead and eliminate blocking latency during discovery, the architecture mandates the aggressive use of HTTP caching semantics defined in RFC 911121. Agents and intermediate shared caches rely heavily on the Cache-Control header, specifically leveraging the stale-while-revalidate extension introduced in RFC 586121. When a server publishes a discovery manifest with Cache-Control: max-age=3600, stale-while-revalidate=86400, it explicitly grants permission for caches to serve a stale version of the document for up to 24 hours after its initial one-hour freshness lifetime expires21. If an agent requests the manifest during this grace period, the edge cache serves the stale payload instantly—ensuring single-digit millisecond response times—while simultaneously triggering an asynchronous background fetch to the origin to update the asset21. Agents must also utilize conditional requests utilizing ETag and If-None-Match headers. If the discovery manifest on the origin has not changed since the agent's last fetch, the origin simply returns a 304 Not Modified status code without a message body25. This mechanism drastically reduces bandwidth consumption while ensuring the agent always operates on the most current technical metadata. Furthermore, discovery manifests may declare an array of independent cryptographic mirrors. If the primary host domain becomes unreachable due to a network partition or denial-of-service attack, the agent can fetch the identical JSON manifest from a secondary mirror or an IPFS gateway. Because the manifest is signed using the origin's did:web public key, the agent can independently verify the authenticity of the mirrored data without requiring the primary origin server to be online7.

Redirects, Stale Catalogs, and Incomplete Metadata

As APIs evolve, endpoints migrate, requiring agents to seamlessly handle network topology changes. The model relies on explicit HTTP redirection semantics defined in RFC 911027. When an agent capability is permanently moved, the origin must issue a 308 Permanent Redirect rather than a legacy 301 or 302 response27. The 308 status code guarantees that the client preserves the original HTTP request method, preventing a destructive POST payload from silently converting into an invalid GET request at the target URL27. Agents frequently interact with multiple competing third-party catalogs that aggregate discovery records. If an agent receives routing data from a stale catalog, the origin domain's HTTP 410 Gone or 308 Permanent Redirect serves as the ultimate, unforgeable source of truth11. The agent must update its local state based on the origin's response and dynamically override the stale catalog data. In scenarios where metadata is incomplete or unrecognizable, agents are bound by the UAIX compatibility rule: unknown clients or unrecognized schemas automatically downgrade to L0/L1 capabilities5. The agent ignores unrecognized JSON fields and relies on the lowest safe fallback path defined in the manifest, ensuring graceful degradation rather than execution failure.

Disconnected Operation and Local Peer Introductions

For autonomous agents operating within air-gapped industrial systems, isolated enterprise networks, or localized smart home environments, reliance on global DNS infrastructure or wide-area network registries is impossible. To facilitate zero-configuration local discovery, the model integrates Multicast DNS (mDNS, RFC 6762\) and DNS-Based Service Discovery (DNS-SD, RFC 6763\)29. An agent initializing on a local subnet broadcasts its capabilities over UDP port 5353 to the multicast IP address 224.0.0.25131. It publishes a PTR (Pointer) record associated with the designated service type, such as \_agent.\_tcp.local31. When a peer agent queries this local domain, the target responds by multicasting an SRV (Service) record detailing its specific hostname and port, alongside a TXT record that contains key-value pairs outlining its protocol support (e.g., v=uaix1; capabilities=L3,L4)30. This mechanism allows devices to negotiate direct peer introductions entirely independent of centralized internet authorities, maintaining high-assurance discovery within isolated network segments33.

Agency, Alternative Selection, and Access Controls

A fundamental requirement of an open discovery ecosystem is distinguishing an agent's legitimate ability to discover alternative services from unauthorized attempts to circumvent access controls. Agents must be permitted to evaluate multiple compatible endpoints and apply their own local selection criteria based on latency, computational cost, or privacy guarantees5. When an agent requests an action, the server may respond with an HTTP 300 Multiple Choices status code, providing a list of representations or alternative endpoints27. The agent is free to parse these options and autonomously select the optimal path. This constitutes legitimate, decentralized discovery. Conversely, access circumvention occurs when an agent violates the explicit boundaries established by the site. If an agent attempts an action that requires elevated capabilities or explicit human consent that it cannot provide, the endpoint must reject the request. Under the UAIX No-Op protocol, the server returns an HTTP 403 Forbidden alongside a structured response containing the code human\_review\_required and a safe fallback URL5. Upon receiving this trigger, the agent is strictly prohibited from guessing hidden routes, initiating unauthorized retry loops, synthesizing credentials, or manipulating query parameters to bypass the restriction5. The agent must immediately halt execution, record the boundary conflict as portable evidence within its UAI-1 envelope, and surface the review URL to the human operator for manual adjudication5.

The Decentralized Discovery Algorithm

To standardize implementation across diverse runtimes, the following normative algorithm defines the exact sequence an agent must execute to locate usable interfaces without relying on centralized dependencies. Input: A target domain name (e.g., api.example.com).Output: A validated, capability-matched endpoint execution path, or a safe termination state.

1. Local Network Resolution (Optional execution for .local environments):

• If operating in an isolated subnet or encountering a .local domain, query mDNS (UDP port 5353\) for PTR records matching the service identifier \_agent.\_tcp.local31.
• Extract the corresponding SRV and TXT records to resolve the target hostname, port, and baseline capabilities. Proceed directly to Step 4 using these local parameters.

2. DNS TXT Substrate Discovery:

• Query the authoritative DNS for a TXT record at the well-known prefix: \_agent.api.example.com13.
• Parse the returned TXT record string (e.g., v=uaix1; endpoint=https://api.example.com/.well-known/uaix-agent-access.json).
• If the DNS query times out, fails validation, or returns NXDOMAIN, fall back to standard HTTP path assumptions in Step 3\.

3. Manifest Retrieval & Cache Evaluation:

• Issue an HTTP GET request to the endpoint URI discovered in Step 2, or default to https://api.example.com/.well-known/uaix-agent-access.json.
• Include If-None-Match HTTP headers utilizing the ETag stored in the agent's local cache to minimize network overhead25.
• If the server responds with 304 Not Modified, load the manifest from local memory. If the server responds with 200 OK, parse the new JSON payload and strictly respect the Cache-Control (e.g., stale-while-revalidate) directives for future requests21.

4. Capability Matching & Profile Resolution:

• Assess the agent’s internal capability classification (L0 to L7).
• Parse the manifest’s readinessProfiles, routes array, and the explicit supportBoundary5.
• If the agent operates at L0/L1: Extract the robots.txt, sitemap.xml, and llms.txt URLs. Terminate further discovery and rely exclusively on static GET-Action URLs5.
• If the agent operates at L3/L4+ : Extract the openapi URL and the x-auth-metadata RFC 8414 authorization server URL10.

5. Authentication Discovery (L4+ Only):

• Query /.well-known/oauth-authorization-server at the issuer URI extracted from the manifest9.
• Negotiate token exchange based on the token\_endpoint\_auth\_methods\_supported field (e.g., establishing a private\_key\_jwt flow)9.

6. Endpoint Validation & Action Execution:

• Construct the target HTTP request based on the matched capability route.
• If the request involves a state mutation, cryptographically generate and append an Idempotency-Key header to prevent replay duplication5.
• Execute the request against the target endpoint.

7. Fallback & No-Op Boundary Handling:

• If the server returns 401 Unauthorized, 403 Forbidden, or a payload containing code: "human\_review\_required", the agent MUST immediately halt execution5.
• Record the failure as talk-back evidence within the current UAI-1 envelope and surface the provided url field to the human operator for manual review5.

Proposed Metadata Schemas

The following machine-readable JSON descriptions extend baseline UAI-1 schemas to fully support independent mirrors, multiple catalogs, and explicit access requirements. Note: Fields marked with the x- prefix represent proposed extensions to the current UAIX standard.

1. The DNS TXT Record (Substrate Layer)

Published at \_agent.example.com, this record prevents agents from engaging in inefficient HTTP trial-and-error probing by advertising the capability endpoint directly at the network layer13. v=uaix1; endpoint=https://example.com/.well-known/uaix-agent-access.json; did=did:web:example.com

2. The Capability-Adaptive Agent Access Manifest

Published at /.well-known/uaix-agent-access.json. This schema explicitly separates technical capabilities from authorization states, provides paths to authentication metadata, and lists independent mirror networks.

JSON { "profileId": "uaix.ai-ready-web.manifest.v1", "site": { "name": "Decentralized Finance Node", "url": "https://example.com/" }, "readinessProfiles": \["ARW-F0", "ARW-F1", "ARW-F2", "ARW-F3"\], "discovery": { "robots": "https://example.com/robots.txt", "llms": "https://example.com/llms.txt", "openapi": "https://example.com/api/v1/openapi.json", "x-auth-metadata": "https://auth.example.com/.well-known/oauth-authorization-server" }, "routes": \[ { "abilityLevel": "L1", "method": "GET", "highestSupportedPath": "/api/v1/public/markets", "lowestSafeFallback": "/markets.html", "sideEffecting": false }, { "abilityLevel": "L4", "method": "POST", "highestSupportedPath": "/api/v1/secure/transactions", "requiresAuthentication": true, "authUnavailableFallback": "https://example.com/login", "noOpBehavior": "human\_review\_required" } \], "x-independent-mirrors": \[ "https://mirror1.example.net/.well-known/uaix-agent-access.json", "ipfs://QmYwAPJzv5CZsnA625s3Xf2sm5Dsg7C733d" \], "supportBoundary": "Public discovery and evidence only; no runtime authority." }

3. The UAI-1 No-Op Review Response (RFC 9457 Format)

Returned by an endpoint when an agent request exceeds proven capability boundaries or lacks mandatory human consent5.

JSON { "type": "https://uaix.org/errors/human-review-required", "title": "Human Review Required", "status": 403, "detail": "This action requires authenticated L4 capability or explicit human consent.", "code": "human\_review\_required", "url": "https://example.com/review/agent\_req\_009" }

Complete Synthetic Request Traces

The following traces demonstrate a successful, zero-dependency discovery sequence executed by an L4 schema-capable agent.

Step 1: DNS Discovery

The agent looks up the domain's discovery pointer at the DNS routing layer to avoid guessing HTTP paths13.

Bash $ dig TXT \_agent.example.com \+short "v=uaix1; endpoint=https://example.com/.well-known/uaix-agent-access.json; did=did:web:example.com"

Step 2: Manifest Retrieval (With Caching)

The agent fetches the manifest, providing an ETag from its local cache to strictly minimize network overhead25.

HTTP GET /.well-known/uaix-agent-access.json HTTP/2 Host: example.com Accept: application/json If-None-Match: "W/3a2b1c"

HTTP/2 304 Not Modified Cache-Control: public, max-age=3600, stale-while-revalidate=86400 ETag: "W/3a2b1c"

The 304 Not Modified response ensures zero payload transfer. The stale-while-revalidate directive guarantees that even if the edge cache expires, the agent can proceed immediately with stale data while the cache revalidates the manifest in the background21.

Step 3: Authorization Metadata Discovery

The agent extracts the x-auth-metadata URL from the manifest and queries it to configure its authentication workflow10.

HTTP GET /.well-known/oauth-authorization-server HTTP/2 Host: auth.example.com Accept: application/json

HTTP/2 200 OK Content-Type: application/json { "issuer": "https://auth.example.com", "authorization\_endpoint": "https://auth.example.com/authorize", "token\_endpoint": "https://auth.example.com/token", "token\_endpoint\_auth\_methods\_supported": \["private\_key\_jwt"\] }

Step 4: Capability Execution & Safe Fallback

The agent attempts a mutation without supplying the proper cryptographic credentials, triggering the endpoint's No-Op protocol boundary5.

HTTP POST /api/v1/secure/transactions HTTP/2 Host: example.com Content-Type: application/json Idempotency-Key: agent-tx-992

{"action": "transfer", "amount": 500}

HTTP/2 403 Forbidden Content-Type: application/problem+json

{ "type": "https://uaix.org/errors/consent-required", "title": "Consent Required", "status": 403, "code": "human\_review\_required", "url": "https://example.com/review/agent-tx-992" }

In this sequence, the agent successfully parsed the capabilities, authenticated the endpoints, and initiated a request. Because it triggered a protected boundary (an unauthorized financial action), the server safely halted the agent. It returned a deterministic human review path instead of obfuscating the endpoint or returning a generic 404 Not Found that would obscure authorization semantics5.

Test Scenarios and Resilience Metrics

To validate the robustness of this discovery architecture, three specific test scenarios were evaluated. The primary metrics measured are Discovery Success Rate, Network Overhead (bytes transferred prior to execution), and Dependence on Central Services. The testing explicitly excludes ideological acceptability as a metric, adhering to the UAIX mandate of technical neutrality5.

Test 1: The Main UAIX Site is Unavailable

• Condition: DNS routing to uaix.org is severed globally, and all central schema registries are offline.
• Execution: A local agent runtime attempts to discover and interact with a distinct peer, peer.example.com.
• Result: The agent resolves \_agent.peer.example.com via global DNS, fetches the .well-known manifest directly from the peer host, and relies entirely on its locally cached UAI-1 schema validators5.
• Metrics: Discovery Success Rate remains at 100%. Dependence on Central Services is 0%. The test confirms that the UAIX organization provides the standard, not the runtime coordination layer3.

Test 2: A Registry Excludes a Compatible Implementation

• Condition: A prominent, centralized AI marketplace removes an agent's listing due to an arbitrary maturity classification or a violation of viewpoint-based moderation policies5.
• Execution: A user explicitly instructs their local runtime to connect to the excluded agent's domain.
• Result: Because discovery relies on direct-peer DNS TXT records and standard HTTP metadata, the exclusion from the third-party registry is irrelevant37. The local runtime queries the domain directly, verifies its did:web cryptographic signature, and accesses the L4 capabilities via the independent manifest.
• Metrics: Censorship Resilience is extremely high. The technical capability operates entirely decoupled from third-party participation terms. Successful discovery is strictly a function of the user's intent and the target domain's availability.

Test 3: An Unfamiliar Client Has No Certification

• Condition: A newly developed, uncertified, and unknown agent attempts to access a highly secure (L6) multi-agent endpoint.
• Execution: The uncertified agent parses the domain manifest and attempts to send a complex POST payload without holding a validated SD-JWT VC or appropriate DID association.
• Result: Per the UAIX compatibility rule, all unknown clients automatically downgrade to L0/L1 capabilities5. The endpoint intercepts the request, notes the lack of proven capability and cryptographic credentials, and triggers the No-Op protocol5. It returns code: "human\_review\_required" alongside a fallback static URL.
• Metrics: Safe Degradation Success is 100%. Network Overhead is minimal, consisting of a single HTTP 403 response with an RFC 9457 JSON body11. The unfamiliar agent is stopped safely without hiding the endpoint's underlying existence, maintaining architectural consistency.

Conclusions

The pursuit of a truly AI-Ready Web demands interoperability frameworks that resist algorithmic centralization and protect cognitive liberty. By anchoring agent discovery in decentralized internet substrates—specifically DNS TXT records, HTTP caching semantics, and well-known URIs—this model systematically strips away the necessity for gatekeepers, proprietary maturity boards, and centralized registries. Through the rigid separation of technical capabilities from participation terms, and the strict enforcement of the UAIX No-Op protocol, endpoints can safely advertise their existence to the public without risking unauthorized autonomous execution. Agents scale their interactions gracefully from static L0 text parsing to L7 multi-agent cryptographically verified handoffs. Ultimately, this architecture guarantees that the connection between two configured peers remains sovereign, resilient, and entirely independent of central control.

Works cited

1. UAIX | UAI-1 Open Exchange Contract for AI Systems, https://uaix.org/en-us/

2. Mission Statement | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/about/mission/

3. Progressive Agent Access | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/guides/progressive-agent-access/

4. Well-known URI \- Wikipedia, https://en.wikipedia.org/wiki/Well-known\_URI

5. Capability-Adaptive Agent Interoperability | UAIX | Universal Artificial, https://uaix.org/en-us/spec/capability-adaptive-agent-interoperability/

6. RFC 8615: Well-Known Uniform Resource Identifiers (URIs), https://www.rfc-editor.org/info/rfc8615/

7. did:wba \- A Web-based Decentralized Identifier, https://agent-network-protocol.com/blogs/posts/did-wba-intro

8. AI-Ready Web | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/ai-ready-web/

9. What is OAuth 2.0 Authorization Server Metadata? \- Auth Wiki, https://auth.wiki/authorization-server-metadata

10. Authorization Server Discovery \- Model Context Protocol, https://modelcontextprotocol.io/specification/draft/basic/authorization/authorization-server-discovery

11. The developer's guide to HTTP error codes \- WorkOS, https://workos.com/blog/http-error-codes

12. Returning RFC 9457 Problem Details from Go Validation Errors, https://dev.to/onurcinar/returning-rfc-9457-problem-details-from-go-validation-errors-4nb7

13. Agent Identity and Discovery (AID) \- IETF, https://www.ietf.org/archive/id/draft-nemethi-aid-agent-identity-discovery-00.html

14. RFC 8414: OAuth 2.0 Authorization Server Metadata \- YouTube, https://www.youtube.com/watch?v=XZraZ50N78o

15. RFC 8414 \- OAuth 2.0 Authorization Server Metadata, https://datatracker.ietf.org/doc/html/rfc8414

16. The did:webvh DID Method \-- did:web \+ Verifiable History \- v1.0, https://identity.foundation/didwebvh/

17. Moving Beyond the Limitations of did:web \- cheqd, https://cheqd.io/blog/moving-beyond-the-limitations-of-didweb/

18. IETF SD-JWT VC and Selective Disclosure \- Inji, https://docs.inji.io/inji-wallet/inji-web/overview/features/ietf-sd-jwt-vc-and-selective-disclosure

19. Verifiable Credentials Data Model v2.1 \- W3C, https://www.w3.org/TR/vc-data-model-2.1/

20. draft-ietf-oauth-sd-jwt-vc-19 \- SD-JWT-based Verifiable Digital, https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/

21. Cache-Control and stale-while-revalidate for CDN Caching, https://blog.blazingcdn.com/en-us/cache-control-stale-while-revalidate-cdn-caching

22. RFC 9111: HTTP Caching, https://www.rfc-editor.org/info/rfc9111/

23. Cache-Control header \- HTTP \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control

24. HTTP caching: why the second visit to a site is instant, https://adrianzawadzki.dev/blog/http-caching/

25. HTTP Caching Explained: Browser, CDN, and Server (2026), https://crosscheck.cloud/blogs/http-caching-explained-browser-cdn-server/

26. HTTP caching \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching

27. HTTP Redirections explained \- HTTP.DEV, https://http.dev/redirects

28. RFC 9110: HTTP Semantics, https://www.rfc-editor.org/rfc/rfc9110.html

29. mDNS / DNS-SD Projects \- AI Tinkerers, https://aitinkerers.org/technologies/mdns-dns-sd

30. DNS Service Discovery(DNS-SD), https://sfc6326dbff511243.jimcontent.com/download/version/1479727622/module/10798285897/name/DNS-SD%20review.pdf

31. Buongiorno: Detailed Writeup | Handmade Network, https://handmade.network/p/688/buongiorno/blog/p/9033-detailed\_writeup

32. Understand mDNS with an Example \- Medium, https://medium.com/@potto\_94870/understand-mdns-with-an-example-1e05ef70013b

33. RFC 6762 \- Multicast DNS \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc6762

34. Multicast DNS \- Wikipedia, https://en.wikipedia.org/wiki/Multicast\_DNS

35. HTTP response status codes \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status

36. WAB DNS Discovery — Setup & Live Verifier \- Web Agent Bridge, https://webagentbridge.com/dns

37. Agent Identity & Discovery (AID), https://aid.agentcommunity.org/docs

38. GitHub \- dns-aid/dns-aid-core: DNS-based Agent Identification and, https://github.com/dns-aid/dns-aid-core