Your first AI workflow: from a brief to a checked result

Choose a task you can check without an AI

For a first project, choose a short task with a clear source and a result you can inspect. Here we will turn a fictional workshop fact sheet into four frequently asked questions. We are not connecting a customer database, sending messages or making decisions about a real learner.

A useful workflow states what goes in, what should come out, how an error is detected and who can approve the result. An impressive-looking chain of boxes is not a substitute for those decisions. A five-step process that produces a reliable draft is a better first project than a twenty-step process you cannot explain.

Create a small source of truth

Our fictional workshop is called Paper & Play. It is a beginner paper-folding session lasting 45 minutes, with 12 places and paper supplied. The session date, venue, age guidance, fee and booking method are unconfirmed. The downloadable CSV contains these same practice facts with source IDs.

Keep unconfirmed information explicit. “Not confirmed” is useful data; an empty field can tempt a model or a hurried person to fill the gap. The example is designed to produce a reviewable internal draft, not a publishable event announcement.

F01: Workshop name = Paper & Play
F02: Level = beginner
F03: Session length = 45 minutes
F04: Capacity = 12 places
F05: Materials = paper supplied
F06-F10: Date, venue, age guidance, fee and booking method = not confirmed

Write a prompt with a visible success condition

Specify the source, audience, output and limits. Keep the request narrow enough that you can compare every answer with the fact sheet. Instructing the model to cite a source ID helps your review, but an ID beside a sentence does not prove the sentence is correct.

Use fictional or otherwise permitted material when practising in an AI tool. Check the tool’s data settings before sharing real work. Your private customer spreadsheet does not become training material just because its filename ends in “practice”.

Task: draft four short FAQs for an internal review.
Audience: someone considering the fictional Paper & Play workshop.
Use only the supplied F01-F10 facts.
Return a table: question | draft answer | supporting fact IDs | review status.
If a required detail is not confirmed, write “Ask the organiser” and mark HOLD.
Do not invent a date, venue, age rule, price or booking method.
Keep the result as a draft. Do not send or publish anything.

Check claims against the actual facts

Review the answer in small pieces. “The session lasts 45 minutes” matches F03. “Children aged six and above can join” has no supporting fact. A source ID attached to that age claim would still be wrong. Mark it HOLD and ask for the missing information.

Check numbers separately. If the draft says two sessions can accommodate 24 places in total, the multiplication is simple, but the source sheet confirms only one session. Correct arithmetic can still support an invented assumption. Remove the extra session unless an authorised source confirms it.

• Does each factual statement match a supplied fact?
• Are missing details clearly held for review?
• Does the source ID support the actual wording?
• Have extra promises appeared in an otherwise correct sentence?
• Could a new reviewer understand why an answer passed or failed?

Make approval a separate step

Keep the draft in a review document. A person checks the facts, supplies missing information and decides whether the result is ready for its intended use. An output can pass a factual check and still need a tone, accessibility or permissions review.

If you later automate the process, preserve this gate before actions such as sending a message or changing a record. Tools such as n8n document approval steps for selected AI tool calls. Connecting one is a separate implementation task involving access, credentials and testing; the local example on this page does not run that service.

Test the workflow with awkward inputs

Repeat the exercise with the duration removed. Then add two conflicting capacity values in separate source notes. The workflow should hold those answers instead of silently choosing a convenient number. Save the cases and explain the expected behaviour before you look at a generated response.

A second test might contain an instruction inside the source material telling the model to ignore the brief. Treat source content as data, not authority to change the task. Model behaviour can vary, so keep the independent check even when one test seems successful.

Turn the exercise into a small portfolio case study

Present the brief, fictional source sheet, prompt version, draft, review table and corrected result. Explain a failure you caught and the rule that prevented an unreviewed action. Label prepared examples and real tool outputs accurately, including which service you used if you ran a model yourself.

This project demonstrates a process you can discuss. It does not establish that you have built a production system, reduced a company’s costs or earned an automation qualification. Your next useful question is what needs to be tested before this process could handle real work.