The next big problem in AI coding isn’t intelligence. It’s continuity.
Over the last 12 months, our team has been quietly building something for AI coding agents because we became convinced there’s a major problem emerging underneath all the excitement around AI-assisted development.
The models are getting incredibly capable.
Claude Code, Cursor, Codex and the rest can all do genuinely impressive engineering work now. We’re well past the “toy demo” stage.
But after using these systems heavily on large real-world codebases, we kept running into the same wall over and over again:
They forget everything.
Inexorably.
You explain your architecture.
You explain why a system exists.
You explain the conventions.
You explain what failed previously and why it failed.
You explain what must never be touched.
Then the agent drifts. Context compression kicks in. The conversation gets long enough that the model starts losing operational awareness of the project. Eventually it begins confidently suggesting things that directly violate earlier decisions.
After enough exposure to this, we started realizing the next big problem in AI-assisted software development is probably not intelligence.
It’s continuity.
Current AI systems are fundamentally stateless underneath the interface. Every session is partially rebuilding understanding from scratch. Even with massive context windows, the system slowly rots under enough complexity.
So we started building a persistent continuity layer specifically for coding agents.
What became interesting very quickly was discovering that most current “memory” approaches don’t really solve the problem either.
A lot of systems now use markdown files, flat notes, or giant rolling context documents as their memory layer. Or they bolt a vector database on to some MCP tools and call it a day. That works surprisingly well at first. Until it doesn’t.
Over time those systems start accumulating:
outdated assumptions, duplicated information, contradictory patterns, stale architectural decisions, temporary fixes that became permanent, abandoned ideas that resurface months later, and increasingly messy context that the agent itself has to continuously reinterpret.
At that point the memory layer starts behaving less like memory and more like an unsupervised junk drawer.
The hard problem isn’t:
“where do we store information?”
The hard problem is:
“how do you maintain reliable behavioural continuity over time?”
How do you stop stale information from resurfacing?
How do you stop agents from repeating known failures?
How do you maintain architectural continuity over months?
How do you make memory actually influence behaviour at the correct moments instead of existing passively somewhere in storage?
How do you stop the memory layer itself from slowly becoming unreliable?
That ended up leading us into some surprisingly deep territory around behavioural grounding, reinforcement and decay, truth-state management, contextual retrieval, policy systems, project-aware continuity, citation verification, and long-term operational consistency.
The goal is not to create “an AI that remembers your favorite programming language.”
The goal is to create agents that actually accumulate durable operational understanding of software projects over time.
The more we work on this, the more it feels like the industry is converging toward the same realization. Anthropic, OpenAI, GitHub, Cursor — everybody now appears to be moving toward persistent memory in some form, and we're seeing a lot of jargon mixed with marketing spin as people "move fast and break things".
Our view is that this becomes one of the foundational infrastructure problems of the next generation of software development.
Not bigger context windows.
Not more autocomplete.
Not another wrapper.
Not another RAG system.
Continuity.