I built what you suggested for letting agents write to real data. Would you actually use it?

A few days ago I asked here how you let agents write to real data. I took the top suggestions and built them into the database I'm working on, Chronos DB, a new Postgres-compatible database where every agent gets its own copy of the whole database in about 2 microseconds, works in it with normal SQL, and you diff and merge what it did. What I built from your answers: Limits per merge weren't enough. An agent capped at 50 deletes per merge can do 500 in ten merges, so limits are now per agent per hour. A run declares its scope before the first write: which tables, columns and tenant it may change. A merge that strays outside it waits for a person. Some columns (owner, billing, identity) can be marked so any change to them needs a human, even one row. Side effects like emails and webhooks queue with the change and fire only when it's approved. A discarded attempt sends nothing. A branch left open too long can't merge without review, even if nothing it read has changed. And the default I now recommend for any agent: no delete merges without a person until you've seen enough to loosen it. It's a preview (v0.1.3), single node, source-available, not in production anywhere yet. Links and install are in the comments. What I still don't know: would you move your data into a new database built for this, or only use something that runs next to your existing Postgres?