Agent Memory vs. Knowledge Base: What's the Difference?

A knowledge base and agent memory differ in who answers for each record. A wiki page is published once someone reviews it, read when someone goes looking, and owned by someone on your team who can be asked to fix it, even when an agent wrote the first draft. An agent memory note is saved by an agent in the course of a task, loaded into a later task without anyone asking, and nobody has vouched for it yet. Most engineering teams need both, plus a review step that moves the durable notes from memory into the knowledge base.

If you run Confluence, Notion, or a docs site and someone says your coding agents need "memory," they are describing a second system with its own write path, separate from the wiki you have. The sections below compare the two on accountability, retrieval, record shape, scope, and decay, then cover what should move between them.

Review decides who answers for a record

A knowledge base gets a new page when a person decides something is worth documenting. Someone writes the runbook for a failed deploy, or accepts a draft an agent produced from the code, and publishes it. The page has an author or an owning team, so when it is wrong there is a person to ask and an edit history showing who changed what.

Agent memory gets a new record during or after an agent's task. A coding agent discovers that an integration test needs a particular environment variable and calls a write tool, or a memory layer extracts the finding when the session ends. No one decided the finding deserved a page. The agent inferred it, sometimes from a single test run, and the record carries that inference forward.

The review step changes what a reader can assume. A wiki page claims that a person stood behind the content when they published it, whoever typed the first draft. A memory note claims only that an agent observed something once. A team that gives memory notes the trust it gives the wiki will act on guesses as if they were decisions. Agent memory governance covers the controls for that risk in detail.

A wiki answers when asked, memory arrives with the task

A knowledge base is pull-based. You type a query into the search box, pick a result, and read it. An agent with a wiki connector works the same way: it decides to search, gets back the pages that match, and reads them. Either way, something has to ask.

Agent memory can arrive without a query from anyone. A memory system can load relevant notes at session start or when the agent touches related code, so the note about the environment variable shows up the next time the agent edits that test. Whether that happens depends on configuration, so check the agent's tool calls or loaded context rather than assume it.

Connecting retrieval to the wiki does not turn the wiki into memory, because retrieval only reads. The mechanics of retrieval, context windows, and stores are covered in agent memory vs RAG vs bigger context windows. For this comparison, the narrower point is that an agent searching your wiki finds what people wrote, and nothing it learns goes back.

Pages are written for people, notes for the next task

A knowledge base record is a page meant to be read top to bottom by a human. A page on regenerating the API client explains prerequisites, commands, and troubleshooting in full sentences and changes through edits that leave history.

An agent memory record is usually short and tied to circumstances. A useful one names the constraint, the evidence, and where it applies: "The payments integration test fails without PAYMENTS_WEBHOOK_SECRET. Seen on branch feat/refunds." Some memory systems, Dosu among them, record the session, repository, or branch that produced a note.

You can use the shape as a field test. If you open a record and it reads like documentation a new hire could follow, it belongs to the knowledge base. If it reads like a sticky note left for the next person on the same task, it is memory.

Permissions follow people in a wiki and the work in memory

Wiki permissions start with a person. An admin grants access by space, group, or page, and an agent searching the wiki should see no more than its credentials allow.

Agent memory needs a different boundary, because the reader is a task rather than a person. The questions are which repository, branch, project, or team a note belongs to, and which agents can retrieve it. A note learned on one feature branch may be true only there. A note learned in one repository may mislead an agent working in another.

Scoping differs from one coding-agent memory product to the next. Before connecting one, ask what identity the agent reads under, whether a note from one repository can surface in another, and what happens to a note when someone's access is revoked. Where coding agent memory should live compares local files, the repository, and shared services on who can read each.

Wikis go stale one page at a time, memory in bulk

Both systems decay as the code changes, and they decay differently. A wiki page goes stale quietly. Nobody edits it, the code moves, and the page keeps its original authority until someone notices the mismatch and fixes it. Because each page has an owner, the repair is a known edit by a known person. Tools that automate knowledge base updates compares ways to trigger that edit from the change that caused it.

Memory goes stale at volume. Agents can write notes far faster than people write pages, often several overlapping notes about the same thing, and no single person owns any of them. A wrong note can keep resurfacing in later tasks until something retires it. How to prune stale agent memory covers how to tie that retirement to the event that made a note false.

The two side by side

Test whether anything writes back

You can tell which system you have with one check. Ask a coding agent to work through a task where it learns something the docs do not say. End the session. Start a fresh one, ideally on a teammate's machine, and see whether the finding is available without anyone repeating it.

If the fresh session can search the wiki but the finding is gone, you have a knowledge base with a read path and no memory. If the finding comes back, check three more things: where the record landed, who else can read it, and whether anyone has reviewed it against the code. If the record exists but the next agent never received it, the break is in loading rather than storage, which context engineering vs agent memory helps you diagnose. A note that reaches every agent on the team unreviewed is shared memory, and it needs the treatment in the next section.

Promote durable notes into the knowledge base

The useful design moves knowledge in both directions. The knowledge base feeds the agent, which reads maintained pages before it works. Memory captures what the agent learns. A review step decides which notes deserve to become maintained pages.

A note is ready to graduate when it meets three conditions:

• It keeps coming back. Agents on different tasks, or different engineers, keep retrieving or rewriting it.
• It still matches the code. Someone checked it against the current implementation rather than the branch it came from.
• Someone will own it. A person or team accepts that the page is theirs to correct.

Notes that fail those conditions should stay in memory or expire. A workaround specific to an unmerged branch, a guess from one failed test run, or an observation nobody has confirmed is useful to the next agent on the same task and harmful as a team rule.

The reverse flow matters as much. When a memory note contradicts a wiki page, the conflict is a signal that one of them is wrong, and the knowledge base is where the corrected answer should end up, because that is the record a person answers for.

Which one fixes your symptom

Agents keep asking questions the wiki answers. Start with the read path. Check whether the agent can reach the page during the task, and whether the page's title and content match what the agent searches for. Adding memory does not help an agent that cannot find a page that exists.

Agents repeat a mistake someone corrected. Look for a write path. If the correction was typed into a chat and never saved, nothing carries it to the next session. Memory addresses the repeat when the correction is recorded and loaded on related work. How to stop coding agents repeating fixed mistakes covers which corrections to keep and where each one belongs.

People cannot find anything. Fix the knowledge base. Check whether the page exists, whether readers have access, and whether it is current. Agent memory serves the next agent rather than a person searching the wiki. If you are choosing a new knowledge base, AI knowledge bases for engineering teams compares how six products build and serve their content.

Some questions expose a gap in both. When no page documents the answer and no agent has recorded it, establish the answer first, then decide whether it belongs in a maintained page, a scoped note, or both.

FAQ

Can we use our existing wiki as agent memory?

Your agents can read it, and they should. A wiki connector gives an agent access to what people wrote but does not save what the agent learns, so a wiki alone covers the read half of memory and leaves the write half empty.

Does agent memory replace a knowledge base?

No. Engineers still need maintained pages they can read, link to, and correct, especially for decisions and procedures the whole team relies on. Memory carries task-level findings between agent sessions, and the best of those findings should end up in the knowledge base.

What should we do when a memory note is wrong?

Find the note, correct or retire it, and check that the next agent receives the corrected version. If the wrong note contradicts a wiki page, fix whichever one is wrong and treat the wiki as the record of the corrected answer. A note that was wrong once is also a reason to look at what else that write path saved without review.

Check what writes back in your stack

Run the write-back test from earlier on one real task this week. If the finding disappears with the session, your agents have a read path and nothing else.

Dosu provides both halves and a path from one to the other. Through the Dosu MCP server, an agent calls read_knowledge to retrieve your team's Documents, approved answers, and Topics, along with notes written on the same repository and branch, and calls write_knowledge to save what it learned. Notes are append-only and save directly without waiting in Review. When the repository is connected to the Library, the note is scoped to that repository and branch, and once the branch's pull request merges, the note becomes a Topic candidate that Dosu checks against existing Topics. With a Monitor on a connected repository, Dosu checks configured pull-request events and paths against published Documents and proposes updates. To require a person to accept, edit, or decline every proposed Document update in Review, turn off Auto Accept Review in the Library settings.

Create a Dosu Library and connect your repository. Creating a Library requires an organization Owner or Admin role. Then run npx @dosu/cli setup to point your agent at it, and repeat the write-back test.