Four Risk Tiers for AI Agents — How to Decide How Much Governance Each One Needs

The agent's failure would visibly affect customers, regulators, or core operations. It touches money, sensitive data, regulated decisions, or material customer experience. When this agent is wrong, somebody outside the company finds out.

Examples:

claims-triage agents that route a customer's loss notification, fraud-screening agents that hold a transaction, contract-review agents whose output feeds a binding signature flow, support agents that resolve cases without human review.

What it needs:

Named primary owner plus a named backup — never a team alias, never empty; On-call response with a defined paging path and a runbook; Continuous monitoring on accuracy, latency, error rate, cost per action; Immutable audit trail of inputs, decisions, and overrides — sampled and reviewed; Sponsor sign-off in writing before launch; quarterly review thereafter.

Failure mode:

The failure mode here isn't overinvestment. It's underinvestment: treating a customer-impacting agent like a productivity tool because that's how it was built. The agent inherits whatever discipline its origin story had — which is usually not enough.

The agent supports a workflow that internal teams depend on. When it breaks, work slows down or gets routed manually for a while — but customers don't see it, regulators don't see it, and the business doesn't materially suffer for a day or two.

Examples:

ticket classification before a human picks it up, internal knowledge-base assistants, document summarization for review queues, content tagging for internal search.

What it needs:

Named primary owner (backup optional unless the workflow is time-sensitive); Monitoring on accuracy and error rate; alerting on threshold breach; Defined lifecycle process — onboarding, periodic review, decommission; Registry entry with scope, data sources, and dependencies documented.

Failure mode:

The failure mode here is overinvestment: applying production-critical governance to a workflow that doesn't carry production-critical risk, and ending up with so much overhead per agent that nobody ships them anymore.

The agent is used by a single person or a small team to speed up their own work. The output goes through them before it goes anywhere else. The user is the de-facto reviewer. When it breaks, exactly one person is inconvenienced, and they're the person empowered to fix it.

Examples:

a personal email-triage assistant, a one-team retrospective summarizer, a researcher's literature-search agent, a sales rep's call-prep assistant.

What it needs:

Lightweight registry entry — the user is the self-owner; Standard tooling permissions only — no custom write access to production systems; Periodic review (quarterly is fine) to confirm it's still in use and still bounded.

Failure mode:

The failure mode here is scope creep: a personal productivity agent slowly accumulates write access to customer-facing systems and quietly becomes production-critical without ever being re-tiered. The periodic review is what catches that.

The agent exists to answer a question or test a hypothesis. It was never meant to be permanent. The moment it has a permanent role, it should be re-tiered and re-launched — not silently promoted.

Examples:

a one-week prompt-engineering experiment, a data-exploration agent for a specific analysis, a proof-of-concept built for an executive demo, a sandbox agent for evaluating a new vendor.

What it needs:

Expected end-of-life date on the registry entry from day one; Sandbox isolation — no production data, no production write access; Auto-decommission when the sunset date arrives, enforced by the registry.

Failure mode:

The failure mode here is the experiment that never ends. A POC quietly becomes load-bearing. Nobody re-tiers it because nobody is paid to. The sunset date is the only thing that protects you from a science-fair artifact becoming a customer-impacting system in eighteen months.