Agentic AI Doesn't Have an Intelligence Problem. It Has a Continuity Problem.

For the last few years, most of our interaction with AI has followed a simple pattern: we ask, AI answers. That is changing very quickly. The next generation of AI will not just tell us how to do something — it will increasingly do the work. An AI agent can inspect a codebase, plan a feature, modify files, run tests, identify an error, correct it and continue until the task is complete. Another agent could research a market, compare competitors, prepare a report and hand the findings to another system.

This is the promise of agentic AI, and I think it will fundamentally change how software, products and even businesses are created. But there is a problem we are not discussing enough.

The more autonomy we give AI, the more important project memory becomes

Imagine giving a capable developer a complicated project, but every morning that developer forgets most of what happened yesterday. You would have to explain why certain architecture decisions were made, which approaches had already failed, what the customer actually wanted, which requirements were mandatory, which compromises had been accepted, what should not be changed, and what the team was trying to accomplish in the first place.

It sounds absurd. Yet we regularly work with AI this way. A model may understand a project extremely well during one session, then the session ends. Another model enters. A different coding agent takes over. Or the context window fills up. Suddenly we are reconstructing the project again. For conversational AI, this is inconvenient. For autonomous agents making changes to real projects, it becomes a much more serious problem.

A context window is not project memory

This distinction matters. A large context window allows an AI to read a lot of information at once — that is useful, but it is not the same thing as persistent project knowledge. Think of a context window almost like working memory: information goes in, the model works with it, and eventually that working session ends.

Project memory needs to behave differently. It should preserve important knowledge over weeks, months and years — not everything, the right things: requirements, architecture decisions, approved instructions, lessons from previous failures, current priorities, known issues, project-specific rules, useful skills and workflows, human decisions, evidence behind important conclusions, and the current state of the project. That information should not disappear simply because we changed the model.

Chat history is useful. But it is not enough.

A six-month conversation history might contain valuable information. It also contains questions, dead ends, repeated explanations, temporary ideas and decisions that were later reversed. An AI should not have to reread thousands of messages every time it joins a project. It needs something more structured — a way of understanding: this is the current requirement; this decision is still valid; this approach was rejected; this is the latest approved architecture; these are the instructions relevant to the task I am performing now.

That turns memory from a transcript into usable project infrastructure. And this is where I think agentic AI becomes much more interesting.

Agents need handovers just like people do

Suppose one agent researches a problem, another writes the code, a third reviews security, a fourth runs tests, and a fifth prepares the release. That sounds powerful, but only if they understand one another. Otherwise we have created something very familiar: a badly coordinated team. The research agent discovers something important, but the coding agent never sees it. The coding agent makes an architectural decision, but the testing agent does not know why. The next agent changes something that had deliberately been protected.

More agents do not automatically create better outcomes — they can also create more opportunities for drift. Good agentic AI therefore needs reliable handoffs. An agent should be able to leave behind more than an answer. It should leave a useful record of what it did, why it did it, what changed, what remains unresolved, what evidence it relied on, and what the next agent needs to know. That is when multiple AI systems begin behaving less like disconnected tools and more like a coordinated operating environment.

Skills should belong to us, not individual AI platforms

There is another layer to this. People who use AI seriously are already developing their own ways of working: how they research, how they review code, how they test a release, how they analyse a business decision, how they write documentation, how they evaluate evidence, how they decide when AI should act and when a human should intervene. Over time, these methods become reusable. I think of them as skills.

Today, many of these skills are trapped inside prompts, custom instructions or particular AI platforms. That may not make sense in the long term. If you have spent months improving a workflow for reviewing software releases, why should that method stop working because you moved from one AI model to another? Your preferred methods should travel with the project. The model provides intelligence. The project provides context. Your skills provide the method. That separation could become extremely powerful.

More autonomy also requires more accountability

There is another side of agentic AI that deserves equal attention: the more an AI can do, the more important it becomes to know what it actually did. When AI only suggested code, a human could review the suggestion. Now imagine agents modifying dozens of files, running commands, restructuring components and making decisions across a project. Soon the question will not only be "can the agent do this?" It will also be "should the agent be allowed to do this without approval?"

Different actions require different levels of autonomy. An agent might safely correct formatting without asking anyone. Changing a database architecture is different. Deleting production data is very different. Changing an important business requirement should probably involve a human decision. The future, therefore, is unlikely to be unlimited autonomy — it will be bounded autonomy. Let AI handle repetitive execution. Let agents investigate, propose, test and automate. But keep judgment, accountability and sensitive decisions visible to people. That also means projects need checkpoints, history, traceability, and the ability to understand how the current state was reached.

The AI model should not become the owner of the project

This may eventually become the most important principle. We do not know which AI coding environment will dominate three years from now. We do not know which model will be best six months from now. And we should not need to know. A project may use one model for architecture, another for coding, another for research and specialised agents for testing or security. Tomorrow, better tools will appear, and we should be able to use them.

The project's accumulated intelligence should therefore remain independent of the AI provider. The code belongs to the project. The requirements belong to the project. The decisions belong to the project. The skills developed around it belong to the project. The memory should too.

Now imagine the workflow

You open an AI coding environment. Instead of spending twenty minutes explaining the project, the agent retrieves the context relevant to its task. It understands the active requirements, sees important architectural decisions, knows which rules apply, loads the appropriate workflow, performs the work, tests what it changed, records the important outcome, and leaves a clean handover for whatever human or AI comes next.

You switch models tomorrow — the project does not start again. A new developer joins next month — the reasoning does not disappear. An agent makes a mistake — you can understand what happened and restore an earlier state. A requirement changes — future agents work from the new truth rather than an old conversation. This is much more than AI memory. It is continuity.

And coding is only the first obvious use case

The same architecture can apply to almost any form of serious AI-assisted creation. A research project should remember its sources, assumptions and rejected conclusions. A marketing project should remember positioning, tone, previous campaigns and brand decisions. A book should retain its characters, structure and editorial choices. A consulting engagement should preserve evidence, decisions, deliverables and client requirements. A business transformation programme should remember why important decisions were made instead of leaving institutional knowledge scattered across presentations, emails and AI conversations. As AI becomes involved in more of our work, this accumulated context becomes a valuable asset in its own right.

The next AI breakthrough may be quieter than we expect

We naturally focus on the models — which one has the highest benchmark, which one writes better code, which one reasons better. Those improvements matter. But I suspect an equally important change will happen around the models: a persistent layer that helps our projects remember, that allows different agents to collaborate, that carries our skills between tools, that keeps humans connected to important decisions, that preserves project truth while models come and go.

The most successful agentic AI systems may not be those with the most agents. They may be the ones where every agent understands what the project is, where it has been, what matters now and where it is supposed to go — because autonomous intelligence without continuity can simply create mistakes faster. But autonomous intelligence combined with memory, traceability and human judgment could genuinely change how we build.

Perhaps the question we should start asking is no longer "how intelligent can AI agents become?" It is: how do we make sure everything they learn remains useful to the project after they are gone?