How to add AI agents to Odoo
Short answer
Build AI agents on Odoo by giving a model a small set of tools that wrap the external API (XML-RPC or JSON-RPC) and the ORM models behind Manufacturing, Inventory and Purchase. Start with read-only tools, let the agent draft changes as chatter notes or draft records, and require a human click before anything is confirmed.
Odoo shops tend to grow module by module: Sales and Inventory first, then Purchase, then Manufacturing, then Quality or Maintenance. The result is a single PostgreSQL database with a very consistent ORM, which is good news for agents, but also a lot of people doing repetitive triage: late purchase orders, manufacturing orders blocked by missing components, reorder rules that fire at the wrong time.
An AI agent in this context is not a chatbot. It is a loop that reads exceptions from Odoo, calls tools, reasons over the results and proposes an action. The work that matters is the tool layer and the approval model, not the choice of model.
Odoo is open enough that you can run the whole stack, including the model, inside your own network. That matters for contract manufacturers and defense suppliers who run Odoo Community or Enterprise on their own servers.
What teams use it for
Manufacturing order blocker triage
An agent scans mrp.production records in Confirmed state with component availability problems, checks stock.quant and open purchase lines, and writes a short cause summary on the order chatter.
Late supplier chasing
For purchase.order lines past their planned date, the agent drafts a follow-up email to the vendor contact on res.partner and attaches the line detail. A buyer reviews and sends.
Reorder rule tuning suggestions
The agent compares stock.warehouse.orderpoint minimums with actual consumption from stock.move history and proposes changes as a list for the planner to approve.
Draft non-conformance records
When a quality check fails, the agent gathers the work order, lot, operator notes and supplier lot, and drafts the follow-up text for the quality team to edit.
Quote and BOM cost sanity checks
Before a sale.order is confirmed, the agent explodes the mrp.bom, compares cost to the quoted price and flags lines where component cost changed since the last quote.
Month-end exception sweep
An agent lists unreconciled receipts against vendor bills (stock.picking versus account.move) and groups the mismatches by vendor for the accounting team.
Odoo integration surface
- External API: XML-RPC at /xmlrpc/2/common and /xmlrpc/2/object using execute_kw, and a JSON-RPC endpoint at /jsonrpc. Newer versions also add a REST-style JSON API; check what your release exposes.
- Authentication with a per-user API key (introduced in recent versions) used in place of the password, so the agent inherits that user's access rights and record rules (ir.model.access and ir.rule).
- Core models for manufacturing agents: mrp.production, mrp.workorder, mrp.bom, stock.quant, stock.move, stock.picking, purchase.order, purchase.order.line, product.product and res.partner. Quality and Maintenance models exist only if those apps are installed.
- Automated actions and server actions, plus outgoing webhooks in recent releases, can push events (order confirmed, picking late) to the agent instead of polling.
- Direct PostgreSQL access is possible on self-hosted installs for read-only analysis, but writes should always go through the ORM so computed fields, constraints and chatter stay correct. Odoo Online does not give database access.
How it works
- 1
Create a dedicated Odoo user for the agent
Give it a real user record with a narrow group set and an API key. Never reuse an administrator. The access rights on that user become the agent's hard limit.
- 2
Write a thin tool layer
Wrap search_read, read_group and a few named methods into tools with typed arguments: get_open_mos, get_shortages(mo_id), get_po_lines_late, post_chatter_note. Hide the raw domain syntax from the model.
- 3
Choose the trigger
Use a scheduled action (ir.cron) or a webhook for event-driven runs, or a queue worker that polls. Event-driven is better for blockers, scheduled is better for sweeps.
- 4
Run the model with the tools
Use a tool-calling model. For regulated data, serve an open-weight model with vLLM or Ollama inside your network. Log every tool call and its arguments.
- 5
Make output a proposal, not a write
The agent posts a chatter note, creates a draft record, or opens an activity (mail.activity) assigned to the right person. Confirmation stays human.
- 6
Add an approval path for the few writes you do allow
For example, adjusting a planned date or creating a draft RFQ. Present the diff, require a click, then execute under the agent user so the audit trail shows who did what.
- 7
Evaluate on historical exceptions
Replay last quarter's blocked orders and late POs and compare the agent's proposals with what planners actually did before enabling it live.
Example flows
Blocked manufacturing order
Trigger: A manufacturing order is confirmed and component availability shows a shortage.
- Agent calls get_shortages for the order and lists missing components.
- It looks up open purchase.order.line rows and expected receipt dates for those products.
- It checks whether an alternative component exists on the BOM.
- It posts a chatter note summarising the cause and creates an activity for the planner.
Result: The planner opens the order and sees the cause and options instead of digging through three screens.
Late PO follow-up
Trigger: A nightly scheduled action finds PO lines more than three days past the planned date.
- Agent groups lines by vendor.
- It drafts one email per vendor listing lines, quantities and needed-by dates.
- It stores the draft as a mail.mail in draft state, not sent.
- The buyer reviews, edits and sends from the PO form.
Result: Chasing takes minutes per vendor and every message is traceable on the PO chatter.
Keeping data on-prem
Odoo Community and Enterprise can run on your own servers or a private cloud, and the agent stack can sit beside them. Run the model with vLLM or Ollama on a GPU host in the same network, keep the tool layer as a small service that talks to Odoo over the internal URL, and keep logs in your own storage. No ERP data needs to leave the network. Odoo.sh and Odoo Online are hosted by Odoo, so you would call their external API over the internet and should decide up front whether prompts may include that data. Air-gapped sites can still use the XML-RPC API on a local network with an open-weight model and no outbound calls.
Security checklist
- Run the agent as its own Odoo user with minimal groups; record rules then apply automatically.
- Keep tools read-only by default and allow-list the few write methods.
- Log each tool call with user, arguments and result summary outside Odoo as well as in chatter.
- Treat text from vendor emails and attachments as untrusted input that could carry prompt injection; never let it choose tool arguments directly.
- Rotate API keys on a schedule and store them in a secrets manager, not in the model prompt.
Ways to get it done
Odoo's built-in AI features and server actions
Effort: Days to configure, limited to what the version provides.
Drafting text, summarising chatter and simple automations in recent Enterprise versions. Enough if you only need writing help.
Build in-house with the external API
Effort: Typically a few weeks for a first read-only agent, longer with approvals and evaluation.
You have a Python developer who knows Odoo models and want full control over tools and approvals.
Work with a partner such as Netray
Effort: A scoped pilot over several weeks, then extend to more workflows.
You want on-prem models, a tested tool layer and an Odoo implementation partner involved in the process design.
Pitfalls
- !Letting the agent write directly through write() or create() on confirmed records, which can bypass your business checks.
- !Skipping the custom fields and Studio changes: many Odoo databases carry x_ fields the agent must know about, or it reports wrong data.
- !Polling the API too aggressively on a shared instance and slowing down shop-floor users.
- !Ignoring multi-company: record rules differ per company and the agent may see an empty result instead of an error.
- !Evaluating only on happy paths. Test on weird orders: subcontracting, kits, multi-step routes.
Frequently asked questions
Can an AI agent run on Odoo Community?
Yes. Community exposes the same XML-RPC and JSON-RPC external API, so an external agent service can read and write through it. You do not need Enterprise features for the agent itself, though some models such as Quality or Maintenance apps are Enterprise only.
Is Odoo Online suitable for agents?
It depends on your plan and version. External API access has historically been limited on some Odoo Online plans, and there is no database access. Check with Odoo what your subscription allows before designing around it.
Should the agent write to Odoo?
Start read-only and let it post notes, activities and draft records. Add narrow writes later, each with a visible diff and a human approval. Confirmed orders, stock moves and accounting entries should stay under human control.
Which model should I use?
Any model with reliable tool calling works. For private data, an open-weight model served locally is common. The quality difference between models matters less than a clean tool layer and good evaluation on your own past exceptions.
How do agents differ from Odoo automated actions?
Automated actions follow fixed rules. An agent can read several records, interpret free text and choose among tools. Use rules for deterministic cases and add an agent only where judgement across records is needed.
Want AI agents working on your Odoo?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment