Agent safety loop

The problemCopy Anchor Link

AI agents are good at writing migrations and bulk updates, and bad at knowing when one quietly destroyed data. An execute_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 loopCopy Anchor Link

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

1. 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.
2. Apply the change.
3. Verify. Check row counts, run the test suite, get_schema to confirm the structure - whatever proves the change did what was intended.
4. 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.
5. 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 sandboxCopy Anchor Link

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 reachCopy Anchor Link

The restore MCP tool can only target previews - restoring a restore point, backup, or PITR timestamp over the project database is not exposed as an MCP tool at all. Overwriting the project database is irreversible, so the control plane gates it three ways: it is refused on production projects (the default environment), it needs an org-wide API key or an org admin session, and it needs a single-use approval token for that one restore - which only a person can create, in the dashboard, because API keys cannot mint approvals. A human makes that call. It is available from the dashboard, the CLI (capydb restore --target-kind project --confirm --approval-token <token>), and the API; see Backups and restores.

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

MCP tool summaryCopy Anchor Link

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.