Pick Your Harness and Run It Once

You are not outside the box looking in. On the first run you are the stop condition.

1. Name the four parts of the harness you chose and point at where each one is configured.
2. State which folder or workspace your harness can see, and demonstrate that you set it deliberately.
3. Choose a first task that is reversible, boring, and made of your own material, and say why each of those three matters.
4. Read a run transcript and separate what it decided, what it touched, and what it claimed.
5. Show one place where the summary of a run and the transcript of the same run disagree, or say why you are confident they do not.
6. Hand someone stack/harness.md and have them restart your setup without asking you a question.

stack/harness.md — one page recording what you are running, where each of the four parts is configured, what the harness can see, what the first run actually touched, what surprised you, and how to start it again from cold. Module 02 turns this page into a permissions table.

The most common way to lose a week to this subject is to spend it comparing harnesses. There is always a new one, the demos are short, and the comparison feels like diligence. It is not. It is the part of the work you can do without any of your own material in front of you, which is why it is so appealing.

The practical problem is that what differs between harnesses is not what they can do, it is where the four parts sit and how much friction each carries. You cannot read that off a landing page. You find it by running one badly for twenty minutes on something small, and noticing which of the four you had to hunt for.

The second problem is that the comparison assumes switching is expensive. It is only expensive if nothing is written down. What transfers between harnesses is the shape of the problem: what your task touches, what must never happen, which steps need a human. What does not transfer is a handful of settings and a config file's name. That is an afternoon, and this module exists to make sure the afternoon is all it costs.

So pick on availability and fit, not on merit. Working in a terminal, pick a coding harness you can install today: Claude Code and Codex CLI are both fine starting points. Working in a browser, pick an assistant with a persistent workspace that holds files and connected accounts. None of this module stops being true when one of those is renamed. Choose in ten minutes and spend the rest of the evening running something.

Key insight: the first harness is a teaching instrument, not a commitment. You are running it to find the four parts, and you will find them faster in a tool you already have.

Module 00 named them in the abstract: model, tools, loop, permissions. The exercise now is location. For the next fifteen minutes your job is to answer four questions about the specific thing in front of you, and to answer them by finding the setting rather than by guessing.

Where is the model chosen, and where is that choice recorded? Some harnesses keep it in a config file, some infer it from your account. What matters is whether the choice survives a restart, because a setting that silently resets is a setting you do not control.

What tools does it have right now, before you add any? Every harness ships with a default set and almost nobody reads it. Look for reading files, writing files, running commands, and reaching the network, because those four determine everything in Module 02. If the tools are listed somewhere, read the list. If they are not, ask it what it can do and verify one answer.

What makes it stop? This is the loop, and it is the part with the least visible controls. Something ends the run: a completion condition, a turn limit, a token budget, or you interrupting it. Find out which. A harness whose only stop condition is your patience is a harness you should not leave running.

Where is the approval setting, and what is it set to out of the box? Every harness has some version of a dial that runs from "ask before everything" to "do not ask". Find it before your first run and put it at the cautious end. You are going to move it later, on evidence, and it is much easier to loosen a setting than to un-send an action.

Write the four answers down as you find them. That is half of stack/harness.md, and finding them once is what makes the next harness an afternoon.

Before permissions, before approval modes, before anything you can configure, there is a cruder and more reliable control: what the harness can see at all.

For a terminal harness this is the directory you launched it in, whatever that directory contains, and anything it can reach by walking upward if you let it. Launch it in the parent of six client folders and it can see six clients. Launch it in your home directory and it can see your life. The most common serious mistake in the first week is not a bad prompt, it is being in the wrong folder when you started.

For a browser workspace the same idea wears different clothes. The working directory is the files you attached plus the accounts you connected. A connected mailbox is not a convenience, it is a wall moved: if the workspace can search all of your mail, all of your mail is inside the box.

   launched here ─────▶  ~/clients/          ← everything below is reachable
                            acme/
                            bexley/
                            scratch/         ← what you meant

   launched here ─────▶  ~/clients/scratch/  ← the same run, contained

The safest setting in your whole harness is the one you set before it starts.

The practical rule for today: make a scratch copy of real material and point the harness at the copy. Not a made-up example, because made-up examples are tidy and your material is not, and the value of a first run is discovering that your filenames are inconsistent or that three documents contradict each other. A copy gives you the mess without the risk.

And keep an undo. In a repo that is a commit before you start; in a workspace it is a duplicated folder with version history on. Reversibility is a mechanism you can name, and if you cannot name yours you do not have one.

Three properties, and the temptation is to drop each of them for a different reason.

Reversible means you can put it back with one action you have already tested. Not "I could probably fix it". Tested. This comes first because a first run is the run where you have the least idea what the harness will do, and the gap between what you asked for and what it did is widest before you have learned how this tool hears you.

Boring means you already know what the right answer looks like without going to check. If the task is "summarise this contract I have not read", you cannot grade it, and an ungradable first run teaches you only that the tool produces text. Pick something you can look at and call right in five seconds: renaming files to a convention, extracting a field whose value you know, rewriting a section you wrote last week.

Yours means it comes out of the task you wrote into stack/charter.md, or at least out of the same material. The charter's Allowed list is a shopping list of legitimate first runs, and the point of drawing from it is that everything you learn today applies directly to the thing you are building rather than to a demo you will never run again.

The temptation is to break all three at once: the harness finally works, so you hand it something ambitious on live material late at night. That run will be impressive and will teach you almost nothing, because you cannot tell which parts it got right by understanding and which by luck. Save it for Module 05, where you make it repeatable.

A run produces three different kinds of information and they get collapsed into one impression unless you separate them on purpose.

What it decided. The sequence of choices: it read this file, searched for that string, decided the convention was date-first, then started renaming. Decisions are where you learn how the harness interprets you. If it read six files when one would do, that is context you paid for. If it went straight to the right file, note why, because the reason is usually something you said and can say again.

What it touched. Every file opened, every file written, every command run, every request sent. This is the only one of the three that is a fact about the world rather than a fact about the transcript. In a terminal the file system tells you the truth even when the transcript does not; in a workspace the version history does.

What it claimed. The report at the end. "I updated the three files and left the fourth alone because it was already correct." This is generated text. It is often accurate and it is never evidence.

   decided ──▶ how it reads you        (transcript)
   touched ──▶ what changed            (file system / version history)
   claimed ──▶ what it says it did     (generated at the end)

               you ✋ compare touched against claimed

Two of these come from the same source. Only one comes from the world.

The discipline takes a minute: before you accept the run, check the touched column against the claimed column. Did it modify anything it did not mention? Did it mention anything it did not modify? On a first run these usually agree. The habit matters more than today's answer, because the run where they disagree is the run where you would otherwise have believed the summary.

There is a structural reason not to trust the closing summary of a run, and it is not cynicism about models. The summary is produced by the same process that produced the actions, from the same context, including its own earlier statements about what it was going to do. If the run went sideways at step four and the model did not notice, the summary is written by something that still believes step four went fine. It is reporting the run it thinks it had. This is the failure profile Module 00 named for agents: they fail quietly, and the account of the run comes from inside the run.

So keep the transcript. Some harnesses write a session log, some let you export a conversation, some make you copy the window into a file. The durable habit is that after a run that mattered, the full step-by-step exists somewhere outside the tool. It is what you read when the result is wrong and you need to find where it turned, what you compare when the same task works on Monday and fails on Tuesday, and the raw material for Module 05, where your best runs become repeatable moves.

Warning: the transcript is also the least private thing you will produce this week. It contains whatever it read, including anything in the files you pointed it at. Keep it where you would keep the material itself, not in a shared notes app.

Everything you have just learned about your harness will be gone in a fortnight. Not the concepts, the specifics: which flag, which folder, which setting resets on restart. This is why the module ends in a file rather than in a working setup. stack/harness.md has six headings, and each one exists for a different future moment.

What I am running answers the question asked when something breaks and someone wants to know what this is. Name the harness and the shape of the setup, not a version number: the arrangement is the useful part.

The four parts and where each is set is the section that makes a future switch cheap. One line each: model, tools, loop, permissions, and the place you found it.

What it can see is the working directory, or the attached files and connected accounts, written as a specific list. Module 02 turns this section into rows in a table, which is easier than starting again from the tool.

The first run records the task in one sentence and what it touched, taken from the file system rather than from the summary.

What surprised me is the most valuable heading and the one most likely to be skipped. Write it while the run is fresh: the thing that took three tries, the setting that was not where you expected, the permission request you did not know was coming. Module 03 builds AGENTS.md out of this section.

How to start it again is four or five lines that get you from a closed laptop to a running harness pointed at the right place. Test it by following your own instructions once, from cold.

Someone installs a coding harness, and because the install finished in the folder they happened to be standing in, that is where they launch it. The folder is one level above both a scratch copy and the live client directory it was copied from. They ask for something harmless: make the filenames consistent, date first, lowercase, hyphens instead of spaces. It does exactly that, in both trees, and reports that it renamed the files. A week later the client asks why a link in a shared document no longer resolves, and the answer is a rename nobody remembers approving, in a directory nobody meant to expose.

The task was reversible in the scratch copy and not in the live one. The harness did not misunderstand anything. The only mistake was made before the first message was typed, by not deciding what the thing could see.

• ## The four parts and where each is set has four lines and each one names a location, not a description. "Approvals: config file, permissions block" passes. "Approvals: configurable" fails.
• ## What it can see is a list of specific places. A reader could point at each one without asking you what you meant.
• ## The first run says what changed according to the file system or the version history, and that list is not simply a copy of the run's own summary.
• ## What surprised me has at least two entries, and at least one of them is about the tool rather than about the material.
• You followed ## How to start it again from a cold start and did not have to add a step while doing it.

Do not run a harness against material that has no undo, and do not spend today making one reversible so you can hurry. If your real material lives somewhere with no version history and no copy — a live scheduling system, a shared inbox, an accounting ledger — then today's job is to make a scratch copy of a slice of it, and if even that is not possible, work on the exported data instead and come back when the undo exists. A first run on unrecoverable material is not a bold start, it is a bet placed before you know the odds.