Intelligence Must Remain in Contact with the World

AI systems are getting better at reasoning, at planning, and at using tools. But most of what a system knows about the world was learned during training and then frozen.

When a system needs current knowledge, we ask it to rebuild its picture of the world from search results, documents, and tool calls. This works for simple questions. It breaks down as systems take on longer and more consequential work.

The world does not hold still. Organizations change. Markets move. Scientific understanding develops. Sources disagree. Knowledge that was correct becomes incomplete, and then false.

A system that cannot keep up with those changes reasons from the wrong premises. It rarely fails loudly. It produces work that is fluent, internally consistent, and wrong in a way that is difficult to see from outside.

Contact with the world has to scale alongside intelligence. We are building the layer that does it.

Where the fix has to live

In early 2026 a small law firm published an account of how it used AI for legal work. The post spread. Lawyers began writing their own skill files, and the labs shipped legal skills of their own.

That was a good direction. A skill can hold how a lawyer wants work done: what to flag, how to format a memo, what position to take with a client. That knowledge is stable, and writing it down is exactly right.

Anthropic's own contract review skill also placed a live legal fact into a static file. Among the things it lists to check in a data protection clause is a breach notice deadline, given as a fixed number: 72 hours for GDPR.¹

The number is correct for GDPR. But it sits in a file as a settled value, with nothing telling the system to confirm it still holds and nothing about which jurisdiction the contract in front of it actually falls under.

That second gap is not hypothetical. California's breach notice rule changed. For years the statute set no fixed deadline at all, requiring disclosure in the most expedient time possible and without unreasonable delay. Since January 2026 it sets thirty calendar days.² A file written against the old standard is not slightly out of date. It is wrong about the thing it exists to answer.

The plugin is not careless about this, which is what makes it worth reading closely. It carries a disclaimer, and the disclaimer is specific. It says the plugin does not provide legal advice, that conclusions should always be verified with qualified legal professionals, and that anyone operating under a different legal system must customize the playbook ... before relying on the plugin's analysis. It also names the jurisdictions its defaults reflect: Delaware, New York, and California.¹

So the file names California as a jurisdiction it covers, states a deadline that belongs to the EU, and says nothing about California's deadline at all. What it never says, anywhere, is that anything in it might have expired.

Notice where the burden landed. Every remedy on offer is human: verify with counsel, customize the playbook, have an attorney review the output. Those are honest safeguards against bad advice, and we would not remove them. But they are not a mechanism. They ask each user, independently, to already know the thing the file cannot tell them, which is that the rule moved. Nobody customizes a playbook for a change they have not heard about.

A memo format does not expire. A legal deadline depends on the law, the place, the sector, the contract, and the date. It can change after the file is written, and nothing in the file will say so.

This is easy to read as an authoring mistake, and better authoring would help. But it is worth following what fixing it properly requires. A better skill would tell the system to check the current rule rather than state it. A better harness would fetch the rule at run time. Both fixes move the problem to the same place. Something has to know the current answer, and something has to keep knowing it.

The skill keeps what it was always right to keep. The rest has to be maintained.

What we mean by a World

The phrase world model already means something in this field. It usually describes a learned system that predicts what would happen next. That is not what we mean, and we would rather say so than leave the reader to resolve the word alone.

A world model predicts. A World records.

We use World to mean maintained state about a real domain: a verified account of what is true now, held outside the model and supplied to a system when it needs it.

Training will never be enough

Training compresses experience into weights. That produces broad capability and useful prior knowledge, and it is the right way to learn patterns, abstractions, and procedures.

It is the wrong way to hold facts and the changing state of a particular domain. Updating weights is expensive. More importantly, a weight update does not preserve when a claim was true, where it came from, what contradicts it, or which later update replaced it.

There is no real attribution, no verification mechanism, no proof, and no observability.

Recent experiments on continual factual learning show how sharp the gap is. A model trained to write new facts into its own weights could combine two of them 32 percent of the time. Given the same two facts in the prompt instead, it succeeded 91 percent of the time. Asked simply to state a fact it had been trained on, it produced the correct content 34 percent of the time.

The knowledge was not gone. The route to it was.

We take this as the central finding. Storage and reachability are separate problems, and weights only reliably solve the first. We set out the full evidence in The Model Should Not Be the System of Record.

A larger and more capable model does not remove this. It reasons more convincingly from premises that are no longer true.

What a World holds

Fresh facts are the easiest part to see. A price changed, a rule changed, a source moved. A system needs the current version before it acts. Keeping that current is a maintenance problem.

Tacit knowledge behaves differently. It is what a strong practitioner checks before acting, which exceptions matter, which sources actually carry weight. Much of it was never written down anywhere, which makes it a problem of extraction rather than maintenance. We keep the two apart because they fail differently, and because treating them as one thing has cost this field a great deal of effort.

Private context is a third kind. An organization has its own policies, standards, prior decisions, and ways of working. Those are not part of any shared account of a domain. They belong to the organization, and they stay there.

The fix is orientation, ours is /orient

A system calls orient once, before it acts, and receives the part of the domain this task needs. Not the whole domain, and not a stack of documents to sort through.

For the breach notice clause, a response carries claims like these.

{
  "world": "legal.data_privacy",
  "as_of": "2026-07-26T06:00:00Z",
  "facts": [
    {
      "claim": "EU GDPR Article 33 requires notice to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach.",
      "status": "current",
      "last_checked": "2026-07-25",
      "source": "Regulation (EU) 2016/679, Article 33(1)",
      "caveat": "The clock starts from awareness, not from the breach event."
    },
    {
      "claim": "California requires disclosure within 30 calendar days of discovery or notification of the breach.",
      "status": "current",
      "last_checked": "2026-07-25",
      "source": "California Civil Code Section 1798.82(a)(2)(A)",
      "effective_from": "2026-01-01",
      "supersedes": "No fixed deadline. The former standard was the most expedient time possible and without unreasonable delay.",
      "caveat": "Do not carry the EU 72-hour figure into California analysis, and do not carry the former open-ended standard either.",
      "exceptions": "Delay is permitted for the legitimate needs of law enforcement, or as necessary to determine scope and restore system integrity."
    }
  ],
  "private_overlay": [
    {
      "claim": "House position is to require processor notice within 24 hours.",
      "source": "Internal playbook",
      "visibility": "customer only"
    }
  ]
}

What matters here is the shape rather than the particular claims. The system does not receive prose and infer what is important. It receives current claims, the source behind each one, the date last checked, what the current rule replaced and when it changed, the caveat that prevents a plausible error, and the private position that applies to this organization and no other.

The second claim is the one to look at, and it is the real one. It carries its own history: the rule it replaced, the date the change took effect, and an instruction not to reason from either the EU figure or the standard California used to apply. A claim that knows what it superseded can stop an error. A number in a file cannot, because it does not know it was ever anything else.

That is also why a World has to be able to refuse. A maintained World has edges, so it can return not here and not this way as first-class results. A model working only from its prior has no edges to report.

Maintaining rather than retrieving

Most systems fetch at the moment of need. Every agent then repeats the same work: locating sources, judging which to trust, resolving contradictions, working out what changed, rebuilding enough context to begin.

Retrieval remains important and we are not arguing against it. But retrieval does not preserve the understanding that work produces. It ranks what it found by relevance, not by truth. The next system starts from nothing, pays the same cost, and may resolve the same conflict differently.

A maintained World keeps it. Evidence accumulates. Changes are tracked. Uncertainty stays visible rather than being flattened into confidence. When the domain moves, someone repairs the representation.

We are not claiming that a World always knows the truth. We are claiming something narrower and more useful: that there should be an explicit process, open to inspection, for keeping a system's understanding in line with reality.

This is not a new need, only stronger and now solved

Anyone who has been in this field long enough will hear "maintain a large structured account of the world" and think of Cyc, and of decades of work that never became infrastructure.

Two conditions have changed.

Cyc had to hand-build the facts and the reasoning together. The reasoning now ships in the models, so a World has to hold only facts and state.

And Cyc had no demand. Nothing called it constantly with real work attached, which meant nothing told it where it was wrong. Agents supply that demand, and the work they do supplies evidence about where the World needs updating, or new coverage.

What this is for

Under this design, a system's understanding of a domain becomes something you can inspect rather than something you infer afterward from its answers.

You should not have to wonder what reality your agent assembled before it replied. You should be able to see what it knew. You should be able to see why it believed it, and how recently anyone checked. You should be able to see where the evidence disagreed, and where the World told it not to proceed.

That is the part we are building. Not a system that is never wrong, but one whose picture of the world is legible before the work starts rather than reconstructed from the wreckage after.

The larger thesis

Current AI systems are organized around the model. We bet future systems will have two components of equal standing. The first is models that learn to reason better, some call this the cognitive core. The second is Worlds that stay in contact with what is being reasoned about.

Training made intelligence general. Worlds make it situated.

The question is no longer only how much a model can hold. It is what representation lets intelligence stay in reliable contact with a world that keeps changing. We think the answer is not a continually rewritten model, but a stable reasoner connected to a continually maintained World.

Next

The Model Should Not Be the System of Record is the evidence. It sets out the continual-learning results behind the claim that weights are the wrong system of record, including the addressing failure that makes stored knowledge unreachable.

Introducing Worlds is the product. It describes what we have built, and how you can use it right now, for free, forever.

Sources

1. Anthropic, legal/skills/review-contract/SKILL.md, in anthropics/knowledge-work-plugins, retrieved 2026-07-26. The deadline appears in a checklist of elements to review in a data protection clause. The disclaimer is in legal/README.md, quoted here in full: "This plugin assists with legal workflows but does not provide legal advice. Always verify conclusions with qualified legal professionals. AI-generated analysis should be reviewed by licensed attorneys before being relied upon for legal decisions. The default playbook examples in this plugin reflect U.S. legal positions and jurisdictions (Delaware, New York, California). If you operate under different legal systems (EU, UK, Netherlands, Australia, etc.), you must customize the playbook in .claude/legal.local.md to reflect your jurisdiction's specific legal requirements, standard contract terms, and compliance obligations before relying on the plugin's analysis." Neither file contains any instruction to check whether a cited rule is still current, and neither mentions California's breach notice deadline. We are not arguing this is a bad skill. We are pointing at where a live fact ended up, and at what the available remedy asks of the reader. ↩
2. California Civil Code Section 1798.82, subdivision (a)(2)(A), amended by Stats. 2025, Ch. 319 (SB 446), effective January 1, 2026. Verified against the statute 2026-07-26. The EU requirement is Regulation (EU) 2016/679, Article 33(1); its 72-hour period runs from awareness of the breach, and notification is not required where the breach is unlikely to result in a risk to the rights and freedoms of natural persons. ↩