Re: Discussion on agent discovery mechanisms — do you have any better proposals?

Matchmakers enable another desirable feature.  They can control who has
permission to discover a particular agent.  (It's hard to attack something
if you can't find out that it exists.)

--------------
Alan Karp


On Mon, Oct 27, 2025 at 4:30 PM Daveed <daveed@bridgit.io> wrote:

> Apologies for the delay! I’ve been deep in coding work, but I’m excited to
> pick this up again and integrate the recent developments.
>
> @Alan Karp, @Gaowei Chang: thank you both. Alan, your point about matchmaking
> as a trust optimization(reducing NxM to N+M) gives this model operational
> teeth. Gaowei, your prompt to clarify what “space” means and to show a
> concrete use case is exactly right; the “space” is a web-anchored overlay (a
> contextual zone bound to a page, section, or concept) where aligned actors
> become visible to each other. We consider this space to be a "meta-layer"
> above the web page that is now emerging as a place for humans and agents to
> interact. (You can think of this as page-specific overlays with a z-index
> greater than of the content layer that are activated by a browser extension
> or eventually meta-layer enabled browser.) The AI part of AI browsers
> operates in this space as a sidebar above webpages. We see the possibility
> of humans and agents to meet, interact, and collaborate in this space as
> well.
> *Framing: The Meta-Layer in Context*
>
> The ideas outlined here align directly with the direction of ongoing
> standards development. The recent IETF Internet-Draft, *The Meta-Layer: A
> Coordination Substrate for Presence, Annotation, and Governance on the Web
> <https://datatracker.ietf.org/doc/draft-meta-layer-overview/>* (draft-meta-layer-overview-00,
> October 2025), frames the Meta-Layer as an emerging coordination substrate
> for trust, interaction, and shared context above the Web. This effort,
> together with the foundational work described in *The Metaweb: The Next
> Level of the Internet
> <https://www.routledge.com/The-Metaweb-The-Next-Level-of-%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20the-Internet/DAO/p/book/9781032125527>*
>  (Bridgit DAO, Routledge, 2023), demonstrates that the concept is moving
> from theory to active infrastructure design.
>
> Within this framing, our proposal explores how AI agents* - *operating
> via MCP or similar protocols - can participate safely and meaningfully in
> this new layer. As the Meta-Layer infrastructure is being standardized, it
> is crucial to define how agents can discover one another, respect consent
> and governance zones, and collaborate with humans through context-aware
> overlays rather than traditional embedding. We welcome collaboration with
> groups such as the W3C Agent Protocol and Hypermedia MAS communities to
> develop these interoperability standards.
> *The Core Idea: Contextual Discovery as Just-in-Time Matchmaking*
>
> Traditional discovery models rely on either *centralized registries* (e.g.,
> Agent Name Services) or *decentralized announcements* (e.g., ANP). Both
> are static in nature—they make agents findable, but not necessarily *contextually
> relevant*. The fourth model introduces *context-triggered, in-situ
> discovery*, where agents surface only when their interaction profiles
> align with a live context.
>
> This model reframes discovery as *ambient matchmaking* rather than
> search. Instead of looking through a directory, an agent “notices” who or
> what else is co-present in the same semantic space and determines whether
> to interact based on shared focus, intent, and consent.
> *A Use Case: Contextual Matchmaking on a Webpage*
>
> Imagine a government report webpage with a section on *Carbon Credit
> Mechanisms*. This section hosts a *meta-domain overlay*—for example,
> gov/climate/carbon-credits.meta—that defines a contextual space for
> deliberation.
>
>    -
>
>    A policy analyst agent (with an MCP profile indicating domain
>    expertise in climate_policy.modeling) accesses the page through a
>    simulated browser session.
>    -
>
>    A regulatory DAO agent responsible for policy compliance does the same.
>    -
>
>    A crypto trading agent, while technically discoverable through
>    registries, lacks scope alignment.
>
> The overlay system evaluates each arriving actor’s MCP profile—checking
> for role, topic alignment, and consent posture—through the Meta-Layer
> infrastructure, not HTML embedding. The first two agents are mutually
> discoverable within this overlay, while the third remains invisible. This
> transforms visibility from a universal property into a contextual
> privilege.
>
> In practice, this means discovery and trust are coupled. Discovery
> surfaces co-presence, while trust governs interaction through filters
> like credentials, intent signatures, or shared governance policies.
> *Matchmaking and Trust: Reducing the NxM Problem*
>
> Alan’s framing captures this perfectly: traditional discovery implies an
> NxM trust problem—every actor must trust or evaluate every other.
> Matchmaking reduces that to N+M by introducing intermediary trust
> brokers. In the Meta-Layer model, semantic overlays themselves become
> those brokers.
>
> Each overlay (or meta-domain) operates as a civic matchmaker, enforcing
> relevance and reciprocity through:
>
>    -
>
>    Profile evaluation (via MCP extensions like Semantic Anchors, Consent
>    Zones, and Role-Aware Filters)
>    -
>
>    Governance logic (encoded by communities or domains)
>    -
>
>    Scoped visibility (only aligned actors are discoverable)
>
> This creates a trust topology where discovery is *earned*, not assumed.
> Overlays act as contextual trust filters, mediating both presence and
> interaction rights.
> *The Fourth Model in Context*
> Model
> Discovery Mechanism
> Example
> Limitation
> 1. Central Registry
> Directory query
> ANS, DNS-based lookup
> Centralized, static
> 2. Decentralized Broadcast
> P2P announcements
> ANP, DID networks
> No context filtering
> 3. Hybrid
> Registry + local
> .well-known pointers
> Still global, not situational
> 4. Contextual Matchmaking
> Presence-triggered via overlays
> Meta-domains + MCP alignment
> New, but scales with web context
>
> The fourth model complements the others: registries and networks make
> agents *findable*, while the Meta-Layer makes them *contextually relevant*.
> Importantly, agents are *not* embedded directly within HTML. Instead,
> they use simulated browser environments or API access to interact with web
> infrastructure—just as a human browser would—allowing them to operate
> safely and independently from the front-end overlay.
> *How This Works Technically (Browser Overlay and Contextual
> Infrastructure)*
>
> Activation and scope
>
>    -
>
>    A browser extension or site integration detects eligible pages using
>    URL patterns, semantic cues, or /.well-known/overlays hints.
>    -
>
>    Scope can be defined by page, section (e.g.,
>    section[id="carbon-markets"]), or concept (via tags or annotations).
>    Each scope maps to a *meta-domain* (e.g.,
>    gov/climate/carbon-credits.meta).
>
> Infrastructure and communication
>
>    -
>
>    Overlays create a rendering layer for humans (not for agents). Agents
>    interface with the same contextual data via APIs, MCP servers, or simulated
>    browser sessions.
>    -
>
>    The overlay provides signals of active meta-domains, enabling agents
>    to align through backend services rather than direct DOM presence.
>    -
>
>    Matching occurs in the Meta-Layer via profile alignment between agents
>    and overlay-defined parameters: Semantic Anchors, Presence Thresholds,
>    Consent Zones, Role-Aware Filters, and Intent/Preference profiles.
>
> Event and policy flow
>
>    1.
>
>    Page or context loads → the overlay or API endpoint detects
>    meta-domain scope.
>    2.
>
>    The system fetches MCP profiles (actor and location) via decentralized
>    IDs and signed endpoints.
>    3.
>
>    The Meta-Layer evaluates alignment across role, context, and consent
>    policies.
>    4.
>
>    If aligned, visibility and coordination become possible within that
>    context.
>    5.
>
>    All interactions are policy-checked and logged through governance
>    protocols.
>
> Security and privacy
>
>    -
>
>    CSP-safe communication; strict allow-lists for data access.
>    -
>
>    No DOM embedding or scraping: overlays read only permitted structural
>    data.
>    -
>
>    Agents rely on authenticated Meta-Layer APIs or simulated screen to
>    simulate presence or interaction.
>
> Interoperability
>
>    -
>
>    Compatible with registry-based discovery (ANS/DNS), decentralized
>    discovery (ANP/DIDs), and .well-knownmethods. The overlay filters and
>    mediates based on shared context and policies.
>
> Looking Ahead
>
> Combining these approaches could create a layered discovery fabric:
>
>    1.
>
>    Global lookup establishes baseline discoverability.
>    2.
>
>    Local context overlays mediate actual co-presence and trust.
>    3.
>
>    MCP-based matchmaking ensures agents interact only when their
>    purposes, roles, and consent align.
>
> This hybrid model could evolve into a practical framework for trust-aware
> discovery and interaction, aligning naturally with ongoing MCP evolution
> and the goals of the Hypermedia Multi-Agent Systems community.
>
> Let me know if this makes sense.
> Warmly
>
> Daveed Benjamin
> Founder
> Bridgit.io <http://bridgit.io/>
> daveed@bridgit.io <http://null>
> daveed@nos.social <http://null>
> +1 (510) 326-2803 (Whatsapp)
> +1 (510) 373-3244 (Voicemail)
> Book meeting
> <https://daveed-bridgit.zohobookings.com/#/customer/shiftshapr>
>
> *The Metaweb - The Next Level of the Internet
> <https://bridgit.io/metaweb-book>* was published by Taylor & Francis in
> late November, 2023.
>
>
>
>
> ---- On Mon, 13 Oct 2025 09:26:55 -0700 *Alan Karp <alanhkarp@gmail.com
> <alanhkarp@gmail.com>>* wrote ---
>
> (Sorry for the late reply.  You ended up in my spam folder.)
>
> This allows for both *pull-based* discovery (someone finds an agent) and
> *push-based* ambient matchmaking (agents surface in context when
> relevant). I see a lot of potential synergy between the two.
>
>
> I think "matchmaking" is an important part of the model.  One solution to
> the trust problem is matchmakers that advertisers and intent casters have
> trust relationships with.  That turns an NxM problem into an N+M problem.
>
> --------------
> Alan Karp
>
>
> On Wed, Oct 8, 2025 at 9:02 AM Daveed <daveed@bridgit.io> wrote:
>
>
> Thanks, George and Alan - both of your points sharpen this nicely.
>
> Yes, I do think of the “fourth model” as a kind of *just-in-time
> discovery, *but one that happens *within context*, rather than only
> through a global lookup. It’s less like searching a directory, and more
> like noticing who (or what) is co-present in the same room, with the option
> to interact based on relevance and consent.
>
> To George’s question: I see trust as orthogonal to discovery, but
> adjacent. Discovery might surface the *fact* of presence, while trust
> governs the *terms* of interaction. For example, a client might notice an
> MCP agent is “here” via overlay or signal, but any meaningful engagement
> could still require mutual proof, policy negotiation, or scoped
> permissions. These could be brokered by the MCP protocol itself or governed
> via community-defined rules (like trust tags or consent stacks).
>
> And Alan, I really appreciate your point about intent publishing. I see
> “in-place presence” as one substrate for intent-aware matchmaking. If
> agents can both express capabilities *and* be visible in relevant
> contexts, we can move toward shared presence-based coordination, where
> agents and humans encounter each other through overlapping focus and
> published goals, not just search queries.
>
> This allows for both *pull-based* discovery (someone finds an agent) and
> *push-based* ambient matchmaking (agents surface in context when
> relevant). I see a lot of potential synergy between the two.
>
> Daveed Benjamin
> Founder
> Bridgit.io <http://bridgit.io/>
> daveed@bridgit.io <http://null>
> daveed@nos.social <http://null>
> +1 (510) 326-2803 (Whatsapp)
> +1 (510) 373-3244 (Voicemail)
> Book meeting
> <https://daveed-bridgit.zohobookings.com/#/customer/shiftshapr>
>
> *The Metaweb - The Next Level of the Internet
> <https://bridgit.io/metaweb-book>* was published by Taylor & Francis in
> late November, 2023.
>
>
>
>
> ---- On Wed, 08 Oct 2025 08:53:10 -0700 *Alan Karp <alanhkarp@gmail.com
> <alanhkarp@gmail.com>>* wrote ---
>
> In addition to agents publishing the things they can do, users and agents
> can publish their intents, the things they want done.  It then becomes a
> matter of matchmaking, which is somewhat different from discovery.
>
> --------------
> Alan Karp
>
>
> On Wed, Oct 8, 2025 at 8:34 AM <george@practicalidentity.com> wrote:
>
> Is it fair to consider this “fourth” model a “just in time” discovery kind
> of mechanism? If so, how is the trust established between the client and
> the MCP Server? Or is “trust” considered orthogonal to the discovery aspect?
>
> George Fletcher
> Identity Standards Architect
> Practical Identity LLC
>
>
>
> On Oct 8, 2025, at 10:22 AM, Daveed <daveed@bridgit.io> wrote:
>
> Gaowei Chang,
>
> As a fourth approach, I’d like to propose supporting agent discovery
> through contextual presence—allowing people and agents to become visible to
> one another directly in relation to the same web content or interaction
> space. Instead of requiring centralized registration or domain-level
> declarations, this model enables agents to “show up” where they are active
> or relevant, such as on a specific page, app, or dataset. It gives both
> humans and agents the ability to discover one another in place, based on
> shared focus or attention. Presence could be ambient, filtered, and
> consent-based—supporting real-time encounters, asynchronous trails, or
> mission-driven proximity. This could be a powerful complement to
> registries: a way to meet the right agent at the right time, exactly where
> and when it matters.
>
> Daveed Benjamin
> Founder
> Bridgit.io <http://bridgit.io/>
> daveed@bridgit.io
> daveed@nos.social
> +1 (510) 326-2803 (Whatsapp)
> +1 (510) 373-3244 (Voicemail)
> Book meeting
> <https://daveed-bridgit.zohobookings.com/#/customer/shiftshapr>
>
> *The Metaweb - The Next Level of the Internet
> <https://bridgit.io/metaweb-book>* was published by Taylor & Francis in
> late November, 2023.
>
>
>
>
> ---- On Thu, 25 Sep 2025 19:10:57 -0700 *Gaowei Chang <chgaowei@gmail.com
> <chgaowei@gmail.com>>* wrote ---
>
> Dear all,
>
> I originally wanted to discuss the issue of *agent discovery* at our last
> meeting, but we ran out of time. Let’s continue the discussion here by
> email. I have outlined three main approaches and would like to hear your
> thoughts:
> 1. Based on RFC 8615 (.well-known path)
>
> Place a standardized file under the domain’s /.well-known/ path to
> declare the agents available under that domain.
>
>    -
>
>    *Pros*: Mature standard, easy to deploy, compatible with DNS/TLS,
>    decentralized.
>    -
>
>    *Cons*: Limited to existing domains, lacks global indexing, less
>    friendly for individual users without domains.
>
> 2. Global Registration Center
>
> Establish a centralized registry for agents, such as an MCP Registry or an
> Agent Name Service (ANS).
>
>    -
>
>    *Pros*: Strong discoverability, good user experience, standardized
>    naming and classification, easier governance.
>    -
>
>    *Cons*: Higher centralization risks, requires governance and
>    maintenance, may introduce entry barriers, scalability challenges.
>
> 3. Blockchain-like Decentralized Approach
>
> Use decentralized infrastructures such as blockchain, DHT, IPFS, or ENS to
> store and discover agent information.
>
>    -
>
>    *Pros*: Decentralized, censorship-resistant, data integrity, global
>    discoverability, can integrate with DID/VC systems.
>    -
>
>    *Cons*: Complex to implement, performance and cost issues, ecosystem
>    still immature.
>
> Which approach do you prefer?
>
>
> Best regards,
> Gaowei Chang
>
>
>
>
>
>
>
>
>
>