AI Agent Use Case Library: 100 Workflow Ideas by Department, Indexed by What the Agent Writes

AI agent use cases sort by function into ten departments: sales, marketing, customer support, finance, HR, IT and service desk, operations, engineering, legal, and data. This library names 100 workflow ideas across those departments and indexes each one by the action the agent takes and the cost of reversing that action, because a department label never predicts whether the workflow survives production.

Essential Insights

• An AI agent use case library is an index of candidate workflows, not a ranked list of products to shop.
• Ten department labels in this library resolve to six repeating action patterns: retrieve, triage, draft, reconcile, monitor, and write.
• Twelve pages competing for this query publish a use-case count between 7 and 42, and the count is the least useful field on the page.
• Reversibility, not ticket volume, decides which of the hundred ideas a small team can actually run first.
• Department indexes hide duplicates, because the same reconcile-two-records workflow shows up in finance, operations, and sales wearing three names.
• The five-type agent taxonomy describes capability, and a use case library has to describe work.
• Every entry needs a trigger, a tool scope, a write boundary, and a named reviewer before it stops being an idea.

What an AI Agent Use Case Library Actually Indexes

An AI agent use case library indexes candidate workflows by the work they contain, which is a different artifact from the ranked listicle the category keeps publishing. Every list in this category opens by telling you agents are transformative, and the count is more informative than the adjective. Twelve of the pages competing for this query on August 19, 2026 advertise a count (7, 8, 10, 12, 15, 16, 22, 23, 24, 25, 30, and 42 use cases), and across the three we read end to end not one entry carries a reversibility class, an oversight cost, or a named owner.

The numbers those pages do carry are outcome numbers, and they are good ones. IBM's use-case explainer reports that 80 percent of executives are increasing agentic AI investment, with spending projected to nearly triple by 2027 (IBM). Atomicwork's roundup, updated April 20, 2026, cites Gartner's projection that nearly 40 percent of enterprise applications will embed task-specific agents by the end of 2026, up from less than 5 percent in 2025 (Atomicwork). Parallel Loop, publishing July 25, 2026, attaches Klarna's reported two-thirds of service chats and the work of 700 full-time agents, plus a National Bureau of Economic Research study of more than 5,000 support agents that found a 14 percent average productivity gain and 34 percent for the least experienced staff (Parallel Loop).

Outcome numbers answer a question nobody choosing a first workflow is asking. The operator's question is narrower and harder: which of these hundred things can this team run next quarter without hiring someone to watch it. Marshal indexes a use case library by what the agent writes and who reverses it, because the department label predicts nothing about whether the workflow can survive a bad Tuesday.

Six Action Patterns Hide Behind Ten Department Labels

Department labels in an agent use case library are packaging, and the six action patterns underneath are the operative part. Retrieve and summarize: the agent reads systems and returns an answer, writing nothing anywhere. Triage and route: the agent classifies an incoming item and assigns an owner. Draft for approval: the agent produces work a human still sends. Reconcile two records: the agent compares two systems of record and closes the gap between them. Monitor and alert: the agent watches a threshold and escalates when it breaks. Execute a write: the agent changes a record, a permission, a payment, or a customer commitment.

Sort the hundred ideas by those six and the duplicates surface immediately. Invoice matching in finance, inventory reconciliation in operations, and CRM writeback in sales are one pattern with three department costumes, which is why our prior map of use cases by business function reads as a geography rather than a shortlist. The textbook five-type taxonomy (simple reflex, model-based reflex, goal-based, utility-based, and learning agents) describes what an agent is capable of, not what it is permitted to touch. Capability taxonomies sort vendors. Action patterns sort exposure.

Consensus says start with the highest-volume workflow, and volume only tells you where the pain is; the part nobody prints is that a cheap reversal beats a big number every time. A retrieve-and-summarize agent that is wrong costs a reread. An execute-a-write agent that is wrong costs a refund, a permission, or a customer.

The Hundred: Ten Departments, Ten Workflows Each

The library below names 100 agent workflow ideas, ten per department, each written short enough to score in a single meeting. A hundred ideas is a shopping list, and the invoice arrives as oversight hours.

• Sales. Inbound lead qualification against written criteria; routing by territory and round robin; enrichment from CRM records; meeting booking and reschedules; pre-call briefs; pipeline hygiene sweeps; stalled-deal nudges; quote and pricing approval prep; renewal risk flags; CRM writeback after every touch.
• Marketing. Campaign performance digests; audience segmentation refreshes; content repurposing into three formats; brand mention monitoring; competitor page change alerts; landing-page brief drafting; UTM and taxonomy cleanup; lead-source reconciliation; email sequence drafting for approval; prompt and keyword coverage reports.
• Customer support. Ticket triage and priority setting; reply drafting for human review; end-to-end resolution of repeat issues; refunds and credits inside a fixed limit; knowledge-base gap detection; article drafting from solved tickets; escalation routing by sentiment; at-risk account flags; post-resolution follow-up; queue analytics summaries.
• Finance. Invoice matching to purchase orders; expense policy validation; approval routing; payment follow-up on overdue accounts; month-end reconciliation drafts; vendor record deduplication; spend anomaly flags; payroll question answering; tax document retrieval; forecast variance summaries.
• People and HR. Resume screening against role criteria; interview scheduling; onboarding task orchestration; offboarding access removal; leave balance answers; policy question answering; benefits document retrieval; employment letter generation; training recommendations by role; engagement survey summarization.
• IT and service desk. Password reset execution; access provisioning and deprovisioning; software request fulfillment; device lifecycle tracking; incident clustering; first-line troubleshooting; change ticket enrichment; patch and update coordination; agent-assist summaries for human staff; service level breach alerts.
• Operations and supply chain. Inventory threshold monitoring; demand forecast refreshes; supplier risk watch; purchase orders inside a preapproved limit; delivery exception handling; route and schedule optimization; quality issue clustering; contract renewal calendar; capacity planning summaries; multi-system order status resolution.
• Engineering. Bug triage and duplicate detection; failing-test summaries; dependency upgrade pull requests; first-pass code review; incident timeline assembly; documentation drafting from diffs; log anomaly clustering; release note generation; flaky test tracking; on-call handoff briefs.
• Legal and compliance. Contract clause extraction; deviation flags against a playbook; first-pass NDA review; obligation calendar building; policy update diffing; security questionnaire drafting; records retention sweeps; regulatory change monitoring; matter status summaries; privileged document routing.
• Data and executive. Metric definition reconciliation; dashboard anomaly narration; natural-language query answering; standing-meeting report assembly; data quality checks; cohort and churn summaries; board packet drafting; market and competitor digests; decision log maintenance; forecast assumption tracking.

Most of those hundred entries are retrieve, triage, draft, reconcile, or monitor work. The entries that execute a write are the shorter list, and they are the ones that need a governed action path and a named approver before anyone demos them.

Department Index Versus Action Index

Indexing this library by department answers where to look, and indexing it by action and reversibility answers what a team can run this quarter without adding a supervisor. Both indexes describe the same hundred entries, so the choice is not about coverage; it is about which question the artifact is built to answer.

Department indexes are still worth keeping, because department heads fund work and want to see their own row. Use them to brief, and use the action index to decide.

Where the Library Misleads You

A use case library misleads in three predictable ways, and each one burns a quarter. First, breadth reads as readiness: a hundred named workflows feels like a hundred available builds, when the real ceiling is how many exception queues one team can clear each week. Second, an entry says nothing about data access, and roughly half the ideas above die on integration rather than intelligence, because the record the agent needs sits in a system nobody will open. Third, the vendor outcome numbers that decorate these lists were measured inside someone else's staffing, tooling, and volume, so they are evidence that a pattern works somewhere, not a forecast for your queue.

One more distortion is worth naming: reversibility is a property of the write, not of the department. Refund execution and permission granting sit in different departments and share a risk profile, which is the whole argument for scoring the workflow rather than the model. Our risk assessment framework scores autonomy, reversibility, data sensitivity, customer impact, and auditability per workflow, and that score is the field this library adds to every entry.

Picking the First Three, and the Owner for Each

Selection from a hundred ideas runs three gates in order, and the order matters: value, then risk, then feasibility, as laid out in our guide to choosing an agent use case. Value asks whether the job is worth owning end to end. Risk asks what the worst day costs and how fast it can be undone. Feasibility asks whether the agent can reach the systems the entry names, which is where most enthusiasm dies quietly.

Write the entry as a trigger, a tool scope, a write boundary, and a named human who clears the exception queue before Friday close. That format converts a library row into something buildable, and it makes the oversight cost visible before the build rather than after. We productize agent work as three systems, a Lead Capture System, a Revenue Generation System, and an Operational Throughput System, so a use case has to land in one of them before it earns a build slot.

Pick three: one retrieve-and-summarize entry to prove the plumbing, one triage-and-route entry to prove the judgment, and one draft-for-approval entry to prove the handoff. Hold the execute-a-write entries until the exception queue from the first three runs clean for a month and the governance controls around scoped permissions and audit trails are real rather than planned. Sequencing that way costs one quarter of patience and saves the rebuild that follows a bad write nobody caught.

Frequently Asked Questions

What are some examples of AI agent use cases?

AI agent use cases include inbound lead qualification in sales, ticket triage and reply drafting in customer support, invoice matching in finance, access provisioning in IT, and bug triage in engineering. Each example is a repeating multi-step workflow with a clear trigger and a measurable outcome. The library above names ten such workflows for each of ten departments.

What are the 5 types of agent in AI?

The five commonly taught agent types are simple reflex, model-based reflex, goal-based, utility-based, and learning agents. Those categories describe how much an agent can reason and remember, not what it is allowed to change in your systems. Capability class is useful for evaluating vendors and largely irrelevant to picking a first workflow.

Are there seven types of AI agents, or five?

Agent taxonomies vary between five and seven types depending on whether hierarchical and multi-agent arrangements are counted as separate categories. Either count is a classification of architecture, not of work. A use case library sorts by the action taken and the cost of reversing it, which is the axis that changes a build decision.

How does an AI agent use case library differ from a use case list?

A use case library carries a structured field set for every entry: the action pattern, the write boundary, the reversibility, and the owner. A list carries names and outcomes. Lists are useful for inspiration; libraries are useful for sequencing work, because they let you sort a hundred ideas by what they cost to supervise.

Which department should run its first AI agent?

Departments with high-volume, rule-heavy, reversible work run their first agent most safely, which usually means customer support, IT service desk, or finance operations. Volume makes the payback visible and reversibility makes the mistakes survivable. Picking the department with the loudest complaint rather than the cheapest reversal is the common error.

What does a library entry leave out?

Library entries leave out integration reality, data quality, and staffing. An entry can name a workflow the agent cannot reach, because the record lives in a system without an accessible interface or an owner willing to grant scoped access. Entries also omit the supervision hours the workflow adds until the exception rate falls.

How do you turn a library entry into a running agent?

Turning an entry into a running agent means specifying the trigger, the tools the agent may call, the writes it may perform, the escalation path, and the human who reviews exceptions. Build the evaluation set before the agent ships, then widen autonomy only after the exception queue stays clean. Scope creep after launch, not model quality, is what usually breaks a working workflow.