What Changes When It Can Act
You draw the line between a system that answers and a system that acts, and you write down — before you build anything — what yours is allowed to do, what it must never do, and who answers for it when it gets something wrong. You pick the one real task the next fifteen modules will build against, and you pick your track. By the end you have a charter: one page, four sections, written in advance rather than assembled after an incident.
ANSWERING ACTING
─────────────────────────┬──────────────────────────────
│
it says something │ it does something
you read it │ the world changes
you decide │ you find out afterwards
cost of a mistake: │ cost of a mistake:
your time │ whatever it touched
│
┌──────────────┐ │ ┌──────────────┐
│ you ✋ │ │ │ ?????????? │
│ read it │ │ │ │
│ before it │ │ │ where does │
│ counts │ │ │ the human │
└──────────────┘ │ │ go now? │
│ └──────────────┘
│
THE CHARTER
allowed · forbidden · owner · wrongThe whole course is an answer to the box on the right. This module writes the question down before the building starts.
- State, in one sentence, what changes about risk the moment a system acts instead of answers.
- Name the four parts of any agent harness and say which one you would change to make a system safer.
- Place your intended system on the five-rung trust ladder and name the evidence that would move it up one rung.
- Choose the smallest of the three shapes that solves a given problem, and defend the choice.
- Write a charter that a person who did not build the system could read and know what it is allowed to do.
- Name one thing your system must never do, and say what enforces that — a setting, a structure, or a promise.
stack/charter.md — one page covering four things: what your system is allowed to do, what it must never do, who is accountable when it does something wrong, and what "wrong" would concretely look like. Every later module either narrows this file or is checked against it.
There is a specific moment where people stop being comfortable with AI, and it is not the moment they discover it makes things up. Most people absorb that quickly. They learn to read output the way they read a confident colleague who has not checked: useful, fast, occasionally wrong, always worth a glance.
The moment trust breaks is when the output stops being output. When the draft is sent. When the file is written. When the record is updated, the refund is issued, the message goes to the client. The mistake did not get worse — the same wrong sentence, generated the same way — but the cost of it moved from your time to your reputation, your data, or your money.
This is worth saying plainly because a lot of tooling blurs it deliberately. A demo where an agent "handles your inbox" is doing something categorically different from a demo where it summarises your inbox, and the interface often makes them look like the same feature with a different toggle. It is not a toggle. It is the whole subject of this course.
So the first discipline is to notice the line every single time you cross it. Not to avoid crossing it — crossing it is where the value is, and a system that only ever suggests is a system that only ever saves you typing. The discipline is to know you are crossing, and to have decided in advance what happens there.
Key insight: the risk of an AI system is not a property of the model. It is a property of what the model is wired to.
The thing you are building is not "an AI". It is a harness: a specific arrangement of four parts, and everything about its behaviour and its danger comes from how you set them.
The model decides what to do next. It is the part everyone argues about and, in practice, the part that matters least to whether your system is safe. A better model makes better decisions more often. It does not make an unbounded system bounded.
The tools are what it can reach. A file system. A browser. Your calendar. A workflow with a URL. This is the part that turns a decision into a change in the world, and it is the part you should be most conservative with.
The loop is what makes it an agent rather than a function: it acts, sees the result, and decides again, until something says stop. The stop condition is a design decision. Systems that run away are systems where nobody wrote one.
The permissions are what it is allowed to do with the tools — read only, write here but not there, reach this host but not that one, ask before this class of action. This is the cheapest safety you will ever buy, and the one people configure last.
Learn to locate these four in whatever tool you are handed and you can evaluate an agent product in about ten minutes, including ones that do not exist yet. Every vendor names them differently. There are only four.
┌───────────┐ decides ┌───────────┐ acts on
│ MODEL │───────────▶│ TOOLS │──────────▶ the world
└───────────┘ └───────────┘
▲ │
│ result comes back │
└────────────────────────┘
THE LOOP
PERMISSIONS ── the box drawn around all of it,
and the only part you fully controlThree of the four parts are given to you. The fourth is the one you set.
Autonomy is not a switch, and it is not a personality trait of your system. It is a rung, and you climb it on evidence.
5 acts silently no report unless something fails
4 acts and reports you read afterwards, you can undo
3 acts with approval you say yes, item by item
2 drafts it prepares, you send
1 suggests it tells you what it would doAlmost everything worth building lives at rung 2 or 3 for far longer than the people building it expect. That is not timidity. Rung 2 — it prepares, you send — captures most of the time saving of full autonomy while leaving the cost of a mistake at zero. The gap between rung 2 and rung 5 is where nearly all of the risk lives and a surprisingly small share of the value.
The rule for climbing: you move up one rung when you have evidence from the rung below. Not a good week. Evidence: a count of runs, a count of interventions, and a record of what you rejected and why. If in fifty gated runs you rejected four, you do not yet know whether rung 4 is safe — you know it fails eight percent of the time, and you have to decide whether that is survivable unattended. If you rejected none in fifty, ask whether you were actually reading them.
You can also move down a rung. Systems earn demotions. A system that has been at rung 4 for three months and then meets a new kind of input goes back to rung 3 until you have seen it handle a few.
Warning: the most common way people end up at rung 5 is not a decision. It is a gate that got annoying and was removed on a busy Thursday, and nobody wrote down that it happened.
Work you might hand to AI comes in three shapes, and picking the wrong one is the most expensive mistake in this whole subject — more expensive than a bad prompt, a bad model choice, or a bad tool.
A conversation. You are in the loop the whole time. Good for work that is different every time, where your judgement is the point, and where nothing is repeated often enough to be worth systematising.
A fixed workflow. Rules you wrote, running in the same order every time, possibly with a model doing one step inside it. Good for work with a knowable shape: this trigger, these steps, this result. It is boring, cheap, debuggable, and it carries most of the load in every real system.
A supervised agent. A loop that decides its own next step. Good when the shape genuinely is not knowable in advance: unknown number of steps, unknown tools needed, unknown obstacles.
The stop rule: use the smallest shape that solves the problem. Not the most impressive. The smallest. If a rule can find the answer, a rule should find the answer — it will be cheaper, faster, more reliable, and it will tell you which step broke instead of telling you a story about what it tried.
The reason this matters so much is that the shapes have different failure profiles. A conversation fails visibly, in front of you. A workflow fails loudly, at a named step. An agent fails quietly and creatively, and the report it writes about its own run is generated by the same thing that made the mistake.
When your system sends the wrong invoice to the wrong client, the client does not have a conversation with your system.
This sounds obvious written down and it is routinely ignored in practice, because there is a comfortable ambiguity in "the AI did it" that people reach for under pressure. Kill it now, in writing, before there is anything to be defensive about. One named person is accountable for what this system does. In a one-person shop that is you, and writing it down still matters, because it forces the next question: accountable for what, exactly, and how would you find out?
This is also the honest answer to a question clients ask and vendors dodge. If you build these systems for other people, your charter is the beginning of the conversation about who carries which risk, and having one before the first incident is worth more than any indemnity clause you negotiate after.
You are going to build one real thing across sixteen modules. Choose it now and it accumulates. Choose it in module nine and you spend the first eight modules reading.
Four criteria, all of them required:
Recurring. It happens weekly at least. A once-a-quarter job will not give you enough runs to learn anything, and you cannot climb the trust ladder on a sample of two.
Bounded. You can describe where it starts and where it stops in one sentence. "Handle customer emails" is not bounded. "When a supplier invoice arrives by email, extract the line items and add a row to the tracking sheet" is.
Currently manual. Somebody does it by hand today, which means you have a baseline to compare against and material to test with. If it does not exist yet you will spend the course inventing requirements instead of learning.
Yours. You own the outcome and you can change the process without asking three people. This is the criterion people skip, and it is the one that stalls the course in module ten when the gate needs someone else's sign-off.
Write the task down at the top of your charter in one sentence. If it takes two sentences, it is two tasks — pick the smaller one.
Every module from here teaches one idea and then splits at the lab.
Builder works in a terminal and a repo. You will run a coding harness, write config files, build a small MCP server, and end with a repo an agent can work in safely. Pick this if you are comfortable installing things and reading an error message without flinching.
Operator works in a browser. You will configure a workspace with files and connectors, build workflows in n8n or Make, expose one of them as a tool your agent can call, and end with a scheduled, gated system. Pick this if you have never opened a terminal and would rather it stayed that way.
The lanes produce the same artifacts by different means, so the two tracks converge every time. Pick the one that matches the tools you will still be using in six months, not the one that sounds more serious. An operator running a gated n8n workflow that saves four hours a week has built something more valuable than a builder with a beautiful repo and nothing in production.
You can switch. The artifact chain does not care which lane wrote the file.
A consultant builds an agent that reads a shared inbox and files each message under a client folder. It works for three weeks. Then a supplier replies to an old thread with an attachment, the subject line no longer matches any client, and the agent — asked to file everything — creates a new client folder named after the supplier's email signature, moves eleven messages into it, and reports success. Nobody notices for nine days, because the report said success and nobody had written down what wrong would look like.
Nothing here was a model failure. The system had no charter, so it had no definition of an unacceptable outcome, so it had nothing to detect and nothing to refuse. A single line — it must never create a client folder; it files into existing folders or it asks — would have turned a nine-day silent mess into one question in a queue.
Fifteen minutes. You are writing one page. Do not build anything yet.
- Your task sentence contains a trigger and a stopping point, and someone else could tell you when it had finished.
- Every entry under Allowed names a real place — a path, a sheet, a folder, a mailbox — not a category of access.
- At least one line under Never is something you were tempted to allow.
- What wrong looks like contains scenes with a sequence of events, not adjectives like "inaccurate" or "inappropriate".
- The charter fits on one page. If it runs longer, the task is too big; go back to step three.
Do not write a charter for a task you are not going to build. This is a document that earns its keep by being checked against something real, and a folder of charters for hypothetical systems is procrastination with good posture. If you cannot name the recurring, bounded, manual, owned task today, spend the week noticing what you actually do by hand and start the course next week with a real one.
You know your task better than you can write it down cold. This prompt makes the machine interview you instead, one question at a time, and drafts the charter from your answers. Use it if the blank page is what is stopping you. Run it in whatever tool you are using now — this one needs no setup.
<task>
Interview me and then draft a one-page charter for an AI system I am about to build.
</task>
<context>
I am at the start of a course on building AI systems that take actions, not just
give answers. Before building, I have to write down what my system is allowed to
do, what it must never do, who is accountable, and what going wrong would look
like concretely.
The task I have in mind: [describe your recurring task in one or two sentences —
what triggers it, what happens, where it stops]
</context>
<instructions>
1. Ask me ONE question at a time. Wait for my answer before asking the next.
2. Ask at most eight questions. Prioritise: the exact trigger, the exact stopping
point, every system or record touched and whether each is read or written,
what is irreversible, who else is affected when it goes wrong, and who would
notice.
3. If an answer of mine is a category rather than a specific thing, push once for
the specific thing, then move on.
4. After the last answer, output the charter.
</instructions>
<output_format>
A markdown document with exactly these headings and nothing else:
## The task (one sentence, includes trigger and stopping point)
## Allowed (bulleted; each line names a real path, sheet, folder or
service, and says read or write)
## Never (bulleted; at least three lines, each a specific action)
## Accountable (one name, one sentence on how they would find out)
## What wrong looks like (three short scenes, 2-3 sentences each, each a
sequence of events ending in what someone discovers)
</output_format>
<rules>
- Do not invent details about my task. If you need one, ask for it.
- Do not add headings I did not ask for and do not add a preamble or summary.
- No statistics, no benchmarks, no claims about how often things fail.
- Under "What wrong looks like", write scenes with events, not adjectives.
- Keep the whole document under one page.
</rules>Run this after the charter, against the same task. It argues for the smallest shape that solves your problem, which is usually not the one you had in mind when you signed up for a course about agents. It is deliberately built to talk you down.
<task> Tell me the smallest shape that solves the task below, and argue against the larger shapes. </task> <context> Work handed to AI comes in three shapes: - A conversation: I am in the loop the whole time. - A fixed workflow: rules I wrote, same order every time, optionally with one model step inside it. - A supervised agent: a loop that decides its own next step. The rule is to use the SMALLEST shape that solves the problem. Smaller shapes are cheaper, more reliable, and fail at a named step instead of failing creatively. My task: [paste the "## The task" line from your charter] Systems it touches: [paste your "## Allowed" list] Things it must never do: [paste your "## Never" list] </context> <instructions> 1. Say which shape is smallest-that-works, in one sentence. 2. For each larger shape, say specifically what it would add for this task and whether that addition is needed. Be concrete about the task, not general. 3. Name the one property of my task that most drives the answer. 4. Name the condition under which your answer would change. </instructions> <output_format> ## Smallest shape that works [one sentence] ## Why not the larger ones [one short paragraph per larger shape] ## The deciding property [one sentence] ## What would change my answer [one sentence] </output_format> <rules> - Default to the smaller shape. Recommend an agent only if you can name a step where the number of actions is genuinely unknown before the run starts. - Do not recommend specific products or tools. - Do not hedge with "it depends" without saying what it depends on. - No more than 300 words total. </rules>
Write the five headings on paper and fill them in. The only part that is genuinely hard is What wrong looks like, and the trick for that one is to stop trying to predict and start remembering: think of the last time a manual version of this task went wrong, and write down what actually happened. Real past failures make better scenes than imagined future ones, and they are the ones your system will repeat.
Save the charter where the rest of the course can read it. Every later module either narrows it or is checked against it — Module 02 turns Allowed into a permissions table, Module 10 turns Never into a gate, and Module 15 hands the whole thing to somebody else.
Save as: stack/charter.md — read again in Module 02, Module 10, and Module 15.
Say these out loud. If you cannot, reread the section named after each.
- I can say what changes about risk the moment a system acts instead of answers. (The line where trust breaks)
- I can name the four parts of a harness and which one I would change to make a system safer. (A harness is four parts)
- I can name the rung I am starting on and the evidence that would move me up one. (The trust ladder)
Module 01 gets a harness running on your machine or in your browser and puts your charter's task through it once, at rung 1, with nothing at stake. You will write down what it touched.