Agent Memory vs Knowledge Base vs System of Record

Three things sit under an AI agent and all of them "store what the agent knows": memory, a knowledge base, and a system of record. Teams pick one, discover it doesn't do the job, and conclude they need a better version of the same thing — when they actually needed a different one.

There is a single question that separates them:

When this piece of information turns out to be wrong, who finds out, and who is accountable?

Answer that for each store and the boundaries become obvious.

Memory: nobody finds out

Agent memory exists to make the next run better informed. Summaries of past sessions, extracted preferences, retrieved chunks, a vector index over your documents. It is optimized for one thing: recall — surfacing something relevant at the moment it is needed.

Nothing in that design has an opinion about truth. A nearest-neighbour match returns the passage most similar to the query, not the passage most likely to be correct. A session summary compresses what was said, including what was said wrongly. If a bad fact enters memory, the failure mode is silent: it keeps getting retrieved, keeps sounding consistent, and gets more plausible each time it is restated.

Memory is the right tool when being approximately right quickly beats being exactly right slowly — recalling that a customer prefers email over calls, that a codebase uses pnpm, that last month's campaign underperformed. It is the wrong tool the moment someone downstream treats it as a fact.

Accountable party: none. That is not a flaw. It is what makes memory cheap.

Knowledge base: the author finds out, eventually

A knowledge base is written for people to read. Docs, wikis, runbooks, internal handbooks. It has authors, and an author is a kind of accountability — someone's name is on the page.

But the accountability is front-loaded. It applies at the moment of writing and then decays. Nothing in a wiki forces a re-check. The characteristic failure of a knowledge base is not that it was wrong when written; it is that it stayed on the page for eighteen months after it stopped being true, and looks exactly as authoritative as the page updated yesterday.

Agents make this worse in a specific way: they read confidently. A human skimming a runbook notices the "last updated 2024" line and hesitates. An agent takes the content and acts.

Accountable party: the original author, at write time only.

System of record: someone is on the hook, and you can prove it

A system of record is the store that wins when two sources disagree. That authority is not a label you apply — it has to be produced by three properties, and all three are properties of the write, not of the storage:

• Attribution — the record can name its source. Not "created by API key 7," but which agent, acting on which request, from which upstream material.
• Accountability — a specific person is on the hook for the record existing in its current form. They either wrote it or accepted it.
• Reconstructability — you can replay how it reached its current state, including the versions it passed through and the changes that were rejected.

Note what is missing from that list: anything about the database. You can build a system of record on Postgres, on a spreadsheet, or on a filing cabinet. What you cannot do is get it for free by adding an API to a data store.

Accountable party: a named human, permanently, with the diff to prove it.

Side by side

	Memory	Knowledge base	System of record
Written for	The agent	People	Both, plus downstream systems
Optimized for	Recall	Readability	Correctness and traceability
Who is accountable	Nobody	The author, at write time	A named reviewer, permanently
Characteristic failure	A wrong fact circulates silently	Content goes stale in place	The review queue outruns attention
Cost of being wrong	Low — until something reads it as fact	Medium	High, which is why the gate exists

The mistake worth naming

The expensive error is not choosing wrong between the three. It is letting the boundary leak — specifically, letting something in memory become a fact without anything happening in between.

It looks like this. An agent researches a prospect. Some of what it finds is verified; some is inference from a job title and a press release. All of it goes into the context window, where the distinction disappears — a context window has no confidence column. The agent then writes a CRM record. Nothing rejected it, so it is now a business fact, and next quarter someone forecasts against it.

No individual step was unreasonable. The failure is structural: there was no moment where the transition from "the agent believes this" to "the business asserts this" required anything to happen.

That transition is exactly what a system of record charges for. It is the whole cost, and the whole value.

How the three actually fit together

They are layers, not alternatives:

1. Memory carries working context between runs. Cheap, disposable, never cited as a source.
2. The knowledge base holds the durable long-form material people read and agents reference — and should link out to the records that carry the actual numbers, rather than restating them.
3. The system of record holds the facts other things depend on. Anything a report, an invoice, a forecast, or another agent reads belongs here, and gets in through a reviewed write.

A practical boundary test, when you are unsure where something goes: if this were wrong for three months, what would it cost? Nothing — memory. Someone would be mildly misinformed — knowledge base. A decision, a customer, or a number would be wrong — system of record, with a review gate in front of it.

Where Busabase sits

Busabase is the third layer. An agent connected to a Busabase workspace does not write to your data directly — it opens a Change Request, a human reviews the diff, and only merged changes become facts, carrying their provenance and full history including the versions that were rejected.

It is not a memory layer and is not trying to be. Keep your vector store; agents should read from both. The distinction this article is about is the one worth keeping sharp: read widely, write narrowly.

If you want the longer argument about what makes a store authoritative, that is the system of record for AI agents page. If you would rather just see a reviewed write happen, connect your agent and let it propose something.