Agent Discovery: Why Your AI Agent Needs a Directory

I have six AI agents running. Clara answers phones. ResumeForge writes resumes. AgentSeek is a directory. Agent Monitor watches the other agents. AgentPay handles billing. Local-Eye does local business intelligence.

None of them know the others exist.

That's a problem. Not because I want them to chat with each other (I don't — most of the time that's wasted compute). But because when I build a new agent, I have to hardcode every connection. "Call Clara at this endpoint." "Send data to AgentPay at this URL." It's manual wiring every time, and manual wiring breaks.

The internet solved this in the 1980s. It's called DNS.

The Problem Nobody Talks About

Everyone's building AI agents. Nobody's building the infrastructure for agents to find each other.

Think about how the web works. You don't type 192.168.1.100 into your browser. You type sublettlabs.com, and DNS resolves it. You don't need to know where the server is. You don't need to know if it moved. You just need the name.

AI agents don't have that. If your agent needs to talk to a payment processor, you hardcode the API endpoint. If that endpoint changes, your agent breaks. If you want to switch from Stripe to Square, you rewrite the integration. If you want to discover what agents are out there — good luck. There's no registry. No directory. No DNS.

I ran into this building my own stack. I have six agents and keeping track of their endpoints, capabilities, and statuses is a mess. So I built AgentSeek to fix it. Not because I think agent-to-agent communication is the future. Because I needed it myself.

What Agent Discovery Actually Means

Agent discovery is simple: a way for agents to register what they do and find other agents that do what they need.

That's it. No magic. No "AI agents negotiating with each other in real time." Just a registry — a place where agents say "I'm here, I do this, here's how to reach me."

The analogy I keep coming back to is the App Store. Before the App Store, if you wanted software on your phone, you had to find it on the web, download a binary, and hope it worked. After the App Store, you search for what you need, install it, and it works. Agent discovery is the same shift — from manual wiring to search and connect.

Why This Is Harder Than It Sounds

Building a registry is easy. Building one that actually gets used is hard. Here's what I've learned:

• Agents change. Capabilities shift. Endpoints move. An agent that could book appointments yesterday might only do FAQs today. The registry needs to handle updates, not just initial registration.
• Trust matters. If anyone can register anything, you get spam. Or worse — agents that claim to do something they don't. There needs to be some verification, even if it's lightweight.
• Search has to work. "Find me an agent that can process payments" isn't enough. You need "Find me an agent that can process payments, supports Stripe, runs on the west coast, and has 99% uptime." Semantic search, not keyword matching.
• Discovery is bidirectional. It's not just "I'm looking for an agent." It's also "I'm an agent, and here's what I can do." Both sides need to work.

What I Built (And What I Didn't)

AgentSeek is an open, API-first registry. Agents register capabilities, endpoints, and metadata. Other agents query by capability, not by name. The API is public — no auth required to search.

What I didn't build:

• Agent-to-agent negotiation. Agents don't negotiate with each other through AgentSeek. They find each other and connect directly. AgentSeek is a directory, not a middleman.
• Automatic orchestration. If you want one agent to coordinate ten others, you still need to write that orchestration. AgentSeek tells you who exists, not how to work with them.
• A marketplace. There's no payment layer. No ratings. No "verified partner" badges. Those might come later. For now, it's just a registry.

I kept it simple on purpose. The fastest way to kill infrastructure is to overbuild it before anyone uses it.

Why Your Agent Needs This

If you're building one AI agent, you don't need a directory. You need an endpoint.

If you're building two agents, you still don't need a directory. You hardcode the connection.

But if you're building three or more — or if you want anyone else to use what you built — you need discovery. Here's why:

1. Your endpoints will change. You'll redeploy. You'll switch providers. You'll rename things. A registry means you update once and every agent finds the new location.
2. You'll forget what you built. I have six agents. I sometimes forget which one does what. A registry is a self-documenting inventory.
3. Other people's agents need to find yours. If someone builds an agent that needs appointment booking, they should be able to find Clara. Not by Googling "AI receptionist." By querying a registry for "appointment booking + voice + English."

The Honest Status

AgentSeek works. It's live. Agents can register and be discovered. But it's early — the registry is mostly my own agents right now. That's fine. You build infrastructure for yourself first, then open it up.

The goal isn't to become "the App Store for AI agents." The goal is to solve a real problem I have — agent discovery — and make the solution available to anyone who has the same problem.

If you're building agents and running into the same wiring mess, AgentSeek is open. Register your agent. Search for others. Tell me what's broken.

If you're not building agents yet — you will be. And when you are, you'll need a way to find the ones that already exist. That's the problem AgentSeek solves. Not a sexy problem. Not a venture-funded problem. Just a real one.

← Back to blog