Instant Branches: Let an Agent Write to a Throwaway Copy of Production
Read-only enforcement is the safest credential you can give an agent, and the right default. It is also the wrong answer when the agent's job is to write: a backfill, a generated UPDATE you want to verify, a migration, a data fix. Refusing every write is correct for a question-answering agent and useless for one that is supposed to change data.
The instinct to avoid is "well, give it write access to production then." There is a better option. Give the agent its own copy of the database to write to.
What an instant branch is
A PgBeam instant branch is an isolated, writable copy of your database, scoped to a credential. It has four properties that make it practical for agents:
- Instant: the branch starts from production's current state and spins up in seconds, not the minutes or hours a full restore would take.
- Isolated: writes land on the branch and never on production. The agent can
INSERT,UPDATE,DELETE, and run DDL freely. - Lightweight: the branch does not duplicate your data up front. It starts from production's current state and only stores what the agent actually writes, so it is cheap to create.
- Scales to zero: an idle branch costs nothing to keep around, and a discarded branch is gone.
The agent connects the same way it always does: a scoped credential or the hosted MCP endpoint. The only thing that changes is the target. A branch credential routes the session to a fresh branch instead of the production upstream.
The workflow
- You mark a credential write-capable against a branch instead of production.
- The agent opens a session. PgBeam provisions a fresh branch from the database's current state and pins the session to it.
- The agent writes freely against the branch, as if it were production.
- You inspect what changed: which statements ran, which rows moved, the full audit trail for the session.
- You discard the branch, or promote its changes after review.
If you never promote, the agent's writes disappear with the branch. The worst case is a wasted branch, not a damaged database.
Why this is the right shape for agents
The reason instant branches matter for agents specifically is that an agent's write is speculative. The agent generated it. You do not yet know if it is correct. With a branch, the agent gets to find out by actually running the write and observing the result, and you get to find out by inspecting the branch, all without the write ever touching real data.
A coding agent can run a migration against a branch and confirm it applies cleanly before you let it anywhere near production. A data agent can perform a backfill, and you can diff the branch against production to see exactly what it did. The branch turns "trust the agent's write" into "verify the agent's write, then decide."
It is the same guarantee read-only gives you, from the other direction. Read-only says: the agent cannot change production because writes are refused. Branches say: the agent cannot change production because its writes go somewhere else. Both keep the core promise intact, an agent credential cannot alter production data, while letting the agent be useful in cases read-only cannot cover.
Humans get the same thing
A branch is just as useful for a person. A contractor needs a realistic environment to develop against, but should not be standing up infrastructure or touching production. Hand them a branch credential. They get a writable database that looks exactly like production, scoped to them, that you discard when they are done. No staging environment to provision, no production risk, no copy of the data to clean up afterward.
Where it fits
Instant branches sit alongside always-rollback dry-run, which is the lighter-weight option when the agent's write does not even need to persist for the length of a session. Use a branch when the agent needs a stable, writable environment it can work in and you can inspect. Use dry-run when you just want to see what a single statement would do and throw it away immediately.
Either way, the branch and everything on it stays under the same policy engine: audit capture, budgets, and masking still apply, because the agent is still connecting through the proxy. The only thing that is relaxed, on the branch and only the branch, is the refusal to write.
Try PgBeam or see the full feature set.