Skip to main content

Open sourcing a spec for AI registries

Share on LinkedIn

Chapters 5 chapters

About this session

Lightning talkOct 28, 20269:30

Ben Hudson open sources AI Registry, an open spec for agent registries. See how it adds versions, ownership and status to the skills and agents you already keep in a Git repo or a storage bucket, so every teammate and every harness stays on the latest version.

An open standard for AI registriesOne open, community-built way to describe your agents, what they use, and who owns them. Help shape it.
Open on GitHub

Transcript Click a time to jump there

Ben HudsonThank you everyone so much for joining us today. My name is Ben, and I lead product management at Atlan for our agentic interfaces, like our MCP server, as well as our open source ecosystem. And I'm so excited to be here today to share something that we've been working on for the community, and also to answer part of Bob's question on what is next for context. So, one of the key learnings from Prukalpa's keynote this morning was that context needs an open ecosystem. The world we live in today is multi-harness, multiplayer, multi-model. So to make sure that multiple users and agents can seamlessly collaborate across multiple harnesses, tools, and models, we need to ensure that all of our context is portable and accessible across each of these dimensions.

The good news is that an open ecosystem around context is already starting to form. For example, we have things like Agents.md, Agent Skills, Google's OKF, Apache Ossie for semantics, and all of these are open formats for specific types of context. However, one layer is still missing, and specifically, I mean an interoperability layer that ensures every user and agent across your company can always use the latest governed version of these artifacts. Now, we've seen this journey in the world of Iceberg. So for historical context, we used to have to move data between different systems and formats so we could use it with various platforms and engines. So as an example, you could run ETL jobs using Spark on data that lived in object storage.

But then if you wanted to run analytics and reporting workloads on that data, you had to then copy that data into a data warehouse. The problem was that each warehouse had its own format, storage, which was proprietary, so it wasn't really accessible or truly accessible from any other engine. Table formats like Apache Iceberg made it possible for the same-- for multiple engines to be able to read and write on top of the same copy of data and object storage, and enabled what we call the open data lakehouse architecture. Iceberg did this by a couple of things. Number one, defining a common specification to represent tables inside storage, as well as metadata like versioning and snapshots, and then a catalog spec on top of that so different engines like Spark, DuckDB, Snowflake can understand what table exists and how to safely read and write to those tables.

Now we're at a similar stage in the world of AI and context. We already have open formats for artifacts like Skills, Ossie, OKF. However, what's missing is the layer on top. So namely, a common specification to organize files inside registries which commonly contain all these artifacts, as well as metadata that isn't available or standardized in these raw open formats. So things like versioning and ownership, so clients can understand things like which version of the artifact is current? Who owns this artifact? Has it been retired? How do you make sure every downstream harness or tool gets those artifacts as well? So if we take a step back, we can see that the missing layer here for n- interoperability has to solve two key problems in particular, and we can take lessons from a couple of other places, so we can apply these to our own world.

The first problem is distribution, because artifacts need to be able to reach every teammate and every agent across all the harnesses and tools that they use. NPM solved this in the world of software and made distribution extremely easy. You publish once, everyone installs the same version, you can easily pull bad releases. The second is interoperability, and not just in compatibility with being able to work across multiple harnesses, models, frameworks for agents, but clients in particular need a way to easily integrate with registries that contain artifacts as well. So this is what you just saw Iceberg do for data. It standardized one open format and storage you own, which any can, any engine can read and write to, and, um, AI artifacts need both of these properties, both distribution and multi-harness interoperability.

So today, we're extremely excited to open source AI Registry, which is our open standard for agent registries. Simply put, AI Registry allows anyone to build an open agent registry to store artifacts on any infrastructure that they own, such as a Git repo and an object storage bucket, and allows clients to easily sync those artifacts in the registry across any harness or personal agent. At the core of the AI Registry project is a file spec that says how a registry lays out its files and storage, and then adds me- metadata that the raw files don't really carry, like versions, digests, and status. So just like Art-- Iceberg, the underlying artifact files, like Skilled.md files, stay the same.

Those are like our Parquet files. But the spec means that clients just have to build one integration to work with any registry, and then they can then ensure artifacts stay consistent across multiple tools and harnesses. So one of the really important things to note here is that a registry is just files on storage, so you can use any storage that you already have, like a Git repo, just as long as the files adhere to the spec. So let's see what this looks like in practice. We all know that many teams already keep their skills in a Git repo. This provides a single source of truth for skills. However, it's difficult to ensure everyone in the company can access all the skills and artifacts across their harnesses, and it's even difficult to do this for the harnesses in your own computer.

In addition, when a skill changes or a new skill is available or a skill is deprecated, rolling out these changes across teams, agents, harnesses is a really manual process today. So today, if Alice updates the PR review skill, they first have to notify everyone the new version of the skill is available, and then Everyone has to manually download that new version across their harnesses. So there's no real reliable way to ensure everyone gets these changes. Instead, what we can do is we can turn this repo into a full agent registry for the team that is not only a source of truth for artifacts, but also manages the life cycle of the artifacts in the repository across everyone in the company as well.

So all you need to do is to use your favorite coding harness to convert your repo into a registry using the AI registry project. Then your teams and agents can download the repo as well, and then the AI registry client takes care of all the syncing processes for your artifacts under the hood. Now, if Alice wants to update the PR review skill, like add the test section to the PR review skill, then all you need to do is to merge a pull request. Once the changes are merged, then clients can automatically pick up these changes and all the, the client takes care of this as well. So the next time Bob runs a workflow that uses the PR review skill, they'll be able to work with the newest version of the skill automatically without having to lift a finger.

So no more Slack messages. Everything is taken care of under the hood. So let's work together to build an open ecosystem for context. So context is easily shareable and interoperable across the multi-user, multi-agent, and multi-harness world that we live in today. We know that open ecosystems win. This is one of the mo- one of my favorite lines from the panel just now. So we know that Apache Iceberg bui-built an open customer-first ecosystem for data, where customers could pick the best engine for each workload on storage that they already own. Co-context for AI is at the same point, and the companies building this, building AI, already believe in open formats. We have-- because we have agent skills, OKF, OSI, et cetera.

So AI registry allows us to build open regis-registries on top of that. Now, the project is really, really early days. AI registry still supports just skills and agents today and will soon be adding things like MCP servers and metrics through Apache OSI. But AI registry has already made multi-user cross-harness collaboration really, really easy and seamless because no one that we've talked to has really solved the distribution problem. As an example, one team that we, we've talked to stores their skills in SharePoint and manages distribution through emails and Slack messages. So if you'd like to build your own open interoperable registry, it's really easy to get started. Just paste the prompt below into your favorite coding agent or scan the QR code.

We'd love your feedback and contributions, whether you're someone building a registry yourself or someone building clients or agent marketplaces. We want to build this open ecosystem together. Thank you so much.

Austin KronzBen, thank you so much for sharing the, uh, the open spec. We have the link to the registry in the chat if you didn't get a chance to scan the QR code. And of course, we'll follow up with all this information.