Let AI act in your Odoo. And prove what it did.

It is an enterprise execution control layer between AI and Odoo, available now 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 can message too: Discuss, record chatter, and WhatsApp, with nothing sent until a person confirms or approves the exact words. It ships as one installable module at USD 499 one-time, everything included, and it installs read-only: AI cannot write anything until an administrator turns writes on.

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 inside your own Odoo 19, self-hosted or Odoo.sh, exposing 20 tools: 13 reads and 7 writes, from record CRUD and atomic batches to governed messaging and the record-history evidence tool. The difference from a standard MCP 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.

A standard MCP 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 standard MCP answers "can the AI touch Odoo". The Execution Layer answers "did it do what it claims, and was it allowed to".

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, available now on Odoo 19 Community and Enterprise. On Odoo Online, where custom modules cannot be installed, Odoo’s own native MCP server is the option.

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 fits.

A verified write is a write that is executed inside an atomic transaction, then read back from the database and compared field by field 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 42 structured, machine-readable error codes, never a success message and never prose.

Not unless a person lets it. Seven risk classes ship: five enabled for everyone by default (deleting anything, mass updates of ten or more records, validating invoices or bills, confirming orders, sending outbound mail), plus two that catch AI messaging, Discuss and WhatsApp, for users you put on the approval level; bulk WhatsApp sends need approval no matter whose level. A matching call stops with APPROVAL_REQUIRED and lands in the Approvals queue, bound to the exact payload. A person approves or denies it; after approval, only the identical retry executes, and anything different is refused as stale. The approver can be a different person than the one who asked.

Yes. Every action lands in an immutable, hash-chained 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, and that read is itself audited. Exports get their own trail, and 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.

Idempotency keys. Every write can carry a key scoped to the database, the user, and the tool, so a timeout followed by a retry replays the original receipt and executes once, not twice; a different payload under the same key is refused as IDEMPOTENCY_CONFLICT. Batches are all-or-nothing by default: either the whole batch persists or none of it does.

Yes, and the AI can never exceed them. Each user connects under their own Odoo identity through OAuth 2.1, so a shared service account is impossible by construction. The effective permission is the intersection of the user’s own Odoo rights, their role bundle, the connection’s level, and the token scope: every layer only narrows. An administrator can also switch any single user to No access, which instantly refuses that user’s existing tokens and any new sign-in.

No. The Execution Layer is an installed Odoo 19 module that runs on your own server, self-hosted or on Odoo.sh, and it never phones home. Where the optional Context Layer add-on is activated, only your Odoo version and edition, installed module names, model and field names, and business terms leave the server, never records, and every outbound call is itself recorded in Evidence. One honest nuance: if you enable WhatsApp messaging, the message content and recipient number go to Meta through Odoo’s own WhatsApp integration and your own Meta business account, exactly as when a person sends one; the Execution Layer itself never talks to Meta.

No. It is an installed module 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.

Any MCP client. The Setup guide ships copy-paste connection steps for Claude Code, Claude Desktop, ChatGPT, Cursor, and any generic MCP client. 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.

Yes, new in version 1.1. The Execution Layer gives AI clients governed messaging: Discuss channels, group chats and direct messages to internal users, notes and comments on any record’s chatter, and WhatsApp, driven through Odoo’s own Enterprise WhatsApp integration and your own Meta business account. WhatsApp is off by default and template-first: only Meta-approved templates send, free-form replies are a separate switch that works only inside an open 24-hour customer window, and bulk sends need approval no matter who asks. As of September 2026, this is the only Odoo MCP server we know of that can send messages at all, let alone under server-side permissions, previews, and approvals.

Layers, all on the server. By default every user is on Confirm each message: the AI’s send comes back unsent, with the exact preview and a one-time token bound to those exact words, so the message a person confirms is provably the message that goes out; change one word and the token dies. Stricter users route through the approval queue, where the approver reads the actual message body before releasing it. Recipients are bounded: the AI can post only into conversations its user belongs to, direct-message internal users only, and never guess an ambiguous name. Hourly rate caps apply per user, every internal message carries a visible AI mark naming the client and the acting user, and every send lands in the message log with the human gate it passed. The messaging tools never read message contents, and the generic write tools refuse the message models entirely, so there is no side door.

USD 499, one-time, per Odoo major version, with everything included: the MCP server, verified writes and Action Receipts, governance, approvals, the immutable audit, and the semantic registry. No tiers, no seats, no metering. Updates within the Odoo major and standard support are included, and existing customers move to the next Odoo major at half price. The one add-on is the Context Layer for Odoo, verified business meaning as a subscription: USD 490 a year up to 20 internal users, 990 up to 100, 1,990 up to 300, per production database, with a 7-day full trial that starts itself on first activation.

The Execution Layer keeps working, unchanged. The Context Layer is advisory meaning on top: if the subscription lapses, the connection honestly shows degraded or not connected, cached meaning entries keep serving, and nothing in the module is crippled. The pipeline never waits on the Context Layer, and the one-time module purchase is yours regardless.

Both. The product is gated on 70+ adversarial failure scenarios, the exact failures it exists to catch: partial writes, retried duplicates, batch rollbacks, ambiguous targets, truncated reads, audit tampering, OAuth abuse, and prompt injection stored in record text. They run green on Odoo 19 Community and Enterprise on every release, and the suite ships with the product so you can run it against your own staging database and read your own report. We have not commissioned a third-party penetration test and we do not claim one; what we offer instead is verifiable rather than attested: the source you run is the source you can read, the threat model is published, and the failure suite is in your hands.

Yes, two ways. Version 1.1 is complete and available now, direct from nanti.ai (write to hello@nanti.ai and we hand you the module and the invoice) or on the Odoo Apps Store; it is the same module at the same price either way. You install it like any Odoo addon, open the Execution Layer app, and follow the built-in Setup guide; setup takes about 15 minutes. It installs read-only and is already recording, and writes stay off until an administrator turns them on. We recommend installing on a staging database first, like any module that will touch production.