Native ROADMAP

[etobella]

After some talks in the Spanish OCA days, I think it would be nice to mark a roadmap. This is still in draft and we need a review of other PSCs, but I wanted to share my insights with all the community.

1. ai_tool

• The module must remain cross-functional and simple enough to be used by MCP and ai_automation (that's why it has its current structure)

2. ai_connection (new module)

• Handles all AI execution logic — no server actions
• Should be cross-functional
• Depends on ai_tool
• No connectors included — specific connectors will live in their own modules:
  • ai_connection_ollama
  • ai_connection_openai

3. ai_automation → ai_server_action

• To be renamed
• Keeps the logic for automation for that part.
• No dependancy on specific connector, just ai_connector

4. ai_mcp

• Keeps its dependency on ai_tool — no changes here

5. New Repository

• New repository called ai-tools to define the different tools there.
• I have some proposals if there is interest

6. field_vector_config

• New module that will allow to define vectorized fields and search over them.
• Quite useful for tools
• I already have a proposal for this

@ValentinVinagre @acysos @jelenapoblet

[jelenapoblet]

@oliverg09 @yoadria @srodriguezb84 please take a look at this roadmap and let's discuss alignment

[angelmoyaSidoo]

Hi everyone!

Great roadmap, thanks for putting this together. It perfectly captures the direction discussed during the OCA Days.

Regarding point 5 (New Repository): I’ve checked and noticed that the ai-tools repository hasn't been created yet.

I am highly interested in this specific part and would love to start working on it. Could someone from the PSC help with creating the repository? I’m ready to jump in, contribute, and start submitting my proposals as soon as it's up and running.

Looking forward to collaborating on this!

[pedrobaeza]

You can propose it in https://github.com/OCA/repo-maintainer-conf/

[etobella]

Hi @angelmoyaSidoo repository has not been created because we are waiting for a meeting to align and approve the Roadmap. I wanted to share it with everyone so anyone can put their comments. I hope it will be reviewed and approved soon

[etobella]

in english please. there is people outside of spain

[oliverg09]

Hi @etobella , I think this is a very interesting and necessary roadmap. In my opinion, in addition to properly separating the logic into modules, it would be a good idea to consider creating a generic tool that allows users to connect to any external API in a configurable way.

After all, most integrations with AI providers, external services, or specialized tools are done through APIs. Therefore, having a generic tool would allow for the reuse of a lot of common logic: authentication, endpoint configuration, headers, parameters, handling of responses, errors, and traceability.

Regarding field_vector_config, I think it would be very interesting to evaluate Qdrant as the primary backend for vectorization and semantic search. Based on past experience, PostgreSQL with vector extensions can be a valid option in certain cases, but it does not always offer the same precision or quality in semantic searches as a specialized vector database like Qdrant.

On the other hand, we would like to better understand what your specific proposal is for this part. Our understanding is that field_vector_config would allow us to define specific fields for vectorization, enabling the agent to locate information more quickly and contextually. It would be helpful to clarify in which scenarios you propose using vector search instead of traditional structured queries, and how you would determine which fields are worth vectorizing to provide real value to the agent.

[etobella]

Hi @etobella , I think this is a very interesting and necessary roadmap. In my opinion, in addition to properly separating the logic into modules, it would be a good idea to consider creating a generic tool that allows users to connect to any external API in a configurable way.

After all, most integrations with AI providers, external services, or specialized tools are done through APIs. Therefore, having a generic tool would allow for the reuse of a lot of common logic: authentication, endpoint configuration, headers, parameters, handling of responses, errors, and traceability.

For that reason, I was preparing ai_oca_connection. The problem of the providers is that sometimes everyone adds their own layer. However, litellm is solving this issue for most cases. I was thinking of using openai as default layer and leave people to decide if using litellm or define new connectors.

Regarding field_vector_config, I think it would be very interesting to evaluate Qdrant as the primary backend for vectorization and semantic search. Based on past experience, PostgreSQL with vector extensions can be a valid option in certain cases, but it does not always offer the same precision or quality in semantic searches as a specialized vector database like Qdrant.

No. Qrant is a new external system for handling vectors. That implies that you are adding an extra point of failure. We can leave the space for qdrant if you want, however, the default tooling will propose using vectors inside odoo database.

On the other hand, we would like to better understand what your specific proposal is for this part. Our understanding is that field_vector_config would allow us to define specific fields for vectorization, enabling the agent to locate information more quickly and contextually. It would be helpful to clarify in which scenarios you propose using vector search instead of traditional structured queries, and how you would determine which fields are worth vectorizing to provide real value to the agent.

The first example is when creating an OCR for invoices. for companies it is easier, but products are not created in the database the same way that our suplier does. this allows to search the products in a better way that gives better solutions.

Same could happen with other kinds of informations that we need to verify in the system (like vectorizing documents or module readmes to search more efficiently)

[pdaucht]

The objective of these comments is to share our experience during our nearly two-year process of integrating Artificial Intelligence (AI) into Odoo.

Despite Qdrant's relatively short time in the market, it is important to note that it was designed specifically for AI. Its performance and stability position it among the top four database management systems currently used for this purpose.

Regarding PostgreSQL, while it offers vector support, it is not a native feature. Odoo has included native vector support starting with version 19.0; however, to our knowledge, this is limited to the Enterprise edition. From a systems architecture perspective, implementing vectorization directly within the Odoo database would complicate management for large, unattended infrastructures. This creates limitations regarding client data portability, as importing the database would require the target environment to have PostgreSQL vector support pre-installed.

Our assistant, Emma, has had OCR capabilities implemented for some time. In early versions, we used AI to perform searches, which occasionally resulted in inconsistencies during the retrieval process. After testing various options and methodologies, we determined that fuzzy search was the most optimal method, which increased the process quality to 98%.

Undoubtedly, vectorization makes searches significantly more efficient. While we initially experimented with Supabase—which is based on PostgreSQL—daily usage proved it was not sufficiently efficient. In our search for better performance, we transitioned to Qdrant. Its stability and efficiency proved superior to its predecessor, and our current implementation of Qdrant specifically for knowledge base management has successfully led to the deployment of our agents to over 50 clients.

[etobella]

I understand your needs and we will keep the door open if any dev want to use other tools. That is the magic of OpenSource. However, as I said, postgres has vectors and thst will be the main source I will promote for several reasons, the main one is that this way you don't need an extra element in your stack. That is a good decision from a maintainability perspective. In some cases Qdrant might have sense, the same for postgres vector. Also, all the vector system is inside odoo and orm security applies. Can you say the same for Qdrant?

I know that you have been working for some time in AI, the same for a lot of people who has been working inside this repository. We were the ones that made the bridge and by experiencing and evaluating license incompatibilites, we decided to open the native work. be aware that we didn't drop the bridge as we understand that it has space, but that doesn't mean that we are going to use it. We don't expect that everyone follows our path as anyone is open to propose modules in OCA. Feel free to do that for the Qdrant vector system.

[angelmoya]

Hi everyone,

Just to share where I am: I am currently exploring how ai_connection could work under the hood, but it's still in the early stages and I won't be submitting a formal proposal or PR just yet.

Regarding skills, I also have a rough idea floating around. It would be interesting to have a structured way to load or sync external packages of predefined skills into Odoo, so the system can detect and invoke them when processing a query. I don't have a clear architectural design for this yet, but I wanted to throw the concept out there: Does anyone have a clear idea or experience on how we could cleanly integrate skills management into Odoo?

[etobella]

@angelmoya nice idea! do you have any information of how to call skills from python code by using claude or openai or any other AI?

[angelmoya]

@etobella Exactly!

From what I've been testing and exploring, a skill usually has two main components when interacting with LLMs (like OpenAI or Claude via Function Calling/Tools):

• The Prompt/Metadata part: A JSON schema that defines the skill's name, description, and expected parameters. We pass this definition to the LLM context so it knows the skill is available.
• The Execution part: When the LLM decides to use the skill, it returns a tool call with the extracted arguments. Then, our Python/Odoo code executes the actual logic (calling python scripts, Odoo methods, or external APIs) and feeds the result back to the LLM.

If we align our architecture with standard formats, we could potentially import and reuse ready-made skills from external repositories, such as https://skills.sh.

I'm currently running some tests and prototyping how we could structure this dual nature (definition + execution) cleanly within Odoo records. I'll share more insights as soon as the tests yield some clear patterns!

[angelmoya]

Hi team,

I have reviewed @etobella PR (#77) introducing the ai_connection base module and submitted a review with some suggestions aimed at making the core interface more powerful and extensible for downstream modules. The feedback focuses on areas like structured return values from _run_ai(), client contract enrichment (usage, model, tool call IDs), iteration limits, and better error handling — all oriented at enabling a clean ecosystem of modules on top of this foundation.

In parallel, I had been working on an extended version of the same concept. Rather than duplicating effort, I have refactored my work into a set of complementary modules that build on top of ai_connection, and I have pushed them to a WIP branch here:

Branch: 18.0-wip

The WIP modules are:

• ai_connection_base_openai — OpenAI-compatible HTTP client provider that other AI services can reuse.
• ai_connection_openai — Native OpenAI connection implementation.
• ai_connection_ollama — Ollama connection implementation (local and cloud).
• ai_connection_session — Session and call persistence, message history, call tracking with token usage, and an integrated prompt wizard.
• ai_skill — Skill management: store, categorize, and inject skill context into AI calls; sync skills from disk.
• ai_tool_web_fetch — Standalone web_fetch tool for AI connections.

My intention is to align these modules with the upstream ai_connection base once the PR is finalized, and then propose them as follow-up contributions to the OCA/ai repository.

Best regards,

[angelmoya]

Hi all,

Quick update on the 18.0-wip .

The base modules are now tested and working on Odoo 18. I’m continuing to explore and build the autonomous agent ecosystem on top of them.

New modules in progress:

• ai_server_action — Server actions that run prompts against an LLM connection and store/post/update the response.
• ai_tool_server_action — Exposes existing server actions as ai.tool records so agents can call them.
• ai_agent — Autonomous agents with souls, protocols, per-user threads, planning, and jobs.
• ai_agent_multi — User/group access rules for agents.
• ai_agent_orchestrator — Orchestrator agents that delegate tasks to member agents.

All these modules have tests and READMEs, and the full test suite passes in Docker on 18.0-wip.

I’ll keep sharing progress as the agent modules mature.

Regards.