Worktrees, checkpoints and reports as data safeguards

Agentic systems change files, generate artefacts, update configuration and trigger external processes. While a person often pauses after a few steps, an agent can execute long action chains. Failure may therefore erase not only an output but intermediate states, decisions and dependencies.

Worktrees, commits and run reports are often called „backups". The label is understandable but technically imprecise. A worktree is a parallel working tree, not an independent copy. A commit does not automatically include untracked files, databases or secrets. A report can describe missing bytes but cannot restore them.

A dependable architecture separates work isolation, versioning, operational evidence and backup with tested restoration.

Worktrees isolate work, not failure

Git can connect several working trees to one repository, allowing branches to be checked out simultaneously. This is valuable for agentic work: an agent receives a named assignment in its own directory while the main workspace stays clean. Diffs, tests and approvals remain task-specific.

Isolation has limits. Linked worktrees share important repository data and references. Corruption, misconfiguration or loss of the common repository can affect several trees. External dependencies—databases, object stores, model artefacts, caches and secret stores—are not copied by adding a worktree.

A worktree is therefore a collision and contamination boundary. It protects parallel changes from accidental mixing. By itself it does not protect against hardware loss, destructive cleanup, malicious encryption or common-storage failure.

The baseline must be known

Before an agent begins, a run needs an origin reference: repository, branch, commit ID, index state, working-tree changes, untracked files, submodules, relevant tool releases and referenced external snapshots.

A clean start is easier to verify than an unknown dirty workspace. If existing changes are required, the run does not inherit them silently. A preflight manifest classifies each as assignment input, protected foreign state or blocker.

git status exposes the index, working tree and untracked files, but visibility is not preservation. Untracked files remain outside commits until deliberately added. Ignored files need a separate policy.

A checkpoint is a semantic state marker

Not every commit is a useful checkpoint. A checkpoint marks a state to which the project can meaningfully return: „import complete", „schema migrated and validated", or „publication package prepared but not approved".

It is atomic enough to understand and complete enough not to depend on invisible intermediate actions. It contains or references the commit ID, external snapshots, artefact versions, schema and tool releases, validation results, known deviations, owner, time, run ID and next permitted transition.

Names do not replace immutable identity. A branch or tag can move; the commit ID addresses a concrete Git state. External objects need stable IDs, versions or hashes.

Commits capture only the versioned slice

A commit is a strong basis for reconstructing file state, but not a snapshot of the entire project. It records content selected through the index or a targeted commit. Local databases, binaries, generated exports, logs, credentials and untracked files may remain outside.

A state inventory therefore distinguishes versioned source, non-versioned authoritative data, reproducible outputs, runtime queues, external services, secrets and disposable cache. Each class needs a different recovery route. Cache may need no backup but requires a rebuild procedure. Secrets stay outside Git and return through a protected secret lifecycle.

A run report is evidence, not a copy

The report connects assignment, baseline, plan, actions, tool calls, diffs, tests, approvals, checkpoints and outcome. It answers what was intended, what occurred, which state resulted, what changed externally and what remains open.

Stable references matter. Instead of „current file", the report records path, version or hash. Instead of „backup succeeded", it records the job, destination, verification and last restore exercise. Reports are retained outside volatile runtime state and cannot be silently overwritten.

Yet a report does not replace payload data. Its value lies in provenance, diagnosis and selection of the correct recovery point.

Real backups need a separate failure domain

A copy on the same device, account or administrative path may be destroyed by the same event. Dependable backups occupy a separate failure domain through another storage system, independent permissions, immutable retention, geographic separation or an offline copy as risk requires.

A Git remote improves availability but is not automatically complete: unpushed commits and local references may be absent, and damaging changes can replicate. A full bundle can package Git objects and references for transport. It still requires separate storage, protection, verification and restoration testing.

External data needs application-consistent snapshots. Copying files from a running database may yield an unusable set. Checkpoint and backup must be coordinated: the report references the exact database snapshot that matches the commit and schema release.

RPO and RTO define recovery objectives

Recovery Point Objective describes acceptable data loss in time. Recovery Time Objective describes how quickly service must return. Both follow impact rather than tool convenience.

A daily copy may be inadequate when an agent performs thousands of hourly changes. A reproducible intermediate export may not need continuous protection. Authoritative state, external effect and approval points determine cadence.

Objectives cover the full system. Restoring a repository in five minutes is insufficient when database, artefacts, rights and queue take two days.

Restore tests are the truth test

„A backup exists" is a claim. A restore exercise provides evidence. It restores into isolation, checks integrity and relationships, runs defined validation and compares the result with the checkpoint manifest.

Git can check object connectivity and bundle prerequisites. Those checks matter but do not prove domain completeness. External snapshots, permissions, key access and startup order must also work. A technically valid restore can be operationally useless when the referenced data release is missing.

Exercises run regularly and after architecture changes. Teams measure actual restore time, data gap, manual work and deviations. Findings improve runbooks, automation and protection scope.

Agentic resumption requires idempotency

After interruption, an agent must not resume from the last sentence. The orchestrator reads the latest confirmed checkpoint and distinguishes proposed, prepared, executed and externally confirmed actions. Repeatable steps use idempotency keys or stable action IDs.

This prevents duplicate messages, charges or migrations. Non-idempotent actions require a state query and sometimes human decision before resumption.

Locks and leases prevent two runs from mutating one target concurrently. Orphaned locks have expiry and recovery rules; they are not deleted before the last state is examined.

A safeguard protocol connects the layers

1 · INVENTORY: identify authoritative and derived state.

2 · BASELINE: capture commit, workspace and external snapshot references.

3 · ISOLATE: provision a dedicated worktree and narrow rights.

4 · EXECUTE: make small verifiable changes with a live journal.

5 · CHECKPOINT: commit and manifest a semantically complete state.

6 · REPORT: record diffs, tests, impact, approvals and open items.

7 · REPLICATE: transfer repository and external backups to another failure domain.

8 · VERIFY: check integrity and catalogue the recovery point.

9 · RESTORE: rehearse restoration in isolation.

This protocol does not turn version control into backup. It connects technical state, meaning and recoverability so all three can be demonstrated together.

Exercise: Design a Recovery Chain Map

1. Inventory Git files, untracked data, databases, artefacts, secrets, queues and caches.

2. Assign owner, authority, backup method, RPO and RTO to each class.

3. Define the worktree baseline and preflight manifest.

4. Specify three semantic checkpoints with entry and exit criteria.

5. Design a run report with stable references and evidence fields.

6. Select a separate failure domain and define encryption and retention.

7. Write a restore exercise including interruption and resumption rules.

Reflection: Which important project state currently sits outside version control? Which „backup" has never been restored completely?

All materials to download — the topic overview and the worksheet:

Scope: The model is product-independent; retention, encryption and recovery requirements depend on data class, risk and applicable obligations. Editorial and technical review: 17 July 2026.