Drafts, audit logs, or 'don't': three ways platforms handle AI agent writes

Three platforms shipped AI agent write access in the last year. All three had to answer the same question — what happens when the agent writes something wrong — and they gave three genuinely different answers.

I read the documentation for a comparison project and ended up with three quotes that are more interesting side by side than apart. None of these companies is wrong. They are solving the problem at different layers, and knowing which layer yours is on saves you from adopting the wrong mechanism.

Sanity: drafts, by default

Sanity's Agent Actions are event-driven APIs that generate, transform and translate content. The notable part is the default:

By default, Agent Actions never mutate a published document. Whenever you supply a published ID, the action creates a draft first before applying any changes.

And if you run one against a published document, the new value "was written to a new draft document and will need to be published."

You can turn this off with forcePublishedWrite: true, and schemas marked liveEdit: true already behave that way. But the safe path is the default — which is the opposite of how most products shipped agent write access, and it deserves more credit than it gets.

What it buys: nothing reaches a reader until a human publishes it.

What it does not answer: whether the value is correct. A draft with a confidently wrong number in it looks exactly like a draft with a right one.

Notion: audit logs, after the fact

Notion 3.6 (July 2026) shipped External Agents, and the first two are Claude and Cursor. You "assign them tasks from a board shared with your whole team, @-mention them like teammates, and watch them run." Custom Agents run on schedules and triggers; AI Autofill brings them directly into databases.

For oversight, Enterprise plans get this:

The audit log includes Custom Agent activity, so you can see when an agent runs, what it changed, and who triggered it.

That is a real mechanism. It answers who changed this, and when.

What it does not answer: should this have become true — and it answers the first question only after the write has landed.

This is the part worth sitting with. Audit logs were designed for a world where writes were slow and the next reader was a person. An agent can update 800 rows in a minute, and the next reader is usually the next agent run, a scheduled report, or a page a customer sees. By the time a human notices, the wrong value has been read, summarized and acted on.

"You can see what the agent changed" and "you can control what the agent changes" quietly stopped being the same promise.

Supabase: don't point it at production

Supabase positions itself as "the complete Postgres developer platform built for agentic workloads" — MCP server, Agent Skills, RLS on every call. Their own engineering post about agents is unusually candid. Agents, they write:

• "skip RLS policies on exposed schemas"
• create views without security_invoker = true, "which silently bypasses RLS"
• miss that "UPDATE requires a SELECT policy. Without one, updates silently return 0 rows"
• "hallucinate CLI commands that don't exist"
• "ignore the docs entirely, relying on training data that may be months out of date"

And plainly: "agents are lazy about it."

Their conclusion follows from the evidence:

We strongly discourage connecting the Supabase MCP server to your production database.

Local or staging only.

That is sound advice, and it is worth noticing why it is sound. Look at their list again: every item is a failure of correctness, and the mechanism being asked to catch it — RLS — governs permission. RLS answers may this caller write this row. It cannot answer is this the right value. An agent with entirely correct permissions writing a confidently wrong number passes every check the database has.

At the engine layer there is no other answer available, which is exactly why "keep agents off production" is the honest recommendation rather than a cop-out.

Three layers, not three grades

Put the three next to each other and they are not competing implementations of one idea. They are three different layers:

Platform	Gate	Unit	Catches
Sanity	Before publication	The document version	Content reaching an audience unreviewed
Notion	After the write	The session	Attribution — who ran what, when
Supabase	At the connection	The environment	Agents touching production at all

Each is well-matched to what that product is for. Sanity's destination is a reader, so the gate is publication. Notion's surface is a collaborative workspace where most edits are low-stakes, so the mechanism is attribution. Supabase is infrastructure, where the only lever available is who may connect.

The gap all three leave open is the same one: a write that is permitted, well-formed, and false.

How to tell which one you need

Three questions, in order:

1. Does the output get published to an audience? If yes, a publication gate is the right mechanism, and Sanity's default is the shape you want.
2. Is the next reader a person who was watching? If yes, attribution is enough — an audit log answers the questions that actually get asked.
3. Is the next reader another agent, a report, or an app? Then neither gate helps, because nothing in the path evaluates whether the value is true before something downstream consumes it.

The third case is where teams get surprised. It looks like the first two until a wrong row has been read by four things before anyone opens it.

What closes it: a pull request for your data

Developers already have the mental model. Code does not go straight into main. It goes through a pull request: a diff of exactly what changes, an author, a place to comment, an approval, and a merge commit that records when it became real.

Agent writes to data today are the equivalent of giving everyone direct push access to main. The three gates above are each a partial substitute — publication review is a release branch, an audit log is git log with no review step, and "don't connect to production" is not granting access at all.

What none of them is, is a pull request. Applied to data, that means:

Pull request	Applied to a data write
The diff	Which fields change, from what to what
The author	Which agent proposed it, on what evidence
Review	A person sees it before it is true, not after
The merge commit	When it became canonical, and who decided

The same shape applies to what an agent knows, not just what it writes — prompts, instructions and reusable skills drift exactly the way code does, and benefit from exactly the same treatment.

What that looks like in practice

Busabase is the third option — a workspace built so the write path is a pull request by default. It is MIT-licensed and runs locally, so the fastest way to judge it is to run it rather than read about it:

npx busabase server
# → http://localhost:15419/dashboard/local

No signup, no account, no cloud. It starts with an embedded Postgres (PGlite), local file storage, and demo content already in place.

Point an agent at it — MCP, an Agent Skill, or the OpenAPI surface at /api/v1 — and have it write something. This is what arrives:

The changed fields with before and after, which agent proposed it, the source it used, and a comment thread. You approve, request changes, or reject. Approved values become canonical and keep the proposer, reviewer and commit attached.

Two honest limits: review is proportional to consequence — low-stakes writes stay fast, and a key with merge rights merges immediately — and if nothing your agents write is worth inspecting, this whole mechanism is overhead you do not need.

---

Disclosure: I work on Busabase, which is an open-source database and workspace for AI agents and takes the third approach — material writes arrive as reviewable proposals with a field-level diff. If you want the longer version of these comparisons, we publish them with the sources: vs Notion, vs Sanity, vs Supabase. Each one states where the other product is the better choice, because a comparison you can tell is rigged is worth nothing.

Sources: Sanity Agent Actions docs, Notion 3.6 release notes, Supabase — AI Agents Know About Supabase. They Don't Always Use It Right.. Verified 21 September 2026; all three ship frequently.