An audit committee member asks you, in May 2026, two questions you have ninety seconds to answer well. "How many AI agents are running in production right now, and what can each one do?" If the second question feels harder than the first, you do not have a governance program — you have a science project. The agent inventory is the artifact every other piece of governance hangs from: the EU AI Act's deployer obligations under Article 26, the NIST AI 600-1 GenAI profile's risk management map, ISO/IEC 42001's clause 8.3 operational control, the MITRE ATLAS v5.4.0 threat model, your insurer's questionnaire, your board's risk appetite statement. None of them work if you cannot list the agents. This lesson is the unified intake-to-register flow: a fifteen-question intake form that every new agent must complete before it touches a production credential, the living register the form populates, and the risk tiering system that turns "we have 47 agents" into "we have 6 high-risk agents under monthly review, 18 medium under quarterly review, 23 low under annual review, here is who owns each, here is what each can do, here is where each one's logs go for the next six months as Article 26 requires."

Why the Inventory Is the Foundation

A common pattern in 2026 mid-market and large enterprise: the agent program started in 2024 with one or two builders inside a function (marketing, customer success, IT) experimenting with n8n or Lindy or Copilot Studio. By late 2025, three or four other teams had quietly launched their own. By May 2026, the security team's quarterly attack-surface review surfaces 19 agents nobody had centrally registered, of which 4 are connected to production Salesforce orgs, 2 have write access to financial systems, and 1 is performing customer-facing actions with no human review. The CISO calls an emergency review. The agent program owner — who only knew about 8 of the 19 — has to explain to the CFO why a system labeled "AI" has been operating without governance.

The reason this happens is not that anyone behaved badly. The reason is that agent creation is now zero-friction. n8n and Make and Zapier and Lindy and Copilot Studio and Agentforce and a half-dozen other platforms make "build an agent" something a non-engineer can do in an afternoon. The traditional governance entry points — code review, infra ticket, change-advisory board — never trigger because the agent never touches infrastructure the traditional controls cover.

The inventory is not a spreadsheet. The inventory is the operating system of the agent program. Every other governance artifact — risk tier, training plan, incident response runbook, compliance log, board update — is a query against the inventory. If the inventory is incomplete or stale, every downstream artifact lies.

What the inventory must answer in twenty minutes

An audit committee meets quarterly and reviews six things, often in one hour. The agent program update is roughly twelve to twenty minutes of that hour. In those twenty minutes, the program owner must be able to answer:

• How many agents are running in production, and what is the trend over the past four quarters?
• What is the risk tier distribution (high / medium / low) and how is each tier defined?
• Which agents are net-new since the last quarterly review, and which were retired?
• For high-risk agents specifically: who owns each, what is the last review date, what is the next review date, what eval evidence exists?
• What is the breakdown by regulatory regime (EU AI Act Annex III categories, sectoral regulation, none)?
• What incidents in the past quarter involved an agent, and what changed as a result?
• Where do the agent action logs live, what is the retention policy, and is it compliant with the longest applicable retention requirement (Article 26 requires six months)?

If any of those seven cannot be answered cleanly from the register, the inventory is failing its job. The fifteen-question intake form exists to make sure every new agent contributes the data the register needs.

The Fifteen-Question Intake Form

The intake form is the door. Every agent passes through it before being issued production credentials, MCP server allowlist entries, or platform-level deploy rights. The form is short by design: fifteen questions, completable in roughly thirty to forty-five minutes by the agent's builder, signed off by the business owner and the governance contact before credentials are issued.

The questions cluster into five groups of three. The clustering is deliberate — it maps to the five fields the audit committee actually queries.

Group 1: Use case and business owner

1. What is the agent's name and one-sentence purpose? Plain language, no jargon. "Drafts first-response emails to inbound customer-support tickets for the EU region in English, German, French, and Italian." A name and one-sentence purpose is the row label every downstream artifact uses. If the team cannot write the sentence cleanly, the agent's scope is not yet clear enough to deploy.
2. Who is the business owner (a named human, not a team) and who is the technical owner? Two named humans. The business owner accepts the outcomes the agent produces; the technical owner is on-call for incidents. Email addresses on file. Either role changing triggers a register update within five business days.
3. What is the success metric and the target threshold? Not "save time." Concrete. "Reduce median first-response time for L1 EU support tickets from 4h12m to under 30min while maintaining CSAT at or above 4.3/5.0 on the agent-handled subset." If the team cannot write a falsifiable success metric, the agent should not be in production. Aspirational metrics ("delight customers") fail this gate.

Group 2: Blast radius and reversibility

4. What actions does the agent take, and on whose behalf? An explicit action list. "Reads inbound ticket from Zendesk. Generates draft. Posts draft to Zendesk as internal note for human agent review. Never sends to customer directly." Or "Reads pipeline data from Salesforce, generates weekly forecast, posts forecast to Slack channel, optionally writes summary to Notion." Each verb-object pair is in scope; anything not on the list is out of scope and out of compliance if the agent does it.
5. What is the blast radius if the agent does the wrong thing? Three named categories. Reputational (customer sees a wrong answer; brand cost). Financial (money moves, refunds processed, contracts altered; quantified maximum exposure). Regulatory or safety (decision affects a person in a protected class, employment, credit, healthcare, education, biometrics, critical infrastructure; EU AI Act Annex III implications). The form requires a sentence per category, even if "none."
6. Reversibility: for each action the agent takes, can the action be undone, by whom, in what time window, with what audit trail? Sending an email is irreversible the moment it lands. Writing to Notion is reversible by editing. Posting a refund is reversible by a credit reversal. The team must enumerate.

Group 3: Data classes and identity

7. What data classes does the agent read, write, or transmit? Choose from the organization's data classification taxonomy (typically Public, Internal, Confidential, Restricted, plus tags like PII, PHI, PCI, IP). For each class, indicate volume tier (single record per call, hundreds, millions). The presence of Restricted or any regulated data class auto-elevates the risk tier ceiling.
8. What is the agent's identity model — delegated (acts as a specific human via OAuth) or service principal (its own non-human identity)? Which IdP (Entra ID, Okta, Google Workspace, Salesforce, Ping). What OAuth scopes are requested? What is the consent UI the human saw if applicable? Identity is the answer to "on whose behalf did this happen?" — and the question that the regulator will ask first.
9. What MCP servers, tools, or external APIs does the agent connect to, and what is the data-egress story? A complete list. For each: vendor, region the data leaves to, contractual basis for the transfer (DPA, SCCs, data residency commitment), and whether the provider is on the approved-vendors list.

Group 4: Success, kill criteria, and review cadence

10. What are the kill criteria — the conditions under which the agent must be paused or disabled? Concrete. "Pause if hallucination rate on shadow eval exceeds 5% over a 1-hour window. Disable if any single output triggers a Tier-1 customer complaint." "Pause if cost per run exceeds $2.00." Kill criteria are pre-committed; they reduce the cost of saying "stop" in the middle of an incident.
11. What is the governance-review trigger — what changes require returning to this committee, versus being handled inside the team? Examples: new MCP server connection, additional OAuth scope, new data class, change in business owner, expansion to a new jurisdiction, model family change, risk tier escalation. Anything on the list = mandatory re-review; anything not on the list = team change-control only.
12. What is the proposed review cadence and the proposed risk tier (high / medium / low)? The team's own assessment goes in here. The governance committee may agree or override. Default cadences: high = monthly, medium = quarterly, low = annually. Cadence ties to who must be in the room for the review.

Group 5: Logging, retention, and regulatory mapping

13. Where do the agent's logs go, and what is the retention period? Datadog, Splunk, LangSmith, AgentOps.ai, Helicone, Langfuse, the platform's native log store. For each, the retention. The retention must be greater than or equal to the longest applicable regulatory floor (Article 26's six months for high-risk AI deployers is the most common floor; sectoral retention can be longer).
14. Which regulatory regimes does the agent's use case fall under? Multi-select: EU AI Act Annex III (employment, education, credit, biometrics, critical infrastructure, law enforcement, migration, judicial / democratic processes); GDPR; HIPAA; PCI-DSS; SOX; FERPA; sectoral (financial services, healthcare); none. The selection drives the FRIA requirement, the deployer-obligation checklist, and the audit trail design.
15. What is the rollback plan if the agent must be removed from production immediately? The runbook. Who has the disable button. What happens to in-flight requests. What human team picks up the workload. How long does the rollback take. Tested? When last?

The Risk Tiering System

Fifteen questions produce a lot of data. The risk tiering system is the scoring rubric that turns the answers into one of three labels: high, medium, low. The rubric must be defensible — if the regulator (or your auditor) asks how a particular agent ended up in the medium tier instead of high, the program owner must be able to point to a written rule.

Tier ceilings — automatic floors

Certain answers raise the tier ceiling automatically. The principle: if any one factor is high, the agent is high, regardless of the rest. The factors:

• Use case in EU AI Act Annex III high-risk category (employment, education, credit, biometrics, critical infrastructure, law enforcement, migration, judicial or democratic processes). Auto-high.
• Use case in sectoral high-risk regime with comparable controls (HIPAA-covered clinical decision, SOX financial reporting, PCI-touching transaction authorization). Auto-high.
• Agent action category is "decisions that materially affect natural persons" (hiring, firing, credit approval, healthcare triage, insurance underwriting, education access, government services). Auto-high. (This often overlaps with Annex III but is broader.)
• Agent has irreversible financial actions above a defined ceiling (e.g., wire transfers, refunds above $X, contract execution). Auto-high until the ceiling can be lowered with controls.
• Agent processes Restricted data class or special-category personal data (GDPR Article 9). Auto-high or auto-medium depending on volume.

Scoring inside the medium and low tiers

Below the ceilings, a scoring rubric produces a numeric score. A simple, defensible scoring example:

• Blast radius: 0 (internal-only outputs reviewed by human before action) / 1 (customer-facing but reversible) / 2 (customer-facing and irreversible) / 3 (financial or safety impact).
• Data sensitivity: 0 (public / internal only) / 1 (confidential, no special category) / 2 (PII or contractual confidentiality) / 3 (Restricted, special category, regulated).
• Identity: 0 (service principal with narrow read-only scopes) / 1 (delegated identity with narrow scopes) / 2 (delegated with broad scopes) / 3 (any write access to systems-of-record).
• Reversibility: 0 (all actions reversible by single human action) / 1 (most actions reversible) / 2 (mixed reversibility) / 3 (one or more actions irreversible).
• Autonomy: 0 (always human-in-the-loop on action) / 1 (human reviews summary, agent acts) / 2 (human samples, agent acts) / 3 (agent acts; human sees logs only).

Summed score 0-3 = low, 4-8 = medium, 9-15 = high (with the auto-high ceilings above always applicable). The scoring is starting material, not gospel: the governance committee can adjust either direction with documented reasoning. The point is that every assignment is justified in writing.

What each tier triggers

Tiers are not labels for their own sake; each tier triggers concrete controls. A common scheme:

• High-risk agents. Monthly governance review with security, legal, business owner, and technical owner in the room. FRIA (Fundamental Rights Impact Assessment) on file. Article 26 deployer-obligation checklist completed. Six-month log retention minimum. Dedicated incident runbook with named on-call. Pre-prod red-team eval. Quarterly tabletop exercise.
• Medium-risk agents. Quarterly governance review. Standard log retention (often six months by default for safety). Documented eval set with regression run on every platform upgrade. Designated owner notified on incident.
• Low-risk agents. Annual review (or upon material change). Standard logging. Eval set with sanity-check cases. Slack channel notification on incident.

The reviewer will ask "what makes this one high but that one medium?" and the rubric is the answer. Every agent's tier should be defensible against the rubric without recourse to "we just felt it was."

The Living Register

The register is the queryable representation of the inventory. It can live in many systems — a wiki page can work for a portfolio of fewer than fifty agents; for larger portfolios a structured tool (Airtable, Notion DB, ServiceNow, a custom internal app, Collibra or OneTrust for organizations with mature GRC tooling) becomes necessary. The choice of tool is less important than the discipline of one source-of-truth.

The required columns

The register has roughly thirty columns, all derived from the intake form plus operational state. The essentials:

• Identification. Agent ID, name, one-sentence purpose, business owner, technical owner, slack channel.
• Lifecycle. Status (proposed, dev, staging, prod, deprecated, retired), production go-live date, last review date, next review date, retired date if applicable.
• Risk and regulatory. Risk tier (high / medium / low), tier rationale link, regulatory regimes (multi-select), FRIA link if applicable, Article 26 checklist link if applicable.
• Architecture. Platform (n8n, Make, Lindy, Copilot Studio, Agentforce, custom LangGraph, etc.), model family and version, prompt version reference, eval set reference, MCP server list, OAuth scopes.
• Operational. Logs destination, retention period, incident channel, on-call rotation reference, kill criteria summary, rollback runbook link.
• Performance. Last SLO compliance report, last eval score, last cost-per-run, escalation rate, incident count this quarter.

Keeping the register alive

A dead register is worse than no register: it creates the illusion of governance without the substance. Discipline practices that keep the register accurate:

• Mandatory pre-prod gate. The intake form populates the register before credentials are issued. No exceptions. The platform team's credential workflow integrates with the register: a request for new MCP server access, new OAuth client, new API key bound to an agent must reference an agent ID that exists in the register, or the request is rejected.
• Scheduled review forcing function. Every agent has a next-review date. As that date approaches, the register tool emails the business owner and the technical owner two weeks ahead. If the review does not happen, the agent's status flips to "review overdue" and the platform team can suspend its credentials. The forcing function is the only thing that prevents the register from staleness.
• Change-trigger update obligation. The governance-review-trigger list defined in intake question 11 is also the register-update trigger list. Any change on that list requires updating the register within five business days. The team's change-management process integrates the register update as a step.
• Quarterly health check. Every quarter, the program owner queries the register for stale rows (last-reviewed > cadence allows), missing fields (any agent missing FRIA where required), or contradictions (high-risk agent with no quarterly review evidence). The discrepancy report is part of the QBR with leadership.

Audit-ready in twenty minutes

An auditor (internal or external) or an audit committee member walks up with a tablet. The program owner opens the register, filters to high-risk agents, and walks through each: name, owner, last review, next review, eval evidence link, incident history. Then medium, summarized. Then low, summarized. Then trend over four quarters. Then recent incidents and what changed. Twenty minutes; complete; honest.

The point is not to impress. The point is that the register is what makes the conversation possible at all. Without it, the same conversation becomes "let me get back to you" — and "let me get back to you" is the answer that destroys credibility with audit committees, regulators, and CISOs in 2026.

Worked Example: The EU L1 Support Agent

Concrete makes the abstract real. A worked example: a customer-success team wants to deploy an agent that drafts first-response emails to inbound L1 support tickets for the EU region, in English, German, French, and Italian. The drafts are posted as Zendesk internal notes for human agent review and edit before sending.

The intake answers (abbreviated)

Q1 — Name/purpose. "Athena. Drafts first-response emails to L1 EU support tickets for human review."

Q2 — Owners. Business: Marta Henriques, EU Support Lead. Technical: Devon Park, Senior Engineer.

Q3 — Success metric. Median first-response time reduced from 4h12m to under 30min; CSAT 4.3+ on the agent-handled subset.

Q4 — Actions. Reads ticket from Zendesk via Zendesk MCP. Generates draft. Posts as Zendesk internal note. Never sends to customer directly.

Q5 — Blast radius. Reputational: drafts that contain wrong information are visible to support agents; if a draft passes review unedited and contains an error, the customer sees it. Financial: low; agent does not commit refunds. Regulatory/safety: data subjects include EU citizens; GDPR Article 5 lawful processing applies; the agent processes support tickets that may contain personal data and occasionally account references.

Q6 — Reversibility. Drafts: reversible (edit before send). Sent emails (if a reviewer hits send unchanged): irreversible.

Q7 — Data classes. Confidential (support content), PII (customer name, email, sometimes account ID), no PCI, no Restricted. Volume: 10-50K tickets per month.

Q8 — Identity. Service principal in Entra ID, dedicated app registration. Scopes: Zendesk tickets:read, tickets:write (notes only, not customer-replies). No human-delegated identity in this design.

Q9 — MCP/tools. Zendesk MCP (EU region), internal vector store for prior solved tickets. Egress: Zendesk EU data residency, internal store in same EU region.

Q10 — Kill criteria. Pause if hallucination rate on shadow eval > 5% over 1h. Disable if any draft posted contains made-up account numbers. Pause if cost per draft > $0.40.

Q11 — Governance-review triggers. Adding write-customer-reply scope; expanding to non-EU regions; switching model family; adding new MCP server; change in either owner.

Q12 — Cadence/tier. Team proposes medium. Reasoning: customer-facing but human-reviewed; PII present but not special-category; no Annex III category.

Q13 — Logs. Zendesk audit log + LangSmith trace store + Datadog. Retention: 12 months (exceeds Article 26 six-month floor).

Q14 — Regulatory regimes. GDPR. Not Annex III (not employment, not credit, not biometric). Not HIPAA. Not PCI.

Q15 — Rollback. Disable button: Devon Park or program owner. In-flight drafts: discarded. Workload picked up by existing support agents (returns to pre-Athena baseline). Tested in staging; never tested in production.

The risk tier computation

Ceilings: no Annex III category, no sectoral high-risk, no decisions materially affecting natural persons in the auto-high sense, no irreversible financial actions, no Restricted data class. None of the auto-high ceilings trigger.

Scoring: blast radius 1 (customer-facing, reversible because reviewed). Data sensitivity 2 (PII at volume). Identity 1 (service principal with narrow scopes). Reversibility 1 (drafts reversible, sent emails irreversible after reviewer ships them). Autonomy 1 (human reviews before send). Total: 6.

Score 6 = medium. The team's proposal matches the computed tier. The governance committee approves medium, quarterly cadence, with one note: the team must implement a hallucination-rate shadow eval before go-live, and report the rate as part of the first quarterly review. The note is appended to the register row.

What the register row looks like

Agent ID AG-2026-031. Name Athena. Status: prod. Owners: Henriques / Park. Risk tier: medium. Rationale: link to scoring sheet. Regulatory regime: GDPR. Platform: n8n self-hosted in EU. Model: claude-sonnet-4-5-2026-03-20. Prompt version: v2.1.0. Eval set: athena-eval-v1.4, 142 cases. MCP servers: zendesk-eu, internal-vectorstore-eu. OAuth scopes: tickets:read, tickets:write (notes-only). Logs: Datadog (EU region) + LangSmith + Zendesk audit. Retention: 365 days. Kill criteria summary: as filed. Rollback runbook: link. Last review: 2026-04-15. Next review: 2026-07-15. Last eval score: 91.4% pass rate. Cost per run: $0.18. Escalation rate: 4.2%. Incidents this quarter: 1 (link to postmortem).

The audit committee member opens that row and reads the same information in twenty seconds. Multiplied across the 47 agents, the program is legible.

Anti-Patterns and How to Avoid Them

The retroactive register

Built after the agents are running. Inevitably incomplete. Owners cannot remember why decisions were made. Scoring rationale is fabricated. Anti-pattern. The remediation: declare a freeze date, register everything currently in production with a "legacy" flag and a 60-day window to complete intake retrospectively (with sign-off from the business owner who effectively existed already). After the freeze, no new agent enters prod without going through intake. The legacy backlog is worked through in 60 days; the new normal starts immediately.

The shadow agent program

A team builds agents in a platform the program owner has not cataloged (commonly: a marketing team using a vendor's bundled-AI capability that ships agent functionality; a sales ops team using a Salesforce-AppExchange package). The agents are not on the inventory because the team never thought of them as "agents." The remediation: the intake form's question 1 is broader than "did you build an agent?" — it is "what AI-driven automation does your team operate?" A discovery sweep that includes vendor-bundled AI catches these. Joint reviews with procurement help: every new vendor procurement now asks whether the product includes agent-like automation, and if yes, the intake form is part of the procurement gate.

The form-for-form's-sake

A 47-question intake form that nobody completes thoroughly because the form is theater. The remediation: the form is fifteen questions deliberately. The questions are the questions the audit committee will ask. Each question maps to a register column. Nothing on the form is decorative. If a question is not on the form, it is not asked.

The unscheduled review

Reviews happen only on demand. Agents drift out of cadence without anyone noticing. Three quarters after go-live, the high-risk agent has not been reviewed in seven months. The remediation: scheduled reviews with calendar invites placed at go-live; status flip and credential suspension if review is more than 30 days overdue. Treat review-overdue as an operational alert, not an HR concern.

The contradictory register

Register says high-risk but FRIA is missing. Register says delegated identity but the audit log shows service-principal calls. The contradiction is the audit finding. The remediation: a weekly automated consistency check across register fields, log destinations, identity systems, MCP server allowlists. Surfaces contradictions before the auditor does.

Key Takeaways

• The inventory is the operating system of the agent program: every other governance artifact is a query against the register.
• The 15-question intake form clusters into five groups of three — use case/owner, blast radius/reversibility, data/identity, success/kill/cadence, logs/regulatory/rollback — each question maps to a register column and to a question the audit committee will ask.
• Risk tiering uses auto-high ceilings (Annex III, sectoral, material decisions on persons, irreversible financial, Restricted data) plus a five-factor 0-3 scoring rubric, summed to low (0-3) / medium (4-8) / high (9-15). The committee can override with documented reasoning.
• Each tier triggers concrete controls: high = monthly review, FRIA, six-month-plus retention, red-team eval, quarterly tabletop; medium = quarterly review, eval regression on upgrade; low = annual review, sanity-check eval.
• The living register has thirty columns covering identification, lifecycle, risk/regulatory, architecture, operational, and performance, kept alive by mandatory pre-prod gate, scheduled-review forcing function, change-trigger update obligation, and quarterly health check.
• The acid test: can the program owner answer the audit committee's seven core questions (count, tier distribution, net-new, high-risk specifics, regulatory breakdown, recent incidents, log retention) in twenty minutes? If no, the inventory is failing its job.
• Anti-patterns to avoid: retroactive register, shadow agent program, form-for-form's-sake, unscheduled review, contradictory register. Each has a specific remediation.
• The worked Athena example shows the form-to-register-to-tier flow in concrete: 15 answers, 5-factor scoring summing to 6, medium tier confirmed, register row queryable in seconds.