Original data · September 2026
Which Odoo AI tools actually verify what they wrote? We counted.
Approval before the write and a log after it are common. Re-reading the row the database actually kept is the rarest check in the category. A dated count, September 2026.
We reviewed more than a dozen public Odoo AI-agent and AI-write tools and sorted what each one claims, in its own words, into the three checks people keep calling "verification." About half describe an approval or dry-run before the write. Nearly every governed tool describes a log of the attempt. Re-reading the committed row and comparing it, field by field, to what the agent was asked to do is by far the rarest. Among the listings we reviewed, almost none describe it. Most stop at "the tool reported success."
Approval checks the plan. The log records the attempt. Only re-reading the committed row tells you what the database actually holds.
Written by nanti.ai. We build the Execution Layer for Odoo, which exists to do the rarest check, so read us knowing that. We name no product on this page on purpose: this is a count of a category’s habit, not a scoreboard of names. Corrections welcome at hello@nanti.ai.
Why the gap matters
That gap is the whole point.
Approval checks the plan. The log records the attempt. Only re-reading the committed row tells you what the database actually holds. A write can pass approval, report success, be logged perfectly, and still have stored the wrong value or landed on the wrong record. Nothing that checks before the write, and no log of what the write claimed, will catch it.
The three checks, on one axis
Before, tried, and after.
Three things get called "verification" and only one of them reports what is in your ledger. Line them up on a single axis, with what the category actually describes for each, and the habit is unmistakable.
Approval or dry-run
checks what would happen
About half describe it
A human-approval gate, a diff, or a savepoint preview that shows a proposed change before it commits. Good, and increasingly common across the category. It inspects the plan, not the row the database ends up holding.
The audit log
records what was tried
Nearly every governed tool
A log of what the agent asked for and what the tool returned. Also good, also common. But what the tool returned is the tool’s own claim, so a faithful log records a false success exactly as it was reported.
Re-reading the row
confirms what the database now holds
By far the rarest
Re-reading the committed record from the database and comparing it, field by field, to what the agent was asked to do. Among the listings we reviewed, almost none describe it. Most stop at "the tool reported success."
The finding in one line: the category has largely solved before and after-the-attempt, and largely skipped after-the-commit. The rarest check is the only one that reports what is actually in your ledger.
Why we counted, and how
We counted instead of asserting.
Google prints "Missing: verified" on the Odoo write-safety results. We wanted to know if that was a wording quirk or a real hole, so we counted instead of asserting. The method was written down before we looked at a single listing: inclusion rules, the three columns, and the rule that every classification uses only the tool’s own public text, so the columns were not drawn to fit the answer. It is published in full.
Every tool is recorded as Claims, Does not claim, or Demonstrates, a verifiable statement about the public record, never "fails." We did not test anyone’s product and will not accuse one.
If your tool re-reads the committed row and we did not capture it, write in and we will fix the number. We update a row within 48 hours of a vendor showing us the public text we missed. Corrections go to hello@nanti.ai.
We name no product on this page on purpose. This is a count of a category’s habit, not a scoreboard of names. Read the pre-registered method, written before the sweep: the census method.
Our own row
We built for the rarest check.
We build the Execution Layer for Odoo, so read this row knowing where we stand. Where others ship a connector that lets an agent act, we ship the full suite that also does the one check almost nobody does.
Every write is re-read after commit on a fresh, independent cursor and compared field by field to what the caller intended. A mismatch returns VERIFICATION_FAILED naming the offending field, not a happy echo. We prove it to ourselves by deliberate fault injection: a test corrupts the stored value and the product refuses to report success.
The positive path is verifiable on staging, and the full fault-injection demonstration ships with the product. It runs on Odoo 19, ships complete rather than as a paid-later half, and is available now.
That is the difference between claiming verification and doing it, and doing it is the check this whole count was about.
Plain answers
Asked, answered.
Isn’t an approval step the same as verification?
No. Approval inspects a proposed change before it commits. It cannot tell you what the row holds after it commits. Checking a plan beforehand and confirming the stored value afterward are two different jobs, and only the second is verification.
Isn’t an audit log verification?
No. A log records what the tool reported. If the tool reports a success the database never received, a faithful log records that false success perfectly. A log is a record of the claim, not a check of the fact.
What does "re-reading the committed row" actually mean?
After the transaction closes, read the record back on a separate database connection and compare each changed field to what was intended. If they disagree, report the write as failed and name the field. That is the check the census counts, and it is the one almost no listing describes.
How many tools did you review, and when?
More than a dozen public Odoo AI-agent and AI-write listings, in September 2026, classified from their own public text under a pre-registered method. The set is a sample of what is public, not a claim to have found every tool. The published count is always "listings reviewed under these criteria," never "all" or "every."
Can I check this myself?
Yes. Open any tool’s public page and look for one sentence: after the write commits, is the row re-read from the database and compared to intent? If the page only mentions approvals, dry-runs, or a log of what the tool returned, it is not describing this check.
The rarest check
Read the row the database kept.
Approval checks the plan. The log records the attempt. Only re-reading the committed row tells you what your Odoo actually holds. See how you verify what an AI wrote to Odoo, and can AI write to Odoo safely. The method behind this count is published in full: the census method.
Evaluating an AI tool that writes to your Odoo?
Name it. We read its public docs and your description and tell you, in writing within five working days, whether it checks the proposal before it writes, logs the result, or re-reads the committed row after. Sourced line by line, using the same pre-registered method as our public write-verification census. Free, no pitch, and we tell you the truth even if the tool is not ours.
Get the Write-CheckOur own write-verification, the Execution Layer for Odoo, is available now. The verdict stays honest either way.
Not ready to talk? Follow what we ship.
An email when something real ships. No newsletters, no spam.
Living this problem every day and want to shape what comes next? We work closely with a small number of Odoo teams on the Execution Layer for Odoo, the ones building AI that writes into Odoo and want a second pair of eyes on the write path. Tell us about your Odoo setup.