AI Agent Use Cases, Ranked by Blast Radius Not Department

The AI agent use cases that reach production share three properties: the agent writes to one system, a named person can undo a bad run inside an hour, and someone notices the same day if it goes wrong. Ticket triage, invoice matching, internal research briefing and reply drafting clear that bar. Resume screening and autonomous outbound do not.

Our position is that listing AI agent use cases by department is the wrong sorting key. Every entry on every list is really a grant of access with a job attached, so the useful question is not "which team owns this" but "what can this agent reach, and how fast can we take it back." Sort by blast radius and the same catalogue produces a completely different starting order.

That reframe comes straight from the people who have to sign off on the access. On Hacker News in February 2026, a developer posting as Quothling described working in a NIS2-regulated field where, as they put it, "we can't give AI's any sort of real access because of the security risk". Then they immediately pointed at their own internal tools, where the same risk would barely matter (HN item 47108865). Two sentences, both true, and the entire selection problem sitting between them.

The short answer: Pick your first AI agent use cases by blast radius, not by department — an agent that drafts, flags or routes inside one internal system is a Monday-morning project, while an agent that sends, scores or decides on a person's behalf is a governance project first and an automation project second.

Last updated: July 30, 2026.

The same catalogue, sorted by blast radius instead of by department.

What an AI Agent Use Case Really Is

An AI agent use case is a bounded job handed to a system that can choose its own steps, backed by a specific set of permissions on specific systems. The permissions are the part the catalogues leave out. A recruiting agent needs candidate records, a finance agent needs ledger access, a support agent needs the ability to write to a customer account. Each of those is a grant, not a feature.

The distinction that justifies the word "agent" is real. A workflow automation follows a fixed path you drew in advance: when this happens, do that, then that. An agent is given an outcome and picks its own path, which is why it can absorb the ambiguous judgement step that used to force a person into the middle of a process. That is also precisely why it is harder to bound. A fixed path can only touch what you wired into it. A chosen path can touch everything the credential allows.

Gartner has a name for the confusion this creates. In an August 2025 press release, the firm called the habit of relabelling assistants as agents "agentwashing", and drew the line at independence: assistants "depend on human input and do not operate independently," while agents "have the capacity to operate and perform complex, end-to-end tasks." The practical version of that test is simpler. If the thing cannot take an action without a person clicking, it is an assistant and its blast radius is the person's. If it can, it is an agent and its blast radius is its credential's.

Practitioners arrive at the same place from the other direction. Commenting on an agent-permissions thread in February 2026, a developer posting as NBenkovich noted that most platforms "were built assuming a human behind the UI," so that once agents arrive, "the missing permission layers start to show". Your CRM has a permission model designed for a rep who makes forty edits a day, not for a process that makes four thousand.

What an AI agent use case is not

It is not a chatbot with a longer memory. It is not a report that arrives on a schedule. And it is not, despite how the lists read, a productivity feature you switch on. The moment an agent can write, send or decide, you have created a non-human actor inside your estate, and the questions that follow are the ones you would ask about a new contractor: who does this report to, what is it allowed to touch, what did it do last Tuesday, and what happens when it is wrong.

Where AI Agents Are Actually Running in 2026

Agent adoption is broad and shallow. In McKinsey's State of AI survey published on 5 November 2025, 23 percent of respondents said their organisation was scaling an agentic system somewhere in the enterprise and another 39 percent had begun experimenting. But "in any given business function, no more than 10 percent of respondents say their organizations are scaling AI agents." Sixty-two percent engaged, under ten percent scaled anywhere specific.

Two widely quoted numbers describe this market and they are not measuring the same thing, which is worth pinning down before either gets used in a business case.

Gartner's 40 percent is a supply-side forecast about software you buy. McKinsey's 23 percent is a demand-side measurement of programmes you run. A slide that puts them next to each other to argue "everyone is doing this" is comparing a vendor roadmap to an operating reality.

The reliability picture is the third leg. Stanford HAI's 2026 AI Index Report records genuine progress. On OSWorld, which tests agents on computer tasks across operating systems, accuracy rose from roughly 12 percent to 66.3 percent, "within 6 percentage points of human performance". The same report states that agents "still fail roughly one in three attempts on structured benchmarks." A one-in-three failure rate is perfectly workable when the failure is a badly routed ticket. It is not workable when the failure is a rejected candidate.

Where the agents that do exist are pointed

McKinsey found agent use "most commonly reported in IT and knowledge management, where agentic use cases such as service-desk management in IT and deep research in knowledge management have quickly developed." That is not a coincidence of vendor marketing. Those two are the lowest-blast-radius jobs in the average company: the outputs are internal, a human works the queue, and a wrong answer costs a re-route rather than a customer.

The barrier is not capability

The most useful finding for anyone building a business case landed in March 2026. McKinsey's State of AI trust in 2026 survey, taken between December 2025 and January 2026 across roughly 500 organisations, reports that "nearly two-thirds of respondents cite security and risk concerns as the top barrier to fully scaling agentic AI, well ahead of regulatory uncertainty or technical limitations."

The same study frames the shift in one line worth stealing: organisations "can no longer concern themselves only with AI systems saying the wrong thing; they must also contend with systems doing the wrong thing, such as taking unintended actions, misusing tools, or operating beyond appropriate guardrails." Saying the wrong thing is a quality problem. Doing the wrong thing is an access problem. Almost every catalogue of AI agent use cases is written as if the first were the only risk.

The Blast-Radius Test

The Blast-Radius Test is a four-question score you can run against any AI agent use case in about ten minutes, using nothing but a whiteboard and someone who knows the systems. Score each question from 0 to 3, add them up, and the total tells you whether this is a deployment, a gated pilot, or a governance project wearing an automation costume.

Reach — how far can a single wrong action travel?

• 0: writes nothing. Reads, drafts, suggests.
• 1: writes to one internal system.
• 2: writes to two or more internal systems, or to a system of record.
• 3: writes to something a customer, candidate, regulator or counterparty sees.

Reversibility — how long does one named person need to undo a bad run?

• 0: under a minute, self-serve.
• 1: under an hour.
• 2: same day, and it needs another team.
• 3: cannot be undone.

Recognition — how quickly does a wrong action get noticed?

• 0: immediately. A human reads every output before it lands.
• 1: same day, through a queue somebody actually works.
• 2: within a week, through a report somebody actually reads.
• 3: only when an outsider complains.

Recourse — is there a named owner who can stop it?

• 0: named individual owner, documented kill switch, tested at least once.
• 1: named owner, kill switch never tested.
• 2: a team owns it, no individual does.
• 3: whoever built it has left, or nobody is sure.

The test is deliberately blunt about one thing: it scores the design you are actually proposing, not the design you intend to build later. An agent that "will eventually have a human approval step" scores as though it does not, because that is how it will run in week one.

Why these four and not the usual criteria

Most selection frameworks score value and readiness. Those matter, and they are also the two things every stakeholder in the room already has an opinion about. The Blast-Radius Test scores the thing nobody in the room owns: what happens when the agent is confidently wrong at three in the morning. Run both. Value tells you which use cases are worth doing; blast radius tells you which order to do them in.

Notice that three of the four questions have nothing to do with the model. Reach, reversibility and recourse are properties of your integration design and your identity model. You can move a use case two or three points without changing a single prompt, which is the most practical finding in this whole article.

One condition on using it: score it with the person who administers the target system in the room. Reach and reversibility are questions about your instance, not about the category. The RevOps administrator knows whether a field is restorable from a backup and how long that takes; the product page does not. A score produced without them is a guess with arithmetic attached.

Eight AI Agent Use Cases, Scored

Here are eight AI agent use cases drawn from the departmental catalogues, scored on the same four axes. The scores assume the most common implementation of each, not the most careful one. Where a design choice moves the score, the block says so.

One note on what is missing from these blocks, because it is missing from the source catalogues too. Almost every published list attaches an impact claim to each entry — hours saved, tickets deflected, pipeline lifted — with no baseline, no measurement window and no source. We have not repeated those. Credible measured results for genuinely agentic deployments, as opposed to assistive ones, are scarce enough in mid-2026 that the one study cited below is the exception rather than a sample. Where we could not find a real number, the block says what the agent does and what it risks, and leaves ROI to your own baseline.

1. Internal research and briefing

What the agent does. Takes a question, searches an approved internal corpus plus whatever external sources you allow, and produces a written brief with citations into a document.

What access it needs. Read on the corpus. Write on a scratch document location. Nothing else.

Score: 1 (Green). Reach 0, reversibility 0, recognition 0, recourse 1. That last point is there because these are almost always built by one individual who never wrote down who owns it.

What goes wrong. Not much, structurally. The real risk is quality: a brief that reads well and cites a source that does not say what the brief claims. That is a review problem, not an access problem.

The human gate. The reader is the gate. Nothing lands anywhere until a person acts on the brief.

Verdict: start here. This is the highest-value-per-unit-of-risk agent in most organisations, and it is the one McKinsey found spreading fastest alongside service-desk work.

2. Support reply drafting (agent-assist)

What the agent does. Reads the incoming ticket and the customer's history, drafts a reply in the console, and waits. A human edits and sends.

What access it needs. Read on tickets and customer records. Write to a draft field. No send permission.

Score: 1 (Green).

What goes wrong. Automation bias. Agents stop reading drafts carefully after a few hundred good ones, which is exactly the tendency the EU's AI Act obliges deployers of high-risk systems to design against in Article 14: staff must "remain aware of the possible tendency of automatically relying or over-relying on the output." Support is not a high-risk category, but the human factor is identical.

The human gate. Built in. The moment you remove it, this becomes a different use case with a score of 8.

Verdict: start here — and this is the one with a real published number attached. In the NBER working paper Generative AI at Work, Erik Brynjolfsson, Danielle Li and Lindsey Raymond studied a conversational assistant rolled out to 5,179 customer support agents and found access "increases productivity, as measured by issues resolved per hour, by 14% on average, including a 34% improvement for novice and low-skilled workers but with minimal impact on experienced and highly skilled workers." That heterogeneity is the part to plan around. If your support team is mostly tenured, budget for a smaller lift than the headline.

3. IT service-desk triage and routing

What the agent does. Classifies an inbound ticket, sets priority, attaches the likely knowledge-base article, and routes to a queue. It does not resolve and it does not close.

What access it needs. Read and write on ticket metadata in the ITSM tool. Read on the knowledge base. No access to the systems the tickets are about.

Score: 2 (Green).

What goes wrong. Out-of-distribution tickets get confidently misrouted, and a small number of genuinely urgent ones get filed as routine. The fix is a confidence floor: below a threshold, the agent routes to a human triage queue instead of guessing.

The human gate. None needed for routing. One is mandatory before you let it close anything.

Verdict: start here. McKinsey names service desk management as one of the two most commonly reported agentic use cases, and the reason is structural rather than fashionable. The output is internal, the queue is worked every day, and a mistake costs minutes.

A close cousin worth naming: employee onboarding, which the departmental catalogues list as a single entry but which in practice spans HR, IT, facilities and payroll. Treat it as four use cases with four grants rather than one agent with four sets of write permissions, and it becomes tractable. Treated as one, it scores 3 on reach before you have written a line of it.

4. Invoice and purchase-order matching

What the agent does. Matches inbound invoices against purchase orders and goods-received notes, flags the exceptions, writes a short reason on each.

What access it needs. Read on invoices, POs and receipts. Write on a match status field and a comment field. Explicitly not payment initiation.

Score: 2 (Green) — provided it cannot pay. Give the same agent payment release and three axes move at once: reach to 3, reversibility to 3, and recognition to 2, because a wrong payment surfaces at reconciliation rather than on the day. The total lands at 8. That single permission is the difference between a Green and a Red.

What goes wrong. Confident matching on near-duplicate invoices, which is also the classic vector for invoice fraud. Any agent in the accounts-payable path should treat two similar invoices from the same vendor as an exception by default, not as a match.

The human gate. On payment, always. On the exception queue, no.

Verdict: start here, with the payment permission withheld in writing.

5. Meeting notes to task routing

What the agent does. Transcribes a meeting, extracts commitments, creates tasks in the tracker, and notifies the owners.

What access it needs. Read on the recording. Write on the tracker. Send on the internal notification channel.

Score: 4 (Amber). Reach 2 because it touches two internal systems, reversibility 1 because you can delete the tasks but not the pings, recognition 0 because assignees see them immediately, recourse 1.

What goes wrong. It manufactures commitments. Someone says "we could look at that" and a task appears assigned to them with a due date, and now a manager's dashboard says they are late on work they never agreed to. It is a small harm that compounds fast because it lands directly in other people's accountability.

The human gate. The meeting owner approves the extracted task list before anything is created. That gate takes reversibility to 0 and hands the use case a named owner, which takes recourse to 0 as well, moving the score to 2.

Verdict: start here with the gate, not without it.

6. Sales lead research and CRM enrichment

What the agent does. Researches inbound leads, finds firmographics and recent signals, and writes them onto the CRM record. Most catalogues file this under lead qualification, which flatters it — the agent is doing research and data entry, and a human still qualifies.

What access it needs. Write on CRM contact and account objects. This is the problem.

Score: 7 (Red). Reach 2 (a system of record for a revenue process), reversibility 2 (a wrong overwrite needs RevOps and a backup), recognition 2 (nobody reads enrichment fields until a rep is already on a call with a prospect), recourse 1.

What goes wrong. It overwrites a field a human curated. The account owner had "no budget until Q3, revisit after the Hartley deal closes" in a notes field and the agent replaced it with a generic company description. Nobody notices for six weeks. The information is gone from the only place it existed.

The design change that fixes it. Give the agent its own custom fields, prefixed and visibly agent-owned, and no write permission on any human-curated field. Reach drops to 1, reversibility to 0, recognition to 1, and the use case lands at 3 — Green. Same model, same prompt, different grant.

Verdict: shadow mode until the field scoping is done. Then it is one of the better second-wave use cases.

7. Resume screening and candidate ranking

What the agent does. Reads applications, scores them against a role, produces a ranked shortlist.

What access it needs. Read on applicant records including personal data. Write on ATS scores and stages.

Score: 9 (Red). Reach 2, reversibility 3 (you can un-reject a candidate, but you cannot un-not-interview the ones who were never contacted), recognition 3 (a systematically skewed ranking is invisible in individual cases and only shows up in aggregate, months later), recourse 1.

What goes wrong. The failure is statistical rather than anecdotal, which is what makes it hard. Every individual decision looks defensible. The pattern across three hundred decisions is the thing you cannot see from inside the queue, and the people harmed by it never appear in your logs because they were filtered before anyone spoke to them.

The legal position. This is not a judgement call. Under the EU AI Act, Annex III point 4(a) classifies as high-risk any AI system "intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates." Point 4(b) extends that to promotion, termination, task allocation and performance monitoring.

The human gate. Not a gate — a redesign. Move the agent to summarising applications without scoring them, or to checking hard eligibility criteria that a human wrote down, and it becomes a Green use case that still saves real time.

Verdict: wait. Not because it cannot work, but because the version that works is a different use case from the one on the catalogue.

8. Autonomous outbound and activity logging

What the agent does. Researches a prospect, writes a personalised email, sends it, and logs the activity in the CRM.

What access it needs. Send on a mail domain you own. Write on CRM activity objects.

Score: 10 (Stop). Reach 3 (external and attributable to your brand), reversibility 3 (a sent email cannot be unsent), recognition 3 (you find out when the account executive hears it from the prospect), recourse 1.

What goes wrong. The failure that ends pilots is not a badly written email. It is the agent contacting someone who is already in a live negotiation with your own sales team, with different pricing, in a different tone. Deal-stage awareness is exactly the kind of context an agent's view of the CRM is stale about, and the person who finds out first is your customer.

The human gate. Every send, at least until you have a tested pre-send check against open opportunities, suppression lists and existing threads.

Verdict: do not start here. This is the use case with the best demo and the worst first month, and the reason it is the last entry on this list rather than the first on a departmental one.

The Access Grant Behind Each Use Case

Once you accept that a use case is a permission set, the design work becomes concrete. For each agent you deploy, four things need an answer before it runs: what identity it authenticates as, what scope that identity carries, which of its actions require a human to approve, and what the audit trail records. This is the table our earlier analysis of non-human identity for AI agents argues should exist before the first prompt is written.

The single most consequential row in that table is the first column. An agent that authenticates as a person inherits that person's entire permission set, and every action it takes is attributed to them in every downstream log. Offboarding then becomes impossible to reason about, because disabling the human breaks the agent and keeping the agent alive keeps a leaver's access alive with it.

Plenty of tools cannot do this yet. If your ITSM or CRM has no concept of a service account with an owner and an expiry date, the workable substitute is a named generic account whose credential is held in a vault, rotated on a schedule, and recorded in a register your identity team owns. It is worse than a real non-human identity and much better than a person's login.

OWASP has codified the failure this creates. LLM06:2025 Excessive Agency in the OWASP Top 10 for LLM Applications traces harm to three root causes — excessive functionality, excessive permissions and excessive autonomy — and its mitigations read like a checklist for the table above: "limit the extensions that LLM agents are allowed to call to only the minimum necessary," "avoid the use of open-ended extensions where possible (e.g., run a shell command, fetch a URL, etc.)," enforce least-privilege access, and "utilise human-in-the-loop control to require a human to approve high-impact actions." The last one includes a warning most implementations ignore: enforce authorisation "in downstream systems," not by trusting the model's own decision about whether it should be allowed.

If you want the identity framing at more depth than an article can carry, this AWS re:Invent 2025 session treats agents explicitly as privileged machine identities rather than as software features:

The approval gate people actually accept

There is a practical objection to least privilege that deserves an answer, and a Hacker News commenter posting as tonymet put it sharply in February 2026: "no reasonable user can know the future and be smart about managing scoped access". Their proposed alternative is transaction approval: the agent works on shadow copies, writes batch into a pending transaction, and the owner approves a list. Emails queue as drafts. File edits copy-on-write. Posts wait for a publish click.

It is a good instinct and it maps cleanly onto the Blast-Radius Test: batching every write into an approval queue drops reversibility to 0 and recognition to 0 regardless of what the agent's scope allows. It does not replace scoping, because a compromised agent with an approved batch still gets its write through, but it does mean people can govern by reviewing a list rather than by predicting the future. The gate is the control most teams can actually operate. Our approach to workflow approval gates treats them the same way: the gate sits at the step that changes something, not at the start of the run.

What Goes Wrong in Week Two

Week one is a demo and it goes well. Week two is when the agent meets the edge cases your data actually contains, and the failures cluster into a small number of shapes. Every one of them below has a control that would have caught it, and every control is cheaper to build before launch than after.

Two of these deserve more than a table row.

Prompt injection is an access problem wearing a content costume

On 6 July 2026, researchers at Noma Labs published GitLost, a demonstration in which a crafted issue in a public repository caused a configured GitHub agentic workflow to fetch files from private repositories in the same organisation and post them as a public comment. The workflow's permissions were, in the researchers' description, read access across public and private repositories plus the ability to add comments. Neither permission is unreasonable on its own. The combination is what made the exfiltration path.

Their summary of the mechanism generalises past GitHub: "Any content the agent reads, whether issues, pull requests, comments, or files, can be weaponized if the agent treats that content as instructional input." That is LLM01 Prompt Injection sitting on top of LLM06 Excessive Agency, and the practical lesson for use-case selection is narrow and useful: never let one agent identity hold both read access to something confidential and write access to something public. Split it into two agents with two identities, and the exfiltration path disappears without a single guardrail prompt.

Scope creep arrives through the connector, not the agent

The agent's permissions rarely change. The connector's do. A vendor ships an update that adds three new tools to an integration, the integration is already approved, and the agent that had read access last month can now write. This is why connector review has to be an ongoing scope check rather than a one-time procurement decision, a point our analysis of MCP server security develops in more detail. The question to ask a vendor is not "is your integration secure" but "what happens to my approved scope when you ship a new tool."

The measurement problem underneath all of it

McKinsey's 2026 trust survey found that the share of organisations reporting AI-related incidents held steady at roughly 8 percent, but that "almost 60 percent of respondents who experienced incidents report satisfactory or negative views of their organization's response." Incidents are not becoming more common. Response is getting worse relative to system complexity. That gap is a logging problem before it is a process problem, and it is why the audit-fields column in the previous section is not bureaucratic decoration.

Which AI Agent Use Cases Are Legally High-Risk

Three of the use cases on a typical departmental catalogue are regulated activities in the EU, and the compliance clock for them moved a month ago. Recruitment screening, employment decisions and creditworthiness scoring are named in Annex III of the AI Act as high-risk. Nothing else on the list of eight above is.

The date matters because most guidance written before July 2026 gets it wrong. High-risk obligations for stand-alone Annex III systems were due to apply from 2 August 2026. On 29 June 2026 the Council of the EU gave final approval to the Digital Omnibus on AI, which states that "the new application dates would be 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk AI systems embedded in products."

The transparency side did not move. The same Council text shortened the grace period for implementing content-marking solutions from six months to three, setting that deadline at 2 December 2026. If your agent talks to customers, that is the date on your calendar, not the 2027 one.

Do the work anyway

Sixteen extra months is a real gift and a bad reason to defer the design. Three of the obligations that apply to high-risk systems are things you want regardless of whether a regulator ever asks.

Article 12 requires that high-risk systems "technically allow for the automatic recording of events (logs) over the lifetime of the system," sufficient to identify risk situations and support post-market monitoring. Article 14 requires that oversight staff can "decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output," and can "intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or similar procedure." Article 26 obliges deployers to assign oversight to people with "the necessary competence, training and authority" and to keep the system's logs for "at least six months."

Read those three as engineering requirements rather than legal ones and they say: log everything the agent did, give a named person a kill switch, and keep the record. That is the Recourse and Recognition half of the Blast-Radius Test, written into law for the cases where it matters most. Building it for your Green use cases in 2026 is how you get to run a Red one in 2027 without a nine-month programme.

The same logic applies to the voluntary frameworks. NIST's AI Risk Management Framework, released in January 2023 and organised around the functions Govern, Map, Measure and Manage, plus its Generative AI Profile from July 2024, gives you a vocabulary your risk function already recognises. ISO/IEC 42001 does the same for management-system auditors. Neither will tell you which use case to pick. Both will make the answer defensible once you have.

When an Agent Is the Wrong Tool

Sometimes the honest recommendation is not to deploy an agent at all, and a catalogue built to sell agent software will never tell you when. Three situations come up repeatedly, and in all three the incumbent approach still wins.

The path is fixed and known. If you can draw the decision tree on a whiteboard and it does not change, a deterministic workflow is better in every dimension that matters. It is cheaper per run, it fails the same way twice, it can be unit tested, and its audit trail is trivially explainable. Reaching for an agent because a rules engine feels dated is how teams end up paying model inference costs to reproduce an if-statement. The agent earns its keep at the ambiguous step, and only there.

The volume does not justify the governance. An agent needs an owner, a scope review, a log, a budget and a periodic check that it still works. Call that a day of setup and an hour a month forever. If the task runs eleven times a quarter, a person doing it is not the expensive option. The catalogues never do this arithmetic because every entry has to look worth building.

The judgement is the job. When the reason a human is in the loop is that the decision requires accountability rather than throughput, automating it does not remove the human; it relocates them to reviewing outputs, usually badly. Our earlier analysis of why AI pilots stall between prototype and production makes the same argument about ownership: governance gaps kill projects late, at the production gate, and ownership by committee reliably produces an unattended system. The pilot succeeds at the task and fails at the handover.

There is a fourth case that is temporary rather than structural. If your organisation cannot currently answer "what identity does this run as" for any of its automation, the first project is not an agent. It is the identity model. Everything after that gets cheaper.

How to Sequence Your First Three AI Agent Use Cases

Pick three, run them in this order, and give each one a month before the next starts. The sequencing rule is that each use case should teach you something the next one needs, and the cheapest lessons come first.

Choose your first if it scores 0-3 and its output is read by a person before it lands. Internal research briefing or support reply drafting, in most organisations. The purpose of the first is not value. It is to build the plumbing — an identity for the agent, a log you can query, a named owner, a budget cap — on a use case where getting it wrong costs nothing. If you cannot answer "who owns this and what did it do yesterday" after month one, do not start month two.

Choose your second if it writes to one internal system and a queue-worker sees the output daily. Service-desk triage or invoice matching. This is where you find out whether your logging is actually usable, because you will be asked why the agent classified something the way it did, and you will need to answer from the record rather than from memory.

Choose your third if it scores Amber and you have a real approver. Meeting-notes routing, or lead enrichment after the field scoping is fixed. This one teaches you what an approval gate costs in practice: how long the queue gets, who ignores it, and what happens on holiday.

That progression maps onto the rollout model we use for the AI gateway itself, which we describe on our AI Gateway page as Observe first. Enforce second. Optimize third. Start in observe mode and find out what is actually happening, turn on the controls that prevent incidents, and only then tune for cost. The order is the same because the reason is the same: you cannot write a sensible policy about behaviour you have never measured.

What to write down before each one starts

Four artifacts, none longer than a page:

1. The grant. What this agent can read, what it can write, and what it explicitly may not do. Signed by whoever owns the system, not by whoever wants the agent.
2. The gate. Which actions require a human, who that human is, and what happens when they are away.
3. The record. Which fields land in the log, where the log lives, and how long you keep it. Six months is the EU AI Act floor for high-risk deployers and a reasonable default for everything else.
4. The exit. How you turn it off, who can do it without a change ticket, and when someone last tested that.

Teams that skip the fourth one discover during an incident that turning the agent off requires a person who is asleep. Our analysis of promoting personal AI workflows into owned company assets covers the ownership half of this in more depth, including what happens to an agent when its creator changes teams.

Where LeapForce Fits

The honest bridge is narrow. LeapForce does not build your recruiting agent or your invoice matcher, and this article is not an argument that you need a platform to run a research-briefing agent. What we build is the governance infrastructure underneath the use cases: one controlled place where every AI tool, connector, model and agent is identified, scoped, logged and budgeted, so that the four artifacts above have somewhere to live other than a spreadsheet.

Concretely, that maps to the columns in the access-grant table. Access and identity treats non-human identities as first-class, so an agent has its own owner, scope and expiry rather than borrowing a person's login, and offboarding is one step. The AI gateway puts policy evaluation in the request path — its lifecycle runs Identify, Check, Protect, Route, Execute, Record — so the log and the budget line are produced automatically rather than assembled afterwards. Workflows carry the human approval gates. Observability and audit is where the record lands, including what was refused rather than only what ran, which is the half of the trail our work on audit trails for agent actions argues most teams are missing.

LeapForce is in active development and the site discloses per-capability build status honestly, so check the current state of any specific capability before you plan around it rather than assuming everything described here ships today.

Limits of This Guide

The Blast-Radius scores in this article are our structured judgement, not measurements. We have not run a controlled deployment of these eight use cases inside a customer estate, so nothing here is a first-hand before-and-after from our own logs. Where a number appears, it carries its source, and you should weigh it accordingly.

Three other limits are worth stating plainly.

The scores are design-dependent, and your design may differ. Two organisations can implement "lead enrichment" in ways that score 7 and 3. Each block above names the design choice that moves its score, but if your implementation differs from the common one we described, re-score it rather than inheriting our number.

The legal section covers the EU and only the EU. US state-level rules on automated employment decisions, including New York City's bias-audit requirement for automated employment decision tools, impose separate obligations we have not mapped here. Nor have we covered sector regulators. If you are in financial services or healthcare, your supervisor's expectations will arrive before the AI Act's do.

Two sources a reader would expect are missing. Forrester and IDC agent-adoption figures are widely quoted in this space and sit behind paywalls we could not verify against, so they are excluded rather than repeated second-hand. We were also unable to re-fetch the Hacker News permalinks directly at verification time because the site rate-limited us; the comment text, author handles and dates were confirmed through Hacker News's own Algolia search index, and the permalinks are canonical.

Finally, this is a snapshot of a fast-moving picture. The reliability numbers in the Stanford index moved by more than fifty points on one benchmark in a year, and the EU compliance dates moved by sixteen months in a single Council session five weeks ago. Treat the framework as durable and every number in it as perishable.

Ready to Govern Your AI?

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