Agent Memory for Data Teams: What an Agent Should Remember About Your Data

An agent should remember the things about your data that are expensive to rediscover and slow to change: metric definitions, ownership, past incidents, and the decisions people made and why. It should not remember data values, schemas, or permissions, because those live in the warehouse and go stale. Anthropic's memory tool documentation describes memory as a client-side store your application controls, which means you decide what goes in. This post is our opinion on how data teams should make that decision.

Key Takeaways

• •Remember decisions, definitions, ownership and incident history. These change slowly and cost hours to rediscover.
• •Do not remember schemas, row counts, grants or query results. Re-read them live from the warehouse every time.
• •Every memory entry needs a source, an author and an expiry, or it becomes a confident wrong answer.
• •Memory is a context-engineering problem, not a model problem: the agent is only as good as the knowledge it can retrieve.
• •Memory must be inspectable and editable by humans, as files or records in a place your team already reviews.

Why agents without memory behave like a new hire every morning

Ask a stateless agent why the orders pipeline was slow last week and it starts from zero. It lists tables, reads query history, forms a theory, and offers it with confidence. Tomorrow, someone asks a related question and it repeats all of that work, often reaching a different answer. Nothing it learned yesterday survives. The cost is not only tokens. It is that your team keeps re-explaining things that are already settled, such as which revenue column finance trusts or why a particular join is known to be lossy.

A human analyst who joined last month already knows some of this. They have heard that the legacy customer table is deprecated, that the Tuesday load is slow because of a vendor export, and that one dashboard should never be edited. That knowledge is not in the schema. It lives in Slack threads, pull request comments and people's heads. We wrote about this gap in why AI agents fail on enterprise data without context, and memory is the mechanism that lets an agent carry that knowledge forward instead of rediscovering it.

The goal is not an agent that remembers everything. It is an agent that remembers what a good colleague would remember, and consults the live system for everything else. That distinction drives every design choice below.

Memory is not the warehouse, and it is not the catalog

Teams often conflate three things: the system of record, the catalog, and agent memory. The warehouse holds the facts, and it is authoritative. The catalog holds descriptions and lineage that people curate. Memory holds what the agent has learned from working with you: which assumptions were confirmed, which fixes were approved, which answers were rejected. Memory should point at the other two, not copy them.

Consider access history. Snowflake's ACCESS_HISTORY view documentation lists a retention period of 365 days for that view. An agent that copies those records into its own memory creates a second, slower, unaudited version of something Snowflake already retains and governs. The better pattern is to remember the question and the conclusion ("the customer_id join was safe after the March migration, checked against access history"), then re-run the query when the answer matters again.

If you keep that rule, memory stays small, cheap to review and hard to poison. If you break it, memory becomes a shadow warehouse with no owner, and the first time it disagrees with the real one, nobody will know which to believe.

A five-layer model of what an agent should remember

We split agent memory into five layers, ordered from most durable to least. Each has a different owner, a different expiry, and a different tolerance for being wrong.

Layers one to three are the ones people underestimate. They are small, high-value and rarely written down anywhere queryable. Layer four is where agents earn their keep, because incident history is the raw material for faster diagnosis. Layer five should never outlive the task.

Notice what is missing from the table: column lists, grants, row counts, query results. Those are layer zero, the live system, and the agent should read them fresh each time through a tool call.

What an agent should never remember

Some things are dangerous to persist even when they are convenient. The first is anything that is authoritative somewhere else and changes: schemas, grants, freshness values, and costs. A remembered schema is a bug waiting for the next migration. A remembered grant is worse, because the agent may reason from access that was revoked last week.

The second is sensitive data. If an agent summarizes a PII audit and stores the raw findings in a notes file, you have copied regulated data into an unmanaged store. Memory should hold the conclusion ("column email in analytics.users is unmasked, ticket opened") and a pointer to the audit trail, not the values. Governance has to follow the data through every system an agent touches, including its own memory.

The third is unverified conclusions. If an agent guessed a root cause and nobody confirmed it, storing that guess as fact trains the next session to trust it. We tag every entry with a status: proposed, confirmed or rejected. Only confirmed entries are used as premises, and rejected ones are kept so the agent stops re-proposing them.

Where memory should physically live

Memory should live somewhere your team already reviews. The Anthropic memory tool is a useful reference here: per its documentation, it is a client-side tool, so your application executes the file operations and stores the results wherever you choose. That design choice matters. It means memory can sit in a Git repository, behind your own access controls, with pull request review on every change.

We prefer plain files and structured records over opaque vector stores for layers one to four. A definition file in a repository can be diffed, blamed and reverted. An opaque embedding cannot. Retrieval over those files can still use semantic search, but the source of truth stays human-readable.

Exposure matters too. If the store is reachable through an MCP server, any compatible client can read it, whether that is Claude Code, Cursor or a custom agent. The Model Context Protocol specification defines tools, resources and prompts as the standard primitives, and memory maps cleanly onto resources for reads and tools for writes. Writes should be gated, since a write is where bad memory enters.

Keeping memory honest: provenance, expiry and review

Every memory entry needs three fields: where it came from, who approved it, and when it should be re-checked. Without provenance, you cannot tell a confirmed fact from a hallucination that was written down once. Without expiry, entries outlive the reality they described. Without review, the store drifts until people stop trusting it and stop using it.

Contracts give a good model for this. dbt's model contracts documentation describes enforcing a declared set of column names and data types at build time. A memory entry that claims "this model returns one row per order" is the same kind of claim and should be checkable the same way. When a contract changes, entries that depend on it should be flagged for re-verification automatically.

• •Provenance: link to the pull request, ticket, query or conversation that produced the entry.
• •Status: proposed, confirmed or rejected, with the approver named.
• •Expiry: a date or a trigger, such as a schema change on a referenced table.
• •Scope: which team, domain or environment the entry applies to.

Review can be light. A weekly pass over new and expiring entries, done by the people who own those domains, is enough for most teams.

Where Data Workers fits, and where it does not

Data Workers is an open-source set of MCP-native agents for data infrastructure, and several of them depend on memory. The Incidents Agent uses past incident history to diagnose new failures faster. The Catalog Agent holds definitions and ownership, and the Schema Agent checks remembered decisions against current drift. The open-source edition is read-only by default, so memory in that mode records what agents observed and proposed, not changes they made.

We should be honest about limits. Memory does not fix a missing semantic layer. If nobody has agreed what revenue means, an agent cannot remember a definition that does not exist, and it will pick one. Memory also does not replace a catalog. If your ownership data is wrong in the catalog, copying it into memory just makes it wrong in two places. Fix the source first.

In our pilot testing, the practical gain has been less repeated diagnosis and fewer re-explained definitions, not smarter reasoning. We do not have a published benchmark for it, so treat that as our experience rather than a measured result. If you already have strong cataloging and runbooks, you may need less than you think.

A rollout order that works

Start with layer one. Write down the ten metrics your team argues about most, with the owner and the canonical SQL, and make them readable by the agent. This alone removes a large class of confidently wrong answers, and it takes an afternoon. Do not start with automatic memory capture, because it fills the store with noise before you have rules for what deserves to stay.

Next, add incident history. After each incident, have the agent draft a short entry: symptom, root cause, fix, and the signal that would have caught it earlier. A human confirms or edits it. Within a few weeks you have a searchable record that the Incidents Agent can use, and your on-call engineers benefit even without an agent.

Only then add decisions and agent-written notes, with the status and expiry rules above. Measure it simply: how often do people have to re-explain something the agent should know, and how often does a remembered entry turn out to be wrong? If the second number rises, tighten review before you add more memory.

Frequently Asked Questions

What is agent memory for data teams?

It is a store of durable knowledge an AI agent can read and write across sessions: metric definitions, ownership, past decisions and incident history. It is distinct from the warehouse, which holds the data itself, and from the catalog, which holds curated descriptions and lineage. Good memory points at those systems rather than copying them.

Should an agent remember query results or schemas?

No. Schemas, row counts, grants and query results change and are authoritative in the warehouse. An agent that remembers them will eventually reason from stale facts. Remember the conclusion and the method instead, then re-run the query or tool call when the answer matters again.

How is agent memory different from a context layer?

A context layer is the broader set of knowledge an agent can retrieve: catalog, semantic definitions, lineage and docs. Memory is the part that the agent itself accumulates and updates through use. In practice they overlap, which is why we treat both as context engineering and give them the same provenance and review rules.

Where should agent memory be stored?

Store it where your team already reviews changes, such as a Git repository or a governed database, and expose it through MCP so any compatible client can read it. Human-readable files for definitions and decisions are easier to audit than opaque vector stores.