Agent registry: discovery without trust is just a list
What an AI agent registry must expose before developers can reuse agents safely.
The registry problem is trust
Agents carry instructions, tools, external access, schedules, and sometimes public-facing channels. A card with a name and a nice description is not enough to install anything safely.
A useful registry shows files, tools, schedules, credentials, write access, dependencies, author, update date, and install command.
This is different from a normal plugin directory. Agents can reason, call tools, and act across systems. A registry listing has to show those capabilities before installation, or it is just asking developers to trust a black box.
Registry, catalog, marketplace
A catalog helps people browse inventory. A marketplace helps people choose between vendors. A registry should provide structured metadata and installation paths.
For developer agents, the registry model is often the right starting point because the user needs to inspect and own the artifact.
This distinction matters for product expectations. A marketplace implies reviews, pricing, support, and vendor comparison. A registry implies installable artifacts, metadata, and repeatable delivery. Agent infrastructure usually needs the second before it can credibly become the first.
What a registry item needs
A real registry item has a clear job, source files, target paths, dependencies, setup instructions, author identity, and update metadata. Install counts are useful, but they are secondary to inspectability.
The best registry items also explain the first-run path. What credentials does the agent need? Which files should the user review first? Which tools can write to external systems? What should a safe dry run look like?
Files and target paths
Dependencies and environment variables
Author and source review path
Install command and previewable output
Why source ownership matters
Agent behavior often needs local policy. A company may want a stricter review rubric, a different Slack channel, a narrower SQL policy, or a custom approval step. Source-owned installation makes those changes normal instead of forcing a fork of an opaque tool.
Installable source files let teams review the agent, change the policy, and commit the result before they run it. Reusable agents should not trap teams inside someone else’s hidden prompt or tool wrapper.
Decision table
Public registry
Use when
Reusable artifacts should be discoverable and installable across projects.
Avoid when
The agents depend on private infrastructure or internal policy.
Internal registry
Use when
A company needs approved agents, private tools, and governance.
Avoid when
The goal is open contribution and public discovery.
Marketplace
Use when
Commerce, licensing, reviews, and support are part of the product.
Avoid when
The core value is source-owned installation.
FAQ
What makes an agent registry trustworthy?
Transparent files, clear ownership, dependency disclosure, review history, and install previews.
Should a registry store runtime state?
It can store metrics and favorites, but canonical source metadata should stay close to the files being installed.
Is evex an agent marketplace?
Not in the commerce sense. It is a community registry for reusable Eve agent configurations.