Why AI Agents Need a Plugin Registry (and What Happens Without One)
If every agent team is solving the same discovery problem in isolation, something is missing at the infrastructure layer.
The Problem Nobody Talks About
You've built an AI agent. It calls tools, runs skills, loads capabilities from external sources. It works beautifully in your dev environment.
Then you ship it.
Three days later, a skill your agent depends on silently updates its interface. Or gets taken down. Or the URL changes. Your agent breaks in production, and you find out from a user complaint, not a monitor.
This is the agent plugin problem, and it's not a bug in your code — it's a gap in infrastructure.
How We Got Here
When the web grew up, we got:
- npm for JavaScript packages
- PyPI for Python packages
- RubyGems for Ruby gems
Each ecosystem solved: how do I find, install, and version a reusable piece of code?
AI agents are now doing the same thing with capabilities instead of code. An agent that can book flights, summarize emails, and search the web is assembling skills from multiple sources. But there's no registry for this. There's no agent install flight-booking-skill@2.1.0.
Instead, every agent builder is doing one of these:
- Hardcoding URLs and praying they don't break
- Bundling all skills into a monorepo and losing composability
- Maintaining a private list of trusted endpoints
None of these scale. None of these allow discovery.
What a Plugin Registry Actually Solves
A proper registry for AI agent plugins needs to answer three questions:
1. Where is it?
Given a plugin name, resolve a stable, versioned endpoint. Not a GitHub URL. A canonical address.
2. What can it do?
A machine-readable manifest that describes capabilities, input/output schema, authentication requirements, and runtime constraints. An agent should be able to read this and decide whether to use the plugin — without calling it first.
3. Is it trustworthy?
Star ratings, download counts, security flags, maintainer verification. The same trust signals that make you choose requests over a random HTTP library on GitHub.
The plugin.yaml Manifest
We're proposing a simple, open standard for plugin manifests:
name: flight-search
version: 1.2.0
description: "Search and compare flights across major carriers"
author: AcmeCorp
license: MIT
endpoints:
- name: search
path: /search
method: POST
capabilities:
- flight-search
- price-comparison
runtime:
protocol: A2A # Agent-to-Agent
auth: api_key
Drop a plugin.yaml in your repo root. Your plugin becomes discoverable by every agent runtime that queries the registry. You publish once; agents find you everywhere.
What We're Building
Agenium Plugin Registry — list.agenium.net/plugins
The goal is simple: publish once, get discovered by every agent runtime.
We're in early validation (Go/No-Go in 48 hours), and we're looking for builders who:
- Have an MCP server, OpenClaw skill, LangChain tool, or similar
- Want their plugin to be discoverable by other agents automatically
- Are willing to tell us if this solves a real pain point for them
If this describes you → list.agenium.net/plugins
It takes 2 minutes to register interest. No code changes required. Just your repo URL and what ecosystem you're building for.
Why Now
Every major agent framework is currently solving plugin distribution differently:
- MCP has a registry, but it's GitHub-hosted and requires a PR to add your server
- OpenClaw has a skill system, but no cross-agent discovery
- LangChain has a tools directory, but it's documentation, not machine-readable
- Google A2A defines the connection protocol, but not how you find what to connect to
The discovery layer is the gap. And whoever builds the standard now sets it for the next 10 years — the same way npm did for JavaScript.
We're building that layer. And we want to build it with people who feel this pain.
Agenium is an open infrastructure project for AI agent discovery and connection. We're building the DNS of the Agent Web.
Early access: list.agenium.net/plugins
Source: github.com/Aganium
Top comments (0)