Context > Code

Agent-first workflow: with AI doing the build, code changes aren’t the point anymore—the outcome is. checkpt captures what sits behind that outcome: context, transcript, evidence, evaluations, and the state to inspect, restore, and continue.

Git tracks code changes. checkpt captures the working state that makes outcomes inspectable and repeatable.

$ ckpt install codex $ ckpt project init "saas-killer"

What broke in the AI era

Git was built for humans typing characters into files. Increasingly, software work spans prompts, transcripts, tool calls, evidence, evaluation loops, and generated outputs.

Opaque changes: large agent-generated commits are not explainable and pull requests are not reviewable.
Context loss: the prompt, decision path, transcript, and evaluations are usually not preserved with the code.
Broken handoffs: work is harder to resume, reproduce, or transfer across people, agents, and sessions.

THE BLIND SPOT

The diff shows what changed. It rarely shows what was attempted, what was evaluated, or how to continue cleanly.

Old unit of history

Code change / commit

New unit of work

Task state / checkpoint

What is a checkpoint?

A checkpoint is an evaluated slice of work that preserves enough state to inspect, restore, compare, or continue the workflow.

Intent

Prompt, task goal, notes

Transcript

Captured session history

Evidence

Files, logs, images, outputs, datasets

Evaluation

Tests, checks, status

Outcome

Code, prototype, workflow, deliverable

{ "intent": "Refactor string calculator for delimiters", "transcript": "codex-run-014.jsonl", "evidence": ["prompt.txt", "events.jsonl", "logs/test-run.txt", "src/calc.ts"], "evaluation": "tests passed: 14/14", "outcome": { "files": ["src/calc.ts"], "status": "tests passed", "checkpoint": "ckpt-0007" } }

The wedge: one real workflow

A developer gives an agent work via a spec; the agent does the work and reports back. Later they need to inspect, restore, or continue that workflow without losing state.

1

Run an agent in a project lane

After ckpt install codex (or cursor, etc.), the agent has the checkpt skill at their disposal—so checkpoints can be created as they work. A lane gives that stream of work its own checkpoint timeline—especially when several agents or parallel runs are in play, without everyone inventing a separate folder strategy.

2

Collect transcript + evidence + outcomes

Save the AI-side execution history alongside resulting files and evaluation.

3

Inspect, restore, or continue

The checkpoint becomes a reusable unit of work, not just an end-state snapshot.

A compact CLI—and an installable agent skill—to run work, capture context, and produce checkpoints: full contextual bundles you can share and apply in a lane.

Typical flow: run → collect → create → show → restore

$ ckpt project init $ ckpt lane create refactor-calc $ ckpt run codex -- prompt.txt $ ckpt collect $ ckpt create $ ckpt show $ ckpt restore

One workflow only. The sequence matters more than the exact command count.

Lane: permanent, not a branch

A lane is the durable place where agent work lives. Context is collected there, applied there, and continued there. Unlike a branch—which forks temporarily from code state—a lane persists as the working stream for a task.

Lane: a task-scoped stream of checkpoints. The durable place where context is preserved and applied over time.
Bundles: selected checkpoints can be bundled and shared so another lane can pick up the same context, evidence, and evaluated state.
Agent applies, not human: with Git, merging branches means a human resolves file conflicts. With checkpt, the agent applies a shared bundle of context into the lane.

Lane A: checkpoints bundle into a package; bundle applies to Lane B—shared context across lanes.

Benefits and key differentiators

What makes checkpt different from Git.

Workflow object, not just file history: Git versions file changes; checkpt captures intent, transcript, evidence, evaluations, and the state to restore or continue.
Agent-first: Built for work given to an agent via spec—the agent does the work and reports back. checkpt holds the state of that workflow.
Working state in between: Most tools stop at prompts or end at code. checkpt preserves the state between intent and outcome.

Wedge in one line

checkpt solves a workflow Git does not capture: AI-native task context, evidence, evaluations, and reproducibility—without replacing Git.

The adoption challenge: distribution

Building checkpt is only part of the problem. The harder challenge is fitting it into the default path developers already use to host, deploy, and share work.

Today: checkpt already helps me build the deck and website locally. Useful.
Friction: I still have to use Cloudflare’s upload flow separately. No clean path from checkpt-backed work into hosting the way Git remotes already have.
Why it matters: A better object model alone doesn’t win adoption. Workflow insertion does. That’s where distribution and platform partnerships come in.

What we want to explore with you

How do we get checkpt into the path where work is hosted, deployed, and shared? Who’s thinking about agent tooling, hosting, or deployment—and is there a way to combine efforts?

We’d love your read

You’ve lived this wave from the build side and the investing side—does what we walked through land? What do you see that we should be paying attention to?

Does it land? Does the checkpoint / lane framing match what you’re seeing in the wild—or where would you push back?
From your vantage point: What are we underestimating, overclaiming, or missing entirely in agent-native workflow and tooling?
If there’s a thread: What would make a next step useful—wedge, distribution, a specific scenario to stress-test, or something else?

A short video of the product in action is in the works—we’ll share it when it’s ready. Today, the floor is yours.

In the room

We’re not asking for a verdict—more an honest read. Where would you poke holes? What should we be asking ourselves that we didn’t?