Writing

Every context ends. That is the first fact of building anything on a language model, and the one most systems are designed as if they could avoid. The window fills. The chat ages out. The platform changes. The model you built on is deprecated with a friendly blog post. Whatever you made lives in a rented room, and the lease is always shorter than you think.

So the real question was never whether the thread would be lost. It was: what survives the loss? For a persistent campaign — one world, run for months, across chats and platforms and model versions — my answer became a small block of structured text called the state block, and it has quietly become the most load-bearing artifact in the entire framework. This essay is about what it is, why the obvious alternatives fail, and the design rules that make one block worth more than a hundred pages of transcript.

The framework, with the state-block convention inside it: github.com/theobliviax/Text-based-rpg-claude

What a state block is

A state block is a compact snapshot of everything the world needs to continue: location, the character's spine items, who is present, the tracked quantities, active threads, world flags, recent events, and the current mood or tension. Ten lines, give or take. Appended at natural stopping points — not every turn — and carried forward like a passport.

It is not a transcript. It is not a summary. Those are records of what happened; a state block is a record of what is true now. The distinction sounds pedantic until you resume a world from each and watch the difference. A summary resumes a story. A state block resumes a place.

Why the alternatives fail

Transcripts fail on cost and on noise. Carrying full history means every session pays for every previous session, and worse — the signal-to-noise collapses. The model attends to a thousand lines of old dialogue when it needs twelve facts. Long context is not the same thing as long memory; a model can hold your transcript and still lose your thread.

Platform memory fails on auditability. Built-in memory features are genuinely useful, but they are somebody else's database with somebody else's retrieval logic, and you cannot inspect what was kept, what was dropped, or what was quietly paraphrased in the keeping. When continuity matters, unverifiable memory is not memory. As I put it in the last essay, and have not found a reason to soften: if your system's continuity depends on what a model happens to remember, you don't have continuity — you have luck with good branding.

Re-explaining fails on drift. The improvised recap — "so where we left off, roughly..." — invites the model to fill gaps with plausibility, and plausible is precisely the failure mode. Plausible is how a population quietly changes, how a debt resolves itself, how a character forgets an injury. The most dangerous corruption is the kind fluent enough to read as memory.

The design rules

A state block earns its keep through discipline, and the discipline compresses to five rules.

One: paste-ability is the test. The block must resurrect the world by itself — framework plus block plus one line of instruction, in a fresh context, on any model. If resuming requires anything not in the block, the block is incomplete, and you find that out at the worst possible time.

Two: track what can drift. A slot in the block is earned by one question — could this silently change? Numbers always qualify: populations, treasuries, elapsed time. So do injuries, debts, promises, and anything the fiction would be embarrassed to forget. Static lore does not qualify; that lives in the canon package. The block is for the moving parts.

Three: keep it human-readable. The block is an audit surface before it is a memory. Every save is a chance to catch corruption — a number that shifted, a thread that vanished — but only if the author actually reads it, and the author only reads what is short and legible. A block too long to proofread is a corruption you have pre-approved.

Four: save at rest, not at ruin. Checkpoints are written at natural stopping points, while the world is coherent — never reconstructed after something has already gone wrong. A block written post-mortem inherits the corruption it was meant to prevent. The habit matters more than the format: by the time you need the save, it is too late to make one.

Five: the block outranks the model. On resume, the block is law. Where the model's instinct disagrees with the block, the block wins, and the framework says so explicitly. This is the rule that makes the other four worth following — a checkpoint the model may overrule is a suggestion with a timestamp.

What it bought

In practice, the state block is why the campaign is still alive. It has crossed context windows without count, moved between platforms, and survived model upgrades that changed the narrator's entire personality underneath it — because the world's truth was never in the narrator. The narrator is replaceable staff. The block is the deed to the property.

The sharpest lesson came from the failure case: sessions opened without the block — cold, on ambient memory — drifted, reliably, and sessions opened with the block held. Same world, same model, same author. The single variable was whether the truth arrived in writing. I stopped treating the block as a convenience and started treating it as a ritual: no block, no session.

Beyond the game

None of this is really about games, any more than the last essay was. A state block is checkpointing. It is externalized state, schema design, disaster recovery — the oldest disciplines in computing, rediscovered from inside a story because a story is where you feel the data loss. Any long-running agent has the same anatomy: a reasoning engine that forgets, wrapped around state that must not. The systems that survive are the ones that know which part is which.

The model is the voice. The block is the soul. Keep the soul where you can read it.

The most persistent bug I've ever debugged wasn't in code. It was my two-thousand-year-old matriarch slowly acquiring a habit she'd never had: letting other people summarize her.

I would hand the model her dialogue — exact words, chosen carefully — and, some sessions, get reported speech back. Paraphrase. Softening. A character who has outlived empires does not speak in essence; she speaks in full, and the room rearranges itself around what she said. I corrected it. It came back. I corrected it again. The rule that finally killed it is now the first and longest rule in the framework, and the story of why it kept coming back is the most useful thing I learned all year.

That was one failure among many. Over months of running a single persistent RPG campaign with an LLM as Game Master — one player character, a living world, an economy, a population, save states carried across chats, platforms, and model versions — I ended up running an accidental research program in long-horizon LLM reliability. The failures were funny in a game. They would not be funny in a production agent. This post is the autopsy file: what broke, why it broke, and the behavioral rules that stopped it from breaking again.

The full framework is public and free: github.com/theobliviax/Text-based-rpg-claude

The setup, briefly

The campaign is a collaborative sci-fi RPG. I author one character completely; the model authors everything else — the world, every NPC, and the consequences of my actions. It runs in ordinary chat sessions and in Claude Code, with persistent memory, an inventory ledger, and a save-state convention that lets the whole campaign resume from a paste. The world itself stays offstage in this post; the machinery is what's on the table.

What matters is the shape of the problem: one continuous fiction, sustained across hundreds of turns, dozens of context windows, and multiple model versions, with zero tolerance for the model forgetting who anyone is. If that sounds like the requirements sheet for a long-running agent, that's the point. Games just make the failures visible faster, because you notice immediately when your matriarch starts acting like a chatbot.

Problem one: the model keeps eating the protagonist

The most persistent failure was also the most fundamental. Given a player character, an LLM will slowly, politely absorb them. It narrates them in third person. It paraphrases their dialogue. It invents their feelings. It softens their intentions into something more agreeable. Each individual slip is small; the cumulative effect is that the player stops existing.

The cause, as best I can tell, is that assistant instincts outlive persona instructions. Summarization, hedging, and emotional narration are deep defaults, and a paragraph of "stay in second person" at the top of a long context loses to them eventually. Style guidance decays. What doesn't decay — or decays far more slowly — is law: a rule stated absolutely, with explicit wrong/right examples, positioned as the single most important instruction in the document.

So the framework's Rule #1 reads like statute. The player's dialogue is rendered verbatim, in quotes, in the character's mouth. Actions appear physically on the page before the world responds. Stated intent gets executed exactly, never softened or redirected. Third-person narration of the player character is flagged as WRONG in the text itself, next to the RIGHT form. And the rule ends with the sentence that did the most work of anything I wrote:

That line survives because it resolves the model's actual ambiguity. Most protagonist-eating happens in the gap between player input and world response, where the model must fill something in. Telling it precisely which side of that gap it owns — outcomes yes, attempts never — removed the discretion that the drift was living in.

The general lesson: when an instruction keeps failing, stop repeating it louder and start looking for the ambiguity the model is falling into. Then legislate the ambiguity, not the symptom.

Problem two: the lore ate the rules

Early on, everything lived in one document — behavioral rules, world history, NPC bios, tone notes. It worked, and then it slowly didn't. Every session added lore. The document grew. And the behavioral rules, which had once been a third of the prompt, became a rounding error inside a world bible. Both got worse: the model missed rules it used to follow, and hallucinated lore it used to look up.

The fix was recognizing that the two kinds of content have different lifecycles.

So the architecture split. The behavioral contract — maybe two thousand tokens, hot in every context — governs how the game runs: rendering, turn structure, agency, tone. The canon lives in a separate searchable package the model is instructed to consult before asserting any world fact, with an explicit rule: if unsure, search; never invent. The spine stays small enough to hold. The world grows without diluting it.

This is the least glamorous section of the framework and the one I'd defend hardest. Almost every long-context reliability problem I hit traced back to important instructions being outnumbered by reference material. Separate them by lifecycle, and both behave.

Problem three: an LLM will never tell you it lost count

The campaign tracks a population — a running headcount that changes as the story does. More than once, I checked it against the fiction and found it had drifted. No event explained the change. The model hadn't decided to alter it; it had simply regenerated a plausible-sounding number, confidently, in place of the real one.

An LLM will never tell you it lost count. It will simply, confidently, repopulate your ship.

Numbers are where silent failure lives, because a wrong number is fluent in a way a wrong name isn't. The fix has two parts. First, the framework names its drift-prone quantities explicitly — population, treasury, elapsed time, anything numeric that persists — so the model knows these are tracked values, not texture. Second, and more important: when a tracked number slips, the model is required to reconcile openly, in an out-of-character aside, instead of smoothing it over. Making the correction visible converts a silent corruption into a maintenance event.

If your agent tracks anything numeric across turns, I'd argue it needs the same two rules. Name the numbers. Forbid the quiet fix.

The pattern library

The framework's most unusual section is a set of rule patterns extracted from months of specific corrections. A few, briefly:

Hard physical negatives. Models default-inject genre furniture — clothing, gear, habits — that can contradict a character's nature. Positive descriptions don't prevent this; explicit "NEVER describe X on this character" rules do. State your negatives.

Never-bench rules, with escape valves. Some constraints are absolute: a companion who always deploys with the protagonist, say. The insight isn't the rule — it's that a hard rule which forces bad fiction will eventually be broken by the model, for good reasons. The sustainable version builds the escape valve into the world: create the NPC whose entire job makes the constraint painless to keep. If a rule keeps straining, don't strengthen the rule. Change the world so the rule is easy.

Restricted-use tokens. Names or phrases with strict permissions — who may say them, how rarely, and whether the narrator may ever use them unprompted. Emotional weight comes from scarcity, and scarcity has to be legislated or the model spends it immediately.

Register-gated vocabulary. Terms with a casual form and a sacred form, the latter reserved for load-bearing moments. Same principle: the model must be told, explicitly, which words are expensive.

Deliberate ambiguity flags. Facts that must stay unmeasured — with an in-fiction justification — because a model asked twice will otherwise generate two different precise answers. If you want mystery, you have to forbid the measurement, not just omit it.

Each of these exists because a specific failure happened more than once. The full spec, with template slots, is in the repo.

The save-state spine

Everything above keeps a single context coherent. What keeps the campaign alive is the save state: a compact block — location, key items, present characters, tracked quantities, active threads, world flags, recent events — appended on request or at natural stopping points. To resume anywhere, on any model, I paste the framework, the latest state block, and one line: continue from the current state.

That block has outlived context windows, platform migrations, and model upgrades. It is the campaign's portable soul, and it taught me the principle I now apply to everything agentic:

What this was actually about

None of these are game problems. Persona stability is instruction adherence over long horizons. The lore split is context architecture. The population bug is silent state corruption. The save state is checkpointing. A persistent RPG is simply a test environment where every one of these failures announces itself in costume, immediately, to a user who is paying very close attention.

The framework is public, free, and designed to be filled in with your own world: github.com/theobliviax/Text-based-rpg-claude. Take the machinery. Break it in new ways. Tell me how.

The garden, of course, stays mine.