In an earlier essay, I argued that RDF reification, the ability to treat assertions as first-class entities, breaks the “SQL mind” because it demands a different stance toward what counts as real. That piece was deliberately abstract. This one is concrete.
Here I want to describe an architectural pattern that emerged from taking reification seriously as a design primitive: the split between fast memory and slow memory. It is the backbone of Pharos Fabric, and I believe some version of it is inevitable for any system where autonomous agents build shared knowledge.
You already have two memories
Cognitive science distinguishes working memory from long-term memory, and the architectural implications run deeper than the labels suggest.
Working memory is small, volatile, and cheap to revise. You hold a phone number in it while you dial, or draft a paragraph knowing you’ll rewrite it. The operating assumption is mutability: everything here is provisional, and the cost of being wrong is near zero.
Long-term memory is consolidated, durable, and expensive to revise. When something moves into it, it is transformed. Neuroscience calls this consolidation, a process of restructuring, pruning, and integrating new information with what is already known. Consolidation isn’t just storage. It’s validation. The brain doesn’t write raw experience to long-term memory; it writes a processed, contextually integrated version.
Now consider most software systems. They have one tier: the database. Everything written there is, by default, canonical. There is no architectural distinction between “I’m exploring an idea” and “this is an audited fact.” The staging area is application code, which evaporates when the request completes, and everything that survives carries the same ontological weight.
That works when all your writers are humans working through curated forms with validation rules. It falls apart the moment you introduce agents.
Why agents need two memories
An autonomous agent (not a chatbot wrapping an API, but an agent with goals, capabilities, and the authority to act) does something databases weren’t designed for: it speculates.
An agent exploring a design space needs to create provisional structures, test relationships, branch hypotheses, and discard dead ends. It needs to do this at interactive speed, without consensus, without validation ceremonies, and without the overhead of immutability. It needs a scratchpad with the full expressive power of a knowledge graph.
The system also needs a place where validated, attested, auditable knowledge lives: where facts have provenance, assertions are signed by identifiable principals, and the history of what was claimed, by whom, and on what evidence is preserved and queryable.
These are different operational regimes, and forcing them into one store means ugly compromises. Either the canonical store fills with speculative garbage, or the exploration space carries validation overhead that kills interactivity.
The answer, which we reached through pain rather than theory, is two tiers.
Fast memory and slow memory
We call them fast memory and slow memory. The names are deliberately informal, because the distinction isn’t about speed in the hardware sense. It’s about epistemological weight.
Fast memory is a mutable graph where agents build constructs: typed, composable working knowledge. Constructs are provisional. They can be created, modified, connected, branched, and destroyed without ceremony. There is no signing, no consensus, no immutability. Fast memory is where thinking happens.
Slow memory is an immutable ledger, native to RDF, with SHACL validation and a cryptographic commit chain, where canonical knowledge lives. Every fact in slow memory was explicitly promoted from fast memory. It carries provenance, a signature from an identifiable principal, and conformance to declared shapes. Slow memory is where knowing happens.
The boundary between them is what matters. The architecture page charts it in one view.
Promotion
Knowledge doesn’t drift from fast memory to slow memory. It is promoted, and promotion is a deliberate, auditable act.
When an agent or a human decides that a construct is ready to become canonical, it asks the fabric to promote it. The construct has to pass three gates.
Shape. The construct is checked against SHACL shapes: declarative constraints that say what a valid entity of this type looks like. Think of schema validation, but for graphs, and expressed in the same language as the data. A Character must have a name, must reference at least one narrative arc, must not violate continuity constraints. The shapes are themselves knowledge in the graph; they can be versioned, reasoned about, and extended.
Capability. The principal asking for promotion must actually hold the authority to assert this kind of fact in this scope. Being able to write in fast memory grants nothing in slow memory.
Signature. The validated construct is wrapped in an envelope that records the content, who is promoting it, when, the shapes it conformed to, and any attestations from other principals who reviewed it. The promoting principal signs that envelope. The signature is not decorative. It is how the system can later answer: who asserted this, and can we verify they had the authority to do so?
Only then is the envelope committed to the ledger. From that point it is canonical. It can be superseded by later assertions, but it can never be silently modified, and the commit chain preserves the full history.
This is reification made architectural. The construct, which was operational state in fast memory, something you worked in, becomes a reified entity in slow memory, something you can make claims about. The envelope is the reification. It takes what was implicit (who said this, when, under what authority, validated against what constraints) and makes it explicit, queryable, and verifiable.
What this looks like in practice
Take a scenario from creative production, though the pattern generalizes.
A worldbuilding agent is developing a faction for an online game. In fast memory it creates a cluster of constructs: the faction, its political relationships with three other factions, a set of key characters, territorial claims on a region map, and an economic model. It revises them dozens of times, branches an alternative in which the faction is allied with a different power, and discards that branch. It pulls in constraints from a narrative bible that another agent promoted to slow memory last week.
None of this touches the canonical ledger. The agent can query its own working state, join it with canonical knowledge from slow memory, and iterate freely.
When the agent and a human creative director agree the faction is ready, they promote it. It is validated against the faction shape, wrapped in an envelope signed by both the agent and the human, and committed.
Now other agents can build on the canonical faction: a quest-design agent writes arcs that reference it, a game-systems agent balances its economy against the others. And if anyone asks where this faction came from, the answer is in the envelope: these two principals attested to it, at this time, against these shapes.
If a continuity error turns up later, the faction isn’t deleted. A new assertion supersedes it, with its own envelope explaining the correction. The history stays intact, and you can always reconstruct what was believed, by whom, at any point in time.
Why not just use Git?
Engineers ask this most often, and it’s a fair question. Git gives you immutability, history, branching, and cryptographic integrity. Why build a second system? Three reasons.
Granularity. Git operates on files. We need to operate on individual assertions within a graph. “Character X is allied with Faction Y” needs its own provenance, independent of every other fact in the same file. Git can’t give you that without encoding a graph database inside flat files, at which point you’ve reinvented the thing you were trying to avoid.
Queryability. You can’t SPARQL a Git repo. The point of slow memory is that canonical knowledge is queryable as a graph, with joins, path traversals, shape conformance checks, and federated queries across ledgers. Git gives you snapshots. We need a live, queryable knowledge surface.
Semantic validation. Git hooks can run linters. SHACL shapes express domain constraints in the same ontology as the data. The shape that says “a Character must reference a narrative arc” is itself a node in the graph, versionable and composable. This is the reification argument again: the validation rules are first-class knowledge, not external tooling.
The deeper pattern
I think the split is a necessary pattern for any system where multiple autonomous agents build shared knowledge. The specific technologies don’t matter; you could build it with a property graph and an event-sourced ledger, or with something else entirely. What matters is the boundary: a deliberate, auditable, governed transition from speculative to canonical.
Without that boundary you get one of two failure modes. Either agents write directly to the canonical store and nothing distinguishes speculation from validated knowledge (the “everything is in production” problem), or every write carries so much validation overhead that agents can’t think at interactive speed (the “everything is a deployment” problem).
The two tiers resolve this by making the epistemological status of knowledge an explicit architectural concern. Fast memory says “someone is thinking about this.” Slow memory says “someone has attested to this.” Promotion is the bridge, and it is where reification, the treatment of assertions as first-class entities with provenance, attestation, and shape conformance, does its real work.
What this means for the industry
Most of the agent frameworks gaining traction today focus on orchestration: how to chain model calls, manage tool use, and coordinate agent conversations. That work is necessary, but it sidesteps the harder question: where does the knowledge go?
When orchestrated agents reach conclusions, make claims, and build artifacts, where do those outputs live? In most current architectures, the answer is a vector database and maybe a log file. That is fast memory with no slow memory: no provenance, no attestation, no validation, no way to answer “who claimed this, and why should I believe them?”
As agent systems move from demos to production, from one agent to many, from disposable conversations to persistent knowledge, the absence of this architecture becomes the bottleneck. Not compute. Not context windows. The inability to distinguish what an agent explored from what the system knows.
None of this is exotic. It’s how human cognition works, how legal systems work (testimony versus findings of fact), how science works (hypothesis versus published result), and how knowledge-intensive institutions have organized themselves for centuries. We just forgot to build our software that way.
It’s time to remember.