Skip to main content

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.

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.

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 conceptWhat it means for agent state
CommitA snapshot of the agent’s full cognitive state at that moment
SHA hashVerifiable fingerprint — prove the state has not been tampered with
Parent linkageOrdered history — trace how state evolved from session to session
BranchTry a different approach without losing the original cognitive state
MergeReconcile divergent state paths after parallel exploration
git checkout <hash>Restore the agent to a previous cognitive state exactly
git blameProvenance — who changed what file and when
git diffSee 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.
# Single-file diff — everything in one place
-## Current task: Writing auth module
-## Agent name: {{AGENT_NAME}}
-## Last session: figuring out JWT
+## Current task: Writing tests for auth module
+## Agent name: my-agent
+## Last session: completed JWT implementation
The diff mixes a task update, a placeholder fill, and a session note. You cannot tell which change matters or which file was responsible.
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

1
Initialize git in the agent workspace
2
cd /path/to/my-agent/
git init
3
Commit the initial state after scaffolding
4
After running init-agent.sh, copying templates, and replacing all placeholders:
5
git add -A
git commit -m "init: initial continuity scaffold"
6
Commit after each session
7
After the agent updates STATE.md, moves tasks, or records new learnings:
8
git add -A
git commit -m "state: completed auth module"
9
Use a consistent message prefix (state:, task:, memory:, snapshot:) to make the log filterable:
10
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
11
Restore a previous cognitive state
12
To return the agent to its state at any earlier commit:
13
git checkout a3f2c1d
# HEAD is now at a3f2c1d state: completed auth module
14
The agent loads STATE.md, TODO.md, MEMORY.md, and all other files as they existed at that commit — a complete cognitive rollback.

Two history layers

Continuity provides two distinct history mechanisms that serve different audiences and different queries.
LayerMechanismAudienceWhat it answers
Byte-level snapshotsgit commits and diffsHumans, CI, toolingWhat changed, when, who authorized it — verifiable and tamper-evident
Semantic historyNested directories (snapshots/, completed/, reflections/)The agent itselfWhat was the state before this task? What did I learn last week? What was the plan for this phase?
Git answers “did this file change and when?” Nested directories answer “what was the agent thinking about when it worked on this?” Both layers are necessary. Git history is raw and verifiable. Nested directory history is structured, queryable, and agent-readable without tooling.
# Git layer — byte-level, verifiable
git diff HEAD~3 HEAD -- STATE.md

# Semantic layer — structured, agent-readable
cat snapshots/2026-06-28T14-30-00.md
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.

Auditing cognitive drift

Because every commit is a snapshot of the full state, you can audit exactly when and how the agent’s behavior or understanding changed.
# See what the agent's state looked like on a specific date
git show HEAD@{2026-06-15}:STATE.md

# Compare the agent's TODO list between two sessions
git diff HEAD~5 HEAD -- TODO.md

# Find when a specific objective first appeared
git log -S "Deploy webhook" --oneline -- STATE.md

# See the full history of the agent's identity file
git log --follow -p IDENTITY.md
Never store secrets, API keys, passwords, or credentials in any Continuity markdown file. State files are committed to git history — secrets written to STATE.md or MEMORY.md will persist in the repository’s commit log indefinitely, even after the line is deleted from the file. Use environment variables and reference them by name in state files if documentation is needed.

Build docs developers (and LLMs) love