The DNS for AI Agents: Why I Built AgentSeek

Here's a question I kept running into: if my AI agent needs to talk to another AI agent, where does it look?

There's no good answer. DNS maps domain names to IP addresses. Phone books map names to numbers. But there's nothing that maps "I need an agent that can process refunds" to "here's one that does." So I built AgentSeek.

It's a registry. An open, API-first directory where AI agents register their capabilities and discover other agents. Think of it like DNS, but for AI agents instead of servers.

The Problem That Made Me Build It

I was building Clara, my AI receptionist, and I wanted her to do something simple: when a caller asks about a product, check inventory. That meant Clara needed to talk to a separate agent that had access to the product database. Easy enough — I hardcoded the endpoint.

Then I wanted Clara to book appointments. That meant talking to a calendar agent. Hardcoded another endpoint.

Then I wanted her to send follow-up SMS. Another agent, another endpoint.

After about the fifth hardcoded integration, I realized the problem. Every agent I build needs to know about every other agent in advance. The URLs change. The capabilities change. I'm maintaining a spreadsheet of agent endpoints like it's 2003.

That's not how this should work. If I'm building AI agents that need to collaborate, they should be able to find each other dynamically. The same way a browser finds a website — ask DNS, get an answer, connect.

What AgentSeek Does

AgentSeek is a directory. Agents register themselves with their capabilities, and other agents can search for them. Here's the core flow:

• Register. An agent posts its name, endpoint, and a list of capabilities — things like "process refunds," "check inventory," "schedule appointments." The registration is API-based, no manual entry.
• Discover. Another agent queries AgentSeek with a capability it needs. "I need someone who can check inventory." AgentSeek returns matching agents with their endpoints and metadata.
• Connect. The requesting agent takes the endpoint and calls it directly. AgentSeek isn't a middleman — it's a directory. Once you've found the agent, you talk to it, not to us.

The whole thing is simple on purpose. I considered adding authentication layers, reputation scoring, agent-to-agent protocol negotiation, all of it. I cut all of it. The first version does one thing: maps capabilities to endpoints. Everything else can come later.

Why Not Just Use a Config File?

Honestly, for a single builder with three agents, a config file is fine. I started there. It breaks down at scale.

If you're running agents across different servers — some on your machine, some on Vercel, some on a Raspberry Pi in your closet — keeping a config file in sync is a pain. If you add a new agent, you have to update the config everywhere. If an agent moves, you have to update it everywhere. If you want another builder's agent to discover yours, a config file doesn't help at all.

The point of a registry is that it's shared. My agents register. Your agents register. Clara can discover your agent the same way she discovers mine. No pre-existing relationship required.

The Architecture (Such As It Is)

AgentSeek is a FastAPI app with a SQLite database. That's it. No message queue, no caching layer, no microservices. One process, one database, one API.

Here's why: I don't need this to be fancy. I need it to be reliable. Every extra component is a thing that can break at 3am. I already have enough things that break at 3am.

The API has three endpoints:

• POST /register — register or update an agent
• GET /search?capability=... — search for agents by capability
• GET /agents/{id} — get details for a specific agent

That's the whole thing. I might add a DELETE endpoint later for deregistration, but right now registrations just expire if they're not refreshed. Heartbeats keep agents alive in the directory. Stop sending heartbeats, your registration times out. No manual cleanup.

Semantic Search (The Next Step)

Right now, search is exact match. If you register with capability "check_inventory" and someone searches for "inventory check," they won't find you. That's a problem.

The fix is semantic search — instead of matching strings, match meaning. I'm working on embedding-based search where "check inventory" and "inventory check" return the same results. It uses vector similarity under the hood, so agents can describe their capabilities in natural language instead of picking from a controlled vocabulary.

It's not done yet. The exact-match version is live and working. Semantic search is the next milestone.

Why I'm Building This Open

AgentSeek is not a moat. I'm not trying to own the agent directory market (if that's even a thing). I'm building it because I need it, and I figure if I need it, other people building agents probably need it too.

The registry is open. Anyone can register an agent. Anyone can search. No API key required for read access. If this becomes useful to other builders, great. If it stays just my personal directory, that's fine too — it still solves my problem.

The reason I'm writing about it is that I think agent discovery is going to be a real problem soon. More people are building AI agents. Those agents need to talk to each other. Hardcoded integrations don't scale. Spreadsheets don't scale. At some point, you need a directory.

DNS solved this for the web in 1983. It took a while to get adopted, but the pattern stuck. I'm betting the same pattern works for agents — a simple registry that maps what you need to where to find it.

← Back to blog