From One Path to Many

In Week 5 you built automations that go in a straight line: trigger, step, step, done. That works until reality arrives.

Reality looks like this. An email lands in your shared inbox. It might be a complaint, a sales enquiry, an invoice query, or a newsletter. Each needs something different. A straight-line automation cannot cope — it either does the wrong thing to three-quarters of your mail, or you build four separate automations that all fight over the same inbox.

What you need is a workflow that looks at what arrived and decides where it goes. That is what this lesson builds.

---

1. The four control structures

Everything branching is built from these four. Learn what each is for and you can build any shape.

Structure	Question it answers	When to reach for it
Filter	Should this run at all?	Always. Every workflow.
Router	Which path should this take?	When different types need different handling
Iterator	This arrived as many things — process each	Attachments, rows, list items
Aggregator	Turn those many results back into one	After an iterator, always

The filter comes first, and it is not optional

The single most expensive mistake in automation is no filter. A workflow triggered on "new email" runs on every email — newsletters, notifications, spam, internal chatter. Every run costs an AI call. You discover this on the invoice.

Trigger: new email
Filter:  to = [email protected]
         AND from NOT ending in @yourcompany.com
         AND subject does NOT contain "Automatic reply"

Three conditions. Typically cuts volume by 90% or more, and every one of those excluded runs would have cost you money.

Build the filter before you build anything else. Test it on its own: send yourself something that should pass, and something that should not.

The router

A router sends each item down exactly one path based on a condition.

Router on {{category}}:

  Route A  category = complaint     -> notify a human, no auto-draft
  Route B  category = billing       -> billing queue + draft reply
  Route C  category = technical     -> technical queue + draft reply
  Route D  FALLBACK (no condition)  -> general queue + notify

Route D is mandatory. Without a fallback, anything matching no condition vanishes silently — no error, no notification, no record. It is the hardest bug class to notice because nothing appears to be wrong. You find out weeks later when a customer asks why nobody replied.

Iterator and aggregator, always as a pair

Email arrives with 5 attachments
  -> Iterator: for each attachment
       -> extract the text
       -> AI summarises it
  -> Aggregator: collect the 5 summaries
  -> AI writes one combined summary
  -> ONE message to Slack

Use an iterator without an aggregator and you get five Slack messages where you wanted one. This is the second most common structural mistake.

---

2. Where the AI step goes

This is the design decision that determines whether your workflow is debuggable.

Do this:

Trigger -> AI CLASSIFIES -> Router branches on the classification -> Action

Not this:

Trigger -> AI decides what to do AND does it

In the first, you can see exactly what the AI decided and why the router sent it where it did. In the second, when something goes wrong, you cannot tell whether the judgement was bad or the action was bad.

Separate the judgement from the action. Always.

Constrain the classification

An unconstrained classifier will invent categories, add explanations, and wrap everything in prose. Your router then fails to match any of it.

Classify this message into exactly one category:
billing | technical | sales | complaint | other

Respond with ONLY the single word, lowercase, no punctuation,
no explanation.
If it spans two categories, choose the one the customer most wants resolved.
If genuinely unclear, respond: other

Message: {{body}}

Four things are doing work there: a fixed vocabulary, an explicit output format, a tie-breaking rule, and an escape hatch.

Set the temperature to 0–0.2. At default temperature the same email gets classified differently on different runs, and you will spend an hour debugging a workflow that is behaving exactly as configured.

Normalise before you compare

The model returns "Billing." — with a capital B and a full stop. Your router matches on billing. Nothing matches. Everything falls to the fallback.

This is the most common "my router is broken" cause there is. Add a normalisation step between the AI and the router:

trim whitespace -> lowercase -> strip trailing punctuation

---

3. Building it, step by step

Build in this order and test at every stage. Building all six steps and then testing means debugging six things at once.

Step 1 — Trigger only. Add nothing else. Confirm it fires and that you can see the incoming data.

Step 2 — Add the filter. Test with something that should pass and something that should not. Do not proceed until the filter is right.

Step 3 — Add the AI classification. Run it on ten real messages. Check two things: is the classification correct, and is it the same on a repeat run?

Step 4 — Add the normalisation step. Trim, lowercase, strip punctuation.

Step 5 — Add the router with all branches, including the fallback. Test each branch with a deliberately chosen input.

Step 6 — Add the actions. Drafts go to a Drafts folder. Never straight to send.

Step 7 — Add the error path. If any step fails, a human gets told which step, which input, and what the error was.

---

4. Testing every path

An untested branch is a branch that will fail in production. Fill in every row before going live.

Path	Test input	Expected	Result
Filter passes	a genuine support email	continues
Filter rejects	an internal email	nothing happens
Route A	an angry complaint	human notified, no draft
Route B	a billing question	billing queue + draft
Route C	a technical question	tech queue + draft
Fallback	something matching nothing	general queue + notify
AI returns junk	a blank or garbled message	fallback, plus an alert
Repeat run	the same message twice	identical classification

The last three rows are the ones people skip and the ones that break.

---

5. Loops, and why they need a cap

Some platforms let you repeat a step until a condition is met. This is where automation bills go badly wrong.

• Maximum iterations set. Always. Even when you are certain it will terminate.
• The exit condition cannot be skipped. What happens if it is never met?
• Cost per iteration known, multiplied by the maximum.
• An alert if the cap is hit — that means something is wrong.

Calculate before you launch: worst-case cost per run × maximum runs per day × 30. If that number is uncomfortable, the caps are too loose.

---

⚠️ Common Mistakes

• No filter. The workflow runs on everything. This is the expensive one, and it is almost always the cause when a bill surprises you.
• No fallback route. Unmatched items disappear silently. Nobody notices for weeks.
• Routing on unnormalised AI output. "Billing." never matches billing, so everything lands in the fallback.
• Temperature left at default on a classification step. Non-deterministic routing, and hours of confused debugging.
• Iterating without aggregating. Twenty notifications instead of one.
• Testing only the happy path. Every branch needs a test, including the failure branches.
• A trigger that triggers itself. A workflow that posts to Slack, triggered by Slack messages. Filter on the sender, or you will find out at scale.
• No logging. Something misrouted three days ago and there is no record of what the AI returned, so you cannot diagnose it.

---

What's Next: You can branch, filter and route. Next we give the workflow the ability to decide its own steps — and look honestly at when that is a good idea and when it is not.