Hand a piece of work to somebody else and you get it back faster, knowing less about it than if you had done it yourself. That trade is the whole subject, and it did not begin with AI — organizations have been climbing this ladder since Tannenbaum and Schmidt described it in 1958, and agile teams still play delegation poker over it. What is new is that you can now move up and down it in one command, several times an hour, per task.
Ask what can actually be handed over and the list turns out to be short:
parts of a task you are still holding the syntax you know what you want, not how to spell it the thinking you know the goal, not the approach the writing you know the change, not the keystrokes the checking you stop reading the work and read signals about it the task itself the running nobody is at the prompt the choosing you stop picking what gets worked on
That is six, and they only go in that order — you cannot hand over the checking while still typing every command. Which is why it is a ladder and not a menu, and why reviewer and approver are two rungs rather than one: reading the work and reading a signal about the work are different acts, and the gap between them is where most surprises live.
Notice too that the list changes character halfway down. The first four are pieces of a job you are still holding. The last two are the job, and then the choosing of jobs — outside it rather than further along.
Each rung has an invariant — one decision still yours — and that decision is also the last place your understanding gets refreshed. Hand over the writing and you stop learning the codebase by typing it. Every rung up buys leverage and costs you fidelity.
The formal version of all of this — with the human-factors literature it rests on, the two boundaries stated separately, and the experiments that would show it is wrong — is Six Levels of Delegation (PDF).
Six rungs, then. Here is what each one looks
like from the prompt —
the teal
lines are your keystrokes, and they thin out as the levels climb. Talk to
toast while you read: press ` anywhere on this page to drop the
terminal.
One command in, one answer out.
Still yours: every action. You type each one, and nothing happens that you did not ask for.
$ ls -al | toast "roast my directory" files-1 through files-213? That's not a directory structure, that's a cry for help. You have `toasted-15.cpp` and `v-9.c`. Git exists. Use it. `Claude.dmg`, `Ollama.dmg`, `Second_Life`... stop hoarding installers from 2024. `thephonebetweenus` has 5 versions. Make a decision. 16GB LLM file sitting next to a `.DS_Store`. Respectable trash heap. $ ps aux | toast "anything suspicious" Found a few things: 1. **VidyoConnect**: Running from a temp folder (`AppTranslocation`) with `--no-sandbox`. Drag it to `/Applications` and reinstall to fix security flags. 2. **Onnai.app**: Located in Xcode `DerivedData`. Is this your debug build? 3. **Zombies**: 2 defunct processes (PIDs 44310, 44023) need cleanup. 4. **AI Load**: LM Studio and Ollama are active and using resources. $ history | toast "what was I trying to do yesterday" Moved files, opened the San Mateo call list, and checked your site's HTML. Then you roasted your directories and investigated high CPU usage.
One question, one answer, back to your prompt. Pipe anything in —
logs, configs, ps output — and project context rides along from the
nearest .crumbs up the tree. Every command is yours.
You drive; toast thinks alongside.
Still yours: every direction. It proposes; you decide what is worth doing next.
A bare toast opens chat — same tool, but now context carries
across turns. Ask, follow up, drill in:
$ toast --- > @models.py explain this Three SQLAlchemy models — User, Session, Token. User owns Sessions; the cascade on delete is doing more than you probably intend. > which cascade? Session.tokens. Deleting a user nukes their sessions and every token — including the ones you keep for audit. Split the relationship. > /exit
History lives in ./.chat — leave and come back, and the
conversation doesn't replay, it continues. That makes chat the ideal test
bench for a .persona: drop the file in the directory, talk to it, tune
it. @file inlines any file into context. Every next move is yours,
which is why you still understand the answer.
toast writes; you review it before it ships.
Still yours: every change. You stopped writing the work. You still read all of it.
In Unix, the reviewer can be another toast — stdout is stdin, so adversarial review is a one-liner. Personas are just symlinks to the binary:
$ toast --add Dev && toast --add Paranoid Added Mimic: /usr/local/bin/Dev -> /usr/local/bin/toast Added Mimic: /usr/local/bin/Paranoid -> /usr/local/bin/toast $ cat auth.py | Dev "fix the token refresh" | Paranoid "what's wrong with this patch" The patch works but opens a race — two concurrent refreshes both pass the expiry check. And the old token stays valid 30s after rotation.
Each stage sees only the previous stage's stdout, so the review is
independent of the reasoning that produced the patch — Paranoid never sees the
prompt Dev was given. Want both in one place? toast --room dev,paranoid
puts them in a single chat session.
You stop reading the work and start reading signals about it.
Still yours: every result. You stopped reading the work. You read whether it passed.
Hand toast a file and it patches the file itself — atomically, at scale:
$ find . -name "*.py" -exec toast {} "add type hints" \; [toast] Updated api.py [toast] Updated models.py (warning: 2 matches found, replaced first only) ... 197 more ... $ mypy . && ito log "added type hints" Success: no issues found in 199 source files logged 4c1f7a9 added type hints # files patched: 199 · files you read: 2
A green check tells you the code passes the check — not that the check
covers what matters. Did you read the warning on models.py, or did you
read Success? Level 4 is a fine place to work, as long as you know that's
the trade.
Something changed between the last rung and this one, and it is worth naming. Up to here the work itself could surprise you. From here you are reading reports, and what you can know is bounded by what somebody thought to measure. Control engineers formalised that distinction in 1960 and called it observability: whether a system's internal state can be reconstructed from its outputs.
Nobody's at the prompt.
Still yours: the system. You wrote the loop, the allowlist and the stopping condition. Then you left.
Autonomy is opt-in: .tools is an allowlist you write yourself, one
command per line — no file, no tool calls. Put toast on the list and
the agent's favorite tool is another toast. Cron for the routine, loops for the
open-ended — toast exits 1 when the model prints DONE,
so the shell itself decides when work is finished:
# the allowlist — one command per line. note who's on it $ printf 'df\njournalctl\nsystemctl\ntoast\n' > .tools # daily briefing 0 7 * * * curl -s https://news.ycombinator.com | sed 's/<[^>]*>//g' | toast "top 5 articles by novelty" | mail -s briefing you@example.com # monday, 9am — you are now absent from your own standup 0 9 * * 1 ito history | toast "write my standup, first person, modest" | mail -s standup you@example.com # loop until the model itself says stop while toast server.py "refactor until clean; print DONE when finished" # weeks later, something feels off $ ito history | toast "what was the focus last week"
One teal line left — and it's you asking the AI to narrate your own
machines back to you. Every tool call runs through
jam, five rounds max — and with
toast in .tools, toast can call toast: delegation all the
way down. This is the level that runs your machines while you sleep — use it on
purpose, not by drift.
You plant; the system grows it; you harvest.
Still yours: the environment. Not the tasks, not the order, not the schedule. What grows, and where.
The audience automates tasks — a farmer grows deliverables. Seed a
directory with an outline, a .persona, and a .tools that
includes toast itself, set the loops running, and come back for the harvest: a
manuscript, a go-to-market plan, a codebase:
# plant: an outline, a voice, and tools — toast included $ mkdir novel && cd novel && vim outline.md .persona $ printf 'toast\nEditor\n' > .tools # grow: chapters draft themselves, then twenty polish passes (jam) 12 times toast outline.md "draft the next chapter into its own file; keep continuity notes in .crumbs" 20 while Editor manuscript.md "polish for publishing" # another field: the go-to-market plan, every monday night 0 22 * * 1 cat brief.md | toast "grow the GTM plan — positioning, pricing, launch, competitor scan via toast; DONE when complete" # harvest $ wc -w ch*.md 84312 total # the notes the system kept for itself $ cat .crumbs Mara learns about the ledger in ch7 — don't re-reveal it later. The fire is day 3. Osei's limp: left leg. Chapters 9–12 are winter. $ cat launch-plan.md | toast "poke holes in this"
The crop is plain files — and so is the memory: the model writes
notes to .crumbs, and every later run in that directory reads them
back. wc the chapters, grep the diary,
ito log the milestones, pipe anything back through level 1 to
taste the harvest. This
is what
Gradient
Descent for Anything was built for: autonomous refinement that runs until the
model itself says DONE.
So — which level are you? The honest answer is it depends on the task, and the six invariants above are how you tell. Whatever rung you are on, exactly one decision is still yours. Name it, and you know both what you are deciding and where your picture of the work stops being updated.
The cost of climbing is real, and it is not token spend. From the audience level up you are outside the task, and everything you learn about it arrives through instrumentation you specified in advance. It becomes surprisingly hard to spot a flawed conclusion you did not participate in reaching — partly because spotting it depended on the reasoning you skipped, and partly because nothing was watching for it. Efficiency improves; the judgment that would have caught the error quietly atrophies. Worth doing — deliberately, per task, knowing which trade you took.
Which is why the interesting failure of most AI tools is not that they are bad at a level. It is that they remove the others. The shape of the product decides for you before you type anything:
A chat window puts you at collaborator and leaves you there. Inline completion puts you at reviewer. An agent puts you at audience and asks you to trust it. None of them let you move.
So you end up with one tool per rung, none of which share your files, your history or your context. The ladder exists whether or not the products admit it. You are just climbing it by switching applications.
What makes a ladder navigable is not the rungs. It is that you can stop anywhere on
it. Unix has always been interruptible — ^C, kill, a pipe you
can tee, a stream you can grep, an exit code you can branch
on — and that is exactly what lets a task move down a rung when it turns out to matter
and back up when it does not. Autonomy that cannot be interrupted is not a higher rung.
It is a different building.
So toast is one binary whose autonomy stays interruptible at
every level: pipes you can inspect, diffs you can read, exit codes you can gate on, an
allowlist you wrote yourself. Same shell, same files, six rungs.
The question was never how autonomous can it get. It is where do you stay in the control loop. Unix was never about automation either. It was about keeping the person at the right point in the loop, and giving them the tools to move. AI deserves the same discipline.
One account, $20 a month. The installer sets up
appled — Apple Intelligence as your inference provider, on-device and
without an API key.
Levels 5 and 6 done right need the rest of the stack: jam, ito,
toasted, email and imessage bots.