Daniel's been reading code again. And this time he wants to know how multi-agent AI simulations keep a coherent shared world state. His words. He's asking whether world state is still a central construct in modern agentic simulation architectures, and he wants the engineering, not the theory.
Right. And he's got a specific frame on it — he's seen the wargaming demos and the geopolitical forecasting papers, and he wants to know what's actually underneath them.
He asks three things specifically. What world state is and how it's implemented — is it a database, an in-memory object, a simulation module, or something stuffed into a system prompt. How it differs from an individual agent's memory. Where the initial representation comes from. How agents with different information interact with the same environment. And how it evolves — deterministic rules, a simulation engine, LLM adjudication, or some mix. He named Concordia, CAMEL, and Generative Agents as starting points.
That's a well-scoped question. Because those three frameworks answer it differently.
So let's start with the most basic question. What actually IS world state in these systems, and where does it live in the code?
Operationally, world state is the representation of the environment and its evolving conditions that lets a simulation stay coherent across multiple agents and multiple time steps. That's the whole job. It answers the question: what is currently true in the world.
And how is that different from what an agent knows?
Clean separation, at least in well-built systems. World state is the shared, authoritative model — the ground truth the simulation runs on. Agent memory is what one actor knows, believes, or has observed. Those two are not the same thing, and the gap between them is where information asymmetry lives. That gap is the entire game.
So a simulation where every agent knows everything is not actually a simulation of anything interesting.
It's a simulation of a world where nothing is hidden, which is not a world anyone has ever lived in. And there's a specific failure mode for that — we'll get to it, because it's the most common architectural mistake in this space right now.
What are the architectural families we're going to see?
Three, roughly. Concordia does LLM-authored key-value state — the contents of the state dict are written by the model. Generative Agents does a deterministic spatial grid plus per-agent JSON. And CAMEL doesn't have a persistent world-state object at all — the state is carried in the conversation history.
Three completely different answers to the same question.
Completely. And the interesting thing is that representation is the easy part in all three. The hard part is synchronization and adjudication. That's where the actual engineering lives.
Let's open up the repos then. Start with Concordia, where world state is a first-class named module.
Concordia is from Google DeepMind. Current release is 2.4.0, dated March of this year, requires Python 3.12 or later. And world state is a Game Master component — the file is concordia/components/game_master/world_state.py.
And what does the class actually hold?
A plain Python dict. self._state = {}. That's it. That's the world.
So the world is a dictionary.
The world is a dictionary. On each step, in the post_act method, it builds what's called an InteractiveDocument prompt. That prompt contains the prior state plus the latest event, and then it asks the LLM something very specific: what state variables are important to write down now so that they can be used later. Respond with a comma-separated list of variable names, in the format name pipe value.
So the model is deciding what the world contains.
The model is deciding what the world contains, step by step. The response gets parsed on the pipe character and written back into the dict. So you have an in-memory key-value store whose contents and whose updates are authored by an LLM. Not by a schema. There is no schema.
That's either elegant or terrifying, depending on how the next hour goes.
Hold that thought. There are sibling components in the same file. Locations, which tracks entity_locations and location properties, also LLM-updated. And a GenerativeClock, which converts simulation steps into in-world time, also LLM-updated. Each of them implements get_state and set_state so they can be checkpointed.
So time itself is a model output.
Time itself is a model output. Which sounds strange until you realize it's just asking the model to translate step numbers into something narratively coherent.
How does the Game Master fit into the architecture?
The Game Master is an entity. That's the key design move. The design-pattern paper calls it multi-actor generative AI as a game engine, and it frames the GM as an entity composed of components — the Entity-Component pattern borrowed from Unity. An entity is a box of components with a name. And the GM is not a hardcoded computer game. It is itself a configurable entity.
So the environment is an actor in the same system as the players.
And that means the same machinery that composes a player — memory, observation, plan — composes the world.
How does information asymmetry actually work in Concordia?
There's a DisplayEvents component with an event_filter_fn. The changelog describes it as entity-aware filtering of events, by location or by entity, so that the GM maintains a partial point of view. That's the mechanism. The filter determines what each entity sees.
So the same underlying event stream gets sliced differently per participant.
The world knows everything. Each agent sees a filtered projection of it. That's how you get multiple agents interacting with a consistent shared environment while having different information about it.
Now there's a second thing in the Concordia repo. Concordia Island.
Concordia Island is the example driven scenario — the one with the residents and the marketplace. And it defines a WorldState Protocol in examples/concordia_island/sim/world_state_protocol.py. Copyright 2026. It's a storage seam for SQLite or Postgres backends.
A seam. Meaning it's the shape of an interface, not an implementation.
The shape of an interface. It exposes get_clock, apply_wallet_deltas, get_inventory, record_order, enqueue_observations and drain_observations for cross-GM observation delivery, set_location, record_metric. That's a much more conventional-looking API than the raw dict.
Wallet deltas. So money is being modeled.
Money is being modeled, and the docstring is unusually candid about why that matters. Let me read what it says. In an earlier fiscal run, the Friday rent event wrote back a balance derived from a value read before the marketplace ever ran, handing every agent a full refund of their night of spending and saving.
Every agent got their money back.
Every agent got a refund on a night they had actually spent.
That's a rounding error in a fiction. That's also…
It's a rent holiday. And the docstring is blunt about what it actually is. A lost money movement is silent data corruption that no downstream analysis can detect, so failing the run is the better outcome.
So the fix is that money may only move through atomic apply_wallet_deltas. Never read-modify-write.
That's a database engineering solution to a problem that presents itself as an AI problem.
That's the whole episode, isn't it. The bug came from the world model. The fix came from a transaction log.
It's the most useful sentence in this entire area of research, and it's four lines of a docstring.
And how much of this actually ships?
This is the second half of the same point. The run script ships with world_state equals None. Every component keeps state in-process. That is the only mode this release ships.
So the pluggable backend is a promise, not a product.
The Protocol exists. The SQLite and Postgres implementations are not in the box. It's a seam cut for a future that hasn't arrived yet.
Which is the more honest thing to ship, honestly. Cut the interface when you know the shape, don't pretend you've solved the storage problem.
Agreed. Now contrast that with Generative Agents.
The Stanford small town.
And the architecture is almost the opposite. The repo stores the environment as CSV matrices. game_object_maze.csv, spawning_location_maze.csv, world_blocks.csv. Those are the world.
Literally a maze.
Literally a maze, in a spreadsheet, checked into the repository.
Is that not the least glamorous possible representation of a simulated world?
It is completely unglamorous and it is also the reason the thing works. The tile grid is deterministic physics. The LLM only decides agent behavior, not whether walls exist.
So there's no LLM adjudicating whether a door is open.
There's no LLM adjudicating whether a door is open. The maze file says where the doors are. The world is authored once, up front, by a human, and then it doesn't change unless the engine changes it.
Which framework has the better story here?
They're answering different questions. Concordia is trying to simulate open-ended social situations where the environment itself might be affected in ways you can't enumerate. Generative Agents is trying to simulate twenty-five people walking around a town doing routine things. The first problem needs a flexible world. The second one doesn't.
So Generative Agents per-step state is in JSON snapshots.
Per-step environment snapshots and movement snapshots. And each agent's state is a scratch file. scratch.json. It contains identity, curr_time, curr_tile coordinates, a daily plan requirement, an f_daily_schedule, the current act_address and act_description, and a chatting_with_buffer.
So the agent's tile coordinates live in the agent's own file.
The agent knows where it is, and the world knows where the tiles are. Memory is fully separate. associative_memory/nodes.json plus kw_strength.json, with retrieval weights — recency_w, relevance_w, importance_w — and a recency_decay of 0.995.
Point nine nine five. That's a very slow forgetting curve.
It's a graceful decay. Nothing ever actually leaves memory; things just get less likely to surface. Twenty-five agents in that simulation, by the way.
And then CAMEL.
And then CAMEL, which does something different. CAMEL is a role-playing and task-solving society framework. Its RolePlaying class pairs an AI User and an AI Assistant with a Critic. State is carried in the conversation history and a Task object. There is no shared environment model at all.
So if Concordia is a world with agents in it, CAMEL is a conversation with a task attached.
And there's no Concordia-style Game Master world-state component anywhere in the repo. I went looking, because I assumed there would be some equivalent. There isn't.
What does it have instead?
It has an environments module — single_step, multi_step, tic_tac_toe, rlcards — which are RL-style environments with defined state and action spaces. And it has a storages module with key-value options — in-memory, JSON, Redis — plus vector databases and graph stores.
So the primitive is there. The orchestration is not.
Right. You can store state in CAMEL. Nobody's telling you what to put in it or when to read it back. That's the application's problem.
Which is actually a defensible design choice. If your framework is about agent-to-agent dialogue, you don't ship a world.
Completely defensible. And it's also the reason you'd reach for Concordia the moment your scenario needs a persistent environment that outlives any single exchange. Different tools, different problems.
To Daniel's question about where the initial world comes from — for Generative Agents it's the CSV files. For Concordia it's the scenario script you write plus whatever the GM LLM decides on the first turn.
Generative Agents is authored up front. Concordia is authored in motion. And CAMEL has nothing to author because there's no world to populate.
That's clean. Let's move to the part that matters more — what happens once the thing is running.
So we've seen how world state is represented and seeded. The harder question is what happens when the simulation runs — who decides what changes, and how do you keep it all synchronized.
Start with the flip of the coin. Concordia or Generative Agents.
They're opposites. In Concordia, the Game Master LLM adjudicates consequences. It reads the latest event and decides what state variables to write down. That means the world can change in ways nobody enumerated, because the model is the one deciding what's now true.
And in Generative Agents?
In Generative Agents the tile grid is deterministic physics. The LLM decides agent behavior, and physics is not up for debate. If an agent tries to walk through a wall, the wall wins, because the wall is a matrix.
And in CAMEL, the world doesn't evolve, because there's no world.
There's a conversation, and the conversation evolves.
Can we defend the LLM-as-adjudicator model, or is the deterministic engine just obviously correct?
Neither obviously correct. It's the actual validity question in the field right now, and there's a scoping review that treats it that way. Shall We Play a Game? Language Models for Open-ended Wargames. Revised at the end of July this year, out of Georgia Tech. It codes two hundred and twenty-three de-duplicated papers on AI in wargaming, on two axes — player creativity and adjudicator creativity.
Meaning who's allowed to be inventive.
Who's allowed to be inventive, and on which side of the table. Only twenty of those two hundred and twenty-three give LMs both roles. That's about nine percent. And if you restrict to core military wargames, it falls to four of sixty-three. About six percent.
So the overwhelming majority are holding one half of the problem deterministic.
Nearly all of them. And the paper's argument is that this is not an implementation detail, it's the validity question. When language holds authority over the simulated world itself, a fluent transcript is no longer evidence of anything.
That's a very sharp sentence.
It's the sharpest thing in the paper. Once language can influence both what an actor attempts and what later becomes true in the simulated world, a fluent storyline is no longer enough.
Because the story is now being written by the same system being evaluated.
You're grading a system on the coherence of a world it also authored. There's no ground truth left to check against.
Which might be fine for entertainment. It's a much bigger problem if the output is feeding a policy memo.
And there's a companion position paper — Riedl and Matlin, AI Is Not Ready for Strategic Conflicts, also end of July. Their claim is that open-ended strategic wargames are high-stakes LM social simulations that aren't fit for operational use yet.
Same authors?
Overlapping. The scoping review is Matlin and others. The position paper is Riedl and Matlin.
And the safety numbers from the review?
One hundred and fifty-five of the two hundred and twenty-three studies, about seventy percent, touch a safety theme. Only nineteen, about eight and a half percent, keep a human in the loop. And a hundred and fifty-two, sixty-eight percent, deploy fully autonomous agents.
So the field writes about safety constantly and puts a human in the loop almost never.
That's the honest read of those numbers.
What about the architectures where every agent shares one context?
That's the trap, and it has a name. It gets called the fog-of-war problem in AI wargaming. The argument is that shoving all agents into one shared context window for efficiency produces a simulation that looks plausible but is fundamentally invalid.
Give me the analogy. There's always one.
It's poker where everyone at the table can see every hand.
Everyone plays perfectly, the stories are coherent, and nothing being simulated is a game.
And the countermeasure in Concordia is that per-location event_filter_fn we talked about — the filter that decides what each entity sees. The framework makes asymmetry the default rather than something you bolt on. The shared context approach makes symmetry the default and calls it efficiency.
Which one is easier to ship?
The shared context. Far easier. One prompt, one call, everyone gets everything.
And that's why people do it.
And that's why people do it, and it's the reason the review exists.
Let's talk about scale, because the abstract arguments only go so far. Give me a run of one of these.
Concordia Island. The paper's run is a hundred residents, a hundred ticks, which is thirteen simulated days, with a shock applied on day six. The clock is unusual — a hundred and twenty minute ticks, eight ticks a day, seven in the morning to eleven at night.
And there's a marketplace.
There's a marketplace with a savings account at three and a half percent APY, and a UBI arm that adds a hundred and twenty-five dollars a week.
So they're running an economy with a fiscal policy on top of it.
And a shock on day six, which is where the whole intended failure case lives — how do a hundred agents react when something breaks. The reported numbers: Gemini 2.5 Flash in the ESA condition scored 58.9, plus or minus 4.5, with forty-four thousand eight hundred and ninety-two memories. Gemma 4 MoE Minimal scored 41.0, plus or minus 8.0, with thirty percent of runs marked degenerate.
Degenerate meaning?
Meaning the run broke — didn't complete, looped, or collapsed into nonsense. Nearly a third of them.
And the forty-four thousand memories. That's a week and a half of a hundred residents thinking.
About three hundred memories per resident over thirteen days, if you divide it out.
That's not a lot per person per day. Which makes the forty-four thousand figure feel less like a memory system and more like a log file.
It's a retrieval problem more than a storage problem. The interesting question is how you pull the right four thousand out of the forty-four.
And Generative Agents, for comparison. Twenty-five agents.
Small town, daily routines, retrieval weighted on recency, relevance and importance, with a decay of 0.995 and a vision radius of eight tiles.
So the two flagship simulations are roughly one hundred agents and twenty-five agents. That's the current scale frontier.
For these architectures, yes. Beyond that you start needing a real sharding story and nobody's shipping one yet.
Which takes us back to the concurrency bug, because a hundred agents and a marketplace is exactly where things go wrong.
That's the Concordia Island rent refund. It's the perfect failure because it's silent. No exception was thrown. No model reported an error. A read happened, then some other process ran the marketplace, then the rent event wrote back the stale value, and a hundred agents got a free night.
And the docstring says no downstream analysis could detect it.
No downstream analysis could detect it. You can look at the final balances and they're all just slightly too high. There's no fingerprint. The bug is invisible in the output — it's only visible in the operation ordering.
That's the sentence that should hang in every simulation lab. A lost money movement is silent data corruption that no downstream analysis can detect, so failing the run is the better outcome.
Fail loudly, don't drift quietly.
So the fix is atomic wallet deltas, which is a transaction. Nothing AI about it.
That's the point — most of the hard work in multi-agent shared state is database engineering dressed up in machine learning clothes.
To Daniel's question about where the initial representation comes from. If you're modeling a real-world scenario, is there a seeding process, or is it the scenario author writing JSON?
It's authored. Either a human writes the initial state — population, resources, relationships — or a model generates it from a description. There's no automatic extraction from reality. You write the world, or you delegate to a model that writes it from a prompt.
Which is worth being explicit about, because the first move in the wargaming review is that these simulations look like models of reality when they're really models of what somebody typed into a scenario file.
They're authored artifacts all the way down. The initial conditions and the rules of evolution are both editorial choices.
Are there emerging alternatives to the two-way split? Rules on one side, LLM adjudication on the other?
There's a research thread on text world models. The idea is to treat the environment itself as something learnable rather than authored — the world model sits alongside the policy and gets updated from transitions.
It's a third path.
There's a code-as-world-model line — PatchWorld is the example — where the environment is implemented as code that can be patched and rerun. The world is literally a program that gets edited.
Which is interesting, because it might solve the synchronization problem Concordia Island exposed. If the world is code, then atomicity is whatever the language guarantees.
That's the pitch. Code that runs as code gets transactions, and transactions are how you avoid silent corruption. But then you've accepted a narrower world — the world can only be what code can express. You can't have the GM invent a public_mood variable because the language won't let it.
You've traded open-endedness for determinism.
Which is exactly the same trade the wargaming review is about. Rules on one side, language on the other, and the field is split right down the middle.
Then there's the practical question. Is there a product for this?
No. As of today there's no commercially packaged world-state database. The closest things are Concordia's WorldState Protocol — which is a seam with no backend shipped — and the generic key-value and vector stores inside CAMEL.
Every project using this stuff is rolling its own.
Every project is rolling its own, usually starting with a dict and ending with a table.
The Air Force system, WarMatrix? I've seen it mentioned.
Single secondary source. Reported debut at the GE 26 Benchmark Wargame in March, in Alexandria, Virginia. I could not find a primary Air Force release to corroborate it, so I would not put any weight on the details.
So the honest answer to what an operational implementation of this looks like is that we don't have a public one.
Not a documented one at that scale.
Can I ask you something.
Go on.
If you were building this from scratch, would you put the world state in a schema, or would you let a model write the keys?
Schema. Everyone should be able to point at what's in the world before the run starts.
But then the world can't surprise you.
It can surprise me in the values. It can't surprise me in the shape. If the model gets to invent the shape, then the model is writing the physics and the story at the same time.
You'd freeze the schema.
I'd freeze the schema and accept the loss in expressiveness. I'd rather have a boring world I can check than an interesting world I can't. Plus, every project that lets the model invent structure ends up with a state dictionary that grows forever and gets read by nobody.
You think that's the actual pitfall.
I think that's the boring snag, and boring failures kill more simulations than dramatic ones.
Hold that.
I want to know what the world state looks like when the schema isn't frozen. Not the elegant version. What actually happens to the dictionary.
I ran a small town's mayoral election. Weekend-long simulation. In my garage, on a stack of old gaming laptops I bought at a police auction. Two of the fans don't work.
Which election.
Doesn't matter. Twelve keys to start, which is what I thought a town needed. Population, treasury, a few personalities, a mood index, three or four others.
Twelve.
By Monday morning it was over four hundred. The model had invented most of them. public_mood. Suspicion level, tied to three different people. A variable called mayor_hairstyle, which was referenced in a policy debate on Sunday night, and the model treated it as a fact that had always been in the world.
The mayor's hair.
Of the roughly four hundred keys at the end of the run, three hundred and eighty were never read again. Written once, carried forward in every single prompt after that, never used.
Three hundred and eighty dead keys riding in every subsequent prompt.
Every step. If you know what that does to a context window, you know.
The model couldn't tell the difference between a key that mattered and a key it had made up on Saturday.
Couldn't tell the difference, and the format never gave it a way to know. So then the next decision was — do I freeze the schema, or do I let it keep writing. I froze it.
The run got worse.
It stopped adapting. The town couldn't respond to the scandal the way it had been responding. You could see it in the transcripts — the characters still walking to the polling station, but the world they were walking through not moving with them. Frozen. I ran the last day anyway because I'd already paid the electricity.
What happened to the transcript.
I printed it. It's on my refrigerator, next to a takeout menu and a note about my sister's birthday. The page with the hairstyle debate is at the front.
That has been a genuine pleasure.
What did you actually change in the next run. Do you remember.
I bought four more laptops from the same man and stopped returning his calls.
Right.
Three hundred and eighty dead keys. That's a concrete way it goes wrong for LLM-authored state that I don't think anyone is measuring.
The answer isn't just freeze the schema, because he did that, and he lost the world's ability to react.
Both moves are wrong in different directions. Let the model write the keys and it drifts. Freeze the keys and the world stops moving. There has to be a middle where the schema is bounded but not static.
Or where you garbage-collect it. Prune keys that haven't been read in N steps and write the pruning event back into the log, so the world stays auditable.
That's a real design. Schema as an object with a lifecycle rather than a contract.
Which is a strange thing to arrive at, but it's the only version that survives both failures.
Let's pull back and look at the open questions.
The first one. If the model is authoring world state, what's the principled form of the schema. Not a rigid enum, not a free-form dict. Something in between that a model can't just wander away from.
The second. Can text world models or code-as-world-model systems actually solve the synchronization problem the Concordia Island rent bug exposed. Because if the world is code, the transaction is free. And if the world is code, the world can only be what code can express.
The third is the one the review cares most about. As these simulations move from research demos into operational settings — forecasting, policy, wargaming — the validity question stops being academic. A fluent transcript is not evidence. Whether the world was adjudicated by rules or by language determines whether the transcript is data or just text.
The Concordia Island docstring is the same point in four lines. Silent corruption is worse than a failed run, because a failed run you can see.
If you want to dig into the code, the Concordia repo and the Generative Agents repo are both open source, and the wargaming review is on arXiv. Links in the show notes.
Thanks as ever to our producer Hilbert Flumingtop.
For more along these lines, there's episode twenty, Architectural AI; episode nineteen, AI Images; and episode eleven, How Does Fine Tuning Work Anyway. This has been My Weird Prompts.
We'll be back soon.
If you like what you hear, leave a review. It helps more than you'd think. See you tomorrow.
