More AI Tools Created a New Problem: Continuity

More choice sounds like progress.

For people using AI seriously, it often is. Different tools have different strengths. One may fit a coding task. Another may be better for a particular kind of reasoning. A third may already be part of a person’s established routine. The more varied the work becomes, the less realistic it is to expect one tool to be the answer to everything.

That was part of the reason Open Free Max kept expanding its support for AI tools and command-line workflows.

Then the shape of the problem changed.

Supporting another tool did not only mean making another option available. It meant accepting that the person’s work could begin in one place, continue in another, and return later through a third. The product could no longer think about a session as a single, sealed encounter. It had to think about the thread that travelled through the encounters.

On July 28, continuity became the question in front of us. Not the continuity of a marketing promise, and not the continuity of a particular technical implementation. The practical continuity of work: what lets a person come back without feeling that they have to reconstruct the last hour before they can make the next decision?

Choice creates a cost that is easy to hide

People rarely experience tool choice as a clean list of benefits.

They experience it in transitions. A thought begins in one interface. A useful result is produced somewhere else. A decision is made in a third place, perhaps without being written down in a way that the next session can understand. The person becomes the bridge between the tools.

That bridge can carry a lot at first. Experienced users develop habits. They remember what they were doing. They copy what matters. They keep notes. They know that changing tools can mean changing the shape of the context as well.

But the cost accumulates.

Every transition asks the person to answer a few hidden questions: What was I trying to accomplish? What has already been decided? Which part is unfinished? Which assumptions were temporary? What should the next tool know, and what would be noise?

These questions are part of the work, but they should not all be repeated merely because the chosen tool changed.

The broader our support became, the more visible this cost was to us. A collection of capable integrations could still feel fragmented if it did not help the person preserve the shape of the work.

We had to separate tool choice from project identity

One possible response would have been to choose a single preferred tool and make everything revolve around it. That would simplify the product story. It would also ignore how advanced users actually work.

A person can have a project identity that outlasts the tool used in any one session. The project has an objective, a vocabulary, decisions, constraints, and open questions. The tool is a participant in the work, not the owner of the work.

That distinction became important as we considered continuity. If the project belongs to one tool, changing tools feels like starting over. If the project remains the stable place, tools can become different ways of moving through it.

We did not want OFM to force people to choose a permanent allegiance before they knew which workflow fit a particular task. The product had to let people use the tools they preferred while keeping the work recognisable as the same work.

This is a deceptively difficult product boundary. It asks us to give the person freedom at the tool level while providing stability at the project level. Too much freedom creates fragmentation. Too much stability creates a new form of lock-in.

The useful answer had to live between those extremes.

The first lesson was that launching is not continuing

It is relatively easy to celebrate the moment an AI session starts.

There is a visible action. A provider is chosen. A project is opened. The person asks the first question. The interface has a clear beginning.

Continuing is quieter.

Continuing means the next session understands why the previous one mattered. It means an interrupted task does not lose its shape. It means moving between tools does not require the person to become a human export format. It means the product can acknowledge that a project is not a sequence of isolated launches but a long-running line of attention.

This changed the way we evaluated features. “Can this tool start?” was no longer sufficient. We also had to ask, “What happens when the person returns?” and “What happens when the person chooses a different tool?”

Those questions do not always produce a new visible feature. Sometimes they change the way a feature is framed. A provider is not just a destination. A session is not just a window. A project is not just a folder.

The language we use influences the experience we build.

We considered making every transition explicit

One path was to ask people to consciously manage every handoff. They could label the current state, summarise the work, select what should carry forward, and confirm the next destination.

There is value in explicitness. A deliberate handoff can prevent important context from disappearing. It can also make responsibility visible. When a person decides what continues, they can notice what has changed.

But an entirely explicit system would put the continuity burden back on the person. It would turn every transition into a small administrative ceremony. That might be acceptable for carefully planned work; it would be exhausting for ordinary movement between sessions.

The opposite path was to hide every transition and make the product infer the thread automatically. That would feel smoother when the inference was right. It would become unsettling when the product carried forward the wrong assumptions without showing the person what had happened.

Neither extreme matched the way we wanted OFM to behave.

The product needed to preserve continuity while leaving enough of the decision visible to remain trustworthy.

The second lesson was that continuity needs levels

Not everything from an earlier session deserves to travel into the next one.

This sounds similar to the distinction between history and memory, but the multi-tool problem gave it a different urgency. Continuity is not a demand to preserve everything. It is a demand to preserve the parts of the work that make the next step intelligible.

Sometimes that is a decision. Sometimes it is an unresolved question. Sometimes it is the current direction of a project. Sometimes it is simply knowing where the last session stopped.

The right amount depends on the moment.

A product that carries too little makes the person repeat themselves. A product that carries too much makes the next tool inherit a cloud of context that may no longer be relevant. The work becomes harder to see because the past has been allowed to stand too close to the present.

We are still learning how to keep those levels distinct. The important change was recognising that continuity should be designed, not assumed. It is a product behaviour with trade-offs, not a background property that automatically improves when more information is retained.

More providers changed our definition of compatibility

Compatibility can mean that a tool launches successfully. That is the narrow definition.

The broader definition asks whether the tool fits the person’s ongoing work. Can they recognise the project? Can they return to a meaningful point? Can they use a different provider without losing the context that matters? Can the product remain understandable when the underlying capabilities vary?

The second definition is more demanding because it includes the human experience around the integration. It also prevents us from treating every supported tool as a separate island. A new provider should expand a person’s options without making the rest of their workflow less coherent.

This is where product work becomes less about adding a list of names and more about building a common sense of place. The details of the tools can differ. The person should still know where they are, what they are working on, and what is next.

We did not want to hide meaningful differences between tools. We wanted to stop those differences from forcing a complete reset of the project’s identity.

What we deliberately did not promise

Continuity is a useful word, but it can become too generous if left undefined.

We are not promising that every tool will produce the same result. We are not promising that a session can move between providers without any adaptation. We are not promising that the product can infer the person’s intention perfectly. Different tools have different behaviours, and the person remains the one who decides whether the next step is right.

We are also not pretending that a unified workspace eliminates the need for good project habits. Clear decisions are still easier to carry than vague ones. A well-defined next step is still easier to resume than an unresolved cloud of possibilities. Product support can reduce the burden, but it cannot make ambiguity disappear.

That honesty protects the feature. If continuity means “the product will remember everything and make every transition invisible,” it will disappoint. If it means “the project can remain a recognisable thread while the person chooses how to work,” it becomes a standard we can actually pursue.

The second version is less magical. It is more useful.

What this means for people using OFM

For users, the benefit of supporting several AI tools should not be measured only by how many tools appear in a menu.

The real benefit is the ability to choose the right tool for the moment without making the project feel like a different project each time. A person can explore with one tool, continue with another, and return later with more of the work still visible as one connected effort.

That does not remove judgement from the workflow. It gives judgement a better place to operate. Instead of spending the first part of every transition reconstructing the past, the person can decide what the past means for the next step.

This matters for people with several active projects because continuity is rarely linear. A creator may move between a content system, a product idea, and a client engagement in one day. A builder may move from research to implementation to communication. A person working across many tools needs a stable sense of project without needing a single narrow path through it.

OFM is becoming a place for that kind of movement.

The product question moved from “which tool?” to “what carries?”

When we began, the natural question around AI integrations was which tool to support next. That question is still useful. It helps us understand where people want to work and what kinds of workflows they are bringing into the product.

The continuity work added another question that is now just as important: what should carry across the choice?

The answer may be a project’s identity. It may be a decision made in a previous session. It may be a clear next step. It may be the knowledge a person intentionally kept because they knew it would matter later. The answer should not be a random accumulation of everything that has happened.

This way of thinking gives us a better filter for future work. When a feature makes another tool available, we can ask whether it strengthens the thread of the person’s work or merely adds another destination. Both may have value, but they solve different problems.

We are interested in the second problem now because the first one is no longer enough.

Continuity is a promise we have to earn repeatedly

A person does not experience continuity once. They experience it at every return.

The first return may be easy. The fifth reveals whether the system truly understands the shape of the work. The difficult cases are not the clean handoffs. They are the interrupted sessions, the changed priorities, the tool that behaves differently, and the project that has grown beyond the assumptions with which it began.

Those cases are where a product’s promises become concrete.

We are treating the work as an ongoing learning loop. Add support for a useful tool. Observe where the thread breaks. Improve the project-level experience. Make the next transition clearer. Then repeat without assuming that a larger collection of integrations automatically means a better workspace.

The open question is how much continuity should be visible and how much should feel effortless. We want people to trust that the work has not vanished, while still giving them the ability to correct the direction. That balance will not be solved by one release.

It will be earned by the quality of each return.

The work continues after the tool changes

This distinction became important because the first version of the problem was easy to describe incorrectly. It sounded like a comparison problem: which tool is best for this task? In practice, many people are not choosing one tool once. They are moving through a working day in which different tools become useful at different moments. The question is less like choosing a permanent home and more like moving between rooms while trying not to lose the conversation.

That movement creates several kinds of interruption. A person may pause because a provider is unavailable, because a project needs a different kind of help, or simply because another tool feels better suited to the next question. They may return later with a different expectation of what should happen. If the workspace treats every transition as a fresh beginning, the person has to spend energy rebuilding the bridge each time.

We considered whether the simplest answer was to choose a preferred path and make the alternatives secondary. That would have reduced some product decisions. It would also have contradicted the reason people were coming to OFM: they wanted more control over how their work moved. A workspace that claims to support choice cannot make choice feel like a mistake.

The other option was to make every tool behave exactly alike. That would have created a neat story, but it would have asked different tools to give up the qualities that make them useful. Compatibility cannot mean erasing every difference. It has to mean preserving enough of the person's intention that the differences remain manageable.

This is where continuity becomes a product responsibility rather than a technical slogan. The person should be able to recognise the project, the current direction, and the next meaningful step even when the surrounding tool changes. We can support that recognition, but we cannot promise that every transition will be effortless. Different tools have different capabilities, limits, and ways of responding. Honest continuity includes those edges.

The work also changed how we think about choice. Freedom is not just the number of doors a product offers. It is the confidence that walking through another door will not invalidate everything that came before. That confidence has to be earned by making the important context visible and by avoiding claims that the product cannot keep.

For users, the result should feel quiet. They should be able to select the tool that fits the moment without feeling that they have abandoned the project. They should not need to become experts in the product's internal model to understand what carries forward. The product's job is to make the continuity legible, not to ask the person to manage it manually at every step.

There is still a limit to what any workspace can carry. A project may change direction so completely that the old context is no longer useful. A new tool may introduce a genuinely different way of working. Sometimes the right answer is to begin again, but that should be a conscious choice rather than an accidental cost of switching.

More tools did not make the product's mission smaller. They made it more precise: protect the thread of the work while allowing the person to change the instrument.

The surprising part of supporting more AI tools was that the tools were not the final subject.

The subject was the person trying to keep a meaningful line through changing conditions. They may change providers. They may change tasks. They may pause for a day. They may come back with a new idea about what the project needs. A useful workspace has to accommodate that movement without turning it into a series of disconnected beginnings.

That is the direction continuity gives us.

We will keep expanding the ways people can work in OFM, but the goal is no longer simply to offer more doors. It is to make sure the work remains recognisable as the person walks through them.

More tools created a new problem. They also clarified the product we want to build.

Open Free Max should give people freedom to choose their tools and enough continuity to keep choosing their work.

The distinction is easy to miss when a product is measured by its list of supported possibilities. A new option looks like progress because it gives someone another way to begin. But a person rarely experiences a tool as an isolated option. They experience the space between yesterday’s decision and today’s next step. If that space becomes harder to cross, more choice can feel like less support.

Continuity does not require every tool to behave identically. In fact, expecting identical behaviour would make the product less honest. Different tools have different strengths, rhythms, and expectations. The useful promise is smaller: the work should remain recognisable, the project should remain visible, and the person should not have to reconstruct the entire situation merely because the next conversation happens somewhere else.

That promise also protects experimentation. People should be able to try a new way of working without feeling that they have abandoned the old one. A workspace can make room for curiosity and still keep a thread through the project. This is the kind of freedom we care about: not unlimited options floating separately, but options that leave the person able to return.