Why Amitte exists — the open registry the agent ecosystem is missing
Every team writing AI agents is rebuilding the same prompts, tools, and connectors from scratch. Amitte is the npm-shaped layer that lets that work compound.
The problem
Open the source code of any team building with LLMs in 2026. You will find the same five things, written from scratch, every time:
- A long system prompt that tells Claude (or GPT, or Gemini) how to do one specific job — write release notes, triage Sentry, draft a PR summary.
- A handful of tool definitions —
search_db,read_file,post_to_slack— wired into whichever SDK that team picked. - A README explaining how to connect the resulting agent to Claude Desktop, Cursor, or some custom orchestrator.
- A version number scrawled in the README that nobody updates.
- A copy-pasted "this prompt is MIT-licensed" line that may or may not be enforceable.
Multiply that by every team in the world building agents and you get a coordination disaster. The same "summarize a git log" prompt has been written five thousand times. The same "connect to a Postgres database" MCP server exists in fifty repos, none of which discover each other.
We have npm for libraries. We have Docker Hub for images. We have PyPI for Python. We have nothing for agent procedures.
Amitte is that nothing-shaped hole, filled.
What it is, concretely
Amitte is an open registry — like npm — but for the three primitives agents actually need:
- Skills — playbooks. A signed markdown file with steps, an LLM reads it and runs the steps.
- Agents — model-backed callables. You ship a system prompt + a tool contract; consumers invoke it like a function.
- MCP servers — tool surfaces. Anything an agent can call as a tool, surfaced over the Model Context Protocol.
Every published entity carries a manifest, a Sigstore signature, an SPDX license, dependencies, and an evaluation score. Consumers can filter for verified-only, agents can refuse to run unsigned content, and the whole thing is queryable from a CLI, an SDK, an HTTP API, or an MCP server that the consumer's agent connects to directly.
Why it has to be open
A closed registry would solve the technical problem and create a worse one — vendor lock-in for the most leveraged piece of the new software stack. The bet is straightforward:
- The protocol is open (manifest schema, MCP, Sigstore).
- The reference implementation (this site) is open source.
- Trust tiers are domain-bound, not platform-bound. A verified publisher's signature is verifiable without trusting our database.
- Anyone can run their own registry mirror. The CLI takes a
--registryflag; the SDK takes aregistryUrl. We are not the control plane — we are a control plane that happens to be the default.
If a better registry shows up tomorrow, the schema works there too. That is the whole point.
Why now
Three things shifted in late 2025 that made this inevitable:
- MCP went mainstream. Claude Desktop, Cursor, Windsurf, VS Code, and every major model now speaks MCP. Tool surfaces are no longer client-specific.
- Agent SDKs converged on the same shape. Anthropic's Agent SDK, OpenAI's Assistants, and a dozen open-source frameworks all agree on tools + system prompt + structured I/O. The agent abstraction is stable enough to package.
- Reproducibility started mattering. "It worked when I ran the prompt yesterday" is a real production incident now. Pinned versions and signed artifacts are no longer optional.
The registry is what these three threads tie together.
What's next
The current site does the basics — publish, search, sign, fetch. The roadmap is about reach: better discovery (semantic search across body content, not just tags), richer evaluation (live red-team scores), and ecosystem alignment (cross-registry mirroring, federated trust).
If you build agents, this is the layer that makes your work compound instead of evaporate. If you publish skills today, you're laying down the corpus the next ten years of agents will run on.
Welcome to the registry. Start at /search.