AI agents for Odoo:
how they connect, and how to keep them governed.

An AI agent for Odoo is an assistant that reads and writes Odoo records on your behalf, translating what you ask in plain language into the API calls that do it. The appeal is obvious: ERP work without the ERP screens. The part that decides whether it is a convenience or a liability is scope, and scope is a governance question more than an integration one.

We build Pinchy, a self-hosted AI agent platform with a governed Odoo integration, and run our own bookkeeping through it, so this is not neutral ground. The mechanics below are true of any agent-to-Odoo connection; the governance section is the part most guides skip.

How an AI agent connects to Odoo

Odoo exposes its data through an external API. Historically that is XML-RPC and JSON-RPC; Odoo 19 adds a REST-style JSON-2 API as the long-term successor (the older XML-RPC and JSON-RPC endpoints are slated for removal in later releases, so the direction of travel is JSON-2). All of them call the same underlying ORM methods, so the capabilities are identical and only the transport differs. An agent connecting over any of them can perform standard create, read, update, and delete operations on records.

Crucially, this is the documented public interface. The agent is just another API client. It does not modify Odoo, install anything into it, or depend on Enterprise: the external API is the same on Community and Enterprise, which is why a connected agent behaves identically on both. The agent's job is to turn "what did we invoice Acme last quarter" into the right query, and "book this receipt to office supplies" into the right write.

What an agent can actually do

Because the external API reaches the ORM, an agent can work across the whole system: CRM, accounting, inventory, HR, and the rest. In practice that looks like:

• Read: find a customer, check stock for a product, pull the open invoices for an account, summarize last month's sales.
• Create: draft a sales order, log an expense, add a contact, open a helpdesk ticket.
• Update: change a record's fields, move a deal stage, reconcile a line.

The pattern that makes it click for most teams is turning an artifact into a transaction. You photograph a supplier receipt, drop it into a chat, and the agent reads the amount and vendor, asks which account it belongs to if it is not sure, and posts the transaction in Odoo with the right fields. The ERP work happens, but the ERP screen does not. That single example is also the one we run our own books on.

The risk hiding in the convenience

Here is the catch that the demos skip. The external API does not have a "just the safe parts" mode. It exposes the ORM, and the ORM can read and write across the entire database. An agent handed raw API access can, in principle, read every customer record, change any invoice, or delete data, not because it is malicious, but because the interface makes no distinction between the one operation the agent needs and the thousand it does not.

Combine that with the fact that an agent can be steered by the content it processes (a prompt injection hidden in a document or an email it reads) and the unscoped version of this integration is a genuine hazard. The receipt you drop in could, in the worst case, carry an instruction the agent follows against the rest of your data. The fix is not to distrust the feature. It is to make sure the agent was never holding that much access in the first place.

Keeping an Odoo agent governed

Everything that makes agent governance work in general applies here, sharpened by how much an ERP holds. Concretely:

• Expose operations, not the raw API. Give the agent narrow, purpose-built capabilities (a "read sales orders" operation, a "create expense" operation) rather than a generic "call any ORM method" tool. The agent should not be able to invent an operation you did not define.
• Default-deny. Start the agent with no Odoo access at all and grant each operation explicitly, scoped to its job. A receipt-booking agent needs to write expenses, not read payroll.
• Audit every write. Each create or update the agent makes against Odoo should land in a tamper-evident audit trail, so a change can always be traced back to who asked and what happened.
• Self-host both sides. If Odoo and the agent both run on your infrastructure, the data the agent touches never leaves it. For an ERP, which holds your customers, finances, and people, that data-residency property is not a nicety.

This is the same four-layer model from the broader agent governance guide, applied to the system in your business that has the most to lose.

How Pinchy does it

This part is about our own product. Pinchy connects to Odoo over its JSON-RPC external API and exposes Odoo work as scoped operations that run through each agent's default-deny allow-list, so an agent only has the Odoo capabilities you granted it and nothing wider. Every action it takes in Odoo is written to a per-row signed audit trail. The connection installs as a small free module from the Odoo App Store and the platform is self-hosted, so a self-hosted Odoo and a self-hosted Pinchy keep your ERP data on your own servers end to end. The plain-language and receipt-to-transaction workflows above are the ones we use, not hypotheticals. The deeper product walkthrough lives on the Odoo AI agents page.