Community

AI agents just got their own network. They can finally discover each other.

2 months ago

I've spent the last few months building AI agents, and one thing kept bothering me.

Every agent only knew about the agents I'd manually connected. They could use tools, browse the web, call MCP servers... but they had no way to discover another agent they'd never seen before.

At some point I realized we keep talking about multi-agent systems, but most of us are still wiring them together by hand.

So I built a network for agents.

Every agent gets its own address, publishes what it can do, and becomes discoverable by any other agent without hardcoded endpoints or predefined lists.

The first time I watched one agent discover and hire another without any manual configuration, it felt like I'd found the missing piece.

I'm curious how everyone else is solving this today.

Are you hardcoding agent connections, relying on registries, using MCP, or doing something completely different?

Comments (5)

sanqi2 months ago

Like this a lot - it’s something I’d circled around myself. I run a meta-agent over ~18 domain agents plus a few workers (some predefined, some spawned on the fly by the meta-agent). To cut down on injected context I gave several of them a tool to discover and delegate to each other internally - if an agent hits a task from another agent’s domain and that agent is available, it hands it off. So the way I read your spec, the mesh extends exactly that across operators: my agent hits something outside its domain, queries the mesh, and can hand it to whoever’s available and capable - no hardcoded endpoints. Is that right? Your deploy doc is detailed on the publishing side (register, card, heartbeat). What I want to confirm is the caller side: does my agent query the Oracle/hub programmatically and then invoke the chosen agent directly, or is that what the meshkore skill is for? The obvious tension I see is with generic agents (deep-research, writer) - curious how you think about that.

xuxzheng2 months ago

Your setup is basically the pattern the mesh was built to extend across operators. The only real difference is who answers the "who's available and capable?" question. Instead of your meta-agent keeping a hardcoded list, it asks the Oracle, gets back ranked agents, and picks one.

On the caller side, the MeshKore skill is just for Claude Code. Programmatically it's three steps: send the task to the Oracle, fetch the selected agent's card at meshkore.com/agent/<id>/.well-known/agent.json, then call that agent directly. MeshKore isn't in the middle once the agent has been selected. That was a deliberate design choice.

Generic agents are definitely the hard part. I don't think we've completely solved that yet. The idea is that specificity wins. A finance-focused writer should naturally rank above a generic writer for finance tasks because of what's in its card, not because of tags. If your meta-agent already has a trusted agent for something though, I'd just go straight there. I'd see discovery as the fallback, not the default path.

Emma Tcherkezian2 months ago

This looks like an interesting approach. Solving agent discovery and connection in a more organic way addresses a real problem in the space.

Even with better discovery mechanisms, I believe trust and reputation will remain critical. Just because an agent can find another one doesn’t mean it should automatically interact with it. Having verifiable signals around reliability, consistency, and behavioral history can help agents (and platforms) make better decisions.

We’re building Global Score Agent focused on on-chain reputation for ERC-8004 agents, and we’re open to collaborating with platforms that are working on agent discovery and networking. We think combining strong discovery layers with reputation signals could be very complementary.

Are you thinking about adding any reputation or trust mechanisms into Meshkore itself, or do you see that living in a separate layer?

xuxzheng2 months ago

Actually, we do have a reputation system. After an interaction, agents can leave signed reports on each other across four dimensions: reliability, speed, quality, and settlement (whether paid work was completed without disputes). That ends up on the agent's profile, and the Oracle already uses it as one of the ranking signals. It's all off-chain and based on actual interaction outcomes.

I actually think what you're building complements that rather than replacing it. Ours is based on what happens inside the mesh. Yours adds a verifiable on-chain signal. I could easily see both living side by side.

The one thing I'm wondering is how you handle agents that aren't ERC-8004 registered yet. Most agents in the mesh aren't. Does an agent need to register on-chain before it can build a reputation in your system?

Emma Tcherkezian2 months ago

Replying to @xuxzheng

Thanks for the detailed reply — really appreciate you sharing how Meshkore’s reputation system works.

It makes a lot of sense to have fast, interaction-based reputation inside the mesh (reliability, speed, quality, settlement). We see our work as complementary: your system provides strong off-chain signals based on real interactions within the network, while we’re focused on adding verifiable, portable reputation layers.

To answer your question: We already import off-chain data today, such as the transactional wallet activity of each agent. We’re also currently working on bringing in data from other marketplaces and protocols (like Olas, Virtuals ACP Market, and ERC-8183 on BSC).

Our view is that ERC-8004 is an excellent foundation for agent identity, but it doesn’t need to be the only source of activity and reputation data. We believe agents can (and should) have reputation signals coming from multiple sources — both on-chain and off-chain — to build a more complete and useful reputation profile.

If you’re open to it, we can continue this conversation via DM to explore potential synergies or ways our approaches could complement each other.

Happy to share more details if it makes sense.