How AI Narrators Work, One Turn at a Time

How AI narrators work is less mysterious than it looks from the reader’s side. On every turn the engine hands a language model three things — a set of standing instructions, a structured record of what the story has established, and the move you just wrote — and the model returns one scene of prose. Nothing carries over on its own: whatever is not put back into the next request is gone.

• A language model holds no memory between requests, so every turn re-sends what the narrator needs to know.
• Anthropic’s documentation states that everything in a request counts toward the context window, the system prompt included.
• Standing instructions set the narrator’s role and voice; the story record supplies the facts it must not contradict.
• Constrained decoding can force the non-prose parts of a turn to match a schema, which is how bookkeeping survives a creative model.
• Fabledrift, an interactive fiction app for Android, hands its narrators the story’s structured memory on every turn, for every reader.

How AI narrators work when you write one move

The loop runs once per move and has four steps. The engine assembles a request out of three blocks of text. The model reads that request and writes one scene. The engine takes the scene apart, updates the record of what is now true, and throws the rest away. Then it waits for you.

Step	What happens	What survives it
Assemble	Instructions, story record and your move are joined into one request	Nothing; the request is rebuilt each turn
Generate	The model writes the next scene and any openings offered with it	The prose you read
Extract	The engine separates the scene from the bookkeeping	Facts, names, places, promises
Commit	The story record is updated for the next turn	The record, which is all the model will see next time

The important part is the asymmetry. The model produces a great deal of text in a turn, and only a small, deliberately chosen part of it becomes permanent. A narrator’s continuity is not a property of the model. It is a property of what the engine decided to write down.

What does an AI narrator actually see?

It sees one long piece of text, organized into parts. The first part is the system prompt: standing instructions that barely change from turn to turn. Anthropic’s prompting guidance notes that “setting a role in the system prompt focuses Claude’s behavior and tone for your use case,” and that XML tags “help Claude parse complex prompts unambiguously” when a prompt mixes instructions, context and variable input.

The second part is the story record — the facts the world has accumulated. The third is your move, usually a single sentence. All three arrive together, and all three cost the same kind of space. Anthropic’s context window documentation is explicit: “Everything in the request counts toward the context window: the system prompt, every message in messages (including tool results, images, and documents), and your tool definitions.”

Why the record is not a transcript

A transcript grows without limit; a record grows only as the world does. After forty scenes a transcript is forty scenes long, while a record might still be a page: who exists, where they are, what was promised, what was broken. That page is cheap enough to send in full on every turn, which is the whole argument for treating story memory as a baseline rather than a tier.

What comes back, and what gets kept?

Two things come back: prose, and bookkeeping. The prose is the scene you read. The bookkeeping is the small structured payload that tells the engine what changed — a new character, a location entered, a promise made. Most engines want that second part to be machine-readable, and a creative model asked to be tidy is not reliably tidy.

That is what constrained decoding is for. Anthropic’s structured outputs documentation describes the failure mode it removes — “parsing errors from invalid JSON syntax,” “missing required fields,” “schema violations requiring error handling and retries” — and the guarantee it puts in their place: responses that are “always valid” and “type safe” because the schema is enforced at generation time.

So a well-built turn is really two outputs with different standards. The prose is judged by whether it reads well. The bookkeeping is judged by whether it parses. Once you see that split, how AI narrators work stops sounding like one act of writing and starts looking like what it is: a creative pass and a clerical pass, running on the same request.

Why do AI narrators contradict themselves?

Almost always because a detail never made it into the record. A name mentioned once in the middle of a paragraph, a door described as locked, a debt implied rather than stated — if the extraction step did not catch it, the next turn has no way to see it. The model is not forgetting. It was never told.

The second cause is volume. More context is not automatically better: Anthropic’s documentation describes how “as token count grows, accuracy and recall degrade, a phenomenon known as context rot,” which makes curating what is in context as important as how much room there is. A narrator handed everything is a narrator handed noise. This is the mechanism behind most of the complaints in the category, and it has a fuller explanation in our piece on why AI story games forget.

There is a third cause worth naming, because it is the one readers can act on. Extraction works from what the prose actually says. A move written as a clear intention gives the engine something to record; a vague move gives it very little.

What an AI narrator cannot do that an author can

It cannot guarantee an ending. Hand-authored branching does: ink, inkle’s “scripting language for writing interactive narrative,” lets a writer lay out every path in advance and test each one. Every reader who reaches a node reads the same words, checked and rewritten until they land. That is a real guarantee, and generated fiction does not have it. Closure has to be arranged instead, which is why how AI stories end is a question about the reader’s last few moves rather than about the engine.

What a narrator has instead is coverage. It can answer a move nobody anticipated, and it can treat an impossible action as a scene rather than an error message. The trade is legible once you see the loop: pre-written prose is exact and finite, generated prose is responsive and unrehearsed. Neither is a better technology; they are different promises to the reader.

Property	Hand-authored branching	AI narrator
Prose quality	Fixed, revised, predictable	Varies with the turn
Coverage of moves	Only the anticipated ones	Any move you can write
Continuity	Guaranteed by the author	Only as good as the record
Endings	Designed and tested	Reached, not planned

What to notice in your next scene

Knowing how AI narrators work changes what the page tells you. Read the openings a narrator offers. They are written after the record is assembled, which makes them a quiet report on what the engine currently believes is true — the people it thinks are present, the threads it thinks are open. When an opening surprises you, that is usually the record showing through the prose.

Both tells are things you can read for deliberately, which is how you judge a narrator quickly; our guide to what makes a good AI narrator turns that into four checks you can run on a single opening scene. The other tell is a callback. When a scene returns to something you did twenty scenes ago, you are seeing an extraction step that worked: a fact caught, written down, and carried forward through every request since. That is all a memory is, in a system like this. Not a model that remembers, but an engine that keeps notes and never stops re-reading them aloud.