Every Project Needed Its Own Memory

The word “memory” can make a product sound more intelligent than it is.

It suggests that the system understands what mattered, knows what to keep, and can bring the right thing back at the right moment. That is a powerful promise. It is also a dangerous one when the person is working across several projects that should not be confused with one another.

Open Free Max had already learned that memory should not mean saving everything. The next lesson was more specific: even useful memory needs a home.

On July 28, we were looking at the way project work was becoming more persistent. People were not returning to one universal stream of activity. They were moving between separate bodies of work, each with its own vocabulary, decisions, constraints, and unfinished questions. A fact that was valuable in one project could be irrelevant, or actively misleading, in another.

The challenge was therefore not only remembering.

It was keeping meaning attached to place.

A busy person does not have one context

The idea of a single personal memory is appealing because it sounds convenient. One place to remember preferences. One place to keep the things that have been learned. One place to make every future session smarter.

Real work is less tidy.

A person may be building a product while writing about it, managing a client engagement, researching a new opportunity, and maintaining a private collection of ideas. These projects can influence one another, but they are not the same project. They have different audiences. They may have different standards of confidentiality. They may use different words for similar concepts.

When all of that is treated as one undifferentiated memory, the product gains breadth and loses precision. The system may remember a fact but lose the reason the fact mattered. It may carry a preference into a place where the preference does not belong. It may make a suggestion feel plausible simply because it was true somewhere else.

The person then has to become the filter.

That is exactly the burden memory was supposed to reduce.

The first distinction was between knowing and belonging

A piece of information can be correct and still be wrong for the current project.

That sounds like a small distinction, but it changes the design of a knowledge system. Correctness is not the only question. Relevance depends on where the information was learned, what it was meant to guide, and whether the conditions around it still exist.

Project memory gave us a way to keep those questions visible.

When knowledge belongs to a project, its meaning is easier to inspect. The person can ask whether it still reflects the project’s direction. They can understand why it is available. They can distinguish a local decision from a general working preference. The project becomes more than a container for files; it becomes a context in which remembered information can be interpreted.

This does not make the information automatically correct. It makes the boundary around the information more honest.

That honesty mattered to us because AI systems are very good at making context feel seamless. Seamlessness is attractive until the wrong context crosses an invisible line.

We considered one shared memory first

The single-memory approach had obvious advantages.

It could feel effortless. A person would not need to think about where a new fact belonged. Useful knowledge could accumulate in one place. The product could present a unified picture of the person’s work, and the person would not have to maintain several separate collections.

For a person with one dominant project, that might be enough. For someone working across many projects, the simplicity would be misleading.

The shared approach also made it difficult to explain unexpected behaviour. If a remembered preference appeared in a new context, was that because it was personal, because it belonged to an older project, or because the system guessed that the two projects were related? A single pool hid the answer.

We could have added labels and filters around the shared pool. That would have recovered some of the missing meaning, but it would have created another problem: the person would have to manage the separation after the fact. The boundary would exist in the interface while remaining absent from the way memory was originally formed.

We chose to start with a stronger boundary instead.

A project boundary is a form of respect

Separating memory by project is not only an organisational choice.

It respects the fact that a person’s work can contain different relationships, responsibilities, and kinds of truth. A draft for one audience should not automatically inherit the assumptions of another. A product decision should not be treated like a personal preference. A temporary experiment should not quietly become the rule for everything that follows.

The boundary gives each project the chance to develop its own understanding.

That is especially important for people who create across formats. A creator may have one project for a public editorial series and another for early research. A vibe coder may move between several applications with different goals and voices. A freelancer may have multiple client contexts that must remain distinct even when the tools used to work on them are similar.

The work is connected because one person is doing it. It is separated because the meaning is different.

The product has to support both truths at once.

Local memory made return possible without blending

The value of project memory becomes clearest when someone returns after a pause.

Without memory, the person may have to reconstruct the project from files, old conversations, and personal recollection. With one shared memory, they may find a lot of context, but not necessarily the context that belongs to this particular project. With project memory, the return can begin closer to the work itself.

That does not mean the system knows the next action. It means the person does not have to start by proving which project they are in.

The project provides the frame. Within that frame, remembered knowledge can be reviewed, corrected, and used as a starting point for the next session. The person remains able to notice when the project has changed and when an old assumption no longer deserves to travel forward.

This is a quieter form of continuity than simply replaying a transcript. It aims to preserve orientation rather than volume.

The difference matters because returning to work is not the same as reopening a record. A record tells us what was said. Orientation helps us understand what we are doing now.

Keeping memory local also kept mistakes local

Every memory system has a failure mode.

One failure is forgetting something important. Another is remembering something with too much confidence. In a multi-project environment, the second failure can spread quickly if the product does not respect boundaries.

A mistaken assumption inside one project is still a problem. But if the assumption is treated as a universal truth, it can shape unrelated work before anyone notices. Local memory does not eliminate mistakes. It narrows their reach and makes their origin easier to question.

That was an important trade-off. A global system might produce more apparent continuity because more information is always available. A project system may require a little more intentionality, but it gives the person a better chance to understand what they are seeing.

We preferred the boundary because trust is not only about how much a product remembers. It is also about whether the product can show why a memory is relevant.

This is one of the reasons we avoid presenting persistence as magic. Memory should be useful enough to help and visible enough to challenge.

The product had to make separation feel natural

A boundary can protect people and still feel like a tax if the product makes them manage it constantly.

We did not want project memory to become a filing job. The person should not have to stop at every moment of work to decide which conceptual shelf a thought belongs on. The project context should do some of the orienting simply by being the place where the work is happening.

That requires restraint. A product can explain too much, expose too many categories, and make a helpful idea feel like a form. It can also hide so much that the person cannot tell what is being carried forward.

The useful middle is a clear project boundary with a human-readable understanding of what it contains. The system should make the local context available without claiming that the local context is complete. It should help the person inspect what has become durable without pretending that a saved item has earned permanent authority.

We are still refining that balance. The principle is clearer than every expression of it: separation should reduce cognitive work, not create a second job.

Memory and a project are not the same thing

Another lesson was that project memory cannot stand in for the project itself.

A project includes files, conversations, decisions, people, deadlines, experiments, and things that have not yet been understood. Memory captures only a selection. It can improve orientation, but it cannot become the entire landscape.

This matters because a compact remembered summary can feel more definitive than the messy work from which it came. The product must leave room for the person to go back to the underlying material. A memory can point toward the work. It should not replace the work.

The distinction also keeps the product from overselling what persistence can do. The aim is not to create an artificial project manager that decides what matters. The aim is to preserve useful project knowledge so that the person can make the next decision with less unnecessary reconstruction.

The person’s judgement is still the centre of the process.

That may sound less futuristic than automatic understanding. It is also a better foundation for work that changes every day.

What this means for people using OFM

For people using Open Free Max across several projects, the practical promise is simple: one project’s remembered context should not casually become another project’s context.

That means a return to a project can feel more grounded. The person can pick up the vocabulary and decisions that belong there, while keeping other work at a respectful distance. The separation is useful whether the projects are technical, editorial, commercial, creative, or some combination of those things.

It also gives people a better way to think about their own work. A general preference can remain part of their personal method. A project decision can remain part of the project. The product does not need to flatten those two kinds of knowledge into one large profile.

The result is not a promise that the assistant will always know what matters. It is a promise that the context has a chance to remain attached to the place that gives it meaning.

That is a more modest promise, and a more useful one.

The unresolved question is how much separation is enough

Projects are not sealed rooms.

They overlap. A person may deliberately carry a lesson from one project into another. A creative practice may inform a product decision. A client workflow may inspire a general habit. If project memory is too isolated, it can make valuable connections harder to preserve.

This is the tension we are carrying forward. Separation protects meaning, but connection creates learning. The product needs to support deliberate movement between the two without making every piece of knowledge global by default.

We do not want to solve this by making the boundaries invisible. Invisible sharing may feel convenient until it becomes impossible to explain. We would rather make the person’s choice clear when knowledge genuinely needs to travel.

The next work is therefore not simply “more memory.” It is better movement between local and general understanding. What should remain with a project? What has become a durable part of a person’s method? What is still an experiment and should not be promoted at all?

Those questions will remain important as OFM grows beyond a single kind of workflow.

The project became the unit of trust

Before this work, it was easy to think of a project as the place where files lived and sessions happened. Memory made that definition feel too small.

A project is also the unit in which context earns trust.

The person can return to it, inspect what has been carried forward, and decide whether the remembered understanding still describes the work. That relationship gives persistence a boundary and gives the boundary a purpose. It is not separation for the sake of neatness; it is separation so that meaning can be questioned in the right place.

This changed how we see the broader product. OFM is not only a way to open several tools. It is becoming a way to keep several bodies of work understandable while they evolve. The tools may vary. The projects may overlap. The person still needs to know what belongs where.

That is the kind of structure that can support advanced users without forcing them into a rigid method.

Every project is allowed to be different

The word memory can make a feature sound more complete than it is. People may hear it and imagine a system that knows the entire history of a project, understands every decision, and can reproduce the past on demand. That is not the promise we want to make. A project's context is always partial. It is shaped by what someone chose to keep, what they forgot, and what has changed since the last time they looked.

The boundary between projects helps us be honest about that partiality. If a remembered detail appears inside the project where it was created, the person can evaluate it against the work in front of them. They can decide whether it still applies. If the same detail appears everywhere, its presence may feel like authority even when it is only an old assumption.

This matters when one person carries several roles. The language used for a client project may not belong in a personal experiment. A decision made while exploring a new idea may be useful there and distracting elsewhere. A content workflow may have its own standards, while a coding workflow has another pace and vocabulary. The more active projects someone has, the more important it becomes to keep these differences legible.

Local memory is therefore not only a technical boundary. It is a way of respecting the shape of a person's attention. The product should not force someone to remember which context is active every time a useful piece of information appears. It should give the project a reasonable home and allow the person to move information deliberately when it truly belongs somewhere else.

There is still a difficult design question here. Some knowledge is genuinely shared. A person may have a preferred way of starting work, a common writing standard, or a repeated decision that applies across many projects. Keeping all of that local would create unnecessary duplication. Sharing everything would blur the very distinctions that make memory useful. We do not have a final answer, and we do not want to hide the tension behind a single setting.

The product will have to help people notice the difference between a project memory and a personal working preference. Those categories may overlap, but they should not be confused. One describes what this work has learned. The other describes how a person often approaches work. The first belongs close to the project. The second may travel, if the person chooses it.

That is why this release is a foundation rather than a finished theory of memory. It gives us a clear unit to protect and a clear question to keep asking: when should context travel, and who should decide?

For users, the immediate benefit is simpler. Opening one project should not quietly bring the unfinished assumptions of five others into the room. The workspace can become more helpful without becoming more intrusive. It can remember enough to make continuation possible while keeping the source of that memory understandable.

Every project needed its own memory because every project had its own meaning.

The most useful conclusion is also the simplest.

Every project deserves the chance to remember itself.

Not because every project is completely separate, and not because a product should make people build walls around every idea. It deserves that chance because context is part of meaning. When knowledge has a place, the person can understand it, challenge it, and decide whether it should travel.

The memory work on July 28 was a continuation of a larger effort to make returning to work less expensive. It taught us that continuity cannot be built from accumulation alone. It needs boundaries, and those boundaries need to remain legible to the people who rely on them.

We will keep learning where the connections should be. For now, we are building from a clear principle: a project should not have to share its memory with every other thing a person is trying to do.

The work may belong to one person. The context belongs somewhere more specific.

That distinction becomes especially important when a person has several projects that look similar from the outside. The same kind of task can carry a different vocabulary, a different history, and a different definition of a useful result. If those differences disappear, the product may appear helpful while quietly making the person spend more time checking whether the context is trustworthy.

Project memory is therefore less about making a larger archive and more about making a clearer relationship. A person should be able to recognise why a piece of knowledge is present, what work it belongs to, and whether it still deserves attention. The memory should feel like part of the project’s character, not like a pile of leftovers from every other activity.

We are still learning how much structure is enough. Too little separation makes context vague. Too much separation can make a person feel that every connection requires paperwork. The useful middle is a boundary that is present when it matters and quiet when it does not.