The Day Memory Became a Promise

Memory is one of those words that makes a product sound more intelligent before anyone has decided what the product should remember.

It is also one of the easiest words to misuse.

When we began working on persistent memory for Open Free Max, the obvious question was how to keep information between sessions. The more important question came later: what would a person reasonably expect us to mean when we said the product had memory?

Would it remember everything? Would it remember only what someone chose? Would it remember a project, an account, a session, or a particular way of working? Would the memory be useful when the work changed? Would it become an invisible accumulation that made every future interaction harder to understand?

On June 25, memory became part of OFM’s product promise. The release included persistent local memory for projects, a memory panel, a way to distill the last session, a way to make memory available to an agent, and the ability to bring relevant memory into work across different AI tools.

Those capabilities sound like a feature list. The story behind them is about restraint.

We were not trying to build a perfect record of a person’s work. We were trying to make returning to a project less like meeting a stranger.

The blank session was a recurring cost

A new session has a certain clean simplicity. There is no baggage. The user can state the task, the assistant can respond, and the interaction can begin.

That simplicity breaks down when a project lasts longer than one conversation.

Projects accumulate decisions. A direction is chosen and later refined. A convention is established. A problem is investigated and temporarily set aside. A content system gains a voice. A product acquires boundaries. None of those things is necessarily a formal specification, but they all affect what a useful next step looks like.

Without continuity, the person becomes the bridge between every session. They remember what matters, repeat it, correct the assistant, and decide how much background to include again. Sometimes they keep notes elsewhere. Sometimes they search through old conversations. Sometimes they accept that a new session will spend its first part rediscovering the project.

That work is not always visible as frustration. It can look like normal prompting. But repetition has a cost, especially for people managing several projects at once. The more contexts a person carries, the more they need a reliable way to return to the one in front of them.

Memory became interesting because it could reduce that cost.

It became difficult because reducing the cost did not mean keeping everything.

The first instinct was to save more

Whenever a product lacks context, the easiest answer to imagine is more context.

Save the conversation. Save the files. Save the decisions. Save the preferences. Save the history. Make the next session aware of the whole story and let the system sort it out later.

That instinct has a seductive logic. If something might be useful, keeping it seems safer than losing it. Storage is cheap. Retrieval can be improved. More information appears to create more possibilities.

But a project is not improved by becoming a warehouse.

An undifferentiated memory makes the person responsible for sorting the product’s past. Old assumptions sit beside current decisions. Temporary questions look like permanent direction. A discarded idea can return with the authority of a rule simply because it survived longer than the conversation in which it was created.

The problem is not only volume. It is meaning.

Memory is useful when a person can recognise why it exists and decide whether it still applies. That pushed us away from a design based on automatic accumulation and toward one based on visible, project-level context.

The product had to remember with a reason.

A project needed its own memory

The project boundary became central.

People do not want one undifferentiated memory following them from a client engagement to a personal experiment, from a content system to a private research project. The contexts may share tools, but they do not share the same assumptions or permissions.

Giving each project its own memory was a way to respect that difference. It said that the context belongs with the work it explains. It also made the concept easier to understand. A person could ask, “What should this project remember?” rather than confronting an abstract question about everything the product knows.

Project-level memory is not a claim that projects are perfectly isolated in every human sense. People still carry ideas between them. A creator may learn something in one project and intentionally reuse it in another. But the product should not assume that transfer is always wanted.

This was an important boundary for OFM. Memory should support the user’s organisation of context, not quietly reorganise it on their behalf.

The project became a home for memory because it was already a meaningful unit of work.

The memory panel made an invisible promise visible

Persistent memory becomes uncomfortable when a user cannot see what is being retained.

The memory panel was therefore more than a place to display content. It was a statement about visibility and control. If memory affects future work, the person should have a way to encounter it as something concrete rather than as an invisible force shaping every answer.

That changes the emotional character of the feature. The user does not have to trust a mysterious background process. They can inspect the project’s remembered context and decide whether it still represents the work. The product can be useful without asking the user to surrender authorship of the project’s identity.

We were careful not to treat the panel as a complete explanation of intelligence. It is not a window into every internal decision an assistant may make. It is a practical surface for the memory OFM is choosing to make available as project context.

That distinction keeps the interface honest. A memory panel should not imply total transparency where total transparency is impossible. It should provide useful visibility into the part of continuity the user can actually review and shape.

Making memory visible also creates a responsibility for the language around it. Labels have to be understandable. Actions have to communicate their consequence. The person should not wonder whether they are editing a note, changing a project rule, or deleting an entire history.

Those details are not separate from the memory feature. They are the feature’s relationship with the user.

Distilling the last session was a choice about meaning

The idea of distilling a session changed the centre of gravity again.

A session can contain a lot of activity and very little durable meaning. There may be exploratory questions, false starts, temporary explanations, and repeated attempts to find the right direction. If the entire session is treated as memory, the product preserves noise alongside insight.

Distillation asks a different question: what should survive from this work?

The word matters because it implies judgement. A distilled memory is not a transcript compressed until it is smaller. It is an attempt to identify the decisions, facts, and orientation that might help the next session begin more intelligently.

That judgement cannot be perfect. A detail that seems temporary today may matter next week. A choice that felt central may be reversed. The product should therefore make distillation a useful aid, not an authority that closes the question.

The user remains the person who knows whether the remembered version is faithful enough.

This is also why memory work is connected to writing. A project’s durable context needs to be expressed in words that can guide future work without turning every future interaction into a long preamble. The act of distilling is partly an editorial act: decide what the project is trying to protect from being forgotten.

Memory had to be available where work happened

A project can have useful memory and still feel forgetful if the memory is trapped in one place.

Open Free Max works across different AI tools and sessions. People may change the tool they use without changing the project they are working on. If project context only helped in one narrow path, continuity would remain fragile. The memory would exist, but the person would have to remember where it was available.

That led to the idea that relevant project memory should be able to inform work across the supported tools. The product’s promise was not loyalty to one conversation window. It was continuity around the project.

This is a subtle difference. A product can try to make itself indispensable by keeping context locked inside its own experience. Or it can make context useful enough that the person can move through their working system without starting from zero each time.

We prefer the second direction, even though it asks more of the design. Context should travel according to the user’s project, not according to a single interface’s desire to own the whole interaction.

That does not mean every memory belongs everywhere. Relevance and user control still matter. It means the default question became: how can we preserve the project’s thread when the surrounding tool changes?

The hardest part was deciding what not to remember

The feature became clearer when we wrote down the things it should not pretend to be.

It should not be an exhaustive diary. It should not be a hidden profile assembled from every interaction. It should not make temporary uncertainty permanent. It should not blur the boundaries between projects. It should not make the user afraid to explore because every experiment might become part of the project’s identity.

Those limits are not marketing copy. They are design constraints.

They also protect the creative side of AI work. People need to be able to try an idea, reject it, and move on. If memory only ever grows, exploration becomes expensive. The product needs a way to distinguish between what was considered and what was chosen, even if that distinction sometimes remains imperfect.

We are still learning how much structure is helpful. Too little structure leaves the user with a pile of notes. Too much structure turns memory into administration. The right answer may vary by project and by person.

The important thing is that the product should make the trade-off visible instead of hiding it behind the word “memory.”

What worked, and what remains uncertain

Persistent local, per-project memory gave OFM a stronger foundation for continuity. The memory panel gave the concept a visible home. Distillation made it possible to think about durable meaning rather than raw history. Making memory available across supported tools moved the promise closer to the way people actually work.

Those are meaningful steps, but they do not prove that every memory will be useful. We still have open questions about timing, editing, relevance, and the amount of context that helps rather than distracts. A project can change quickly. A memory can be accurate and still be wrong for the task in front of someone.

There is also a human question. Some people want the product to remember as much as possible. Others want to decide each time. A single default will not satisfy everyone. The experience has to communicate enough for different users to understand what kind of control they have.

We would rather acknowledge those differences than describe memory as a solved problem.

The release gave us a foundation for learning in the open.

What this means for users

For OFM users, the promise of memory is not that the application knows their whole history.

It is that a project can carry forward selected context so the next session has somewhere to begin. The memory is connected to the project, visible enough to inspect, and intended to support work across the tools that belong to that project.

That can matter when a person is moving between client work, content production, product experiments, and personal systems. Each project can retain its own orientation instead of forcing the user to keep every distinction in their head.

The user still decides what deserves to remain. The product’s role is to make that decision easier and to make the result useful when work resumes.

Memory should reduce repetition without reducing agency.

The project should not have to repeat its identity

There is a difference between repeating a task and repeating the identity of the work around that task. A person may be happy to explain the new question they have today. They are less likely to want to restate the project’s purpose, constraints, vocabulary, and decisions every time an assistant joins the conversation.

That identity is often distributed across small signals. The name of the project suggests one thing. A previous decision rules out another. A writing style has been chosen. A technical direction has been narrowed. A client-facing promise has been made. None of these details needs to become a permanent commandment, but together they form the atmosphere in which useful work can happen.

Persistent project memory gives those signals somewhere to live. It lets the next session begin with a little less ceremony, while leaving room for the person to change direction. That combination is important. Continuity should not turn the past into a contract the present is forbidden to revise.

The product is most useful when it carries orientation forward and lets decisions remain decisions.

Memory is also a question of ownership

The word “local” matters in this story because it points toward a different relationship with context. Project memory is not only something the product provides. It is part of the working material a person is trying to organise and protect.

That raises questions we want to keep visible. Who decides what belongs in the memory? How easy is it to correct an outdated idea? What happens when two parts of a project pull in different directions? How should a person understand what may be used in a future session or with another supported tool?

These are not questions to answer with a decorative privacy statement. They belong in the experience. The more useful memory becomes, the more important it is that the user can recognise its boundaries. A person should be able to make an informed choice about what continuity means for their project.

That is why the memory panel, the project boundary, and the act of distilling matter together. They make memory something the user can relate to as working context, rather than a mysterious accumulation happening somewhere outside their view.

We are still learning how to make that ownership feel natural. The direction is clear: memory should belong to the work and remain legible to the person doing it.

The next question is whether memory can stay alive

The June 25 decision answered one question: should OFM remember useful project context beyond a single session?

Yes, but remembering is only the beginning.

The next question is how memory changes as the project changes. How should an old direction be retired? How should a new decision replace a previous one? When should a person be reminded that a memory may no longer apply? How can a product preserve continuity without quietly accumulating contradictions?

Those questions make memory less like a storage feature and more like a relationship with the project. A relationship needs maintenance, but it should not demand constant attention. The product has to help at the moments when maintenance is useful and stay out of the way when the work is moving.

That is the promise we are trying to keep.

We are not building a machine that remembers everything about a person.

We are building a workspace that should remember enough of a project for the next chapter to feel connected to the last one.

That promise has a practical consequence for the person using OFM. They should not have to wonder whether continuity came from a decision they made or from a system that quietly collected everything around them. Trust grows when the boundary is understandable. A person can then decide what deserves to stay close to the project and what should remain outside it.

Memory also changes the meaning of a return. Without it, reopening a project can feel like arriving at a room after someone has removed all the labels. With too much of it, the room becomes crowded with objects whose purpose is no longer clear. The useful version is more modest: the next visit starts with enough orientation to make a good decision.

That is why the work is not finished when memory exists. We still have to learn how people want to review it, correct it, and let it evolve. A project is not a frozen document. Its important knowledge changes as the work changes. The memory has to be capable of belonging to that movement without trying to control it.

The question we are carrying forward is simple to state and difficult to answer: what is the smallest amount of remembered context that makes a project feel alive again? The answer will not be identical for every kind of work, but the responsibility remains the same. Remember enough to help. Leave enough space for the person to decide.

The promise also has a time dimension. Useful memory should help on the next visit, but it should not assume that the person will always want to return in the same way. A project can move from exploration to delivery, from private experiment to shared work, or from an active priority to something that is simply worth keeping. The meaning of remembered context changes with those transitions.

That is why we are treating memory as part of the relationship between a person and a project rather than as a permanent record. The project should become easier to recognise without becoming impossible to change. Continuity should lower the cost of returning, not raise the cost of starting again when a new direction is the right one.

We are still early in learning this balance. The important decision was to take the user’s sense of ownership seriously. A memory that helps is one the person can understand, question, and shape. Everything else is accumulation pretending to be care.