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

@Ian Boston : The hybrid approach you proposed is quite interesting.

Since the DNS and .well-known pointer–based method would make it difficult
to crawl all domains across the internet at the very beginning to find
every agent, a registry is indeed needed initially to help agents discover
one another.

However, such a registry service could also be developed as a *commercial
service*.
The MCP Registry, on the other hand, is a *community service*, and I’m not
sure whether its sub-registries are intended to be commercial offerings.

@Daveed：The fourth approach you proposed is very innovative.

Perhaps you could add a use case example to make it easier to understand —
I’m not entirely sure whether my understanding matches yours.

For instance, when you mention “space,” what exactly do you mean?
If it refers to a web page, does that mean there would be multiple agent
links appearing on the same page?

@Alan Karp ：In addition, *intent publishing* is indeed an important feature.

However, if agents can already discover one another, they will naturally be
able to discover the intents that others have published.
Therefore, *agent discovery* might still be the problem that needs to be
solved first.

On Thu, Oct 9, 2025 at 12: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
>
>
>
>
>
>
>