The Word Warp Drive

On the bridge the captain never touches the world. The captain says what should happen: "Scan that ship for life signs." The crew run it against the world and report back what happened; the captain decides again. The core is the captain. It only ever emits text.

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

A starship runs on standing orders: the rules of engagement, the mission, the chain of command, written down and posted on the bridge. None of it lives in the captain's head. It's re-read every time it matters. A harness hands the core its orders 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 Deck 1, Section 4.

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

A ship's system is an entry on the console: a name, what it does, what it needs. The captain uses it by giving the order; the crew decide 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 core "calls" it by writing the order: a small structured message naming the tool and its arguments. It has no idea whether the system is real. It writes the order because, given the standing orders and the training, an order of that shape is the likely next thing. The harness reads it, runs real code, and pastes the result back (Section 1).

Take the entry off the console and the system is gone. The core will then do what it always does: write a plausible answer. Try it.

One context window fills up (Deck 1, Section 5), and everything the core reads competes for attention. So a harness can send an away team: a fresh run of the same core with a fresh, empty context, handed one task and only the text it needs. The team works in its own window. Only its final report comes back to the bridge.

Away teams share nothing. They can't see the bridge, and the main loop never sees their working. That's the point: the log file the team read never enters the main window; three lines of report do. Deciding what to delegate, to how many teams, in what order, is orchestration, and the orchestrator is the same core under different orders.

The core is a bettor (Deck 1, Section 6), and now it has hands. So the harness runs safety protocols at every station: rules written in ordinary code that run whether or not the core "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 core, which is exactly why it's reliable. A protocol doesn't get tired at line 400 of a long context. Step through a session with the protocols on, then switch them off.

Everything on this deck lands in one place: the context window. The orders, the systems list, the tool results, the away-team reports, the conversation so far. It's a briefing with a length limit, and the harness's real job, under all the other names, is preparing 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 Deck 2's manifest). Loading on demand keeps a skill's instructions out of the briefing until the task calls for them. Truncation turns a 50,000-line tool result into its first and last hundred. Prepare the briefing.

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

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

• Put invariants in protocols and preferences in the orders. 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, an away team's report: each costs tokens and attention on every pass. Budget the briefing, 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 core 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 orders, the systems list, or the protocols, is a measurement.

That's the ship. One core that guesses the next word; a costume that makes it answer; a crew that gives it hands; standing orders, ship's systems, away teams, safety protocols, and a briefing around it. All of it text and code around the one trick at the top of Deck 1, and, used with that in mind, the most useful crew anyone has assembled around a next-word engine.