Every time an agent updates its state files and commits the result, git records a byte-perfect snapshot of the agent’s full cognitive state at that moment. The commit hash is a verifiable fingerprint. The parent linkage is an ordered history. The diff between any two commits shows exactly what the agent knew, decided, or completed in the interval between them. Add git to a Continuity workspace and every commit becomes a checkpoint you can inspect, revert, or branch from.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/bitwikiorg/continuity/llms.txt
Use this file to discover all available pages before exploring further.
Git concepts mapped to agent state
The standard git model maps directly onto the problem of agent state versioning. Each primitive that git provides for tracking code changes turns out to be equally useful for tracking changes to an agent’s identity, tasks, memory, and plans.| Git concept | What it means for agent state |
|---|---|
| Commit | A snapshot of the agent’s full cognitive state at that moment |
| SHA hash | Verifiable fingerprint — prove the state has not been tampered with |
| Parent linkage | Ordered history — trace how state evolved from session to session |
| Branch | Try a different approach without losing the original cognitive state |
| Merge | Reconcile divergent state paths after parallel exploration |
git checkout <hash> | Restore the agent to a previous cognitive state exactly |
git blame | Provenance — who changed what file and when |
git diff | See exactly what changed between two cognitive states |
Why git + Continuity is better than git alone
A single monolithic file in git gives you file history, but the diff is noise — every concern (identity, tasks, memory, plan) shares one file, so a task completion and an identity change appear in the same diff hunk with no separation. Continuity splits state by concern, so every file has its own lifecycle and its own diff stream.- Without Continuity
- With Continuity
Recommended commit cadence
Commit frequency determines the resolution of the cognitive history. Too infrequent and you lose the ability to trace how a decision was made. Too frequent and the log becomes noise.After STATE.md changes
Commit whenever the agent’s current status or active objective changes. These commits mark transitions between work phases.
After TODO.md updates
Commit when tasks are added, completed, or reprioritized. Each commit preserves what the task list looked like at that moment.
After completing significant work
Commit at the end of each session or after completing a milestone. Use a descriptive message like
state: completed auth module so the log is readable without opening files.Before irreversible actions
Commit before any action that cannot be undone. Combined with
CHECKPOINT.md, this gives you a restore point for the cognitive state that authorized the action.Example workflow
git log --oneline
# a3f2c1d state: completed auth module
# 9b1e4f2 task: added JWT test tasks
# 5c8a0d1 memory: recorded rate limiting insight
# 2d3f7e0 init: initial continuity scaffold
Two history layers
Continuity provides two distinct history mechanisms that serve different audiences and different queries.| Layer | Mechanism | Audience | What it answers |
|---|---|---|---|
| Byte-level snapshots | git commits and diffs | Humans, CI, tooling | What changed, when, who authorized it — verifiable and tamper-evident |
| Semantic history | Nested directories (snapshots/, completed/, reflections/) | The agent itself | What was the state before this task? What did I learn last week? What was the plan for this phase? |
For more on how nested directories provide semantic history organized by concern, see the State Files reference and the Boot Sequence documentation for how
INIT.md discovers and loads the history chain on startup.