What the built-in memory of ChatGPT, Claude and Copilot is worth
Until recently, each of our tools had only a partial knowledge of our projects. Claude Code had its instructions, Cursor its rules, Codex its own, and none of the three knew what the other two had understood. The effect was most visible from one session to the next. Our projects are documented, yet an agent keeps nothing between sessions. At every start it therefore reread the documentation, the file tree and the key files to get the project back in mind, and everything it had drawn from them disappeared when the window closed. A decision made the day before in another tool did not exist for it.
This rereading has a cost, and it is paid three times over. The first cost is time, since the opening minutes of each session go into rereading what was already known. The second is quality, because everything the agent rereads takes up its context window, and a window filled with files reread for nothing leaves less room for the requested work. The third is money, because each rereading is billed in tokens, in every session and on every tool, and those tokens are not free. That bill is what led us to look for something else.
This loss of context is not limited to software development, and every vendor answers it with a memory built into its own tool, which any user will recognise. ChatGPT remembers what you tell it from one conversation to the next, Claude offers projects where you can store documents and instructions, and Copilot reads the SharePoint files and emails the user has access to. For someone working alone with one of these tools, the rereading disappears and context carries over from one exchange to the next, which is genuine progress.
This progress, however, stops at the boundary of the account. As soon as a company rolls these tools out across its staff, each person has their own memory, and what we experienced with our three tools plays out again across departments. What the sales department has taught its ChatGPT exists neither for the accounting department's ChatGPT nor in the Claude used by the engineers. Companies have been here before with personal Excel files, when everyone kept their own version of the truth in a workbook nobody else opened.
The comparison ends there, and the difference matters more than the fragmentation. A workbook can be copied to a shared server, and it remains the company's property. A ChatGPT memory lives with the vendor, in a format the company can neither read, export nor connect to another tool. Over the months, part of what the company knows, its procedures, its decisions and its ways of working, ends up stored in accounts it does not control, and on the day it changes tools, none of it follows.
None of this calls the agents themselves into question, and our article on eve by Vercel showed what they bring to an e-commerce site or an internal tool. What remains to be decided is where their knowledge is stored and who it belongs to. Our answer is a memory shared between tools, owned by the company and governed by it. The sections that follow take these three words in order.
A shared memory for every AI agent in the company
Shared, first. Today, when we open the code of our own website in Claude Code and ask where media files are stored, the agent answers Vercel Blob before reading any code, adds that an initial scoping had planned for Cloudflare R2, and gives the date of the change and the file concerned. The same question asked from Cursor or Codex gets the same answer, because all three tools query the same place.
That place is Cognee, a memory engine for agents published as open source under the Apache 2.0 licence, which we run on a studio server. The three tools connect to it through an MCP server we adapted to our setup, and each has the same two commands, remember and recall, whatever interface we are working in. The source of this memory is a folder of Markdown files, versioned with Git, which holds the records of our projects, the procedures we reuse and the lessons drawn from each project.
Measured against the three costs described earlier, the change shows up session by session. An agent opening a site delivered two months ago already knows which CMS was chosen, why the alternative was set aside, and which incident led to the rule we have applied to client uploads ever since. It no longer starts from a fresh interpretation each time. A lesson learned on an animated site serves the next site, because it was written once and can be retrieved from any tool. And when a session in Cursor ends in a decision, the next session in Claude Code knows about it.
For a company, it is enough to replace project records with client accounts, procedures with internal processes, and lessons with decisions made in meetings. The mechanism is the same. What makes it possible is the way Cognee organises what it is given, which deserves a closer look.
Knowledge graph or vector search, and what it changes for an agent
Here is what an ordinary decision record becomes once it enters Cognee. The company in the example is fictional, and the two carriers it compares, Colissimo and Chronopost, are French parcel delivery services.
"On 2026-06-03, Atelier Vasseur
chose Colissimo for shipments
within France. Chronopost was
ruled out because the volume
did not justify its price. The
decision is reviewed every
quarter."
|
| chunking, extraction
v
[Atelier Vasseur]
|
+--chose (2026-06-03)--> [Colissimo]
| |
| [France shipments]
|
+--ruled out--> [Chronopost]
|
because
v
[low volume]
[Carrier decision]
|
+--reviewed--> [every quarter]The engine splits the document into chunks, then a model extracts the entities, such as a company, a carrier and a date, along with the relationships between them. Each relationship becomes a link, and together they form a knowledge graph. When an agent later asks "which carrier for France, and why", it follows the links from Atelier Vasseur to Colissimo, then to the reason, the alternative that was ruled out and the review date. A different question, "what is reviewed every quarter", starts from another node and reaches the same decision.
Most tools that feed documents to an LLM do not work this way. They rely on vector search. Each passage is turned into a series of numbers representing its meaning, and the agent receives the passages whose meaning is closest to its question. This works well for finding a paragraph on the same subject. It works less well for answering "why did we choose this supplier", because the answer is often spread across three documents, and similarity to the question is not enough to connect them.
This difference is what makes a memory shareable between several tools. A coding agent, a support assistant and an agent preparing a meeting do not ask the same questions, and a graph answers all of them from the same facts. Cognee also keeps vector search alongside the graph, together with a relational database, and combines the three depending on the question. We chose it for that combination, for its licence, and because it installs on an ordinary server. It also has its limits at this stage, since ingesting a document takes several minutes, and a modified document has to be removed and sent again, which requires some tooling. The last of our reasons mattered most, because it determines the second word of our answer. A memory can only be owned if it runs on infrastructure belonging to whoever fills it.
The company's knowledge remains its property
Owned, next, which starts with a folder of forty-two Markdown files on GitHub holding our entire memory. They can be opened in any text editor, read without any tool and copied to a USB stick. The graph described above is a projection of these files, which remain the source, and if the server disappears it can be rebuilt from them in an hour. If we change memory engines in two years, the files stay and connect to the next one. No subscription conditions the company's access to what it knows, and no service provider does either, Nualt included.
This is the point that seems most important to us, beyond the technology. A company's knowledge, meaning its procedures, its decisions and the reasons behind them, and the history of its clients, is part of its value. When that knowledge pours into the memories of third-party tools, it becomes someone else's feature. When it lives in files the company owns, on infrastructure it controls, it remains an asset the company can read, pass on, audit and develop without asking anyone's permission.
In return, keeping knowledge in files means writing them with an understanding of how a graph reads them, and three rules cover most of it. Each thing gets a single name that is used consistently, because a project called "Atelier Vasseur" in one file and "the Vasseur client" in another becomes two nodes. Each section of a file stands on its own and names its subject in the first sentence, because chunking can split the text anywhere. And relationships are written as short sentences, subject, verb, object, because that sentence is what becomes a link.
Access rights, or who feeds the memory and who reads it
Governed, finally. For us the question does not arise yet, because a single person feeds the memory and every tool that queries it does so on that person's behalf. In a company of thirty people, it arises on the first day. The HR agent must not see management's salary grid, and an intern asking the same agent a question must not receive the same answer as the HR director.
Cognee handles these rights at the level of its document sets. Each department has its own set, each user receives read or write rights on each of them, and a search only covers what the person running it is allowed to see. The same agent, queried by two people, therefore does not consult the same sets and does not give the same answer. For a small or mid-sized business, the simplest model lets department heads feed their own scope while everyone reads what concerns them. This is handled through configuration, without development, and since the memory lives with the company, the company holds these rules.
What comes next requires more. Having a manager approve a document before it enters the memory, giving each department its own agent with its own tools, and measuring what the agents retrieve and what they miss all call for an additional layer. These are the subjects of the next articles in this series.
An open-source repository to start your knowledge base
The three writing rules given above are collected in agent-memory-starter, a public repository under the MIT licence. It contains three record templates, for a project, a decision and a procedure, the writing conventions that let a graph read them correctly, and a script that checks each file before ingestion. It does not depend on Cognee, and the files it produces can be read by any memory engine, or by none at all, which is consistent with the idea that they belong to the company rather than to a tool.
It is the work of a single studio, built from its own projects. The templates are designed for an ordinary business, with a supplier choice, an onboarding procedure and a client account, and they were first used in-house. Feedback from those who apply them to other trades is welcome, as it was for our method for animated websites.
At Nualt, memory is part of the project
The memory described here runs for our own agents, on a studio server, with our projects inside it. Nothing it contains is specific to a development studio. Any company with procedures, decisions and clients can have the same thing, on its own server or with its hosting provider, using the AI tools it already has, and remain its owner from end to end.
What this requires is structuring the knowledge before connecting the agents, deciding who feeds the memory and who reads it, and giving managers a simple way to write into it. It is a project with a beginning and an end, like a website or an online store, and that is how we approach it. We start from what the company already knows, write it in a form an agent can retrieve, connect the tools afterwards, and at the end the company owns the result, understands it and can develop it with or without us. As with the authentication module for Medusa, what we build for ourselves serves as the basis for what we build for others.
Shared AI agent memory for businesses, your questions
The questions that come up when we present this approach to a company that already uses ChatGPT or Copilot.
How is this different from a ChatGPT or Claude project?
A project belongs to an account and a vendor. A shared memory belongs to the company, is read by all of its tools, and stays in files the company can open, export and connect elsewhere.
How is this different from classic RAG?
Classic RAG relies on vector search and retrieves passages close to the question. With a knowledge graph, an approach known as GraphRAG, the search also follows the links between facts, such as a decision, its reason, its date and its alternative. Cognee does both and chooses depending on the question.
Where is the data stored?
Wherever the company decides, whether on its own server, with its usual hosting provider or on a machine rented in its name. The source files and the memory built from them never leave that infrastructure, and no AI tool vendor has access to them.
Which documents should go in first?
The ones people explain most often, meaning the procedures used every week, the decisions whose reasons have been forgotten, and the records of current clients or projects. Around thirty well-written files are more useful than three hundred documents poured in at random.
Do you need a developer to feed the memory?
To install it and set up access rights, yes. To write in it, no, since it consists of text files with a few writing rules, those of the agent-memory-starter repository, which a department head can apply without any special tool.
