One multiverse of story entities, written, played and branched with agents.
Raon:Verse is the successor to Novel Buds: a platform where novels, visual novels and chats are built on the same story entities inside one Multiverse, every LLM actor is an agent, and a timeline-based world model gives those agents the state of the world at any moment, in any branch.
Starting over from what Novel Buds taught
Novel Buds proved that an agent can work inside a story project. Building it also showed where its structure stops scaling: a project held exactly one novel and one timeline, agent edits could not be traced or cleanly undone, two separate runtimes split the agents, and retrieval treated the story as text chunks sitting beside the timeline rather than inside it.
Raon:Verse starts over from those lessons. Novels, visual novels and chats share the same story entities inside one Multiverse, every LLM actor is an agent, and the timeline itself becomes the structure the agent reads the world through.
One novel per project → one shared Multiverse
A Novel Buds project owned one outline, one manuscript and one timeline. In Raon:Verse the project is a Multiverse of shared story entities, and any number of novels, visual novels and chats are built on top of it, each in whichever Verse it needs.
Two runtimes → one agent model
Structured Journeys and free-form Agents were separate systems with a fixed list of Journey kinds. Now every LLM actor, from the writing assistant to a character in a chat, runs on the same loop, the same tools and the same approval rules.
Untraceable edits → every write is a Mutation
Rolling back an agent edit meant restoring a whole object, and deletes were permanent. Now every tool call records a Mutation with inverse effects, so any change can be undone, any object restored to a past revision, and deletes go to a trash.
All-or-nothing approval → per-call consent
Pending tool calls were approved or rejected together behind one user-wide auto switch. Now each call is approved against a fingerprint of its exact plan, with ask or auto per conversation, and per-field version checks stop the agent from overwriting what the author just typed.
In-process runs → durable workers
Runs lived inside the API process with an in-memory event bus. Now they execute in a worker, jobs are queued in the same transaction as the change that caused them, and the event stream replays from wherever a client left off.
Text chunks beside a timeline → a timeline the agent reads through
Retrieval embedded story text while the timeline sat apart as its own feature. Now time, Verse, knowledge and importance are first-class structure, and search joins them in at query time.
Built to be worked on with an agent
Raon:Verse is designed on one premise: the author works together with an agent, rather than calling on one now and then. The agent is always on hand in a drawer that opens from every screen, it sees what the author is looking at, and almost everything in the app is within its reach: entities, timelines, manuscripts, plays, modules and settings.
That reach comes from the architecture, not from a list of special tools. UI edits and agent tool calls run through the same Mutation executor and the same verbs, so the agent can do what the author can, and every change it makes lands in the same History, reviewable and undoable. The writing assistant, the translator, a character speaking in a chat and the subagents they spawn all run on this one hierarchy (thread, Journey, Run, Step, ToolCall).
One drawer, on every screen
The agent lives in a global drawer that opens with the same button on the home screen and inside any project. Each message carries the screen, object and selection the author is looking at, and @ hands it any object, so “tighten this scene” or “put her on the timeline” needs no setup.
Anything the author can do
Agents work through one fixed set of verbs (read, create, copy, update, patch, move, delete, restore, undo) across every object type, on the same path the UI uses. Revertibility, soft delete and permissions are enforced by the engine, so a new feature is reachable by the agent the day it exists.
Working side by side
The author and the agent can edit at the same time. Per-field version checks stop the agent from overwriting what the author just typed, and when the author changes something the agent has read, the agent is told what changed before its next step and re-reads it before writing.
Standard and Pro strategies
One per-thread switch shared by every agent type. In Pro the lead agent dispatches independent subagents in parallel, has them check each other adversarially, and synthesises by evidence rather than consensus, without changing the tools, approvals or limits.
Subagents that can only narrow
A child inherits its parent’s tool catalog and can only remove from it through its preset’s access and spawn settings, so a read-only child’s child can never gain write access. Subagents run in the background and report back as messages, not tool results.
Undo as the safety net
Because every tool call is one Mutation with inverse effects, letting the agent act on its own is safe: the safety net is undo, not approval. Ask mode approves each call against its exact plan; Auto mode applies at once, and undo first checks that the change still holds.
Errors written for the agent
Every result is an ok / error envelope whose hint addresses the model, not the user. Schema errors return the type’s reference so the agent can correct itself, and a stale write comes back as a version conflict that names what to re-read.
Scoped memory
Agent memory lives at user, Multiverse, Verse and thread scope as versioned, undoable objects; thread scope is the scratchpad a lead agent shares with its subagents. Facts about the story stay out of memory and in the world model.
Runs that can wait
Every tool call is persisted and moves through an explicit lifecycle. While a call waits for approval or background work the run parks, and an external completion schedules it again, so an approval can arrive minutes later or after a restart.
- Streaming
- Queued
- Pending
- Running
- Done
The world as a structure, not a pile of chunks
Stories in Raon:Verse branch constantly: alternate worlds, time travel, a different choice in a visual novel. A plain index over story text cannot tell which version of a character a paragraph describes, which world it belongs to, or whether the character speaking should know it.
So the timeline is the backbone. The world, every entity and every story each live on a line, every record carries a coordinate on it, and the agent reads the world at a coordinate instead of searching loose text.
A lighthouse keeper goes back to save her drowned brother, twice, and a smuggler follows her six years forward. Every world it splits, every life and every story is drawn below in world time. Pick a line to lay it flat in its own time.
31 lines: 6 worldlines, 22 lifelines and 3 storylines. Hover to trace one, click to lay it flat.
A multiverse is many worlds whose lines keep crossing. Before the play writes its next node, Raon:Verse does not hand that tangle to one agent: it sorts the lines by Verse and by entity, lays each line that matters flat in its own time, and gives every agent a single line to focus on, its own entity in its own Verse.
This is the multiverse as it is stored: 6 Verses, 22 lifelines and 3 storylines, crossing wherever someone travels in time or a world splits. Read whole, it is where continuity breaks.
Branch a world without copying it
Each Verse is a branch of the world’s timeline. It shares everything before the moment it split as the very same records, and characters appear in it through their own lifelines rather than as copies. When a character lives differently there, only their life after the split is stored separately. Six worlds hold one shared past, and fixing that past fixes it everywhere.
Snapshots: who they were then
A snapshot is a character’s profile at one moment of their life: looks, outfits, relationships, secrets. For any scene the agent gets the latest snapshot from before it, so it meets the character as they were then, not as they end up.
Who knows what, and since when
A secret belongs to a character, and each snapshot can word it differently. Knowledge entries on a lifeline mark from which moment a character knows something, so an agent playing that character only knows what the character knows in that scene.
Links that resolve in time
Links tie records together: a scene to the people in it, an event to the person behind it, a father to his son, optionally hidden behind a secret. A link to a person always points to who they were at that moment, in that world.
Custom calendars
Every Multiverse can define its own calendar: its own months, eras that count backwards, leap years and weekdays. Change the calendar and every date in the world is recalculated and checked in one step, or nothing changes at all.
Play writes back as history
What happens during play is saved as events on the timeline, each linked to the scene that caused it, and never written into the shared character profile. One chat can change where a character’s story goes without rewriting them for every other story.
One coordinate system
“Now” is a single position: the story’s Verse and world time. Tools default to it, ambiguous positions are refused with the candidates listed, and calendar or overlap violations come back as structured errors the agent can fix.
State is computed, not summarised
For each character on stage the agent gets the selected snapshot and the events overlapping that moment, instead of a summary blob or a paragraph describing an outdated version.
Branching costs nothing
Visibility, knowledge and importance are joined at query time and never copied into chunks, so branching, jumping or revealing a secret needs no re-embedding. Chunks follow Markdown blocks, and only changed chunks are re-embedded.
Questions vectors cannot answer
Time-range filters, timeline and story-stream sources and one-hop Link expansion let the agent ask temporal and relational questions alongside semantic, CJK-aware keyword and hybrid ranking.
One world, three ways to play
A messenger where the model plays everyone else
The model plays every character except the user’s persona, each reaction a separate call: messages, read receipts that tell left-on-read from ignored, and stickers chosen by meaning. Scheduled messages go stale instead of firing out of context when the user speaks first.
Staged scenes with choices that fork
Each shot sets the speaker, location, sprite emotion and outfit, time of day and weather, or replaces the stage with a generated CG. Choices take an option or a free-written path, and choosing differently at an answered choice opens a new branch.
A co-writing editor
The play view is the outline and manuscript editor itself. The agent writes into the chapter on screen with writing framing instead of simulator framing, applying changes directly with undo as the safety net.
Direct or Agent
A play session runs either as one structured completion turned into tool calls, or as a full tool loop with Standard / Pro and a character subagent that speaks and judges as a specific entity, on the same tools and context.
Branch from here
Any node can start a branch storyline that shares everything before it as the same records, so an upstream edit reaches every branch, and splits off its own branch Verse at that world time.
Play variables from history
Variables are never stored as current state. They are recomputed from the assignments recorded on nodes, so branching, going back or viewing the past always shows the values from that moment.
Assets by meaning
The model asks for sprites, backgrounds and stickers by meaning. The server resolves an exact match, then the nearest vector, then a default, pins the result to the shot, and counts misses so authors know what to draw next.
Prompts and play experiences as attachable modules
Everything authored on top of the engine lives in a Module: the prompts agents run on, the Skills they can load, the state and custom nodes a play uses, and the panels and code that render them.
Modules attach to the user, a Multiverse or a single Play, so one world can run as an RPG with levels and dice rolls while another stays a quiet romance, without touching the engine.
A sparse prompt cascade
Every prompt is a render target such as system:play:chat. The most specific attached module that defines a target wins and the base module defines all of them, so a module overrides exactly what it needs. Prompts grow as append-only blocks, so provider prefix caches survive.
Engine selects, template serialises
Templates are sandboxed Jinja2: the engine chooses what data goes in, and the template only decides how it reads. Each template’s syntax tree is analysed to fetch just the data it uses, authors place their own cache breakpoints, and overrides sit behind an unlock that doubles as an escape hatch.
Skills
Skills follow the Agent Skills format, supporting files included: an index in the system prompt, the full text on demand, and the same Skill usable as a slash command, with each exposure set per context.
Play extensions
State variables, Chat and VN node types and panels extend play. The model places a typed custom card, the user interacts with it, and the result feeds the next turn; rolling again can open a new branch.
Sandboxed surfaces and tools
Module UI runs in an opaque-origin iframe and worker, rendered through Remote DOM and talking to the host only over a consent-granted capability bridge. Python tools run in a server-side WASM sandbox with no access to the database or keys.
Versions you can branch
Branching a version copies a Module, so one world can get its own customisation. Archives carry the modules a world uses, and turning a module on always shows its content for consent, asked again whenever that content changes.
What it’s built on
- Backend
- Python 3.14FastAPISQLAlchemy 2 (async)AlembicPydantic v2ProcrastinateJinja2 (sandboxed)Marktip
- Data & search
- PostgreSQL 18pgvectorPGroongaValkey
- AI / LLM
- OpenAIAnthropicGoogle GenAIxAIOpenRouterOllamaadapter / dialect layer
- Frontend
- React 19TypeScript 6Vite 8TanStack Router + QueryTiptap 3Base UIMotionRemote DOM
- Quality
- pyrightruffimport-linterpytestVitestPlaywrightGitHub Actions
- Infra
- Docker ComposeAPI + worker split
Designed and built solo, from the product plan and data contracts to the agent runtime, backend and frontend. Raon:Verse is still in active development.