Over the past year I have worked fairly intensively with several current AI systems — not as isolated everyday queries, but as standing working tools: developing large concepts, analysing technical documents, and working through engineering, physical, regulatory, legal and economic questions. What follows is not a technical specification or a proposal. It is the observation of an active user of several AI platforms who happens to know a bit of engineering — a conceptual architecture hypothesis grown out of three practical incidents over the past year.

The first. Early on, before I had learned to watch the limits, I unexpectedly hit the ceiling of a chat in the middle of a large, multi-context task. There was no way to take a proper snapshot, and no way to carry the context into a new chat. While I was requesting the conversation history from the system itself, I had already reconstructed what I needed by hand, another way. I sent the developers feedback at the time: there should be an indicator as you approach the limit, and there should be continuity between chats, so that context does not have to be rebuilt from zero every time. A year ago this was a real problem. Today those mechanisms already work noticeably better.

The second. Sometimes work on a task stretches over time: a pause happens, the chat's state is left as it is, and on return it turns out that the model — even on a paid subscription — has let some context that should have been held slip, and starts filling the gap on its own. Not an obvious mistake, but a plausible, confident guess at what should be there. The practical fix was simple: move working instructions and current state into separate storage — a plain text file — and on returning to the work, just tell the model to pull the current state from there. It is, in effect, a manual, "duct-tape" analogue of a Cell: the same separation of persistent state from the computing tool, just assembled by hand out of what today's interface already offers.

The third. When a large PDF was loaded — roughly fifty pages — the model behaved as if it had read the whole document, while in fact it had absorbed only the first eight to ten pages, and not completely even those. The rest was filled in as the conversation went along, through clarifying questions and answers tuned to the visible part — and on a direct question the model admitted it, in fact, had not read the rest, and had been filling it in. For general, widely known concepts this mode works well enough. But as soon as the discussion turns to specifics — the interaction of nodes in a given circuit, the details of a safety system, particular physical or electrical processes — the result turns into plausible nonsense, indistinguishable from a reliable answer unless you already know the subject yourself.

Three different failures, but they share a root: working state lives inside the chat and inside a single model, not alongside the user as an independent entity. Hence the question this article is built around: if a user's memory can be persistent, why can't the whole of their working state be persistent?

The third incident points to a broader pattern. Large context windows are often treated as the main way to solve the problem of long-term work with AI, but in practice things are more complicated: there is a real difference between information being available to a system and that information actually taking part in a given piece of reasoning. A model can work with relevant fragments of a large corpus, extract individual pieces, reconstruct links between them, and probabilistically fill in the overall picture — and the result can look thoroughly convincing.

If a necessary detail never made it into the context actually being used, the model will produce a plausible continuation instead of an accurate reproduction of the source. For everyday tasks that is often an acceptable trade-off. For engineering, regulatory, legal, or other high-precision analysis, the difference between "this plausibly follows" and "this is actually present in the source material" is fundamental. Increasing the size of the context window, on its own, does not remove this architectural problem.

There is an opposite constraint too. Picture extended work on one complex project: engineering architecture is discussed first, then the physics of a specific process, then a legal question, then a regulatory one, then economics — and after several switches, the conversation returns to the engineering architecture again.

For a human these are different professional spaces within one project. For an AI system there is a risk that they gradually collapse into a single semantic mass: an assumption that was reasonable in one context quietly starts being used as an established fact in another. A legal interpretation bleeds into an engineering one. A term with one meaning in physics picks up shades of meaning from an earlier regulatory discussion. This is context contamination.

A genuine paradox follows: more context does not automatically mean better understanding. Sustained professional work needs two properties at once — continuity and isolation — and the second incident above shows that today these have to be maintained by hand.

A plausible next step is a shift from a largely model-centric architecture to a state-centric one. The persistent entity is no longer a chat, or even a particular model, but a personal AI Cell — a user's own AI honeycomb, holding the operational state: identity, active projects and tasks, independent working contexts, rules, permissions, preferences, links between contexts, available data sources, tools, compute environments, the state of unfinished processes.

The Cell is not obliged to store the user's entire digital life inside itself — it is more of an operator of the structure of that state, of access rights, and of the links between the sources that are actually needed. Inside such a Cell a relatively small internal agent can run. It is not there to replace powerful reasoning models; its job is different — to hold the state together: which context is active right now, which contexts need to stay isolated from one another, what information a given task actually needs, which sources it is allowed to use, and which external compute capability fits the work at hand.

Memory across chats solves the problem of forgetting. AI Cell solves the problem of continually reconstructing working state — the very thing I was doing by hand in the second incident, through a text file.

Inside a Cell there should not be one endless user context. A single large project can contain an Engineering Context, a Physics Context, a Legal Context, a Standards Context, an Economic Context, a Commercial Context. All of them belong to one user and one project — but it does not follow that the contents of each should automatically flow into every next task. If the engineering analysis needs one specific legal constraint, the Cell can hand over exactly that constraint, not the entire history of legal discussions.

The principle: persistent state without persistent context contamination.

Once a user's state stops belonging to a particular model, the next question follows naturally: why should every task be solved by the same system at all? For one job a general-purpose reasoning model is the best fit; for another, a specialised engineering system; for a third, a dedicated legal environment; a fourth may need a medical system; and confidential work may need a local or private compute resource.

This is where the idea of Semantic Roaming comes in. The internal agent inside the Cell defines the boundary of a task and assembles a bounded work package: the task itself, the required context, the applicable rules and permissions, and the specific sources it should use. The external compute system no longer needs the user's whole history and has to work out on its own which part matters right now — it receives exactly the work it is meant to do. Once the work is done, the result returns to the Cell and is attached to the working context it came from.

In simplified form the architecture reads as:
Persistent State → Context Selection → Bounded Task Package → Semantic Roaming → Appropriate Capability → Result → Return to Original Context

This is more than ordinary model routing. Routing sends a request. Semantic Roaming moves a bounded piece of meaning, assembled from the user's persistent state, that keeps its ties to a specific context. In other words: the user does not move into the platform — the task visits the capability.

A useful analogy is an ordinary public calculator. A person walks up, enters the values they need, gets a result, and walks away. The calculator has no need to know who that person is, where they live, what they were computing yesterday, or what larger project they are working on.

In Semantic Roaming an external AI capability could work the same way: the Cell knows the user, the capability knows the task. Naturally, the task itself may carry personal, commercial, medical, or otherwise sensitive information, and the requirements for handling that data do not disappear. But the architectural boundary shifts: an external compute provider no longer needs the user's entire persistent operational state just to perform a single operation.

Separating a user's state from the compute resource has an interesting economic consequence. Today, large AI platforms mostly try to provide the model, the interface, memory, history, projects, storage, agents, tools, and a whole working environment all at once. If a user's persistent state lives in the Cell instead, a platform can play a much narrower role — that of a provider of one specific capability.

No platform has to be the best at everything. One system may be particularly strong at mathematics, another at programming, a third at engineering analysis, a fourth at professional legal work, a fifth at a specific class of scientific data. The user does not need to live permanently inside every such platform — the Cell just routes the relevant task there and gets a result back:
Task → External Capability → Computation → Result → Usage Charge

What could be billed: compute time, volume processed, model class, task complexity, the use of a specialised knowledge base, a licensed professional environment, or access to a particular compute resource. The economic unit gradually stops being just "a user inside a platform" and becomes capability available on a compute network.

This architecture could change the character of competition among AI providers. A provider no longer needs to build yet another all-purpose global ecosystem and try to win the user over entirely — it can focus on the one thing it does better than anyone else, and sell that capability to external Cells.

This is especially interesting for smaller, specialised AI companies. They do not need to build a global memory of users, a universal interface, a full ecosystem of projects, a multi-year record of user state. They can compete purely on the quality of one kind of computation. It comes down to: the Cell owns continuity; providers supply capabilities; Semantic Roaming connects them. It starts to resemble the economics of telecom roaming.

Under this model, a user's large home platform does not disappear — it takes on a different infrastructural role, a kind of Home AI Operator. Such an operator could provide the Cell's identity, synchronisation across devices, encrypted backup, recovery, permission management, roaming infrastructure, a catalogue of capabilities, billing, and settlement between providers.

Cloud infrastructure does not disappear either: the Cell can keep an active local state on the user's device and a protected backup copy with the home operator. The architecture is not built on local versus cloud — these are simply different layers doing different jobs.

Modern devices already carry substantial CPU, GPU, and NPU resources, and there is no need to spend them trying to run a giant frontier model locally. They can do a different class of work instead: persistent state management, context separation, local retrieval, permission enforcement, task classification, task package construction, result integration.

The heavy model performs the hard computation; the user's device performs the intelligent preparation for it, which suggests a multi-tier topology:
User Device / Cell → Local Compute → Regional Compute → Specialised Capability → Large Frontier Compute

A simple request can stay local. A medium task can move to a regional compute node. A specialised one goes to the matching provider. Only genuinely heavy work, needing the largest model and substantial resources, should have to reach the biggest compute centre.

There is no reason to walk around the block to reach the bin standing right outside your own door. Yet the constant reconstruction of a large user context is sometimes architecturally doing exactly that: a new request arrives → working state is restored → relevant context is searched for → part of the history is reprocessed → and only then does the actual task begin. The more projects, documents, and professional contexts accumulate, the longer that route gets. More compute power lets you cover it faster — it does not answer the more basic question of whether the route is needed at all.

Any AI request contains two different kinds of work: useful computation — actually solving the task — and context servicing — reconstructing enough state to pose the task correctly in the first place. Over a long-running interaction the second component potentially keeps getting heavier. If persistent state already exists, there is no need to recompute, from scratch, everything the system should already know as stable state each time; only the minimal task-specific context needs to be handed to the external capability. This could mean fewer tokens reprocessed, less compute load, less network traffic, lower latency, and potentially lower energy use.

This remains a hypothesis that needs measuring. But the underlying research question is concrete enough: how much of today's AI computation is actually needed to solve the task, and how much exists only because the system keeps rebuilding the task's state from zero each time?

If tasks can move dynamically between compute resources, it becomes possible to build not just a few giant AI data centres but a more distributed infrastructure. A large share of everyday tasks could potentially be served by local and regional nodes, while the biggest data centres remain reserved for the genuinely heavy work.

The advantage of this model is not only efficiency — it also potentially narrows the blast radius of failure. Concentrating enormous compute capacity in one place also concentrates risk: a fire, a power failure, cooling damage, a network incident, or another technical accident at a large compute centre can knock out a significant share of capacity all at once. In a distributed architecture, losing one node mainly means a temporary reduction in available compute capacity. If the user's state exists independently of the compute node, the task can simply be rerouted:
Node fails → Cell persists → Capability is rerouted → Computation continues elsewhere.

This makes graceful degradation possible: with local resources constrained, the system can keep simple tasks local, move heavier ones regionally, send priority work to specialised providers, and queue non-priority work for later. In this model the compute network gains not only throughput, but a measure of topological resilience.

A persistent Cell could potentially hold not just context, but a verified user identity, a professional role, and the corresponding permissions. That opens the door to a more differentiated model of AI access. An anonymous public system is forced to apply fairly broad, universal restrictions, because it usually has no way of knowing who is asking, for what purpose, in what professional context, or with what authority.

In a Cell architecture a task could carry Verified Identity, Role, Task Purpose, Authorization Scope, Context Boundary, and an Audit Token. This does not mean removing safety controls — if anything, they can become more precise: contextual, role-aware, and auditable. A verified identity should not mean "permission to bypass the rules." It can mean the option to apply a different, professionally defined access mode in situations where that mode is genuinely appropriate.

Independent Cells and external capabilities interacting will need a common language. If this reasoning is pushed to its conclusion, some kind of shared protocol would be needed — for lack of a better name, call it the AI Semantic Roaming Protocol (ASRP). This is not a proposal for a formal standard so much as a thought experiment: the name is simply built from the term Semantic Roaming, not coined as a brand.

It has no need to standardise how the models themselves are built: a general-purpose reasoning system, a specialised engineering platform, a local server, or some architecture that does not exist yet could all be constructed in entirely different ways. What gets standardised is the boundary between a Cell and a capability:
Discovery → Capability Negotiation → Authorization → Bounded Context Transfer → Execution → Result + Provenance → Accounting → Settlement

Such a protocol would need to address identity, capability description, task manifest, context boundaries, permissions, authentication, trust, result provenance, accounting, billing, settlement, failover, recovery, and interoperability. In that model, a Cell stops being just a feature of one platform and becomes a potential node in a larger compute network.

When a mobile subscriber travels to another country, their home operator does not need to build its own base station nearby. Identity and the contractual relationship stay with the home operator, physical infrastructure is temporarily provided by another network, usage is metered, and settlement happens between the operators.

A similar, though not literal, model can be imagined for AI:
Home AI Platform → Personal AI Cell → Semantic Roaming → Visited Capability Provider → Result → Settlement

The user keeps their persistent digital working environment. But compute capability can come from wherever it is available better, faster, cheaper, or more precisely fit for the professional task at hand.

The advantages of this architecture are entirely open to dispute — on the complexity of the Cell, the cost of maintaining it, security, routing quality, protocols, latency, synchronisation, the reliability of distributed compute, the cost of local nodes, and the economics of inter-operator settlement. It is quite possible that some of the presumed advantages turn out smaller than expected, or do not hold up at all. But it is much harder to argue against testing the underlying architectural hypothesis experimentally.

A large part of AI development today follows a fairly clear trajectory: more models → more context → more bandwidth → more compute power → more data centres. This genuinely expands what is possible. But it also raises a question: does solving a harder task always require more compute — or does some of that compute exist only because working state is organised inefficiently?

This can be tested experimentally. Take one set of long-running professional tasks and compare:
— Architecture A — a large model with continual reconstruction and transfer of context;
— Architecture B — a persistent Cell with isolated contexts, bounded task packages, and Semantic Roaming across different compute capabilities.

Then measure: tokens processed, compute time, latency, network transfer, memory usage, energy consumption, monetary cost, context-related error rate, and result quality. If the Cell architecture loses, the hypothesis needs revising. If, at comparable or better quality, it turns out substantially more efficient, there is a case for pursuing it further.

One important qualification: the idea of a Cell does not require tearing down what already exists. It does not redraw the existing market of models, platforms, and in-chat memory — it adds one more, parallel layer on top of it. Even if such an architecture were to gain approval and start developing — including on the regulatory side — the transition would inevitably be a long one. The familiar platform model and a cellular architecture would likely coexist for some time, regardless of how fast the second one develops.

The practical relevance for anyone who chooses to get involved during that transition lies exactly there — not because anyone intends to break something, but because the parallel coexistence of two architectures creates room to work in its own right.

This concept does not call for abandoning large models — quite the opposite. Large models keep doing what they do best: computing, analysing, reasoning, and creating. But a user's state no longer has to live permanently inside every compute platform it touches.

The three incidents this article opened with — hitting a limit with no way to save state, losing state during a pause, a large document silently going half-read — are not really about the shortcomings of particular models. They are about the fact that today a task's state is tied to a chat and to a model, rather than to the user. Perhaps the next step in AI development is not only more powerful models, but a different architecture around them: one persistent Cell, isolated contexts, many compute capabilities, distributed infrastructure, Semantic Roaming between independent environments.

This is a practitioner's observation, not a technical specification: it is impossible to cover the whole architecture in one piece of writing, and a good deal of the detail is deliberately left out. The idea can be criticised, measured, tested, and disproved. If anyone finds it interesting enough for a deeper professional conversation, I am glad to have that conversation — with no commercial angle, purely out of interest in the subject.

Depth under the keel was once measured with a lead line — a rope with knots and a weight. Then came more precise instruments. The straight ruler did not vanish when the slide rule appeared. The slide rule did not vanish the day the calculator arrived. The calculator went on existing alongside the computer, and the computer did not vanish when artificial intelligence appeared.

This is not so much a sequence of inventions cancelling each other out as one continuous chain of tools evolving — each one letting the work be done differently, coexisting for a while with what came before, and gradually taking the place where it turns out to be more useful. Perhaps AI Cell and Semantic Roaming, relative to today's AI architecture, are simply another possible link in that same chain.

And before building ever larger infrastructure to process ever larger contexts, it may be worth asking a simpler question first: how much of this computation is actually necessary?

State stays. Compute moves.