Repository Roadmap

[etobella]

Lately there has been a lot of comments regarding the future of the repo. Here would be the place to discuss about it. From the PSCs perspective, there is 3 paths:

• Native: The workflow is handled within odoo. the only external part is the connection towards the LLM or AI system. Similar to Odoo EE AI

  • Pros: All in odoo
  • Cons: Harder to achieve complex workflows.
  • Not implemented yet

• Bridge: The workflow is handled by an external system (n8n, cursor...).

  • Pros: Independent of the external system, that is usually prepared for handling this kind of things
  • Cons: One extra app to handle, license struggles
  • Current implementatoion

• MCP: Opening a gate for external systems to integrate with Odoo (Odoo is not launching the AI)

  • Pros: Current standard. Integration with external AI Agents
  • Cons: Security concerns
  • There are some proposals about this.

[etobella]

@pedrobaeza @tishmen This should be the place for discussion.

IMO, MCP has a lot of concerns mainly for security issues. For example, we have seen MCP examples, where the AI was able to revert a posted invoice. For me it is not an option right now. In any case, that is my personal opinion. Anyone is open to propose an MCP server module

About the native, we have been checking it and the natural way for doing it would be using pydantic-ai for connecting with external systems. And then, makiing some automation tools. We could do also the chatter bot using it. However, as I said before, I don't have the time right now. I assume that I will be able to do it in the future. Another topic is that the bridge allowed me to see how we can handle it easily. The bridge is a good approach for making mock ups and checking if we can deliver the functionality

[tishmen]

@etobella @pedrobaeza Thanks for opening this discussion! Just to clarify why I initially commented on the 19.0 migration thread - my focus is on developing against Odoo 19 right from the start, so naturally my contributions will begin there.

Native approach (similar to Odoo Enterprise AI)

This is the path I intend to work on, and I currently have the time to dedicate to it. My plan is to:

• Add observability and grading (requests and responses saved for evaluation, grading, and cost analysis, on a per-user basis, similar to LangSmith).
• Keep the agent flexible enough to execute anything an Odoo user can within the bounds of a server action, so complex workflows are still possible.
• Use the Discuss module as the single point of user interaction, making it seamless. This means a lot of JS/OWL code.

Bridge approach (n8n, etc.)

I think this has real merit for fixed workflows. n8n is a great option here because it’s visual and easy to configure. This could align nicely with how fixed wizards are handled (similar to the MCP PR for v16).

MCP approach

On security concerns: I don’t plan on using the MCP repository I previously linked. Instead, I’ll rely on server actions to expose internal Odoo methods, which keeps everything within Odoo’s own rules and permissions framework. That way, security is preserved by design.

[etobella]

@tishmen Probably, the cleaner option right now would be to create something like the bridge that allows us to process like chained actions and create one action that asks directly to an AI system. Actually, it could be really easy to make the chatbot as we have the code to make it in n8n.

about the n8n and so on, for me, it is better for making drafts or creating new workflow ideas. it is easier for users. However, at the end it will have sense to add an internal system for doing that.

[tishmen]

@etobella Thanks for sharing your thoughts!

I’ll be moving forward with developing the native integration as part of a larger project that I intend to open source. Once the code is ready - if the quality and functionality are on par - we can look at merging it into this repo and continue the conversation from there.

In the meantime, you can absolutely continue working on the bridge module - right now I don’t see any conflicts between the two approaches. They actually complement each other well: the bridge for easier fixed workflows and the native integration for deeper, seamless handling inside Odoo.

[arielbarreiros96]

Hello everyone, thanks for bringing this topics to the public attention, also thanks @etobella for opening this issue for discussing roadmap.

I totally agree with the approach of creating native ai features for CE, and I do believe I can be very helpful (specially when performance is critical) to have such capabilities on hand, this is why from the very beginning (#1) this was taken into account. In relation to this, I think the best approach would be to define base objects and let others take those blocks (agents, tools, etc) for creating their own implementations, the idea of taking an existing mature/well supported libraries is on the essence.

@tishmen In relation to MCP, IMO there are two things to bare in mind, first there is the mcp-client, which I don't see how could this not be ai_native, then there is the mcp-server. From my point of view, there are several things to bear in mind on the server side:

• MCP server is not necessarily native or bridge (they could be accessed from the outside but also by native applications)
• Security should be Top 1 priority here, on this implementation the MCP is a two part system, one making the magic and the other basically checking access rights, like you have mentioned this is not quite what we need, but permissions are not so simple to handle like checking Odoo's access rights for a user. IMO a good MCP should have the ability of understanding data structure and explore its environment (actions, models, fields, views, etc.), but most users should ever see that. Let's take this example:
  • We define an "Agent" (let's call it "Snoopy") that agent has a tool which uses Odoo's MCP
  • We start the conversation with the Snoopy, we're talking about a record and we ask him to set the "Secret Field" to "Secret Value", but since secret_field was added using an OCA new module, there is no way "Snoopy" knows this from its training data, so Snoopy uses its very useful tool for knowing data structure and finds the secret_field which happens to be a text field (for the sake of simplicity).
  • Snoopy knows what field I'm referring to, knows what value I want to set, and has the permissions to do it, but it can't do it, because it first has to check MY permissions, because maybe I'm not supposed to do it.
  • This is in my opinion the main dilemma, any useful Odoo MCP should somehow verify two sets of permissions, the ones of the user "using" the MCP, and the ones of the actual user. Of course you could always use only one set (by design or by defining permissions_caller_user=permissions_actual_user) but this will probably defeat MCP's "magic".
• At last my other concern here is that AI doesn't really know what's "possible" and what not, so there will be ALWAYS responsibility on the human behind using it, for instance there is the case Enric mentioned before, there is nothing preventing agents from changing paid invoices back to draft, and then cancelling them, instead of creating a credit notes, this is "possible" from the AI perspective (while maybe not the intended behavior), therefore if there's nothing preventing it, it will happen eventually.

That being said, I'm willing to help in the efforts for creating a robust MCP that everyone could use as safely as possible.

For the moment we'll continue to push the usage of ai_oca_bridge and continue to create features to enrich that experience. I think at the end this will be beneficial since having the two ways of interactions will only enrich the experience and the amount of tools available.

Hope all this makes sense to you. Thank you all for reading up to this point 😅

BTW, if anyone has ideas to include on the roadmap posted at the beginning of the issue, feel free to comment, so hopefully we don't overlap

[tishmen]

@arielbarreiros96 I agree with everything you said, especially on the security part — that’s exactly where I think we need to be most careful.

I think the cleanest way forward is to make server actions the core building block.

• Server actions can already respect Odoo’s ACLs and permissions, so they’re a natural way to handle security.
• Each server action could host metadata (parameters, schema, description, etc.) that a generic MCP server can expose externally. That way the agent will simply use the server actions as tools, instead of talking directly to the database or models.
• For fixed workflows, those same server actions could also call n8n via REST API, making it possible to design predictable, visual flows while still reusing the same foundation.

This approach gives us one consistent layer:

• Native agents call server actions directly.
• MCP discovers and calls the same actions via metadata.
• Workflows (n8n) can be orchestrated through server actions making REST calls into n8n.

On top of that, we should add observability to track requests, responses, and costs. This will need to be a high-performance integration, since it will be very write-heavy.

That way we don’t have to maintain parallel integrations — everything converges on secure, observable server actions.

@pedrobaeza @etobella @arielbarreiros96 what are your thoughts on this unified approach?

[tishmen]

To add to my previous comment — clients will be responsible for managing their own server actions, meaning they will need to add and maintain new ones based on their business needs.

What we can do on our side is provide sensible defaults and a few example server actions to serve as a starting point. This way, users can extend the system safely without us having to maintain every possible use case.

Also worth noting: server actions can leverage the queue module (already ported to v19, waiting on merge) for asynchronous execution and reliability, which makes them scalable even for long-running or resource-heavy tasks.

[arielbarreiros96]

Hello @tishmen I can't quite picture an MCP server relying solely on server actions, it could be great though, if it could also use them.
Even with that approach, still we have the permissions issue, take into account that for certain things the agent may need a higher security clearance than the "actual" user.
Anyway, if you already have something in mind (or in the oven) you can open a draft PR and we could start figuring out the rest from there 😉 👌

[tishmen]

@arielbarreiros96 Thanks for the input 🙌

In the next week or so I should have an implementation ready (without the observability part for now). Once that’s up, I think the best way forward is to let the code do the talking, we can then discuss and refine based on something concrete.

I'll let all of you guys know when it's ready.

[ValentinVinagre]

Nothing to say that @etobella @arielbarreiros96 hasn't already mentioned. For one thing that hasn't been mentioned in these conversations, ai_native isn't currently planned, as we're currently working on other projects. However, I'd say one of us could get started by the end of this year or early next year. I'm honestly not convinced about the mcp approach, but we're always open to suggestions. Regarding ai_native, we're putting forward a few interesting opinions, ideas, and frameworks to implement it in a generic, connection-independent way.

[tishmen]

@ValentinVinagre Thanks for the clarifications and for keeping this discussion open. I understand you want to proceed with the bridge-first approach and I fully respect that decision, it’s a pragmatic path to validate workflows quickly.

I’ll keep an eye on progress and I’m happy to help with testing or anything else you need along the way. In parallel, I’ll continue developing my native solution (targeting 19.0). If it reaches the right level of maturity and aligns with the project’s direction, I’ll propose it for inclusion in the future. Until then, I’ll iterate independently so both tracks can move forward without blocking each other.

[ValentinVinagre]

Okay. I'm sure you're doing great work and it will be a great contribution to the community, and we'd be delighted if it ends up happening.
Best regards.

[etobella]

@tishmen I think that both paths do not collide and they have place here.

What we are saying is that both paths have benefits and we don't want to disminish one for the other. The only reason for not having ai_native right now is that it fitted better to our customers the bridge one, but we are sure that we will see it here at some point. I hope that you can share you work here because it is an interesting solution for everyone.

[marcelsavegnago]

We currently have a PR for an mcp_connector, but this is just an initial test and should not be considered a definitive implementation. The idea was to spin up each MCP server from Odoo, receiving an input and returning an output.

At the moment, I’m focusing more on the ai_oca_bridge — currently using n8n as a workflow automation tool, but I’d like to adopt a similar open-source alternative in the future. I haven’t had the time yet to evaluate other options, but it’s something I plan to explore further.

That said, if anyone finds this interesting and wants to collaborate, any help is more than welcome — including evaluating whether this approach actually makes sense or not 😅.

#40

[ValentinVinagre]

@marcelsavegnago @tishmen I think both could collaborate with the MCP since if they have a similar need they could model it together. What do you think?