I want to build a time machine… for running programs

Omar Abdelrahman 12 October 2026

A few months ago, I started working on a problem that seemed much narrower:

Why should a long-running program have to replay its history just to recover from a failure?

Durable execution systems make programs survive crashes, machines disappearing, long waits, retries, and external events. But many of them recover by reconstructing execution from an event history.

That works.

But the longer the program lives, the more history there is to reconstruct.

So I started working on a different model.

I called it Transparent Continuation Checkpointing, or TCC.

Instead of treating execution history as the thing you reconstruct the program from, TCC commits the continuation state needed to resume the program directly.

In other words:

save where the program is, then continue from there.

That became the foundation of Trigora.

But while building it, I started wondering whether recovery is actually the least interesting thing you can do with a durable continuation.

Because once the execution itself becomes persistent, something strange happens.

You can start treating a running program like data.

And if you can do that, maybe you can build a time machine.

A running program should be an object you can manipulate

Imagine an AI agent has been running for three days.

It has:

called dozens of tools,
talked to a user several times,
spawned subtasks,
waited for approvals,
modified databases,
generated files,
spent money,
and accumulated a large amount of internal state.

Then something goes wrong.

Today, debugging often means reconstructing what happened from logs and attempting to reproduce the failure.

But what if you could open the actual execution and see:

checkpoint 184
    ↓
search CRM
    ↓
checkpoint 185
    ↓
call payment API
    ↓
checkpoint 186
    ↓
wait for approval
    ↓
checkpoint 187
    ↓
agent decision
    ↓
failure

Then click checkpoint 187.

Inspect the program state.

Change the code.

And resume the actual failed execution.

Not a reproduction.

The same execution.

That alone would be useful.

But it gets much more interesting.

Fork the future

Suppose you could take checkpoint 187 and fork it.

                       ┌─ GPT-6
                       │
execution → checkpoint ├─ Claude
                       │
                       ├─ different prompt
                       │
                       └─ different tool policy

Each branch begins from the exact same committed execution state.

Everything before the checkpoint has already happened.

No replay.

No repeating earlier API calls.

No charging the customer twice.

No rebuilding context.

You simply explore alternative futures.

Then you compare them.

branch A
success: 91%
cost: $1.14
latency: 18s

branch B
success: 97%
cost: $0.72
latency: 11s

And promote one branch back into the canonical execution.

That starts looking less like workflow orchestration and more like version control for live computation.

Production executions become evals

AI evals usually start from artificial test cases or from the beginning of a task.

But the interesting decisions often happen much later.

An agent may have spent hours collecting information before reaching a difficult state.

What if you could take a real production checkpoint and run 1,000 alternative continuations from it?

Change the model.

Change the prompt.

Inject a tool failure.

Change a policy.

Change a user response.

Now you are evaluating models from real execution states rather than synthetic starting points.

Every production execution becomes a potential test fixture.

And every checkpoint becomes a reproducible experiment.

That could fundamentally change how agents are evaluated.

Rewind without undoing reality

There is an important complication.

Programs do things to the outside world.

They charge cards.

Send emails.

Write databases.

Call APIs.

Spawn other agents.

You cannot simply rewind time and pretend those things never happened.

That is why I don't think the interesting primitive is a virtual-machine snapshot.

The system has to understand the difference between:

program state and committed external effects.

If an execution forks after a payment happened, the new branch should know that the payment already committed.

It must not silently perform it again.

This is where durable execution semantics matter.

The hard problem isn't serializing memory.

The hard problem is making a continuation safe in a world where the program has already changed reality.

Now make it work with programs that weren't written for Trigora

This leads to another problem I've been thinking about.

Today, using a durable execution system often means adopting its runtime or programming model.

But what if you already have a large agent built with LangGraph, the OpenAI Agents SDK, a custom Python service, or something else?

Telling developers:

Rewrite your agent on my platform.

is a pretty large ask.

So what would it take to make an existing program TCC-compatible?

I'm imagining a small instrumentation layer — something like a TCC Bridge.

It would run inside or alongside the existing program and capture enough information at safe execution boundaries to produce a resumable continuation:

existing program
      │
      │ instrumentation
      ▼
TCC Bridge
      │
      ├─ program position
      ├─ durable state
      ├─ committed effects
      ├─ waits
      ├─ child executions
      └─ runtime/code version
      │
      ▼
Trigora

Instead of moving the application to Trigora, you would make the application itself TCC-aware.

Maybe something as simple as:

app = trigora.instrument(existing_app)

is possible for some frameworks.

Or perhaps:

trigora run python app.py

could instrument supported runtimes automatically.

I don't think this can work transparently for literally every program.

Sockets, native handles, threads, GPU state, database transactions, and arbitrary memory make that much harder.

The likely abstraction is durable safe points.

At those boundaries, ephemeral machine state can disappear, while the semantic state required to continue becomes durable.

The research question becomes:

What is the minimum instrumentation required to turn an ordinary async program into a safely resumable continuation?

I think that question is extremely interesting.

Then make computation portable

If a continuation is sufficiently self-contained, another possibility appears.

Why should it resume on the same machine?

Or even the same infrastructure?

Imagine:

Cloudflare → AWS

machine A → machine B

US → Europe

runtime v1 → runtime v2

local → cloud

A running computation could potentially move while preserving its logical execution state.

The machine becomes implementation detail.

The continuation becomes the unit of computation.

I'm not claiming Trigora can do all of this today.

It can't.

Today Trigora is much more concrete: a durable execution platform built around TCC, with direct recovery from committed state instead of history replay.

But I increasingly think recovery is only the first application of the underlying primitive.

The end state

The thing I want Trigora to eventually make possible is simple to describe:

A running program should be persistent and addressable.

You should be able to:

pause it.

resume it.

inspect it.

recover it.

fork it.

rewind it.

simulate alternate futures.

move it somewhere else.

All while preserving the effects it has already committed to the real world.

That would turn computation into something much closer to a versioned object.

Git gave us branching and history for source code.

Databases gave us transactions and snapshots for data.

Virtual machines gave us snapshots of machines.

I want TCC to eventually give us something similar for execution itself.

Not a history you have to replay.

A history you can navigate.

That's the time machine I want to build.

I'm building the first pieces of this at Trigora. The current TCC engine and platform are available on GitHub. I'm especially interested in hearing from people working on runtimes, compilers, durable execution, distributed systems, and long-running agents who think this idea is either promising or completely wrong.