Introducing ai-registry: An Open Standard for AI Registries

Context needs to be portable and accessible

Enterprise AI is multi-everything: multi-user, multi-agent and multi-harness.

In this world, artifacts like skills and agent definitions can easily diverge across people, harnesses, and agents. This makes it difficult to know which version of your company’s know-how each person or agent is actually using in their workflows.

For multiple users and agents to seamlessly collaborate, context has to be portable and accessible across today’s harnesses, tools, and models, as well as the ones still to come. While open formats for AI artifacts like skills and semantic models already exist, there’s no standard that makes the registries holding those artifacts open and interoperable across clients and storage systems.

That’s why today, we’re excited to open-source ai-registry, an open standard for AI registries.

Simply put, ai-registry allows anyone to build an open registry to store artifacts on any infrastructure they already own, such as a git repo, and allows clients to easily sync artifacts across any harness or personal agent.

The open context ecosystem is forming

Open context formats already exist and are being widely adopted by AI tools and practitioners. Agent Skills, Agent Plugins, AGENTS.md, Open Knowledge Format and Apache Ossie each define an open format for a specific type of context. Each works across various tools – for example, Claude Code and Codex can both read the same SKILL.md file. However, one layer is still missing: nothing ensures that every user and agent across your company always uses the latest governed version of these artifacts.

Lessons from the world of data

We’ve seen this journey before, in data analytics.

Previously, you could run ETL jobs with Spark on data in object storage, but you had to copy that data into a warehouse to run analytics and reporting workloads. Each warehouse had its own proprietary storage and format, so other engines couldn’t access it.

Table formats like Apache Iceberg made it possible for multiple engines to read from and write to the same copy of data in object storage. This is what we call the open lakehouse architecture.

Iceberg did this by first defining a table spec that describes a table’s layout in storage, as well as metadata like snapshots and versioning. It later added a REST catalog spec that not only tells engines like Spark, DuckDB and Snowflake which tables exist, but also lets them read and write to those tables safely.

What the missing layer needs

Today, context formats are open, but there’s no standard way for a client to answer:

• Which version of an artifact is current?
• Who owns it?
• Has it been deprecated or pulled?
• How does every harness and agent get the current version?

An AI registry – a single place that stores a team’s or company’s artifacts and tracks their versions, owners and status – answers these questions.

Many registries already exist, but every harness and agent platform implements its own, such as a plugin marketplace or a vendor-specific agent registry. Each one keeps versions, ownership and status in its own format, on its own storage, so clients need a connector for every registry, and an artifact’s metadata isn’t portable across registries.

In a multi-everything world, artifacts have to be both distributable and interoperable. That’s why registries need a standard that solves for both, and we can borrow lessons from the projects that solved each one:

Distribution. Artifacts need to reach every teammate and every agent, in every tool they use. npm solved this for code. You publish once, everyone installs the exact version, and a bad release gets deprecated for everyone.

Interoperability. Artifacts need to work across harnesses, models and agent frameworks. Clients also need one way to read any registry. Iceberg solved this for data: one open format on storage you own, which any engine can read and write.

ai-registry is that missing layer.

Hello, ai-registry!

ai-registry is an open standard for AI registries. It does two things:

• Lets anyone build an open registry on infrastructure they already own, such as a git repo or an S3 bucket.

• Defines a standard layout for a registry’s files, plus essential metadata like versions, digests and status. Clients build only one integration, and can work with every registry that follows the spec.

How it works

The ai-registry file spec defines a standard layout for a registry’s files, and adds metadata on top of raw artifact files, like SKILL.md, which stay unchanged. In Iceberg terms, skills are the data files, like Parquet, and ai-registry’s file spec is the table format.

A folder of files that follows the spec is a valid registry. Here’s a complete registry with one skill in it:

team-skills/
├── registry.json                 # discovery: the registry's name, namespaces and kinds
├── index.json                    # every artifact, with its latest version and status
└── artifacts/engineering/skill/pr-review/
    ├── versions.json             # every version, its digest and status
    ├── 0.1.0/
    │   ├── artifact.json         # metadata and a digest per file
    │   └── SKILL.md              # the author's file, unchanged
    └── 0.2.0/
        ├── artifact.json
        └── SKILL.md

Each version is immutable, and versions.json records its digest and status. This enables clients to resolve the pr-review@0.2.0 skill to its exact bytes, check them against the digest, and install that version into the folders every harness reads. Claude Code, Codex, Cursor, Copilot and your own agents then all run the same version.

What the project includes today

The project ships three things:

• The ai-registry file spec, which defines how files are organised in a registry, as well as metadata like versioning and ownership. Today, registries support skills and agents as kinds (artifact types). More kinds are planned, including MCP servers and semantic models in the Apache Ossie format.

• aireg, a CLI that creates registries, publishes and validates versions, and installs them. Today, it supports Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI and OpenCode on macOS, Linux, and Windows.

• Example registries and checks, which give you complete registries to start from, and a way to validate that a registry follows the spec.

Why a spec, and not another registry?

When building our own managed registry offering at Atlan, we learned that a registry product is just one more server with its own format. Each harness needs an integration built for it, and the registries you already have must migrate in or stay separate.

A spec standardises the format instead of the server. That gives you two things no single registry can:

• A client written once reads every registry. A harness vendor integrates with the spec, not with each registry.
• The files outlive the software. A registry is still a registry without the tool that wrote it, so you can switch clients, or run several, against the same repo.

Why not just a git repository?

This is usually the first question we get. A registry that follows the ai-registry spec can live in a git repository. The difference is the metadata and the client on top. A plain repo gives everyone whatever copy is there when they pull, so teammates end up on different copies and nobody can tell which.

With ai-registry, every version is recorded with a digest, pinned in a lockfile, and verified on install. Clients make sure every machine gets the same verified version of each artifact and that every harness stays in sync from one record. The registry can deprecate, yank, or archive a version in one place, and clients can then warn about deprecated versions and stop installing yanked or archived ones.

ai-registry in practice: turn your skills repo into a registry

Many teams already keep their skills in a git repo. That gives them one source of truth for artifacts, but rolling out any change across the org is manual. When Alice improves the team’s pr-review skill, she merges the change and asks everyone in Slack to pull and copy it into each harness. Some people do, and nobody can tell who’s on which version.

Instead, Alice can turn her skills repo into a full AI registry. The repo stays the source of truth, and the registry manages the lifecycle and distribution of each artifact across the organisation.

Every step is just a prompt to a coding agent.

Let’s build an open ecosystem for context, together

We already know open ecosystems are good for customers. Apache Iceberg built one for data, where customers can use the best engine for each workload, on data that lives in storage they own. Context for AI is at the same point. The companies building AI already back open formats like Agent Skills, OKF, and Ossie, and ai-registry builds open registries on top of them.

If you build harnesses or clients, we’d love for your tools to add support for registries that follow the spec, so your users can bring the registries they already have and be productive from day one. If you run an agent marketplace, serving your catalog using the ai-registry spec can ensure that every tool that reads the spec is able to install from you.

If you’re building a registry or are rolling out AI inside your company, we’d love to get your feedback and contributions. Paste this into your favourite coding agent to get started, and open an issue or a pull request on the repo:

Set me up with ai-registry: https://github.com/atlanai/ai-registry

We believe context should be portable and interoperable, and ai-registry is an essential step toward that. We’re excited to build this open ecosystem together.

ai-registry is the first of several open-source projects you’ll hear about from us. We also contribute to projects like DuckDB, Apache Ossie, and OpenLineage, and we’ll be sharing more about that work soon.