Types of AI Agents and What Each One Costs to Supervise

The five types of AI agents in every textbook are simple reflex, model-based reflex, goal-based, utility-based, and learning agents, and the commercial world adds a dozen more labels on top: conversational, planning, collaborative, autonomous. All of those categories are real. None of them tells you the number a budget holder will ask for, which is what the agent will cost to supervise once it is running.

Our angle at LeapForce is that supervision cost, not agent type, is the variable that decides which agents you should build. Two agents with identical reasoning can differ by more than an order of magnitude in human review minutes per action, and the difference is set by five things the textbook taxonomy never mentions. A practitioner building agents for manufacturing ERP systems put the first of them plainly on Hacker News in March 2026, writing that "the biggest hurdle isn't model reasoning" but the write-access problem. Every useful action his agents needed was a database write, and no description of the agent's reasoning told his team what supervision that write required.

The short answer: Learn the five textbook types so you can read the vocabulary, then grade every agent you actually deploy on reach, exposure, approval, identity, and retention to place it in one of five containment classes from C0 to C4, because the class sets your oversight bill, and a C1 drafter routinely costs more to run forever than a properly bounded C2 actor.

Last updated: July 30, 2026.

The Oversight Card sorts any agent into one of five containment classes; the supervision bill follows the class.

One thing to state plainly up front. Nobody on our side ran a controlled trial of these five classes across a fleet of production agents, so there is no first-hand measurement here and no oversight-hours figure of our own. What follows is a cost model built from published security research, regulatory text, and how LeapForce's platform models agent identity, with every external number attributed to its source.

The two lists of AI agent types you will actually meet

Two competing lists of AI agent types are in circulation. The academic list, drawn from Russell and Norvig's Artificial Intelligence: A Modern Approach, sorts agents by how they decide; the commercial list sorts them by what they are sold to do. Neither is wrong. Mixing them is where most confusion starts.

The academic ladder has five rungs, worth knowing because every vendor glossary is downstream of it. As the Chapter 2 course material from the University of Pittsburgh puts it, simple reflex agents "select actions on the basis of the current percept, ignoring the rest of the percept history." Each rung above adds one capability: an internal model of the world, an explicit goal, a utility function scoring outcomes, and finally improvement from feedback, usually through reinforcement learning.

IBM's overview of AI agent types uses the same five and adds a sixth practical category, hierarchical agents that "break down complex problems into smaller, manageable subtasks", noting that all five "can be deployed together as part of a multi-agent system." That concession matters. If your production system contains several types at once, the type is not a property of the system you are approving; it is a property of a component inside it.

The commercial list is the one your vendors use: conversational agents, planning agents, collaborative agents, multimodal agents, autonomous agents, coding agents, browser agents, voice agents. These labels describe an interface or a job, not a mechanism. A "conversational agent" can be a scripted FAQ tree or a model with write access to your CRM. The label does not distinguish them, which is exactly the problem.

Both lists share one blind spot: neither says anything about what the agent is permitted to touch, which is what makes most published breakdowns of the types of AI agents unusable the moment you have to approve one.

What an AI agent is not: model, chatbot, workflow

An AI agent is not a model, not a chatbot, and not a workflow, and the three confusions cost real money. A model is the reasoning component. A chatbot returns text to a person. A workflow executes a path you wrote in advance. An agent wires a model to tools, memory, and a goal, then decides for itself which tools to call.

Anthropic draws the sharpest line in the field between the last two. In its engineering note on building effective agents, workflows are "systems where LLMs and tools are orchestrated through predefined code paths," while agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." In a workflow the set of possible tool calls is knowable before the run. In an agent it is not, and every control you design has to survive that. Anthropic's own advice is to resist the upgrade: find "the simplest solution possible," which "might mean not building agentic systems at all," because agentic systems "often trade latency and cost for better task performance." That is the least fashionable sentence in the agent literature and probably the most valuable one for a buyer.

Here is the practical version, expressed as the question a reviewer should ask:

The model choice is orthogonal to all three. Swapping a stronger model into a chatbot does not make it an agent. Giving a weak model a database connection and a loop does.

Why the type sets no controls and the class sets your bill

The five textbook types of AI agents are a genuine intellectual achievement and a poor procurement tool, because knowing that something is a goal-based agent rather than a utility-based one changes nothing you would write in a security review — and, more to the point here, nothing you would write in a budget. It sets no permission, triggers no approval, mandates no log, and implies no regulatory obligation. Run the consequence test on any classification: name one thing you would do differently. For the cognitive taxonomy, the honest answer is nothing.

This is not a complaint about rigour. Russell and Norvig were classifying decision procedures, and the ladder is exactly right for that. The failure is one of transplantation: it gets lifted into business content and presented as a selection framework, where it quietly stops working because the properties that determine risk were never on the ladder.

Watch what happens when you try. A simple reflex agent sounds like the safest thing on the list. Now give it one condition-action rule: if an invoice matches a supplier record, pay it. That agent can move money with no human in the path, and it is still, textbook-correctly, a simple reflex agent. Meanwhile a learning agent sounds alarming until you notice it only ranks help articles and cannot write anywhere. The taxonomy has inverted the risk order, and with it the cost order.

We have made the classification argument elsewhere and will not relitigate it here. Our earlier analysis argued that autonomy and access, not agent type, are the two axes to sort a fleet on, and a companion piece ranks use cases by blast radius rather than by department. Take that as settled. This article picks up where those stop, at the question neither answers: once you know where an agent sits, what does supervising it actually cost you, every week, forever?

That question is where agent programmes go to die. Gartner's widely reported forecast that more than 40 percent of agentic AI projects will be cancelled by the end of 2027 cites "rising costs, unclear business value, or insufficient risk controls" as the reasons, according to The Register's coverage. Two of those three are governance economics. The pilot works, the supervision bill arrives, and the business case that justified the pilot no longer clears.

One transparency note on that figure. Gartner's original press release for the prediction no longer resolves. We tried a direct fetch, a browser-agent fetch, and a full browser session, and all three returned a not-found page from gartner.com rather than the release. We are therefore citing the forecast through The Register's contemporaneous report rather than the primary document, and readers should weight it accordingly.

The security field organises its own vocabulary around consequence rather than cognition for the same reason. The OWASP Top 10 for Agentic Applications, published on 9 December 2025 and developed with "more than 100 industry experts, researchers, and practitioners," sorts risk by what an agent can be made to do: goal hijack, tool misuse, identity and privilege abuse, memory poisoning, rogue agents — not by how it reasons. None of its ten categories maps to a rung on the cognitive ladder, and each one implies a control that somebody has to operate.

The Oversight Card: five questions that price supervision

The Oversight Card is five questions you can answer about any agent in under thirty minutes, and each answer maps to a control somebody has to build once and then operate forever. That second half is the cost. The card replaces "what type of agent is this" with "what can it reach, who stands between it and the reach, and how many human minutes does that cost per action."

Question 1 — Reach. What can this agent change, and where? Four levels: reads only; drafts output a human sends; writes reversibly inside one system; writes irreversibly or across systems. Reach is the strongest predictor of everything downstream. The Hacker News commenter running an agent with production SSH access described the same split from the operator's chair: yes for reversible actions, not yet for irreversible ones.

Question 2 — Exposure. Does the agent read content it does not control? Any text an agent ingests is an instruction channel. Simon Willison's lethal trifecta names the combination to avoid: "access to your private data," "exposure to untrusted content," and "the ability to externally communicate." Combine all three and an attacker "can easily trick it into accessing your private data and sending it to that attacker."

Meta turned the same observation into a design rule. Its Agents Rule of Two holds that an agent may satisfy no more than two of three properties in a session: processing untrustworthy inputs, holding access to sensitive systems or private data, and being able to change state or communicate externally. When all three are genuinely required, the agent "should not be permitted to operate autonomously and at a minimum requires supervision." That last clause is a cost, and it is triggered by exposure rather than by capability.

This is not theoretical. In May 2025, Invariant Labs demonstrated a prompt injection against the GitHub MCP integration in which a malicious public issue coerced an agent into pulling private repository contents and publishing them in an autonomously created pull request. The flaw sits in the agent architecture, not the MCP server code, so no server-side patch fixes it. Our earlier analysis of MCP server security develops on the connector side.

Question 3 — Approval. Who stands between the decision and the action? Four grades: nobody; the owner reviews samples afterwards; a named human approves each action before it lands; two competent humans approve independently. Approval is the only control that reliably contains a class you cannot reduce.

Question 4 — Identity. Whose credentials does the agent act under? Three grades: a human's personal credentials; a shared service account; the agent's own non-human identity with a named owner, an explicit scope, and an expiry. This is where most enterprises are furthest behind. CyberArk's 2025 Identity Security Landscape, a survey of 2,600 cybersecurity decision makers, reports "82 machine identities for every human in organizations worldwide" and finds that "42% of machine identities have privileged or sensitive access", while 88 percent of respondents said their organisation's definition of a privileged user applies only to humans.

The governance gap is documented separately. The Cloud Security Alliance's May 2026 whitepaper on the non-human identity governance vacuum reports that "78% of organizations have no documented policy for creating or removing AI identities" and that "only 20% of organizations have formal processes for offboarding and revoking API keys." An agent whose credentials nobody can revoke has no upper bound, whatever its cognitive type. Our earlier piece on owner, scope and expiry for non-human identities sets out what a complete agent identity record contains.

Question 5 — Retention. What does the agent keep between runs? Three grades: nothing; task-scoped memory discarded at completion; persistent memory accumulating customer or employee data. Persistent memory turns a transient prompt injection into a durable behavioural change, which is why OWASP tracks memory and context poisoning as its own risk category.

The OWASP GenAI Security Project's launch session for the agentic list, recorded at its London summit on 9 December 2025, is the clearest 23 minutes available on why agentic security needs a different frame from model security.

The five containment classes, C0 to C4

Score the card and an agent lands in one of five containment classes. These are the types of AI agents a reviewer can actually act on, and the rule for placement is deliberately blunt: an agent takes the class of its highest axis. A read-only agent that holds persistent customer memory and reads untrusted email is not read-only in any sense that matters. Classes exist so that a reviewer, a budget holder, and an auditor can use the same word and mean the same thing.

C0 — Retriever

What it is. An agent that reads and synthesises and cannot write anywhere. Internal search over a policy library, a code-explanation assistant over your repositories, a research summariser over vetted sources.

Controls that are enough. Read-only connector scopes, source allow-listing, an audit record of what was retrieved and by whom, and a data-class boundary so the agent cannot reach material the requesting user could not reach directly.

Controls that are not enough. Assuming read-only means risk-free. An agent that reads HR records and answers questions about them is a query interface to HR records. The failure mode is over-broad read scope, not damage.

Who signs off. The system owner, once, at intake.

When to choose it. When the value is in finding and explaining and a human already does the acting. Most first agents should be C0; most organisations skip straight past it.

C1 — Drafter

What it is. The agent produces an artifact (an email, a ticket reply, a pull request, a contract redline) that a human reviews and sends. The human is the actuator, which is a control and not a formality.

Controls that are enough. Everything in C0, plus provenance labelling on generated content, and a review surface that shows the human what changed rather than only the final text.

Controls that are not enough. Approval theatre. If a reviewer approves forty drafts an hour, the approval has become a click, and EU regulators name this failure directly by requiring that overseers can recognise "automation bias" risks. Measure your reviewers' rejection rate; a rate near zero means you have a C2 agent wearing a C1 label.

Who signs off. The system owner plus the team whose name goes on the output.

When to choose it. When output quality is contested, the work is customer-visible, or you need a period of evidence before granting write access.

C2 — Scoped actor

What it is. The agent writes, but inside one system, through a fixed list of actions, and every action is reversible. Reclassifying a ticket, applying a CRM tag, opening a draft record, updating an internal status field.

Controls that are enough. Its own non-human identity with a named owner and an expiry, an explicit action allow-list rather than broad API scope, rate limits, an idempotency strategy on every write, and a tamper-evident action log. Idempotency is the one teams underestimate: many business systems accept no idempotency key, so the fallback is a duplicate check the agent must pass before the write lands. The HN practitioner building agents for manufacturing ERPs called out exactly this, worrying that a hallucinated retry could produce double-ordering. That concern belongs to the class, not to the model.

Controls that are not enough. Read-scope thinking. Teams routinely grant a broad integration token because the action list is short, which means the agent's real reach is the token's reach, not the allow-list's.

Who signs off. System owner plus a security reviewer. This is the first class that needs a second pair of eyes at design time.

When to choose it. When the action is high-volume, low-value-per-instance, and cheaply undone. This is where most genuine automation return sits.

C3 — Cross-system actor

What it is. The agent writes in two or more systems, so its actions compose: reading a support ticket, updating the CRM, provisioning an account. Composition is what makes this class different, because two safe actions in sequence can produce an unsafe outcome neither one contains.

Controls that are enough. Everything in C2, plus credential brokering so the agent never holds long-lived keys, a human approval gate on the irreversible subset of its action list, egress control on anything leaving the company, and a trace that reconstructs a full run rather than logging individual calls. Our earlier work on audit trails that prove agent actions covers what a defensible trace has to contain.

Controls that are not enough. Per-system review. Each connector passing its own review says nothing about the combination, and the combination is the risk. Review the run, not the tools.

Who signs off. System owner, security, and the data owner for every system in scope.

When to choose it. When the process genuinely spans systems and the handoffs are where the time goes. If one system holds 80 percent of the work, build a C2 agent there and leave the handoff to a person.

C4 — Principal actor

What it is. The agent acts as a principal in its own right: it moves money, deletes data, sends externally on its own authority, or operates in a domain the EU AI Act treats as high-risk. Payment execution, production infrastructure changes, unreviewed customer communication, credit or hiring decisions.

Controls that are enough. Everything in C3, plus a named human approver per action, dual control where regulation demands it, a documented stop procedure, spend and rate ceilings enforced outside the agent's own logic, and an evidence trail built for an external auditor rather than for engineering.

Controls that are not enough. Model-level guardrails. A prompt instructing the agent not to exceed a limit is not a limit. Ceilings that live in the same context the agent can be talked out of are not ceilings.

Who signs off. Executive owner, security, legal or compliance, and, where Annex III applies, whoever will answer the regulator.

When to choose it. Rarely, late, and only after the same process has run at C3 long enough to produce evidence. Organisations that build a C4 agent first usually build it because it demos well.

What each class costs you in oversight

Oversight cost rises faster than capability across the containment classes, and it is the number most agent business cases omit. The cost is not model spend. It is human minutes per agent action, the review surfaces someone has to build, and sign-off calendar time before anything ships, and it compounds with volume in a way licence costs do not.

We will not invent numbers for it, because the honest answer depends on your volumes and your reviewers' loaded cost. What we can do is name the cost drivers per class so a finance partner can price them against real internal figures.

The arithmetic that matters is one line, and you can run it on the back of an envelope before anyone writes code:

Weekly oversight hours = actions per week x review rate x minutes per review / 60.

Everything the class system does is move one of those three terms. Reach and approval set the review rate. Exposure and retention set the minutes per review, because a reviewer weighing whether an input was adversarial takes longer than one checking a field value. Identity sets neither directly, but a missing identity makes the review impossible to target, which is worse.

Put plausible internal figures into that line and the classes separate immediately. Take an agent handling 2,000 actions a week. At C1 with a 100 percent review rate and two minutes per artifact, that is roughly 67 hours a week: more than one and a half full-time people, forever, to supervise one agent. Move the same work to a properly bounded C2 with a 5 percent sampled review and it costs about 3.3 hours a week. The agent did not get smarter. The class changed, and with it the review rate.

Those inputs are illustrative rather than measured, so get your own before quoting the result to anyone. They are cheap to obtain: time a two-week sample of the reviewers already doing the work, and count the actions the agent would have taken over the same period. What is not negotiable is the shape. The cost is dominated by a term the agent's cognitive type does not touch, and the review rate is a policy choice rather than a property of the technology. None of this prices the benefit. The class tells you what the supervision side of the ledger costs, and you still have to put a number on the other side.

Three patterns fall out of that model, and all three contradict the usual advice.

C1 is often more expensive to run than C2. A drafter needing full human review of every artifact costs reviewer time proportional to volume forever. A scoped actor with sampled review costs a fixed fraction of it. Teams stay at C1 because it feels safer and pay more for it indefinitely.

Read that carefully, because it is the sentence most easily misused. It is not an argument for removing the human because the human is expensive. The C2 move is only available when two conditions hold: every action on the list is genuinely reversible, and the list is genuinely enumerable in advance. If either fails, C1 is the correct class and the reviewer time is the price of the work, not waste. Teams that skip those preconditions because the arithmetic looked good are the ones that end up in an incident review.

The C3-to-C4 step is a step, not a slope. Everything up to C3 is engineering, and engineering costs fall as tooling improves. C4 adds legal review, external-auditor evidence, and control testing, which are calendar costs no tooling compresses. Budget the jump as a project with its own approval, not as an increment on an existing one.

Volume, not risk, makes oversight unaffordable. A C4 agent doing five actions a week is cheap to supervise even with dual control. A C1 agent doing fifty thousand is not supervisable at all at a 100 percent review rate. Most teams size controls against the worst case and then discover the bill is set by the common case.

This is, we suspect, a large part of why agent programmes stall. When the cost of oversight is discovered after the pilot rather than priced into it, the business case that justified the pilot no longer clears — which is close to what Gartner's cancellation forecast attributes to "rising costs" and "insufficient risk controls." We wrote separately about the pattern in why AI pilots stall before production.

There is a capability term in this too, and it is unflattering. Carnegie Mellon and collaborators built TheAgentCompany, a benchmark of professional tasks inside a simulated software company, and found that "the most competitive agent can complete 30% of tasks autonomously." Models have moved since those runs and nobody should treat 30 percent as today's ceiling. But if anything close to that share of attempts needs human repair, the oversight term is not a safety tax on top of the work. It is most of the work, and a business case modelling it as a rounding error is modelling the wrong thing.

One agent, three classes: a worked example

Take one helpdesk agent, change nothing about its model, prompt, or cognitive type, and it passes through three containment classes with three completely different control sets and three completely different supervision bills. In Russell and Norvig's terms it is a goal-based agent at every stage.

Stage one, C0. It reads the ticket queue and the knowledge base and suggests the three most relevant articles to a human agent. Reach is read-only. Exposure is mixed, because ticket text comes from customers. Approval is not required because nothing is actuated. Retention is nothing. Controls needed: read scopes bounded to the requesting agent's own permissions, plus a retrieval log.

Stage two, C2. The same agent applies a category tag and sets a priority field. Reach becomes reversible write in one system. Two controls appear immediately: an action allow-list containing exactly set-category and set-priority, and its own identity with an owner and expiry so the write is attributable and revocable. A third appears on inspection. The agent reads customer-authored text and writes based on it, so a customer can now influence ticket priority by asking. Small, acceptable, and it belongs in the record.

Stage three, C4. The same agent issues refunds under a threshold. Reach becomes irreversible and financial, and the exposure that was acceptable at C2 is now the dominant risk, because customer text sits directly upstream of a money-moving action. On Meta's rule of two the agent holds all three properties at once, so autonomous operation is out. The control set changes shape rather than growing: a per-refund human approval, a spend ceiling enforced by the payment system rather than the agent, and an evidence trail a finance auditor can read.

Notice what the last column does. It is constant, and it is useless. That column is what most breakdowns of the types of AI agents are actually about. The review-rate column beside it is the one that decides whether stage three is affordable, and it moved from zero to one hundred percent while the cognitive type stayed exactly where it was.

Run the card in one sitting: a 30-minute intake

You can classify an existing agent in about thirty minutes with the people who built it, and the output is a one-page record that survives handover. Do it as a conversation, not a form, because the interesting answers arrive when someone says "well, technically it can also…".

1. List the tools, not the capabilities (5 minutes). Ask for the literal set of tool definitions or API scopes the agent holds. Not what it does — what it can call. Anthropic's guidance that tool definitions deserve "just as much prompt engineering attention as your overall prompts" cuts both ways: definitions vague to the model are vague to you.
2. Grade Reach on the worst tool (5 minutes). Find the single most destructive call and grade on that. One delete endpoint in a list of forty reads makes the agent a writer.
3. Trace the untrusted input path (5 minutes). Name every text source entering the agent's context that your organisation did not author: customer messages, web pages, third-party documents, repository contents, external calendar invitations. If the list is empty, check again.
4. Find the actuator (5 minutes). Ask who or what causes the action to land. If the answer is "the agent, unless someone notices", approval grades at none regardless of the design document.
5. Ask whose key it is (5 minutes). Whose credentials appear in the target system's audit log? If a person's name shows up when the agent acts, identity is at its lowest grade, and offboarding that person will either break the agent or leave it running with a ghost.
6. Ask what survives the run (5 minutes). Memory, caches, vector stores, transcript archives. Anything persisting customer data raises retention and usually raises the class.

Then write the record. Six fields, one page, and the class it produces:

The record's real job is re-review. Agents drift upward: someone adds a connector, someone widens a scope, and the class changes silently. Put the expiry date on the identity and the class gets looked at again by construction rather than by discipline.

Where regulation attaches to use, not to type

No regulator asks what type of AI agent you deployed. The EU AI Act attaches obligations to the use context, which maps far more closely to containment class than to cognitive architecture, and the same is true of the voluntary frameworks auditors actually work from.

Article 14 of the EU AI Act requires that high-risk systems be designed so they "can be effectively overseen by natural persons during the period in which they are in use," and that overseers be able to "intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state." Read as a control specification, that is a C3-and-above requirement: a documented stop procedure and a human with authority to use it. For biometric identification under Annex III point 1(a), Article 14 requires that no action be taken unless the identification "has been separately verified and confirmed by at least two natural persons". That is dual control, written into law, attached to a use case rather than to an agent type.

The use cases that trigger high-risk status sit in Annex III and are ordinary business domains, not exotic ones: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and administration of justice and democratic processes. An agent that screens CVs is in scope. The same agent architecture summarising internal documents is not. Type identical, obligation completely different. We went through the deployer-side obligations and dates in our EU AI Act guide for AI deployers.

The voluntary frameworks push the same way. The NIST AI Risk Management Framework organises work into four functions, GOVERN, MAP, MEASURE and MANAGE, where GOVERN "cultivates and implements a culture of risk management" and MAP "establishes the context to frame risks related to an AI system." Context, not architecture. NIST's separate taxonomy work in AI 100-2 E2025 on adversarial machine learning, published March 2025, likewise classifies by attack lifecycle stage and attacker capability rather than by the target's agent type. ISO/IEC 42001 follows the same management-system logic, though we could not quote it: the ISO site refused all three of our fetch attempts, and we will not paraphrase a paywalled standard from secondary sources.

The practical consequence is that your containment class is close to an audit-readiness score. Produce the six-field record for every agent and you have most of what a MAP-function inventory asks for. Fail to name the owner of an agent that writes to a regulated system and no description of its reasoning will help.

Agent washing: telling a real class change from a new label

"Agentic" has become a marketing prefix, and the containment classes are the cheapest test for whether a product genuinely changed. Gartner's term is agent washing: rebranding assistants, robotic process automation and chatbots "without substantial agentic capabilities", with the firm estimating only about 130 of the thousands of self-described agentic AI vendors are real, as reported by The Register. A commenter on that story put the buyer's question better than the analysis did, asking what differentiates "real agentic" from "slapped IFTT and an LLM together".

The class framing answers it. A product has genuinely changed class if it changed one of the five axes. Ask the vendor:

• Reach. What can it write, in which systems, through which specific actions? "It integrates with Salesforce" is not an answer; "it can call these four Salesforce actions" is.
• Exposure. What untrusted content enters the agent's context, and what stops that content from being read as instructions?
• Approval. Is there a supported human approval gate, on which actions, and can we configure which?
• Identity. Does the agent get its own credential, or does it act as the connecting user? If the latter, your audit log will show a person doing things they did not do.
• Retention. What persists between sessions, where, and under whose retention policy?

Three of those five are capability the vendor must build, not configure. A product answering "it depends on your setup" to all five has not changed class; it has changed its landing page.

The capability side deserves the same scepticism, and the published numbers are specific. Reporting on TheAgentCompany results recorded a best score of 30.3 percent of tasks fully completed and 39.3 percent with partial credit, with other leading models lower — Claude 3.5 Sonnet at 24 percent, GPT-4o at 8.6 percent, per The Register. Ask any vendor selling autonomous agents which of those numbers their product beats, on what task set.

The security data points the same way. OWASP's reporting, summarised by Help Net Security, maps prompt injection to six of the ten agentic Top 10 categories and traces the concentration of incidents to coding agents, 28 of 53 tracked projects. Coding agents are C3 or C4 almost by definition: they read untrusted repository content, hold credentials, and write across systems. The incident distribution is a class distribution.

When the classical taxonomy still wins, and where ours is weak

The Oversight Card is a budgeting and governance instrument, not a design instrument, and it is genuinely the wrong tool for several real jobs. We would rather say where it fails than let a reader discover it.

When the classical taxonomy still wins. If you are choosing an architecture rather than approving a deployment, the cognitive ladder is exactly the right vocabulary. It tells you whether you need state, planning, a scoring function, or feedback, and those are real engineering decisions with real costs. If you are teaching, or reading research, the textbook types are the shared language and ours is not. And if your system genuinely is a single deterministic reflex loop, the containment card will grade five axes to tell you what one glance already told you.

Where our framework is weak. Four honest limits:

The classes are ours, not a standard. Nobody outside this article uses C0 to C4. It will not appear in an audit template or a vendor questionnaire, so use it to get organised and then translate. If your auditor wants NIST AI RMF function coverage, give them that. We have also published an adjacent four-level autonomy-and-access grid; if your teams already use that one, keep it, because a second vocabulary for the same idea costs more than it earns.

The cost model is a shape, not a benchmark, and we have not run the counterfactual. The weekly-hours formula holds by construction, but we have not measured real review rates across a population of deployments and neither, as far as we can find, has anyone else. The 2,000-action example is arithmetic on assumed inputs; if someone quotes our 67 hours back at you as a finding, they have misread us. Nor can we show that teams using this card have fewer incidents than teams using the textbook types. The argument is analytical, not empirical.

Highest-axis placement is deliberately crude. An agent with persistent memory and read-only reach lands at the same class as one with reversible writes and no memory, and those are not the same risk. The crudeness stops teams negotiating themselves downward, but it will over-classify some agents and someone will have to make a judgement call.

Multi-agent systems break the card. When one agent calls another, the effective reach is the union of everything downstream, and nobody has a clean way of grading that yet. OWASP tracks insecure inter-agent communication as its own risk for exactly this reason. Our best current advice is to grade the whole system on its worst leaf and accept that this is unsatisfying.

One more honest exclusion. Vendor surveys put the non-human-to-human identity ratio anywhere from 45:1 to 144:1, varying so much between sources that we have cited only the CyberArk and Cloud Security Alliance figures, which we could fetch and attribute directly. The spread itself is the finding: nobody has a reliable enterprise-wide count of their machine identities, which is precisely the governance problem.

Where the class shows up in your stack

Containment class is only useful if something enforces it, and enforcement lives in infrastructure rather than in the agent. This is the layer LeapForce builds: one controlled path every AI tool, connector, model, and agent goes through, so an agent's class is a property of the platform rather than a promise in a design document.

The five card axes map to five places. Reach is connector scoping — a vetted registry with action-level rather than API-level permissions. Exposure and egress are handled in the request path at the AI gateway, whose per-request lifecycle runs Identify, Check, Protect, Route, Execute, Record. Approval is a human gate inside a workflow. Identity is the one we are most opinionated about: on our access and identity layer, every agent and workflow runs under its own identity with a named human owner, an explicit scope, and an expiry, because unowned automation is where the governance gaps start. Retention shows up as data-class boundaries and audit records. LeapForce publishes per-capability build status openly. Some of this ships today, some is in development, and the honest read is that the identity and gateway layers are the mature parts.

Our own rollout guidance follows the same logic and is deliberately unglamorous: Observe first. Enforce second. Optimize third. Point traffic at the gateway in observe mode until you know what is actually running, turn on protection, then apply enforcement rules learned from the observation rather than guessed. Most organisations start at enforcement, discover they were guessing about their own estate, and stall. To be clear about the limit: LeapForce does not build your agents, and no governance layer makes a poorly scoped agent useful. It makes the scope enforceable and the actions provable, which is a different job.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.