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.