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 (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.