Earlier this year, Melody Koh wrote about a founder whose whole interview is one request: show me your mech, and teach me something I don't know about how you use AI. A mech is a powered suit that a pilot climbs into: it makes the pilot much stronger, but the pilot still flies it.

I tried to answer the question for my own setup, and I could not. I had skills, memory files, hooks, scheduled jobs and a dozen tools wired into my coding agent, and it looked good in a screen share. But I could not say how it fit together, which parts I trusted, or why. When something went wrong, I could not tell if the fault was the rule, the tool or me.

I didn't have a mech. I had a garage.

This post is the model I built to fix that, and a short test to find where you are.

Robot or mech?

Most AI agent demos I see show a robot: you give it a job, it goes off and does it, and you check the result later. When the result is wrong, you find out after the damage.

A mech works the other way. You are the pilot and the AI is the suit, which still does plenty on its own. The difference is that you decide what it may do alone, one action at a time, and only on evidence.

Trust is a ladder

Autonomy belongs to each action, and the undo decides how much. The same agent can read a database on its own and still need your yes to write to it. A read costs nothing to undo. A write might cost you a weekend.

Two rules keep the ladder honest:

1. Up on evidence, down at once. An action moves up one step after five good runs in a row, and only when you decide. One mistake moves it down a step the same day.
2. Anything that leaves the building stops at "ask me first", until you decide otherwise. An email, a pull request, a message in a shared channel: once sent, you cannot pull them back. You can lift one action above that line, but only with a written decision: the date, the reason, an undo you have tested, and the date you will look at it again. A lift that you do not review expires.

The second rule is the one people want to break first. After a month of drafts you would have sent without changing a word, it is tempting to let the assistant send on its own. A month of good drafts is not, on its own, a reason to lift the send. What it does is make your yes take a second, because there is nothing left to fix.

When I put my own setup on the ladder, I found several actions sitting at "do it, then tell me" with an undo that nobody had ever tested. They felt safe only because nothing had gone wrong yet.

One of them had already caught me out. My agent could update pages in our team wiki on its own, because I assumed the wiki keeps every version. One afternoon I left six comments on a draft report, and the agent's next update rewrote the whole page from its own copy. The comments vanished from the page, and the names I had put on the next tasks were gone for good, because a draft page keeps no history.

Making the yes cheap

The first rule has a cost I underrated. If I have to confirm every run, within a week I click "good" without reading, and the evidence is worth nothing.

So let the grader check every run against the job's test, and look yourself only at what it cannot settle: every run it marks bad or unsure, plus one run in five picked at random. Read the rest in one pass over the run log each week. When a random check finds a bad run that the grader passed, the grader is wrong too, and the action drops a step until its test is fixed.

What you keep is the last word. A part never grades its own runs; if it could, the ladder would climb by itself.

When yes stops meaning yes

The ladder had a failure I did not see coming. Over four days I gave my agent 1,311 approvals. About half of them passed no safety check, and I picked the first option more than nine times out of ten. A question you always answer with yes only adds a delay, and it trains you to stop reading.

So I am building my mech to ask fewer questions, and to make each one count more:

• A score from fixed rules. Before a merge, a script scores the change on blast radius, undo and security, and the lowest row is the score. At 90 or more, with both reviews green, the merge runs and I read the report afterwards. A change to a database migration, the CI or the agent's own rules always gets a low row, so it always stops at my yes. The agent never writes its own score, for the same reason a part never grades its own runs.
• A floor, a cap and a brake. No threshold below 70. At most 20 passes a day for one action. One failure after a pass turns the score path off until I turn it back on.
• One yes for a short series. When I merge five reviewed branches in a row, one yes covers that kind of plan for four hours or 20 actions, whichever ends first. A failure or the stop switch ends it early.

Two smaller rules came out of the same month. The agent may not ask me to approve an output that I have not seen in full: my terminal folds tool output, so "the report is above" does not count. And a yes that gives the mech more freedom must come from a place no agent can type into. A stop can come from anywhere. A lift, a series or a promotion cannot.

What the mech is made of

When I sorted every item of my setup, each one landed in one of five parts. The cockpit is what you see: the chat, the summaries, the list of what ran overnight. The brain is the memory, where each lesson gets a review date so that an old one does not mislead the agent. The nerves are the rules, kept in one place. The muscle is the work: skills, tools, MCP servers and scheduled agents. The chassis is the armor and the hangar: hard limits in code, and a versioned place where the parts come from.

A sentence in the prompt that says "never send" is not armor, because the model can ignore it. A mail connector that can write drafts but has no permission to send is armor, because whatever the prompt says, the email stays a draft until you send it. In a coding agent, the same armor is a hook that refuses a delete. Most setups I see are all muscle: a long list of skills, one memory file, rules in prose and no armor at all.

The nerves are where my own setup stalled. The same rule lived in several files and the copies disagreed, nobody could say who allowed an action, and nothing recorded what worked. Now the main rules file is read-only for the agent and changes only through a review. A new rule I state goes into a small staging file and works at once, but it expires after seven days unless I move it into the main file.

One request, from start to end

Every turn follows the same loop, shown in the figure below: the mech senses, decides, acts and learns.

When the session starts, the hangar loads the rules, skills and tools and stamps their version, and the brain recalls what matches the job and your words. Before each action, a check finds the action's ladder step, reads the stop switch and the budget, then allows the action, asks you or refuses, and writes one audit line either way. The muscle does the work while a second check records what changed. At the end, the grader checks the output against the job's test, and the brain keeps any new lesson with a review date.

In Claude Code, these checks are hooks: SessionStart, UserPromptSubmit, PreToolUse, PostToolUse and Stop.

Example 1: "move Thursday's meeting with the client"

On Tuesday, a client writes to ask if we can move Thursday's meeting. I type: reply to this email, propose a new slot and send the invite.

The assistant already has my mail, my calendar and my rules, and memory adds two things it knows about this client: they prefer mornings, and I never book meetings on Friday afternoon. Reading the email and my calendar is "just do it", so it finds two free mornings without asking me. Writing the reply and the invite as drafts is "do it, then tell me", because I can delete a draft and nobody ever sees it.

Sending is different. An email and an invite leave the building, so the assistant stops at "ask me first" and shows me the exact text, the recipient and the time. It could not send on its own anyway, because the connector has no permission to. I change one word and say yes.

The grader then checks the job's test: the reply answers the question, the invite matches the reply, and the slot does not clash with my calendar. It marks the run good, and the run log gets its line. A week later the client's assistant answers in place of the client, so I add a lesson to memory, copy their assistant on scheduling emails, with a review in three months.

Example 2: "fix the failing test and open a pull request"

On Monday morning I type: the date test fails on main, fix it and open a pull request.

The session already has my rules and skills, version 42. Before the model even reads my request, the prompt hook finds two memory entries that match "test" (run the tests through the task runner, not directly, and the date tests use the Paris time zone) and puts both in the context. The agent reads three files and runs the tests without asking, because reading is "just do it". It edits one file, which git can undo, so it only tells me afterwards, and the tests pass.

A push and a pull request leave the building, so the hook stops at "ask me first" and shows me the exact command, the branch and the diff. I type yes.

The grader runs the job's test: the tests are green, one file changed, and the pull request names the failing test. This is run 3 of 5 for "fix a failing test", and the log gets its line: date, skill and version, link, good. The agent also proposes a lesson, date tests break after a clock change; check the time zone first, which I accept with a review in three months.

If I had changed a rule during the session, the next check before an action would see an old version stamp, and the agent would reload before it went on, or stay at "ask me first" until it did.

Where to start?

Prerequisites

• An AI assistant that you use every day: a chat assistant such as Claude or ChatGPT, or a coding agent such as Claude Code, Cursor or Codex
• At least one set of instructions that it loads by itself: the instructions of a chat project, or an instruction file for a coding agent
• 30 minutes and a text file

The strategy

You do not build a mech in one go. Each stage below asks the same two questions: which actions have you put on the ladder, and what evidence lets them climb? You find your stage, then add the one missing piece that moves you up. You cannot skip a stage.

Step 1: Find your stage. You are at the highest stage where every answer is yes, for that stage and every stage below it.

• 0 · Unseated. Does the AI load any instructions, memory or tools without you pasting them?
• 1 · Seated. Can you list the jobs you give to AI, with the ladder step of each one? Does code enforce at least one "never"?
• 2 · First part. Does one job have the evidence to climb: one skill, with a run log of its last five runs, all good?
• 3 · Trusted. Does one action run at "do it, then tell me", with an undo you have tested? Are your rules in one place, with a review date on every lesson?
• 4 · Drones. Does one job run at "just do it", with no chat open and a spend limit? Can one switch stop every running job?
• 5 · Builder. Does someone else trust a part you built, because of its run log?

When I scored my own setup strictly, I landed at stage 1: lots of parts in daily use, some running alone overnight, and not one written record of five good runs. On paper, my mech had never proved anything.

Step 2: Write down the five jobs you give to AI most often, and next to each one the ladder step you would accept today.

Step 3: Add one hard limit in code, for the action that would hurt most if it went wrong.

Step 4: Turn the job you repeat most into one skill, and start a run log: date, output, good or not. After five good lines, you are at stage 2.

Step 5: Move up one stage at a time.

That's all! Thank you for reading. If you find something wrong or a better way to do it, let me know in the comments below, and tell me your stage and the one part your mech is missing.

Thanks to Melody Koh for the question that started this post. The figures are drawn with an isometric drawing kit; the cover is AI-generated.