How to build AI agent memory with a knowledge graph

TL;DR

• An AI agent is only as good as what it remembers. Memory has three layers: the context window (short-term), retrieval (pulling the right facts for a task), and a persistent source the agent draws on across sessions.
• The persistent layer is where most teams struggle. A pile of documents or a bolt-on vector store gives an agent something to search, but keeping it current, structured, and permissioned becomes a second job.
• The stronger pattern is a structured context graph the agent retrieves from: typed, connected, access-controlled, and fed by the work itself so it stays current without anyone maintaining it.
• You can build that in Tana: capture memory from meetings and chats automatically, give it structure with types, keep it current by updating instead of duplicating, and let agents retrieve over it through the MCP server, with every write returning as a proposal you approve.

An AI agent with no memory is a very fast goldfish. It reasons well inside one conversation and forgets everything the moment the session ends, so every task starts from zero and every answer is only as good as what you pasted in. Fixing that is an architecture problem, not a prompt problem: you have to decide where the agent's memory lives, how it stays current, and how the agent gets the right slice of it at the right time. This guide walks through the components of agent memory and how to build the persistent layer with a structured context graph. For the concept behind it, see What is context engineering for AI agents; for the team-context angle specifically, see How to give AI agents company context.

What AI agent memory actually means

"Memory" is not one thing. For a working agent it is three layers, and they fail in different ways:

• Short-term (the context window): the conversation so far and whatever you loaded into the prompt. It is finite, and it resets when the session ends. Stuffing more into it is not memory, it is a bigger prompt.
• Retrieval: the mechanism that pulls the relevant facts into the window for a given task, so the agent works from the right slice instead of the whole archive. This is where retrieval-augmented generation (RAG) fits: retrieve, then generate.
• Persistent (long-lived context): the source that outlives any single session, that the agent draws on tomorrow and that the rest of the team's agents share. This is the layer that turns a goldfish into a colleague.

Most agent-memory effort goes into the first layer (better prompts) and skips the third. But reliability comes from the persistent layer: an agent that can retrieve what your team actually decided, from a source that is current, is dependable in a way no prompt can make it.

Why a structured context graph beats a bolt-on store

Once you accept that agents need a persistent source, the question is what that source should be. The common first answer is a vector store: embed a pile of documents and let the agent search them. It works for a demo. It struggles in production for reasons that are structural, not fixable with a better model:

• It goes stale. The documents were right when you indexed them. Nobody re-indexes after every decision, so the agent confidently retrieves last quarter's answer.
• It is unstructured. A blob of text returns passages, not facts. The agent cannot filter to "open issues from this customer" because the store has no notion of an issue, a customer, or open.
• It ignores permissions. A flat index does not know who is allowed to see what, so either everything is exposed or you build an access layer yourself.

A knowledge graph, or context graph, answers these by construction. The memory is typed (an issue is an issue, with fields), connected (a decision links to the meeting that produced it and the customer who raised it), permissioned (each item carries its own access control), and, if it is fed by your work, current. The agent does not retrieve a passage that mentions a topic; it retrieves the structured, current record of it. That is what Tana is built to be.

How to build AI agent memory in Tana, step by step

Six steps. The first three build the memory; the last three make agents use it safely.

Step 1: capture the memory from real work, not by hand

Memory you maintain by hand is memory that rots, because maintaining it is the first thing that slips. In Tana the persistent layer is fed by the work itself: meetings are transcribed and their outcomes extracted, chats are captured, and documents live alongside them. Every meeting and chat feeds your shared context, so the agent's memory grows as a side effect of working rather than as a task someone has to remember. Capture is on by default, and you can pause it with off-the-record mode.

One important boundary: extraction lands as proposals you accept, not silent writes. So the memory is auto-generated but human-confirmed, which is exactly what you want a downstream agent to trust.

Step 2: give the memory structure

Structure is what lets an agent retrieve facts instead of paragraphs. Ask chat to create a type in plain language, for example a Decision type with fields for the date, the owner, the project, and the rationale. Tana creates it with fields and a workflow. Two settings make the type pull its weight as agent memory:

• Fields turn each entry into structured data an agent can filter and sort, not a wall of text.
• AI instructions on the type tell the AI how to fill and read it, so entries stay consistent no matter who or what creates them.

Now the memory has a shape. An agent asking "what did we decide about pricing, and why" gets typed Decision records with their rationale and their links, not a keyword match.

Step 3: keep the memory current

A stale memory is worse than none, because the agent trusts it. Tana keeps the record current by default: re-running extraction updates existing outcomes rather than creating duplicates, and pinning a document to a recurring meeting makes extraction update that document instead of spawning a parallel one. The third time a topic comes up, it strengthens the existing record rather than adding a lookalike. (For record types you want frozen, like dated snapshots, you can turn updating off so they stay immutable.)

Step 4: control what the memory exposes

An agent should retrieve only what its user is allowed to see. In Tana every document, space, and meeting has its own access control, and access inherits from org to space to item. When an agent retrieves context, it sees only what the person it acts for can see. That means one shared memory can serve the whole team without leaking across permission boundaries, which a flat index cannot promise.

Step 5: connect your agents to the memory over MCP

This is where an external agent gains the memory. Tana runs a Model Context Protocol (MCP) server, so an agent connects once and can retrieve from your context graph. The retrieval tools are the point: contextRetrieval gathers the relevant context for a natural-language question the way built-in chat does, and semanticSearchItems finds conceptually related items, not just keyword matches. That is RAG done for you, retrieval over a structured, permissioned source, rather than a pipeline you assemble and maintain.

Connecting is a one-line setup in Claude Code, and Claude Desktop or any MCP client that speaks HTTP and OAuth connects the same way. The agent reads live context; it does not get a stale export.

Step 6: let agents act, and run on a schedule

Memory is more useful when the agent can also write back. Over the same MCP server an agent can create and update items, and those writes return as proposals you approve, so an agent can maintain the memory it reads without ever changing it silently. And a scheduled agent closes the loop: describe one in a sentence, put it on a schedule, and it retrieves, acts, and files, on its own, filing into the tools you already run on, from GitHub to Linear to Slack. The memory is read, used, and kept current by the same system.

Retrieval is the easy part; the source is the hard part

It is worth being precise about where the difficulty actually is. Retrieval, the RAG step, is close to a solved mechanism: given a good source, pulling the relevant slice into the context window is well understood. The hard part is having a source worth retrieving from, one that is current, connected, structured, and permissioned. A vector store gives you retrieval and leaves that source problem to you. A context graph fed by your work is the source, so the retrieval on top of it is grounded rather than a search over stale text. Build the source right and the memory takes care of itself.

Where a do-it-yourself stack falls short

You can build agent memory yourself: a vector database, an embedding pipeline, a sync job for each data source, and an access layer bolted on top. For a single app with static content, that is a reasonable weekend. The cost shows up over time, and it is maintenance, not capability: every new data source is another connector, the index drifts from reality the moment work moves on, and structure and permissions are yours to enforce. The alternative is not a better pipeline, it is not owning the pipeline: a source that captures itself from the work, stays structured and current, and exposes retrieval and write-back over a standard protocol. That is the layer Tana provides, so your agents get dependable memory without you running the plumbing.

What you have when it is running

After setup, your agents stop starting from zero. An agent picks up a task and retrieves the decisions, issues, and calls that surround it, from a source that is current because keeping it current is the system's job. It answers "why did we do it this way" from the meeting where it was decided. It files its work back as proposals you approve. And because the memory is one shared, permissioned graph, every agent on the team draws on the same grounded context instead of each keeping its own half-remembered version. That is the difference between an agent that is impressive in a demo and one you can rely on next quarter.

Frequently asked questions

What is AI agent memory?

AI agent memory is what lets an agent work from more than the current prompt: the short-term context window, a retrieval step that pulls the right facts into it, and a persistent source the agent draws on across sessions. The persistent layer is the one that matters most and is hardest to get right, because it has to stay current and structured. Tana provides that layer as a shared context graph, fed by your meetings and chats, that agents retrieve over through its MCP server.

How do you give an AI agent long-term memory?

Put the memory in a persistent source outside the model, keep it current, and give the agent a way to retrieve from it, rather than trying to hold everything in the prompt. In practice that means a structured, permissioned store the agent queries at task time. Tana is built as that source: it captures the memory from your work automatically, keeps it current by updating instead of duplicating, and serves it to agents over an MCP server so retrieval is grounded in what your team actually recorded.

Is a knowledge graph better than a vector database for agent memory?

For team agents, usually yes, because the hard part is not retrieval but the source. A vector database gives an agent something to search but leaves structure, freshness, and permissions to you. A context graph is typed, connected, access-controlled, and, if it is fed by your work, current, so the agent retrieves the structured record of a decision, not a passage that mentions it. Tana is that graph, with retrieval and write-back exposed over its MCP server.

What is RAG, and does Tana use it?

RAG (retrieval-augmented generation) means retrieving the relevant facts and giving them to the model at generation time, instead of relying on what the model was trained on. Tana does this: its contextRetrieval and semanticSearchItems tools gather the relevant slice of your context for a question, which an agent then reasons over. The difference from a typical RAG project is that Tana is also the source being retrieved from, structured, permissioned, and kept current, so you are not building and maintaining the retrieval pipeline yourself.

How do AI agents access my company's context in Tana?

Through Tana's Model Context Protocol (MCP) server. An agent such as Claude Code connects with a one-line setup, and Claude Desktop or any MCP client that supports HTTP and OAuth connects the same way. Once connected, the agent can retrieve context and write back, with every write returning as a proposal you approve. Access respects your permissions, so an agent only ever retrieves what the person it acts for is allowed to see. The company-context angle is covered in depth in How to give AI agents company context.

How do you keep AI agent memory from going stale?

Make updating the memory a side effect of working, not a separate chore. In Tana, memory is captured from meetings and chats as they happen, and re-running extraction updates the existing record instead of stacking a new copy, so the source reflects the latest state rather than the moment you last indexed. A scheduled agent can keep it tidy on its own. Staleness is the quiet killer of agent reliability, which is why the memory needs to come from a source that updates as work happens rather than a store someone has to re-index.