What Is Artificial Intelligence Continuity, AIC?

AI is beginning to outgrow the chat session.

The first wave of generative AI followed a fairly simple pattern:

Prompt → AI → answer → done.

Even as conversations became longer, the basic pattern remained similar. A person provided information and instructions, the model used the context available to it, and then generated the next response.

But AI systems are moving toward something different.

Agents can work through multiple steps, use tools, manage files, make intermediate decisions, wait for people or other systems, and then continue later. A task may span several separate runs and several context windows. It may pause and resume. In more advanced architectures, even the model, server or runtime environment carrying out the work may change while the project is still underway.

That creates a problem bigger than how much an AI system can remember.

The more important question becomes:

What from the past must still be valid when the AI system continues?

Anthropic has described work across multiple context windows as an open engineering challenge for long-running agents. The company compares the problem to a project where a new engineer begins a shift without automatically knowing what the previous engineer did. One part of the solution is therefore to leave behind structured artefacts that can be handed to the next session.

Google, meanwhile, describes durable execution as a core part of Agent Executor: long-running agent workflows need to be able to resume after interruptions or after waiting for events such as human approval.

These are different technical approaches to parts of the same larger problem.

A new run needs more than information about earlier work.

It needs to continue the right work, from the right state, toward the right goals, with the right authority.

The everyday handoff problem

You can already see the problem in something as ordinary as today’s AI chats.

Imagine a person working with an AI on a large project over a long period of time. Decisions are made. Earlier ideas are rejected. Documents are created. Some parts of the work are finished and should not be reopened. Other parts are still waiting for action.

Eventually, the original conversation becomes too large or impractical, and the project has to continue in a new chat or session.

The obvious response is to hand over the history.

But what does that history actually mean?

It might contain ten different title ideas even though only one was eventually selected.

It might contain an old work plan that was later replaced.

It might contain a problem that has already been solved.

It might contain an earlier instruction that only applied to one temporary step.

And it might contain a draft that looks finished even though a later file is the current master version.

A new AI session can therefore have access to a large amount of perfectly accurate historical information and still continue the project incorrectly.

It can reopen something that was already completed.

It can select an obsolete version.

It can treat a temporary decision as a permanent rule.

It can miss what the actual next step is.

It can even reintroduce something a human explicitly decided should be removed.

In today’s AI workflows, there is often still a human between sessions who catches these mistakes.

The human effectively says:

That is old.

This is the current version.

This work is finished.

This rule is permanent.

Continue from here.

The human is effectively performing the continuity check.

But as AI agents become more autonomous and are expected to continue work without a person reviewing every handoff, more of that function has to be built into the systems themselves.

Memory is not the same as continuity

This is the central distinction.

Memory asks: What happened before?

AIC asks: What from the past must still be valid and govern what happens next?

An AI system can therefore have excellent memory and poor continuity.

The fact that an old instruction can still be retrieved does not mean it still applies.

The fact that a goal exists in the history does not mean the goal is still active.

The fact that an agent once had a certain permission does not mean it should still have that permission.

And the fact that a particular state has been stored does not mean that state is the authoritative version from which work should continue.

The 2026 preprint Beyond Memory: A Transactional Continuity Kernel for Long-Lived AI Agents addresses this distinction directly. Its authors argue that storage alone is not enough to determine which state is allowed to become active. Their proposal instead uses a controlled chain in which changes must be validated before they replace the previously authoritative state.

This is a research proposal, not an established standard.

But the underlying question matters:

It is not enough for information to survive. The system must be able to determine which information is still allowed to govern what happens next.

“The report must be sent on Friday”

A concrete example makes the difference clearer.

An AI agent is given an instruction:

“The report must be sent on Friday.”

The agent works on the report during the week. It gathers material, creates drafts and stores information about the task.

On Thursday, the underlying AI model changes.

Or the server restarts.

Or the workflow is moved to another technical environment.

The history and memory survive.

On Friday, the next run has to decide what should happen.

But several things may have changed.

The report may already have been sent shortly before a system failure.

The recipient may have changed on Thursday.

A human may have cancelled the task.

The agent’s right to send email may have been revoked.

There may even be two different copies of the agent’s state, both believing that they represent the current version.

Both copies may be able to read the sentence “the report must be sent on Friday”.

That does not solve the problem.

Memory can tell the system that the commitment once existed.

Continuity has to help determine whether the commitment still applies, whether it has already been fulfilled, which version is current and who still has the authority to act on it.

What happens when the model changes?

This is where the question becomes even more interesting.

We often identify an AI agent with the model currently running it. But a long-lived agent architecture does not necessarily have to work that way.

The September 2026 preprint Runtime-Independent Persistent Agents: Preserving Identity, Memory, and Code Across Models, Harnesses, and Servers explores an architecture in which the components carrying the agent’s continuity are separated from the model, harness and server currently executing it.

The authors describe a continuity-bearing layer containing, among other things, an architectural identity representation, private durable memory and a versioned software body. The model, agent framework and host server are instead treated as components that can, in principle, be replaced.

In the proposed architecture, a controlled transition can therefore be understood as a migration rather than the creation of an entirely new agent — but only if the transfer occurs through an authorised process that preserves traceable lineage and the right to continue.

This too is research, not an industry standard.

But it makes an important question concrete:

If an agent uses model X today, and tomorrow its relevant state, memory, goals, code and identity are connected to model Y, what has to be true for that to count as a legitimate continuation?

Is it the same logical agent?

Or is model Y actually a new agent that has inherited its predecessor’s history?

System designers do not need to solve the philosophical version of that question before the practical version becomes important.

The organisation still needs to know which state applies, who performed earlier actions, which permissions are allowed to carry forward and who is responsible for what happens next.

Seven dimensions of the same larger problem

There is no established AIC taxonomy.

To make the broader issue easier to discuss, NextNet proposes seven pedagogical dimensions. They are a working framework for discussion, not a claim that research or industry already uses this exact classification.

1. Memory continuity

The most obvious dimension is memory.

Relevant information has to be able to survive between runs: earlier events, decisions, facts, instructions, experiences and other information that future work depends on.

But memory only creates access to the past.

It does not automatically determine how the past should be interpreted.

A perfect archive can contain both the old instruction and the new instruction. The continuity problem appears when the system has to determine which one still applies.

2. State continuity

State describes where the work actually is now.

Which step is active?

What has been completed?

Which file version is current?

Which branch of a workflow is the valid continuation?

This is different from simply having a chronological history.

A system may know about five earlier states and still require a mechanism for determining which one is the authoritative state on which the next action should be based.

3. Goal continuity

Long-running work requires goals that can survive beyond a single session.

But goals also need to be able to change.

A goal can be achieved.

It can be replaced.

A human can cancel it.

New circumstances can make it irrelevant.

Goal continuity therefore does not mean making goals permanent. It means enabling the system to distinguish between goals that are still active and goals that only remain in history.

4. Commitment continuity

Some decisions create future obligations.

The report must be sent on Friday.

A customer must be contacted after a particular event.

A purchase may only be completed after human approval.

A project has been closed and must not automatically be reopened.

These commitments sit somewhere between memory, goals and responsibility.

They need to carry forward when they are still valid — but the system must also be able to mark them as fulfilled, revoked or replaced.

5. Identity continuity

When AI begins carrying out real actions, systems need to be able to answer a basic question:

Which agent did this?

Microsoft Entra Agent ID illustrates how AI agents can be given their own technical identities that can be used for token-based authentication and authorization within Microsoft’s ecosystem.

This is not a question of personality or of treating an AI as a person.

It is a question of technical identification and traceability.

If an agent continues after a restart or migration, it must be possible to determine which logical agent or system role the next action belongs to.

6. Authority continuity

Identity does not automatically answer the question of what an agent is allowed to do.

An agent can be correctly identified and still lack the right to use a particular tool, read a particular data source or perform a particular action.

NIST’s NCCoE is examining questions around identification, authentication, authorisation, auditing and accountability for software and AI agents. The work is a concept/project effort around applying existing standards and practices — not a completed AIC standard.

For continuity, this matters for a simple reason:

A permission that was valid yesterday must not automatically remain valid tomorrow if it has been revoked.

A continuity system therefore needs to do more than carry authority forward.

It must also know when to stop carrying it forward.

7. Provenance continuity

Finally, the system needs to understand where important parts of its state and history came from.

Who created the information?

Which tool changed it?

Which previous state did a decision depend on?

What changed — and when?

The W3C PROV family provides an established framework for representing provenance relationships among entities, activities and agents.

PROV does not solve AI continuity by itself.

But this kind of traceability illustrates an important building block: when a long-lived system continues, it should still be possible to reconstruct where its information and decisions came from.

The pieces are developing — but the whole remains open

One of the most interesting things about this area is that many of the continuity problems are already being addressed in practice, but from different directions.

Anthropic is working with structured handoffs and artefacts so that a new agent session can understand what previous sessions have done.

Google is developing durable execution for long-running workflows that need to resume after interruptions.

Microsoft is developing dedicated identities and permissions for AI agents.

NIST is examining how identity, authorisation, auditing and accountability should work as agents gain access to data, tools and applications.

W3C’s PROV family shows how provenance, derivation and chains of change can be represented.

Researchers are also exploring architectures in which continuity is treated as something broader than the storage of memory.

A closely related research direction appears in the April 2026 position paper The Continuity Layer: Why Intelligence Needs an Architecture for What It Carries Forward. It treats continuity as a system property distinct from both memory and retrieval. The paper describes seven properties that, according to its author, a continuity system should provide, including persistence across sessions, update handling, temporal ordering, disambiguation, reconstruction, model independence and operational usefulness.

Those seven properties are not the same as NextNet’s seven AIC dimensions. The Continuity Layer describes properties or requirements of a continuity system, while NextNet’s framework groups the kinds of memory, state, goals, commitments, identity, authority and provenance that may need to continue correctly over time.

The frameworks are different, but the paper is another sign that continuity is beginning to be treated as a technical problem in its own right rather than as a synonym for memory.

None of this means that Anthropic, Google, Microsoft, NIST, W3C or the researchers behind these papers are working according to NextNet’s AIC framework.

They are not.

Nor does any one of these approaches solve the entire problem.

Better memory does not automatically determine which state is authoritative.

An identity does not automatically determine which old goals remain active.

An authentication mechanism does not tell us whether an earlier commitment has already been fulfilled.

A log does not automatically determine which version is correct.

And a resumption mechanism alone does not determine what the agent is still allowed to do.

The larger continuity problem becomes clearer when all of these questions begin to meet inside the same long-lived system.

Continuity can become a security problem

It is easy to think of continuity as a convenience feature.

No one wants an AI system to forget the project every morning.

But incorrect continuity can be much more serious than lost convenience.

Imagine an obsolete state becoming active again after the work has already moved on.

Or a revoked permission surviving inside the copy from which an agent resumes.

Or two instances recovering from a failure and both believing they are the authoritative continuation — then both performing the same action.

Or an attacker managing to manipulate information that later travels forward as if it were a legitimate part of the agent’s history.

The Continuity Kernel preprint discusses risks such as stale overwrites, un-audited exposures and self-authorising privilege escalation, alongside the need for auditability. Its proposed design therefore avoids allowing candidate changes to become active simply because they have been created.

This becomes more important as AI systems gain greater ability to act.

If a chatbot remembers something incorrectly, the result may be a wrong answer.

If an agent with access to email, databases, financial systems or production environments continues from the wrong state, the result may be a wrong action.

Continuity therefore becomes more than a memory problem.

It becomes part of security and governance.

Good continuity also means letting the right things end

There is an important paradox here.

Maximum continuity might sound as though the goal is to preserve as much information as possible forever.

But such a system could become dangerous and difficult to control.

Old goals need to be able to end.

Permissions need to be revocable.

Incorrect information needs to be correctable.

Obsolete instructions need to be replaceable.

Information that should be removed needs to stop influencing future work.

An old role may no longer belong to the agent.

A functioning continuity system therefore has to support both preservation and termination.

It has to answer three questions:

What must survive?

What must be allowed to stop?

Who or what is allowed to decide the difference?

That is another reason AIC cannot be reduced to “more memory”.

AIC is not about consciousness

As AI systems gain stronger continuity, people may increasingly experience them as the same entity over time.

The system may remember earlier work.

It may return to old projects.

It may know what decisions were previously made.

It may continue from where “it” stopped yesterday.

But technical or operational continuity is not evidence of consciousness, subjective experience or personhood.

An AI system could have very strong continuity — stable technical identity, long-term memory, preserved goals, versioned state and controlled migration between models — without any of those properties telling us whether the system experiences anything.

The preprint on runtime-independent persistent agents treats identity and continuity in architectural and functional terms.

Those questions need to remain separate.

Do we really need another AI acronym?

It is a fair objection.

The AI world already has no shortage of abbreviations.

AI, LLM, RAG, AGI, ASI, MCP and a growing number of other technical terms already compete for attention.

The abbreviation AIC is also already used in other fields, including for Akaike Information Criterion in statistics and model selection. In this article, AIC is used specifically as an abbreviation for Artificial Intelligence Continuity.

There is no inherent value in creating one more acronym.

That is not the point of AIC.

The more important issue is that AI is developing quickly enough for new system properties and new problems to emerge before the language around them has stabilised.

AIC is intended as a way to discuss the whole.

An LLM describes a type of model.

RAG describes a way of retrieving relevant external information.

Agentic AI describes systems that can work toward goals and use tools.

Memory describes information that can be preserved and recalled.

Identity describes who or what is acting.

Authorisation describes what the system is allowed to do.

AIC instead tries to capture the question of how these relevant elements can continue together in a correct, controlled and verifiable way over time.

Why this needs to be discussed now

When generative AI was mainly used to answer a question or create a piece of text, the continuity problem was relatively limited.

Agentic systems change that.

They can have technical identities of their own.

They can gain access to external tools and data.

They can work toward long-running goals.

They can pause while waiting for a human.

They can continue in another session.

And researchers are already exploring how parts of an agent might persist even when the model, harness or server changes.

Questions that could previously be handled separately then begin to meet inside the same system:

Which state is authoritative?

Which goals are still active?

Which commitments have already been fulfilled?

Which agent is continuing?

Which permissions remain valid?

How do we know where the information came from?

How do we revoke something that should no longer apply?

How do we audit a decision long after the model that made it has been replaced?

And what must be true before we can say that the next run is genuinely a correct continuation of the previous one?

The verified source base does not provide a single, final answer to that broader question.

That is exactly why the discussion matters now.

It is easier to discuss continuity, control and responsibility while these architectures are still being built than after the behaviour of long-lived AI agents has become invisible infrastructure in everyday life.

Why NextNet proposes Artificial Intelligence Continuity

NextNet does not claim to have discovered the continuity problem.

That would be wrong.

Researchers, technology companies and standards organisations are already working actively on different parts of it.

In the research for this article, however, NextNet has not identified Artificial Intelligence Continuity, AIC, as an established standard term with the broader meaning used here. Related research does explicitly address AI continuity and continuity layers from other perspectives.

That does not prove that the words have never been used anywhere.

It means that NextNet is using AIC as its own pedagogical umbrella term for discussing several related questions as parts of the same larger problem.

Perhaps AIC will never become the established name.

That is not the important part.

The important part is that the questions the term attempts to bring together already exist — and they become harder to treat separately as AI systems grow more autonomous and more persistent.

If Artificial Intelligence Continuity helps us see those questions as parts of the same larger problem, the term has already served a purpose.

The rest will be decided by research, technical development and the people building the systems.

💬 What do you think?

As AI agents begin working over longer periods of time, which part of their continuity do you think will be most important to control?

Share your thoughts in the comments.

📚 Related articles