cc @OCA/ai-maintainers @etobella @ValentinVinagre @arielbarreiros96

I don’t think we should add n8n as a dependency for AI features in Odoo.

• It’s a large external orchestration platform that adds operational and maintenance complexity for everyone, even when they don’t need it.
• n8n is not fully open‑source (not OSI‑approved), which doesn’t align well with OCA’s typical expectations for core dependencies.
• There’s no strong need to depend on it to deliver AI capabilities in Odoo; we can implement these natively.
• If we do consider heavy frameworks, options like LangChain or AutoGen provide broader agent tooling and tend to deliver better outcomes for complex workflows. Even then, such dependencies should remain optional.

Proposed direction:

• Keep ai_native_* as the primary path for built‑in agent functionality and observability.
• Offer n8n (and similar) only as optional ai_bridge_* integrations, not as core dependencies.

I’ll provide a native module in the coming days that covers an agent plus observability (tracing/metrics) without external orchestration. Happy to align on minimal interfaces and extension points so bridges can remain optional.

@tishmen thanks for your comments, but be aware of:

1. None of the modules here are core modules. OCA offers a lot of options, but none of them are "core" or "required" for your installation. It is part of the implementation process to decide what do you want to add on your system.

2. We are using n8n on a personal basis, but the bridge system is agnostic of that. We are not adding that dependency. We offer the examples using it, but you could decide to use any other external system (even privative systems). There is no license conflict here. it is like using fs_storage. It is agnostic on the destination, so there is no problem if you use Google Drive or Microsoft SharePoint

3. Using n8n or any other tools has some benefits, as it is easier (and faster) to create complex workflows. Much easier than EE Odoo AI system (the only native solution we have right now).

4. Also, it is easier when you are creating new workflow, easy to test and easy to deploy

5. Right now there is no ai_native_* modules in the repository. It is part of the roadmap, but we have not reached them for several reasons:

   1. native modules will be more limited and complex options will not be there, like using external files, sending to external systems and so on
   2. using external services offers extra capabilities that will not be achieved with ai_native
   3. no one has done it or paid for creating them. And that is the most important one. We understand that native might be an interesting approach, however, OpenSource is not free. It requires time (so money) to make it and noone has invested time (or paid someone to do it).

6. OCA will not mark which solution is better or more aligned with their open source concept. At the end, both approaches have sense and are OSI aligned. They come from different evolutions, so they can coexist peacefully. It would be different on a fork, but in this case, both options were defined on the begining.

IMO, native modules will appear, but native and bridge will coexist as both have their own sense:

• native will be better when the workflow is better defined and only has sense inside odoo. Making it inside odoo will make it faster. However, configuration will be harder or more complex if we don't invest a long time to reach similar capabilities that, IMO, it has no sense to add.
• bridge will be better at the begining, as users are usually not sure of what they are looking for. With time, things will simplify and if the process is critical, they will look how to do it with native.

Just to be clear of the PSC perspective, yesterday we had a PSC meeting (before your comment 😉) and we have this roadmap in mind.

I will wait for you PR and check what you did to achieve the native modules.

In any case, I will try to invest some time on it at some point, but it will be in a few months.

I also want to go to native approach.

@pedrobaeza @etobella I’ve already forked the repo and started working on a native AI implementation.

My proposal is to leverage an MCP server for secure external tool access into Odoo, similar to this example: https://github.com/ivnvxd/mcp-server-odoo.
For internal flows, the native Odoo AI integration can rely on predefined server actions to maximize compatibility with existing features.

That said, I believe the first essential step is to have a native Odoo agent implemented. From there, we can add observability (tracing/metrics) and ensure external bridges remain optional.

there is already a mcp proposal. Please align with the current module please.

@etobella Are we discussing about the following PR: #40?

yes, anyway, this is not the thread for discussing the roadmap. I will open one just for that

@etobella Just to clarify, I think the MCP server you’re referring to is the one used for defining and consuming external MCP tools inside Odoo (the mcp_connector from this PR).

The server I shared earlier (https://github.com/ivnvxd/mcp-server-odoo) works in the opposite direction: it exposes internal Odoo models and actions as MCP tools/resources to any external MCP client (Claude Desktop, Cursor, etc.). Both approaches are complementary and ultimately both are needed for a complete ecosystem:

• mcp_connector → Odoo as a client of external MCP servers.
• mcp-server-odoo → Odoo as a server exposing its own tools/resources.

One important detail: in this PR the functionality is triggered via a wizard, which is quite rigid and limited to one-off calls. For maximum flexibility, we should evolve this into an agentic loop (Odoo AI agent that can decide and iterate across multiple tool calls).

That said, we must ensure that this agent loop is strictly bound by Odoo’s permissions and record rules, so that we never expose more than what a user already has access to. That way we preserve security and consistency while still enabling more powerful agent workflows.

Please open a new thread and we can continue the discussion over there. Thank you!

I feel that if there's an OCA official MCP implementation, it should rather be built on top of the fastapi module from the OCA rest framework. In particular the linked module reimplements auth, audit log, and puts everything in fat controllers.

we must ensure that this agent loop is strictly bound by Odoo’s permissions and record rules

I think any sensible implementation would go through the ORM, so it's more of a matter of giving it the discovery tool that is already properly filtering objects by the current user ACLs.

Which I think leads to one of the most important point of the design. You have essentially 3 possible modes, which would be read-only, read-write, and read-write-with-approval. So the toolsets needs to be different. And even looking just at one given mode, readonly to make things simple, there are different ways to implement this. Here are the options:

1. stick to Odoo ORM methods. The obvious downsides is that these methods are actually quite complex to use properly. Just go look at def read_group for an example source docstring. It's so complicated that the LLM messes a lot of calls.
2. Make simpler tools to call. The problem is that there is context-pollution. The LLM has knowledge of Odoo, and will mix the syntax with Odoo syntax (in my tests, it was much worse)
3. Tools can optimize payload size or LLM processing time. If calls are expensive, it's better to give it all parameters at once, and let the clever model work on it. If working with a very fast but more limited LLM, you want the tools to return only the essential information, and make more calls.

So, you have at least the mode and LLM type dichotomies to account for.
I think a shared solution needs to account for these, and so provide a way to compose the toolset to instantiate your agent properly -- properly in the sense that it will perform reliably and fast enough.

• ai_oca_bridge: [19.0][MIG] ai_oca_bridge: Migration to 19.0 #55

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

Two modules that are not in the list above are being migrated:

• ai_tool — [19.0][MIG] ai_tool #101
• ai_oca_mcp — [19.0][MIG] ai_oca_mcp #102 (depends on [19.0][MIG] ai_tool #101)

Neither appears in the checklist because neither was on 18.0 when it was generated: ai_tool was merged there afterwards, and ai_oca_mcp is still the open #76. Flagging it here so nobody starts them in parallel.

Both install and pass their tests on 19.0 (15 tests, 0 failures). ai_oca_mcp builds on @angelmoya's work in #76 rather than redoing it — one of the fixes it needed applies to 18.0 as well, and is noted in #102.