Moving Execution Without Moving Truth.

Field entry, 15 March.

The phrase was “local and cloud teleportation”, which sounds more glamorous than the problem felt.

The actual question was practical: can a coding agent project move between cloud execution and local development without losing its mind? Or, more precisely, without asking the user to become a customs officer for their own files.

In the existing system, cloud mode had a clear authority structure. File actions happened through Podium on a Chronicle filesystem. Bash execution happened in a sandbox. The web app could show the work because the work had a canonical place to live. Files, diffs, checkpoints, and history were not vague concepts; they belonged to a system that knew how to store and replay them, which is exactly what local development complicates.

The naive version is easy to imagine: if the project is local, just let the local machine own everything, with files living locally, commands running locally, and the agent talking to the app as if that settled the matter. The trouble is that this does not feel like teleportation so much as a fork in reality.

If cloud mode and local mode each become their own source of truth, every switch risks becoming a migration. Which files are authoritative? Which history matters? Where do diffs live? What happens to a partially completed turn? What happens if local execution writes a file and the cloud view does not know? What happens if a browser reloads after the handoff?

This is the kind of problem that starts as a feature and quickly becomes a distributed systems exam, the sort one discovers folded inside the map after already leaving the inn.

The important question in the March session was explicit: are Podium and Chronicle still the authority for file edits in this plan? The answer needed to be yes, and that gave the work its principle: move execution, not truth.

The local machine can become the place where commands run. It can provide access to local tools, local services, local performance, local network state, and the particular weirdness of the developer’s laptop. But the file story should not split unless there is a very good reason. The authoritative workspace should remain the shared system that the rest of the product already understands.

This sounds abstract, but it is exactly what makes the experience coherent.

If Chronicle remains the file authority, the app can still show history. The project can still reload. Diffs can still be reasoned about. A cloud-started session can continue locally without becoming a different session wearing the same title. The UI can expose a runtime switcher instead of asking users to understand an architecture diagram.

That is where local/cloud stops being infrastructure and becomes product design. The civilized experience is not “choose your consistency model.” It is “continue here.”

The user does not want to choose between metaphysical states of file ownership. They want to continue in local mode because the task needs local resources, or continue in cloud mode because they want the laptop to sleep. The control should express that: continue here, continue there. Not “change authoritative persistence regime.”

Of course the implementation still has to deal with the ugly parts. Handoff requested and acknowledged. Host readiness. Drain phases. Rollback. Heartbeats. Blocking the client while a runtime is not ready. Not pretending a metadata flip is a durable handoff.

But the principle keeps the ugliness pointed in the right direction.

One thing I have learned from building with agents is that they are happy to implement state transitions before the states are properly named. That is dangerous. If you do not name the authority boundary, the code will invent one by accident.

In this case, naming the boundary clarified the work: file truth remains with Podium and Chronicle, execution can happen on the machine best suited to the task, and the UI offers a way to switch between those execution places without asking the user to understand the architecture underneath. The rest is orchestration, which is not easy, but at least it is honest.

There is a broader lesson here about AI development environments. The future is probably not purely local or purely cloud. Local is too useful: private services, native tools, fast feedback, hardware, developer muscle memory. Cloud is too useful: long-running work, isolation, reproducibility, sleeping laptops, remote agents. The interesting products will let work move between them.

But if they move the wrong thing, users will feel it.

Move execution and it feels like flexibility; move truth and it feels like data loss waiting to happen.

Field note

I like “teleportation” as a product word because it captures the desired feeling: I was working there, now I am working here, and nothing essential was lost in transit.

But teleportation only works if identity survives the move, and for coding agents identity is not just the project name; it is files, history, diffs, run state, permissions, and the ability to replay what happened. That is the part to protect.