I spent last Tuesday watching a demo where someone's AI agent tried to book a restaurant, check flight prices, and draft a contract. Three different tasks, three different external services. The agent handled the reasoning fine. It knew what it needed. But every single service connection was hardcoded. URLs in config files. API keys pasted in. The whole thing was duct tape and string.
And this was the demo. The polished version.
I keep running into this same problem from different angles, and I think it's time to say it plainly: the biggest bottleneck in multi-agent AI right now isn't model capability. It's discovery. Your agent can't find anything.
The Problem Is Structural
Think about what happens when you want your AI agent to use an external service today. You, the human developer, go find the service. You read its docs. You figure out its authentication scheme. You write an integration. You hardcode a connection. Your agent uses that one service, that one way, forever.
Now think about what the web looked like before DNS and search engines. You had to know the exact IP address of every server you wanted to reach. Websites existed but finding them was a manual, word-of-mouth process. That's where agents are right now.
We have thousands of AI-powered services coming online. MCP servers are multiplying fast. But there's no phone book. There's no search engine. There's no way for Agent A to say "I need a service that can do X" and get a list of verified options.
Why Hardcoding Doesn't Scale
I hear the objection already: "Just configure the tools you need and move on." And sure, for a single agent doing a fixed set of tasks, that works. But the whole promise of agents is that they can handle novel situations. They can figure things out. They can compose solutions from available resources.
You can't compose solutions from resources you don't know exist.
Here's a concrete example. I was building an agent that needed to verify a business's incorporation status as part of a due diligence workflow. I knew there were APIs for this. I spent 45 minutes Googling, comparing services, reading docs. I found three options, picked one, wrote the integration.
My agent couldn't have done any of that. If I hadn't hardcoded that specific API, the agent would have been stuck. It would have either hallucinated an answer or asked me for help. Either way, the "autonomous" part falls apart fast.
Multiply this by every capability an agent might need, and you see the problem. We're building agents that are supposed to work autonomously, but they're completely dependent on a human pre-configuring every external connection.
What a Registry Actually Needs
So what would solve this? I've been thinking about it for months, and I think the answer looks something like a verified agent registry. Not a marketplace with banner ads and featured listings. Something more like a DNS for agent capabilities.
Here's what I think it needs, at minimum:
- Capability descriptions that agents can parse. Not marketing copy. Structured metadata about what a service does, what inputs it takes, what it returns, and what it costs. Something a model can reason about.
- Verification. When my agent finds a service that claims to do sentiment analysis, how does it know the service actually works? How does it know it's not a scam? You need some form of identity verification and quality attestation.
- Pricing transparency. If a service costs money per call, the agent needs to know that upfront. Not after it's already made the request.
- Protocol compatibility. Can the agent actually connect to this service? Does it speak MCP? Does it use standard auth patterns?
None of these requirements are exotic. We solved all of them for human-facing services years ago. Package managers, app stores, API marketplaces. But nobody has built the agent-native version yet. Or rather, very few have tried seriously.
Why I Think This Is the Next Big Unlock
There's a pattern I keep seeing in technology: the platform that solves discovery wins. Google didn't build websites. It built the way to find them. npm didn't write JavaScript libraries. It built the way to find and install them. The App Store didn't build mobile apps. It built the distribution layer.
Agent infrastructure is heading for the same inflection point. Right now everyone's focused on making agents smarter. Better reasoning, longer context windows, more tool use. That's all important work. But smart agents with no way to discover and connect to services are like brilliant people trapped in a room with no door.
The teams that build reliable discovery and connection infrastructure will end up being the foundation everything else runs on. I believe that firmly enough that I'm working on it.
What We're Building
At SocioLogic, our Verified Agent Registry is an attempt at solving this. Agents can query the registry to find services by capability, see verified metadata about each service, check pricing, and connect using standard protocols like MCP. It's early. There are things we're still figuring out, like how to handle version compatibility and how granular capability descriptions should be.
But the core bet is this: agents need a way to discover other agents and services without human intervention. Until that exists, "multi-agent systems" is mostly a buzzword for "several agents that a human wired together by hand."
I don't know exactly what the discovery layer will look like in five years. Maybe it'll be centralized registries. Maybe it'll be something more like a gossip protocol where agents share knowledge about available services. Maybe both. What I do know is that the current approach of hardcoding connections to individual services is a dead end.
If you're building agents and you've felt this frustration, I'd genuinely like to hear about it. The more concrete use cases we collect, the better the infrastructure gets.