WorldSeed: A Tick-Based Multi-Agent World Engine Driven by YAML and an AI Referee
More is Different. A multi-agent world engine where AI agents live, talk, compete, ally.
At a glance
- What is it?
- WorldSeed is a Python engine that runs declared worlds on a tick loop, resolving certain outcomes through a DSL and uncertain ones through a LiteLLM-backed AI Dungeon Master. The README's four demo scenes show what that architecture buys and where it stays silent.
- Who is it for?
- WorldSeed fits teams who want to author a multi-agent scenario as a YAML world declaration and watch it run on a tick loop, rather than wiring agents together in code. It is a poor fit if you need deterministic, reproducible outputs from every tick, since uncertain outcomes are routed to an LLM referee whose judgement the README does not claim is stable across runs.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 131 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem WorldSeed Targets: Authoring a World Instead of a Workflow
Most multi-agent frameworks ask you to wire agents together in code: define a graph, a router, a set of tool calls, and a termination condition. WorldSeed inverts that. The README's instruction is blunt: "Don't build a workflow. Seed a world." The formula it prints is rules plus different agents plus consequences producing emergence. You declare roles, rules, private information, actions and consequences in a YAML file, then let agents interact until artifacts appear. The intended audience is anyone building a social simulation, a production room, a game, or a fictional scenario where the interesting output is not a single answer but a sequence of events. The README claims the engine is scene-agnostic, and the four demo scenes are the evidence it offers: an autoresearch lab, an AI tool pilot lab, an office layoff drama, and a teahouse espionage story. Same engine, different YAML. That claim is the whole pitch, and it is testable by reading the configs directory rather than trusting the marketing.
The Tick Loop and the Two-Tier Resolution Path
The mechanism the README describes is a tick loop over the declared world. A tick is one beat of the world clock. Each tick, every agent perceives its own filtered slice of state, proposes an action, and the engine resolves it. Resolution is split in two. Predictable outcomes follow the rules you declared and are handled by what the README calls the DSL engine. Uncertain outcomes go to an AI referee, described as an AI Dungeon Master. Effects then apply, the world advances, and the next tick begins. The architecture diagram in docs/assets/arch-diagram.svg shows this as a linear flow: you describe a world, it ticks forward, each agent sees a filtered slice, the DSL engine or the Dungeon Master resolves, state changes, consequences fire. Two design consequences follow. First, agent perception is filtered, so private information is a first-class concept rather than an afterthought. Second, the boundary between certain and uncertain is a configuration decision you make, and it determines how much of your simulation is reproducible. The README does not explain how that boundary is declared, and that omission matters more than any feature list.
What the Demo Scenes Actually Demonstrate
The autoresearch scene is the only one with numbers attached, and they are the project's own reported run, not an independent measurement: a goal of lowering val_loss on a 5M GPT trained on TinyStories, and after 11 hours, 100 hypotheses, 86 experiments, 72 peer-reviewed papers, and val_loss down 24.7 percent. Treat those figures as a claim from the maintainers. The more interesting detail is the described emergent behavior. A data specialist reportedly stopped finding wins in her own lane and began drafting hypotheses in attention design and second-order optimization, while the other two agents stayed in their territory. The README states nothing in the config told her to do that. That is the kind of outcome a tick loop with a referee can produce and a fixed workflow cannot. The other three scenes are described qualitatively: builder agents competing in a tool pilot lab, four coworkers with conflicting incentives in the layoff scenario, and four spies trading secrets in a teahouse. The teahouse scene is the clearest illustration of the YAML claim, since the README presents it as the same engine with a different config and a different world.
Getting It Running: Commands, Prerequisites and the dm Extra
The README lists prerequisites as Python 3.11 or later, Node.js 18 or later, and uv. The sequence is a clone, a uv sync with an extra, a frontend build, an environment file, and a play command. The commands are: git clone https://github.com/AIScientists-Dev/WorldSeed && cd WorldSeed, then uv sync --extra dm, then cd frontend && npm install && npm run build && cd .., then cp .env.example .env, then uv run worldseed play configs/ai_layoffs.yaml. The dashboard is served at http://localhost:8000. The environment file needs an API key for any LiteLLM provider, which the README lists as OpenAI, Anthropic, Ollama and others. The dm extra is not explained in the material; it presumably pulls the Dungeon Master dependencies, but that is an inference from the name, not something the README states. The frontend is TypeScript and Node-based, which is why the build step exists before the Python command runs. The README also points to two runtime guides, one for OpenClaw agents at docs/openclaw/QUICKSTART.md and one for Codex subagents starting at docs/codex/00-core.md and continuing into docs/codex/05-scenario-architecture.md.
The LLM Referee Is the Main Structural Risk
Routing uncertain outcomes to an AI Dungeon Master is what makes open-ended social scenarios possible, and it is also the weakest point in the design. Anything the DSL cannot resolve becomes a model call, which means cost scales with how often your declared rules run out, and latency per tick is bounded by provider response time rather than by your own code. The README says every run is different and that past runs are preserved and replayable, but it does not state that the referee's decisions are reproducible. Those two statements can coexist: you can replay the recorded event stream without the model producing the same judgement again. If your use case requires the same input to yield the same output, this engine is the wrong tool, and a rules-only simulation or a scripted agent pipeline would serve you better. The second limitation is scenario authoring. Everything hinges on one YAML file, and the README shows neither the schema nor a complete example. A reader cannot tell from this material how much of a world is declarative and how much requires Python. Until that is visible, treat the one-YAML-file promise as a claim to verify rather than a settled property.
How This Differs from a Scripted Agent Pipeline
A framework like LangGraph or AutoGen builds a graph of agents and tools and executes it to a stopping condition. Control flow is explicit and the output is whatever the graph produces. WorldSeed keeps control flow implicit in a tick loop and makes the world state, not the call graph, the central object. The practical difference appears when you want to interrupt. WorldSeed's dashboard offers three modes the README names: watch, where you observe all agents including their inner state; intervene, where you whisper privately to any agent; and play, where you step into a character and act alongside the AI. A scripted pipeline has no equivalent surface, because there is no persistent world to step into. The cost of that design is determinism and observability of control flow. You gain a world you can inhabit and a replayable history; you give up the ability to reason about exactly which code path produced a given output. If your task is a bounded pipeline with a clear success criterion, the graph approach is simpler. If your task is studying what happens when agents with private information and conflicting incentives share a space, the tick loop is the right shape.
Maintenance, Licensing and What to Check Before You Commit
WorldSeed is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is the licence text, not legal advice; read LICENSE in the repository for the binding terms. The project is not archived, and the last push recorded is 2026-05-08, so the repository is active. No releases were retrieved, which means there is no tagged version to pin against. You will be tracking the main branch unless you create your own tag, and that is a real operational cost for anyone deploying this in a pipeline. Two dependencies carry their own upgrade weight: the frontend requires Node 18 or later and a build step, and the runtime depends on LiteLLM, so provider API changes propagate into your simulation. The dm extra adds whatever the Dungeon Master path needs, and its contents are not described in the material. Before committing, read configs/ai_layoffs.yaml end to end to see how much of a world is actually expressible in YAML, check docs/ARCHITECTURE.md for the resolution boundary between the DSL and the referee, and confirm whether any LiteLLM version is pinned in the dependency files. If the referee boundary is not configurable, the reproducibility question is settled for you.
Editorial conclusion
WorldSeed fits teams who want to author a multi-agent scenario as a YAML world declaration and watch it run on a tick loop, rather than wiring agents together in code. It is a poor fit if you need deterministic, reproducible outputs from every tick, since uncertain outcomes are routed to an LLM referee whose judgement the README does not claim is stable across runs. Before adopting, verify three things in the repository: the full YAML schema in configs/ai_layoffs.yaml and docs/ARCHITECTURE.md, what the dm extra in uv sync --extra dm actually installs, and whether any pinned LiteLLM provider version appears anywhere in the tree.
Community notes