Alerts and tickets in. Pull requests you can defend.
Delatura runs AI agents inside disposable copies of your codebase. Each run stands your app up in its own preview, replays the acceptance flows you approved against it, and hands back a branch with the evidence attached — the tools it called, the checks it ran, and the video of them running.
- one environment per run
- read-only roles stay read-only
- append-only audit trail
Writing the code stopped being the bottleneck.
An agent that opens ten pull requests a day has not saved you ten pull requests of work. It has moved the work — from writing, which one engineer does with full context, to reviewing, which another does with none. Past a certain volume your throughput falls while your activity graph climbs.
So the useful question is not how much an agent can do unattended. It is how much of what it did you can check in ninety seconds.
AI now writes or assists 61% of the average enterprise codebase, with adoption at 84% and trust at a record low. CloudBees, 2026 State of Code Abundance.
Seven stages, and one of them is a gate
Every task takes the same path, whether a person filed it or an alert did.
- 01IntakeAn alert, a ticket, a message, a person, another agent.
- 02SandboxA disposable copy of the repo, scoped to one organization.
- 03Agent runTools come from the role, and a grant cannot exceed it.
- 04PreviewThe run’s own deployment, running and addressable.
- 05Pull requestA branch into your existing review and CI.
- 06gateVerificationApproved flows replay against that preview. Video, screenshots, per-step results.
- 07ReviewAn independent pass, with the run trail attached.
The gate runs at 06, on the pull request — not before it. A failed replay is recorded on the run with its video and per-step results, so a reviewer sees it before they read a line of the diff. It does not block the merge today; your reviewers still do. Making it blocking is the next step, and we would rather say that here than let the diagram imply it.
A pull request that arrives already argued
Reviewing agent output is only expensive when you have to reconstruct what happened. Every run hands back the reconstruction.
The trail
What the agent read, every tool it called, every command it ran, how long each took, and which agent version executed — recorded as it happens, not summarised afterwards.
The replay
Each acceptance flow you approved, replayed against this run’s preview by a browser executing stored steps. No model in the loop, so the same build gets the same verdict.
The proof
Per-step results, a video of that replay, the screenshots it asserted on, and anything it downloaded — attached to the run rather than living in a dashboard somewhere else.
The failure
When a flow fails you get the step it failed at and the footage of it failing. A red result is worth more than a green one; it is the part you cannot fake.
- goto/checkout
- fillcard number
- clickPay now
- assertorder confirmation visiblenot reached
Recorded from the running product
Not mockups. Where a surface is still thin, the clip shows that too.
An agent gets exactly the tools its role allows
Roles are remits, not labels. A review agent is read-only. A verify agent runs checks and drives the preview but never edits source. Grants adjust the set inside the remit; denies always win.
The rule that matters is the one nobody else enforces: a grant cannot exceed the role. Hand a review agent a shell and it does not get one — the tool is surfaced as unavailable, with the reason, and the agent runs without it. An operator picks from a remit; they do not widen it by editing a field.
- Readrole defaultgranted
- Greprole defaultgranted
- Editgranted by operatorgranted
- WebSearchdenied by operatordenied
- Bashoutside the review role’s remitunavailable
Bash was granted and still did not land. A review agent’s remit is read-only, and a grant cannot widen a remit — so it is surfaced as unavailable, with the reason, instead of silently taking effect.
Enforced below the application
Controls that depend on the application remembering are not controls. These four sit underneath it.
| What holds | How it is enforced | Where |
|---|---|---|
| One organization cannot read another | Row-level security with FORCE on every product table, and the API connects as a restricted role — so a query that forgets its organization filter returns zero rows instead of somebody else’s data. | postgres · withOrg |
| The agent never holds your repository | It holds a copy, inside a disposable environment provisioned for that run and destroyed afterwards. The worst case is a bad branch. | sandbox provider |
| Secrets decrypt at egress, never at rest | Values are encrypted with the organization bound in, are not readable back through the API or the interface, and are redacted out of run output. | vault |
| The trail cannot be rewritten | UPDATE and DELETE are revoked on the audit table at the database, so the application cannot quietly edit history even if it is compromised. | audit_event |
What we don’t do yet
We sell a trust layer. The fastest way to lose you is to overstate one, so this list is maintained on purpose — and it shrinks in public.
- The gate records; it does not block the merge yet. A failed replay lands on the run with its video and per-step results — your reviewers are still the thing that says no.
- No SOC 2, ISO 27001 or HIPAA. No audit started. We will not write "SOC 2 ready" to imply otherwise.
- GitHub only, and no self-hosted or VPC deployment.
- No benchmarks. We have not run SWE-bench or measured ticket throughput, so we quote neither.
The ones that actually get asked
- Can I use it today?
- Delatura is in private beta. Access is granted by request while we work with a small number of teams — self-serve sign-up is closed, and we would rather onboard you properly than hand out an empty workspace.
- Where does our source code go?
- Into an isolated environment holding a copy of the repository, scoped to your organization for the life of the run and destroyed afterwards. Isolation is enforced in the database rather than in application code, so a missing filter returns nothing rather than another tenant’s rows.
- What stops an agent from doing something it should not?
- Its role. Each role carries a fixed remit — a review agent is read-only, a verify agent can run checks but never edit source — and grants adjust the toolset inside that remit without widening it. Granting a shell to a review agent does not give it one; the tool is surfaced as unavailable with the reason.
- Do you have SOC 2?
- No, and no audit is under way. What we can do is walk your security team through the isolation model, the audit trail and the data boundary in detail, and answer your questionnaire in writing.
- What happens when an agent gets it wrong?
- The blast radius is a branch. You get the failing evidence — which flow failed, at which step, with the video of it failing — attached to the run before anyone reads the diff. To be exact about today’s behaviour: that result is recorded rather than blocking the merge.
- How is this different from an AI assistant in the editor?
- Those make an engineer faster while they are typing. This handles work nobody is typing — the alert at 2am, the dependency bump, the ticket open for six weeks — and it is governed as unattended work rather than sold per seat.
Bring us a repository and a problem.
We onboard a few teams at a time with an engineer on our side for the first runs. Tell us what you would point it at and we will tell you whether it fits — including when it doesn’t.