What Makes an Agent's Write Authoritative?

"Authoritative" is a strange word to apply to a row in a database. The row doesn't know anything. What we mean is that a person is willing to act on it without re-deriving it — and that willingness has to come from somewhere.

It comes from what happened on the way in. Four things have to survive the write, and in most systems at least one of them quietly doesn't.

1. The attribution chain usually breaks at "who"

Ask a typical system where a record came from and you get created_by: api_key_7, created_at: 2026-08-14T09:12:00Z. That identifies a credential, not a cause.

The chain you actually need has three links, and only the first is normally captured:

• The credential — which key wrote it. Every system has this.
• The actor — which agent, on whose behalf, in which run. Most systems collapse this into the credential, and then every agent sharing a key becomes indistinguishable.
• The occasion — what the agent was asked to do when it produced this. Six months later, "the CRM says the deal is $40k" is unusable; "the agent extracted $40k from the Q3 renewal thread while summarizing the account" is something you can go check.

The third link is the one that makes a record auditable rather than merely logged, and it is the one almost nobody stores, because at write time it feels redundant — you were there, you remember. Attribution is written for the version of you that wasn't there.

2. A diff has to be judgeable, not just displayable

Every system can show you what changed. Far fewer let a person decide about it in the time they actually have.

The economics are unforgiving. One record changed: a reviewer reads the diff, thinks, decides — maybe thirty seconds. Forty records changed, in one proposal, each with three fields: the same reviewer has about the same thirty seconds of genuine attention, because the queue behind it did not get shorter.

What happens next is predictable and is not a discipline problem. Review does not stop; review goes shallow. The approvals keep coming, they just stop meaning anything. A rubber stamp is worse than no gate at all, because it manufactures the evidence that someone looked.

So "judgeable" is a design requirement with teeth:

• group by decision, not by row — thirty-eight records that changed the same way are one decision, plus two exceptions worth reading;
• surface the exceptions — the outlier value, the field that changed twice, the record that contradicts its own source;
• make rejection as cheap as approval — if rejecting means writing an explanation and re-running the agent, reviewers approve marginal changes to avoid the friction.

A review gate is worth exactly as much as the attention behind it. Design for the attention you will actually get, not the attention the process assumes.

3. Provenance has to survive the merge

This is where most implementations lose it. During review the context is rich — you can see the proposal, the diff, the agent's reasoning. Then it merges, and what lands in the table is the value. The context moves to an audit log, in another table, joined by timestamp and record id.

Technically nothing was lost. Practically it was, because six months later nobody performs that join. They look at the record, and the record says $40,000 with no memory of ever having been anything else.

The test is simple: can someone looking at the record alone tell where it came from and who accepted it? If they have to know that an audit log exists, and know how to query it, provenance is a feature you have rather than a property the record has.

4. Rejected changes are evidence — keep them

The instinct is to discard what wasn't accepted. It is the wrong instinct.

A rejected proposal is the only record of what you decided not to make true. It tells you which agent produces plausible-but-wrong output, which prompt drifts, which upstream source is unreliable. Delete it and every rejection becomes a private event that happened once in someone's head.

There is a second reason, less obvious and more important: keeping rejections is what makes a system of record honest about itself. A store that only remembers its accepted history is telling you a story about how it was always right. The rejected versions are the part that shows judgment was actually exercised.

Why permissions and audit logs don't cover this

Both get offered as the answer. Neither is.

Permissions decide who may write. That is a boundary around capability, drawn before anyone knows what will be written. An agent with write access to the customers table can write anything to the customers table, including something correct in form and wrong in fact — which is the whole problem, since that is exactly what agents produce.

Audit logs record that a write happened. They are written after the fact, by definition. An audit log is how you find out on Thursday what went wrong on Tuesday. It is genuinely useful and it is not a control, because at no point did it offer anyone the chance to say no.

The gap both leave is the same one: a moment, between the agent's write and the record becoming true, where a person could have stopped it. That moment is not a permission and not a log. It is a state — proposed but not yet true — that the data model has to be able to represent. If your schema has no way to hold a change that exists and isn't real yet, no amount of process gets you a system of record.

What this looks like in practice

Not every write deserves this. Applying it to everything is how teams end up with an approval queue nobody reads.

Set the boundary by consequence, not by habit:

• No gate — drafts, scratch work, retrieval caches, anything the agent will overwrite next run.
• Gate — anything another system reads downstream, anything a person will quote, anything with a customer's or a regulator's name near it.

Then keep the gated volume inside what a human can genuinely attend to. If the queue is growing faster than it drains, the answer is not a faster reviewer; it is fewer things behind the gate, better grouping, or a narrower agent brief.

How Busabase implements it

An agent connected to a Busabase workspace opens a Change Request rather than writing: a proposal holding the full set of intended changes, sitting outside the canonical data. A human reads the diff and merges or doesn't. Merged records keep their attribution — which agent, which request, which reviewer — attached to the record itself, and the history stays permanently, including the versions that were rejected.

Whether a specific write actually stops for a human is decided by the credential's permission level, not by the agent's good intentions. That is deliberate: an enforcement boundary you can point at beats a convention you have to maintain in every call.

The longer argument for why any of this makes a store authoritative is on the system of record for AI agents page. If you would rather see the mechanism than read about it, connect your agent and let it propose something you can reject.