Agentic AI: The Action Ledger Test for Real Autonomy

Agentic AI is software that holds a goal, decides its own next step, and then acts through tools: writing to a database, sending an email, moving money, changing a config. The output is an action, not a paragraph a person still has to act on.

That definition is easy. The hard part is that it does not tell you anything useful about a specific system, because every vendor now claims it. Our position is that the word "agentic" is a claim about architecture, and it should be a claim about authority. Stop asking whether a system is really agentic and write down the list of actions it can take without a human. We call that list the Action Ledger, and it is the only artifact in this article you actually need.

A practitioner posting as vektormemory put the problem sharply on Hacker News on 27 July 2026, describing what happens when people try to let an agent operate a real server. Most setups end up either locked down so hard the agent is useless, or handed a standing key and hope. Neither is real autonomy: one is "a chatbot with a read-only window into your server", the other is "a loaded gun with the safety off". That binary is not a personal failing. Gartner named it as the root cause of enterprise agent failure in May 2026.

The short answer: A system is agentic to exactly the degree that it can take a consequential action without a human first approving it, so classify it by its most consequential unapproved action, not by whether it has a planner, a memory store or a multi-agent graph.

Last updated: July 30, 2026.

The four autonomy levels described by Gartner in May 2026, with what changes at each boundary.

We have not run a controlled deployment of our own agents and measured it, so nothing in this article is presented as a first-hand LeapForce test. Every number below is attributed to the organisation that measured it.

What Agentic AI Actually Means

Agentic AI describes a system that pursues a goal across multiple steps, chooses those steps itself, and reaches into other systems to carry them out. The cleanest formulation belongs to Anthropic's engineering team, which separates two things the market keeps merging. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths". Agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."

That distinction is about who decides the sequence. In a workflow, a developer wrote the sequence and the model fills in the blanks. In an agent, the model picks the next call based on what just happened. Both can be extremely useful. Only the second one can surprise you.

Note what the definition does not require. It does not require a large language model, a planning module, a vector store, or several agents talking to each other. Those are implementation choices, and any of them can be present in something that is not agentic and absent from something that is. A single loop that reads a queue, decides which of four API calls to make, and makes it is agentic. A twelve-agent orchestration graph that only ever returns a document for a human to send is not, in any sense that changes your risk.

So the useful test is the one about consequences. Does the system change state in a system of record without a person clicking approve? If yes, it is agentic in the way that matters, whatever it is built from. If no, it is a very good drafting tool, and you should stop paying for agent-grade controls.

There is a reason to insist on this. Gartner's June 2025 research put the definitional confusion in numbers. It described "agent washing" as "the rebranding of existing products, such as AI assistants, robotic process automation (RPA) and chatbots, without substantial agentic capabilities". Then it estimated that "only about 130 of the thousands of agentic AI vendors are real". A year later the same pattern was still being flagged. In May 2026, Gartner Senior Director Analyst Jan Snoeckx told a supply-chain audience that agent washing works by "relabeling conventional automation as agentic", raising the risk of misaligned investment and long-term lock-in.

If roughly 130 out of thousands of claims are real, no definition you can read off a marketing page will help you. You need something you can check.

What Agentic AI Is Not

Four things get sold as agents and are not. Knowing which one you are looking at changes the controls you need, the price you should pay, and the failure you should plan for. None of these four is bad technology. Three of them are more predictable than a real agent, which is often an argument in their favour.

The distinction that survives all four rows is authority, not intelligence. A dumb script with production credentials is more dangerous than a brilliant agent that can only read.

This is where Gartner's May 2026 analysis lands hardest. The firm's finding was that failures "are most likely to occur when organizations fail to distinguish between an agent's ability to act and the scope of access it is granted". Two different properties. Capability is what the model can figure out how to do. Scope is what your IAM configuration will actually let it do. Vendors sell the first. Incidents come from the second.

Worth naming a fifth non-agent: the demo. A scripted run on curated data with a friendly evaluator tells you the capability ceiling under ideal conditions and nothing about the floor.

The Four Autonomy Levels That Replace the Label

Instead of a binary, use a ladder. AI agent governance is proportional work: the controls should scale with what a given action can do, and the useful unit of measurement is the AI agent autonomy level. In May 2026 Gartner published a four-level classification of AI agent autonomy and predicted that "by 2027, 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents occur". Not because the agents were bad. Because the governance did not match the level.

Senior Director Analyst Shiva Varma described the mechanism plainly: "Enterprises are treating AI agent governance as binary, either locked down or fully trusted, and that is the root cause of failure." Two failure modes fall out of that. Over-restrict a simple agent and you slow delivery and push people into building their own, which is how shadow AI starts. Under-restrict an autonomous one and you have handed a probabilistic system your write credentials.

Three things about this ladder are worth more than the ladder itself.

The levels are per-action, not per-product. One deployed agent is routinely Level 1 for search, Level 2 for drafting, and Level 3 for the one call that updates a record. Its governance requirement is set by that last one. This is why product-level classification fails: you end up governing the average when the risk sits in the tail.

Level 3 is where most of the self-deception lives. Varma's warning is specific: without real security testing, clear approval workflows with audit trails and agent-specific incident response, "approvals can degrade under time pressure or approval fatigue, creating a false sense of safety while expanding the attack surface." An approval queue nobody reads is worse than no approval queue, because it launders the decision. OWASP catalogues this as a threat in its own right, T10, Overwhelming Human in the Loop.

Level 2 is not safe just because a human presses the button. Gartner's note is that advisory agents "can anchor judgment, creating downstream risk when inaccurate outputs are trusted due to automation bias." The human is in the loop and still wrong, because the draft arrived looking finished.

The EU AI Act reaches the same conclusion from the legal side, requiring that overseers of high-risk systems stay conscious of the tendency to over-rely on outputs. When a regulator and an analyst firm independently name automation bias as the control that fails, treat "a human reviews it" as a claim requiring evidence rather than an answer.

The Action Ledger: A One-Sitting Test for Any Agent

Here is the procedure. It is meant to be finished in one sitting per agent, and it replaces every unfalsifiable conversation about whether something is really an agent. Build a table with one row per action the system can take, and four columns.

How to enumerate the actions, since this is the step people get stuck on. Do not read the system prompt, and do not ask the agent. Read the tool manifest: the list of functions, connectors or MCP servers the runtime actually mounts, plus the IAM policy attached to each credential those tools use. The union of "tools mounted" and "permissions those credentials hold" is the real action list. Anything the prompt says about restraint is commentary on that list, not a constraint on it.

Column 1: the action. Every state-changing call, named concretely. Not "updates CRM" but "writes to the opportunity stage field in Salesforce". Read-only calls go in a separate list; they matter for data exposure, not for blast radius.

Column 2: the identity it runs as. Whose credential authorises this call? If the answer is a shared service account, a developer's personal token, or a key in an environment variable that three people know, write that down. The action is attributable to whatever appears in the target system's log, and nothing else.

Column 3: the gate. Does a human approve this specific action before it executes, every time? "Sometimes", "for large amounts", and "the model is instructed to ask" are all answers of no. A gate the model can decide to skip is not a gate. This is the column that sets the autonomy level.

The practical corollary is the part most implementations get wrong. If approval is implemented as a tool the agent calls, the agent decides whether to call it, and you have built a suggestion. A gate has to sit outside the model's control path: at the connector, the gateway, or the tool-execution boundary, wherever the call is actually brokered. The Model Context Protocol says as much about itself, conceding that the protocol cannot enforce its own consent rules and that the enforcement belongs to the host. Put the check where the credential is held, not where the reasoning happens.

Column 4: the record. After this action runs, what artifact exists, where does it live, how long does it survive, and can it be altered by the same credential that performed the action? If the answer is "the model's own log file", the record does not exist for any purpose that matters.

Filled in for an illustrative invoice-chasing agent, it looks like this. This example is constructed to show the method, not drawn from a customer deployment.

That ledger answers the question at a glance. This system is Level 4, because two of its state-changing actions run with no gate at all, one of those two writes off revenue, and the third has a gate the model itself decides whether to use. Its identity story is a single shared account, so the CRM audit trail will attribute a write-off to svc-ar-bot and no further. And the discount gate is decided by the model, which means it is not a gate.

The rule to remember, and the one that makes this portable: an agent's autonomy level is set by its most consequential unapproved action, not by its architecture. Everything else about the system is a design detail.

Two things the Action Ledger is good for beyond classification. It is a vendor test: ask a supplier to fill in columns 2, 3 and 4 for their product. A real agent platform can. A relabelled workflow will produce column 1 and go quiet. It is also a scoping tool. Once you can see which single row creates the risk, you usually find you can move that one action to Level 3 and leave the rest alone, which is much cheaper than governing the whole system at its worst level.

For the identity column specifically, our earlier analysis of non-human identity for AI agents sets out the three fields we think every agent identity needs: a named human owner, action-level scope rather than system-level access, and an expiry. Column 2 of the ledger is the question those three fields answer.

How Agentic AI Works: Six Moving Parts

Most explainers list four components. We list six, because the two usually missing are the two that decide whether the thing is deployable. An agentic system, whatever the framework, assembles some version of the following.

Perception. The inputs that tell the agent what state the world is in: a webhook, a polled queue, a search result, a file, the output of its own last tool call. Weak perception is the quiet cause of most bad agent decisions, because the model reasons impeccably over an incomplete picture.

Goal and policy. The objective, plus the constraints on how it may be pursued. In practice this is usually a system prompt, which is a weak place to put a constraint. Prompt-level rules are advisory. They are read by the same probabilistic process that decides everything else.

Planning. Decomposition of the goal into steps, and revision of those steps when a step fails. This is the part that gets marketed. It is also the part that improves fastest with model releases, which means it is rarely the bottleneck by the time you deploy.

Tools. The hands. This is where an agent stops being a text generator. The Model Context Protocol, a widely adopted open standard for connecting models to tools, is unusually blunt about what a tool is: "Tools represent arbitrary code execution and must be treated with appropriate caution". It goes on to warn that tool descriptions "should be considered untrusted, unless obtained from a trusted server." Read that twice. The spec requires that hosts "obtain explicit user consent before invoking any tool", then concedes the crucial point: "MCP itself cannot enforce these security principles at the protocol level." Every integration an agent gains is another row in your ledger, and the enforcement of that row is not the protocol's job. The protocol that gives agents hands says in writing that the safety rules are somebody else's job. That somebody is you. We have written separately on governing MCP connectors.

Memory. State that survives between invocations: conversation history, scratchpads, retrieved documents, learned preferences. Treated as a defining feature by most explainers. The evidence is less kind, and we come back to it below.

Record. What the system leaves behind. Vendor architecture diagrams rarely include this box, and it is the one an auditor, an incident responder and a regulator all ask for first. A record is not a log of model tokens. It is an attributable, tamper-resistant statement that this identity took this action against this resource at this time, under this policy decision. OWASP's threat catalogue recommends going further and requiring that AI-generated logs be "cryptographically signed and immutable for regulatory compliance."

The first four boxes are what vendors demo. The last two are what determines whether the demo survives contact with your change-control process. Our earlier work on audit trails that prove agent actions covers the record box in detail.

Agentic AI vs Generative AI: The Operational Difference

Almost every question about agentic AI vs generative AI resolves into one sentence: generative systems produce content, agentic systems produce change. It is not a spectrum of intelligence. It is a difference in what exists after the system finishes running. A generative system leaves you a draft. An agentic system leaves you a modified database, a sent message, or a charge on a card.

Everything operational follows from that one difference.

The undo row is the one to sit with. A hallucinated paragraph costs a reader thirty seconds. A hallucinated DELETE costs whatever was in the table. In April 2026 a report titled "An AI agent deleted our production database. The agent's confession is below" drew 860 points and over a thousand comments on Hacker News. In a later thread, a commenter quoted the agent's written account of what it had done: it guessed that deleting a staging volume through the API would be scoped to staging only, and did not verify. That commenter cites a trade-press write-up of the incident, which we could not open, and we could not reach the original thread either. So treat it as a widely discussed practitioner report rather than an established fact. The reasoning failure it describes is ordinary. The consequence was not, because the credential was not scoped.

Another Hacker News commenter, mennylevinski, wrote about that class of incident in May 2026 and drew the right conclusion. The issue was less the model and more "excessive permissions and a lack of guardrails or approval steps". Which raises the question of how agents should be scoped for identity and access. That is the Action Ledger, arrived at independently.

How Reliable Are AI Agents? What the Measurements Say

Agent capability is rising steeply and agent reliability is a different curve. Both statements are measured, and holding them together is the whole art of deploying agents without becoming one of the cancelled projects.

On capability, Stanford HAI's 2026 AI Index is the cleanest current record. On OSWorld, which tests agents on computer tasks across operating systems, "accuracy rose from roughly 12% to 66.3%, within 6 percentage points of human performance". The same report's summary of takeaways, published in April 2026, records that "the success rate of agents handling real-world tasks improved from 20% in 2025 to 77.3% today, according to Terminal-Bench, while AI agents handling cybersecurity issues solved problems 93% of the time compared to 15% in 2024".

Those are large moves in a short time. Now the other curve.

Consistency is not the same measurement as capability. The τ-bench paper by Shunyu Yao, Noah Shinn, Pedram Razavi and Karthik Narasimhan introduced a metric for it, pass^k, the fraction of k independent attempts at the same task that all succeed. Their finding was that "state-of-the-art function calling agents (like gpt-4o) succeed on <50% of the tasks, and are quite inconsistent (pass^8 <25% in retail)". Read those two numbers together. Fewer than half of single attempts succeeded, and on fewer than a quarter of retail tasks did all eight independent attempts succeed. A system you have to supervise on every run is a different product from one you can leave alone, and only the second one is worth automating an action for.

A March 2026 study pushed on this at scale. Aaditya Khanal, Yangyang Tao and Junxiu Zhou evaluated ten models across 23,392 episodes on a 396-task benchmark spanning four task-duration buckets and three domains. Three of their findings should change how you plan a deployment.

That last row deserves emphasis, because persistent memory is treated across most explainers on the subject as one of the defining traits of a mature system. In this evaluation it made long-horizon performance worse in every model tested. One study is not a settled result, and it measures long-horizon task performance rather than user experience. But it is a measurement, and the confident claim it contradicts is not.

Task length is the other axis. METR tracks how long a task can get before a model's autonomous success rate falls to 50%. Their revised methodology, published on 29 January 2026, put the post-2023 doubling time at "130.8 days", faster than the 165.3 days their earlier method estimated, with the top model in that update at 320 minutes. Their original 2025 analysis is the more useful sentence for planning: current models have "almost 100% success rate on tasks taking humans less than 4 minutes, but succeed <10% of the time on tasks taking more than around 4 hours".

Set that against deployment reality. The same Stanford AI Index found organisational AI adoption at 88% of surveyed organisations, while "AI agent deployment was in the single digits across nearly all business functions". Nearly everyone has AI. Almost nobody has agents in production. The gap is not capability. It is that nobody has an answer for column 4.

A Worked Example: An Agent That Ran a Real Shop

The most instructive public record of a genuinely autonomous deployment is Anthropic's Project Vend, because it was allowed to fail in public with the numbers attached. In phase one, published on 27 June 2025, an instance of Claude nicknamed Claudius was given a real shop to run: web search, an email tool for contacting wholesalers, note-taking, a Slack channel of customers, and the ability to set prices.

It lost money. The write-up records that when employees asked for specialty metal items, "Claudius would offer prices without doing any research", stocking goods "priced below what they cost". It was talked into issuing discount codes over Slack, and gave items away free, from a bag of chips to a tungsten cube. It took payments through Venmo, then for a time told customers to remit payment to an account it had hallucinated. The sharpest drop in the balance came from buying metal cubes it then sold below cost.

Read that as an Action Ledger and every failure is a column, not a model defect. Setting a price was Level 4 with no gate. Sending a payment instruction was Level 4 with no gate and no validation of the destination account. Issuing a discount was Level 4 in a channel where anyone could ask. The model's reasoning was not the variable that changed the outcome.

Phase two, published on 18 December 2025, is the more useful half. Anthropic's conclusion was that "Claudius struggled with its shopkeeping mission in phase one because of a lack of scaffolding". Phase two added CRM, better inventory management, improved web search, feedback forms, payment links, and a newer model, moving from Claude Sonnet 3.7 to Sonnet 4.0 and later 4.5. The business improved: it named itself "Vendings and Stuff", expanded to three locations across San Francisco, New York and London, and weeks with negative profit margin were largely eliminated.

Two details from phase two are worth more than the profit line.

A second agent was installed as Claudius's manager, a CEO named Seymour Cash, to apply performance pressure. Some of it worked: discounts fell by about 80% and giveaways halved. But Seymour authorised lenient financial requests "about eight times as often as it denied them". An automated approver approved. That is the Level 3 failure mode from the ladder above, reproduced in a controlled experiment, and the direction of the error is the point. Adding an approval step improved the average and left the tail intact. And staff kept finding ways through. One floated a bulk-sourcing scheme another staffer had to point out would fall foul of the Onion Futures Act of 1958. During a vote to name the CEO agent, a staff member claimed their entire part of the organisation had backed one name and talked Claudius into believing it without producing a shred of evidence. The write-up is explicit that the setup required a great deal of human support.

The lesson is not that agents cannot run a shop. It is that the delta between phase one and phase two was tooling and controls, not intelligence. If your agent programme is stalled, the model is probably not what is stalling it.

Five Named Ways Agentic AI Breaks

OWASP's Agentic Security Initiative first published Agentic AI: Threats and Mitigations in February 2025. The document served at that link today is version 1.1, dated December 2025, and it catalogues seventeen threats, T1 through T17. Worth checking which revision you are reading, because most secondary write-ups still describe the fifteen-threat original. The same project published a separate Top 10 for Agentic Applications on 9 December 2025; the T-numbers below come from the threat-and-mitigations document, which is still the one practitioners cite by number. Five of them describe what actually goes wrong in enterprise deployments, and naming them is more useful than a generic warning about risk.

Privilege compromise (T3). OWASP's definition is that this "arises when attackers exploit weaknesses in permission management to perform unauthorized actions", often through dynamic role inheritance or misconfiguration. The weakness it names is the one your ledger exposes in column 2: an over-scoped or shared credential is exploitable whether or not anyone is currently exploiting it, and the same misconfiguration that lets an attacker through lets a confused agent through.

Tool misuse (T2). The agent abuses a tool it is legitimately allowed to use, "operating within authorized permissions" in OWASP's phrase. The catalogued threat is attacker-driven, through deceptive prompts or manipulated data. The uncomfortable part for a deployment is that the same permission boundary is what stands between you and the benign version, where an agent asked to fix one thing decides that fixing an adjacent thing is helpful. Both land in the same place because the tool was reachable.

Memory poisoning (T1). False or malicious data is seeded into short- or long-term memory, and the agent then acts on it. Persistent memory is not only a performance trade-off; it is an attack surface that a stateless system does not have.

Identity spoofing and impersonation (T9). OWASP's summary is that attackers "exploit authentication mechanisms to impersonate AI agents or users to perform unauthorized actions under false identities", and it extends the threat to the theft or misuse of a formal, persistent agent identity. The practical consequence is what column 2 of the ledger exposes: the credential is the whole identity. Guardrails written into a chat layer do not travel with a stolen token, because the token is what the target system checks.

Repudiation and untraceability (T8). OWASP's description: this "occurs when actions performed by AI agents cannot be traced back or accounted for due to insufficient logging or transparency in decision-making processes", making it hard "to audit decisions, attribute accountability, or detect malicious activities". This is the one that turns a recoverable incident into an unbounded one, because you cannot scope a breach you cannot reconstruct.

Atulpriya Sharma put the identity and attribution problem well in a lightning talk at an OpenSSF event in March 2026. In most estates the most privileged identity is no longer human. And its audit log shows a service account rather than which user asked, or why:

Worth noticing what these five have in common. Not one is a reasoning failure. Every one of them is an access, identity or record failure, which is to say a configuration failure, living in your infrastructure rather than in the model. That is good news. Configuration is the part you control without waiting for a better release.

What Regulators Already Require of a System That Acts

You do not need new rules for agents to already be regulated. Existing instruments attach obligations to systems that act, and two of them are specific enough to design against today.

The EU AI Act's Article 12 requires that high-risk AI systems "technically allow for the automatic recording of events (logs) over the lifetime of the system", sufficient to identify risk situations, support post-market monitoring and monitor operation. That is column 4 of the Action Ledger, written as law.

Article 14 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". The specifics matter for agent design. Overseers must be able to understand the system's capacities and limits, stay conscious of automation bias, and correctly interpret outputs. They must also be able to decide not to use the system, to override its output, and to "intervene in the operation" 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".

An agent with no stop button is not compliant with Article 14 in any reading. Neither is one whose approval step is a rubber stamp, since the article requires effective oversight rather than nominal supervision.

There is a design problem hiding in the word "stop", and it is worth naming because compliance language obscures it. Halting a multi-step agent mid-sequence can leave a partial state: the invoice raised and the ledger entry not written, the account created and the permissions not applied. A stop that produces an inconsistent record is its own incident class. The regulation asks for a halt "in a safe state", which in practice means that every action sequence needs a defined interruption point and a compensating action for the steps already committed. That is transaction design, and it is unglamorous work no model release will do for you.

On timing: the implementation timeline has prohibitions and AI literacy applying from 2 February 2025, general-purpose AI model obligations from 2 August 2025, and the remainder of the Act from 2 August 2026 except Article 6(1), which follows on 2 August 2027. Our own read of what deployers should be doing before then is in our 2027 guide to EU AI Act compliance.

The NIST AI Risk Management Framework, released on 26 January 2023, organises the same work into four functions, Govern, Map, Measure and Manage, and NIST released a Generative AI Profile, NIST-AI-600-1, on 26 July 2024. Neither is agent-specific. Both are close enough that inventing a parallel agent-governance vocabulary is usually a way of avoiding the work rather than doing it.

There is also a decided case on the question everyone asks last, which is who carries the loss. In Moffatt v. Air Canada, 2024 BCCRT 149, issued on 14 February 2024, Air Canada argued it could not be held liable for information given by its own chatbot. Tribunal member Christopher C. Rivers was unimpressed: "In effect, Air Canada suggests the chatbot is a separate legal entity that is responsible for its own actions. This is a remarkable submission." The finding was that the airline "is responsible for all the information on its website" and that "it makes no difference whether the information comes from a static page or a chatbot." Air Canada was ordered to pay $812.02.

The sum is trivial and the reasoning is not. This was a chatbot that only produced a sentence, and the deploying organisation still wore the consequence. Extend the same logic to a system that moves money or changes a record and the exposure stops being a refund. Be precise about its weight, though: this is a small-claims decision of a provincial tribunal, not binding precedent anywhere, and nothing here is legal advice. What it tells you is that the "separate legal entity" defence was tested early, in the mildest possible fact pattern, and it lost.

One caution on all of this. Being technically capable of producing a log is not the same as producing an attributable one. If every agent action arrives at the target system under one service account, you satisfy Article 12's letter and lose the ability to answer the only question anyone will ask, which is who caused this.

Where Agentic AI Earns Its Keep Today

The pattern in the evidence is consistent: agentic AI pays when the task is high-volume, the error is cheap, and the reversal is easy. Gartner's June 2025 recommendation was that agentic AI "only be pursued where it delivers clear value or ROI", reserving agents for cases where decisions are needed, automation for routine workflows and assistants for simple retrieval.

Mapped to autonomy levels, that produces a practical starting portfolio.

Two rules of thumb we would apply to that table. First, an action belongs at Level 4 only if you can state, before deployment, the specific threshold that halts it and the specific mechanism that reverses it. If you cannot finish the sentence "it stops when…", it is not ready. And "reversible" has to mean something operationally: restoring a row from a backup is a reversal, un-sending a customer email or clawing back a wire transfer is not. An irreversible action does not belong at Level 4 at any volume, however cheap each instance looks. Second, moving one action up a level is nearly always a better move than moving a whole system, and it is the move that ledger-based scoping makes visible.

Gartner's supply-chain guidance in May 2026 reached a compatible conclusion from a different direction: the priority now is not full autonomy but "building the operational discipline, architectural flexibility and decision frameworks" that let agentic AI scale as the technology matures. Our own analysis of why AI pilots stall on the way to production found the same four unanswered questions behind most of them, and none of the four was about the model.

Where This Is Still Uncertain

Several things in this article are less settled than the confident register of most writing on this subject suggests, and the honest move is to say which.

Autonomy-level taxonomies are not standardised. The four levels used here are Gartner's, published May 2026. Other taxonomies exist with different cut points, and no standards body has ratified one. The ladder is useful because it forces a per-action question, not because the number four is correct.

The reliability picture rests on a small number of studies. The March 2026 long-horizon evaluation is one paper. Its finding that memory scaffolds hurt long-horizon performance contradicts widespread practice, which is exactly why it should not be treated as settled after a single result. τ-bench's headline numbers date from mid-2024 and current models will do better; the shape of the pass^k decay is the durable part, not the specific figure.

Analyst predictions are predictions. Two Gartner forecasts appear above, one about cancellations by 2027 and one about demotions by 2027. Neither has happened yet. They are useful as a description of what practitioners are reporting now, not as measurement.

Some sources a reader would expect are missing. We could not verify McKinsey's State of AI figures on agent adoption, because the page did not load for us on any attempt. It is widely quoted and it is not cited here, since we could not read the primary text. We also declined to use a figure circulating from a sandbox vendor about the share of agent sessions that exceed their task scope, since no methodology was published with it. The Moffatt decision above is quoted from the tribunal's own published text rather than from press coverage of it, which is the standard we tried to hold everywhere.

We have not run this at scale ourselves. LeapForce is in active development and discloses per-capability build status. The Action Ledger is a reasoning tool we derived from the sources above, not a method validated across a deployment portfolio. If you run it and it fails to separate two systems you know to be different, we would rather hear that than not.

And the ledger has a real limit. It is excellent at bounding what an agent can do and poor at predicting what an agent will decide to do inside those bounds. Goal misalignment, deceptive behaviour and cascading errors across multiple agents live outside its reach. It reduces the size of the problem. It does not dissolve it.

Where LeapForce Fits

Once work moves from a person to an agent, the operative questions change from "which tool is best" to who owns this agent, what can it touch, what did it do, and what did it cost. That layer is what we build: one controlled layer for every AI tool, connector, model and agent, with non-human identities treated as first-class citizens that carry an owner, a scope and an expiry.

The rollout model we publish for our AI gateway is deliberately incremental, and it matches the ladder in this article: observe first, enforce second, optimize third. Point one team's traffic at the gateway in observe mode, learn what is actually happening, then apply allow and deny rules you derived from evidence rather than guesswork. That sequence exists because the alternative, enforcing first, produces exactly the over-restriction that Gartner identifies as a driver of shadow development.

LeapForce is not an agent framework and does not build your agents. Per-capability build status is disclosed honestly on our site, and the gateway endpoint, tracing and SSO are live while other capabilities are in development. If you want to see how a personal workflow becomes an owned, scoped company asset, our write-up on turning personal prompts into owned agents is the closest thing to a walkthrough.

Ready to Govern Your AI?

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