LESSON 5 of 7 Intermediate

Putting AI Into a Workflow

The trigger-step-action pattern, why non-determinism breaks ordinary automation habits, and the four controls every AI workflow needs.

5 min read β€’ 4 quiz questions Facts reviewed Aug 2026

What you'll be able to do

  • Design a workflow around the trigger, AI step and action pattern
  • Explain why an AI step needs different safeguards to a deterministic one
  • Choose between full automation, human review, and suggestion-only

Assumes: Lesson 4 β€” AI Agents: Beyond Chat

The shape of every AI workflow

Strip away the tooling and nearly all of them are the same three parts:

Trigger β†’ AI step β†’ Action

  • Trigger β€” something happens. A form is submitted, an email arrives, a timer fires.
  • AI step β€” something is judged, extracted, classified or written.
  • Action β€” something changes. A row is updated, a message is queued, a ticket is routed.

The tools that host this change constantly β€” the visual builders, the assistant platforms, the code frameworks. The pattern does not. Learn the pattern and the tool is an implementation detail.

The one thing that makes AI steps different

Ordinary automation is deterministic. The same input produces the same output, forever. Everything about how we build and operate automation assumes this: retries are safe, tests are stable, a passing run means a working system.

An AI step breaks that assumption. It samples from a distribution. The same input can produce different output on Tuesday than it did on Monday. And the system can change under you when a provider updates a model.

Four consequences follow, and they are the whole lesson.

1. Retries are not automatically safe

The classic bug: the AI step drafts a reply, the send succeeds, recording the send fails, the workflow retries β€” and the customer gets two emails.

With a deterministic step you can often retry blindly. Here you cannot. You need an idempotency key β€” a record of β€œthis trigger has already been actioned” checked before acting, not after.

2. You cannot test by running it once

One good run tells you almost nothing. What you need is a fixed set of representative inputs with known-correct outputs, run whenever anything changes.

Twenty cases in a spreadsheet is a legitimate evaluation set and puts you ahead of most teams. That is the next lesson.

3. Confidence should route the work

Accuracy is never uniform. A classifier at 85% overall might be 98% on clear cases and 60% on ambiguous ones. Treating all outputs identically throws away that structure.

Ask the model for a confidence signal alongside its answer and route on it:

high   β†’ act automatically
medium β†’ act, but flag for review
low    β†’ send to a human, do not act

A caveat worth stating plainly: self-reported confidence is weakly calibrated. It is a useful ordering signal, not a probability. Set your thresholds by measuring what actually happens at each level, not by trusting the number.

4. Log the input and the output, always

When something goes wrong two months from now, β€œthe AI classified it wrong” is not debuggable. What you need on every run:

  • the exact input that was sent,
  • the exact output that came back,
  • which prompt version and model produced it,
  • what action was taken as a result.

That last item matters most. Without it you cannot answer β€œdid we email this person already?” β€” which is the question you will be asked.

Three levels of autonomy

Match the level to the cost of being wrong. Most teams jump straight to the first and regret it.

LevelShapeRight when
SuggestAI drafts, human sendsErrors are visible to a customer
ReviewAI acts, human sees a queueErrors are recoverable but embarrassing
AutomaticAI acts, nobody watchesErrors are cheap and reversible

A sound sequence: ship at suggest, measure real accuracy for a fortnight, then promote to review, and only reach automatic for the specific case where the numbers justify it.

Four workflows that genuinely work

These are durable shapes, not product recommendations.

Triage and routing. Ticket arrives β†’ classify topic and urgency β†’ route. Low risk: misrouting is annoying and instantly fixable. An excellent first project.

Extraction into structure. Invoice or form arrives β†’ pull out vendor, amount, date, line items β†’ write to a system. High value, and easy to validate β€” the numbers either reconcile or they do not.

Summarising for a human. Long thread or transcript β†’ summary plus action items β†’ posted for review. Output goes to a person who can judge it, so the risk is inherently contained.

Draft generation. New content published β†’ draft variations for other channels β†’ land in a queue for approval. Suggest-level by construction.

Notice the common thread: each produces something a human either checks or can trivially correct. That is not a coincidence β€” it is why they work.

What to avoid early on

  • Chains where every step is an AI step. Errors compound. Four steps at 90% each is 66% end to end.
  • Automating something you have never done manually. If you cannot describe the correct answer, you cannot evaluate it.
  • Silent failure. A workflow that stops working without telling you is worse than no workflow.
  • Anything irreversible without a gate. Same rule as agents β€” reversibility decides.

Try this: Take a repetitive task and write down its trigger, its AI step and its action on one line each. Then write the four inputs where you would most fear a wrong answer. If you cannot state what the correct output is for those four, that is the work to do before automating anything.

Quick Quiz

Test what you just learned. Pick the best answer for each question.

Q1 How does an AI step differ from an ordinary automation step?

Q2 A classification workflow is right about 85% of the time. What should you build?

Q3 Why is a retry dangerous around an AI step that sends messages?

Q4 What is the most useful thing to log on every AI step?