How to Build an AI Agent Registry — Part 1: Schema and Ownership
This week: Agent Registry - The infrastructure layer that turns an agent sprawl problem into a governance capability. What is it? how to build it?
The Problem
An organisation deploys 50 agents across 6 teams over the course of a year. Without any central register, wihtout any ownership mapping, wihtout any shared schema.
Then the audit request arrives.
They ask the following questions:
Which agents are live?
Who approved the one touching customer financial data?
What has it been told in its system prompt?
Nobody could answer.
This is not a technology failure. The agents worked fine but the governance infrastructure was never built.
A Note on the choice of technology
Before we process, I want to make a note on my technology choices here. The architecture in this issue is Databricks-on-AWS. That is not a neutral choice, but it reflects where I spend most of my time. I work with Tier 1 UK financial institutions, and the patterns I see repeatedly across those engagements have shaped this stack.
Databricks gives me Unity Catalog for governance, lineage, and access control across the full data and AI estate. AWS gives me IAM for identity and CloudTrail for audit trails. These tools are production-stable, work in hybrid deployments, and hold up under compliance scrutiny. Where open source alternatives exist and are worth knowing about, I have noted them inline.
Where open source alternatives exist and are worth knowing about, I have noted them inline. But the primary recommendation here is the stack I have seen hold up under real compliance scrutiny.
What an Agent Registry Actually Is
An Agent Registry is the control layer that makes an agent estate governable. It is not a dashboard. It is not a catalog you update manually. It is infrastructure, the layer that sits beneath your agents and answers the questions an audit demands: what exists, who owns it, what it can do, and how much autonomy it operates with.
It has four components. This issue covers the first two: Schema and Ownership. Part 2, out on Wednesday, covers Risk Class and Autonomy Level - the enforcement layer.
I am splitting this deliberately.
Schema and Ownership are about description and accountability - what an agent is and who controls it.
Risk Class and Autonomy Level are about enforcement - what an agent is allowed to do and what stops it.
These are different engineering problems. Collapsing them into one piece does neither justice.
Component 1: Schema — How an Agent Describes Itself
Schema is the agent’s self-declaration. Without it, agents are opaque. Orchestration breaks. Integration fails silently. You cannot route work to an agent you cannot describe.
A schema record needs to capture: capabilities and skills, the APIs and tools the agent can call, input and output formats, memory and context handling behaviour, access permissions, and communication protocols.
Unity Catalog (UC) is the agent registry in this stack. It governs agent tools as registered, versioned functions - each one a securable object with access control, lineage tracking, and metadata surfaced through Catalog Explorer or the REST API. It supports attribute-based access control on tags, which means you can attach metadata directly to agent capability records and build access policies around them. If you think about it, UC becomes the same governance layer that already covers your data assets, your ML models, and your pipelines, just extended to agents without adding a separate system.
Unity Catalog also works across Databricks workspaces on AWS, Azure, and GCP. If your agent estate spans cloud environments, governance travels with it through the same control plane. That’s powerful.
AWS AgentCore Agent Registry is worth knowing about as a complementary discovery layer. It stores agent records across frameworks and clouds and supports semantic search and approval workflows - and is useful if your estate includes agents running entirely outside Databricks and you need a single cross-platform catalogue. It is a discoverability tool, not a governance layer. For most Databricks-on-AWS deployments, Unity Catalog covers the registry function without it.
Open source alternative: purpose-built open source agent registry tooling is immature right now. The practical path is a lightweight service catalogue like Backstage for discoverability combined with OPA for policy enforcement - neither of which was designed for agents, but both of which work today without significant custom engineering. I have found this GitHub Repo, I never tried it or even explored it - might you might want to have a look.
If you find one or know one - let me know in comments.
Component 2: Ownership — Who Controls the Agent
Ownership is where shadow AI comes from. An agent without an owner is an agent nobody is responsible for. In regulated environments, that is not an abstract risk.
An ownership record needs to capture: the team or business owner, accountability mapping, the access governance model, the escalation path, approval authority, and lifecycle responsibility - including who decommissions the agent and when.
On the identity side, AWS IAM is the enforcement mechanism. Each agent should operate under a dedicated IAM role with least-privilege permissions - no shared credentials, no roles that accumulate access over time. IAM Policy Autopilot, allows AI coding tools to generate baseline IAM policies directly from application code, reducing the gap between what an agent was built to do and the permissions it actually holds.
Accountability trails run through AWS CloudTrail. Every registry access and administrative action is logged. In AgentCore Agent Registry, CloudTrail integration is built in, meaning you have an auditable record of who approved an agent, when it was registered, and when its record was last modified.
Unity Catalog extends this further. Audit logs capture every agent action. Unity AI Gateway release introduced MCP server governance - controlling which agents can access which external systems and tracking how that data is used. Ownership in the registry is not just a field in a database. It maps directly to the IAM role, the Unity Catalog access policy, and the audit trail.
Open source alternative: Open Policy Agent (OPA) provides policy enforcement for ownership and access governance in environments not running on the Databricks or AWS managed stack. It is cloud-agnostic and widely used in regulated industries.
If you find good open-source stack please comment here. I am looking for them as well.
Coming Wednesday: Risk Class and Autonomy Level
Schema and Ownership tell you what an agent is and who is responsible for it.
That is necessary but not sufficient.
The harder question is what an agent is allowed to do and what stops it when it operates outside its boundaries.
Part 2 covers Risk Class: how risk classification moves from a metadata tag in Unity Catalog to a live runtime control via Unity AI Gateway and AgentCore Policy. I will also cover Autonomy Level, the scale from assistive-only (L0) to multi-agent autonomy (L4), and the kill switch infrastructure that makes higher autonomy levels safe enough to deploy in a regulated environment.
This is the part of the registry most organisations skip entirely. It is also the part that determines whether your governance is real or decorative.
Talk soon,
Sandi.
P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.
Ask your friends to join.
More valuable content coming your way.
Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.
I am not an expert in this area but have started learning the things. Thank you for sharing this article. Keep sharing the insights
Hey! Sounds like we have similar interests. I’m a PhD researcher studying continual learning in deployed LLMs, and one question keeps following me: what would it mean for AI systems to remember better?
This piece is about why agents should not only retrieve what looks similar, but what belongs together, more like human memory does. Let me know what you think!
https://apattichis.substack.com/p/the-problem-with-searching-only-by