Give Your AI Agents a Queue, Not Database Access

The natural way to build an agent with tools is to give it the tools. Read the database, write the database, send the email.

It works, right up until it does not, and the failure is rarely one bad action. It is forty of them, discovered later, each one now with consequences.

The fix is small and structural: the agent never writes to a real table.

The pattern

Every write tool an agent has writes a proposal into a pending_actions table, with a status of pending. That is all it can do.

A separate endpoint — triggered by a human clicking approve — reads the proposal, performs the real insert, and marks it approved. Rejecting marks it rejected with a note.

agent → pending_actions (pending) → human review → real INSERT
                                  ↘ rejected + note

Two properties fall out of this that are worth more than they look.

Every action becomes reversible before it happens. A queue converts an irreversible operation into a draft. The cost of a bad proposal drops to the seconds it takes to read and reject it.

The system-generated fields stay out of model hands. When a post is approved, the publish timestamp and reading time are computed at approval time, not taken from the model. Anything derived from real state should be computed by the code that owns that state.

Where the boundary goes

Not every tool needs the gate. The split I use:

Direct, no gate — reads. Query posts, clients, subscribers, business context. Web search. These are safe by construction: worst case is a wasted call.

Gated — anything that creates or changes a record. New content, new tasks, converting a lead into a client.

Gated and mark-only — anything that would leave the building. Social posts, newsletter drafts, outreach. Approving these marks them approved and fires nothing, because I have not connected the downstream systems and I would rather the gap be explicit than discover it by sending something.

That last category is worth calling out. It is tempting to wire the whole chain up because you can. An action that leaves your system — an email, a post, a message to a person — is the one category where "reversible" stops being available to you at any price.

What it costs

Honestly: some of the promised autonomy. The agent cannot run overnight and present finished work. It presents proposals, and proposals need a human.

I consider that the correct trade at this scale, and I would revisit it per tool rather than in general. The read tools already run unattended. If a specific write proved reliable over hundreds of proposals, promoting just that one is a small change — the queue does not have to be all-or-nothing.

What I would not do is start from full write access and add gates after something goes wrong. The gate is cheap to build first and expensive to retrofit, because by then the incident has already happened.

If you are building agents

Put the table in on day one. It is one table, one status column, and one approval endpoint.

The version of this you regret is never the one with too many gates.