Turn orchestration
One player message may contain several character rounds before the final narration.
This is an agentic loop rather than a fixed pipeline. The GM chooses which characters need to decide and whether the consequences require another round, while deterministic boundaries limit what can be skipped, repeated or committed. Creative judgement remains with agents; important state transitions pass through explicit tools and validation.
- The game master reads the player's action, current scene, relevant records, pacing cues and rules.
- It activates the characters whose decisions matter now.
- Each character agent receives its stable persona, current situation, own relationships, known entities and recalled memories.
- The GM resolves their intents into outcomes and state changes.
- It may start another round or deliver narration.
- Delivered output records one played turn and schedules background work.
Character output is structured: intent, optional utterance and commitment. A failed high-commitment action may retry once with the first outcome included. Later rounds see earlier rounds from the same turn.
The GM cannot simply narrate a consequential result before resolving the required characters. The engine tells it which operation must happen next, rejects redundant activations of the same situation, and checks that actions occur where the player actually is. These gates reduce contradictions without prescribing the prose.
Why characters run separately
A character agent is shown the character's persona, current situation, relationships, known entities and recalled experience—not the complete world database. Running that decision separately makes perspective a real boundary rather than an instruction buried in one omniscient prompt. A frightened witness can withhold information, a stranger can fail to recognise a place, and two people can interpret the same event differently.
The response is returned to the GM as structured intent. The GM remains responsible for judging what succeeds, applying world rules and composing the player's final view. Character agents do not write directly into the conversation or database.
The GM, character agents, record keeper, world author, chronicler and image author have separate prompts and tool sets. Child agents are one-shot: durable identity and memory come from roleplay state, not a long private chat transcript.
The engine bounds rounds, active characters, tool calls and output tokens. These limits prevent an autonomous scene from running indefinitely while still allowing characters to act without direct player input.
Different limits solve different problems. Character and round limits bound the breadth of a scene; tool-call limits stop a helper from searching indefinitely; output budgets prevent a local model from spending a long generation on prose where a structured answer is required. A reminder or retry can recover an unfinished helper call, but repeated provider failures remain visible in activity rather than being disguised as story events.
Foreground and background work
The delivered turn is foreground work. Recording, suggestions, images, speech preparation, compaction and off-stage decisions may follow according to settings and available providers. They still belong to the same bounded system, and the activity list shows which helper ran, how long it took and whether it failed.
No autonomous loop continues while the chat is idle. Background story actions are considered only when a player message advances the session; leaving a browser tab open does not spend tokens or move the world.
Stable personas and tool declarations precede changing scene data, preserving provider prefix-cache reuse between calls.
For the player, the practical consequence is simple: describe an action, not a desired transcript. The orchestration layer already supplies the scene, rules and relevant perspectives.