HASZB_AIHASZB_AI

Search across courses, lessons, glossary terms, prompts and tools.

Stage 8 · AI Automation

The anatomy of an automation

Trigger, condition, action. Every workflow you will build is these three parts arranged differently.

6 min read

In this lesson

  • Break a workflow into trigger, condition and action
  • Choose between scheduled and event-driven triggers
  • Identify which step needs judgement and which does not

Automation is what most people actually need when they think they need an agent. It is more predictable, cheaper, easier to test, and it covers the majority of real tasks.

Three parts

Trigger — what starts it.

  • Event-driven: a form is submitted, an email arrives, a file appears, a payment succeeds. Runs when something happens.
  • Scheduled: every hour, every weekday at 08:00. Runs whether or not anything happened.

Prefer event-driven where possible. Scheduled runs either do nothing most of the time or discover work late.

Condition — whether to continue. Filters, branches, checks. This is where most workflow bugs live, because the edge cases are here: the empty field, the duplicate, the message that arrives twice.

Action — what actually happens. Send, write, create, update, notify. Anything with an effect.

Where the model goes

The important design decision: use the model only for the step that needs judgement.

Take "route incoming support messages to the right team". The full workflow is:

  1. Trigger: message arrives
  2. Extract sender, subject, body — ordinary code
  3. Decide the topic — this needs judgement
  4. Look up the team for that topic — ordinary code, a lookup table
  5. Assign and notify — ordinary code

Only step three needs a model. Steps two, four and five are deterministic and should be, because deterministic steps are testable, free and cannot surprise you.

Constrain the judgement step

When the model does make a decision, constrain its output hard. Do not ask "what should happen with this message?" — ask it to choose from a fixed list:

Classify into exactly one of: billing, technical, account, other. Reply with the single word only.

Now the output is one of four known values. Your code can switch on it safely, and an unexpected value is an obvious error rather than a silent misroute.

This is the general principle: the model narrows, your code acts. Free-form output flowing straight into an action is where automations become unpredictable.

Start by mapping the manual process

Before building anything, write down what you actually do now, step by step, including what you check and when you decide not to proceed. Most of that checking is invisible until you write it out, and it is exactly what the automation must reproduce.

Then automate the boring middle first and leave the judgement to yourself. Add the model step once the rest is reliable. Building the reverse way — clever decision first, plumbing later — is how workflows end up impressive in a demo and unusable on a Monday.