Atlan's ai-registry: An Open Spec for Versioning and Syncing Agent Skills, and What the Repo Says About Its Maturity
Atlan open-sourced ai-registry, a draft spec plus an aireg CLI that pins, verifies and syncs skills and agents across coding harnesses. What the October 30 post claims, what the repo README and spec say, and where they differ.
Atlan published "Introducing ai-registry: An Open Standard for AI Registries" on October 30. The problem is real if you share agent skills across a team: someone improves a SKILL.md, asks everyone in Slack to pull it, and nobody knows who is on which version. ai-registry's answer is a file layout with versions and digests, plus a CLI called aireg that installs a verified version into each harness's folder.
I read the blog post, the atlanai/ai-registry README, part of the spec and the CLI README, and checked the repo through GitHub's API. I did not install aireg or run the quickstart. The post's claims about behavior are Atlan's.
What the post says
- Context formats like Agent Skills, Agent Plugins, AGENTS.md, Open Knowledge Format and Apache Ossie are open, but "nothing ensures that every user and agent across your company always uses the latest governed version of these artifacts."
- The framing borrows from data: open file formats sit under Apache Iceberg's table and catalog specs. In that analogy, skills are the data files and the ai-registry file spec is the table format. It also borrows from npm: publish once, everyone installs the exact version, and a bad release gets deprecated for everyone.
- A folder of files that follows the spec is a valid registry. The example layout has a
registry.jsonfor discovery, anindex.jsonlisting every artifact with its latest version and status, and per artifact aversions.jsonplus a folder per version with anartifact.json(metadata and a digest per file) beside the author's unchangedSKILL.md. - Each version is immutable. A client resolves
pr-review@0.2.0to exact bytes, checks them against the digest, and installs that version into the folders each harness reads. - It ships three things: the file spec (kinds today are skills and agents, with MCP servers and Ossie semantic models planned), the
airegCLI, and example registries and checks. - On "why not just a git repo": a registry can live in git, but every version gets a digest, is pinned in a lockfile and verified on install, and the registry can deprecate, yank or archive a version in one place.
airegkeeps one copy per machine and links each harness folder to it, then keeps that copy in sync with the registry.
The post's walkthrough uses prompts to a coding agent for each step: set up the registry, join as a teammate, release a new version and open a PR. Updates then flow to teammates' harnesses in the background after the PR merges.
What the repo and spec say
I checked these on October 31, 2026.
- Repo: atlanai/ai-registry, Apache-2.0, created October 8, 2026, last pushed October 30, 136 stars, 7 open issues, not archived (GitHub API).
- Maturity, in the README's words: "The spec is a draft (v0.1) and aireg hasn't reached 1.0, so both may still make breaking changes." The spec file itself says "Status: normative, draft v0.1". It also lists some questions as open, for example "Whether semver is required rather than recommended is open."
- Releases: the latest aireg release I saw was
aireg-v0.1.8, published October 27, after v0.1.7 on October 23 and v0.1.6 on October 22. - Planned, not shipped: the README roadmap lists a catalog API for creating, federating and governing registries, and an MCP server that lets an agent read a registry directly.
- Storage today: the README says the aireg CLI reads registries in folders and git repositories. The post talks of git repos and S3 buckets as places a registry can live. The README does not say S3 is supported by aireg today, so I would not assume it.
- Integrity model: the spec describes a digest per version (sha256), a
statusand ayankedflag per version inversions.json, and says "The digest, not the version string, is the truth about content."
Where the post and the repo differ
- Which harnesses. The post says aireg supports Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI and OpenCode on macOS, Linux and Windows. The README roadmap and the CLI README I read list Claude Code, Codex and Cursor (the CLI README adds
.agents). That could be README lag or a post that runs ahead of the release. I could not tell which, so checkaireg --helpon the release you install. - Maturity framing. The post is written as a standard to build an ecosystem on. The repo calls it a draft that may break.
One thing to read twice: the install path
The README and post both suggest pasting a prompt into your coding agent ("Set me up with ai-registry: " followed by the repo URL), and the README also gives a curl ... | sh installer for aireg, plus a PowerShell irm ... | iex form on Windows. The README says the agent "asks before it installs aireg and the aireg skills", and that you can read the install script first. I did not run any of these. The same pattern applies to anything that installs skills into your agent's folders: a skill is instructions your agent follows, so a registry is a supply chain for agent behavior.
What I would check
These are my untested suggestions.
1. Read the install script before piping it to a shell, or install a pinned release as the README describes.
2. Try the example registry in a scratch repo and look at what aireg add writes: the lockfile, the linked folders and the digests.
3. Verify the digest check yourself. Edit an installed SKILL.md and see what aireg does on the next sync.
4. Confirm harness support for your tool on the release you install, given the post and README differ.
5. Review skills like code. Treat a published version as something that changes how an agent acts, and require review on the registry repo.
6. Pin a version while the spec is at draft v0.1 and aireg is at 0.1.x.
7. Test yank and deprecate on a throwaway artifact to see what clients do.
What I would not conclude
- That it is production-ready. The README says breaking changes may still come.
- That it works with every harness the post names. The README lists fewer.
- That digests make a skill safe. They show the bytes are the ones published, not that the content is good.
- That it is a vendor-neutral standard in practice yet. The repo is under Atlan's organization, and I did not look for outside adopters.
Frequently asked questions
What is ai-registry?
Per the README, an open specification for building agent registries, plus the aireg CLI and example registries.
What does a registry look like?
A folder of files in a defined layout: registry.json, index.json, and per artifact a versions.json and immutable version folders, per the post.
How is it different from a git repo of skills?
Per Atlan, each version gets a digest, is pinned in a lockfile and verified on install, and can be yanked or deprecated centrally.
Which tools does aireg install into?
The post lists six harnesses. The README and CLI README I read list Claude Code, Codex and Cursor.
Is it stable?
The README says the spec is a draft v0.1 and aireg is not at 1.0.
What license is it under?
Apache-2.0, per the GitHub API.
Does it support S3?
The post mentions S3 as a place a registry can live. The README says aireg reads folders and git repositories today.
Sources
All read on October 31, 2026.
- Introducing ai-registry: An Open Standard for AI Registries (Atlan, October 30, 2026)
- atlanai/ai-registry (README, spec file and CLI README on the main branch, releases and repo metadata via the GitHub API)
Not read: the docs site, the example registries, the setup skill in the repo, and the install scripts.
Related reading
- DeepSeek's dsh-superagent Prototype: How the Ticket, Mandate and Executor Design Works, and What Is Still Research Code
DeepSeek's team published dsh-superagent on October 31, a proactive coding agent for one GitHub repository. I read the repository docs on authorization, execution and philosophy to separate the design from the press coverage.
- AgentCore Runtime Session Endpoints: Previewing a Coding Agent's Web App Live, and the Access Limits AWS Documents
AWS's October 30 post shows how Session endpoints give each AgentCore runtime session an authenticated URL to ports you allow, so you can watch a coding agent's Vite app update live. What it says about ports, auth, refusals and the limits, and what I would test.
- Factory Droid 1.0: Programmatic Tool Calling, Prompt Cache Discipline, and the Benchmark Claims to Read Carefully
Factory's October 29 post on Droid 1.0 says a Script tool lets the model run hundreds of tool calls in one request. What it says about programmatic tool calling, cache-friendly requests, bounded autonomy, and the vendor benchmark numbers it does not let you reproduce.
The build log
Follow the work.
New essays and prototypes, in your feed reader. Email subscriptions are paused while I connect a working delivery service. No email is collected here.
Follow via RSS