The verification sandbox
An AI agent that proposes an improvement may be right. It may also be wrong. The verification sandbox makes the difference visible before anyone does anything on the real database.
The sandbox is a disposable copy of the database. In it the agent runs its proposal, measures the effect and compares it with the original. Afterwards the copy is always cleaned up.
The loop
- Create a copy. The platform creates a copy tied to this one task. The copy's name comes from the task itself, never from a request by the agent. An agent therefore cannot accidentally end up on another database.
- Fill it. The copy gets the content the customer allows (see below).
- Baseline. The agent runs the existing procedure or query and measures run time, reads and the execution plan.
- Apply the proposal. The agent's script is run in the copy. Only a script stored as a file with the same task, with a matching fingerprint, may go in.
- Measure again and compare. The platform compares before and after and gives a verdict.
- Clean up. The copy disappears on completion, on cancellation and on a forced stop. A cleanup service catches the rest.
What is in the copy?
The customer chooses, per source, as a rung on a ladder:
| Rung | What is in it | When |
|---|---|---|
| Synthetic | Generated data in the right structure. | Default. Good for syntax and logic. |
| Synthetic, shaped to real statistics | Generated data with the distributions and volumes of the real database. | When performance matters: the optimiser then picks realistic plans. |
| Real data | A copy of (part of) the real data. | Only if the customer explicitly allows it. |
Without permission for a rung, no copy with that content is created. The refusal happens when the task is created and again at the tool call.
Free SQL in the copy
In the copy an agent may run free SQL to check results. Limits apply there too:
- one SELECT per call, in a transaction that is always rolled back;
- a maximum number of columns, rows, run time and calls per task;
- every column in the result must be traceable to a source column, otherwise the whole result is refused;
- every cell goes to the model masked, unless the source is in open mode;
- the threshold of ten applies to aggregates.
With a copy containing real customer data, the model does not see the real table names but pseudonyms, just as on the source.
An error without a value
If running a script fails, the platform answers with the batch number, the error code and the category. Never with the text from the database engine. That text often quotes exactly the value it tripped over.
What the sandbox delivers
A report per task with:
- the baseline and the second measurement;
- the difference in run time and reads;
- the verdict, calculated with fixed thresholds;
- the scripts that were run.
The verdict is advice. Whether the change goes to production is decided by a human.
What does it cost?
A copy costs compute while it exists. The platform tracks the seconds per task and books them to the customer. Because the copy disappears after every task, you do not pay for copies that are left behind.
Example
A data engineer suspects that a view with six joins is the cause of a slow report.
- The agent reads the view definition and the statistics of the underlying tables.
- It creates a copy with synthetic data shaped to the real statistics.
- It measures the view, rewrites it with two intermediate steps, and measures again.
- Verdict: 64 percent fewer reads, same result on a sample.
- The script is ready as a file on the task. The engineer promotes it to test herself.
The number in this example is illustrative.