Arlem

Insights / Legatus · Tabula

Preview, then confirm: letting an AI write to your books without losing sleep

The question every owner asks before an agent touches real data: what if it gets it wrong? The answer is a design rule, not a better model. Model proposes, person confirms, code writes.

TopicGuardrails
SystemsLegatus · Tabula
PublishedSeptember 2026
Reading time5 min

The fear is correct

Language models are probabilistic. They will, occasionally, read "four" as "fourteen", pick the wrong customer with a similar name, or invent a field that was not in the message. In a chat that is a typo. In a ledger it is a wrong balance that compounds for months. Anyone who says "the model is accurate enough" has not run one against real invoices for a year.

So the goal is not a model that never errs. It is a system where the model's errors cannot reach the database unnoticed.

The rule

Model proposes
It reads the message or document and produces a structured proposal: which rows, which values, which accounts. It never has a "write" tool.
Person confirms
The proposal is rendered as a preview a human can read in five seconds, with the consequences spelled out. One word commits it.
Code writes
Deterministic code validates the proposal against the schema and the business rules and writes it in one transaction. If anything does not fit, the write is refused and the reason is shown.

This is the same separation a good finance team already has: the junior prepares the entry, the senior approves it, the system posts it. We simply made the junior an AI.

What a preview has to show

  • Every value that will be written, in the user's words, not in field names. "Café Norte · 5 kg · 1,250,000 ARS", not customer_id=17.
  • The consequences. New balance, new stock, new total for the month. Errors are far easier to catch in the consequence than in the entry.
  • What was inferred. If the message said "Norte" and the agent picked "Café Norte", say so. Ambiguity is where most errors live.
  • A way to edit without retyping: "make it 4 kg" should re-render the preview, not start over.

The other guardrails

  • Allowlists. Only known people, in known groups, can ask for writes. Everyone else gets read-only answers or nothing.
  • Rate limits. A runaway loop or a compromised phone cannot post a thousand entries in a minute.
  • Schema and rules in the database. Unknown customer, missing currency, negative stock, a sale below cost: refused at the database, whatever the model said.
  • Append-only corrections. Nothing is deleted. A mistake is reversed with a new entry that says so. The history stays honest.
  • A log a human can read. Who asked, what the model proposed, what was confirmed, what was written, when. Not for compliance theater; for the Monday when a number looks off.

Where the human can step out

Reads never need confirmation: balances, prices, stock, statements. Low-stakes writes with an easy undo (a draft, a reminder that is not sent yet) can be auto-approved once the team trusts the agent. Anything that moves money, changes a price or touches a customer's record keeps the confirmation step. In our own companies it has stayed that way after a year, and nobody has asked to remove it, because it costs one word and it has caught real mistakes.