The dangerous moment in an AI database workflow is not always execution.
Often, it is the moment before execution, when nobody knows the blast radius yet.
The agent says a change is simple.
The SQL looks plausible.
The request sounds routine.
Then the query touches more rows than expected.
That is why production AI database agents need dry-run mode.
Dry-run is not a prompt instruction
“Check before you act” is not enough.
A real dry-run is enforced by the database or server-side tool layer. It lets the agent prepare a proposed operation, but prevents the side effect from happening until the system has produced a structured preview.
A useful dry-run result should include:
- operation type
- affected row count
- affected entity IDs or sample IDs
- before/after values for writes
- tenant or workspace scope
- policy checks passed or failed
- query budget impact
- approval requirement
- rollback or compensation hint
- audit event ID
The final execution should be deterministic. Not “let the model generate fresh SQL again.”
Longer version: Dry-run mode for AI database agents
The practical rule:
If the agent cannot preview the blast radius, it should not execute the operation.
Top comments (1)
This is exactly the right framing. I would add one more constraint: the dry-run output should become the approval artifact, not just an advisory preview.
The system should bind the final execution to the previewed operation: same query template, same scoped inputs, same policy version, same expected blast radius. If the agent has to regenerate the SQL after approval, the approval is weaker than it looks.
The useful receipt is: preview generated, human/system approved these exact bounds, execution consumed that approval, result matched or diverged from the preview.