The project grew. Progress became harder.

Continuity began while I was working with coding agents on a large project.

Early in a session, an agent could follow the scope, work through problems, and land useful changes. But each session accumulated decisions, corrections, constraints, and implementation details.

Eventually, that context began to interfere with the work it was supposed to support.

I came to think of this as contextual saturation.

Starting another session cleared the working context. It also left behind the reasoning that had brought the project to that point.

The next agent could inspect the code. It didn’t necessarily know why an approach had been rejected, which assumptions mattered, or why an apparently sensible change would break existing logic.

Explaining that history again consumed the new session’s capacity. Leaving it out meant repeated questions, reopened decisions, and scope drift.

As the project grew, catching up increasingly competed with moving forward.

I began thinking about human memory as an inspiration for a separate system.

But remembering was only part of the problem. What we do with memory mattered just as much.

Think about touching a hot pan. Years later, you might remember little about the kitchen, the food, or the pan’s color. Yet what you learned can still guide your actions around heat.

The detailed circumstances and the useful understanding do not have to travel together every time.

What needed to carry forward was the significance of the experience.

That example led me to distinguish the components.

A memory retained the event and its circumstances. An experience connected the event with an action and an outcome. A lesson expressed what had been learned.

Evidence could support that lesson: the surface was hot, contact caused a burn, and pain was experienced.

Supported understanding could become knowledge to carry forward. That knowledge could inform a skill—an action to take, or deliberately avoid, in a relevant situation.

This became the basis of Continuity’s persistence sequence.

The same reasoning applied to a good result.

A sequence of actions solved a problem. The interaction became an experience of that solution. A lesson could identify what had worked, with the observed outcome providing support.

The resulting knowledge could inform a reusable skill.

Later, a different task might make that skill relevant. Applying it would require recognizing the relationship between the situations, without reconstructing every detail of the original work.

Some understanding came from direct interactions and their outcomes. Other understanding came from books, research, and external sources.

I developed separate concepts for local resolution and global resolution.

Both needed a sequence through which a lesson could acquire support and become knowledge. Their acquisition and verification differed.

An observed solution could provide evidence within an interaction. A claim encountered during research needed its own verification. Recording either one was only the beginning.

These components needed to remain distinct while belonging to one system.

A relational database offered a way to retain them and represent their connections: an experience to its memory, a lesson to its evidence, knowledge to its origin, and a skill to the understanding behind it.

It also allowed that history to remain outside the model’s active context, available for retrieval.

But storage left an operational question unanswered. How would the working model find what mattered?

If the working model searched through the database itself, that search would add more material to its context.

My idea was to give that work to a background agent.

The working model would supply a small amount of context about the current request or task. The background agent would use it to search the retained information and return what was relevant.

The broader history—and the work of searching it—could remain outside the active conversation.

I wanted users to retain control of their interactions and the understanding developed through them.

They also needed the freedom to change models, providers, or harnesses without abandoning the significance of earlier work.

Local PostgreSQL became the storage foundation. The idea expanded into a service with its own API and SDK framework, through which different tools could access the Continuity layer.

The intelligence could change while the retained work remained.

Continuity began taking shape through an LLM plugin, then MCP tools for agentic harnesses.

I built the application to provide a place to put the approach into practice.

The Assistant offered direct interaction with the Continuity layer. Other surfaces brought related tools into a shared workflow, organized by category.

Together, they provided different places to develop and demonstrate continuity within one coherent environment.

That is the work behind Continuity today.