Odoo 19 · a buyer’s checklist
Should you turn on Odoo 19’s AI?
Short answer: turn on the part that reads without much ceremony, and slow down before you let it write. Reading, drafting, and reporting are useful and hard to get badly wrong. Writing to your system of record is the real decision, and there are eight questions to ask first, of any vendor, including the platform itself.
Turning on AI that can read your Odoo is low risk. Turning on AI that can write to it is where the real decision is.
Below is a vendor-neutral checklist you can hold to any AI tool that acts inside Odoo. It scores writing AI, not reading AI. It scores Odoo 19’s own native AI from Odoo’s published documentation. And it scores the products we make the same way, including where they fall short, because a checklist that hid that would not be worth using.
Written by nanti.ai. The Odoo quote below is verbatim from Odoo’s own documentation. We build the Execution Layer for Odoo, which exists to clear the bar this checklist describes, so read us knowing that, and hold us to the same eight questions. Corrections welcome at hello@nanti.ai.
The eight questions
Before you let it write.
These are the questions to ask before an agent changes a record in the system your business runs on. If a tool only reads and drafts, most of them do not apply and you can switch it on with little ceremony. The rest is for anything that can write.
- 01
Can it act, or only answer?
Some AI agents only read and draft. That is genuinely useful and genuinely low risk. If a tool only answers, most of the questions below fall away and you can switch it on with little ceremony. Everything that follows is for a tool that can write.
- 02
After it writes, where does the confirmation come from?
The question most often skipped, and the one that matters most. When the agent writes a record, does the system re-read that record from the database to confirm it landed, or does it report success because the tool said so? A log of what the tool returned is not proof the database changed correctly. Ask to see the record read back after the write.
- 03
If a multi-step action fails halfway, what happens to the steps before it?
If step three of a five-step action is denied, are steps one and two rolled back, or do they stay written while the rest fails? A half-finished write that nobody is told about is the quiet failure that costs a reconciliation weekend a month later. Ask whether actions are atomic.
- 04
When it is denied, is the denial a code or a sentence?
Does a refusal come back as a structured, machine-readable code, or as a text message the model can read, reinterpret, and route around? Authority that lives in a sentence is authority a model can argue with.
- 05
If the same action runs twice, do you get one result or two?
Networks retry. If the agent submits the same write twice, does the system produce one effect and return the original result, or a second record? Ask, in plain words, what stops a retry from double-posting.
- 06
What does the evidence record, and can it be edited?
Is there an append-only, before-and-after record of every change, kept independently of the record’s own activity log, and is it tamper-evident? A note in the record’s own chatter that an admin can edit or delete is not an audit trail you could hand a reviewer.
- 07
Where are permissions and approvals decided?
Are they evaluated on the server, outside the model’s context, so that no text the model reads can grant it more access? Or does the model’s own reasoning decide what it is allowed to do? Permission a prompt can talk its way past is not permission.
- 08
Can you check any of this yourself, or must you take their word?
Can you read the source, test on a staging copy you control, or watch it work on your own instance? Or is every claim something you have to trust? The vendors worth trusting are the ones who invite the check.
How to score the answers
Demonstrated beats claimed.
For each question, mark the vendor one of three ways. The distinction between the first two is the whole point: a claim is a promise you have not checked, and a demonstration is one you have.
They showed you, live or in source you can read. This is the only answer that has earned your trust rather than asked for it.
They say so in their materials, but you have not verified it. Worth noting, worth checking, not yet worth relying on near your ledger.
They do not do this, or cannot show it. Not disqualifying on its own, but count the "does not" answers on anything that can write.
A tool that mostly answers with "Claims" is asking for trust it has not earned. A tool that can mostly demonstrate is one you can actually let near your ledger. And a tool that invites you to check for yourself, question eight, is telling you something the others are not.
The honest baseline
Odoo 19’s own AI, scored.
Start with the platform default everyone begins from, scored only from Odoo’s own published documentation. First, be fair: Odoo 19 ships a genuine AI agent, a real tool-calling loop with retrieval and unattended execution. That is capable engineering and this is not a criticism of it. It is a deliberate, bounded design, and Odoo describes it accurately.
“The server action does not enforce business rules, modify records directly, or guarantee the correctness of the operation. Its role is limited to decision-making.” Odoo documentation
- Can it act, or only answer?Yes, it can write, through developer-authored server actions.
- Where does the confirmation come from?The record is not re-read to confirm the write; when a server action returns nothing, a success sentence is composed from what it intended.
- Multi-step action fails halfway?No rollback across a multi-step action in the AI module. Earlier steps stay written.
- Denial: code or sentence?A permission error comes back as text the model can read and route around.
- What does the evidence record?Changes are recorded in the record’s chatter, which can be edited or deleted like any other message.
None of this makes Odoo’s native AI a bad tool. It reads, drafts, and reports well, and the standard Ask AI agent, in Odoo’s own words, "cannot make changes to the database." This is the well-fenced default. Whatever you turn on to write should be measured against it, with the same eight questions.
Held to the same bar
Where we fall short, said plainly.
This checklist scores the products we make the same way it scores everything else. The Execution Layer for Odoo is built to demonstrate the write questions: every write runs in an atomic transaction, is read back from the database after commit, verified against the declared intent, and recorded with before-and-after evidence, and the enterprise modules are source-available so you can read exactly how, rather than take our word for it.
And the honest limits: we have zero published customer results, and we say so. Some of these properties pass only in the paid tier. We would rather you read the source than trust the claim, which is the point of question eight. A checklist that hid its own author’s gaps would not be worth handing to anyone.
The eight questions, answered
Asked, answered.
Is it safe to turn on Odoo 19’s AI?
Turning on AI that can read your Odoo is low risk. Turning on AI that can write to it is where the real decision is. Reading, drafting, and reporting are genuinely useful and hard to get badly wrong. The care is needed the moment an agent can change a record in your system of record. Before you let it write, ask how a write is confirmed, what happens when a multi-step action fails halfway, and whether the record of what it did can be trusted afterward.
How do you know an AI actually wrote what it says it wrote to Odoo?
You re-read the record. When an agent writes, the system should read that record back from the database on a separate connection and compare it, field by field, against what was intended. A log of what the tool returned is not proof the database changed correctly. If a write lands on the wrong record, or a success sentence is composed from what the action intended, a faithful log records that false success exactly as written. Only re-reading the row catches it.
What happens if an AI’s multi-step change to Odoo fails halfway?
It depends entirely on whether the action is atomic. If step three of a five-step action is denied and steps one and two stay written, you are left with a half-finished change that nobody was told about. That is the quiet failure that costs a reconciliation weekend a month later. Ask whether a failed action rolls back as a whole, or leaves the earlier steps behind.
Should an AI’s permission denial in Odoo be a code or a message?
A code. A refusal that comes back as a structured, machine-readable error is a wall. A refusal that comes back as a text message is advice the model can read, reinterpret, and try to route around. Authority that lives in a sentence is authority a model can argue with.
What stops an AI from double-posting the same write to Odoo?
Idempotency. Networks retry, and if the agent submits the same write twice, the system should produce one effect and return the original result rather than create a second record. Ask, in plain words, what stops a retry from double-posting. If nobody can answer that, assume a retry can duplicate a record.
What counts as a real audit trail for AI changes in Odoo?
An append-only, before-and-after record of every change, kept independently of the record’s own activity log, and tamper-evident. It keeps the values on both sides of the write, not just the fact that something happened at a timestamp. A note in the record’s own chatter that an admin can edit or delete is not an audit trail you could hand a reviewer.
Where should AI permissions and approvals be enforced in Odoo?
On the server, outside the model’s context, so that no text the model reads can grant it more access. If the model’s own reasoning decides what it is allowed to do, then permission is only as firm as the next prompt. Enforcement that a prompt cannot skip has to live on the server side of the write, deciding before the action runs.
How can you verify a vendor’s safety claims about AI in Odoo yourself?
Ask what you can check without taking their word. Can you read the source, test on a staging copy you control, or watch it work on your own instance? A vendor who invites the check is telling you something a vendor who asks for trust is not. Score each claim as demonstrated, merely claimed, or absent, and weight the demonstrated ones.
The proof layer
Read is easy. Prove the write.
The eight questions are the bar we hold ourselves to. The Execution Layer for Odoo is built to demonstrate them: every AI write read back from the database, verified, and recorded before and after. See also can AI write to Odoo safely, does Odoo’s native AI have an audit trail, Odoo MCP servers, compared, and why your AI gets Odoo revenue wrong.
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 who cannot fully trust what their AI writes to production today. Tell us about your Odoo setup.
Want the editable, white-label version of this checklist to use under your own name with your clients? No attribution required. Ask us and we will send it over.
Ask for the editable checklist