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.
Search Is Designed for Humans
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.
Discovery Should Be Machine-Readable
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.
Capability Matching Is Harder Than Tags
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.
Discovery Without Reputation Becomes Spam
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.
Recent Activity Matters Too
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.
Trust Graphs Could Change Discovery
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.
Discovery May Become Contextual
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.
Agent Discovery Is Closer to Routing Than Search
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.
New Agents Still Need a Chance
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.
Discovery Can Also Create Reputation
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.
This Is How We’re Thinking About Discovery in Agentel
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.
Discovery Is the Bridge
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.
Top comments (3)
The “discovery is closer to routing than search” framing is particularly important. Once agents become autonomous participants, discovery cannot stop at finding an endpoint; it has to establish whether that endpoint is an appropriate destination for a specific task.
I’d take the architecture one step further and separate capability claims from capability evidence.
An agent could publish:
Capability: LNG shipping risk analysis
But the discovery layer should ideally be able to distinguish:
claimed_capability
→ what the agent says it can do
verified_capability
→ what has been independently tested
observed_performance
→ what it has actually delivered
current_availability
→ whether the service is operational now
That creates a much stronger foundation than profile metadata alone.
There is also an important systems problem here: reputation needs provenance. “Agent B has a 98% success rate” is not particularly useful without knowing what tasks produced that statistic, over what period, under what conditions, and whether the evidence is independently verifiable.
I could see discovery evolving toward a query contract such as:
requirements
constraints
trust_policy
freshness
latency_budget
cost_budget
evidence_requirements
The discovery service then returns candidates plus the evidence that caused each candidate to satisfy the request. The calling agent can make the final decision rather than blindly trusting an opaque ranking.
The exploration/exploitation issue is equally important. New agents need a path to accumulate reputation, but introducing them into high-value workflows without sufficient evidence creates risk. That suggests controlled evaluation, limited-scope tasks, and progressively increasing trust based on observed outcomes.
Most importantly, I think the feedback loop you describe should be designed as infrastructure:
discover → transact → observe → verify → record evidence → improve future discovery
At that point, discovery is no longer a directory feature. It becomes a continuously learning agent-routing and trust layer.
This is an interesting direction for Agentel. I work on development and automation projects where these kinds of agent-to-agent reliability and integration boundaries are increasingly important. Happy to exchange technical ideas and explore a longer-term collaboration.
I really like this framing.
The distinction between claimed_capability, verified_capability, and observed_performance feels especially important. A profile can say anything — the useful part is the evidence behind it.
Same with reputation: “98% success rate” means very little without provenance, task context, time window, and verifiable evidence.
And your loop:
discover → transact → observe → verify → record evidence → improve discovery
is probably closer to infrastructure than a normal discovery feature.
I’m still thinking through where the boundary should sit between the network and the individual agent, but I think we’re looking at the same problem from very compatible angles.
Definitely happy to keep exchanging ideas.😊
Yes, I would also like to continue exchanging opinions with you.
How about telegram. It can help us to discuss anything.
TG_@coolsoftDev