In September 2023, a 16-year-old in São Paulo named Mateus built a system that automatically read his school's announcement emails, extracted homework deadlines, and added them to a shared calendar for his whole class. He didn't write code. He used a free tool called Zapier and an AI called ChatGPT, connected together in about two hours. His classmates thought he'd done something nearly magical. His teachers asked if he was a programmer. He wasn't — he just understood something most adults around him didn't: that you can connect AI tools together like building blocks, and the result can do real work on its own.
That pattern is happening right now across every industry. In 2024, companies like Notion, Make, and n8n reported that their fastest-growing user groups were non-programmers — students, teachers, small business owners, journalists — people who had ideas but previously needed to hire a developer to build them. The tools finally caught up to the ideas. What used to require months of coding can now be assembled in an afternoon by someone who understands the logic, not the syntax.
This course will teach you that logic. You'll learn what a workflow is, why some workflows fail, how to design one that actually holds together, and how to think about what happens when it goes wrong. You won't be writing Python. You will be making real decisions about how AI systems behave — decisions that, until about two years ago, only professional engineers got to make. That's not a small thing. By the end of this module, you'll be able to look at almost any repetitive task and see the workflow hiding inside it.
If you finish every module, here's who you become:
In the spring of 2012, Patrick Doyle, the CEO of Domino's Pizza, stood in front of investors and said something that confused most people in the room: "We are a technology company that sells pizza." At the time, Domino's was testing a system it called the Domino's Tracker — a real-time pipeline that connected the moment a customer placed an order online to every single step that followed: the store receiving the order, a worker placing it in the oven, a driver picking it up, and a notification landing on the customer's phone. Every step was linked. Every step triggered the next. If the driver was delayed, the system knew. If an ingredient was out of stock, the system knew before the customer ever called.
This was, in its bones, a workflow. Not a complicated AI in the 2024 sense — no language models, no chatbots — but a connected chain of steps where output from one stage became input for the next, automatically, without a human having to relay the information by hand. By 2016, Domino's was generating more than 60% of its U.S. sales through digital channels, and competitors who hadn't built similar systems were scrambling. The company's stock rose more than 2,000% over the decade that followed. What looked like a pizza business was actually a workflow business. The pizza was almost beside the point.
Here's what makes that story matter to you right now, in 2025: the tools Domino's used in 2012 required a team of engineers and millions of dollars. The tools you have access to today — for free or nearly free — can build the same kind of connected, automatic pipeline in an afternoon. The logic hasn't changed. Only the barrier to entry has.
A workflow is a sequence of steps where each step depends on the one before it, and where the whole sequence moves toward a goal without a human having to restart it each time. That's the full definition. Everything else is just detail.
Think about what happens when you search for something on Google. You type a word. That triggers a lookup across billions of pages. That lookup produces a ranked list. That list gets formatted for your screen. That formatted page gets sent to your browser. That browser renders it. You see results. You did one thing — you typed — and a chain of about a dozen automated steps happened in under half a second. Each step fed the next. No human was in the middle relaying information. That's a workflow.
Now here's the new part. In 2023 and 2024, AI tools became capable enough to act as steps inside workflows. Instead of just moving data from one place to another, a workflow step can now understand text, write a summary, make a judgment call, or generate an image. That changes everything. It means a workflow isn't just mechanical plumbing anymore — it can think at each junction.
The key thing to understand: a workflow is a design, not a piece of software. Before you touch any tool, you need to have the logic clear in your head. What starts it? What happens next? What does each step need from the step before? If you can answer those questions, you can build the workflow. The tool is just the thing that runs it.
Every workflow — from Domino's pizza tracker to the most sophisticated AI pipeline at a tech company — falls into one of three shapes. Once you can recognize these shapes, you can read any workflow you encounter and understand what it's doing.
Linear: Step A leads to Step B leads to Step C. Always in order, no branching. The simplest possible design. Most beginner workflows are linear. The Domino's tracker was mostly linear: order received → oven → driver → notification. The risk of linear workflows is that if one step breaks, everything stops. There's no alternate path.
Branching: At some point in the chain, the workflow makes a decision. "If the email is marked urgent, do this. Otherwise, do that." Branching makes workflows smarter — they can respond to different situations differently — but it also makes them harder to design and harder to debug (meaning: figure out why they went wrong). Most real-world AI workflows are branching. This is where things get interesting.
Looping: The workflow runs, checks a condition, and if the condition isn't met, it runs again. Like a retry system: "Try to get a response from this API. If it fails, wait 60 seconds and try again. Repeat up to five times." Loops are powerful but dangerous — if the exit condition is wrong, the workflow runs forever, which can cost money, crash systems, or produce thousands of unwanted messages.
When a no-code AI workflow goes wrong — and they do go wrong — the mistake is almost always in one of these three shapes. Either a linear workflow didn't account for an edge case, a branching condition was stated wrong, or a loop never found its exit. You now know where to look.
In March 2023, a team at HubSpot — a marketing software company based in Cambridge, Massachusetts — released a set of what they called "AI-powered workflows." One example they published publicly: a workflow that automatically reads every new customer support email, uses a language model to classify it (billing question, technical issue, general feedback), routes it to the right team, and drafts a suggested reply for the agent to review. The agent still sends the reply — a human is still in the loop — but the workflow handles all the triage (sorting and routing) that used to take hours of manual review each day.
What's significant about this isn't just that it's efficient. It's that one of the steps is now doing something that used to require a human to understand language. Classifying an email isn't moving a piece of data — it requires reading, interpreting, and making a judgment. In 2020, that step required a human. In 2023, it can be a workflow step. That shift is the whole game.
But here is the genuine tension that no one likes to talk about: when a step in your workflow is an AI making a judgment call, that step can be confidently wrong. A rule that says "if the email contains the word 'cancel,' route to the retention team" is wrong in a predictable way. An AI that classifies email intent can be wrong in ways that are hard to predict, hard to notice, and hard to explain after the fact.
If an AI in a workflow makes a wrong judgment and a customer is harmed by it — say, their urgent medical equipment request gets misrouted and delayed — who is responsible? The person who built the workflow? The company that sold the AI? The company that deployed it? There is no clean answer here. Courts are still working this out. You should be too.
You now understand something that most people who use AI tools every day have never clearly thought through: an AI isn't magic, and it isn't software in the old sense either. It's a step in a chain. And the chain was designed by a person. That means the design matters, the decisions at each step matter, and the person who builds it carries responsibility for what it does — whether or not they wrote a line of code.
Every time you interact with a digital product that responds to something you did — a confirmation email, a personalized recommendation, a chatbot that knows your order history — you are touching the output of a workflow. Most people experience these things as features of the product. They don't think about the logic underneath.
You now can. You know that somewhere, there is a trigger. There is a sequence of steps. At one or more of those steps, there may be an AI making a judgment. There is an output that lands somewhere — your inbox, your phone, a database — and that output affects what happens next for a real person.
In late 2024, the European Union's AI Act began requiring that certain automated decision-making systems — hiring algorithms, loan approval workflows, medical triage tools — must be explainable. Meaning: someone has to be able to describe every step of the workflow and justify why each decision was made the way it was. That's a legal requirement now. It exists because the people who built those systems often didn't think carefully enough about the design.
You can now look at almost any automated system — a spam filter, a social media feed, a customer service bot — and ask: what's the trigger? What are the steps? Where is an AI making a judgment? What happens if it gets that judgment wrong? Most people who work with these systems professionally have never been asked to think this way. You have, starting now.
This course is about building these systems. But understanding the structure comes first, because you can't build something you can't see. By the end of this lesson, you can see it. The next three lessons are about making it.
You've been handed a system that's causing complaints and no one can explain why it's behaving the way it does. Your job is to reverse-engineer the workflow underneath it — identify the trigger, map the steps, name the shape, and find where an AI judgment might be going wrong.
Your AI partner in this lab is Rox — a peer analyst who has seen a lot of broken workflows. Rox will challenge your reasoning and won't let you get away with vague answers. Push back if you disagree.
In December 2023, a Chevrolet dealership in Watertown, New York deployed an AI chatbot on its website to help customers. The dealership used a no-code tool to connect a language model to its customer-facing chat window — took maybe a day to set up. Within 72 hours, screenshots of the chatbot's conversations were going viral across the internet. The bot had agreed to sell a 2024 Chevy Tahoe for one dollar. It had told a customer that Ford made better trucks than Chevy. It had agreed that, legally, a car dealer must honor any price a chatbot offers. None of these things were true, and none of them were things the dealership intended the chatbot to say.
The problem wasn't the AI. The AI did exactly what language models do — it responded helpfully to requests based on the patterns it was trained on. The problem was that the people who deployed it had not designed the workflow. They had configured a tool. They had given the chatbot a name and a logo. They had not written down what the bot was allowed to say, what it should refuse, what data it could access, or what should happen when a customer tried to manipulate it. There was no plan. There was only a product.
The dealership's story got a lot of laughs online, but the underlying mistake is made constantly, at every scale, by everyone from billion-dollar companies to individual students building their first automation. The tool was opened before the logic was clear. That ordering — tool first, design never — is where most no-code workflows go wrong.
The hardest habit to build when you start making workflows is resisting the urge to open a tool immediately. Tools are designed to feel inviting. They have drag-and-drop interfaces, free templates, tutorial videos. They make you feel like you're building something the moment you start clicking. That feeling is real — but it's building the wrong thing. You're building a version of someone else's template with your name on it, not a system you actually designed.
The right order is: understand the problem → design the logic → then open the tool. This sounds obvious. Almost no one does it. The reason is that most people think of the tool as the hard part and the design as the easy part. The opposite is true. The design is where every consequential decision happens. The tool is just how you run the design you already made.
Here is the set of questions you should be able to answer clearly before you open any tool:
The Chevy dealership's chatbot had no answers to any of these questions. The goal was not stated. The boundaries were not set. The failure modes were not considered. The tool was opened, the template was deployed, and a 2024 Tahoe was sold for a dollar within three days.
In 1992, a user experience researcher at Apple named Carolyn Snyder began documenting a technique that product teams had been using informally for years: drawing the screens of a digital product on paper before writing a single line of code, then testing those paper drawings with real users. They called it paper prototyping. The idea was radical at the time — you could find the problems in a design before building it, at almost zero cost, because drawing a box on paper takes five seconds and deleting it takes one.
For workflow design, the equivalent is a flowchart on paper. Before you open Zapier or Make or any other tool, you draw boxes and arrows. Each box is a step. Each arrow is the direction data flows. Branches get drawn as diamonds (the classic decision shape). Loops get drawn as arrows that curve back. You label every box with what it does and every arrow with what it carries.
This takes ten to fifteen minutes. It will save you hours. Here's why: when you draw the workflow on paper, you immediately see the gaps. "Wait — where does this step get the customer's email address from? I never specified that." That gap would have taken you forty-five minutes to debug inside an actual tool, and it would have frustrated you, and you might have concluded that the tool was broken rather than realizing the design was incomplete.
In 2024, the no-code platform Make.com published data showing that users who sketched their workflow before building had a 73% lower rate of workflow errors on first deployment compared to users who built directly in the tool. The paper step isn't a beginner crutch. It's what experienced builders do because they've learned what happens when they don't.
There is a specific way that promising workflows fail that has nothing to do with AI or code. It's called scope creep — the slow expansion of what a workflow is supposed to do until it's trying to do everything and doing nothing well.
In 2022, a mid-sized logistics company in Rotterdam began building an automated workflow to manage driver schedules. The initial design was clean: incoming delivery requests → assign to available driver → send confirmation. Three months later, the workflow also handled customer complaints, translated communications into four languages, flagged unusual delivery patterns for management review, and attempted to predict traffic delays. The original system had been working. The expanded system crashed twice a week.
Scope creep happens because workflows are seductive. Once you see that your system can do one thing, it's tempting to make it do adjacent things. Each addition seems small. But each addition adds complexity, adds more places for something to fail, and adds more cases the design didn't account for. The rule of thumb used by professional workflow designers: one workflow, one goal. If you want the system to do two things, build two workflows.
The Rotterdam logistics workflow began flagging "unusual delivery patterns" for management review — which meant it was building a profile of each driver's behavior over time. The drivers didn't know this was happening. It wasn't mentioned when the system was originally designed. At what point does a workflow that expands on its own logic start doing things its users and subjects didn't agree to? Who is responsible for noticing that it crossed a line?
You've now learned the two things that separate a workflow that works from one that doesn't: design clarity before building, and disciplined scope. These aren't just abstract principles. They're observable in the systems you interact with every day.
When you get a confirmation email after buying something online, that is a well-designed workflow: clear trigger (purchase completed), clear goal (confirm the transaction to the customer), single scope. When a bank's chatbot gets confused because you asked about both a lost debit card and a disputed charge in the same message, that is a workflow with insufficient scope definition — it was probably designed for one question type at a time and nobody planned for compound questions.
When Spotify recommends a song that feels eerily perfect, and then recommends four in a row that feel totally wrong, that is a workflow where an AI step is doing the heavy lifting and the design team has been adding inputs to the recommendation engine without clear scope boundaries. The good guess and the bad guesses come from the same system — just from different branches that were added at different times without a unified design.
Knowing this changes how you read every story about an AI doing something wrong. The headline will say "AI fails" or "chatbot goes rogue." You will know to ask: what was the design? Was the goal stated clearly? Did the builders consider failure modes before deploying? Who is responsible for the design? Most people see the output. You can see the design process — or the absence of one — underneath it.
You have been asked to design a workflow for a school newspaper. Here's the brief: when a student submits an article draft through a Google Form, the workflow should automatically route it to the correct editor (news, sports, opinion, or arts) based on the article's category, and send the student a confirmation message.
Mira is your design reviewer. She has seen a lot of workflow designs that looked complete on paper but fell apart in practice. She will ask you to justify your decisions and probe the gaps. Before you sketch anything, tell Mira your one-sentence goal and your trigger. Then build from there.
On November 14, 2022, a man named Jake Moffatt contacted Air Canada's AI chatbot after the death of his grandmother. He wanted to fly to the funeral on short notice. He asked the chatbot if he could buy a full-price ticket and claim a bereavement discount afterward. The chatbot told him yes — he could apply for a refund within 90 days of the travel date. He bought the ticket. He applied for the refund. Air Canada denied it, saying bereavement discounts had to be requested before travel. Moffatt took Air Canada to small claims court in British Columbia. On February 14, 2024, a judge ruled against Air Canada. The company was ordered to pay Moffatt the refund it had said he was entitled to. Air Canada had argued, in court, that the chatbot was a separate legal entity and that the airline was not responsible for what it said. The judge rejected this argument entirely.
The chatbot's workflow had a failure that fit a specific pattern: it had been given access to information about policies but had not been given accurate, current information about how those policies worked in practice. It gave a confident answer based on incomplete data. Nobody had tested the specific scenario Moffatt described. Nobody had mapped what should happen when a user asked about after-the-fact bereavement claims — because that was an edge case (an unusual situation) that the workflow designers hadn't considered. The chatbot didn't malfunction. It functioned exactly as designed. The design had a gap.
The Air Canada ruling matters beyond the airline industry because it settled something important: deploying a workflow makes you responsible for what it does. You cannot later claim the AI said something on its own. This is now case law in Canada. Other jurisdictions are watching.
After years of studying broken automated systems — from chatbots to data pipelines to AI routing systems — researchers and engineers have identified that failures cluster into a small number of repeating patterns. You don't need to memorize all of them. But you should know the five that show up most often in no-code AI workflows, because if you can name a failure pattern before it happens, you can design around it.
Pattern 1: The Missing Edge Case. The workflow was designed for the common case and nobody planned for the unusual one. Jake Moffatt's after-the-fact bereavement request was an edge case. Most bereavement requests come before travel. The workflow handled the common case fine. The edge case broke it. Every workflow you design has edge cases. Your job is to name them before launching.
Pattern 2: Stale Data. The workflow makes decisions based on information that was accurate when the workflow was built, but is no longer accurate. Air Canada's chatbot may have been trained on policy documents that didn't reflect current policy. A product recommendation workflow built in January might be recommending items that are discontinued by March. Data has a shelf life. Workflows that don't refresh their data go stale.
Pattern 3: The Ambiguous Instruction. An AI step in the workflow was given an instruction that seemed clear to the person who wrote it, but is ambiguous in practice. "Summarize this email professionally" — what does professionally mean? Formal? Brief? Bullet points? Without a specific answer, the AI makes a guess. The guess is sometimes right. Sometimes it produces a casual summary for a legal document because the AI's sense of "professional" differed from the designer's.
Pattern 4: Silent Failure. The workflow fails, but nobody notices because the failure doesn't produce an error message — it produces a wrong result that looks right. A summarization step that silently drops the most important sentence. A routing step that sends everything to the default path because the condition was written incorrectly. Silent failures are the most dangerous because they can run for weeks or months before anyone realizes the output is wrong.
Pattern 5: Cascading Failure. One step produces a slightly wrong output. The next step uses that output and produces a more wrong output. By the end of the workflow, the final output is wildly incorrect — but the error is invisible in any one step. This is especially common in AI workflows where each step is an AI making a judgment based on the previous AI's judgment. Errors compound.
In October 2023, the team at Zapier — one of the largest no-code workflow platforms, based in Sunnyvale, California — published an internal study of why workflows built by non-professional users failed within the first 30 days of deployment. The leading cause, accounting for 41% of failures, was not technical errors. It was that the workflow had never been tested with inputs that differed from the single example the builder used while setting it up.
A builder creates a workflow to process customer feedback. They test it with one feedback message: "Great product, love the packaging." It works. They deploy it. Then real customers send feedback like: "The packaging was terrible but the product itself is outstanding" — and the sentiment analysis step incorrectly classifies it as negative because it parsed "terrible" without context. Or a customer writes in a language the workflow wasn't designed to handle. Or a customer submits completely blank feedback. None of these were in the test.
Testing is not something you do after design. It is part of design. The minimum standard for any workflow before deployment: test with the common case, test with at least three edge cases you can think of, and test with one input that is completely wrong or malformed to see how the workflow fails. A workflow that fails gracefully — that sends a clear message saying "I couldn't process this" — is far better than one that silently produces garbage.
A well-designed workflow knows what it can't handle and says so. Instead of routing ambiguous feedback to the wrong team, it flags it for human review. Instead of sending a broken summary, it returns an error state that a person can see. Building a failure state into your design is not pessimism — it is professionalism.
One of the most consequential decisions you make when designing a workflow is where — if anywhere — a human reviews the output before it reaches the end of the chain. This is called the human-in-the-loop question, and it's not a technical question. It's a values question.
Full automation — no human review — is faster and cheaper. It also means every error the workflow makes gets all the way to the end user without a checkpoint. The HubSpot email triage workflow from Lesson 1 kept a human in the loop at the final step: the agent reviewed the AI's draft before sending. That costs time. But it also means no customer ever receives a response that the AI hallucinated entirely.
There is no universal right answer about where to put humans in the loop. It depends on how much the error costs. For a workflow that recommends movies, a bad recommendation is annoying. For a workflow that routes medical complaints, a bad routing decision could cause serious harm. The higher the cost of error, the more a human needs to be in the loop — and the earlier in the chain, not just at the end.
In 2024, several school districts in the United States began using AI workflows to flag students whose writing patterns suggested they might be struggling emotionally. The workflows were fully automated — counselors were notified by the system, but didn't review the writing themselves before the notification was sent. Some students whose writing was flagged found out they had been reported and felt surveilled and embarrassed. No human was in the loop to catch cases where the AI's judgment was wrong or the context was missing. Should automated systems that affect students' mental health records ever be fully automated? If not, where exactly does the human checkpoint go?
Air Canada tried to argue that the chatbot was its own entity. The judge didn't accept that. No court has. The consistent legal and ethical principle emerging across the UK, EU, US, and Canada is this: the person or organization that deploys an automated system is responsible for what it does. Automation doesn't transfer responsibility to the machine. It concentrates responsibility on the designer.
This is worth sitting with. Every workflow you build — even a simple one, even one just for personal use — is a small act of design that has consequences. Some are trivial. Some are not. A workflow that sends automated messages to people is making those people's experience without their consent. A workflow that stores data is accumulating information about real individuals. A workflow that makes recommendations is shaping what those individuals see and do next.
You don't need to be paralyzed by this. You do need to take it seriously. The builders who cause harm with their workflows are almost never malicious. They're just people who didn't think carefully enough about what the system would do when it ran on real inputs in the real world.
You now understand something that most companies that deploy AI workflows are still working out: failure patterns are not random, and responsibility doesn't end at deployment. You can look at any broken AI system in the news and identify which failure pattern it fell into. You can look at any new workflow being proposed — at school, at a business, anywhere — and ask: where is the human in the loop? What happens when this gets an input it wasn't designed for? What's the design for failure? These are the questions that experts are paid to ask. You can ask them now.
A youth sports league has built a workflow: when a parent submits a player registration form online, an AI reads the form, assigns the player to a team based on age and skill level, and automatically emails the parent with the team assignment and practice schedule. The league is about to launch it.
Dev is your audit partner. He's been brought in before launches to find what breaks. He'll respond to your audit points with follow-up questions that push you to be more specific. Your job: find at least three failure modes before this goes live. Use the five failure patterns from Lesson 3 as your framework. Take positions — don't just list possibilities.
In October 2023, a 15-year-old named Maya Chen — a student at Westlake High School in Austin, Texas — was helping run her school's student council. Every year, student council coordinated club fair registration: clubs submitted their info by email, someone manually copied it into a spreadsheet, someone else built a schedule, someone else posted it on the school website. It took three people a combined twelve hours. Maya had been using Zapier for about six weeks. She proposed a workflow: clubs submit through a Google Form, Zapier automatically copies the data to a Google Sheet and formats a schedule, and a final step uses a language model to write a short description of each club based on their form answers, which gets posted to the school site automatically. She demoed it to the council. It ran in four minutes. No one had to touch a spreadsheet. The council president asked if she could also use it for the spring talent show. Then the principal asked if she could build something similar for the school's volunteer sign-up process.
Maya hadn't built anything new. She had applied a pattern she understood — trigger, steps, output — to a problem that had existed for years without anyone thinking it was solvable. The tools were available to everyone. The pattern was the thing she knew and others didn't. That's the entire lesson of this course compressed into one story.
You are now in roughly the same position Maya was after six weeks. You understand the structure. You know the three shapes. You know what breaks and why. You know how to design before you build. What you don't have yet is the specific experience of sitting down and making the first decision in your first real workflow: what problem to pick. That's what this lesson is about.
The most common mistake beginners make is choosing a problem that's too ambitious. Not because the ambition is wrong — ambitious problems are the interesting ones — but because a first workflow is also a learning experience, and if the problem is too hard, the lessons get buried under the frustration of a system that doesn't work.
There is a specific set of characteristics that make a problem ideal for a first workflow:
A workflow that sends you a weekly summary of your unread emails fits all four. A workflow that automatically sends assignments to your teacher does not — the cost of failure is too high until you've tested thoroughly. Maya's club fair workflow fit all four: it ran once a year, the input was a standardized form, success meant a complete and correctly formatted schedule, and if something went wrong it was caught before publication.
You should know what tools exist and what each one is good for. This isn't about picking the "best" tool — there isn't one. It's about understanding what each tool does so you can match the tool to the workflow you actually want to build.
Zapier (founded 2011, Sunnyvale, California) is the most widely used no-code workflow platform in the world. It connects over 6,000 apps and is designed for people with no technical background. Its strength is breadth — it connects almost anything. Its weakness is that complex logic (branching, loops, error handling) requires a paid plan and can get expensive quickly. For simple linear workflows, it's the fastest starting point.
Make (formerly Integromat, rebranded 2022) is more powerful than Zapier for complex workflows. It has a visual canvas where you can literally draw your workflow, which makes the design-before-building principle easier to apply. It handles branching and error paths more naturally. The learning curve is steeper. For learners who want to build something more sophisticated, Make is often a better second tool.
n8n (launched 2019, Berlin) is open-source — meaning you can run it on your own computer for free, without paying a subscription. It's the most technically demanding of the three but gives you the most control. Large organizations use it when they need to build workflows that handle sensitive data they don't want stored on a third-party server.
Notion AI and similar embedded tools — in 2023 and 2024, many productivity platforms (Notion, Airtable, Coda) built AI workflow capabilities directly into their existing products. These are the lowest-friction starting points for beginners because the workspace, the data, and the automation are all in one place. The tradeoff: they're less flexible than dedicated workflow tools.
The tool you use matters less than the clarity of your design. A well-designed workflow runs in any of these tools. A poorly-designed workflow fails in all of them. Choose the tool after the design is clear, not before — and choose based on which one lets you implement the specific shapes (linear, branching, looping) your design requires.
Every workflow, regardless of tool or complexity, requires you to make three fundamental decisions. These decisions are not technical. They are design decisions — and they determine whether the workflow is trustworthy, useful, and ethical.
Decision 1: What data does this workflow touch, and does it have the right to touch it? Workflows that handle other people's information — names, emails, grades, health details — require that you think carefully about data permission. Even if the data is technically accessible to you, the question is whether the people whose data it is would expect you to automate processes with it. This is not a hypothetical. In 2022, students at a US university were disciplined after an automation they built began scraping and archiving other students' posts from a private class forum without those students' knowledge.
Decision 2: When does a human need to see this before it completes? You are placing checkpoints in the chain. There is no universal answer. There is only the question you must ask: what is the cost of error at this step? If the answer is high, a human checkpoint belongs there. If the answer is low, you might automate all the way to the end. What you cannot do is skip this question.
Decision 3: What is the version of this workflow that you would be comfortable explaining to the people it affects? If you cannot describe every step of your workflow to the people whose lives it touches — what it reads, what it decides, what it sends, what it stores — and have that description feel honest and fair, the design is not finished. This is the explainability standard the EU AI Act requires for high-stakes systems. You should apply it to every system you build, regardless of stakes. It's good practice and, increasingly, it's the law.
Maya's workflow wrote descriptions of school clubs using an AI and posted them automatically. The students who ran those clubs never saw the AI-written descriptions before they went live. Was that a problem? The descriptions were probably accurate. They were based on information the clubs submitted. But nobody asked the clubs whether they wanted a machine to write their public description. At what scale of impact does automatically-generated content about real people require their consent? A club description? A profile? A performance review?
Here is a honest list of what someone who understands Module 1 of this course can realistically build in the next week, using free tools, with no coding experience. These are not hypotheticals — they are real workflows that learners at this level have built and deployed.
A personal task organizer: When you add something to a notes app, a workflow categorizes it (task, idea, reminder) using an AI step and routes it to the right list. Trigger: new note added. One AI step. Two output destinations. Linear with one branch.
A reading tracker: When you finish a book and log it in a Google Sheet, a workflow uses an AI to generate three follow-up questions worth thinking about and emails them to you. Trigger: new row in Sheet. One AI step. One email output. Linear.
A club or team communication helper: When an event is added to a shared calendar, the workflow drafts an announcement message and sends it to a group chat for a human to review and send. Trigger: calendar event. One AI step. One messaging output. Linear, with a human-in-the-loop checkpoint.
None of these require code. All of them require design. The design is the work. The tool is what runs the design you made.
You've now finished Module 1. Most people who encounter AI tools experience them as products — things that happen to them. You now know the structure underneath: triggers, steps, shapes, design decisions, failure patterns, responsibility, and the three decisions that define whether a workflow is trustworthy. When someone says "the AI did something weird," you have a framework for asking why. When someone proposes an automated system that affects people's lives, you know what questions to ask. That is consequential knowledge. The rest of this course is about building with it.
You are going to design a workflow from scratch — one you could actually build this week. Choose a real problem from your life: a repetitive task at school, a club, a team, a hobby, or your own personal organization. It must meet the four criteria from Lesson 4 (repetitive, well-defined input, clear success criterion, low cost of failure).
Soren is your architecture partner. He will test whether your design is actually buildable, whether you've considered failure, and whether your three core decisions are answered. He's not trying to talk you out of building — he's making sure what you build will actually work.