The Word Machine

At a game table the player never touches the world. They say what they'd do: "I check the door for traps." The dungeon master resolves it against the world and narrates what happened; the player decides again. The machine is the player. It only ever emits text.

A harness is the dungeon master: a plain program that reads the machine's output, notices when it's a request to do something, does it, pastes the result into the context, and runs the machine again. Repeat until the machine writes a final answer instead of a request. That loop, with the machine inside it, is what agent means. Step through one.

A character is a sheet of paper: class, stats, equipment, a few lines of backstory. None of it lives in the player's head. It's re-read every time it matters. A harness hands the machine a sheet the same way: a role, house rules, facts about the project, an example of good output, the format to answer in. That's a system prompt, a rules file, a persona. All text, placed in the context every pass, enforced by nothing but the attention look-backs from Floor 1, Room 4.

The whole trade is visible on the sheet. Every line makes the wanted next word likelier, and every line costs tokens and attention. Build one and watch the answer change; then add the forty-page style guide and watch it drift.

A spell is an entry in a book: a name, what it does, what it needs. The player casts by speaking the incantation; the dungeon master decides what happens. A tool works exactly this way. The harness writes each tool's entry (name, description, the shape of its arguments) into the context as text. The machine "casts" by writing the incantation: a small structured message naming the tool and its arguments. It has no idea whether the spell is real. It writes the incantation because, given the sheet and the training, an incantation of that shape is the likely next thing. The harness reads it, runs real code, and pastes the result back (Room 1).

Take the entry out of the book and the spell is gone. The machine will then do what it always does: write a plausible answer. Try it.

One context window fills up (Floor 1, Room 5), and everything the machine reads competes for attention. So a harness can summon a familiar: a fresh run of the same machine with a fresh, empty context, handed one task and only the text it needs. The familiar works in its own window. Only its final report comes back to the summoner.

Familiars share nothing. They can't see the main conversation, and the main loop never sees their working. That's the point: the log file the familiar read never enters the main window; three lines of summary do. Deciding what to delegate, to how many familiars, in what order, is orchestration, and the orchestrator is the same machine wearing a different sheet.

The machine is a bettor (Floor 1, Room 6), and now it has hands. So the harness carves wards at the doors: rules written in ordinary code that run whether or not the machine "remembers" them. Before a tool runs: is this command on the allowlist? Does deleting a directory need a human's yes? After a tool runs: run the formatter, run the tests, paste the failures back so the next turn sees them. Before the harness ships at all: run it against a fixed set of tasks with known answers and grade it. Those are evals.

None of this lives inside the machine, which is exactly why it's reliable. A ward doesn't get tired at line 400 of a long context. Step through a session with the wards up, then drop them.

Everything on this floor lands in one place: the context window. The sheet, the spellbook, the tool results, the familiars' reports, the conversation so far. It's a backpack with a weight limit, and the harness's real job, under all the other names, is packing it: what goes in this turn, what gets summarized, what gets thrown out, what gets fetched only when needed.

The moves have names. Compaction replaces old turns with a summary. Memory files are notes written to disk and re-read next session. Retrieval fetches the few documents that matter (RAG, from Floor 2's inventory). Loading on demand keeps a skill's instructions out of the pack until the task calls for them. Truncation turns a 50,000-line tool result into its first and last hundred. Pack the bag.

The words of current AI development, each with its exact address on this floor:

Four rules fall straight out of these six rooms, and they are the rules people building with these tools keep re-learning:

• Put invariants in wards and preferences on the sheet. If a thing must be true every time, code enforces it. If it should usually be true, text suggests it. Confusing the two is how a "never push to main" rule ends up as a prompt that got outvoted at line 400.
• Every addition is context. A tool, a rule, a file, a familiar's report: each costs tokens and attention on every pass. Budget the pack, not just the prose. The best harnesses are the ones that read less.
• You are engineering the loop, not the model. The knobs are frozen. What you control is what the machine reads, what it may do, and what comes back. That's the whole surface, and it's a lot.
• Judge a harness by its evals, not its demos. One good session is a bet paying off. A graded set of tasks, re-run after every change to the sheet, the spellbook, or the wards, is a measurement.

That's the dungeon. One monster that guesses the next word; a costume that makes it answer; a loop that gives it hands; a sheet, a spellbook, familiars, wards, and a backpack around it. All of it text and code around the one trick at the top of Floor 1, and, used with that in mind, the most useful scaffolding anyone has built around a word machine.