Agent safety loop

Restore points turn risky changes into an undoable loop - create a checkpoint, apply, verify, and recover into a preview if it went wrong.

The problem

AI agents are good at writing migrations and bulk updates, and bad at knowing when one quietly destroyed data. A run_sql that drops the wrong column looks exactly like one that succeeded. The safety loop makes every risky change checkpointed and verifiable, so a mistake is a detour instead of an incident.

The loop works the same for humans - the MCP tool names below map one-to-one onto CLI commands.

The loop

Before a risky change - a schema migration, a bulk UPDATE, destructive SQL:

Checkpoint. For a backup-backed point, run create_backup, wait for the job to complete, select its backup_key from list_backups, then call create_restore_point with kind: backup and that key. On PITR-eligible plans, kind: pitr pins a timestamp instead.
Apply the change.
Verify. Check row counts, run the test suite, get_schema to confirm the structure - whatever proves the change did what was intended.
On failure: call restore with the restore_point_id. The checkpointed state lands in a preview database - production is not touched - where the agent can inspect the pre-change data and repair from there.
On success: delete_restore_point. The underlying backups follow the normal retention policy.

With the CLI and a PITR-eligible project:

capydb restore-points create --label "before-orders-migration" --kind pitr
# ... apply and verify ...

# On failure - recover the checkpoint into a throwaway preview:
capydb restore --restore-point <id> --preview-name recover-orders --wait

# On success:
capydb restore-points delete --id <id>

Previews stay the sandbox

Restore points guard changes to the production cell; preview databases remain the throwaway sandbox for everything exploratory. The division of labor:

Rehearsing or experimenting? Clone a preview, break it freely, reset or delete it. No checkpoint needed - the preview is the checkpoint.
Changing production deliberately? Run the loop above. The restore point is cheap insurance against the change being wrong in a way verification catches too late.

An agent that rehearses a migration in a preview first and then runs the loop against production gets both layers.

Production overwrites are deliberately out of reach

The restore MCP tool can only target previews - restoring a restore point, backup, or PITR timestamp into production is not exposed to agents at all. Overwriting the project database is irreversible, so it requires an explicit confirmation flag and the org admin role, and is only available from the dashboard and the CLI (capydb restore --target-kind project --confirm-project-overwrite). A human makes that call; see Backups and restores.

This is why step 4 lands in a preview: the agent recovers the data and proposes the fix, and if production itself must be rolled back, a human performs the overwrite - usually after inspecting the restored preview first.

MCP tool summary

Tool	Role in the loop
`create_restore_point`	Pin an existing `backup_key`, or a PITR timestamp, before the change. It does not start a backup job.
`list_restore_points`	Existing restore points plus the project's PITR window.
`restore`	Recover a `restore_point_id` (or backup / PITR timestamp) into a new or existing preview. Never production.
`delete_restore_point`	Retire the checkpoint once the change is verified.
`get_schema` / `run_sql`	Verification: confirm structure and data landed as intended.

The full tool surface and setup are in the MCP server reference; the one-prompt setup path is in Set up with an AI assistant.