Context > Code

When work is given to an agent via specification, the code diff is no longer the full unit of work. checkpt captures the working state of that workflow — context, transcript, evidence, evaluations, and outcome.

The shift is simple: when the agent does the work and reports back by evaluations, the thing that matters is no longer just the final file diff. It is the full state needed to inspect, trust, restore, and continue the workflow.

Git versions file changes. checkpt captures the working state needed to inspect, continue, and trust agentic workflows.

$ 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 diffs: large agent-generated commits are harder to review and explain.
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

File diff / 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

Start with a narrow, believable use case: 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

Associate work with a task-scoped stream instead of a generic folder mess.

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.

DEMO COMMANDS TO SHOW

Sequence: 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.

flowchart LR subgraph Git["Git: branch workflow"] direction TB M[Main] --> MR[Merge] M --> B[Branch B] B --> W[Work on branch] W --> H[Human in loop] H --> MR end subgraph Ckpt["checkpt: lane + bundles"] direction TB C[Bundle shared] --> AP[Apply to lane] AP --> AG[Agent applies context] AG --> N[No human conflict resolution] end

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?

What we want to do next

This is a good moment to pause, let you reflect and ask questions—then talk about where we go from here.

We don’t expect an answer on Thursday. We’re looking for a positive signal: what should we do next? How can we leverage what you’re offering?
If this feels promising: is there a path to a deeper conversation around support, partnership, or funding?
Your read: Where is this wedge strongest? Which teams would be the best to pressure-test it with?

How we’d like to leave it

“You’ve been thinking about this category. I’d love your read on where this wedge is strongest—and which teams would be the best to pressure-test it. Then we can figure out what makes sense as a next step.”