The Claim Changed
When I wrote the first PermeantOS post, the project was still a question wearing the clothes of a prototype.
Could an AI agent’s live runtime state be moved between machines? Could the expensive attention state inside one inference engine be captured, described, transferred, written into another runtime, and used for continuation without rebuilding the whole prefix from scratch? Could that state be tied to the agent’s memory, artefacts, pending work, and operational identity rather than treated as a loose tensor dump?
That was the research claim.
The claim is different now.
PermeantOS has demonstrated that agents can move across validated paths. Not as a metaphor. Not as a UI trick. Not as a replayed prompt pretending to be continuity. The project now has real-runtime evidence that an agent can move from a local runtime to a remote GPU runtime, continue work there, export the advanced state, return home, and continue from the returned evidence.
That does not mean PermeantOS is finished. It means the foundation has crossed a line. It is no longer just a research preview. It is becoming an open-source platform.
What I Proved
The main proof path used Qwen/Qwen2.5-0.5B-Instruct and moved live KV state from Apple Silicon MLX to an AWS NVIDIA vLLM target. PermeantOS captured the source KV cache, normalised it through USXF, transported it over the production transport path, allocated compatible vLLM target blocks, wrote the migrated state into vLLM, seeded prefix-cache metadata, and validated continuation across a 128-token horizon.
The important part is not only that the tensors arrived. The target runtime accepted them as live state and continued from them.
The migration package also carried a 27-node Agent Memory Graph. That graph included task state, artefacts, retrieval context, pending work, provenance, and policy-relevant evidence. On the AWS target, the agent resumed pending work and produced a new artefact. PermeantOS then exported the target-advanced runtime boundary through a reverse API, imported that state back into MLX, returned the updated graph and artefacts to the origin, and continued again from the proof that work had happened remotely.
That is the shape of the breakthrough: not simply moving bytes, but preserving continuity across a round trip.
Why This Is Different From Replaying A Prompt
A replay can look convincing from the outside. If I send the same prompt to two runtimes, I may get similar text back. That is not migration.
Migration means the target runtime receives the operational state that the source had already built. It means the target does not need to reconstruct the entire prefix as ordinary prompt processing. It means the target can be validated against hashes, block metadata, token-span alignment, prefix-cache state, continuation behaviour, and agent graph evidence.
PermeantOS is built around that distinction. USXF carries the meaning of the state, not only the bytes. The Agent Memory Graph carries the work around the model state, not only the model cache. The evidence reports tie claims to concrete runs.
The claim is deliberately precise: PermeantOS has proven agent movement for validated runtime/model paths. It has not proven universal migration for every model, every tokenizer, every attention layout, or every runtime. That broader matrix is the platform work ahead.
The Runtime Story Is Widening
The first major path was MLX to vLLM. That mattered because it crossed both host and runtime boundaries: local Apple Silicon to AWS NVIDIA GPU, source runtime to serving runtime.
The follow-up work broadened the evidence. TinyLlama validation added another model family shape. A local MLX-to-llama.cpp proof showed canonical KV tensors exported from MLX being fed into llama.cpp’s internal KV memory through a raw writer, with tokenizer, span, position, and continuation alignment checked at the boundary.
That llama.cpp path matters because it is an independent open-source runtime story. It is not enough for PermeantOS to work inside one carefully controlled integration. The platform has to keep proving that its canonical state representation can cross real runtime boundaries.
The next maturity step is obvious: more adapters, longer horizons, automated evidence jobs, and a public compatibility matrix that says exactly what works, what is experimental, and what is not supported yet.
QATQ Moves Out So PermeantOS Can Stand Clearly
One important decision was to stop making QATQ part of the core PermeantOS claim for now.
QATQ, Quaternion-Augmented TurboQuant, is promising. It may become a serious codec for KV cache compression. But it deserves its own project, its own benchmarks, its own losslessness work, and its own release path. PermeantOS should not ask users to trust the migration breakthrough because of an experimental compression codec.
So the platform claim now stands on raw and FP8 state movement, exact continuation evidence, graph integrity, and runtime acceptance. QATQ can mature separately and fold back in when it is ready as a crate, binary service, or runtime-native codec.
That separation makes both projects healthier.
From Proof To Platform
The website now describes PermeantOS as a validated early platform, not merely as a research preview. That is a deliberate shift, but it comes with discipline.
A successful proof is not the same thing as a platform people can trust. The next phase is about making PermeantOS easy to try, easy to inspect, and honest about exactly where it works today.
That means a newcomer should be able to install it, run a real migration demo, read the evidence, and understand which models and runtimes have been validated without needing to follow the entire research trail. Contributors should be able to add a new runtime path from clear adapter contracts rather than guesswork.
The breakthrough now has to become repeatable: packaged releases, practical examples, public compatibility notes, and evidence that keeps growing as more runtimes are brought into the migration matrix.
Why This Matters
Agents are becoming more useful, but their continuity is still fragile. They live inside context windows, process memory, vendor APIs, local machines, and runtime-specific caches. When the machine changes, the agent often effectively dies and gets reconstructed from text.
I do not think that is good enough for durable agent systems.
If agents are going to do long-running work, they need portable state. They need to move toward hardware that suits the task, away from hardware that is overloaded or expensive, and back again when the work is done. They need memory that is not only conversational, but operational. They need evidence that work continued, not just logs that something was reissued.
PermeantOS is an attempt to build that layer in the open.
The careful version of the claim is this: PermeantOS has shown that agent state migration can work across validated real-runtime paths, including remote execution and return-home continuation.
The shorter version is the one that still makes me grin a little.
Agents can move.
What Comes Next
The next work is productisation, not victory laps.
PermeantOS needs broader runtime support, especially practical open-source targets like llama.cpp and additional model families. It needs longer-horizon tests that are affordable but meaningful. It needs public evidence automation. It needs release engineering. It needs packaging. It needs a serious documentation hub. It needs clean adapter boundaries so other engineers can bring their own runtimes into the migration matrix.
The goal is not to claim magic. The goal is to build a precise, inspectable, open platform for portable AI state.
If the first post was the question, this one is the answer beginning to harden into infrastructure.
The machine should not own the mind. The agent should be able to carry itself forward.