75 Real-World AI Agent Use Cases in 2026

Most lists of "AI agent use cases" are lists of tasks a language model can help with. That is a different thing. A task a model can help with becomes an agent when a system decides for itself what to do next, acts on the world through tools, reads the result of that action, and repeats until a stopping condition is met.

That distinction is not academic. It determines what you build, what it costs, what can go wrong at 3am, and whether you need a human in the loop or on the loop. Anthropic's engineering team draws the line the same way: workflows are systems where models and tools are orchestrated through predefined code paths, while agents are systems where the model dynamically directs its own process and tool usage (Anthropic, "Building effective agents").

This article catalogs 75 use cases. Each one gets five fields: the goal, the autonomy loop, the tools and data it needs, the human control that keeps it safe, and the failure mode that will actually bite you.

Every entry carries two labels.

• Deployed means a named vendor or organization publicly documents this capability, and the primary source is linked. Nothing here is a customer success story, and there are no ROI figures anywhere in this article, because vendor-supplied ROI is not evidence.
• Pattern means the design is buildable today with off-the-shelf components, but I am not asserting that any named company runs it in production. Treat it as an architecture sketch, not a case study.

Risk tiers (T1, T2, T3) are defined in the risk tier section below.

If you want the broader inventory of automation ideas that do not require autonomy, see 100 AI automation ideas. If you want to build one of these, start with how to build an AI agent and then the AI agent architectures guide. Deployed AGNT scenarios live in /use-cases/.

---

Agents, chatbots, and fixed workflows are three different products

Before the list, get the taxonomy right, because roughly half of failed "agent" projects are workflows that were given an agent's budget, or chatbots that were given an agent's permissions.

	Chatbot / assistant	Fixed workflow	Agent
Who decides the next step	The user, every turn	The developer, at design time	The model, at run time
Control flow	Turn-taking	Directed graph in code	Loop with a stopping condition
Tool use	Optional, usually retrieval	Called at fixed nodes	Selected dynamically from a toolset
Number of steps	One or few per turn	Known in advance	Unknown in advance
Failure signature	Wrong answer	Wrong branch, dead node	Compounding error across steps
Cost profile	Predictable per turn	Predictable per run	Variable, capped by iteration limits
Right control	Content review	Schema validation and retries	Checkpoints, approvals, sandboxing
Best when	Humans need information	The path is stable and known	The path cannot be predicted

Three practical consequences follow.

A chatbot with write access is not an agent, it is a liability. Turn-taking gives you an implicit human check on every action. Remove the human and add tools, and you have removed the only safety mechanism the design ever had, without adding the ones an agent needs.

A workflow that never branches unpredictably should stay a workflow. Anthropic's guidance is explicit that agentic systems trade latency and cost for task performance, and that for many applications a single optimized model call with retrieval is enough. Predictability and consistency are features. Do not pay an agent's token bill and error budget to get less of both.

Agents earn their cost in exactly one situation: you cannot predict the number of steps or the path in advance, and the environment can tell the system whether each step worked. Coding is the canonical example because tests are an oracle. Anything without an oracle needs a human to be the oracle, and that is a design constraint, not an afterthought.

Anthropic's own framing of the agent loop is worth keeping in front of you while reading the 75: the agent starts from a command or a clarifying conversation, plans and operates independently, gains ground truth from the environment at each step through tool results or code execution, pauses at checkpoints or blockers, and terminates on completion or on a stopping condition such as a maximum iteration count.

---

Part A: Use cases by business function

Software engineering and platform operations (1-9)

Software is the most mature agent domain for one structural reason: code solutions are verifiable through automated tests, so the agent can iterate against real feedback rather than against its own confidence.

1. Autonomous test authoring for untested modules

Deployed · T2

• Goal: Raise test coverage on modules that have none, without a human writing the first draft.
• Loop: Read the module and its callers, write tests, run the suite, read failures, revise, stop when the suite is green or the iteration cap is hit.
• Tools and data: Repository read/write, test runner, shell, project conventions file.
• Human control: Output arrives as a pull request. No merge without human review. Branch protection prevents direct writes to main.
• Failure mode: Tests written to match current behavior, including the bugs. Coverage rises, defect detection does not.
• Source: Anthropic documents Claude Code writing tests for untested code and fixing failures (Claude Code overview).

2. Pull request review as a CI job

Deployed · T1

• Goal: Give every PR a substantive first-pass review before a human opens it.
• Loop: Trigger on PR event, fetch the diff and surrounding context, analyze against project standards, post structured comments, re-run on new commits.
• Tools and data: CI runner, VCS API, diff, repository conventions, prior review history.
• Human control: Advisory only. The agent comments; it does not approve, merge, or block. Humans remain the approving reviewers.
• Failure mode: Comment volume trains reviewers to skim. Low-signal nits crowd out the one real finding.
• Source: Anthropic documents automated code review and issue triage via GitHub Actions and GitLab CI/CD; OpenAI documents a Codex code review workflow and GitHub Action (Anthropic, OpenAI).

3. Bug report to pull request, dispatched from team chat

Deployed · T2

• Goal: Convert a reported symptom into a candidate fix without a human first reproducing it.
• Loop: Parse the report, search the codebase for the responsible path, reproduce, form a root-cause hypothesis, implement, run tests, open a PR with reasoning.
• Tools and data: Chat integration, repository, test runner, logs, issue tracker.
• Human control: The PR is a hypothesis under review. Reviewers verify the root cause, not just the green build.
• Failure mode: The agent fixes the symptom the reporter described rather than the defect that produced it, and the test it writes locks in the wrong invariant.
• Source: Anthropic documents routing bug reports from Slack to pull requests (Claude Code Slack integration).

4. Overnight CI failure analysis

Deployed · T1

• Goal: Arrive in the morning with build breakages already diagnosed and grouped.
• Loop: Run on a schedule, pull failed runs, cluster failures by signature, pull the correlated commits, produce a per-cluster diagnosis, post the digest.
• Tools and data: CI API, build logs, commit history, test result artifacts.
• Human control: Read-only against production systems. The digest proposes, engineers decide.
• Failure mode: Infrastructure flakes classified as code defects, sending a team to debug a runner.
• Source: Anthropic documents scheduled routines for overnight CI failure analysis and weekly dependency audits (Claude Code routines).

5. Dependency upgrade and breakage repair

Deployed · T2

• Goal: Keep dependencies current without a human absorbing every breaking change.
• Loop: Detect available upgrades, bump one at a time, build, run tests, read failures, patch call sites, escalate on failure, open a PR per dependency.
• Tools and data: Package manager, lockfile, changelogs, test suite, CI.
• Human control: One PR per dependency so the blast radius stays inspectable. Security-sensitive packages routed to a named owner.
• Failure mode: Green tests on a semantic change the tests never covered. Behavior drifts silently.
• Source: Anthropic documents updating dependencies and weekly dependency audits as automated tasks (Claude Code overview).

6. Security scanning with triage and proposed fixes

Deployed · T2

• Goal: Turn a scanner backlog into ranked, explained, fixable findings.
• Loop: Scan, analyze each finding in code context, discard non-exploitable paths, rank by reachability and impact, draft a fix, write the vulnerability description.
• Tools and data: Source, dependency graph, scanner output, threat model, security workbench.
• Human control: Security engineer owns triage decisions and every fix merge. Findings are never auto-closed by the agent.
• Failure mode: Confident dismissal of a real finding as unreachable because the agent could not see a dynamic call path.
• Source: OpenAI documents a Codex Security workflow covering scans, backlog triage, fix proposals, and vulnerability reports (Codex Security).

7. Parallel subagent teams on a decomposable change

Deployed · T2

• Goal: Cut wall-clock time on a change that touches many independent areas.
• Loop: A lead agent decomposes the task, assigns subtasks to workers, workers execute in isolated contexts, the lead merges results and resolves conflicts.
• Tools and data: Orchestration layer, per-worker sandboxes, shared repository, merge tooling.
• Human control: A single reviewable artifact at the end, not a pile of parallel outputs. Iteration and concurrency caps set at launch.
• Failure mode: Workers make locally correct, mutually incompatible design choices. Integration cost exceeds the parallelism saved.
• Source: Anthropic documents agent teams with a lead coordinating subtasks and merging results; OpenAI documents Codex subagents (Anthropic, OpenAI).

8. Log anomaly watch with escalation

Deployed · T1

• Goal: Notice the anomaly in the log stream before the pager does.
• Loop: Sample recent output on an interval, compare against learned normal patterns, investigate candidates by pulling correlated traces, alert only on a passing threshold.
• Tools and data: Log pipeline, trace store, deploy timeline, alerting channel.
• Human control: Alert-only. No remediation authority. Alert budget capped so the channel stays credible.
• Failure mode: Alert fatigue in week two. The team mutes the channel and the design is dead.
• Source: Anthropic documents piping log output into Claude Code with an instruction to notify on anomalies (Claude Code overview).

9. Localization pull requests for new strings

Deployed · T1

• Goal: Keep translated resource files in sync with the source language automatically.
• Loop: Detect new or changed source strings in CI, translate with product glossary and context, validate placeholders and length constraints, open a PR.
• Tools and data: Resource files, glossary, style guide, CI, screenshot context where available.
• Human control: Native-speaker review before merge for user-facing surfaces. Legal and safety strings excluded from automation entirely.
• Failure mode: Correct-but-wrong translation of a domain term the glossary missed, propagated across every locale at once.
• Source: Anthropic documents translating new strings in CI and raising a PR for review (Claude Code overview).

Customer support and success (10-15)

Support is the second domain Anthropic names as a strong agent fit, and the reasoning is specific: interactions follow a conversation flow while requiring external data and actions, tools can pull customer and order data, actions like refunds and ticket updates are programmatic, and success is measurable through resolution.

10. Tier-1 resolution with real account actions

Pattern · T3

• Goal: Fully resolve common account issues rather than answering questions about them.
• Loop: Classify intent, retrieve the account state, decide whether policy permits the action, execute it, verify the resulting state, confirm to the customer, escalate on any ambiguity.
• Tools and data: CRM, order and billing systems, knowledge base, refund and credit APIs, policy engine.
• Human control: Hard monetary and frequency caps enforced outside the model. Anything above the cap becomes an approval request. Every action written to an audit log with the reasoning attached.
• Failure mode: Policy edge case resolved generously and consistently, producing a systematic leak nobody notices until reconciliation.

11. Escalation packet assembly

Pattern · T1

• Goal: Ensure a human specialist never opens a ticket cold.
• Loop: On escalation, gather history, related tickets, account state, recent product changes, and reproduction steps; summarize the customer's actual problem versus the stated one; attach the packet.
• Tools and data: Ticketing system, CRM, product telemetry, release notes, prior resolutions.
• Human control: Purely additive. The original ticket is never modified or summarized away.
• Failure mode: A confident summary that frames the problem incorrectly, anchoring the specialist on the wrong track.

12. Knowledge base gap closure

Pattern · T1

• Goal: Convert repeated ticket patterns into documentation that prevents the next batch.
• Loop: Cluster recent resolved tickets, find clusters with no matching article, draft an article from the actual resolutions, verify against product behavior, submit for review.
• Tools and data: Ticket archive, KB CMS, product docs, staging environment for verification.
• Human control: Support lead approves publication. Drafts never auto-publish to a customer-facing surface.
• Failure mode: Documenting a workaround as the supported path, entrenching a defect instead of surfacing it.

13. Proactive incident notification with scoped blast radius

Pattern · T3

• Goal: Tell affected customers about an incident before they open a ticket.
• Loop: Detect the incident, determine the affected cohort from telemetry, draft a message per segment, validate the cohort query, send in staged waves, monitor reply sentiment.
• Tools and data: Incident management, telemetry, customer database, messaging platform.
• Human control: Incident commander approves the cohort definition and the copy before the first wave. Send volume capped per wave with a manual gate between waves.
• Failure mode: A cohort query that is off by one join, notifying tens of thousands of unaffected customers of an outage they never experienced.

14. Churn signal investigation

Pattern · T1

• Goal: Explain why an account's health score dropped, not just that it did.
• Loop: Detect the score change, pull usage telemetry, support history, invoice events, and recent contact changes; test candidate explanations against the data; write a briefing for the account manager.
• Tools and data: Product analytics, CRM, billing, support archive, calendar of account interactions.
• Human control: Advisory. The agent has no ability to contact the customer or apply retention offers.
• Failure mode: Correlation reported as cause. The account manager acts on a seasonal usage dip.

15. Post-resolution quality audit

Pattern · T1

• Goal: Sample closed tickets for policy compliance and resolution quality at a rate humans cannot match.
• Loop: Sample closed tickets, evaluate each against a rubric, flag deviations, aggregate into per-agent and per-policy trends, publish the report.
• Tools and data: Ticket archive, policy documents, QA rubric, prior human QA scores for calibration.
• Human control: Findings never feed performance management directly. A human QA lead reviews flagged tickets before any coaching conversation.
• Failure mode: Rubric drift. The agent's interpretation of "empathetic" diverges from the team's and scores stop meaning anything.

Sales and revenue operations (16-21)

16. Inbound lead research and routing

Pattern · T1

• Goal: Give every inbound lead a researched context packet and a correct owner within minutes.
• Loop: Enrich from public sources, check for existing account and open opportunities, match against ICP criteria, assign territory and owner, write a briefing note.
• Tools and data: CRM, enrichment APIs, company website, product usage data, territory rules.
• Human control: Routing rules are deterministic code, not model judgment. The agent researches; the rules engine assigns.
• Failure mode: Enrichment matches the wrong entity with a similar name, and the wrong firmographics follow that record forever.

17. CRM hygiene against source-of-truth systems

Pattern · T2

• Goal: Keep the pipeline reflecting reality rather than optimism.
• Loop: Compare CRM records against calendar, email, product usage, and billing; detect stale stages, missing next steps, and contradicted close dates; propose corrections; apply the safe subset.
• Tools and data: CRM API, calendar, email metadata, product telemetry, billing.
• Human control: Field-level allowlist for autonomous writes. Stage and amount changes always require rep confirmation. Full change log with one-click revert.
• Failure mode: Overwriting a rep's deliberate manual entry with an inference from stale telemetry.

18. Deal risk review before forecast lock

Pattern · T1

• Goal: Surface the deals whose stated status is not supported by evidence.
• Loop: For each deal above a threshold, gather activity, stakeholder coverage, competitive mentions, and procurement signals; score against historical won/lost patterns; write a short risk memo per deal.
• Tools and data: CRM, email and call metadata, meeting notes, historical closed-deal corpus.
• Human control: Read-only. Memos go to the sales manager, never to the rep's forecast field.
• Failure mode: Penalizing deals that follow an unusual but legitimate buying process, teaching reps to game activity metrics.

19. Renewal preparation packet

Pattern · T1

• Goal: Walk into every renewal with the usage story, the support history, and the entitlement math already assembled.
• Loop: Trigger on renewal date minus N days, pull entitlement versus consumption, support incidents, feature adoption, and contract terms; compute upsell and downgrade scenarios; draft the packet.
• Tools and data: Contract repository, billing, product analytics, support archive, pricing rules.
• Human control: Pricing scenarios computed by a deterministic pricing engine, not generated. The agent assembles; it does not quote.
• Failure mode: A misread contract clause producing an entitlement number the customer can disprove in the meeting.

20. Competitive intelligence monitoring

Pattern · T1

• Goal: Keep a current, sourced view of competitor pricing, packaging, and public positioning.
• Loop: Crawl tracked sources on a schedule, diff against the last snapshot, verify material changes against a second source, classify significance, publish only genuine changes.
• Tools and data: Public web, pricing pages, changelogs, job boards, filings, snapshot store.
• Human control: Only public sources. No scraping behind authentication, no gated content, no competitor product accounts.
• Failure mode: A page template change read as a pricing change, generating a false alarm that reaches sales leadership.

21. Quote and order form assembly

Pattern · T3

• Goal: Produce a compliant quote from an agreed deal shape without a manual desk cycle.
• Loop: Read the deal terms, apply the price book and discount policy, check approval thresholds, assemble the document, run a compliance check, route for signature.
• Tools and data: CPQ system, price book, approval matrix, legal template library, e-signature.
• Human control: Every quote above the discount threshold requires named human approval. Non-standard terms halt the loop and route to legal. No autonomous signature authority.
• Failure mode: A stacked discount combination the policy engine permits individually but never intended in combination.

Marketing and content (22-27)

22. Content refresh against source drift

Pattern · T2

• Goal: Detect published content that has become factually stale and fix it.
• Loop: Re-verify the claims in existing articles against their cited primary sources, flag drift, draft corrected passages with updated citations, open an editorial change request.
• Tools and data: CMS, citation index, live source fetch, version history.
• Human control: Editor approves every published change. Citation changes are diffed explicitly, never silently applied.
• Failure mode: Updating a claim to match a source that itself changed for a reason the agent does not understand, propagating an error with a fresh citation attached.

23. Campaign brief to asset set

Deployed · T2

• Goal: Produce the full asset set for a launch from one brief, in parallel.
• Loop: Decompose the brief into asset types, dispatch specialized agents per asset, generate against brand constraints, self-check against the brief, assemble for review.
• Tools and data: Brand system, asset library, CMS, code generation environment, email platform.
• Human control: Brand and legal review before anything ships. Generated imagery labeled as synthetic where transparency obligations apply.
• Failure mode: Asset set that is internally consistent and collectively off-brief, because no single agent held the whole brief.
• Source: Google documents deploying multiple agents to execute a product launch workflow spanning website code generation, on-brand asset creation, and customer email (Gemini Enterprise Agent Platform).

24. SEO technical audit with fix proposals

Pattern · T2

• Goal: Find and fix the technical issues suppressing organic performance.
• Loop: Crawl the site, compare rendered output against expected structure, check schema validity, internal link depth, canonical consistency, and index coverage; cluster issues by root cause; propose template-level fixes as code.
• Tools and data: Crawler, search console API, rendered DOM, templates, schema validators.
• Human control: Template changes ship as reviewed PRs through the normal deploy pipeline. No direct CMS writes to live pages.
• Failure mode: A template fix that resolves the audit finding and breaks a rendering path the crawler never sampled.

25. Multi-source research briefing

Deployed · T1

• Goal: Produce a sourced briefing on a topic that requires reading across many documents.
• Loop: Plan sub-questions, search, read, evaluate whether the evidence answers the question, search again on gaps, synthesize with citations, stop when coverage is sufficient or the budget is spent.
• Tools and data: Web search, document retrieval, internal knowledge stores, citation tracking.
• Human control: Every claim carries a resolvable link. Uncited assertions are treated as the agent's inference and labeled as such.
• Failure mode: Circular sourcing, where three citations trace back to one unverified original.
• Source: Anthropic describes search tasks requiring multiple rounds of searching and analysis with an evaluator deciding whether further searching is warranted; OpenAI documents a deep research capability (Anthropic, OpenAI).

26. Paid channel anomaly detection

Pattern · T1

• Goal: Catch spend anomalies within hours instead of at the weekly review.
• Loop: Pull spend and conversion data on an interval, compare against expected ranges by segment, investigate outliers by drilling into creative, placement, and audience dimensions, alert with a diagnosis.
• Tools and data: Ad platform APIs, conversion data, historical baselines, creative metadata.
• Human control: No bid or budget write access. Alerts only. Pausing spend remains a human action.
• Failure mode: Alerting on a genuine demand shift as if it were a tracking failure, and vice versa.

27. Event and webinar follow-up sequencing

Pattern · T2

• Goal: Personalize follow-up based on what each attendee actually did, at attendee scale.
• Loop: Ingest attendance and engagement signals, segment by behavior, select the follow-up track, personalize against account context, queue sends, monitor engagement, adjust the next touch.
• Tools and data: Event platform, CRM, marketing automation, content library, consent records.
• Human control: Consent state checked as a hard gate outside the model. Send volume caps and suppression lists enforced by the platform, not by the prompt.
• Failure mode: Personalization that reveals tracking the recipient did not know about and finds unsettling.

Finance and accounting (28-33)

28. Invoice ingestion, coding, and exception routing

Pattern · T2

• Goal: Take invoices from arrival to correctly coded and matched without manual keying.
• Loop: Extract fields, match to purchase order and receipt, apply the coding rules, validate totals and tax, post the clean cases, route exceptions with a reason.
• Tools and data: Document store, OCR, ERP, PO and receiving records, chart of accounts, tax tables.
• Human control: Payment release stays a separate human-authorized step. Threshold-based mandatory review. No vendor bank detail changes ever executed by an agent.
• Failure mode: A duplicate invoice with a slightly altered number passing the duplicate check and being posted twice.

29. Month-end reconciliation and variance investigation

Pattern · T2

• Goal: Arrive at close with variances already investigated and explained.
• Loop: Pull sub-ledger and bank data, match transactions, identify unreconciled items, investigate each by tracing source documents, draft the explanation, escalate the unexplained.
• Tools and data: ERP, bank feeds, sub-ledgers, document repository, prior-period explanations.
• Human control: The agent never posts a journal entry. It drafts entries for controller approval. All source traces are attached and auditable.
• Failure mode: A plausible narrative attached to a variance whose real cause is an upstream data error, closing the investigation prematurely.

30. Expense policy compliance review

Pattern · T1

• Goal: Review every expense report against policy instead of sampling.
• Loop: Parse each report and receipt, check against policy rules and historical patterns, flag likely violations with the specific clause cited, aggregate patterns by team.
• Tools and data: Expense platform, receipt images, policy document, travel booking data, corporate card feed.
• Human control: Flags route to a human reviewer. No autonomous rejection, no autonomous notification to the employee.
• Failure mode: Systematic flagging of a legitimate pattern in one region because the policy has an unwritten local exception.

31. Collections outreach prioritization

Pattern · T1

• Goal: Focus collections effort where it will actually recover cash.
• Loop: Score open receivables by age, amount, payment history, and relationship signals; investigate top accounts for known disputes or service issues; produce a ranked worklist with context.
• Tools and data: AR ledger, payment history, CRM, support tickets, contract terms.
• Human control: Advisory ranking only. No customer contact. Credit hold decisions remain human.
• Failure mode: Prioritizing a customer whose non-payment is a live service dispute, converting a fixable issue into a churn event.

32. Rolling forecast variance narrative

Pattern · T1

• Goal: Explain forecast-versus-actual variance with traced drivers, not adjectives.
• Loop: Compute variance by dimension, decompose into volume, price, and mix effects, trace each material driver to source transactions, draft the narrative, flag unexplained residual.
• Tools and data: Financial data warehouse, forecast model outputs, transaction detail, operational metrics.
• Human control: FP&A owner reviews before distribution. The unexplained residual is always reported, never absorbed into a narrative.
• Failure mode: A confident driver attribution that is arithmetically consistent and causally wrong, which then anchors the next planning cycle.

33. Vendor contract and spend consolidation review

Pattern · T1

• Goal: Find duplicate tooling, auto-renewals, and unused licenses before they renew.
• Loop: Extract terms from contracts, join to actual spend and usage, identify overlap and underuse, compute the renewal calendar, produce a ranked action list with notice deadlines.
• Tools and data: Contract repository, AP data, SSO and license usage logs, vendor catalog.
• Human control: Procurement owns every cancellation. Notice-period math is verified by a human before any termination notice is sent.
• Failure mode: Recommending cancellation of a tool whose usage is low but load-bearing for one critical process.

People operations and recruiting (34-38)

The EU AI Act treats AI used for recruitment, candidate evaluation, promotion, termination, task allocation, and performance monitoring as high risk under Annex III (high-level summary). Every use case in this section carries regulatory obligations in the EU, and the design constraints below reflect that.

34. Job requisition intake and calibration

Pattern · T1

• Goal: Turn a vague hiring request into a calibrated, legally reviewed requisition.
• Loop: Interview the hiring manager through structured prompts, draft the requisition, compare against internal leveling and comparable roles, flag inconsistencies, iterate.
• Tools and data: HRIS, leveling framework, compensation bands, prior requisitions, job description templates.
• Human control: Compensation figures come from the band system, not from the model. HR business partner approves before posting.
• Failure mode: Requirements inflation copied from comparable postings, narrowing the funnel on criteria nobody actually needs.

35. Structured interview scheduling and logistics

Pattern · T2

• Goal: Coordinate multi-panel interview loops without a coordinator playing calendar tetris.
• Loop: Read panel requirements, query availability, propose slots respecting time zones and interviewer load, book, handle declines and reschedules, confirm.
• Tools and data: Calendars, ATS, interviewer pool with load limits, video conferencing, candidate preferences.
• Human control: Logistics only. The agent never evaluates a candidate or sees evaluative content. Candidate-facing messages use approved templates.
• Failure mode: Optimizing for interviewer convenience and scheduling a candidate's loop across a week, degrading their experience.

36. Interview note structuring against a rubric

Pattern · T2

• Goal: Make interview feedback comparable across interviewers by structuring it against the defined rubric.
• Loop: Take interviewer-submitted notes, map observations to rubric dimensions, flag dimensions with no supporting evidence, return to the interviewer for completion.
• Tools and data: ATS, rubric definitions, interviewer notes, structured feedback forms.
• Human control: The agent never scores and never ranks candidates. It restructures human observations and identifies gaps. Hiring decisions and scores remain entirely human, which is the design line that keeps this out of automated candidate evaluation.
• Failure mode: Restructuring that smooths a hedged human observation into a firmer claim than the interviewer made.

37. Onboarding provisioning orchestration

Pattern · T2

• Goal: Have a new hire's access, equipment, and first-week plan correct on day one.
• Loop: Read the role and team from HRIS, resolve the entitlement bundle, request provisioning per system, verify each grant landed, chase incomplete items, report exceptions.
• Tools and data: HRIS, IAM, device management, ticketing, role-based entitlement catalog.
• Human control: Entitlements come from a maintained role catalog, never inferred by the model. Privileged access requires named human approval regardless of role.
• Failure mode: Copying entitlements from a similar existing employee, silently propagating that employee's accumulated over-provisioning.

38. Policy question answering with source citation

Pattern · T1

• Goal: Answer employee policy questions accurately and consistently, with the clause attached.
• Loop: Retrieve candidate policy passages, verify the question is actually answered by them, answer with citation, escalate to HR when policy is silent or jurisdiction-specific.
• Tools and data: Policy repository with jurisdiction tagging, benefits documentation, HRIS for individual context.
• Human control: Escalation is the default for anything involving leave, accommodation, compensation, or termination. This is an assistant with retrieval, not an agent with authority.
• Failure mode: Answering with the wrong jurisdiction's policy, giving an employee guidance that contradicts their legal entitlement.

Legal, compliance, and risk (39-43)

39. Contract review against a clause playbook

Pattern · T1

• Goal: Give counsel a marked-up first pass showing every deviation from the standard position.
• Loop: Segment the agreement, classify each clause, compare against the playbook's preferred and fallback positions, mark deviations by severity, draft redlines for standard deviations.
• Tools and data: Contract lifecycle management system, clause playbook, precedent library, prior negotiated positions.
• Human control: Attorney reviews everything before it leaves the building. No autonomous transmission to a counterparty. Novel clause types halt the loop.
• Failure mode: Missing an unusual clause that does not resemble any playbook category, precisely because it does not resemble any playbook category.

40. Regulatory change monitoring

Pattern · T1

• Goal: Track rule changes in the jurisdictions that matter and map them to affected internal controls.
• Loop: Monitor official sources on a schedule, detect published changes, read the change, map it to the internal control inventory, draft an impact note, route to the control owner.
• Tools and data: Regulator publication feeds, official gazette sources, internal control register, prior impact assessments.
• Human control: Compliance officer validates every mapping. The agent monitors and drafts; it does not assess compliance status.
• Failure mode: Missing a change published only in a format the monitor does not parse, producing false confidence in coverage.

41. Data subject access request assembly

Pattern · T2

• Goal: Locate and assemble all personal data for a requester across systems within the statutory window.
• Loop: Resolve the identity to internal keys, query each system in the data map, collect and classify results, apply redaction rules for third-party data, assemble the package, log the trail.
• Tools and data: Data inventory, identity resolution, per-system query interfaces, redaction rules, request tracker.
• Human control: Privacy officer reviews the package before release. Identity verification is a separate human-controlled step. Every access is logged, including the agent's.
• Failure mode: An incomplete data map. The agent searches every system it knows about and confidently reports completeness it cannot have.

42. Third-party risk assessment intake

Pattern · T1

• Goal: Process vendor security questionnaires and evidence into a consistent risk position.
• Loop: Parse the completed questionnaire and attached evidence, verify claims against the artifacts, identify contradictions and gaps, generate follow-up questions, draft the risk summary.
• Tools and data: GRC platform, questionnaire responses, audit reports, certification registries, prior assessments.
• Human control: Risk acceptance is a named human decision. The agent produces findings, never a pass/fail verdict.
• Failure mode: Accepting a certification at face value without checking scope, so an in-scope system is covered by an out-of-scope attestation.

43. Marketing claim substantiation review

Pattern · T1

• Goal: Ensure every public performance or comparative claim has traceable support before publication.
• Loop: Extract claims from draft content, classify each as factual, comparative, or puffery, locate the substantiation, flag unsupported claims, block publication on unresolved items.
• Tools and data: Content drafts, substantiation repository, benchmark results, prior legal approvals.
• Human control: Legal sign-off required on all comparative and performance claims. The agent's block is advisory; the editorial gate is real.
• Failure mode: Classifying a substantive claim as puffery, letting an unsupported assertion through the one control designed to catch it.

Data and analytics (44-48)

44. Pipeline failure diagnosis and safe recovery

Pattern · T2

• Goal: Diagnose broken data pipelines and recover the safe cases automatically.
• Loop: Detect failure, read logs and lineage, classify the cause, apply the matching runbook for known-safe causes, verify recovery, escalate anything unrecognized.
• Tools and data: Orchestrator, lineage graph, logs, runbook library, warehouse.
• Human control: Only pre-approved runbooks are executable. Anything outside the runbook library escalates. All recovery actions are idempotent and logged.
• Failure mode: A retry that succeeds mechanically while emitting duplicate rows downstream because the sink was not idempotent.

45. Data quality monitoring with root cause tracing

Pattern · T1

• Goal: Catch quality regressions and trace them to the change that caused them.
• Loop: Run quality checks on a schedule, detect violations, walk the lineage graph upstream, correlate against deploys and schema changes, name the likely cause, alert the owner.
• Tools and data: Quality test framework, lineage metadata, deploy history, schema registry, ownership map.
• Human control: No pipeline modification authority. Alerts go to the owning team, not to a general channel.
• Failure mode: Alert storms during a legitimate large migration, drowning the one unrelated regression that mattered.

46. Ad hoc analytics request handling

Pattern · T2

• Goal: Answer routine "what is the number for X" requests without consuming analyst time.
• Loop: Clarify the question, identify the certified data model, write the query, validate against known control totals, produce the result with caveats, escalate ambiguous definitions.
• Tools and data: Semantic layer, certified data models, warehouse read replica, metric definitions, control totals.
• Human control: Read-only against a replica. Queries restricted to the certified semantic layer, not raw tables. Cost caps enforced by the warehouse.
• Failure mode: Answering with a technically correct number computed on a different definition than the requester meant, which is how two teams end up with two revenue numbers.

47. Metric definition drift audit

Pattern · T1

• Goal: Find where the same metric name means different things across dashboards and reports.
• Loop: Parse dashboard and report definitions, normalize the logic, cluster by metric name, detect semantic divergence, report conflicts with the exact differing logic.
• Tools and data: BI tool metadata APIs, query logs, semantic layer definitions, metric catalog.
• Human control: Analytics governance owner resolves each conflict. The agent never edits a definition.
• Failure mode: Flagging intentional variants, such as bookings gross versus net, as drift, burning credibility on the first report.

48. Experiment analysis readout

Pattern · T1

• Goal: Produce consistent, statistically honest experiment readouts.
• Loop: Pull assignment and outcome data, validate randomization and sample ratio, compute the pre-registered metrics, check guardrail metrics, draft the readout with explicit uncertainty.
• Tools and data: Experiment platform, warehouse, pre-registration document, statistical library.
• Human control: Metrics must be pre-registered. The agent cannot select metrics post hoc. Data scientist reviews any readout that drives a launch decision.
• Failure mode: Reporting a segment result the experiment was never powered to detect, which then becomes a launch justification.

---

Part B: Use cases by industry

Healthcare and life sciences (49-53)

The EU AI Act classifies emergency call triage and dispatch prioritization, and risk assessment and pricing in health and life insurance, as high-risk Annex III uses. Clinical decision support is separately regulated as a medical device in most jurisdictions. Nothing in this section is a clinical decision-maker.

49. Prior authorization packet assembly

Pattern · T2

• Goal: Assemble a complete, payer-specific prior authorization submission from the chart.
• Loop: Read the order, retrieve the payer's criteria, search the chart for the required clinical evidence, identify missing documentation, assemble the packet, flag gaps for the clinician.
• Tools and data: EHR with scoped access, payer policy documents, clinical documentation, submission portal.
• Human control: Clinician attests to clinical accuracy and submits. The agent assembles evidence; it never asserts medical necessity on its own authority.
• Failure mode: Pulling a chart element that supports the criterion textually but belongs to a different episode of care.

50. Clinical documentation gap detection

Pattern · T1

• Goal: Flag documentation that is incomplete relative to the care actually delivered.
• Loop: Compare orders, results, and notes for an encounter, detect unaddressed results and missing elements, generate a specific query to the clinician, track resolution.
• Tools and data: EHR, encounter data, documentation standards, coding guidelines.
• Human control: Queries go to clinicians as questions, never as suggested text to accept. No autonomous chart modification of any kind.
• Failure mode: Query volume that trains clinicians to dismiss without reading, defeating the control and the purpose simultaneously.

51. Clinical trial site feasibility screening

Pattern · T1

• Goal: Rank candidate trial sites against protocol requirements using real data.
• Loop: Parse the protocol's inclusion and exclusion criteria, query de-identified population data per site, model realistic enrollment, assess site capability and history, produce a ranked assessment.
• Tools and data: De-identified population data, site performance history, protocol document, investigator registries.
• Human control: De-identified data only. Clinical operations validates every enrollment estimate. Site selection stays a human decision.
• Failure mode: Overestimating eligible population by ignoring a criterion that is not coded in structured data.

52. Pharmacovigilance case intake triage

Pattern · T2

• Goal: Route incoming adverse event reports to the correct severity queue within the regulatory clock.
• Loop: Parse the report from any channel, extract event, product, and outcome, code against the standard terminology, apply seriousness criteria, route, start the reporting clock.
• Tools and data: Safety database, standardized medical terminology, product dictionary, regulatory timelines.
• Human control: Safety physician reviews every case before regulatory submission. Seriousness downgrades are never autonomous; upgrades may be.
• Failure mode: Missing an implied serious outcome expressed in colloquial language in a patient-submitted narrative.

53. Literature surveillance for a research program

Pattern · T1

• Goal: Maintain current awareness across a research area with traceable citations.
• Loop: Query bibliographic sources on a schedule, screen abstracts against inclusion criteria, retrieve full text for candidates, extract structured findings, update the evidence table.
• Tools and data: Bibliographic APIs, full-text repositories, licensed journal access, structured evidence store.
• Human control: Researchers verify every extraction against the source before it informs a decision. Preprints labeled distinctly from peer-reviewed work.
• Failure mode: Extracting a result from an abstract without the qualifications in the methods section, which is exactly the error that compounds through an evidence table.

Financial services and insurance (54-58)

The EU AI Act treats creditworthiness evaluation, except for financial fraud detection, and risk assessment and pricing in life and health insurance, as high-risk Annex III uses.

54. Transaction fraud investigation

Pattern · T2

• Goal: Investigate flagged transactions faster than a queue of analysts can.
• Loop: Take the model-flagged transaction, gather account history, device and location signals, and network relationships; test fraud hypotheses; produce a disposition recommendation with evidence.
• Tools and data: Transaction store, device fingerprinting, customer profile, known fraud patterns, case management.
• Human control: Account restriction and freeze decisions require human authorization. The agent recommends. Every recommendation carries the evidence chain.
• Failure mode: Learned patterns that correlate with a demographic proxy, producing disparate false positive rates that surface as a fair-lending problem.

55. AML alert enrichment and narrative drafting

Pattern · T2

• Goal: Reduce the investigative overhead on each alert without reducing scrutiny.
• Loop: Gather transaction context, counterparty information, adverse media, and prior alerts; assemble the timeline; draft the investigative narrative; recommend escalate or close with reasoning.
• Tools and data: Transaction monitoring system, KYC records, sanctions and PEP lists, adverse media sources, case management.
• Human control: Every SAR filing decision is a named human decision. Closure of an alert requires human sign-off. Full audit trail retained for examiners.
• Failure mode: A well-written narrative that makes a weak case look investigated, degrading the quality signal regulators rely on.

56. Insurance claim intake and documentation completeness

Pattern · T2

• Goal: Get claims to an adjuster with complete documentation on the first pass.
• Loop: Parse the FNOL, extract structured facts, check the policy for coverage applicability, identify missing documentation, request it from the claimant, verify receipt, route when complete.
• Tools and data: Policy administration system, claims system, document intake, coverage rules, communication channel.
• Human control: Coverage determinations and claim denials are human decisions. The agent verifies completeness, not entitlement.
• Failure mode: Requesting documentation the claimant cannot obtain, creating an effective denial through process friction.

57. Regulatory reporting package assembly

Pattern · T2

• Goal: Assemble periodic regulatory returns with traced provenance for every figure.
• Loop: Pull source data per line item, apply the reporting rules, validate against edit checks and prior periods, trace each figure to its source, flag variances, assemble the package.
• Tools and data: Data warehouse, reporting rule definitions, validation rules, prior submissions, lineage metadata.
• Human control: Attestation is a named human act. Every figure must be traceable to source before submission. No autonomous filing.
• Failure mode: A rule interpretation change applied silently, so the period-over-period comparison a regulator reads is not comparable.

58. Portfolio document diligence

Pattern · T1

• Goal: Extract and cross-check key terms across a large document set during diligence.
• Loop: Classify each document, extract the term set per type, cross-reference for contradictions between documents, flag anomalies and missing documents, build the term summary.
• Tools and data: Virtual data room, document classifiers, term extraction schema, checklist.
• Human control: Deal team verifies every extracted term against the source document before it informs valuation. Extraction confidence surfaced per field.
• Failure mode: A term correctly extracted from a superseded version of an agreement that is still sitting in the data room.

Retail and e-commerce (59-62)

59. Product catalog enrichment and normalization

Pattern · T2

• Goal: Produce complete, consistent, attribute-normalized listings from messy supplier data.
• Loop: Ingest supplier feeds, normalize attributes to the internal taxonomy, detect missing required attributes, research from supplier documentation, generate copy, validate against category rules, publish or queue.
• Tools and data: PIM, supplier feeds and spec sheets, category taxonomy, image store, compliance rules.
• Human control: Regulated categories, including anything with safety, age, or health claims, route to human review without exception. Price and availability are never model-generated.
• Failure mode: Confident attribute inference for a spec that is missing from the source, producing a filterable attribute that is wrong.

60. Inventory exception investigation

Pattern · T1

• Goal: Explain stock discrepancies rather than just report them.
• Loop: Detect variance between system and counted stock, trace movements backward through receipts, transfers, sales, and returns, identify the likely break point, produce an investigation note.
• Tools and data: WMS, ERP, POS transaction log, transfer records, cycle count data.
• Human control: Inventory adjustments require human authorization. The agent traces and proposes; it does not write to stock records.
• Failure mode: Attributing shrinkage to a receiving error when the real cause is a systematic scanning failure that will keep recurring.

61. Return and warranty disposition

Pattern · T3

• Goal: Decide the correct disposition for returned items consistently and quickly.
• Loop: Read the return reason, order history, and item condition evidence; apply the policy; check for abuse patterns; decide refund, replace, repair, or deny; execute the permitted subset.
• Tools and data: Order management, returns platform, policy engine, condition images, customer history.
• Human control: Denials always route to a human. Refund value capped per transaction and per customer per period, enforced outside the model. Abuse flags are advisory only.
• Failure mode: Systematic leniency on an edge case, discovered by a small number of customers, exploited at scale before reconciliation catches it.

62. Marketplace listing compliance sweep

Pattern · T2

• Goal: Find listings that violate marketplace or regulatory rules before enforcement does.
• Loop: Sample and scan listings against rule definitions, evaluate flagged listings in context, classify severity, propose the correction, queue for action.
• Tools and data: Listing data, marketplace policy documents, regulatory requirements by jurisdiction, image analysis.
• Human control: Delisting is a human action. Corrections to live listings go through the normal publishing review.
• Failure mode: Over-broad rule interpretation that suppresses compliant listings, with revenue impact that is hard to detect and harder to reverse.

Manufacturing and supply chain (63-66)

63. Supplier disruption monitoring and impact tracing

Pattern · T1

• Goal: Know within hours which products a supplier disruption will affect.
• Loop: Monitor supplier and logistics signals, detect a disruption event, trace through the bill of materials to affected finished goods, compute on-hand coverage, model the shortfall date, alert with the impact map.
• Tools and data: Supplier master, BOM, inventory positions, in-transit data, public logistics and news sources.
• Human control: Advisory. No purchase orders, no allocation changes, no supplier communication. Supply planners decide.
• Failure mode: An incomplete BOM at the sub-tier level, so the impact map misses the component that actually stops the line.

64. Maintenance work order triage and preparation

Pattern · T2

• Goal: Get technicians to the job with the right diagnosis, parts, and procedure already staged.
• Loop: Read the fault signal or report, retrieve asset history and manuals, form a probable-cause list, identify required parts and check availability, draft the work order with procedure references.
• Tools and data: CMMS, sensor and telemetry history, equipment manuals, parts inventory, technician skills matrix.
• Human control: Safety-critical procedures require a qualified human sign-off before work begins. Lockout/tagout requirements are never model-generated.
• Failure mode: Anchoring the technician on the most statistically likely cause, extending diagnosis time when the actual fault is unusual.

65. Quality deviation investigation support

Pattern · T1

• Goal: Accelerate root cause analysis on quality deviations with full data traceability.
• Loop: Gather batch records, process parameters, material lots, and environmental data for the affected window; compare against passing batches; identify differing variables; assemble the evidence set.
• Tools and data: MES, LIMS, batch records, environmental monitoring, material genealogy.
• Human control: Quality engineers own the root cause determination and every CAPA. In regulated manufacturing, the agent's output is an input to the investigation record, never the record itself.
• Failure mode: Surfacing a statistically differing variable with no mechanistic relationship, sending an investigation down a false path that then has to be documented and closed.

66. Demand and supply plan reconciliation

Pattern · T1

• Goal: Find where the demand plan and supply plan disagree, and why, before the S&OP meeting.
• Loop: Compare plans across horizons and dimensions, identify material gaps, trace each gap to constraint, assumption, or data error, draft the exception list with proposed discussion points.
• Tools and data: Planning system, capacity model, supplier commitments, demand forecast, prior plan versions.
• Human control: No plan modification authority. The output is a meeting agenda, not a decision.
• Failure mode: Treating an intentional strategic build-ahead as a planning error, wasting the meeting's scarcest resource on a non-issue.

Public sector and education (67-69)

The EU AI Act classifies AI used to determine access or admission to education, evaluate learning outcomes, and assess eligibility for public benefits as high-risk Annex III uses. It also prohibits inferring emotions in educational institutions outside medical or safety reasons.

67. Public records request processing

Pattern · T2

• Goal: Locate responsive records and apply exemption review within statutory deadlines.
• Loop: Parse the request scope, search records systems, assess responsiveness, apply exemption criteria per document, prepare the redaction proposal, assemble the release package with a log.
• Tools and data: Records management systems, email archives, exemption criteria, redaction tooling, request tracker.
• Human control: Records officer reviews every exemption and redaction before release. Withholding decisions are always human and always documented.
• Failure mode: Over-redaction that is defensible per document and, in aggregate, defeats the transparency the statute requires.

68. Benefits application completeness and documentation support

Pattern · T1

• Goal: Help applicants submit complete applications the first time.
• Loop: Review the submitted application against program requirements, identify missing or inconsistent items, generate a plain-language list of what is needed, verify receipt, confirm completeness.
• Tools and data: Application system, program requirement definitions, document intake, plain-language templates.
• Human control: Eligibility determination is entirely human. The agent checks completeness only, and cannot deny, delay, or deprioritize an application. A human channel is always available and always advertised.
• Failure mode: Requesting documentation from an applicant who is exempt from that requirement, creating a barrier that falls hardest on the people the program exists to serve.

69. Course material alignment and accessibility audit

Pattern · T1

• Goal: Check that course materials match stated learning objectives and meet accessibility standards.
• Loop: Parse materials and objectives, map coverage per objective, identify uncovered objectives and unmapped content, run accessibility checks, produce a remediation list.
• Tools and data: LMS, course materials, learning objective definitions, accessibility standards, captioning and alt-text checks.
• Human control: Instructors own all pedagogical decisions. The agent audits materials, never students. No student data is in scope.
• Failure mode: Reporting surface coverage of an objective the material technically mentions and never actually teaches.

Energy, utilities, and field service (70-72)

The EU AI Act classifies safety components in the management and operation of critical infrastructure, including water, gas, heating, and electricity supply, as high-risk Annex III uses. Nothing in this section touches a control system.

70. Outage report correlation and crew briefing

Pattern · T1

• Goal: Convert scattered customer outage reports into a probable fault location and a briefed crew.
• Loop: Cluster reports geographically and topologically, correlate with meter and SCADA telemetry, infer the probable fault segment, assemble the network and access briefing, notify dispatch.
• Tools and data: Outage management system, network topology, meter data, customer reports, GIS, weather.
• Human control: Read-only against operational systems. No switching, no field device commands, no control actions of any kind. Dispatchers decide crew assignment.
• Failure mode: A topology model that is out of date after a recent reconfiguration, sending a crew to the wrong segment during a storm.

71. Field service job packet assembly

Pattern · T2

• Goal: Ensure the technician arrives with the right parts, permissions, and site knowledge.
• Loop: Read the job, retrieve asset and site history, identify likely parts, check van and depot stock, confirm access and permit requirements, assemble the packet, flag prerequisites.
• Tools and data: Field service management, asset records, parts inventory, site access records, permit systems.
• Human control: Permit-to-work and safety qualification checks are enforced by the FSM system as hard gates, not by the model.
• Failure mode: Predicting parts from the reported symptom and being wrong often enough that technicians stop trusting the packet and revert to guessing.

72. Energy consumption anomaly investigation

Pattern · T1

• Goal: Distinguish genuine consumption anomalies from metering and data problems.
• Loop: Detect deviation from the expected profile, check for meter communication and estimation flags, compare against weather-normalized baselines and peer sites, classify the cause, alert with a diagnosis.
• Tools and data: Interval meter data, weather data, building or site metadata, meter health records, historical baselines.
• Human control: No billing adjustments. No customer contact. Findings route to the analyst who owns the account.
• Failure mode: Classifying a real equipment fault as an estimation artifact, so the fault persists and the bill arrives anyway.

Media, travel, and professional services (73-75)

73. Rights and licensing clearance check

Pattern · T1

• Goal: Verify that every asset in a production has clearance for its intended use and territory.
• Loop: Inventory the assets in the cut, match each to a license record, compare intended use, territory, and term against granted rights, flag gaps and expiries, produce the clearance report.
• Tools and data: Asset management system, rights database, license agreements, production metadata, music cue sheets.
• Human control: Rights counsel signs off before distribution. Unmatched assets block release rather than defaulting to cleared.
• Failure mode: Matching an asset to a license for a similar asset, producing a clearance report that is complete and wrong.

74. Travel disruption rebooking preparation

Pattern · T3

• Goal: Have viable rebooking options ready before the traveler learns their flight is cancelled.
• Loop: Detect the disruption, identify affected itineraries, search alternatives respecting fare rules and policy, rank by traveler impact, hold inventory where permitted, present options.
• Tools and data: GDS or booking APIs, fare rules, corporate travel policy, traveler profiles, disruption feeds.
• Human control: Ticket reissue and any cost-incurring commitment require explicit traveler or travel-manager confirmation. Holds expire automatically rather than converting.
• Failure mode: Holding inventory across a large affected population and creating the very scarcity the rebooking is competing against.

75. Engagement scoping from a client brief

Pattern · T1

• Goal: Turn a client brief into a scoped, staffed, priced draft proposal grounded in past work.
• Loop: Parse the brief, retrieve comparable past engagements, decompose into workstreams, estimate effort from historical actuals, check staffing availability, draft the scope document.
• Tools and data: Engagement archive with actuals, resource management system, rate card, methodology library, CRM.
• Human control: Partner reviews and owns scope, price, and commitment. Estimates derived from historical actuals, not generated. No client-facing transmission by the agent.
• Failure mode: Anchoring on comparable engagements that succeeded, ignoring the ones that overran, producing systematically optimistic estimates.

---

The suitability test: should this be an agent at all

Run any candidate through these seven questions before writing a line of code. Score one point each.

1. Is the path unpredictable? Can you not know in advance how many steps the task takes or which tools it needs? If you can draw the flowchart, build the flowchart. This is the single highest-weight question.

2. Is there ground truth in the environment? Can the system get real feedback on whether each step worked, from a test suite, a validation rule, an API response, a diff? Anthropic's guidance is direct on this: agents must gain ground truth from the environment at each step to assess progress. Without it, the agent is grading its own homework.

3. Is the action space bounded and enumerable? Can you list every tool it may call, and is each one individually safe to call at the frequency the agent might call it?

4. Are the actions reversible, or gated? Every irreversible action, meaning money out, messages sent, records deleted, contracts signed, needs to either be reversible or sit behind a human approval. Not both is required. Neither is disqualifying.

5. Is the cost of a wrong step bounded? Not the cost of a wrong final answer, the cost of a wrong intermediate step multiplied by the iteration cap. Agents compound errors; that is their defining risk.

6. Can a human meaningfully review the output? If review takes as long as doing the work, you have moved the bottleneck, not removed it. If the output is unreviewable in practice, humans will rubber-stamp it, and your control is theater.

7. Is the latency and cost profile acceptable? Agentic systems trade latency and cost for task performance. If your use case is latency-sensitive and the task is not hard, you are paying for nothing.

Scoring.

• 6-7 points: Build the agent. Start at Tier 1, earn Tier 2.
• 4-5: Build a fixed workflow with model calls at specific nodes. You get most of the value at a fraction of the risk.
• 2-3: Build an assistant with retrieval. A human stays in the loop every turn.
• 0-1: Do not use a model here. You have a data problem, a process problem, or a spec problem wearing an AI costume.

If you scored 6-7, how to build an AI agent covers the implementation, and the agent architectures guide covers which topology to pick. If you scored 4-5, 100 AI automation ideas is the better starting inventory.

---

Risk tiers: what controls each tier requires

Tiers here are engineering controls, not legal classifications. Legal classification is separate and additional. Under the EU AI Act, systems in areas such as employment, creditworthiness, essential services, education, law enforcement, and critical infrastructure carry provider obligations including a lifecycle risk management system, data governance, technical documentation, automatic record-keeping, instructions for use, human oversight by design, and accuracy and cybersecurity requirements. Limited-risk systems carry transparency obligations, meaning users must know they are interacting with AI.

Tier 1: read and recommend

The agent reads systems and produces output for humans. It writes nothing to a system of record.

Required controls: scoped read-only credentials; citation or provenance on every claim; output delivered to a named human owner rather than a broadcast channel; an alert budget so signal survives; logging of every read for audit.

Most of the 75 cases above start here. Many should stay here permanently. Tier 1 is not a lesser design, it is the correct design whenever human judgment is the actual bottleneck-breaker.

Tier 2: reversible writes in controlled surfaces

The agent writes, but only to surfaces where a human reviews before the change reaches production or a customer. Pull requests, draft documents, queued tickets, staging environments.

Required controls: everything in Tier 1, plus a field-level or resource-level allowlist for writes; an iteration cap and a wall-clock timeout; a complete change log with one-step revert; sandboxed execution for anything that runs code, per Anthropic's recommendation of extensive testing in sandboxed environments with appropriate guardrails; and an explicit escalation path the agent takes when blocked rather than improvising.

The design test for Tier 2: if the agent did the wrong thing on every run for a week and nobody noticed, what would the damage be? If the answer is "unrecoverable," it is not Tier 2.

Tier 3: irreversible or externally visible action

The agent moves money, sends messages to customers, changes entitlements, or takes any action that cannot be quietly undone.

Required controls: everything in Tier 2, plus per-action and per-period value caps enforced outside the model, in code the agent cannot reason its way past; named human approval for anything above threshold; a kill switch that halts in-flight execution, not just new starts; staged rollout with a manual gate between stages; independent reconciliation on a schedule that does not depend on the agent's own reporting; and a documented incident procedure that starts with revoking credentials.

Two rules that are not negotiable at Tier 3. Caps live in the tool layer, never in the prompt, because a prompt is a suggestion and a permission check is not. And the audit log records what the agent did and why it decided to, because a log of actions without reasoning is unusable during an incident.

Cross-tier requirements

Regardless of tier: every agent has a named human owner; every agent has a documented stopping condition; every agent's tool definitions are treated as a first-class interface and tested as one, since Anthropic reports spending more time optimizing tools than prompts when building their SWE-bench agent; and every agent is evaluated against a fixed test set before and after any prompt, model, or tool change. Model providers ship evaluation and guardrail tooling for exactly this purpose (OpenAI evals, OpenAI guardrails and approvals).

---

What connects the agent to your systems

Every use case above depends on the agent reaching real tools and real data. That integration layer has largely converged on the Model Context Protocol, an open standard for connecting AI applications to external systems including local files, databases, search tools, and workflow-specific prompts. MCP is supported across clients including Claude, ChatGPT, Visual Studio Code, and Cursor (modelcontextprotocol.io).

The practical implication for the list above: the hard part of most of these use cases is not the agent. It is the tool surface. Anthropic's guidance to invest as much effort in the agent-computer interface as teams historically invested in human-computer interfaces holds up. A tool with an ambiguous parameter name produces an agent that fails in ways that look like reasoning failures and are not.

---

Frequently asked questions

What is the difference between an AI agent and a chatbot?

A chatbot responds to a user turn by turn; the user decides what happens next. An agent decides for itself what to do next, calls tools to act, reads the result, and keeps going until a stopping condition is met. The practical test: remove the human from the conversation. A chatbot stops. An agent continues.

Are these 75 use cases all in production somewhere?

No, and the labels say which are which. Entries marked "Deployed" link to a vendor's own documentation of that capability. Entries marked "Pattern" are architectures that are buildable with current tooling but that I am not claiming any named organization runs in production. No ROI figures appear anywhere in this article because vendor-supplied ROI is marketing, not evidence.

Which use case should a team start with?

The one where the environment can tell the agent whether it succeeded, and where a wrong answer costs a review cycle rather than money. Software engineering is the usual answer because tests are an oracle. Anthropic names coding and customer support as the two domains where agents have shown the most value, and gives the same reason in both cases: clear success criteria, feedback loops, and meaningful human oversight.

How much autonomy should an agent have on day one?

Tier 1. Read-only, output to a named human. Move to Tier 2 when you have a measured error rate on a fixed evaluation set and a revert path. Move to Tier 3 when you have value caps in code, a kill switch, and independent reconciliation. Teams that skip to Tier 3 do not discover their error rate until it costs something.

Do agents replace fixed workflows?

No. Workflows are better wherever the path is predictable, because they are cheaper, faster, and more consistent. Anthropic's own recommendation is to find the simplest solution possible and only increase complexity when needed, which sometimes means not building an agentic system at all. A large fraction of what gets marketed as agent work should be a workflow with model calls at specific nodes.

What is the most common way agent projects fail?

Compounding error across steps with no environmental feedback to catch it. The second most common is a tool surface that is ambiguous enough that the agent misuses it and the failure is misdiagnosed as a model limitation. The third is a human review step that nobody can actually perform at the volume produced, which quietly becomes a rubber stamp.

How do regulations apply to these use cases?

Domain, not technology, drives most obligations. Under the EU AI Act, uses in recruitment and worker management, creditworthiness assessment, essential public and private services, education access and evaluation, critical infrastructure safety components, and law enforcement fall under Annex III high-risk classification, carrying requirements including human oversight by design, record-keeping, data governance, and technical documentation. Limited-risk systems carry transparency obligations: end users must know they are interacting with AI. Check the classification before you scope the build, not after.

Can one agent handle several of these use cases?

Usually it should not. Narrow agents with small, well-documented toolsets are easier to evaluate, easier to permission, and easier to debug. When a task genuinely spans domains, an orchestrator that delegates to specialized agents is the better shape than one agent with a large toolset. Both Anthropic and OpenAI document orchestration and subagent patterns for exactly this reason.

Where do I see AGNT-specific implementations?

/use-cases/ has the deployed scenarios. 100 AI automation ideas covers the broader automation surface including the non-agentic majority. How to build an AI agent is the implementation walkthrough, and the AI agent architectures guide covers topology selection.

Put the use case into production with AGNT

AGNT combines agents, visual workflows, goals, tools, memory, plugins, MCP, approvals, evaluations, and traces in one local-first runtime. Use it when the use case needs more than a demo loop and you want the operating state on infrastructure you control. Download AGNT or review the source.

---

Sources

All primary sources were retrieved on 11 August 2026.

• Anthropic, "Building effective agents," Anthropic Engineering. https://www.anthropic.com/engineering/building-effective-agents
• Anthropic, "Claude Code overview," Anthropic documentation. https://docs.anthropic.com/en/docs/claude-code/overview
• Anthropic, Claude Code subagents, routines, GitHub Actions, GitLab CI/CD, and Slack integration documentation. https://docs.anthropic.com/docs/en/sub-agents · https://docs.anthropic.com/docs/en/routines · https://docs.anthropic.com/docs/en/github-actions · https://docs.anthropic.com/docs/en/slack
• Model Context Protocol, "Introduction." https://modelcontextprotocol.io/introduction
• OpenAI, developer documentation index covering Agents SDK, Agent Builder, guardrails and approvals, agent evals, deep research, Codex code review, and Codex Security. https://developers.openai.com/api/docs/guides/agents · https://developers.openai.com/codex/code-review · https://developers.openai.com/codex/security/plugin
• Google Cloud, "Gemini Enterprise Agent Platform" product documentation. https://cloud.google.com/products/agent-builder
• Future of Life Institute, "High-level summary of the AI Act," including Annex III high-risk classifications and Article 5 prohibitions, with links to the Act text. https://artificialintelligenceact.eu/high-level-summary/
• NIST, AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework

Every use case not carrying a source link is labeled "Pattern" and represents an implementation design, not a documented deployment.