I have spent over ten years implementing Odoo for companies across Bulgaria and Southeast Europe. Small family businesses, mid-size manufacturers, multi-company groups with subsidiaries in three countries. What I have learned in that time is that the gap between what people expect from software and what software actually delivers is almost always a communication problem. The software does not understand what the user means. The user does not know how to speak the software’s language. And so they talk past each other, forever.
AI was supposed to fix this. And in some ways, it has. But the way AI is typically wired into ERP systems today creates a new version of the same old problem — except this time it is the AI that does not understand the business, because nobody gave it the right context to work with.
This is the story of why that happens, and what we built to address it.
The way people think versus the way databases think
When a salesperson opens an order in Odoo, they see a complete picture: a customer, a date, a list of products with quantities and prices, a warehouse, payment terms, a total. Everything on one screen. In their mind, that order is that picture — coherent, meaningful, in context.
The database sees something entirely different. It sees dozens of columns spread across three tables, joined by foreign keys. partner_id = 1423. amount_total = 540.00. warehouse_id = 2. Numbers without history, without relationships, without meaning in isolation.
This tension — between how humans understand information and how it is actually structured in the system — is at the root of every difficulty in deploying AI inside ERP. And the architectural decision you make about how to bridge that gap determines whether your AI assistant is genuinely useful or just an expensive search bar.
When a sales manager asks for “orders from Petrov over 1,000 BGN last month,” they are thinking like a businessperson. The system needs to respond like one — not like a SQL query.
What Odoo 19 EE chose to do — and why it is understandable
Odoo 19 Enterprise embeds AI directly into the core. Per-field indexing via pgvector in PostgreSQL, configurable agents, AI server actions, natural language search. The approach has a clear logic: data is already in Postgres, pgvector is an extension, nothing new to install. Fast to ship, easy to enable, zero additional infrastructure.
But when you look at what actually happens when a user asks a question, the cracks appear.
The fragmentation problem
When Odoo 19 indexes a sales order, it does so field by field. The customer name becomes one vector. The total becomes another. The date becomes a third. Each vector contains the value of a single field — with no knowledge that these three values belong to the same business transaction.
In small databases with simple data models, this works adequately. With 50,000+ records and the kind of relational complexity that manufacturing or distribution clients generate — sales orders with 15 lines, each linked to product templates with multiple variants — the quality of results degrades noticeably. The AI has to reconstruct the picture from fragments. And in our experience with real clients, users stop trusting the AI after the first few disappointing answers.
The infrastructure cost
pgvector shares the same PostgreSQL instance as your business data. Vector similarity search is computationally intensive. For clients with heavy transaction volumes — manufacturers running MRP, distributors with constant stock movements — we have seen this additional load affect system responsiveness in ways that are hard to justify to a CFO who just wants the ERP to be fast.
The lock-in
When your AI architecture is baked into the Odoo version, your choice of embedding model, indexing strategy, and all associated parameters are tied to Odoo’s release cycle. Migration from version 19 to 20 means rebuilding the entire AI index — a process whose complexity in a production environment is not trivial.
Odoo 19 EE makes a pragmatic choice: maximum ease of setup at minimum infrastructure dependency. The question is whether those priorities match yours — especially if you are thinking about AI not as a feature to tick off, but as a long-term strategic investment.
The unit of context
The module we built — ai_tokenizer, embedded inside l10n_bg_claude_terminal — starts from a different premise: the unit of AI context is the screen, not the field.
An Odoo form view is the natural definition of a business object from the user’s perspective. It includes everything: direct fields, resolved Many2one relationships (customer with city, credit limit, category), One2many lines (order lines with products, quantities, prices), and aggregates (totals, taxes, status). All of it visible in a single glance.
We take everything on that screen and translate it into a single composite document — structured text, readable by a human, containing the complete business context of the record. That document is what gets indexed.
When Claude receives this, it sees exactly what the salesperson sees. Not isolated numbers. A complete picture of a business transaction — in the language of the business, not the language of the database.
The insight is simple but consequential: AI should understand business the way people understand it — in context, in relationships, in meaning. Not as a collection of column values.
How it works in practice
The architecture has three clearly separated layers, each with a single responsibility.
The result: when a user asks “show me recent orders from Petrov”, Claude already has the full picture of each order — not a set of field values to reconstruct, but a complete, human-readable business document. The answer is fast, accurate, and contextually complete.
When you need it now
For cases where the background process is too slow — you just created a record and want Claude to know about it immediately — the Claude terminal panel in Odoo includes a “Tokenize Now” button. One click, synchronous processing, status badge updates in real time. The badge shows whether the current record is indexed, stale, or pending.
Security: where data lives matters
For many organizations — especially in regulated sectors — the question of where data goes is more important than the question of how good the AI is. The architecture is designed with this priority in mind.
What this changes for your team
For business analysts and managers
Natural language questions — “show me customers whose orders declined more than 30% compared to last quarter” — get answered with full context for each order: which products, which quantities, which salesperson, what notes were added. Not just numbers. The complete picture.
For R&D and product teams
Claude Code CLI with Qdrant access means a developer can ask “what customizations have been made to sale.order for client X” and get an answer based on actual data — not documentation that may be out of date. Code review, workflow debugging, and data analysis become significantly faster when the AI already knows the context.
For IT architects and CTOs
The system is modular and replaceable at every level. Switching the embedding model from local Ollama to Voyage AI or OpenAI is a configuration change — no code modification, no rebuilding the index from scratch. Independence from Odoo’s release cycle is a strategic asset. And for 50 to 100 Odoo clients, the system runs with a separate Qdrant collection per database — full isolation between clients, scalable to millions of records on a single Qdrant instance.
Where this is going
We are building this in three stages, each one a qualitatively different capability layer.
The code is open
The base MCP infrastructure and the tokenization engine are both open source under LGPL-3.0. If you want to see what conversational ERP actually looks like in production, or if you are thinking about AI for your own Odoo implementation, the code is the best starting point.
If you have questions about the architecture, about specific deployment scenarios, or about what this would look like for your organization — drop us a line. We have been running this in production, and we are happy to talk through what we have learned.
OCA maintainer l10n-bulgaria · 10+ years of Odoo implementations · bl-consulting.net