How do you verify what an AI agent actually wrote to your Odoo?

You re-read the record from the database on a fresh, independent cursor after the transaction commits, and compare it field by field against what the agent was asked to do. A success message is the tool’s own claim, not a fact the database confirmed. Verification is the step that turns "the tool said it worked" into "the row now holds this value", and it is the only check that can tell the difference. Reading the row back inside the same transaction is not enough, because that read sees what the transaction wrote, not what finally committed.

No. An audit log records what the agent tried and what the tool returned, which is the tool’s own account of events. If a write lands on the wrong record, or a success sentence is composed from what the action intended rather than from a database read, a faithful log records that false success exactly as it was reported. A log is a record of the claim; verification is a check of the fact. You want both, but only one of them catches a wrong value that stored and still reported success.

No, and this is the distinction most tools blur. An approval or a dry-run runs before commit: it checks what a write would do and asks whether to proceed. That catches a bad plan, and you should use it. But it inspects a proposal, not the row the database ends up holding, so it cannot see a value that drifts or lands wrong at commit time. Checking beforehand and confirming afterward are two different jobs, and only the second one is verification.

The silent wrong value: a write that stored something other than intended, or did not store at all, while the tool still reported success. An approval waved through a plan that looked fine. A log recorded the success the tool announced. Only re-reading the committed row from the database and comparing it to the intent reveals that the row does not say what everyone was told it says. That single case, success reported over a write that did not land as intended, is the whole reason verification exists.

It means every field the write was supposed to change is checked against two things: the value the caller intended, and the value read back inside the transaction, both compared to the value the database holds after commit. If any field disagrees, the write is reported as failed and the offending field is named, rather than a single blanket "success" or "failure". Naming the field is what makes a verification failure something you can act on instead of a mystery.

Because a read inside the same transaction sees the transaction’s own uncommitted changes, not what actually committed to the database. To confirm what persisted, you have to look from outside the transaction that wrote it, on an independent cursor, after commit. Verifying from inside the write is like proofreading your own sentence in your head: it confirms what you meant, not what landed on the page.

Be fair first: Odoo 19 ships a real, capable AI agent, and for reading and drafting it is well fenced. But on the write path there is no read-back. We read the Odoo 19 Enterprise source: when a server action returns nothing, Odoo composes a success sentence from what the action intended, so the record is not re-read to confirm the change landed. That means the native agent reports success from intent, not from a verified database read, and post-commit verification is exactly the property it does not provide on its own.

The Execution Layer for Odoo verifies after commit on an independent database cursor, comparing each field against both the in-transaction read-back and the caller’s intent, and reports VERIFICATION_FAILED naming the offending field rather than returning a happy echo. The behaviour is proven by deliberate fault injection: a test corrupts the stored value behind a write, and the product refuses to report success. Releases are gated on that adversarial test suite. It is available now on Odoo 19 Community and Enterprise, with the enterprise modules source-available so you can read exactly how it behaves, and the failure suite ships with the product so you can run it on your own staging. See the Execution Layer for Odoo (nanti.ai/execution-layer).