Stop choosing AI use cases; start defining workflows

“Find AI use cases” sounds like a practical instruction. It often produces a spreadsheet of attractive verbs: summarise, research, reconcile, recommend, draft and automate. The list can create momentum without establishing whether any item belongs in a real operating workflow.

The better starting point is the work itself. Who is trying to achieve what outcome? What information and authority do they need? Which systems must change? Where does judgement enter? What happens when the normal path fails? Only after those questions are answered can a team decide whether an agent, deterministic automation, decision-support tool or process change is appropriate.

That sequence matters because an agent is not an isolated feature. It becomes part of a socio-technical system: people, policies, data, software, suppliers and operating routines. The UK Government Service Standard now explicitly advises teams to design around user needs rather than pre-selected technologies, including generative AI. A workflow definition makes that principle actionable.

Replace the idea list with a workflow canvas

Choose a bounded unit of work that has a recognizable beginning and end. “Improve procurement” is too broad. “Review an approved requisition, identify compliant suppliers and prepare a recommendation for a buyer” is closer. Then complete a canvas with nine fields:

Field	Question to answer
Outcome	What changed state proves the work was useful?
Trigger	What event starts the workflow, and who may initiate it?
Inputs	Which records, instructions and contextual facts are required?
Decisions	Where must the workflow interpret, choose, approve or refuse?
Actions	Which systems can be read or changed?
Authority	Who may decide, delegate, override and stop?
Exceptions	Which ambiguous, adverse or unusual cases need another route?
Evidence	What must be recorded to explain the outcome?
Ownership	Who is accountable for performance once the workflow is live?

This is not process mapping for its own sake. Each field exposes a reason an apparently simple use case can fail. A drafting assistant may need no external authority. A procurement agent that contacts suppliers or changes an order does. A summarization tool may work with a document snapshot; a decision-support workflow may depend on current authoritative records.

NIST’s AI Risk Management Framework Core makes context a prerequisite: intended purpose, users, setting, system boundaries, benefits, costs and human oversight should be understood before a go/no-go decision. The workflow canvas is a compact way to collect that context.

Define the present workflow before imagining the future one

Start with how work actually moves, including the unofficial routes. Observe representative cases. Sample straightforward work and exceptions. Note where people copy data between tools, wait for approval, ask a colleague, maintain a private spreadsheet or repair poor upstream information.

The current workflow provides the baseline against which change can be judged:

• elapsed time and active working time;
• rework, correction and abandonment;
• queue size and variation in demand;
• handoffs and approval delays;
• error consequence, not merely error count;
• user and operator effort;
• control failures and unresolved exceptions; and
• cost of systems, review and support.

Do not assume every awkward step is waste. A second review might protect against a consequential mistake. A pause may allow data to arrive. A conversation may resolve ambiguity that the formal process ignores. Discovery should distinguish accidental friction from a control or adaptation that the future workflow still needs.

The GOV.UK discovery guidance treats understanding users, constraints, the wider service and success measures as the work required before committing to build. That discipline is especially valuable when an AI demonstration can make the solution look settled before the problem is understood.

Locate judgement, discretion and authority

Not every decision is the same. Mark each decision point as one of four types:

1. Rule application: the required result follows from stable, explicit conditions.
2. Prediction or classification: the workflow estimates an uncertain property.
3. Interpretation: context and evidence must be assembled into a reasoned view.
4. Commitment: the decision changes rights, money, access, obligations or external state.

AI may assist all four, but the control design should differ. Stable rules often belong in conventional software. Predictions need representative validation and monitoring. Interpretations need source quality, uncertainty handling and review. Commitments need explicit authority, preconditions and auditable execution.

Separating the types also prevents “human in the loop” from becoming a vague remedy. Name what the person must decide, what evidence they see, how much time they have, what competence and authority they need, and what happens if they disagree or do not respond.

Compare solution shapes, not just models

Once the workflow is visible, compare at least four possible interventions:

• change the policy, form or information flow so less work is necessary;
• use deterministic rules or conventional workflow automation;
• add AI assistance while a person retains the decision and action;
• delegate bounded planning or action to an agent with enforced controls.

The best solution may combine them. A deterministic service can validate eligibility, a retrieval component can gather relevant material, a model can draft a recommendation, and an authorised person can approve the commitment. Calling the whole arrangement “an agent use case” conceals the architecture and makes ownership harder.

OECD workplace case studies show that AI implementation changes tasks and often creates new work such as interpreting alerts, prioritising responses and feeding decisions back into systems (OECD). Evaluate the complete redistribution of work, not just the task that the model appears to perform.

Turn the canvas into a decision contract

A workflow candidate is ready for experimentation when its sponsor can state:

For this defined group of cases, we believe this operating change can improve this measured outcome without violating these authority, quality and impact constraints. We will test these assumptions, and the next decision will be to stop, revise, expand or prepare for live operation.

Attach observable acceptance conditions. For example, the workflow might need to reduce avoidable rework while maintaining review quality, route every high-consequence exception to an eligible approver, and leave a record that lets operations reconcile every external action. Avoid a single composite “AI score”; the sponsor needs to see trade-offs.

The U.S. Government Accountability Office groups AI accountability practices around governance, data, performance and monitoring (GAO). A useful decision contract covers all four: named accountability, fit inputs, outcome and control measures, and a plan for operation after the test.

Use workflow boundaries to control scope

Scope by authority and consequence, not by how impressive the demonstration looks. A good first boundary might include one business unit, one request class, read-only system access and draft recommendations. It should also define what is excluded: unusual contract terms, protected decisions, missing evidence, conflicting instructions or actions above a monetary threshold.

Boundary conditions are not a permanent excuse to avoid difficult cases. They make learning interpretable. As evidence improves, the team can decide whether to widen data, cases or authority one dimension at a time. When a boundary changes, update the evaluation set, controls, operating procedures and benefit model.

Fund the workflow decision, not an AI performance

A prototype should answer the uncertainties that block the next operating decision. If the main unknown is data access, test that integration. If it is whether reviewers can detect weak recommendations, test the review interface and real workload. If it is external action safety, use a representative sandbox and reconcile state changes.

The deliverable is not a clever demonstration. It is evidence about a future workflow: a map, baseline, solution comparison, controlled prototype, observed results, unresolved risks, operating owner and explicit next decision.

Starting with workflows does not make an organisation less ambitious about AI. It makes ambition accountable to work that people can operate, improve and trust.