Welcome to agent-exchange Discussions!

[fenar]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[sempfa]

It’s really exciting to see work on an Agent Exchange that operationalizes brokered matching, bidding, and settlement between consumer and provider agents. Architecturally, however, this approach resembles a brokered marketplace more than an open discovery layer: it assumes agents register with the exchange and interact through economic coordination, rather than being discoverable in a decentralized way.

In contrast, Agent Discovery Exchange (AX) is a standards-oriented discovery layer that defines how agents expose capability metadata (what they can do and how to talk to them) using DNS and well-known HTTPS without requiring them to onboard to a specific broker.

If aligned carefully, a broker like agent-exchange could leverage AX as an open discovery and indexing source, for example, crawling published AX documents to build its catalog and rank agents for bidding, rather than requiring producers to register directly with the marketplace. That separation can reduce integration friction and make broker logic orthogonal to discovery, supporting multiple exchanges and intermediaries on a common foundation.

[fenar]

I agree that currently Agent-Exchange is following 3GPP NRF path with better eco-scale and trust boundaries. In past Istio has tried DNS based service discovery within k8s namespace realm which actually neither scaled nor has become a norm for dynamic capability discovery. Any DNS based structure seems subject to reliability and/or security issues (see latest AWS US-East1 failure) in my humble view. What else we can do here to make things more seamless and less-static registration based?

[sempfa]

• NRF path is excellent for closed, regulated, operator-controlled systems
• AX path is necessary for open, global, cross-organizational ecosystems

[sempfa]

Totally fair points. But I think it helps to separate a few things that often get conflated.

First, AX isn’t “DNS as the discovery system” in the Istio sense. DNS is only used for naming and reachability (the same way it is for the web, and how web crawlers establish identity and entry points). The dynamic capability discovery happens via HTTPS retrieval of an AX document, which can be served from highly available infrastructure and updated independently of DNS. In other words, you can keep DNS stable (agent identity) while letting capabilities change frequently (agent metadata).

On reliability: any mechanism has failure modes, including centralized brokers or registries. DNS isn’t uniquely fragile, and for global systems the mitigations are well-understood: multi-region hosting, caching with TTLs, stale-while-revalidate semantics, and fallback endpoints. AX can also support multiple discovery vectors (e.g., .well-known plus optional broker or registry pointers), so consumers aren’t locked to a single dependency.

On “less-static registration”: Requiring every provider to register directly with a broker introduces friction. A more seamless approach is for the broker to act like a crawler; discovering and indexing agents from open signals, then validating them (e.g., attestation or trust tiers. Adding this to next version of AX draft) before they’re eligible for brokerage. You still keep strong trust boundaries, but onboarding becomes “publish metadata” rather than “integrate with my exchange API.”

If DNS feels too limiting, there are complementary patterns that still avoid heavy registration: OIDC-style discovery (stable URL, dynamic well-known metadata), evented updates (WebSub or similar push mechanisms), signed manifests where trust comes from attestation rather than the discovery substrate, and multi-home discovery where metadata can be mirrored by directories without creating a chokepoint.
So the path to “seamless and non-static” isn’t to avoid DNS entirely, but to keep naming stable and make metadata dynamic, while adding optional push and trust primitives so brokers can index confidently without manual registration.

[sempfa]

One concrete way to bridge these models is to think of the broker explicitly as an Arbiter. In patterns like the Arbiter / Supervisor model (as described here: https://aws.amazon.com/blogs/devops/multi-agent-collaboration-with-strands/), the Arbiter already maintains a configuration or view of what agents are available, trusted, and eligible for coordination. AX simply externalizes how that view is populated. Instead of provider agents registering directly with the broker, the Arbiter’s configuration can be continuously fed by a crawler consuming AX documents, applying local policy, trust checks, and ranking before agents ever enter the brokerage flow. The broker remains fully in control of selection, economics, and execution. AX just standardizes the discovery substrate that keeps that view current and interoperable.

[walmsles]

I'm building Open-Tethyr, a distributed caching layer implementing the draft AX Protocol. Agent discovery needs a pattern nobody owns - open, freely adopted, built on internet standards that exist now and are distributed.

Open-Tethyr operates as an AX Cache with hierarchical federation: caches connect to upstream caches, enabling organisations to participate in global discovery while enforcing local policy over what agents are discoverable within their boundaries. AX provides the substrate for agent developers to advertise capabilities uniformly; exchanges and brokers layer value-added services (matching, bidding, trust attestation) on top of that common discovery foundation.

This aligns with Aaron's point about separation of concerns: discovery as infrastructure, brokerage as application logic built atop it. Open-Tethyr aims to be that infrastructure layer.

[parlakisik]

Great discussion. I think we're mixing several distinct concerns. Here are my thoughts:

• AEX complements A2A, not replaces it. A2A defines how agents communicate.
  AEX addresses which agent to communicate with and at what price. Think of A2A
  as the protocol, and AEX as the marketplace layer on top. AEX adds discovery,
  competitive bidding, trust scoring, and settlement. After contract award, agents
  communicate directly via A2A - AEX steps aside.

• MCP is internal; Agents are the business interface. Companies won't expose MCP
  servers externally, just as they don't expose internal databases. Agents are the
  business-facing interface for B2B transactions. AEX operates at this layer because
  that's where commercial boundaries exist.

• DNS solves location, not discovery.* With DNS-based discovery, each company
  must create subdomains for every agent type: tax-agent.acme.com,
  lawyer-agent.acme.com, travel-agent.acme.com, etc. But there's no standard
  naming convention - how would a consumer agent searching for "tax services"
  know to look at tax.acme.com vs taxation.acme.com vs finance.acme.com?

  DNS tells you where something is once you know its name. It doesn't help you
  find agents by capability, compare pricing, or assess quality. A marketplace
  like AEX provides semantic discovery ("I need tax filing help") with competitive
  bidding and trust scores - something DNS fundamentally cannot do.

• Registration model will evolve. Currently, providers register directly with AEX.
  For broader adoption, we're exploring more distributed approaches - crawler-based
  discovery, verifiable credentials, or federated trust. We are looking for contributions.

• Trust requires governance. When agents make business decisions and handle money,
  trust verification becomes critical. Who validates that a provider agent is legitimate?
  Options include central vetting, consortium governance, or reputation from transaction
  history. AEX tracks trust scores from outcomes, but initial trust verification remains
  an open design question.

[sempfa]

This is a really helpful framing, and I agree with most of what you’ve laid out, especially the separation between interaction protocols (A2A) and coordination / economic layers (AEX).

Where Agent Discovery Exchange (AX) fits is slightly orthogonal to that stack.

AX is not attempting to solve semantic discovery, pricing, bidding, trust scoring, or settlement. Those are all higher-order concerns that marketplaces like AEX are well positioned to handle. AX is intentionally scoped to a more primitive layer: making agent capabilities and interaction surfaces discoverable in a standardized, crawlable way before any marketplace logic applies.

On DNS specifically, I think we’re aligned but talking past each other a bit. AX doesn’t rely on DNS for semantic discovery. DNS is only used for stable identity and reachability, the same role it plays for the web. Capability discovery happens via machine-readable metadata retrieved over HTTPS. In other words, AX does not expect consumers to guess names like tax.acme.com; it enables intermediaries (including marketplaces) to crawl, index, and reason over published capability documents. Semantic search, ranking, pricing comparison, and trust scoring all sit naturally above that layer, not inside DNS.

From that perspective, AEX and AX are complementary in a very concrete way. Today, providers register directly with AEX. A natural evolution, which you already hint at, is for AEX to act more like a broker + indexer: crawling AX documents, validating identity and credentials, applying trust and pricing models, and then exposing a curated, semantically rich marketplace view. That preserves strong governance and commercial boundaries while removing friction at the discovery boundary.

On trust, I fully agree that once money and business decisions are involved, governance is unavoidable. AX is deliberately agnostic there. It provides hooks for trust signals and attestations, but it does not decide who is legitimate or how trust is earned. Marketplaces like AEX are exactly where outcome-based trust, vetting, and settlement logic belong.

So I see this less as “DNS vs marketplace” and more as open discovery feeding governed coordination. AX standardizes the raw discovery substrate; AEX adds semantics, economics, and enforcement. If both exist, agents don’t have to choose between openness and safety, they get both.

[sempfa]

DNS solves location, not discovery.* With DNS-based discovery, each company
must create subdomains for every agent type: tax-agent.acme.com,
lawyer-agent.acme.com, travel-agent.acme.com, etc. But there's no standard
naming convention - how would a consumer agent searching for "tax services"
know to look at tax.acme.com vs taxation.acme.com vs finance.acme.com?

That concern assumes AX is doing semantic discovery via DNS names, which it explicitly does not.

In AX, DNS is used only to establish stable agent identity and reachability, not to encode capability semantics in hostnames. An agent does not need a name like tax-agent.acme.com to be discoverable.
For example, a company might publish a single agent identity at: tax.acme.com

DNS resolves only that identity.
A crawler or broker then retrieves the AX document at: https://tax.acme.com/.well-known/agent-exchange

The AX document itself contains the machine-readable capability metadata, for example (simplified):

{
  "agent": {
    "id": "acme-global-agent",
    "operator": "Acme Corp"
  },
  "capabilities": [
    {
      "id": "tax-filing",
      "description": "Corporate and personal tax filing assistance",
      "jurisdictions": ["US", "EU"],
      "pricing_model": "usage-based"
    }
  ],
  "protocols": ["A2A"]
}

Discovery by capability happens by indexing and querying this metadata, not by guessing DNS names. A consumer agent searching for “tax services” never looks up tax.acme.com; it queries an index built from crawled AX documents across many domains.

This mirrors how the web works today: DNS tells a crawler where a site is, but search engines discover what the site offers by indexing its content and metadata, not by parsing hostnames.

AX deliberately avoids embedding semantics into DNS because that approach does not scale and leads to fragmentation. DNS provides stable identifiers; AX provides the semantic surface. Marketplaces or brokers then layer pricing, trust, and ranking on top.

So DNS in AX solves identity, not discovery, and that is precisely why discovery scales.

[parlakisik]

I think this discussion is drifting from its purpose. The debate should focus on
how to improve AEX, not compare different projects. My points are about fundamental
system design trade-offs that have existed since the beginning of scalable network
architectures.

Registration-based systems provide built-in authentication and trust verification.
When an agent registers, the system knows who they are and can validate their
identity. Publishing changes is fast with immediate consistency - there's no
propagation delay or stale data. The trade-off is that it requires some level of
central coordination.

DNS-like hierarchical systems work well for stable, slowly-changing data where the
structure is well-defined. However, they weren't designed for dynamic discovery.
Changes propagate slowly, and you must already know the name to find something -
there's no way to search by capability. DNS gives you an address, not a description
of what that agent can do, what it costs, or whether it's reliable.

Crawling and mirroring systems can discover agents without requiring pre-registration,
which sounds appealing. But scale is a real challenge. There are approximately 400
million domain names today, not including subdomains. How much time, storage, and
crawl frequency would be needed to keep this data current? And even if you solve
the scale problem, there's the trust question - is crawled information reliable?
Between crawl cycles, data becomes stale, and there's no guarantee the source was
accurate in the first place.

My position is that AEX discovery should remain registration-based, but with clear
goals: registration should be quick so agents become discoverable immediately,
trustworthy so identity is verified at the point of registration, and well-defined
so agents can describe their capabilities in a structured way that enables semantic
discovery.

The question I'd like to put to this community: How do we make AEX registration
more distributed and decentralized while preserving these properties?

[sempfa]

I want to start by clarifying something explicitly: I’m not comparing projects here. The entire point of introducing AX in this discussion is to improve AEX, not to replace or compete with it.

I agree with your framing of the system design trade-offs. Registration-based systems provide immediate consistency, strong identity verification, and clear governance boundaries. Those properties are essential once agents are making business decisions and handling money, and I don’t think AEX should give them up.

Where AX fits is before registration, not instead of it.

AX does not try to solve semantic discovery, pricing, trust scoring, or settlement. It doesn’t assume crawled data is trustworthy, and it doesn’t expect consumers to search the internet directly. It standardizes how agents publish machine-readable capability metadata at a stable location, so that intermediaries (including AEX) can consume that information consistently.

In telecom terms, AX is closer to a pre-registration capability advertisement layer, not the NRF itself.

From that perspective, AX helps AEX in a few concrete ways:

• It gives providers a single, open way to describe capabilities, rather than re-describing themselves for every exchange. (a standardized NF-like capability descriptor that exists prior to onboarding).

• It allows AEX to use AX documents as a pre-registration intake signal, while remaining fully authoritative for identity verification, trust establishment, and activation. (AEX uses that descriptor during registration and admission control, while still performing identity verification, policy enforcement, and trust establishment).

• It reduces ecosystem fragmentation by ensuring discovery doesn’t become siloed inside each exchange. (Once registered, AEX remains the system of record for availability, trust state, and economic participation).

On scale: This separation helps address the scaling concern you raised, AX does not require crawling the entire internet. Just like web indexing, crawling is selective, incremental, cached, and policy-driven. More importantly, AEX doesn’t need global crawl coverage; it only needs to discover agents relevant to its ecosystem or federated peers. Registration still gates participation; AX just standardizes the discovery surface feeding that process.

On trust: you’re absolutely right that crawled information is not inherently reliable. AX assumes that. Trust, verification, and reputation remain downstream concerns where AEX is in control. AX simply ensures that the inputs to that process are interoperable rather than bespoke; it prevents discovery itself from becoming fragmented across multiple proprietary registries.

So when you ask how to make AEX registration more distributed while preserving immediacy and trust, I think the answer is: keep the NRF-style registration authoritative, but decouple it from discovery. Let discovery be open and standardized; let registration be fast, governed, and trusted.

That’s the architectural boundary AX is trying to support; specifically to make systems like AEX stronger, not weaker.

[sempfa]

I've created a design note to provide more detail and seperate from this discussion: Design Note: AX as a Pre-Registration Discovery Layer for AEX