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

(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
>
>
>
>
>
>
>