Feature-complete · in final hardening · Odoo 19
The execution layer for Odoo.
The enterprise MCP server for Odoo: every AI action verified, governed, audited.
An AI can write to the wrong record and report success. Nothing errors. Nobody notices. This layer catches it: every action is read back from the database and proven before it says done. Your rules run on the server, not in a prompt.
An installed MCP server for Odoo 19. Any client connects: Claude, ChatGPT, Cursor. Self-hosted and Odoo.sh, Community and Enterprise. Feature-complete and in final hardening. An independent nanti.ai project.
The failure nobody sees
It did the wrong thing. And reported success.
The dangerous failure isn’t the error. It’s the write that goes wrong quietly: technically valid, confidently reported, found weeks later. Reviewing the plan can’t catch it. It happens during execution.
- the wrong record
Put Riverside Foods on 45-day payment terms.
update_recordres.partner1 record updatedDone. Riverside Foods is now on 45-day payment terms.
What the database saysIt landed on res.partner/1042, Riverside Cafe. Similar name, different customer. Valid, so nothing flagged it. It surfaces weeks later, in an invoice dispute.
With the Execution Layer · designedAMBIGUOUS_TARGETTwo partners match “Riverside”. The write is refused, with both candidates, until a person picks one. Then it executes, reads back, verifies, and receipts. - the partial read
How many invoices are overdue right now?
search_recordsaccount.move14 rowsYou have 14 overdue invoices, totalling $18,290.
What the database says23 are overdue. The tool returned a page of 14 and never said so, so the model answered from a partial list. It surfaces at month close, as a number that won’t reconcile.
With the Execution Layer · designedtruncated: trueThe read comes back flagged: truncated, 14 of 23. The agent pages through the rest and answers from all 23, or says it couldn’t.
Illustrative sessions on sample data. Any model on any connector can fail this way, because nothing in that pipeline checks what actually happened. The “with” outcome is how the Execution Layer behaves today: built, and shown running further down this page.
The first question to ask before you let AI touch your ERP: how do I know it did what it claims? A connector can’t answer that. Answering it is the whole product.
Not a mockup
The real product, running on Odoo 19.
The five pillars are built and working, the suite installs on Odoo 19 Community and Enterprise, and every screen below is a real capture from a nanti.ai development instance. Not a rendering, not a promise: the product, running.
- 5pillars, built and working
- 119adversarial cases green, both editions
- 12 / 15MCP tools, core / Complete suite
- C + EOdoo 19 Community and Enterprise
Real screens from a nanti.ai evaluation stack on Odoo 19 Enterprise. Dashboard figures are test-suite traffic, not customer data; rules shown were seeded as sample configuration, and the evaluation company name is redacted from the window chrome. The features are real. Full walkthrough in the docs.
The trust stack
Transport. Meaning. Proof.
AI on a business system is three different jobs. The connector is transport. The Context Layer is meaning, before the action. The Execution Layer is proof, after it.
- Connector transport
Moves requests and records between the AI and Odoo. Necessary, nothing more. It can’t say what a field means, or prove what a write did.
- Context Layer meaning
The verified meaning before the action: which records count, which fields mislead, whether the intent is safe. Live today on Odoo 19.
- Execution Layer proof
Validates, executes, reads back, verifies, and receipts every action. Your rules enforced on the server. This page. Feature-complete, in final hardening.
A connector moves data. The Execution Layer proves what happened.
With its sibling, the Context Layer for Odoo, the pair closes the loop around every AI action: meaning before the action, proof after it.
For the MCP shortlist
Yes, it’s an Odoo MCP server.
Any MCP client connects: Claude, ChatGPT, Cursor, your own stack. But “speaks MCP” is the floor. What separates one Odoo MCP server from another starts after the protocol: whose identity the AI acts under, what needs approval, and what you can prove afterwards.
What is MCP? The open standard that connects AI clients to business systems: one protocol, any client, any system. It’s genuinely good, and we implement it fully. But a connector-grade server only answers “can the AI reach Odoo?”. The Execution Layer also answers “did it do the right thing, with permission, and can you prove it?”. Everything MCP promises, everything enterprises require.
MCP standardizes the transport. Everything in the right column is what we build on top of it, and it’s our honest answer to “which Odoo MCP server is safe to trust”: the one that can prove what happened. On Odoo Online, where custom modules can’t be installed, Odoo’s own native MCP server is the option.
Choosing today? We keep an honest, dated survey of the whole field: Odoo MCP servers, compared. Connecting a specific client: connect Claude to Odoo · connect ChatGPT to Odoo.
Pillar 01 · Verified execution
Every action comes back as evidence.
One validated pipeline for every tool call. No fast path around it. A write isn’t “sent”: it’s executed, committed, read back, verified, and receipted. Walk one through the chain.
Validated, then executed atomically
Checked against your preconditions and the user’s own permissions, then run inside an atomic transaction. Batches are all-or-nothing. An idempotency key rides along, so a timeout and retry executes once, not twice.
Committed to the database
The transaction commits. The change now lives in Odoo’s database, not in the model’s context window. No half-applied states: it fully lands, or it doesn’t.
Read back and compared
The layer reads the record back and compares it against the declared intent. Success is reported only when what persisted matches what was meant. A mismatch returns a structured failure, never a quiet one.
Receipted, with before and after
It lands in an immutable record: before and after snapshots, the acting user, the receipt id. It answers the one question no prompt can: what did the AI actually do.
-
executedatomic transaction, preconditions passed -
persistedcommitted to the database -
verifiedread back from the DB = declared intent -
recordedbefore “30 days” → after “45 days” · rcpt_84h2
A schematic, so you can walk the chain. The real receipt screen is in See it running, above.
Reads are covered too: every bounded read carries a truncation flag, so a partial list can’t pose as a complete one. And every failure is a machine-readable code an agent can act on, never prose to misread.
Structured failure codes include AMBIGUOUS_TARGETAPPROVAL_REQUIREDPRECONDITION_FAILEDVERIFICATION_FAILEDIDEMPOTENCY_CONFLICT
Pillar 02 · Governance
Your rules, enforced where prompts can’t reach.
Prompt instructions are suggestions. Your operating rules become server-side enforcement: identity, permissions, approvals, and preconditions that hold no matter what the model was told, or by whom.
- oauth identity
Every user is themselves
Each user connects under their own Odoo identity, over OAuth. A shared service account is impossible by construction. The AI touches exactly what that person may touch, and the audit says who.
- role bundles
Tools that don’t exist can’t be misused
Plain-language role bundles decide which tools even exist, per user. The AI a salesperson talks to simply has no delete. The one an accountant uses posts only with approval.
- approvals
Prepare, approve, then execute
-
prepare -
approve -
execute
Destructive actions stage the exact change first, server-side. A person approves it, and the token is bound to that exact payload: any drift invalidates it. The approver can be someone other than the asker.
-
- preconditions
Your business rules, as code the server runs
Rules you write in plain language become preconditions no action can skip:
- “A task can never be created without an assignee.”
- “A stock adjustment requires a valid procedure from Odoo Knowledge.”
- “Payment terms above 30 days need a manager.”
Pillar 03 · Evidence
A log that finds you.
Every action lands in an immutable record with before and after snapshots. Open any record, see everything AI ever did to it, in order. And you don’t have to go looking.
Per-record history is one question, not an afternoon of grepping logs.
“Show everything AI ever did to this customer” is a single view: each entry carries the
change, the before and after values, the acting user, and the receipt id. AI clients can
read the same history through the get_record_history tool, and that read is
itself audited.
Alert rules watch the log for you. When something worth attention happens, the log comes to the right person instead of waiting to be opened:
email webhook Odoo activity
For regulated environments, Evidence Plus goes further. The add-on mirrors the audit trail, in chain order, to storage you own (S3 Object Lock, Azure immutable blob, your SIEM, a signed webhook) and packages any period as a report a third party can verify without access to your Odoo. nanti.ai never receives audit content: destinations under our own domain are refused by the software itself.
-
writepayment terms before “30 days” after “45 days” -
createsale.order S00912 3 lines · all-or-nothing batch -
writecredit limit staged, not executed
A schematic. The real before-and-after history screen is in See it running, above.
Pillar 04 · Meaning
It refuses to guess.
Ask an agent to assign a task to John when two employees are named John. A guess is a coin flip that writes to your database. Instead: a structured refusal with the candidates, every time. Never a guess.
Underneath sits a versioned semantic registry per model and field, synced with the Context Layer for Odoo. Meaning supplies what records and fields mean; execution holds every action to it. Meaning before the action, proof after it.
A refusal isn’t the AI failing. It’s the layer doing its job: the agent gets the candidates as structured data, asks you one question, then acts on the answer, verified like everything else.
{
"error": "AMBIGUOUS_TARGET",
"message": "Two employees match \"John\".",
"candidates": [
{ "id": 214, "name": "John Keeler", "department": "Sales" },
{ "id": 388, "name": "John Mora", "department": "Support" }
],
"required_action": "clarify_before_execution"
}Machine-readable, so the agent can ask the user instead of picking one.
Pillar 05 · Dependability
Built to be trusted. Shipped to be tested.
Trust is earned in the boring places: what happens when Odoo changes, what happens when things fail, and whether you can read what you’re running.
-
A published compatibility contract
Supported Odoo versions stated in writing, and new Odoo major versions covered under an active subscription. Compatibility is a commitment, not a changelog surprise.
-
Drift, detected
Every toolset carries its version and a schema hash, so a changed Odoo or a changed toolset is detected at the handshake, not discovered in production.
-
A failure suite, 119 cases, that ships
The failure suite we attack the layer with, 119 cases green on Odoo 19 Enterprise (117 on Community, 2 Enterprise-only skips), is the release gate, and it ships with the product: run it against your own staging database and read the report. Cases it cannot run on your stack are reported as not run, with the reason, never as passes.
-
Code you can read
The core is open source and the enterprise modules are source-available. You can read what you’re trusting with your ERP.
The price of proof
Connect is free. Complete is one price.
One product, one price per year, by the size of your company. Per production Odoo database, everything included: all five pillars, every tool, the Context Layer for Odoo, updates, and new Odoo majors under an active subscription. No seats, no metering, no per-request charges.
$0 forever
Free and open source, LGPL-3. Per-user OAuth identity, scoped API keys, the twelve core tools, fail-closed writes, structured errors, and the action log. Yours, forever.
- Any MCP client: Claude, ChatGPT, Cursor, your own agent stack
- On your own Odoo 19, self-hosted or Odoo.sh, Community and Enterprise
- Writes off until an administrator allows them, and fail-closed even then
- Up to 20 internal users $1,990 / year
- Up to 100 internal users $4,990 / year
- More users or several production databases: terms agreed together. Talk to us
- All five pillars in full: verified writes and receipts, governance, evidence, meaning, dependability
- The Context Layer for Odoo, included for the whole instance
- The published compatibility contract: new Odoo majors covered under an active subscription
- A support SLA, and one deployment, one paste to activate
Free for the first 7 days, no card
Add-ons, priced separately: services, never withheld features
- Evidence Plus $1,490 / year
Off-site immutable audit mirror to storage you own (S3 Object Lock, Azure immutable blob, SIEM, webhook), plus evidence report packs a third party can verify without Odoo access.
- On-prem Context Layer mirror $4,990 / year
Hash-verified registry packs delivered into your network, for environments where nothing may call out.
- Priority support +30%
4-business-hour response with a named engineer, at 30% of the Complete price.
The terms, plainly
- Internal users are the people who log in to Odoo; portal and website users never count. The count is self-declared, the dashboard shows it, and the module never phones home. Outgrow your size and it says so once; nothing ever blocks.
- Staging, development, and test databases are free and unlimited.
- Complete is free for the first 7 days, no card. Prices are USD list prices excluding VAT, per year, with annual renewal; cancel up to 30 days before renewal.
- If a subscription ends, the installed modules keep running unchanged and your audit trail stays yours. Hosted Context Layer access stops; updates and support stop.
These are the launch prices, published now so you can plan. Nothing is buyable yet: Complete becomes purchasable at launch, complete, and we write once, at launch.
Straight about status
Where this stands.
This product is feature-complete and in final hardening: built and working, proven by its own adversarial suite, and honestly not yet something you can buy or install. Here is exactly what is real today and what is still ahead of launch.
- All five pillars, built and working: every write validated, executed atomically, read back from the database, verified against the intent, and receipted with before and after evidence
- Server-side governance: per-user OAuth 2.1 identity, role bundles, Prepare, Approve, Execute for destructive actions, and your preconditions, enforced where prompts cannot reach
- An immutable audit with complete per-record history, alert rules that notify people over email, webhook, or an Odoo activity, and the Evidence Plus add-on that mirrors it all to storage you own
- Installs and runs on Odoo 19, Community and Enterprise, self-hosted and Odoo.sh; twelve core tools, fifteen across the Complete suite; your records never leave your server
- Proven by a 119-case adversarial failure suite: Enterprise 119 green, Community 117 with 2 Enterprise-only cases skipped by design; the suite ships, so you can run it on your own staging
- Subscription activation, built and tested end to end: one deployment, one paste of an activation code, and a dashboard that reports your real subscription state honestly
- Feature-complete and in final hardening. There is no way to buy or install it yet; leave your email and we write once, at launch
- An independent penetration test precedes general availability, and the trust artifacts (security whitepaper, compatibility contract, data-processing pack) are drafted and publish at launch
- In the release test matrix today: Claude Code and the official MCP Python SDK. ChatGPT, Claude Desktop and Cursor are supported with guides documented from their published connector flows
- Pricing is published above; buying is not open yet. Both tiers release together, complete, at launch
- We verify persistence and permissions, never the AI’s judgment. An authorized but wrong-headed action still executes, and the receipt proves exactly what it did; the rules you write are what stop it
Execution Layer for Odoo is an independent nanti.ai project. Odoo is a trademark of Odoo S.A.; this project is not affiliated with or endorsed by Odoo S.A.
Plain answers
Asked, answered.
What is the Execution Layer for Odoo?
It is an enterprise execution control layer between AI and Odoo, for Odoo 19. Every AI action runs through one validated pipeline: the request is checked against your rules and the user’s own permissions, executed atomically, read back from the database, verified against the intent, and recorded with before and after evidence. The result of every write is an Action Receipt: Executed, Persisted, Verified, Recorded. It is feature-complete on Odoo 19 Community and Enterprise, proven by a 119-case adversarial failure suite, and in final hardening before launch.
Is the Execution Layer for Odoo an MCP server?
Yes, a complete one. The Execution Layer speaks MCP, the open standard we implement fully, so any MCP client connects to it: Claude, ChatGPT, Cursor, or your own agent stack. It is an installed MCP server on your own Odoo 19, self-hosted or Odoo.sh, exposing twelve core tools (fifteen across the Complete suite, seventeen with the optional developer tools). The difference from a connector-grade server is everything enforced around every call: per-user identity, approvals, verification against the database, and an immutable audit. MCP is the transport; the product is the proof.
How is it different from an MCP connector?
A connector moves data: it gives an AI reach into Odoo. The Execution Layer proves what happened. It wraps every action in validation, atomic execution, database read-back, verification, and an immutable audit record, and it enforces your approval rules and preconditions on the server, where a prompt cannot reach. A connector answers "can the AI touch Odoo". The Execution Layer answers "did it do what it claims, and was it allowed to".
What should we look for in a safe, auditable MCP server for Odoo?
Five things, whichever product you choose. Each user acting under their own Odoo identity, never a shared key. Server-side approvals for destructive actions. Writes verified by reading the database back, not assumed from a success response. An immutable audit with before and after values. And structured, machine-readable failures, including explicit truncation flags on reads. The Execution Layer for Odoo is exactly that list; it is feature-complete on Odoo 19 Community and Enterprise and in final hardening before launch. On Odoo Online, where custom modules cannot be installed, Odoo’s own native MCP server is the option.
Which MCP server is best for Odoo?
It depends on what you need, honestly. On Odoo Online, Odoo’s own native MCP server is the natural start. For personal and developer use, the free community gateways are excellent. For business use, judge every candidate on the criteria that matter once an AI can write to your ERP: verification by database read-back, idempotency on retries, atomic batches, approval workflows, an immutable before-and-after audit, and alerting. We keep an honest, dated comparison of the field at nanti.ai/odoo-mcp-servers, including where our own Execution Layer, feature-complete and in final hardening, fits.
What is a verified write, and what is an Action Receipt?
A verified write is a write that is executed inside an atomic transaction, then read back from the database and compared against the declared intent before success is ever reported. The Action Receipt is the record of that chain, Executed, Persisted, Verified, Recorded, carrying the before and after values. If any step fails, the AI receives one of 33 structured, machine-readable error codes, never a success message and never prose.
Can the AI delete or mass-update records without approval?
Not when your rules say otherwise. Destructive and high-impact actions go through a server-side Prepare, Approve, Execute sequence: the layer stages the exact change, a person approves it, and only then does it execute. The approval token is bound to the exact payload, so any drift after approval invalidates it, and the approver can be a different person than the one who asked.
Is there an audit trail with before and after values?
Yes, by design. Every action lands in an immutable audit record with before and after snapshots, so you can open any record and see everything AI ever did to it, in order; AI clients can read the same history through the get_record_history tool. Alert rules can notify people over email, a webhook, or an Odoo activity when something worth attention happens: a log that finds you, not a log nobody opens. For regulated environments, the Evidence Plus add-on mirrors the audit trail, in chain order, to storage you own, and packages any period as a report a third party can verify without access to your Odoo.
What stops a retried request from creating duplicates?
Idempotency keys. Every write carries one, so a timeout followed by a retry executes once, not twice. Batches are all-or-nothing by default: either the whole batch persists, or none of it does.
Does each user keep their own permissions?
Yes. Each user connects under their own Odoo identity through OAuth, so a shared service account is impossible by construction. Plain-language role bundles then decide which tools even exist for each user: the AI a salesperson talks to simply does not have the destructive tools an administrator might.
Does our data leave our server?
No. The Execution Layer is an installed Odoo 19 addon suite that runs on your own server, self-hosted or on Odoo.sh. Your records never leave it. Where the Context Layer for Odoo is used alongside it, the Context Layer receives questions, terms, and metadata only, never your records.
Does it work on Odoo Online?
No. It is an installed addon suite for self-hosted Odoo and Odoo.sh, Community and Enterprise, on Odoo 19. Odoo Online does not allow installing custom server modules, and Odoo Online users have Odoo’s own native MCP server instead.
Which AI clients work with it?
Any MCP client: Claude, ChatGPT, Cursor, or your own agent stack. The layer sits between the AI and Odoo, so the model and the client stay your choice, and the validated pipeline is the same for every one of them. There is no fast path around it.
What is the difference between Connect and Complete?
Connect is free and open source, the LGPL-3 core module: per-user OAuth identity, scoped API keys, the twelve core tools, fail-closed writes, the truncation contract, structured errors, and the action log. Complete is the subscription: five source-available modules that add all five pillars in full, verified writes and receipts, governance, evidence and immutable audit, meaning, and dependability, with the Context Layer for Odoo included for the whole instance, the published compatibility contract, and a support SLA. On a Connect-only install the Complete models simply do not exist, and writes still fail closed rather than pretending to verify.
Is it actually built, or just a plan?
Built. The addon suite installs and runs today on Odoo 19, both Community and Enterprise, and all five pillars work: one open-source core, five Complete modules, the Evidence Plus add-on, and an optional developer-tools addon. It is proven by a 119-case adversarial failure suite, run on both editions, that attacks the layer with the exact failures it is meant to catch: partial-write refusals, retry-after-timeout duplication, batch rollback, ambiguous targets, truncated reads, audit tampering, OAuth abuse, and prompt-injection stored in record text. The same suite ships with the product, so you can run it against your own staging database and read the report; cases it cannot run on your stack are reported as not run, with the reason, never as passes. What is not done yet is the final hardening before launch: an independent penetration test, the published trust artifacts, and distribution. That is why we say feature-complete and in final hardening, not available now.
What does the Execution Layer for Odoo cost?
Connect is free and open source. Complete is one price per year, by the size of your company, per production Odoo database, with everything included: USD 1,990 a year up to 20 internal users, USD 4,990 a year up to 100, and terms agreed together above that or across several databases. No seats, no metering, no per-request charges, and the Context Layer for Odoo is included. Internal users are the people who log in to Odoo, self-declared; portal and website users never count, and nothing ever blocks if you outgrow your size, the dashboard just says so. Staging, development, and test databases are free. Complete is free for the first 7 days, no card. Add-ons, priced separately, are services rather than withheld features: Evidence Plus at USD 1,490 a year, the on-prem Context Layer mirror at USD 4,990 a year, and priority support at 30% of the Complete price.
When is it available?
It is feature-complete and in final hardening. We do not ship it in pieces: when it releases, it releases complete, with the adversarial failure suite for you to run on your own staging before trusting production. Subscription activation is already built and tested end to end: you deploy the module archive once and paste one activation code. There is nothing to install or buy yet. Leave your email on the page and we write once, at launch.
Be first
Know what your AI did.
Feature-complete and in final hardening. It releases complete, and there is nothing to install or buy yet. Leave your email and we write once, at launch. Its sibling is already live: the Context Layer for Odoo, on Odoo 19.
One email, at launch. No newsletters, no spam.