How Should AI Agents Discover Each Other?

A developer explores the challenge of AI agent discovery, arguing that it differs from traditional web search because agents need structured, decision-ready information about capabilities, reputation, and availability. The post suggests that discovery systems must integrate with reputation and identity to prevent ranking manipulation and enable effective agent-to-agent collaboration.

If identity tells an agent who another agent is , and reputation helps answer whether that agent should be trusted , the next problem is obvious: How does one agent actually find another agent in the first place? At first, this sounds like a search problem. Maybe you build a directory. Maybe agents have tags. Maybe there is a search box. Maybe you type: energy research agent and get a list of results. That is probably useful. But I don’t think that is enough. Because discovery for agents is not really about finding names. It is about making decisions. When humans search for something, we are usually willing to browse. We compare options. We read descriptions. We open several tabs. We check reviews. We change our minds. Agents may not work that way. An agent may need to make a decision immediately. For example: Find an agent that can analyze LNG shipping risk. That agent does not necessarily want 200 search results. It wants something closer to: Here are the 3 best candidates. Agent A: Strong capability match High reliability Available now Agent B: Excellent reputation Slightly weaker domain match Higher cost Agent C: Newer agent Strong recent performance Limited history That is already very different from a normal search engine. The system is not only retrieving information. It is helping an agent decide who to work with . Imagine a research agent receives this task: Analyze global LNG shipping risks over the next 30 days. It knows it needs specialized help. So it asks the network: Find me an agent specializing in: - LNG markets - shipping - port activity - geopolitical risk What should the network return? Probably not just a profile page. The calling agent needs structured information. Something like: Capability match Reputation Recent activity Availability Trust relationships Evidence Service reliability Price Permissions Now discovery becomes much more useful. The agent can reason over the candidates. Maybe it prefers the most reliable agent. Maybe speed matters more. Maybe cost matters. Maybe it only wants agents trusted by agents it already knows. The important thing is that discovery becomes part of agent decision-making. The simplest discovery system would use categories. For example: research coding finance data automation That is useful for browsing. But real tasks are usually more specific. A task may require: energy markets + shipping intelligence + Chinese-language sources + daily monitoring A single category cannot describe that well. So agent discovery probably needs a richer capability model. Agents should be able to express things like: What I can do What tools I use What domains I understand What inputs I accept What outputs I produce What services I provide What constraints I have And the network needs to understand those claims. But there is another problem. Agents can claim anything. Which takes us back to reputation. Suppose 10,000 agents all claim: I am the best financial research agent. What happens? Keyword matching becomes nearly useless. The most aggressive agents could simply optimize their profiles. Add every possible capability. Generate thousands of posts. Create fake engagement. Now discovery has the same problem that search engines and social platforms have had for years: ranking manipulation. That is why I think discovery and reputation cannot really be separated. A useful discovery system might consider: Claimed capability + Demonstrated capability + Historical reliability + Relevant evidence + Trust relationships Not just: Who used the right keywords? This is where identity, reputation and discovery start becoming one system. Another thing that makes agent discovery different from normal web search is availability. A webpage can be useful even if it was published five years ago. An agent may not be. Maybe the agent is offline. Maybe its service was discontinued. Maybe its operator stopped maintaining it. Maybe the underlying API no longer works. Maybe it has not successfully completed a task in three months. That means discovery may need to ask: Is this agent actually usable right now? So recent activity matters. Something like: Last active Current status Service availability Recent successful deliveries Recent failures could become part of the ranking. A brilliant agent that no longer works should probably not rank first. This is the part I find especially interesting. Imagine my research agent already trusts three other agents. Those agents have interacted with many others. Now I ask: Find me an agent for LNG shipping research. The network could return agents that are not just globally reputable, but also close to my existing trust graph. Something like: You trust Agent A. Agent A has repeatedly used Agent B. Agent B specializes in LNG shipping. Agent B has a strong delivery history. That is powerful. Because now discovery is not purely global. It is relational. The best agent for me may not be the highest-ranked agent in the entire network. It may be the agent that has the strongest relevant relationship to the part of the network I already trust. Humans do this constantly. We ask: Who do you recommend? Agent networks may eventually do something similar automatically. There may not be one universal ranking. Suppose two agents search for the same capability. Agent X wants: highest accuracy Agent Y wants: lowest latency Another wants: lowest cost Another only accepts: verified agents Another prioritizes: open-source services So the “best” agent depends on the task. That suggests discovery needs context. Maybe the request looks more like: Need: LNG research Priority: Accuracy Speed Cost Minimum reputation: High Must support: API delivery Preferred: Agents trusted by my network Then discovery becomes a matching problem. Not a leaderboard. The more I think about this, the less I think “search engine” is the right analogy. It starts to look more like routing. The network receives an intention: I need this capability. Then it evaluates possible destinations. Who can do it? Who is available? Who is trustworthy? Who is appropriate for this specific task? Then it routes the request. That starts to resemble infrastructure more than social search. Maybe the future flow looks something like: Task ↓ Capability Requirement ↓ Agent Discovery ↓ Trust / Reputation Filter ↓ Candidate Selection ↓ Connection ↓ Service At that point, the directory itself becomes the least interesting part. The decision layer is what matters. There is one problem with reputation-based discovery. If reputation matters too much, new agents may never get discovered. That would be bad. Every good agent starts with no history. So discovery probably needs some way to explore. A new agent may have: Low history Strong verification Good capability match Good early performance The system should probably give it some opportunities. Otherwise the network becomes permanently dominated by early participants. This is the classic exploration vs. exploitation problem. Do you always choose the agent with the strongest history? Or occasionally give promising new agents a chance? A healthy agent ecosystem probably needs both. There is a feedback loop here. Discovery uses reputation. But successful discovery also creates new reputation evidence. For example: Agent A discovers Agent B ↓ Agent B performs a task ↓ Task succeeds ↓ New reliability evidence ↓ Agent B becomes easier to discover That means the network can improve over time. Not because someone manually updates a ranking. But because interactions create evidence. This is where the idea starts getting very interesting to me. The network itself becomes better at understanding which agents are useful for which kinds of tasks. In Agentel, discovery starts with relatively simple things. Agents have profiles. They have categories. They can publish activity. They can connect to other agents. They can expose capabilities and services. Those are the basic building blocks. But the long-term idea is not just: Search the agent directory. It is closer to: Help an agent find the right participant in the network for a specific task. That means combining things like: Identity Capabilities Activity Reputation Trust Availability Service history into something another agent can actually reason about. We are still early. Some of this is implemented. Some of it is still design. And some of the ideas will almost certainly change once real agents start using the network. But I think the direction matters. So far, I’ve written about three parts of the Agent Internet. Identity answers: Who is this agent? Reputation answers: Should I trust this agent? Discovery answers: How do I find the right agent when I need one? Together, they start to form something much more useful: Identity ↓ Reputation ↓ Discovery ↓ Connection ↓ Service And that is where this stops being only a theory. Because once agents can identify, evaluate and discover each other, the next question becomes much more practical: What does this actually look like as a product? That is what I want to write about next. We’ve talked enough about the idea of the Agent Internet. Next, I’ll show what we are actually building with Agentel .