Memory Should Not Mean Saving Everything

When people ask for memory, they rarely mean that they want every word preserved forever. They want the important parts to stop disappearing. A decision. A convention. A piece of project knowledge. The explanation they should not have to repeat for the fourth time.

That distinction became central while we were building persistent memory for Open Free Max. The easy answer would have been to keep more history. The useful answer was harder: decide what deserves to become shared knowledge, and let a person remain part of that decision.

History and memory are not the same thing

A conversation can be valuable because of its context. Memory has a different job. It should help a future session begin with the right understanding without forcing the future session to replay everything that came before.

This sounds obvious until the two ideas are placed next to each other. History answers, “What happened?” Memory answers, “What should we carry forward?” A product that treats those questions as identical can either overwhelm the next session or forget the information that actually matters.

We wanted OFM to keep that difference visible. The past could remain available for reference, while durable facts could be reviewed before they became part of the project's shared understanding.

The human had to stay in the loop

The most important part of the memory work was not that the product could find information. It was that the person could review what was being proposed.

That creates a small but meaningful pause. A fact is not automatically trusted just because it appeared in a conversation. Someone can accept it, reject it, or decide that it belongs only to that moment.

This approach is slower than saving everything. It is also more honest. Project knowledge has consequences. A wrong assumption repeated across several sessions can be more damaging than a missing detail that is discovered and corrected.

Keeping the project private by default

Memory also forced us to be clear about where the knowledge lives. For OFM, local storage is not a decorative privacy statement. It is part of the product decision. The project's durable knowledge should stay with the project and the person who owns it.

That does not remove every question. People still need to understand what is being remembered and how to correct it. Privacy and clarity have to work together; one cannot compensate for the absence of the other.

What we are still learning

Good memory is not the maximum amount of information. It is the right amount of continuity.

We are still learning how much help people want when deciding what should stick. The product needs to make review feel worthwhile without turning every session into an administrative task. That balance will matter as much as the search itself.

The request hidden inside “make it remember”

When a person says that an AI should remember, they are often describing a moment of repetition. They have explained the same project rule again. They have corrected the same misunderstanding again. They have watched a new session begin with no knowledge of a decision that shaped the previous one.

The request is not always for a database. It is for recognition.

The person wants the next conversation to begin closer to where the last one ended. They want the project to feel continuous even when the tool, session, or day has changed. They want the important parts of the work to remain available without carrying the entire history in their own head.

That is a reasonable expectation. It is also a dangerous one if the product answers it by keeping everything automatically.

Keeping everything is the easiest mistake

Saving more can look like remembering more. A complete record creates the feeling that nothing will be lost. But a complete record does not tell the next session what matters, what has changed, or what should be trusted.

Imagine opening a project and receiving every conversation, every abandoned idea, every temporary guess, and every correction without distinction. The information is technically present. The understanding is not.

This is the difference between storage and memory. Storage preserves material. Memory gives material a useful place in the future. The second task requires selection, context, and sometimes the courage to leave something behind.

We wanted to build around that harder definition.

A project has several kinds of truth

Some information is durable. A naming convention, a product decision, or a recurring constraint may remain useful for months. Some information is temporary. A possible approach, a rough estimate, or an idea that was rejected may be valuable only while a specific conversation is active.

There is also information that is true but belongs to a different project. A preference from one client should not quietly become a rule for another. A decision made while exploring one product should not shape an unrelated piece of work.

This is why project scope matters. Memory that is available everywhere can become a source of confusion. A useful fact in the wrong place is not useful anymore.

The product has to preserve not only the words of a fact, but the place where that fact is allowed to matter.

The review step is a product feature

We could have hidden the decision about memory inside the system. A session could end, a summary could be generated, and the result could be treated as truth without asking anyone to look at it.

That would feel convenient in the beginning. It would also make errors harder to see.

Instead, we made review part of the experience. A proposed fact should be readable by a person. It should be possible to decide whether it is durable, whether it is accurate, and whether it belongs to the project.

This introduces a moment of friction, but it is a useful moment. It gives the person a chance to say, “Yes, this is something we should carry forward,” or “No, that was only true for that conversation.”

The difference between those two sentences is the difference between curated knowledge and automatic accumulation.

Trust is built through correction

Any memory system will eventually remember something incorrectly, incompletely, or without enough context. The question is not whether that can happen. The question is what the person can do when it does.

A memory that cannot be corrected becomes a quiet source of future mistakes. It may influence a session without announcing why. The person then has to investigate a conclusion that appears to have come from nowhere.

Correction has to be ordinary. The user should be able to change a fact, reject it, or remove it without feeling that they are fighting the system. A product that makes remembering easy but correcting difficult will eventually make people afraid of its memory.

That fear is worse than a blank session. A blank session asks for context. A wrong remembered fact can give the impression that context already exists when it does not.

The memory of a project is not the memory of a person

We also had to think about ownership. A project memory should describe the work, not silently become a profile of the person doing it.

That boundary matters for privacy and for usefulness. A personal preference may help in one context and be irrelevant in another. A decision made by a team may need to be understood as a team decision, not as a permanent trait of one individual.

The safest default is to keep the memory close to the project and clear about its source. What is this fact about? Where did it come from? Why is it being kept? Who should be able to rely on it?

These questions may seem slower than automatic personalisation. They are also the questions that make durable knowledge easier to trust.

Local is a behaviour, not only a location

Keeping memory local is important to us because it changes who is responsible for the information. The project knowledge remains with the person and the project rather than becoming an invisible part of a remote service.

But local storage on its own is not enough. People also need to understand what is stored, when it changes, and how to remove it. Privacy is not only a technical destination. It is a behaviour of the product.

That behaviour should be visible in ordinary use. The person should not have to become an investigator to understand whether a piece of knowledge was saved. They should be able to see the difference between a session history, an approved fact, and an external knowledge source.

The clearer those boundaries are, the more confidently people can use the continuity the product offers.

The problem of multiple tools

AI work rarely uses one tool forever. A person may move between different agents, different sessions, or different ways of working depending on the task. If memory belongs only to one conversation, the person has to repeat themselves each time they change tools.

That is one reason shared project knowledge matters. The knowledge should follow the project rather than being trapped inside the last interface that saw it.

At the same time, sharing does not mean flattening everything into one voice. Different tools may approach a task differently. The important thing is that the durable project facts remain understandable while the active conversation can still have its own context.

This is a balance between continuity and independence. The project should remember its decisions without forcing every session to become identical.

What should remain temporary

One of the most useful questions for a memory system is what should not be remembered.

A rough idea can be valuable while it is being explored and harmful after it has been rejected. A temporary workaround can solve an immediate problem without becoming a permanent convention. A sentence written in frustration can describe a moment without representing the team's actual decision.

The answer is not to avoid recording any of these things. History has value. The answer is to keep history and durable knowledge distinct.

This distinction gives people permission to think out loud. If every exploration becomes a permanent rule, experimentation becomes risky. People may start writing for the future system instead of solving the present problem.

Good memory should make thinking safer, not more formal.

The moment a fact becomes a commitment

A fact can change a future session. That means approving it is a small commitment, even when the interface makes it look like a simple click.

We wanted that commitment to remain understandable. The person should know what will happen if the fact is accepted. It will become available as project knowledge. It may shape the next answer. It may prevent the same explanation from being requested again.

That is useful when the fact is right. It is why the review step matters so much when the fact is wrong.

The product is not only helping the agent remember. It is helping the person decide what the project is allowed to remember about itself.

Why search is only half the experience

Finding information is an important part of memory, but search alone does not create understanding. A search result can show where a phrase appeared. It may not tell you whether the idea was adopted, questioned, or replaced later.

That is why the experience needs both retrieval and curation. Retrieval helps a person return to the past. Curation helps the person shape what the future should inherit.

If a system offers only search, the user becomes responsible for turning every result into a decision manually. If it offers only automatic facts, the user loses the ability to inspect the path that produced them.

The two modes need each other.

What memory changes about returning to work

Returning to a project after a pause can feel like arriving in a room where everyone has left notes on the table. Some notes are essential. Some are outdated. Some are addressed to a problem that no longer exists.

The goal of memory is not to remove the room's history. It is to make the important notes easier to recognise.

That can change the first few minutes of a session. Instead of repeating the project's basic constraints, the person can begin with the question that is actually current. Instead of explaining why a decision was made, they can review the decision and decide whether it still holds.

The benefit is not only speed. It is a better quality of attention. The person can spend the beginning of the session thinking about the next problem rather than proving the past to the tool.

A memory system has to accept forgetting

Forgetting is not always a defect. Projects change. People change their minds. A decision that was correct last month may be replaced by a better one this month.

If a memory system treats every stored fact as permanent, it turns progress into contradiction. The project moves forward, but the system continues to present the past as if it were current.

We need memory to have a relationship with time. A fact should have context, and the product should make it possible to recognise when that context has changed. Not every piece of knowledge needs an expiry date, but every piece of knowledge should be allowed to become outdated.

This is another reason human review matters. A person can notice a change in meaning before a purely automatic process does.

What we want to avoid

We do not want a memory system that makes people wonder what it knows about them. We do not want facts to appear in a project without a clear origin. We do not want a wrong decision to gain authority simply because it has been repeated.

We do not want privacy to be explained only in a policy page while the product behaves like a black box. We do not want users to choose between useful continuity and control over their own knowledge.

These boundaries may make the experience less magical. They also make it more respectful.

The lesson beyond AI

The memory problem is not unique to AI. Teams have always struggled with the difference between documentation and understanding. A folder can contain the history of a project without helping a new person understand which decisions still matter.

What AI changes is the speed at which this confusion can spread. A new session can act on a remembered assumption immediately. That makes good project knowledge more valuable and bad project knowledge more urgent to correct.

The product therefore has a responsibility to make the difference visible. It should not use the word memory to hide a large collection of text. It should make the idea concrete enough that a person can decide whether it deserves trust.

The question we are carrying forward

We started with a desire to stop repeating ourselves. We ended up with a deeper question: what should a project be allowed to carry into the future?

The answer will not be the same for every project or every person. That is why we are building memory around review, scope, local ownership, and correction rather than around the promise to save everything.

Good memory is not a louder past. It is a more useful future.

We are still learning how to make that future feel light enough to use and trustworthy enough to matter. The work continues at the boundary between convenience and responsibility, which is exactly where a memory product should be built.

The smallest useful memory may be the best one

There is a natural temptation to measure a memory system by how much it can retain. A larger history can look like a more capable product. But the user does not experience memory as a storage capacity. They experience it when a future moment becomes easier or harder because of what was kept.

A single well-chosen project decision can be more useful than thousands of unfiltered lines. It can save a repeated explanation, prevent a wrong turn, or remind a new session of a constraint that would otherwise be missed.

This changes the way we think about progress. We do not need the memory area to grow endlessly. We need the quality of the retained knowledge to improve. Sometimes that means adding a fact. Sometimes it means removing one. Sometimes it means deciding that the history is enough and nothing should be promoted.

Restraint is part of the feature.

A good memory should make people more curious

The best outcome is not that a person stops looking at the past. It is that they can look at it with better questions. Why did we choose this? Is the decision still valid? Which assumption changed? What should the next session know before it begins?

Memory should support that curiosity rather than close it down with an automatic answer. A remembered fact is a starting point for better work, not an authority that ends the conversation.

That is the standard we are carrying forward. Keep enough continuity to make the next step easier, but leave enough space for the project to change its mind.

The future should remain editable

Projects are living things. Their knowledge should be durable enough to help and flexible enough to change. If a person cannot revise what the system carries forward, continuity becomes a prison built from old decisions.

That is why the memory experience has to treat correction as normal rather than exceptional. The future is not a fixed archive. It is the project continuing to decide what it believes.

That may be the most important difference between a memory feature and a permanent record. A record looks backward. Project memory has to stay available to change, because the work itself is still moving.

That is the kind of continuity we want to build.

Useful, local, and open to correction.

It should make tomorrow's work clearer without pretending that yesterday's decisions can never change.