World Models Need Memory

Two essays landed this week that caught my attention. Jack Dorsey published From Hierarchy to Intelligence, explaining how Block is reorganising around what he calls a "company world model" — a live representation of the entire business that replaces the information-routing function of middle management. Separately, Rohit Krishnan at Strange Loop Canon argued that the future of work is world models — that once you have hundreds of agents making thousands of decisions, you need an operational simulation of the business to manage by exception rather than by oversight.

Both are right. I think they're describing the same inevitable future from different angles. And I think both are glossing over the hardest part.

The part everyone skips

Jack's world model is built from "recorded actions" — Block is remote-first, so decisions, discussions, code, and plans already exist as machine-readable artifacts. Krishnan's version connects to "the systems a company already runs" and builds a live operational model from there.

Those are the inputs. But inputs aren't knowledge.

When a new analyst joins a large organisation and asks how to reconcile records across two internal systems, they don't read the wiki. They ask the person who's been there fifteen years. That person knows that the same term means different things in different databases, that a particular join silently breaks unless you filter first, and that the documented approach was wrong until someone quietly fixed it three years ago but never told anyone.

That knowledge doesn't live in systems. It lives in people. And when those people leave, it leaves with them.

Both essays assume the world model will somehow acquire this kind of operational knowledge. Neither spends much time on how. I think that's because the "how" is where the real difficulty lives — and it's less fun to write about than the vision.

The gap between access and understanding

I've spent the last eleven months working on this. The thing that surprised me most wasn't the hard engineering problems. It was how little difference "more access" makes.

We ran experiments. Same coding problem, same agent, twenty times. Sometimes it solved the task in eight steps. Sometimes thirty. Sometimes it wandered for half an hour before stumbling into the answer. The variance was enormous. Not because the model was stupid — because it had no memory of how this kind of problem had been solved before. Every run was a fresh start.

Add validated knowledge from previous runs and the variance collapses. Eight to twelve steps, consistently. Half the tokens. Reliable enough that you'd actually trust the output.

There's a more striking result buried in there. Take a cheap, small model — Haiku — and give it access to shared memory. It hits 100% pass rate at $27. Take a frontier model — Sonnet — running bare with no memory. It hits 90% at $215. The small model with memory outperforms the big model without it, at a fraction of the cost.

That's not an incremental improvement. That's a different economics.

The world model essays describe the destination. What they skip is the grinding, iterative process of getting there. That process is corrections — thousands of them — accumulating into something that eventually looks like competence. Without a system to capture and compound those corrections, every agent starts from scratch every time.

Why this isn't just another knowledge base

I can hear the objection already: "We have Confluence. We have data dictionaries. We have README files. How is this different?"

It's a fair question, and I used to think the same thing. Then I read the research.

There's a study showing that static context files — the kind everyone tells you to write for your agents — actually reduce task success rates while increasing costs by about 20%. More context is not better. Dumping documentation into an agent's context window is the equivalent of handing a new hire a thousand-page manual and expecting them to absorb it all before their first meeting.

What works is targeted, validated knowledge delivered at the right moment. Not "here's everything we know about this system" but "here's the one thing that will save you from the mistake you're about to make."

And the validation matters. A wiki page has authority because someone senior wrote it. A piece of operational memory has authority because it's been used successfully forty-seven times and the outcome was correct every time. Those are different trust signals. Agents respond much better to the second kind, and honestly, so do humans.

The multiplayer dimension

This is where it gets genuinely interesting, and where I think there's white space that neither essay addresses.

Jack's piece is about one company. Krishnan talks about scaling across companies — "scale it across companies and you have the training data to build a compelling environment." But neither addresses the mechanics.

Inside a company: how does one team's agent benefit from what another team discovered, without leaking sensitive context across Chinese walls? The compliance team and the engineering team might both need to understand the same data model, but they can't see each other's work. That's not a theoretical concern — it's a regulatory requirement for most enterprises we talk to.

Across companies: if a thousand development teams are all struggling with the same API quirk or the same framework bug, the first team that figures out the workaround could share it without sharing their codebase. That's a network effect. And it's the difference between a tool and a platform.

Yann LeCun's new lab raised over a billion dollars this year for AI with persistent memory and reasoning. GitHub shipped cross-agent memory inside Copilot. Anthropic has team memory feature flags hidden in their latest builds. The frontier labs can see this problem clearly. But they're all building for their own ecosystems — Claude memory for Claude users, Copilot memory for GitHub users.

The real world is heterogeneous. Enterprises use multiple models, multiple tools, multiple vendors. They acquire companies that use different stacks. They merge teams that were built on different platforms. A memory layer that only works inside one vendor's ecosystem misses the point the same way a database that only works with one programming language would.

What I keep coming back to

Both essays describe the destination correctly. Companies will be organised around world models. Agents will do most of the execution. Humans will manage by exception, simulation, and triage.

But a world model that doesn't learn from its own operations is a dashboard with a fancy name.

The part that makes it compound — the part that turns a snapshot into something that actually gets smarter — is the memory layer underneath. Not a static knowledge base. Not a documentation platform. A system that observes what agents actually do, extracts what works and what doesn't, validates it against real outcomes, forgets what's stale, and makes everything it learns available to every agent that needs it.

I don't think this is an optional add-on. I think it's the load-bearing wall.

If the world model is the future of the enterprise, the question is: who builds its memory?