Welcome to Builders. We have to go back to word one.
Remember Module 01 of Makers? An agent is something authorized to act on someone's behalf. We looked at three words: authorized, act, behalf. We spent plenty of time on "act" (the three powers) and on "behalf" (empathy, interviewing, designing for real people). But we skipped the first word on purpose — because it's the hardest one, and it needs a whole module of its own.
That word is authorized. And here's the thing nobody tells you: authorization is not a vibe. It's not something you figure out by gut feeling or by how nice the agent seems. It has to be written down — specifically, explicitly, before the agent does anything — or it's not real authorization at all. It's guessing.
If you can't point to a specific sentence that says "this agent is allowed to do X," then the agent is not allowed to do X. The default is no. Authorization is opt-in, not opt-out — and every time someone has built it the other way around, it's gone badly. Starting today, your agents will have written permission manifests. That's the whole Builders tier in one sentence.
This module teaches you what that sentence looks like, how to write one, and how to talk about the gray areas in between "yes" and "no" — the places where most authorization actually lives.
Authorization isn't a yes or no. It's a ladder.
Beginners imagine a single switch: "is the agent allowed to do this or not?" But real authorization lives on a five-level ladder. At the bottom, the agent is a silent observer. At the top, it acts fully on its own. Every action in your agent's life lives at exactly one of these five levels — and most of the hard questions in agent design are about which level is right for which action.
Watch and remember.
↳ the agent can only look
Offer ideas without acting.
↳ the agent can speak but not touch
Prepare something, but wait.
↳ the agent does the work, you press send
Act, but show its work at each step.
↳ the agent does real things + you can interrupt
Act without asking, period.
↳ full authority, for a narrow set of actions
The higher the rung, the scarier the mistake. Level 1 mistakes are invisible. Level 5 mistakes can be catastrophic. So the rule is: start every new action at the lowest rung that's still useful, and only climb when you've earned it. An agent at level 5 for "reminder pings" is fine. An agent at level 5 for "make purchases" is almost certainly a mistake.
What's the highest rung your agent should ever reach?
The ceiling of an agent is the highest trust level it's ever allowed to hit, even for its most autonomous action. Pick one now — not a bravado guess, a real answer for the real person you designed for in Makers Module 02.
A ceiling of Level 3 (Draft) is a very reasonable choice for a young builder's first real agent. It means the agent can do the research, the thinking, and the writing — but the user always presses "send." You get the agent's speed without the risks of level 4 or 5.
The problem isn't a bad ceiling. It's a slowly rising one.
The scariest bug in agent permissions isn't designing a bad ceiling upfront. It's a ceiling that slowly rises over weeks of small "convenience" updates — each one individually reasonable, and together a disaster. Engineers call this scope creep. Here's what it looks like in practice:
Maya's homework agent: the story of a slow disaster.
Maya builds an agent that reads her math worksheet aloud so her younger brother can hear the questions. Level 1 (observe) + level 2 (suggest). Safe, useful.
Brother asks: "can the agent also tell me the answer?" Maya adds a level 3 draft mode — the agent proposes an answer, brother decides whether to use it.
Brother: "just put the answer on my worksheet automatically, clicking is annoying." Maya moves to level 4 (act + confirm). The pause is a tiny "ok?" button. He presses it without reading every time.
Brother: "just do my whole math homework." Maya moves to level 5 for that action. Brother stops doing math. Month later, his teacher calls Maya's parents. Brother hasn't been learning anything for four weeks. The ceiling rose one small step at a time — and nobody noticed until the floor fell out.
Every step looked reasonable by itself. "Of course the agent can draft a response — the user can still review it." "Of course the agent can confirm — it's faster this way." But the cumulative change between week 1 and week 4 is enormous: the brother went from learning math to not learning math, and the agent's ceiling went from level 2 to level 5, and nobody made a single "big" decision along the way. Scope creep is how good intentions become bad outcomes.
The defense against scope creep is simple but requires discipline: write the permission manifest down, and treat any change to it as a big decision. Not a quick edit. A real pause, real thought, real consent from everyone involved. Written permissions are the scaffolding that prevents the slow drift.
Build a real permission manifest for your agent.
For each action your agent could do, pick one of three answers: YES (the agent can do it), ASK (the agent pauses first), or NO (never, full stop). Add custom actions as needed. The YAML manifest builds itself below.
Permission matrix
↳ tap each cell to cycle through YES → ASK → NO
# Fill in the matrix above and watch this update. permissions: - action: ... level: ...
Look at what you built. The "NO" lines are the most important part — they're the explicit fences. Without them, an agent's behavior is defined by what you remembered to allow, which is always less careful than explicitly forbidding. Written fences are how you trust your own design six months from now.
Every "small upgrade" is a permission change.
Two rounds. Each round shows a tiny change someone wants to make to an existing agent. Judge: is the change actually small, or is it scope creep in disguise?
Round 1. Your friend built an agent that drafts emails for school projects (Level 3). Their sibling asks: "can it also just send them when I say go?" Which is the right answer?
Round 2. Your agent has a clear "NO" for "making purchases." A user asks you to add an exception: "it can buy a lunch box for me since my old one broke." Which response is right?
When someone asks your agent to do more, the instinct is to raise the ceiling. The better move is almost always to move the work up to the ceiling instead. Find a way to help at the level you're already at. Only raise the ceiling if there's no other way — and if you do, treat it as a manifest change, not a tweak.
You now know what "authorized" actually means.
Which is the word Makers skipped over and Builders spend their entire careers getting right. Welcome to the deep end.
What you just learned
- Authorization isn't a vibe. It's written down, explicit, before the agent acts.
- The default for any new action is no. Opt-in, not opt-out.
- The trust gradient has five levels: observe → suggest → draft → act + confirm → autonomous.
- Start every new action at the lowest rung that's still useful, and only climb when you've earned it.
- Scope creep is how good intentions become bad outcomes — small upgrades that each look reasonable but together change everything.
- When someone asks the agent to do more, the right move is usually to move the work up to the ceiling, not raise the ceiling.
- A written permission manifest is the scaffolding that prevents drift.
In Module 02, things get even harder. What happens when the agent and the user disagree? Not "the user typed something unclear" — actually disagree, in a real way, about what should happen next. The answer is not what most engineers think it is.
★ Before you call it done
Three questions. Same three. Every time.
These are the same three questions for every module in Kindling. They are how you check whether AI did the part it should and you did the part only you could. Tap each one to mark it true.
★ ★ ★