Basic workflows: steps and conditions

Target audience: everyone | Prerequisites: 2.2 Structured output, 1.5 Anatomy of an AI-automated system

What you'll learn

After this document you will be able to:

• write down a workflow (an automated sequence of steps) step by step: every step's input, action, and output;
• set up conditions — decision points where the path branches — and decide whether a rule or the AI model resolves them;
• use a loop when the inputs arrive many at a time;
• place a human-in-the-loop step inside the flow (a human reviews the result before use and approves it).

From document 1.5 we know the system's seven parts and three shapes — here the parts are assembled into a straight, traceable sequence.

In plain terms

A workflow is like a properly set up post office: letters come in at one end, every desk does one thing and passes the result on; at the intersection a sign directs — “invoices to the left, information letters straight ahead, angry ones to the manager's desk”. The post office doesn't improvise — that is exactly what makes it trustworthy: if something goes wrong, you know at which desk to look.

From input to output: the point of steps

A workflow is a sequence of steps that always runs in the same order: every step takes an input, does one thing, and gives an output — the next step's input — until the flow reaches the end.

Example: Mari's invoice flow (1.2: about 40 PDF invoices a month to accounting):

Two rules that make a step good:

• Every step does one thing. If the step's description contains the word “and” (“extract the data AND compose the answer”), split it into two. A one-thing step can be reviewed in a second and rebuilt when needed without the whole flow falling apart.
• Every step's output is checkable. After step 2 you can look at whether the fields are right; after step 3, what was decided. The error doesn't stay in the dark.

Where to build this? Tools like n8n, Make, and Zapier are visual boards where steps are connectable blocks — there is no code to write. This document is tool-agnostic: the principles hold in all of them; building one flow from start to finish is shown by 2.5.

Conditions and branches: if-then-else

Flows are rarely a straight line — usually there comes a spot where the path branches. That spot is a condition: a question whose answer is yes or no. Every answer's direction is a branch: the path along which the flow moves. In human language: “if the number matches, then enter it; otherwise ask Mari.”

There are two ways to resolve a condition — the choice between them is one of the most important decisions in building the flow:

A rule gives a fact, the model gives a judgment. A simple test: if the decision can be made by looking only at numbers and fields, put in a rule; if it takes reading the text and getting a feel, use the model. Because the model's judgment is an opinion, not a fact, always give it an “unknown” option as well, which leads to a human. But if the condition cannot be written down in advance even with a model, that is the sign that an agent system is needed (see 4.1): there the model decides every next step itself. Still, stay with the workflow as long as it suffices — a pre-written path is more controllable and often better, too.

In plain terms: the condition is the intersection, the branch is the road leading from it: when numbers are read at the intersection, put a rule there; when a letter must be read, put a model.

Loops: when the letters come in bulk

Forty client letters arrive in one day at once — like one package. Each one goes through the same path. Do you build 40 workflows? No — you build one and add a loop: “take the next letter and run it through the same flow, until the box is empty.”

   box: 40 letters
        │
        ▼
   ┌─► take the NEXT letter
   │        │
   │        ▼
   │   the same workflow with one letter:
   │   classify → condition → branch → output
   │        │
   │   failed? ──► mark as failed, letter onto the list
   │        │
   │        ▼
   └── more letters in the box? ── yes
            │
           no
            ▼
   all processed + list of failures for handling

Two nuances with the loop:

1. Build and test with one letter, then let the loop repeat. The loop doesn't change the path — only the number of repetitions; if there is a flaw inside the flow, it repeats it 40 times.
2. One letter's failure must not stop the others. If one letter won't classify, it stays on the failed list and the loop moves on. What to do with the failures next is the topic of 3.4 Errors and error handling.

In plain terms: the loop is a conveyor belt — you build only one workstation, and the belt carries every product through it; a flaw in one product doesn't stop the belt.

A human in the loop as a workflow step

A workflow can also include a step that is not the machine's work: the approval step. The flow reaches a fixed spot, puts the work onto a human's list, and waits — it doesn't move on until the human has said “yes” or pushed it back.

Where to place the approval step? 1.2 gave the answer: where the mistake costs — before the system touches the outside world. Three common placements:

In plain terms: the approval step is a signature on the screen, like on a bank transaction: the system prepares, but the last word, before anything goes outside, belongs to the human. Approval is not the system's weakness, but part of the design.

A step-by-step example: the HomeCraft Store's three branches

The HomeCraft Store (the 1.2 world): Mari sells handmade goods in an e-shop and receives letters of three kinds a day — returns, information, complaints. A three-branch workflow looks like this:

   TRIGGER: a new e-mail arrives at the shop's address
        │
        ▼
   STEP 1: CLASSIFICATION (AI model)
   prompt (the instruction given to the model):
   “read the letter and determine its type”
   structured output (JSON format, see 2.2):
   type = return | info | complaint | unknown
        │
        ▼
   CONDITION: if “type” is…
        │
        ├── return ────► BRANCH A: draft + approval
        │                  pull the order data from the database
        │                  compose the reply draft
        │                  APPROVAL STEP: Mari reviews
        │                  the approved reply goes to the client
        │
        ├── info ──────► BRANCH B: reply automatically
        │                  pull the shipping and stock data from the database
        │                  compose the reply based on that data
        │                  the reply goes to the client directly
        │                  (1.4 adds a nuance: only text whose content comes
        │                   from previously approved data can go on its own)
        │
        ├── complaint ─► BRANCH C: always to a human
        │                  the letter and the whole context go to Mari
        │                  the system does not reply to the client itself
        │
        └── unknown ───► BRANCH C: also to a human
                          (the classifier wasn't sure)

   at the end of every branch: A RECORD IN THE LOG — type, decision, time

The AI model does two jobs here — it classifies and it composes wording. All the facts (whether the product is in stock, how long shipping takes, when the purchase was made) come from the database, not from the model's head — that way a hallucination (a confidently stated but wrong answer from the model) cannot sneak into the reply.

The conditions, letter by letter:

In plain terms: the three branches automate three ways — info completely on its own, returns halfway (Mari approves), complaints not at all. Every branch is a decision of its own, just as 1.2 said: the choice is where the human stands in the process.

Summary

• A workflow is a pre-written sequence of steps: every step takes an input, does one thing, and passes a checkable output on.
• The condition is a decision point, the branch is a path. Numbers are decided by a rule, text by the AI model — and in case of doubt the “unknown” branch leads to a human.
• The loop repeats the same path for all the inputs: test it through with one letter, then let it repeat; one failed input doesn't stop the others.
• The approval step stops the flow for a human — where the mistake costs, the last word stays with the human.
• The tools (n8n, Make, Zapier) are only the workbench — the principles hold in all of them.
• If the path cannot be written down in advance, that is the sign that an agent system is needed (see 4.1) — but before that, always try the simpler shape.

What's next?

• previous → 2.2 Structured output
• next → 2.4 Inputs and data preparation
• A complete guide to building one workflow → 2.5 Your first end-to-end automated workflow
• back → handbook index