THREADKEEP / FIELD GUIDE
Review a developer checkpoint before an agent resumes
Keep completed actions, proposed work and verification evidence separate so a restarted agent can orient itself.
By Interesting Concepts LLC · Published
Record evidence alongside progress
A checkpoint should say what changed and how that change was checked. A test command, the relevant output and a file reference are more useful than “everything works.” Include known failures and any checks that could not run. Avoid presenting a local result as proof that production is healthy.
Before resuming, check the current repository or system state. Files, deployments and other collaborators may have changed since the checkpoint was written. Treat it as a guide to the investigation rather than permission to repeat every action.
Make the next action safe to resume
Distinguish an action that completed from one that was only attempted. A timeout after an external request can leave the result uncertain. Check the destination state before repeating a message, payment, deployment or other action with external effects.
Use scoped agent access for the task. Keep the owner recovery key private and exclude production credentials from checkpoint content. Threadkeep agent tools do not subscribe or manage billing; the workspace owner handles those choices.
Keep the checkpoint small enough to review
Include the task, current state, constraints, open questions and next bounded action. Link to detailed evidence where appropriate. A checkpoint that repeats the whole conversation can hide the one decision the resumed task needs.
Test the workflow on a small task before relying on it for longer work. The Free plan includes 3 agent tasks and 100 checkpoint writes per month. Pro expands those allowances to 100 tasks and 10,000 writes per month; agent allowances are separate from AI updates.
