Explainers6 min read
What is an agent system of record?
A plain definition of the agent system of record, the 12 field groups it tracks, why it borrows from HR's employee registry, and nine criteria for evaluating one.
Tomas LindqvistDirector of Platform Product
Updated
On this page
An agent system of record is the authoritative registry of every AI agent operating in an enterprise: who owns it, what it is allowed to do, what data it touches, and how it is performing. It does for agents what a human capital management system does for employees, and as of September 2026 it is the control point most audit and risk teams ask about first when AI agents move from pilot to production.
Why agents need a system of record
Defined simply, an AI agent is software that takes a goal, plans steps, calls tools or systems, and produces an outcome with limited or no human intervention per step. A chatbot answers; an agent acts. Once software can act, the questions that apply to any actor in the enterprise apply to it: who authorized it, what can it reach, and who answers when it is wrong.
Most organizations discover the problem the same way. A finance team pilots an agent to collect audit evidence. HR deploys a help desk agent. A partner ships an agent inside a procurement tool. Two engineers build an agent in a low-code studio over a weekend. Within a year, an internal survey typically finds 30 to 60 agents with no common inventory, no single owner per agent, and no record of which ones can write to the general ledger or the HR core. That is the sprawl an agent system of record exists to prevent.
The concept borrows deliberately from HR. An employee registry records a person's role, manager, start date, access grants, training status, and performance history. It exists because organizations learned that unaccounted-for people with unaccounted-for access are a control failure. Agents create the same exposure at higher speed, so the registry pattern transfers almost field for field.
What the registry tracks
Meridian's Registry is the system of record for agents built by Meridian, by partners, or by the customer in Studio. Every agent gets one entry. The table below lists the 12 field groups Registry maintains and why each one exists.
| Field | What it records | Why it matters |
|---|---|---|
| Agent identity | Unique ID, name, version, source (Meridian, partner, customer-built) | You cannot govern what you cannot name |
| Accountable owner | A named human and a backup, with a business unit | Every consequential outcome has a person attached |
| Scope | The single workflow the agent is authorized to perform | Prevents drift from "help desk" to "payroll changes" |
| Permissions | Systems, objects, and operations the agent may read or write | Enforced through the customer's existing security model |
| Data touched | Actual data categories accessed in the last 30 and 90 days | Supports DPIAs and access reviews with evidence, not intent |
| Approval tier | Which actions run autonomously and which require a human sign-off | Makes the human-in-the-loop policy inspectable |
| Model configuration | Which model the agent runs on, and which routing rules apply | Needed for model risk management and vendor reviews |
| Compliance status | Risk classification, review date, DPIA reference, open findings | Answers the auditor's question in one screen |
| Lifecycle state | Draft, pilot, production, suspended, retired | Retired agents lose credentials automatically |
| Consumption | Credits used by period, cost per completed outcome | Ties spend to work done |
| Outcomes | Completed actions, deflections, hours saved, error rate | The basis for blended workforce analytics |
| Incident log | Escalations, overrides, rollbacks, and their resolution | Pattern detection across agents, not just per agent |
Two design choices that matter more than the field list
Two design choices matter more than the field list. First, Registry records what agents actually did, not only what they were configured to do. Permission grants describe intent; access logs describe reality, and audits are about reality. Second, the registry is enforceable. When an owner suspends an agent in Registry, the agent's credentials at the Gateway stop working within seconds. A registry that is only a spreadsheet with better formatting is an inventory, not a system of record.
Blended workforce analytics
Blended workforce analytics is reporting that places agent work and human work in the same frame: hours, cost, throughput, quality, and coverage by process. Without it, leaders see agent metrics in one dashboard and headcount metrics in another and cannot answer the question that matters, which is whether the process got cheaper, faster, or safer.
An example from an HR service center
A useful blended view for an HR service center might show:
- Case volume by channel, split into cases resolved by the Help Desk Agent, cases escalated from agent to human, and cases opened directly with a human.
- Median resolution time for each path. In modeled design-partner deployments, the Help Desk Agent deflects up to 75% of case volume and shortens resolution time by about 30% for the cases it handles.
- Human hours redeployed, measured by comparing generalist time on tier-1 cases before and after deployment.
- Error and reopen rates by path, so quality is compared rather than assumed.
- Credits consumed per resolved case, next to the fully loaded cost per human-resolved case.
The same structure applies in finance. The Audit Agent's evidence packages, the Controls Agent's flagged transactions, and the Close Agent's completed reconciliations each appear as work units with a cost, a cycle time, and a human review outcome. Because Registry holds the outcome fields for every agent, the analytics layer does not need a separate integration per agent.
How the registry fits with the rest of the platform
Registry is one of five platform components, and its value depends on the others.
- Gateway enforces what Registry records. Third-party and customer-built agents connect through Gateway using Model Context Protocol for tools and OpenTelemetry for observability, so every tool call carries the agent's registered identity.
- Data Fabric supplies zero-copy access to warehouses, so the "data touched" field reflects real queries rather than a static list.
- Studio publishes customer-built agents directly into Registry with an owner and a scope before they can run.
- Assist, the conversational front door, only runs agents that Registry marks as production and that the requesting user is authorized to invoke.
Buying criteria for an agent system of record
If you are evaluating an agent system of record in 2026, the following criteria separate a governance layer from a catalog.
- Coverage of non-native agents. The registry must accept agents you did not buy from the vendor, through open standards rather than a proprietary SDK. Ask how a partner's agent, or one built in your own cloud, registers and authenticates.
- Enforcement, not just documentation. Suspending an agent in the registry should revoke access in the runtime. Ask for a demonstration with a stopwatch.
- Evidence of data touched. Ask whether the registry can show, for a chosen agent, the tables, objects, and record counts accessed in the last 90 days.
- Approval tiers as data. Human-in-the-loop rules should be stored as structured fields, so an auditor can list every agent permitted to post a journal entry without human approval.
- Ownership workflows. Owner departure should trigger reassignment, not orphaned agents. Ask what happens when an owner's account is deprovisioned in the IdP.
- Cost attribution. Consumption should be visible per agent and per outcome, so finance can budget for agents the way it budgets for contractors.
- Blended analytics. Look for reports that place agent and human throughput in the same table for the same process.
- Auditor-ready exports. Compliance status, permissions, and incident history should export in a format your audit firm will accept as evidence.
- Identity integration. Agents should carry identities from your enterprise IdP, with credentials rotated and revoked through the same lifecycle as human accounts.
Common mistakes
- Treating the registry as a one-time inventory. Agents change versions and scopes monthly; the registry must update from the runtime automatically.
- Registering only high-risk agents. Sprawl comes from the long tail of small agents, and small agents acquire permissions over time.
- Assigning ownership to a team rather than a person. Teams do not answer escalation pages at 2 a.m.
- Skipping the retirement state. Retired agents with live credentials are the agent equivalent of a former employee with a working badge.
An agent system of record is not a new idea; it is an old control applied to a new kind of worker. Organizations that already run disciplined employee lifecycle processes will recognize most of it. The difference is speed: an agent can be created, granted access, and put to work in an afternoon, so the registry has to be in the path from the beginning rather than reconstructed later.
Outcome figures in this article are modeled outcomes from design-partner deployments and are not guarantees of results.
Terms used in this guide
Frequently asked questions
An agent registry is an inventory: a list of agents with descriptive fields. An agent system of record is the authoritative, enforced source of truth: the runtime consults it before an agent acts, and changes to it, such as suspending an agent or narrowing its scope, take effect in the runtime. Meridian's Registry is enforced through Gateway, which is what makes it a system of record rather than a catalog.
Because an agent can take actions with consequences, and consequences need an accountable person for escalation, approval, review, and regulatory response. Assigning ownership to a team leaves nobody to answer an escalation or a works council question. Registry requires a primary and a backup owner per agent and prompts reassignment when an owner's account is deprovisioned.
No. IAM issues identities and enforces access at the system level; the agent system of record adds what IAM does not hold: scope, approval tiers, data actually touched, compliance status, consumption, and outcomes. Meridian agents carry identities from the customer's IdP, and Registry references those identities rather than replacing them.
At minimum: identity and version, accountable owner, scope, permissions, data touched, approval tier, model configuration, compliance status, lifecycle state, consumption, outcomes, and an incident log. The two fields most often missing from home-grown inventories are data actually touched, as opposed to permissions granted, and a lifecycle state with an enforced retirement.