Introduction.

An AI agent can do the wrong thing in Odoo and report success. It writes to the wrong record, or reads a truncated list and answers as if it were complete. Nothing errors, nobody notices, and it surfaces weeks later. Reviewing the AI’s plan beforehand cannot catch it, because the mistake happens during execution.

The Execution Layer for Odoo is the fix. It is an enterprise execution control layer that sits between any AI client and Odoo, and it turns “the AI said it worked” into “here is the proof it worked”. Every action runs through one validated pipeline, is verified against the database, and is recorded as evidence you can read.

A connector moves data.        It gives an AI reach into Odoo.
The Execution Layer proves.    It shows what the AI actually did, and enforces your rules.

Not another MCP connector

The Execution Layer speaks MCP, the open protocol, so any MCP client connects to it: Claude, ChatGPT, Cursor, or your own agent stack. But “speaks MCP” is the floor. A connector answers “can the AI reach Odoo”. The Execution Layer answers “did it do what it claims, was it allowed to, and can you prove it afterwards”.

The five pillars

1. Verified execution. Every write runs in an atomic transaction, is read back from the database after commit, verified against the declared intent, and returned as an Action Receipt: Executed, Persisted, Verified, Recorded. Idempotency keys make a retry execute once. Batches are all-or-nothing. Reads carry an explicit truncation flag.
2. Governance. Each user acts under their own Odoo identity over OAuth. Plain-language role bundles decide which tools even exist per user. Your business rules become server-side preconditions that no prompt can skip.
3. Approvals. Destructive actions go through a server-side Prepare, Approve, Execute sequence, with an approval token bound to the exact payload, approved by a person who can be someone other than the one who asked.
4. Evidence. An immutable audit with before and after snapshots, complete per-record history, and alert rules that notify people over email, a webhook, or an Odoo activity.
5. Meaning. A versioned semantic registry per model and field, and deterministic refusal of ambiguity: two employees named John produce a structured refusal with the candidates, never a guess. Synced with the Context Layer for Odoo.

Who it is for

Companies that run self-hosted Odoo 19 or Odoo.sh, Community or Enterprise, and want to let AI act in their ERP without giving up identity, approvals, verification, or the audit trail. The Execution Layer is an installed Odoo addon suite: your records never leave your server.

Where it stands

The Execution Layer is feature-complete and in final hardening. All five pillars are built and working; the addon suite (one open-source core, five Complete modules, the Evidence Plus add-on, and an optional developer-tools addon) installs and runs on Odoo 19 Community and Enterprise; and a 119-case adversarial failure suite passes on both editions (Enterprise 119, Community 117 with 2 Enterprise-only cases skipped by design). It exposes twelve core MCP tools, fifteen across the Complete suite, seventeen with the optional developer tools. Pricing is published: Connect free, Complete one yearly price by company size.

It is not yet something you can buy or install from a store. An independent penetration test, the published trust artifacts, and distribution land before launch, not after. We do not ship it in pieces: when it releases, it releases complete.

Its sibling: the Context Layer

The Execution Layer’s sibling is the Context Layer for Odoo, the verified meaning layer. The two close the loop around every AI action: meaning before the action, proof after it. The Execution Layer works fully without it; where the Context Layer is present, it supplies what records and fields mean, and the Execution Layer holds every action to it.

Next: how it works, the one pipeline every tool call runs through.