Decide what counts as an agent before you count anything
Inventories stall here, because the team spends a week arguing about definitions instead of listing rows. Use a working definition that is deliberately wide and narrow it later if the list becomes unmanageable. Something counts if it decides at run time what to do with your data, rather than following a path someone drew in advance. That test catches more than the things sold to you as agents:
- Agents built on your CRM platform, whoever built them: your team, a partner, or a vendor.
- Agents inside purchased tools that read or write your records through an integration.
- External assistants connected to the org through an integration user or an API key.
- Internal scripts and services that call a model and then write the result onto a record.
- Pilots and proofs of concept that were never formally launched and were never switched off.
It excludes deterministic automation. Flows, assignment rules and scheduled jobs do exactly what they were configured to do, so reading the configuration tells you the behaviour. Why that line matters, and why it moves once an agent is involved, is the subject of what agents on Salesforce actually are.
Look in five places, not one
No single screen holds the answer, so the list is assembled from partial views that overlap. Between them, these five find most of what any one view misses:
- The agent builder in your platform. The one authoritative source, and it covers only the agents built there.
- Integration users and connected apps. Anything outside the platform that touches your data needs an identity to do it. Work through that list and ask what sits on the other end of each one.
- Identities with API access and steady programmatic activity. Something making calls at volume on a schedule is a system, and somebody should be able to name it.
- The vendor and procurement list. Ask which purchased tools have added AI features since they were bought. Many agents arrived as a feature release rather than as a purchase decision.
- The teams themselves. Ask what people are using, without making it a compliance interview. Pilots surface here and nowhere else.
Run all five. Each one alone gives a confident and incomplete answer, and the gaps between them are where the interesting rows are.
What each row has to hold
A list of names is not a register. A row earns its place when it answers the questions somebody will ask on the bad day, so capture these from the start, including where the answer is blank:
- What it does, in one sentence a non-specialist would understand.
- Who owns it on the business side, by name, and who owns it on the platform side, by name.
- Which identity it runs as, and what that identity can read and write.
- Whether a written approval exists, and if so which version.
- Which model sits behind it, and who controls that choice.
- When it was last inspected against the approval, and where that report can be read.
The fifth line is the one people leave out, and it is the one that dates fastest. A model can be swapped or retired under a live agent without anything in your org changing, so a row that cannot say what the agent is running on cannot tell you when that happened.
The rows you cannot complete are the output
The instinct on a first pass is to treat blanks as unfinished homework and hide them until they are filled. Do the opposite. An agent with no named owner is not an administrative gap, it is the first finding, and it is usually the most actionable thing the exercise produces. No written approval means nobody can say what the agent is supposed to do. Never inspected means nobody has checked. Record all three states honestly: nothing is green by default, and an uninspected agent shows as uninspected rather than as fine.
Rank by what failure would cost, not by what is newest
Once the list exists, the pull is to work down it in the order it was written. Order it by blast radius instead, which usually comes down to three questions per row. Does it speak to customers in your name? Does it write to records rather than only reading them? Does it touch money, contracts or personal data? An agent that summarises knowledge articles for staff can wait. An agent that sends customer correspondence or moves an opportunity cannot.
Assume it is out of date the week after you finish
The inventory is a snapshot and it starts decaying immediately. A team pilots something. A vendor ships an AI feature into a tool you already own. An integration is connected for a project and left in place. A list rebuilt by hand once a quarter is a list that is wrong for most of the quarter. The version that stays true is event-driven: rows change when something happens to the agent, not when somebody remembers to audit. Why that shift matters more than the list itself is the longer argument.
Where Huscribe fits
Huscribe keeps the register as a product rather than a spreadsheet. Agents inside the org are found by the readiness check, agents outside it are registered by you, and each row carries the signed approval by version, the inspection state, what changed last and where the evidence lives. Discovery runs through a dedicated identity, and what that access can and cannot touch is set out in full. You do not need Huscribe to start. You need one row, honestly filled in, for the agent whose failure would hurt most. The route from that row to a signed approval and a schedule of checks is in how Huscribe builds and inspects Salesforce agents.