Design useful work
What is an AI workflow? Follow one client job from start to finish
An AI workflow is a sequence of work in which an AI model performs one or more tasks. It might read a request, find relevant information or prepare a draft. The rest of the workflow still matters: where the information comes from, what checks run, who makes the decision and what happens when a step fails.
Describe the whole job, including evidence and the next human decision, before selecting a model or automation tool.
Separate fixed rules from interpretation
Some tasks have a clear answer every time. If a record has no client ID, return it for correction. If a draft has not been approved, leave it in the draft queue. Ordinary software can apply those rules without asking an AI model to decide what they mean.
Other tasks involve language or a choice that cannot be covered by a short list of rules. A model might interpret a client’s request or prepare an explanation from approved evidence. Give it the information for that task and check the result before allowing the next step.
An agent can choose some of its next actions using tools and the results it receives. A workflow can also follow a fixed sequence with an AI call inside it. The terminology varies between products, so ask which choices the model can actually make.
IBM provides a broader explanation of AI workflows. The example here focuses on a service job you can map and review.
Follow a request for client content
Suppose a content firm wants a client to request a draft using its approved business context. This is a proposed teaching example, inspired by Said’s view of a service that could use a firm’s existing knowledge of a client and its competitors. It is not a claim that such a service has launched.
Client
Receive a specific request
Name the audience, purpose and kind of content required.
Software rules
Check which information may be used
Select this client’s approved records and check their validity and access.
AI model
Prepare a draft with supporting records
Use the selected brief and context. Attach the evidence needed for factual claims.
Client or named expert
Review the draft and the evidence
Check accuracy, suitability and whether the request needs specialist advice.
Approved publishing process
Release and record the decision
Publish only through the agreed route and retain the approved version.
Missing evidence returns an unknown or a question. A draft is not permission to publish, spend money or change the client’s systems.
The draft is one step. The client boundary, current source selection and publishing permission are just as important to the result. If those are hidden behind the phrase “the AI handles it”, nobody has enough information to judge the design.
Carry the evidence through the steps
Said describes provenance as central to our current knowledge build. Records keep their origin and validity information, and confidence falls when they are not refreshed by the relevant date. Later steps need that information too, rather than a polished summary with the source history removed.
His rule for missing evidence is clear: if the system cannot provide a trace or a deterministic basis that a person can review, it must say it does not know. In a new workflow, make that an actual check around the model output. An instruction in a prompt is useful, but it cannot be your only enforcement mechanism.
For the proposed content example, a reviewer should be able to open the record supporting a factual claim. A source identifier tells them where to look; they must still check that the record supports what the draft says. A citation can exist and be irrelevant.
| Information | Why the next step needs it |
|---|---|
| Client and task | Stops one client’s material being used for another job. |
| Source and relevant passage | Lets a person inspect the basis of the draft. |
| Validity and collection dates | Shows whether the underlying information may be old. |
| Unknowns or disagreements | Prevents an unresolved question becoming an apparent fact. |
| Review or approval record | Shows which version was accepted and what can happen next. |
Design what happens when the normal route breaks
Try a request that names the wrong client, an expired agreement and two conflicting statements. Each should have a route you can explain. That might be a request for more information, a pause for a person to decide, or a refusal to carry out a particular action.
Also decide what happens when a tool is unavailable. A failed data connection is different from a client having no data. Preserve that distinction in the output. Otherwise a technical failure can quietly become a business conclusion.
Use those cases in the first test. A workflow that handles one perfect brief proves very little about how it will behave during a busy week.
Record the workflow in a usable design sheet
Worked example
A client asks for a content draft
Invented teaching example. No client outcome is claimed.
REQUEST
Prepare a short draft for an agreed audience, using the current client brief.
RULES
Use records for this client only.
Do not publish or create an unsupported factual claim.
WORK
Retrieve the approved brief and relevant context.
Prepare a draft and preserve the records used.
EXCEPTIONS
If the brief does not support a claim, leave it out and explain the gap.
If records conflict, show the disagreement to the named reviewer.
REVIEW
The reviewer checks the draft and authorises the next step.
The accepted decision is recorded for later work.
Build foundations the next job could reuse
A useful first workflow may establish current client records, approval rules and a way to inspect evidence. Those can help a later service, such as preparing a progress review from the approved plan. You would still need the new inputs, responsibilities and tests for that service.
Our delivered case studies show research, journalist-request handling and shared analytics. They are examples of complete pieces of work, with their actual limits. Use them to understand the design; do not assume every task in those systems is an autonomous agent.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.