Agentic Fabriq
AGENT OPERATIONS
Agent Registry vs. Agent Inventory
Inventory and registry aren't rival terms fighting over one meaning. They're sequential records, and one has to feed the other before either is useful.
TL;DR
Inventory and registry aren't rival terms so much as sequential records, and arguing about which one is "correct" misses that each does a job the other can't.
Run discovery across a mid-size enterprise and you'll typically turn up agents by the hundred. Most of them were never reviewed by anyone. A registry, by definition, only ever lists the ones that were.
The confusion is understandable, because in casual conversation people do use the two words interchangeably, and nothing enforces a standard vocabulary here the way, say, a protocol spec does. But the moment you build one system to do both jobs, it does both badly: either everything discovered gets waved through as trusted, or everything unreviewed disappears from view entirely.
This isn't a call for more process. The inventory should stay wide, cheap, and automatic to populate.
The registry should stay narrow and deliberate. The gap between what's in one and what's in the other isn't a bug in your tooling. It's the actual state of your agent estate, measured.
Overview
Say the two terms out loud and the disagreement mostly dissolves. An inventory is a record of what exists. A registry is a record of what's trusted. Put that way, nobody would confuse them, and yet "agent registry" and "agent inventory" get used as synonyms constantly, in vendor pitches and internal wikis alike.
Some of that is genuinely just vocabulary drift, and we don't think there's a governing body handing down the "correct" definitions here. What isn't drift is the operational gap underneath the words. One record has to be comprehensive, including the things nobody wants found. The other has to be selective, including only what someone has actually vouched for. A system that tries to be both ends up being neither.
Two Different Questions
The inventory asks: what agents do we have? It's comprehensive by design. If an agent exists and touches enterprise systems, it belongs here, whether or not anyone approved it.
The registry asks: which agents are trusted to operate? It's selective by design. An agent earns a place here only after it has an owner, a documented purpose, scoped permissions, and a defined lifecycle.
The whole relationship in one line: you can see something you haven't approved. You can approve something only after you've seen it. Visibility comes first, and it doesn't imply trust on its own.
The Inventory: Everything That Exists
The inventory is populated by discovery, not by request. It doesn't judge an agent's legitimacy. It records that the agent is there, and that's precisely what makes it valuable: it catches the agents nobody filed paperwork for.
Take a marketing team that wires up a third-party content agent to draft campaign copy and pull numbers from the analytics platform. Nobody asked the platform team. The agent works, so it stays, unapproved, ungoverned, holding a live token to the analytics warehouse. Discovery-based scanning surfaces it. A registry alone never would, because nobody registered it.
A healthy inventory entry captures the basics: where the agent runs and how it was found, what credentials it appears to use, what systems and data it can reach, who if anyone seems to own it, and whether it looks active, idle, or abandoned. Plenty of entries stay incomplete, and that's fine. An unverified owner is itself a useful fact. It tells you exactly where a gap is.
The Registry: Everything That's Trusted
The registry is populated by a process, not a scanner. An agent lands here because someone proposed it, someone reviewed it, and someone approved it. Where the inventory tolerates ambiguity, the registry refuses it.
A registry entry is a commitment: a named, accountable owner; a documented use case and intended scope; explicit permission boundaries; managed credentials with rotation and revocation; monitoring and an audit trail; a defined lifecycle state.
Take a finance reconciliation agent that posts adjusting entries to the general ledger. Getting into the registry means a finance owner, a written description of which accounts it may touch, a hard limit on transaction size, a dedicated service identity rather than a borrowed login, and a log of every entry it posts. Registration is what turns "an agent that can write to the ledger" into "an agent we've decided to trust with the ledger, within these limits."
Registration is not a formality. It's the moment an enterprise stops merely knowing an agent exists and starts being accountable for what it does. Skip the process and call the result a registry anyway, and you've built an inventory with an extra column.
Two Hundred Agents
Run discovery across an enterprise and suppose it turns up two hundred agents. They're not the same kind of thing. Some are approved production systems doing real work, a procurement agent that triages requests, an IT operations agent that restarts failed jobs. Some are experiments a data team spun up last quarter and never cleaned up. Some are abandoned: the owner left, the project ended, and the credentials are still live. Some are third-party agents individual users connected to their own accounts. Some are simply unauthorized, running with real access nobody sanctioned.
All two hundred belong in the inventory, because the enterprise needs to know they exist. A much smaller number belong in the registry, the ones that have actually been through review and earned approved status. The gap between those two counts is the honest shape of an agent estate mid-adoption, not a failure to clean up, and closing it gradually is what an Agent Operations program is for.
We'd resist the urge to treat that gap as a scoreboard to zero out by next quarter. Some of the two hundred should never be registered at all, the abandoned ones especially, and the right outcome for those is decommissioning, not approval. A shrinking inventory and a growing registry aren't the same kind of progress, and conflating them is its own small version of the mistake this post is about.
How They Connect
In a mature setup the two systems aren't separate silos. They're stages in one flow.
Figure 1 — Discovery feeds the inventory. Review turns inventory entries into registry entries. Registry status then drives downstream authorization and monitoring.
The connection runs both directions. An agent discovery finds that isn't in the registry is worth investigating on its own. A registry entry discovery can no longer find running is a sign of drift, an approved agent quietly decommissioned or moved without anyone updating the record. Reconciling the two views is ongoing work, not a setup task you finish once.
What Goes Wrong
Two failure modes show up when organizations collapse these into one system.
Treat every discovered agent as approved, and governance disappears. The unauthorized analytics agent and the abandoned experiment are now legitimate simply because they were found. Discovery becomes a way of laundering shadow agents into trusted status, which is close to the opposite of control.
Track only registered agents, and the enterprise goes blind to everything else. Unauthorized activity, third-party connections, forgotten experiments, all of it operates entirely outside the field of view. A clean list of trusted agents tells you nothing about what else is running with real access right now.
Conclusion
We think the argument over which term is "more correct" is a distraction from the actual relationship: the inventory answers what agents you have, the registry answers which of them are trusted, and you need both, in that order.
Discover broadly. Record everything, including what you'd rather not have found. Approve deliberately, and let the gap between the inventory and the registry tell you how much of your agent estate is still ungoverned. That gap is data, not embarrassment, and it's the clearest single number an Agent Operations program can report.