AI coding agent memory provenance is the ability to trace a statement, suggestion, or code change from an AI coding agent back to the stored memory that shaped it, and from that memory back to the session, project, and tool where it was first recorded. If your agent says "use pnpm, not npm" or "we dropped Redis for SQLite," provenance tells you where that came from: which memory, which repo, which tool, and whether it is still true.
At Open Agentic Brain & Memory (OpenAB), we think provenance matters more as agents remember more. Once you give Claude Code, Cursor, Codex, Antigravity, or Kilo Code (beta) a persistent memory, their answers stop coming only from the prompt and the code in front of them. Some of each answer comes from things learned in earlier sessions, sometimes in a different tool or on a different laptop. That helps, but only if you can still answer the question every developer eventually asks: why did my coding agent say that?
Without memory, a coding agent's reasoning is fairly easy to audit. It read your prompt and the files it opened, and maybe ran a few commands. If it suggests something odd, you scroll up and find the cause.
Memory changes that. Here is a typical scenario:
On Monday, in Claude Code, you decide to replace Redis with SQLite for a small internal service because the extra infrastructure isn't worth it.
On Tuesday, you open the same repo in Cursor and ask for a caching layer. Cursor writes it against SQLite without being asked.
On Thursday, a teammate's branch reintroduces Redis for a reason you never heard about, and your agent quietly keeps steering toward SQLite.
Tuesday is exactly what shared memory is supposed to do: tell one tool and every tool knows. Thursday is where provenance comes in. If you can't see that the SQLite preference came from a specific Monday decision in a specific project, you can't tell whether the agent is helping you or working from an old memory.
For memory to be traceable, each stored item needs enough context that a person can work out where it came from and decide whether to trust it. In practice, that means: A clear unit of memory. Decisions, fixes, and preferences are stored as separate, readable items, not mixed into one opaque summary.
A project tag. Every memory belongs to a project, so "always use pnpm" in one repo doesn't silently spread to a repo that uses Yarn.
A visible briefing. What the agent was told at session start should be something you can read, not a hidden system prompt.
On-demand lookup. When the agent recalls something mid-session, you should be able to run the same query yourself and see the same results.
Edit and delete rights. If a memory turns out to be wrong or stale, you fix it at the source so it stops affecting every future answer.
OpenAB is built around these properties.
OpenAB captures decisions, fixes, and preferences from your coding sessions and stores them in a local SQLite database on your own machine. Each memory is tagged with a project, and the project is found by walking up from your working folder to the nearest .git. So you never have to label anything yourself. The repo you were working in is the project the memory belongs to.
At session start, a start-up hook distills and ranks what's relevant and injects a briefing of at most 2,000 tokens, in 84 ms at p50. That briefing is your first provenance checkpoint. Everything your agent "just knows" at the start of a session came from it. When an answer surprises you, read the briefing first. The briefing lists memories you can look up individually, so you can go from an item in the briefing to the full memory behind it.
During a session, tools can also pull memory on demand over MCP using brain_recall, brain_remember, brain_context, and load-my-brain. Recall over 10,000 memories takes 28 ms at p50. Recall is a plain query against your own store, so you can run the same query yourself and see exactly which memories came back. Nothing is hidden behind a hosted ranking service you can't inspect.
Say your agent insists on a pattern you don't remember choosing, like calling refresh() before save() in an auth module. Here's how to trace it with OpenAB:
Check the session briefing. Was the rule in the start-of-session context? If so, it came from an earlier memory in this project, or from the project map, which covers up to 20 projects in your global CLAUDE.md, AGENTS.md, and GEMINI.md.
Run the recall yourself. Use brain_recall with a few words from the agent's claim. Hybrid search uses both keywords and meaning, so "refresh before save" will find a memory worded as "token must be refreshed prior to persisting the session."
Check the scope. Recall can search one project or all of them. If the memory came from another repo, you've found the cause: a lesson from one codebase applied to another.
Open it in the control panel. OpenAB's local control panel lets you read, edit, pin, or delete every memory. If the rule is correct, pin it. If it's outdated, edit it. If it was never true, delete it.
Confirm the fix. Start a new session and check that the briefing reflects the change, in this tool and in every other tool that shares the memory.
The point is that tracing ends in a fix. Provenance that only explains a bad answer, without letting you correct its source, just helps you diagnose the same bug repeatedly.
Many memory systems for AI tools are hosted APIs. Your sessions go to a vendor's server, get summarized and embedded there, and come back as context. Even when that works well, provenance has gaps you can't close: you can't see the full store, you can't confirm what was sent to the model, and you can't be sure a deleted memory is actually gone.
OpenAB takes the opposite approach, and that's why provenance is practical. There's no account and no OpenAB server. Your memory lives in local SQLite. For cross-machine sync, it's encrypted with age, the key stays only in your OS Keychain, and the encrypted blob is stored as a Release asset in your own private GitHub repo. At start-up, OpenAB merges in what your other laptops learned, so the briefing is the same everywhere. If the repo or token leaks, nothing readable is exposed. You can read more in our overview of OpenAB's shared, owner-held memory for coding tools.
This affects provenance directly. If a memory traveled from your desktop to your laptop, it went through infrastructure you own, and the copy on each machine is something you can open and inspect.
Cross-tool memory adds a question single-tool memory never has to answer: which tool learned this? A decision made in Claude Code can show up in Codex the next day. That's the core promise. Decide something in Claude Code on Monday, and Cursor already knows it on Tuesday. When you trace a memory, it's useful to remember that the tool giving the answer is often not the tool that recorded the lesson.
Project awareness keeps this manageable. When you open a folder, OpenAB gives you that repo's history first. Memories from other projects aren't walled off, since recall can still search across all of them, but they aren't pushed into every session by default. So when an agent applies a lesson from another project, it's usually because recall explicitly reached across projects, and that's easy to see and question.
Size matters for provenance. If an agent is handed a huge dump of past notes, nobody will read it, and nobody can trace which line caused which answer. A small, ranked briefing is something you can actually review.
That same limit is why OpenAB saves tokens in every AI coding tool you use. Instead of re-explaining a project or pasting long notes into every chat, each tool gets a briefing under 2,000 tokens. context for a 10,000-memory store takes 1,325 tokens instead of 1,131,367. On the LoCoMo benchmark, OpenAB keeps 97% of the full-conversation score while reading 18% of the tokens. Fewer tokens per session means you hit Claude, Cursor, and Codex limits later, and a shorter briefing is one you can audit line by line.
Provenance answers "where did this come from?" A second question follows: "is this memory usually right?" OpenAB covers this in two ways:
Outcome scores track how memories perform over time, so memories that keep leading to good results rank higher and weak ones rank lower.
brain eval scores recall against your own history, so you can measure whether the right memories come back for the questions you actually ask, instead of relying on a generic benchmark.
Together with the control panel, these give you a full loop: see what the agent was told, trace it to a memory, judge whether that memory is reliable, and correct it if it isn't.
When you set up OpenAB, you can start from past AI work or start fresh. If you import past work, you get value right away, but some old decisions may come with it. That's when provenance tracing helps most. Spend your first few sessions checking briefings, and pin or delete as you go. If you start fresh, every memory comes from a session you remember, which makes tracing simpler from day one.
Read the start-of-session briefing whenever an answer surprises you. It's at most 2,000 tokens.
Rerun the agent's recall yourself with brain_recall and compare results.
Check whether the memory came from this project or another one.
Pin memories that are correct, edit stale ones, and delete wrong ones in the local control panel.
Run brain eval from time to time to make sure recall still returns the right memories.
Keep your memory owner-held: local SQLite, age-encrypted sync, and the key in your OS Keychain.
OpenAB is free and open source under Apache-2.0, built by Rohith, Chandan, and Sushmita. You can find the source in the GitHub repo rohithhn/Open-Agentic-Brain-and-Memory. Our blog has guides on AI memory layers, context engineering, long context vs RAG vs memory, agent hooks, and self-hosted memory privacy.
Yes. The start-up hook injects a briefing of at most 2,000 tokens, and that briefing is the full set of remembered context the agent starts with. You can read it, and every memory behind it is in your local control panel.
Edit or delete it in the control panel. All your tools share one memory, so fixing it once fixes it everywhere, including on your other machines after the next sync.
No. There's no account and no OpenAB server. Recall runs against your local SQLite store, and sync uses an age-encrypted blob in your own private GitHub repo.
Every memory is tagged with the project found by walking up to the nearest .git. Recall can search one project or all projects, so you can scope a query and see whether the memory belongs to the current repo.