Your AI agent inventory register is the single list of every AI agent your organisation runs, with one row per agent recording its purpose, owner, capabilities, depth, data, connections, certification status and review dates. Use it to answer the first question any board, auditor or regulator asks: what agents do you have, and who is responsible for each?
What is the register for?
You cannot govern what you have not listed. Agents appear in pilots, inside vendor products, in spreadsheets with scripts attached, and in teams that never told IT. An inventory brings them into view. The concept, and how it differs from a model inventory, is in what an AI inventory is.
The register is also the index for every other governance record. The role charter, risk assessment, certification evidence and change log for an agent all hang off its inventory ID.
When should you use it?
Add an agent at the idea stage, with status "proposed", and keep it there until it is retired. An agent that is decommissioned stays on the register with status "retired" so its past decisions can still be traced.
Review the whole register quarterly, and reconcile it with what is actually running: check identity systems for agent accounts, and procurement records for vendor tools with agent features. The practical method is set out in how to maintain an inventory of AI agents.
How do you fill in each field?
- Agent ID never changes, even if the agent is renamed.
- Type distinguishes agents you built, agents configured on a platform, and agent features inside a vendor product. All three belong on the register.
- Capabilities and depth is a summary. Highest depth is the field to scan; full detail sits in the depth matrix.
- Data lists the classes the agent reads, especially personal, special-category and card data.
- Actions lists the systems it can change, separate from those it reads.
- Withheld or refused actions is a reference to the agent's entries in the withheld actions register.
- Reversibility notes whether any action is hard to undo; detail sits in the action reversibility register.
- Regulatory flags note any classification that adds obligations, such as a high-risk use under the EU AI Act.
The template
| Field | Guidance |
|---|---|
| Agent ID | Permanent reference |
| Name | Current name |
| Type | Built, platform-configured, vendor feature |
| Status | Proposed, in test, live, suspended, retired |
| Purpose | One sentence |
| Business unit | Owning team |
| Accountable owner | Named person |
| Capabilities | List |
| Highest depth | 1 to 5 |
| Data classes read | Public, internal, personal, special-category, card |
| Systems it acts in | List |
| Customer-facing? | Yes or no |
| Regulatory flags | High-risk use, model risk in scope, DPIA required |
| Certification status | Current, lapsed, failed, not certified |
| Certificate expiry | Date |
| Links | Charter, risk assessment, change log, DPIA |
| Last reviewed | Date |
A worked sample
A hypothetical insurer, four rows (extract of fields).
| ID | Name | Type | Status | Owner | Highest depth | Data | Customer-facing | Flags | Certification |
|---|---|---|---|---|---|---|---|---|---|
| AG-001 | Claims intake | Platform-configured | Live | Head of home claims | 3 | Personal | Yes | DPIA done | Current |
| AG-002 | Underwriting summary | Built | In test | Head of underwriting | 2 | Personal, health | No | Life underwriting: high-risk under EU AI Act; DPIA required | Not certified |
| AG-003 | Email triage | Vendor feature | Live | Customer service manager | 2 | Personal | No | None | Not certified |
| AG-004 | Broker commission reconciliation | Platform-configured | Suspended | Finance controller | 3 | Internal | No | None | Failed |
Two rows need action. AG-003 is live without certification because it arrived as a feature in an email tool; nobody treated it as an agent. AG-004 failed its last run and was suspended, which is the register doing its job. AG-002 is flagged early because risk assessment and pricing for life and health insurance is listed as high-risk in Annex III of the EU AI Act.
For a shorter answer to the same question, see how to keep an inventory of AI agents.
Where Pryme fits
Every agent in Pryme has an identity, an owner, a set of certified capabilities and an expiry date, so the core inventory fields come from the platform rather than a spreadsheet. Agents outside Pryme still need rows. See agent governance is a bound, not a model.
Questions people ask
Do agent features inside vendor software belong on the register?
Yes, if they read your data and take or draft actions. Record them as vendor features, assess them, and note what control you have over their bounds.
Who should own the register?
A central governance function, usually in operational risk or a dedicated AI governance team. Each business owner keeps their own rows current.
How is this different from a model inventory?
A model inventory lists models and their validation. An agent inventory lists agents and what they can do. One agent may use several models; several agents may share one.