DEV Community: Chandan Sharma

Odoo 19 ships a real AI agent. I read the source to see what happens after it writes.

Chandan Sharma — Sat, 12 Sep 2026 14:04:52 +0000

Short answer, so you can leave if that is all you came for: nothing reads the row back. When a tool returns no value, Odoo composes a success sentence from what the action intended and hands that to the model. The agent then reports success because it was given a string, not because anyone checked the database.

Here is the longer version, with what I actually found.

First, the part most people get wrong

A lot of posts right now claim Odoo's AI is "just an API wrapper." That is false, and you can refute it with one screenshot of the source.

Odoo 19 Enterprise ships a genuine tool-calling agent loop. Up to 20 successive rounds of up to 20 parallel tool calls, with an injected termination protocol. Retrieval over an indexed corpus with a real vector field type. Unattended execution through cron. And real write capability, through server actions an administrator authors and marks for AI use.

That is an agent by any reasonable definition. It loops, it calls tools, it acts on its environment, and it runs without a human present. Odoo also made a defensible safety choice: there is no generic write tool. Writes travel only through actions a human wrote, and the ORM access rules still apply.

So the interesting question is not capability. It is what happens after it acts.

What Odoo says about that, in their own words

From the AI server actions documentation:

An AI server action acts as a decision maker, or a manager. It reads the record and its context. It interprets the AI prompt. And it decides which tool to call, and what arguments to use.

And, in the same documentation:

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.

Read that second one again if you are about to point this at a production database. Odoo is being straight with you. The agent decides. Everything else is yours to build.

Also, if you assumed the chat assistant could act:

The standard Ask AI agent cannot make changes to the database. As such, it can open views and display reports, but it cannot create leads or alter data.

The four things I found in the source

1. Nothing is read back. When a server action returns nothing, Odoo substitutes a static description assembled from the action's intent, along the lines of "Activity created for X." The model is told the write worked by a sentence Odoo composed. The database is never re-read to confirm it.

2. There is no savepoint in the module's tool execution. Picture a five-step action where step three is denied by a record rule. Steps one and two are already written and stay written. Steps four and five then run against a half-changed state. Nothing tells you the data is now inconsistent.

3. A denial becomes advice. The exception handler catches the error, converts it to a string, and returns it to the model as the tool result so the run can continue. Odoo's own code comment says this is intentional, so a prompt can say "do X, and if it fails, do Y." A permission error is a token the model can reason around rather than a wall.

4. The evidence is a chatter message. It records what was attempted, not the before and after state, and a mail.message can be edited or deleted like any other record.

Why this matters more in an ERP than anywhere else

If an agent gets a blog post wrong, you notice. If it writes to the wrong record in your ERP and reports success, nothing errors, nobody notices, and it compounds. A month later somebody is reconciling accounts and cannot work out why.

An enterprise prospect described this to me better than I could:

An agent does the wrong thing and reports success. Writes against the wrong person or record, or reads a truncated list and answers as if complete. Nothing errors. Nobody notices. It piles up. Checking the draft before it runs does not catch it, because the mistake happens during execution.

That last sentence is the one that matters. Reviewing what the agent proposed does not protect you, because the failure happens after approval.

What a write actually needs before you can leave it running

Four properties. None exotic, all checkable.

Read-back. The result handed to the model is re-read from the database after the write, not composed from the request.
Atomicity. A multi-step action completes fully or leaves no trace.
Structured refusal. A denial returns a machine-readable code, not a sentence the model can reinterpret.
Evidence. An append-only record of before and after values, independent of the record's own chatter.

If you are evaluating any AI-for-ERP tool, including mine, those four are a better test than any demo. Ask the vendor to show you the row, re-read from the database, after the write. Not the log of what it tried.

Disclosure, and my own score

I help build one of these (nanti.ai). So take the above as claims to verify rather than neutral reporting, and here is my own honest scoring against the same bar.

We do the four. Every write is re-read on an independent connection after commit and compared field by field against what the caller intended, proven by deliberately corrupting the stored value behind a write in the test suite to confirm the product refuses the happy echo. Refusals are committed on a separate transaction so the record of the denial survives the rollback of the action it denied.

Where we fall short, since a bar you only apply to other people is worth nothing:

We have not commissioned a third-party penetration test, and will not claim one.
Several of those properties are paid-tier only. A free-tier install genuinely has less.
Until this week our own core advertised an idempotency key it did not honour on the free tier, so a client retry could create a second record. That was a real defect in shipped code. It is fixed, with a test that holds it closed.
We claim tamper-evident, never tamper-proof. A database superuser who disables the trigger can still alter rows. The hash chain makes that evident rather than impossible.

None of this makes Odoo's engineering bad. It is a deliberate, bounded design and their documentation describes it accurately. It does mean that if you are about to let an agent write into your ERP, the question is not how capable it is.

It is: after it writes, where does the confirmation come from?

If the answer is that the model said so, you do not have a record. You have a rumour.

Odoo is a trademark of Odoo S.A. This is independent work, not affiliated with or endorsed by Odoo S.A.

If you have pointed an agent at your Odoo, I would like to know what it wrote that it should not have.

Your AI can query Odoo. It still gets revenue wrong.

Chandan Sharma — Mon, 07 Sep 2026 19:20:30 +0000

Connecting a large language model to Odoo used to be the hard part. It is not any more. There are MCP servers, XML-RPC wrappers, and JSON-RPC clients that hand an agent the ability to read and write Odoo records in an afternoon. Reaching the data is solved.

Understanding it is not. An agent that can run any query will still answer "what was our revenue last month" with a number that is confidently, quietly wrong. The failure is not in the connection. It is that the model was never told what the records mean.

Here are three traps I hit repeatedly, each one real, each one something a naive agent walks straight into.

Trap 1: "invoices" is not a table

Ask an agent to "add up last month's invoices" and it will look for something invoice-shaped. In Odoo it finds account.move, sees invoice-like columns, and sums them.

But account.move is not the invoices table. It is the journal-entries table. Customer invoices, vendor bills, customer credit notes, and vendor refunds all live in the same model, separated only by a discriminator column, move_type:

out_invoice is a customer invoice
in_invoice is a vendor bill
out_refund is a customer credit note
in_refund is a vendor refund

So the honest domain for "customer invoices" is:

[("move_type", "=", "out_invoice")]

An agent that skips that filter sums your sales and your supplier bills into one figure. It will not error. It will return a plausible, wrong total. You can see the discriminator in Odoo's own source, in addons/account/models/account_move.py, where move_type is defined and used to tell these document types apart.

Trap 2: "revenue" has no single answer

Say the filter is right and the agent is looking only at customer invoices. Now: what is revenue?

There is general-ledger revenue, recognised through income accounts. There is invoiced sales, the total of issued customer invoices. They are different numbers, on different date bases (invoice date, accounting date, or delivery period), and a business means a specific one when it asks. No column in Odoo is named revenue. A field like amount_total looks close, but it is a document total that mixes tax and, across the wrong population of moves, mixes document types too.

The correct behaviour when a human asks "what is revenue" is not to answer. It is to ask which definition and which date basis apply, then compute that one. An agent optimised to be helpful will instead pick the first plausible field and commit.

Trap 3: field labels lie

account.move has a field invoice_user_id. From the name you might read "the user who created the invoice". It is not. It is the salesperson associated with the invoice, which is a business fact about attribution, not authorship. If your agent maps it to "created by" and builds a per-rep sales report on it, the report is subtly wrong in a way nobody catches until commission season.

Field names are shorthand written for developers, not contracts about meaning. Guessing from the label is how an agent produces answers that survive review because they look reasonable.

The missing layer

The pattern under all three traps is the same. A connector tells an agent how to reach a record. Nothing tells it what the record means, which tempting reading is wrong, or what it must clarify before it computes. That second thing is a separate layer:

question -> context -> AI reasoning + existing connector -> Odoo

The context step carries three kinds of knowledge the connector never will: what a business noun maps to, what a field actually means, and the negative knowledge of which plausible interpretation to refuse. I have been building an open format for exactly this layer, OCL, and the reference implementation is small enough to run in a minute, so the rest of this is a walk-through you can reproduce.

Trying it

The repository ships an example resolver over ten public Odoo 19 example entries. Clone it and ask the revenue question:

git clone https://github.com/Nantiai/ocl-standard.git
cd ocl-standard
python reference/python/ocl_examples.py get-context "What is revenue?"

The interesting part of the response, trimmed:

{
  "facts": [
    {
      "entry_id": "ocl.example.odoo19.account.revenue_ambiguity",
      "rendered": "... Clarify: Which business definition and date basis apply?"
    }
  ],
  "warnings": [
    {
      "entry_id": "ocl.example.odoo19.account.amount_total_warning",
      "rendered": "... Correction: Resolve the metric definition and record population first.",
      "severity": "warning"
    }
  ],
  "unknowns": [
    {
      "code": "clarify_revenue",
      "message": "Which business definition and date basis apply?",
      "required_action": "clarify_before_execution"
    }
  ]
}

The context pack does not answer the question. It returns a warning against treating one total field as universal revenue, and an unknown that says clarify before execution. Handed to a model as tool output, that is the difference between an agent that guesses and one that asks the one question it should have asked.

The other two traps are covered by two more calls. Resolving a noun to its real domain:

python reference/python/ocl_examples.py resolve-noun "customer invoice"
# -> model account.move, domain [["move_type", "=", "out_invoice"]]

And explaining a field instead of trusting its name:

python reference/python/ocl_examples.py explain-field account.move invoice_user_id
# -> meaning: "Salesperson associated with the invoice."

Putting it in an agent's tool loop

The same resolver runs as an MCP server, so an agent can call get_context, resolve_noun, and explain_field mid-reasoning:

{
  "mcpServers": {
    "ocl-public-examples": {
      "command": "python",
      "args": [
        "/absolute/path/to/ocl-standard/reference/python/ocl_examples.py",
        "serve-mcp"
      ]
    }
  }
}

Now, before the agent writes a query, it can ask what "revenue" means, get told to clarify, and clarify. Before it reports on a rep, it can check what invoice_user_id is. The knowledge lives outside the prompt, so it is auditable and it does not drift.

Honest boundaries

This is worth saying plainly, because the failure mode of posts like this is overclaiming.

The format is an experimental technical alpha, 0.1.0. It can change while independent implementations test it.
The ten examples are candidates that demonstrate the shape, not a certified registry. Each one carries a low confidence score on purpose. A conforming document describes evidence and assertions; deciding a fact is verified is a separate, deliberate step, not "an LLM wrote plausible JSON".
The example server serves only those public examples. It is not a commercial runtime, and cloning it does not give you coverage of a real Odoo database.

What is real and reproducible today is the pattern: separate reaching records from meaning, encode the meaning as facts, warnings, and unknowns, and give an agent a way to ask before it computes. You can apply that idea with or without this repo.

Who I am

I help build nanti.ai, and OCL is our open take on this context layer for Odoo. The repository is Apache-2.0: github.com/Nantiai/ocl-standard. If you would rather see one grounded decision run without cloning anything, there is a no-login live demo of the revenue case at api.context.nanti.ai/demo/revenue. The reference server is also published on the official MCP registry as io.github.Nantiai/ocl-standard.

Odoo is a trademark of Odoo S.A. This project is independently developed and is not affiliated with or endorsed by Odoo S.A.

If you have connected an agent to Odoo, I would like to know which field it got wrong first. Mine was invoice_user_id.