Duration: 36:19
PART 1 — Analytical Summary 🚀
Context 💼
In this session, Joseph, a software developer at Odoo, unveils the “Talk to your ERP” feature first introduced during the keynote. The idea is simple yet powerful: let users navigate the ERP UI and refine data views using natural language questions. Instead of clicking through menus and filters, users ask, “What are the products we sold the most?” and the system opens the right view, applies the correct group-bys, and sorts results accordingly. The value proposition spans onboarding (helping new users discover where answers live) and productivity (experts can shortcut multi-step UI actions).
How it works ⚙️
Under the hood, the feature combines an LLM’s language understanding with structured tool calls and carefully curated context. Odoo feeds the model with a filtered inventory of what the user can actually access: a list of available menus, related models, and the user’s current view state, encoded as XML “facets” (active filters, group-bys, measures, etc.). Security-wise, the AI only “sees” menus and models visible to the current user.
A two-layer tool architecture makes the agent both precise and actionable. Supporting tools (e.g., “get menu details”) help the model shortlist candidate menus and fetch normalized search view metadata: searchable fields, grouped filters, group-bys, and available measures for pivot and graph views. With that, the agent can reason about where to go and what to apply.
Then come the terminating tool calls. The agent can open four view types—list, kanban, pivot, or graph—via dedicated “open menu” tools, or it can adjust search (domains/filters/group-bys) in-place on most views. A core heuristic guides this: if a query is self-contained or diverges from the current model, open the appropriate menu; if it clearly depends on the current context, adjust the search on the current view. When ambiguity is high, it falls back to opening a sensible default menu.
Prompt design was a major effort. Odoo distilled an initially bloated instruction set (~1,000 lines) down to a tighter, intention-driven spec (~300 lines) that encodes domain syntax examples (e.g., Odoo domain expressions) and operational rules. Crucially, admins can customize these instructions—tuning behavior for specific departments or use cases. While the system primarily runs “zero-shot,” Odoo includes targeted examples where the LLM tends to confuse patterns, effectively making it “few-shot” for reliability.
Why it matters 🧠
This natural language layer reduces the friction between business questions and data analysis. For onboarding, it turns “I don’t know where to find it” into “ask and go there,” revealing UI paths as it performs them. For experts, it composes multi-step actions—switching apps, selecting views, layering domains and group-bys—without breaking flow. Because it respects user permissions, teams retain the guardrails they expect from Odoo.
A tangible example: asking for “POS orders in restaurant config that contain products from the drinks category” triggers the agent to open POS orders, constrain configurations to bar/restaurant, and add a domain ensuring order lines include items from the “Drinks” category. That’s non-trivial to assemble manually, but natural for the agent.
Limitations and roadmap 💬
The team is candid: the system is effective for common patterns but not omniscient. It can get confused and must avoid non-literal values on the right-hand side of domain expressions. Currently, “open menu” supports four view types (list, kanban, pivot, graph). Token payloads are significant—on the order of ~10k tokens per request in a database with many apps—and a single user query may trigger multiple requests, impacting cost and latency.
Security and privacy depend on the chosen LLM provider and contractual controls (e.g., no data used for training). The agent does not currently use local models; support may come later. Field descriptions aren’t sent; the model infers meaning from names and structure. Tooling is extensible via server actions, and model/field restrictions are possible through code customization. There’s no caching or prompt-history layer yet, and a “strict mode” pre-prompt can confine answers to agent-linked sources.
On the roadmap, the team aims to show which menu the AI opened, expand search-bar feature coverage, and reduce context payload via RAG, pruning the menu set before reasoning. That’s a classic trade-off: lower token costs via more API steps, potentially increasing total latency. But the direction is clear—tighter context, stronger guardrails, and deeper app-level specificity. The takeaway: constrain the agent’s intent (UI navigation and search composition) and invest in rich, accurate metadata per app to keep it reliable. 🧠⚙️
PART 2 — Viewpoint: Odoo Perspective
Disclaimer: AI-generated creative perspective inspired by Odoo's vision.
Our mission has always been the same: make powerful things simple. “Talk to your ERP” is another step in that journey—an interface that feels natural while staying true to the structure and security of Odoo. We don’t want AI to guess; we want it to execute with context, permissions, and a clear intent: help you reach insights and actions faster.
We built this with openness in mind. The tools are extensible, the prompts are customizable, and the community can specialize behavior per app or industry. As we refine the heuristics and reduce payloads with better retrieval, the experience becomes more predictable and more helpful—without sacrificing the integrated, modular fabric that makes Odoo unique.
PART 3 — Viewpoint: Competitors (SAP / Microsoft / Others)
Disclaimer: AI-generated fictional commentary. Not an official corporate statement.
Natural language navigation is becoming table stakes across enterprise suites. Odoo’s approach is pragmatic: couple LLMs with tool calls, permissions, and UI heuristics. The real test is scale—latency, token costs, and governance in larger environments. Enterprises will look for deterministic behavior, auditability, and strong separation of duties, especially when queries span accounting, HR, and regulated domains.
The differentiation will hinge on depth and control. Microsoft’s Copilot and SAP’s Joule emphasize compliance posture, data residency, and model flexibility (including private or regional endpoints). Odoo’s extensibility via server actions is promising; success will depend on expanding view coverage, adding robust RAG, and offering choices around hosting and model vendors. If they keep the UX crisp while hardening controls and performance, they’ll have a compelling alternative for mid-market and fast-scaling organizations.
Disclaimer: This article contains AI-generated summaries and fictionalized commentaries for illustrative purposes. Viewpoints labeled as "Odoo Perspective" or "Competitors" are simulated and do not represent any real statements or positions. All product names and trademarks belong to their respective owners.