AI Automation
Automate real work with little or no code — and keep it running after you leave the room.
Most automation projects do not fail on the technology. They fail because someone automated a broken process, or automated a task that happens twice a month and took four minutes anyway. The tool was never the hard part — n8n and Make can be learned in a fortnight. The hard part is judgement: knowing which processes deserve automation, which ones need fixing first, and which ones should stay human because the cost of a silent error is higher than the cost of the labour. This path is deliberately unbalanced. You spend the first phase not building anything — reading a real process end to end, timing it, counting how often it actually runs, and finding the exceptions nobody documented. Only then do you wire things together, because a workflow built on a fantasy of the process will break the first week and nobody will trust the next one. Then you spend a full phase on the part demos always skip: what happens when the API times out, when the model returns something unparseable, when the same webhook fires twice, when it all silently stops on a Saturday and nobody notices until Tuesday. An automation that works is a prototype. An automation that fails loudly, retries safely and has a named owner is a system. This path is about the second one.
What you will learn
Prerequisites
- No programming required, but comfort reading JSON helps
- Access to a real process you or a colleague performs weekly
- Willingness to interview the people who do the work
Where it leads
- AI Automation Specialist
- Operations / Business Process Analyst
- Internal tooling builder
- Freelance automation consultant
Phases
Phase 1 — The process, before the tool
Understand the work as it is really done, and earn the right to automate it by proving it is worth automating.
Estimated duration · 4-5 weeksReading a process honestly
The documented process and the real process are never the same thing, and the gap is where automations die. You will sit with the person who does the work, watch them do it, and write down the shortcuts, the copy-paste, the "oh, except when it is a returning client" that appears in no procedure. Every exception you miss now becomes an incident later.
Topics covered
What you will build
- Produce a one-page map of a real process with every branch and exception, validated by the person who performs it
- Time twenty real executions and publish the median, not the average
- List the three exceptions the official procedure does not mention
The decision to automate — and when not to
Frequency times duration times error cost, minus the cost of maintaining the thing forever. Most tasks lose that arithmetic and should be left alone. You will also learn the refusals that matter: never automate a decision whose silent failure is invisible, never automate a process nobody will own, and never automate away the only step where a human catches mistakes.
Topics covered
What you will build
- Write a one-page business case with real numbers, and a maintenance line item nobody can pretend is zero
- Kill one candidate automation in writing and explain why the arithmetic fails
- Rank five candidate processes and defend your ordering to a sceptic
Phase 2 — Wiring it together
Make systems talk to each other, and put the model only where it earns its place.
Estimated duration · 6-8 weeksTriggers, webhooks and moving data
Ninety percent of an automation is plumbing: something happens, data moves, a shape changes, another system accepts it. You will learn triggers versus polling, how authentication actually breaks, why rate limits humble everyone eventually, and why your workflow should never trust the shape of incoming data. Master this and the AI part becomes almost trivial.
Topics covered
What you will build
- Ship a workflow that reacts to a real webhook and writes to a real system, running unattended for a week
- Handle a paginated API end to end without losing or duplicating a record
- Feed your own workflow deliberately malformed data and make it refuse cleanly
Putting a model in the loop
A language model inside a pipeline is a non-deterministic component in a deterministic machine, and that is a design problem before it is a prompting problem. Use it where the input is genuinely messy and unstructured; use a rule, a lookup or a regex everywhere else, because those never hallucinate and never bill you. The reflex to route everything through a model is the most expensive beginner mistake in this field.
Topics covered
What you will build
- Replace one model call in your workflow with a deterministic rule and measure what you gained in cost and stability
- Build a triage workflow that escalates low-confidence cases to a human inbox with the reason attached
- Force JSON output, validate it against a schema, and make the failure path do something sensible
Phase 3 — Reliability and handover
Turn a workflow that works into a system that keeps working when you are on holiday.
Estimated duration · 5-7 weeksDesigning for the day it breaks
It will break. The API will time out, the webhook will fire twice, a field will arrive null, the quota will run out mid-batch. The question is whether your workflow half-completes an action and corrupts the data, or fails cleanly and tells someone. Idempotency is the concept that separates amateurs from professionals here, and almost nobody learns it before their first duplicated invoice.
Topics covered
What you will build
- Make your workflow idempotent and prove it by firing the same webhook five times with no duplicate side effect
- Cut the network mid-run, then show the recovery path and the alert it produced
- Build a failure log a non-technical colleague can read and act on
Ownership, cost and governance
The reason most automations die within a year is not technical: the person who built it left, nobody knew how it worked, so it was switched off. Documentation, a named owner, credentials that do not belong to a personal account, and a monthly cost someone actually looks at. Add the boring legal questions — what personal data crosses which border, who can see the logs — because they surface at the worst possible moment.
Topics covered
What you will build
- Hand one workflow over to a colleague and have them modify it without asking you a single question
- Publish a monthly cost figure per workflow and the volume that justifies it
- Write the runbook: what breaks, how you know, what to do, who to call
Questions
Do I really need no code, or is that marketing?
Mostly honest, with an asterisk. You can build genuinely useful workflows in n8n or Make without writing a program, and the first two phases need none. But the moment you handle a real API, you will read JSON, understand what a null does to a mapping, and probably write a five-line expression to reshape a payload. That is not programming, but it is not zero either. The people who plateau are the ones who treat the visual canvas as a way to avoid ever understanding data. The people who go far use the canvas to move faster while knowing exactly what is flowing through it.
n8n, Make, or writing the code myself — which one should I learn?
The question is less important than it feels. The concepts transfer completely: a trigger is a trigger, a retry is a retry, idempotency does not care about your vendor. Learn one properly and you can pick up the other in a weekend. That said, the trade-off is real: hosted visual tools get you to the first working version fastest and charge you per operation forever, self-hosted gives you control and gives you an ops problem, and custom code gives you everything and costs you maintenance. Start visual, because you learn the process faster than you learn the framework. Move to code only when a specific limit hurts you — not because a forum told you real engineers do not use no-code.
Why does an automation that worked perfectly stop being used?
Because trust is asymmetric. It takes months of silent success to build and one bad Monday to destroy. A workflow that quietly sent a wrong message to a client, or duplicated an entry nobody caught for three weeks, is finished — people will go back to doing it by hand and they will be right, because they can see their own mistakes and they could not see yours. This is why the reliability phase is not optional decoration. The second killer is orphaning: the builder leaves, the credentials expire, an upstream system changes a field name, and nobody knows enough to fix a five-minute problem. Both failures are organisational, which is exactly why engineers keep being surprised by them.
Related paths
Want to walk this path with a coach and a cohort?
Discover the 212AY Academy →