Odoo is modular by design and your instance is unique — Sales and Stock active, maybe Project, maybe Accounting, almost certainly a custom module or two. We build AI agents and workflows on top of the Odoo you already run, honouring groups, record rules and your customisations.
Quotations get drafted by hand one at a time, orders that come in by email get retyped into Sales, project hours land at the end of the week from memory, and bank reconciliation waits for closing because no one has time. Odoo has the objects, the workflows and the permissions — but between the customer’s email and the Sales Order there’s always a person copying data.
We build the connector against your instance via XML-RPC or JSON-RPC, with a technical user scoped down to the groups and record rules the use case needs. The agent reads res.partner, sale.order, project.task or account.move, writes with an external_id so nothing duplicates, and respects your custom modules — including the ones that override standard behaviour. We deploy it as an Odoo module or as an external service, whichever fits your tech team.
Reads Quotations and Sales Orders, cross-references res.partner and mail.message, and drafts the next follow-up email in the rep’s voice. Drops it into the order’s chatter as a message to review before sending.
Orders received by email or PDF parsed into Sales Orders: matching against product.product by SKU, EAN or description, with a confidence per line. Doubtful lines are flagged for human validation — nothing gets invented.
For professional services running on the Project module: reads tasks, messages and timesheets, suggests hour assignments per task, drafts the weekly status to the client and flags projects drifting outside the agreed budget.
When the Accounting module is active: cross-references bank statements with account.move and account.payment, proposes reconciliations with rule and confidence, and only sends to human review the ones the model can’t tie down.
Every new ticket is classified by team, priority and product, and the agent drafts an initial reply grounded in your internal docs. The team approves, edits or escalates — the ticket leaves resolved, not copy-pasted by hand.
We create a technical user with the groups and record rules strictly required by the use case. No admin out of habit, no global access. We document which models the agent reads and writes, and why.
Odoo’s permission model is the source of truth. If a human user can’t see a quote because a record rule excludes them, neither can the agent. Before each deployment we audit that the technical user’s scope matches the operational reality you expect.
If your team prefers to keep everything inside the modules repo, we install a custom module with its own models, views and dependencies. If they prefer the logic to live outside, we deploy it as an external service that talks to Odoo over the API. We choose with you, not by default.
Every agent write carries a stable external_id (ir.model.data) or a reference in a custom field. If the flow retries after a failure, we don’t duplicate partners, quotes or journal entries. Any execution can be replayed safely.
We validate against a sandbox database with copied data before touching production. And if you’re mid-upgrade (16 → 17 → 18), the connector is tested against the target version before the migration: the version jump doesn’t break the agent because we cover it in the plan.
Both. The XML-RPC and JSON-RPC APIs are the same on Community and Enterprise. The practical difference is which modules you have active: if a use case depends on Helpdesk, Subscriptions or Studio (Enterprise), we say so up front and propose either an alternative or adopting the module. We never push a licence by default.
Only if you explicitly ask us to. By default we coexist with them: the agent respects custom models and behaviours just like a human user would. Before deployment we review the custom modules that touch the models in our use case (extended sale.order, account.move with custom fields) so we don’t write against fields that depend on your logic.
The connector is versioned with your instance. Before the migration we test it against the target version on a sandbox database: we identify field changes, renamed models or deprecated APIs and resolve them before go-live. The Odoo migration and the agent migration are planned as one project, not two separate fire drills.
We decide that with you depending on how your tech team works. As an Odoo module if you want it versioned in your repo, installed via Apps and maintained alongside the rest. As an external service if you’d rather isolate the AI logic, scale it separately and iterate without touching the instance. Both options give the same level of security and traceability.
We design for privacy from the start, human control, traceability, usage limits, permissioning and documentation. For sensitive processes, we help assess risk and applicable obligations under GDPR and the EU AI Act.
Every engagement is led personally by one of the partners. If there's a fit, you get a personal first read of your case within one business day — not a canned demo.
