Design Note: AX as a Pre-Registration Discovery Layer for AEX

[sempfa]

Purpose

This note clarifies how Agent Discovery Exchange (AX) relates to Agent Exchange (AEX) and why AX is intended to strengthen, not replace, a registration-based exchange model.

The goal is to avoid conflating open discovery with authoritative registration, and to show how both can coexist cleanly using well-understood distributed systems patterns.

Problem Statement

As agent ecosystems scale across organizational and administrative boundaries, discovery becomes a bottleneck. Today, emerging agent exchanges often combine:

• discovery

• registration

• trust verification

• economic participation

into a single, centralized control plane.

While this provides strong guarantees, it also introduces friction and fragmentation: agents must integrate separately with each exchange, and discovery becomes siloed behind proprietary onboarding APIs.

Architectural Framing (Telecom Analogy)

From a telecom perspective, this mirrors long-standing design patterns:

• NRF-style registration provides:

  • authenticated identity

  • immediate consistency

  • authoritative trust boundaries

  • controlled admission

• But NRF assumes a closed, operator-managed domain and does not address how network functions are discovered prior to registration.

AX is explicitly not an NRF replacement.

Instead, AX fills a gap that exists before NRF-style onboarding.

Role of AX

AX defines a pre-registration discovery mechanism that allows agent functions to expose:

• machine-readable capability descriptors

• supported interaction protocols

• optional trust or provenance signals

at a stable, internet-native location.

Key properties:

• AX does not grant trust

• AX does not authorize participation

• AX does not perform semantic matchmaking

• AX does not replace registration

In telecom terms, AX is closer to a capability advertisement surface than a control-plane registry.

How AX Improves AEX

AEX can remain fully registration-based and authoritative while consuming AX metadata as an input signal.

A practical flow looks like this:

1. Capability Advertisement (AX)
   Agent operators publish standardized capability metadata at a stable endpoint.

2. Pre-Registration Intake (AEX)
   AEX consumes AX documents selectively (partner domains, federated peers, curated sources).

3. Registration & Admission (AEX)
   AEX performs identity verification, policy checks, trust establishment, and activation.

4. Operational State (AEX)
   AEX remains the system of record for availability, trust score, pricing, and settlement.

This preserves all the desirable properties of registration-based systems while removing discovery fragmentation.

+----------------------------+      +----------------------------+      +----------------------------+
| Agent Discovery Exchange   |      | AEX Intake / Discovery     |      | Agent Exchange (AEX)       |
| (AX)                       |      | Intake                     |      | Registration & Control     |
|                            |      |                            |      | Plane                      |
|  agent.example.com         | ---> |  AX Metadata Consumer      | ---> |  Identity Verification     |
|  /.well-known/             |      |  Policy Filters            |      |  Trust Establishment       |
|  agent-exchange            |      |  Federation Scope          |      |  Admission Control         |
|                            |      |  Optional Pre-Validation   |      |  Pricing / Settlement      |
|  Capability Metadata       |      |                            |      |  Runtime Availability      |
|  Protocols                 |      |                            |      |                            |
|  Optional Attestations     |      |                            |      |                            |
|                            |      |                            |      |                            |
|  (Open, non-authoritative) |      |  (Advisory, non-binding)   |      |  (Authoritative)           |
+----------------------------+      +----------------------------+      +----------------------------+

AX provides an open, pre-registration discovery substrate. AEX remains authoritative for identity verification, trust establishment, and activation. Discovery and registration are explicitly decoupled.

Scale Considerations

AX does not imply uncontrolled global crawling.

Just as NRF federation is selective and policy-driven, AX consumption can be:

• scoped to known domains

• cached and incrementally refreshed

• filtered by policy before registration

AEX does not need to discover “all agents on the internet”, only those relevant to its ecosystem.

Trust Model

AX assumes that advertised information is not trustworthy by default.

Trust remains downstream:

• identity verification

• credential validation

• reputation and outcome scoring

• compliance enforcement

all remain responsibilities of AEX or other coordination layers.

AX merely standardizes the format and location of discovery signals so those processes don’t rely on bespoke integrations.

Design Principle

Decouple discovery from registration.

• Discovery should be open, standardized, and interoperable.

• Registration should be fast, authoritative, and trusted.

This mirrors proven architectures in telecom, networking, and the web, and avoids turning discovery into a proprietary chokepoint.

Summary

AX is not an alternative exchange.
AX is not a trust authority.
AX is not a semantic marketplace.

AX is a discovery substrate that allows systems like AEX to scale intake and federation without sacrificing governance.

Used together, AX and AEX preserve the strengths of registration-based systems while reducing ecosystem friction and fragmentation.

[fenar]

Good explanation and structural thinking. Are you planning to implement it as part of the Agent-Exhange repo (we can put a plan around it with some teaming) ?

[sempfa]

Thanks, glad it resonates.

My current thinking is to keep AX itself separate and registry-agnostic, so it can serve multiple downstream systems (including Agent-Exchange, enterprise registries, marketplaces, etc.) without being coupled to any one implementation.

That said, I do think it makes a lot of sense to implement AX consumption inside Agent-Exchange as a concrete reference path e.g. using AX as a pre-registration discovery and intake layer feeding into Agent-Exchange’s existing broker/registry model.

I’m very open to collaborating on that, whether as a reference implementation, optional module, or phased plan, as long as the separation between open discovery (AX) and broker/registry semantics remains clear. Happy to discuss how best to structure that together.