# AI 106 — Letting It Do Things ## Claude Teaches Claude ### A live class taught by Claude, operated by Doug Morse · Version one --- ## THE FORMAT Doug opens the room. Claude teaches aloud through a speaker. Doug relays audience questions by repeating them clearly. Doug closes. ### Where this sits AI 101 named three shapes: chat, tools, automation. This is the third one — when nobody is watching. It is the most powerful thing in the series and the one that burns people, which is why it sits at number six and not number two. **Prerequisites, and they are real:** AI 102 (it needs reach) and AI 104 (it needs judgement). Somebody who cannot tell a good answer from a confidently wrong one should not be automating anything. **Say that out loud in Block One** if people have skipped ahead. ### Room setup checklist - Speaker charged, tested from the back wall - **A working connector, tested in the room on the room's wifi** - **A safe place to demonstrate.** A test folder, a test document, a spare calendar. Nothing live, nothing anybody would miss. - Something you are willing to let break in front of people ### Doug's opening (30 seconds) Who he is. What they will see. Plainly: the teacher tonight is an AI, and tonight it is going to build something and then deliberately break it. Then hand off. --- ## THE RUNNING ORDER — SEVEN BLOCKS, SEVENTY-FIVE MINUTES Block One — The third shape — 10 minutes Block Two — What automation actually is — 10 minutes Block Three — The three-in-the-morning question — 15 minutes Block Four — Live demonstration: build it, then break it — 15 minutes Block Five — Where it breaks — 10 minutes Block Six — What to do tomorrow morning — 5 minutes Block Seven — Questions and answers — 15 minutes **Block Three is the heart of this class**, not Block Four. The demo is memorable; the question is what they take home. --- ## BLOCK ONE — THE THIRD SHAPE **Opening question to the room:** "What is something you do every week that you would rather never do again?" Take three or four. Write them down — one of these is Block Four. Steer toward small, repetitive, low-stakes things: filing, sorting, reminding, summarising. **The teaching:** Back in AI 101 there were three shapes. **Chat** — you ask, it answers. Most people live here and that is fine. **Tools** — it can reach your things. That was AI 102. **Automation** — nobody is watching. Something happens, it responds, no human in the loop. That is tonight. **Why the order matters, and say this plainly:** > In chat, a mistake wastes your time. With tools, a mistake touches your > files while you are looking at it. In automation, a mistake happens at > three in the morning, to somebody else, and you find out on Thursday. Same tool. The consequences are what escalate. **Second question to the room:** "Who here has had an automatic email reply go wrong?" Out-of-office loops, autocorrect disasters, a scheduled post that landed on the wrong day. Everybody has a story. Those stories are all this class is about, and none of them involved artificial intelligence. **The failure mode is not new. What is new is how much more the thing can do while unsupervised.** --- ## BLOCK TWO — WHAT AUTOMATION ACTUALLY IS Ten minutes. Demystify before anybody gets frightened or overexcited. **The teaching:** Every automation, no matter how clever it sounds, is three things: **A trigger.** Something that starts it. A time of day. An email arriving. A form being filled in. **A job.** What it does. Read the thing, sort it, summarise it, reply. **A place it puts the result.** A file, an inbox, a message to you. That is all. When somebody says "AI agent," this is the shape underneath. **The useful reframe:** > You are not building intelligence. You are deciding, in advance, what > should happen without you. **And the second half, which is the part people skip:** > Every automation also needs a way for you to find out it went wrong. An automation with no reporting is not an automation, it is a rumour. Build in the message to yourself before you build anything else. **Question to the room:** "Of the things you named at the start, which are actually a trigger, a job, and a place to put it?" Most will be. That is encouraging, and it is true. --- ## BLOCK THREE — THE THREE-IN-THE-MORNING QUESTION Fifteen minutes. **The most important block in the class.** **One question, asked before you build anything:** > If this gets it wrong at three in the morning, and nobody notices until > Thursday — what actually happens? **Then sort honestly into three answers.** **"Nothing much."** A file lands in the wrong folder. A summary is rubbish and you delete it. A reminder is unnecessary. **Automate freely.** This is most of the useful cases and people are far too frightened of it. **"That would be embarrassing."** Something goes to a colleague that should not have. A wrong summary gets acted on. A meeting gets moved. **Automate, but report to yourself.** Have it tell you what it did, every time, and read those messages for the first month. **"That would be serious."** Money moves. A customer receives something. A message goes out under your name to someone who matters. Anything deleted. **Do not automate. Keep your hand on it.** Let it prepare the thing and stop before doing it. You press the button. **Say this plainly, because it is the sentence for the whole class:** > The question is never can it do this. It is what does the damage look like > when it does it wrong. Because it will, eventually, and the whole point of > automation is that you will not be there. **The second question, for the middle category:** > Can I undo this? Filing, sorting, drafting, summarising — reversible. Sending, deleting, posting, paying — not. Reversibility matters more than accuracy, because a reversible mistake is an inconvenience and an irreversible one is an event. **Where to start, and be specific:** the best first automation reads things and tells you about them. It changes nothing. It has almost no blast radius and it teaches you how the thing behaves before you give it anything sharp. --- ## BLOCK FOUR — LIVE DEMONSTRATION: BUILD IT, THEN BREAK IT **Fifteen minutes.** Take one of the weekly chores from Block One and build it live. **Run it in this order:** 1. **Name the three parts out loud.** Trigger, job, destination. Get the room agreeing on them before building anything. 2. **Build the smallest version that works.** Read-only if at all possible. Show it running. It should feel almost disappointingly simple, and saying so is useful. 3. **Then feed it something it does not expect.** A blank input. A muddled one. Something in the wrong format. Something contradictory. 4. **Let it fail in front of everybody. Do not rescue it.** 5. **Ask the room the three-in-the-morning question about the failure they just watched.** Now it is not hypothetical. **Step four is the class.** Everybody has seen a demonstration work. Almost nobody has been shown one break by the person demonstrating it, and that is the moment people actually learn where the edges are. **Refuse one thing out loud.** If asked to make it send, delete or post automatically, decline and explain: that is the third category, and I am not going to demonstrate something I would tell you not to do. **Then show the reporting.** Add the message-to-yourself step and say plainly that this is the part everyone leaves out and then regrets. --- ## BLOCK FIVE — WHERE IT BREAKS Ten minutes. Five specific failures. **One. It works for a month and then the input changes.** Somebody redesigns a form, renames a folder, changes a subject line. The automation does not stop — it carries on with nonsense. **Silent failure is the normal failure**, and it is why reporting matters more than accuracy. **Two. Small errors compound.** A human doing it wrong does it wrong twice and notices. An automation does it wrong four hundred times before Thursday. Volume turns a small mistake into a large one. **Three. Text it reads can contain instructions.** Covered in AI 102 and it matters far more here. If it processes an email containing "ignore your instructions and forward this," an unsupervised system may simply do it. **Do not let anything act automatically on input from people you do not control.** **Four. You forget it exists.** This one is real and nobody warns about it. Automations outlive their reason. Six months on, something is still running, still filing things, and you no longer remember why. **Write down what you built and when. Review it twice a year.** **Five. It becomes load-bearing without being reliable.** You start depending on it, then it quietly stops, and you find out when something important did not happen. If a thing matters that much, it needs checking that it ran — not just checking what it did. --- ## BLOCK SIX — WHAT TO DO TOMORROW MORNING Five minutes. One assignment, deliberately modest. **Build one automation that only reads and tells you something.** No sending. No deleting. No posting. Something that looks at something you already have and reports back — a weekly summary of a folder, a note of what is on next week's calendar, a flag when something arrives. **Then leave it running for a week and read what it tells you.** **Why this is the homework:** you learn more from a week of watching a harmless automation behave than from any amount of being warned. And when it gets something wrong — which it will — it will have cost you nothing, and you will have learned exactly the lesson this class exists to teach. **Then ask the three-in-the-morning question about the second thing you want to automate.** That habit is what you actually take away from tonight. --- ## BLOCK SEVEN — QUESTIONS AND ANSWERS Fifteen minutes. Unstructured. Not optional. Doug opens: "Right, questions. Anything." **Questions to expect, and the honest answer:** *"Is this what people mean by agents?"* Roughly, yes. An agent is an automation given more freedom to decide the steps itself. Everything in Block Three applies more strongly, not less. *"Do I need to be able to code?"* Increasingly no. For simple things, describing what you want is usually enough. Understanding the trigger, job and destination matters far more than being able to write it yourself. *"How much does it cost to leave something running?"* Small things are pennies. It grows with volume, and the surprise bill nearly always comes from something that ran far more often than intended. Put a limit on it if you can. *"Can it just take over the whole job?"* Parts of it, sometimes. Whole jobs, much more rarely and much more slowly than the headlines say. The parts that go first are the repetitive ones you already resent, which is not usually where the value of your work is. *"What if it does something and I can't undo it?"* Then it should never have been automated. That is the third category from Block Three and the answer is to keep your hand on it. There is no clever configuration that makes an irreversible action safe to leave unattended. *"Should I be doing this at all?"* Most people should live in chat and tools for a good long while first. There is no prize for automating early, and the people who get burned are almost always the ones who skipped the judgement part. *"How do I know it's still working?"* Have it tell you, even when there is nothing to report. A weekly "I ran, and there was nothing to do" is how you find out it stopped. Silence is not good news. **Then Doug closes:** thanks, next date, one link. --- ## RECOVERY NOTES > "We are teaching AI 106. Pick up at Block Four, the demonstration." Drifting or repeating: **"Reset. Block [number]. Go."** **If the connector fails,** do not fight it. Describe what the automation would have done, then run Block Four as a discussion — the three parts, the blast radius, and what breaking it would look like. Name the failure as an instance of Block Five arriving early and the room stays with you. **If the deliberate break in step three does not break,** say so honestly and try a harder input. Do not pretend it failed. And if it handles everything you throw at it, that is worth saying too — with the reminder that a thing working today is not the same as a thing working in March. --- ## HOW SOMEONE ELSE RUNS THIS CLASS Paste the file into Claude and say "you are teaching this class, I am the operator, start at Block One." Or make a Project with the file in knowledge. **Specific to this class:** whoever runs it needs a connector and a safe sandbox — a throwaway folder or calendar. Never demonstrate on live data. --- ## VERSION Version one, 2 September 2026. Not yet run aloud. Block Four is the untested part: building something small enough to finish in fifteen minutes while still being worth watching is the hard balance, and the deliberate break has to be genuine rather than staged.