An agent inventory tells you what exists, not what it may do

A list of the agents a firm runs, with owners and purposes, answers one question: what exists. Governance needs a second answer: what each agent may do, at what depth, under which certificate and bounds, right now. A register without that second answer is a catalogue, useful for counting but no help in controlling anything.

What does a typical inventory capture?

Most firms building an AI inventory start with a sensible set of fields: the agent's name, a description, the business owner, the technical owner, the model provider, the systems it connects to, the data it uses, and a risk rating. Some add the date it went live and the date of its last review.

That is a good start, and many firms do not yet have even that. Knowing what agents exist, who owns them and where they run is the foundation. The question of how to keep an inventory of AI agents is worth answering well.

But look at what those fields describe. They describe the agent as a thing. They do not describe its authority.

What does it leave out?

The questions a supervisor, auditor or incident reviewer will actually ask:

• What can this agent do? Not in general, but which specific actions, in which systems?
• For each action, can it only read, or draft, or execute, or move money?
• On what evidence was that authority granted, and is the evidence still current?
• What limits apply: amounts, accounts, customers, times?
• Who approves what it cannot do on its own?
• What did it do yesterday, and was each action within its authority?

A static inventory entry answers none of these. An agent described as "accounts payable assistant, owner: financial controller, risk: medium" might be drafting invoice coding for review, or it might be releasing payments. The entry looks the same either way.

What should sit behind each entry?

Each agent in the register should link to a live view of its authority. An illustrative structure:

The top row is the traditional inventory. Everything below it is what governance needs. An AI agent inventory register template can hold the top layers directly and link to the rest.

Why does it have to be live?

Because authority changes even when nothing in the inventory does. Certificates lapse after a fixed period. A certification run that clears no depth drops an agent to depth 1 the same day. A customer lowers a limit. A source is withdrawn. Each of these changes what the agent may do, and none of them would prompt anyone to update a static register.

Model changes are a particular case. Switching from one model provider to another, or accepting a new version from the same provider, can change behaviour enough to undermine the evidence behind each capability. Whether switching model providers changes what an AI agent may do depends on whether the firm treats that as a reason to recertify. If it does, the agent's authority may change; if the register does not reflect that, the register is wrong.

A register that is reviewed quarterly will be out of date for much of each quarter. The authority layers need to come from the system that enforces them, not from a document someone maintains by hand.

Who keeps it?

Responsibility splits naturally. A central function, usually in risk, governance or the office responsible for AI, owns the register's structure and makes sure every agent is in it. Business owners keep the purpose and ownership fields accurate. The capability, depth, certificate and bounds layers should be generated by the platform that enforces them, so they cannot drift from reality.

The process of keeping the static layers current is set out in how to maintain an inventory of AI agents. The principle for the live layers is simple: never ask a person to type what the system already knows.

What can a complete register tell you?

Things a static one cannot. Which agents can move money, and on whose approval? Which agents have certificates lapsing in the next fortnight? Which agents rely on external sources for decisions? Which agents had more refusals this week than last, and on which bound? How many agents are running at depth 3 or above, and who accepted the evidence for each?

Those are governance questions. A board or risk committee asking "what are our agents allowed to do?" should be able to get an answer from the register in minutes, not a project.

What should you do differently?

Look at your current AI inventory and pick one entry. Try to answer, from the register alone, what that agent is permitted to do today, on what evidence, and within what limits. If you cannot, add the authority layers, sourced from the system that enforces them. An inventory is the first step in agent governance. It is not the last.

Where Pryme fits

In Pryme, each agent's capabilities, certified depth, certificate status, bounds and verdict history are held by the platform that enforces them, so the authority view is always current. A firm's inventory can link each entry to that view, giving reviewers what the agent exists to do and what it may do now.