Installation

To install this module, you need to:

Download the module and add it to your Odoo addons folder. Afterward, log on to your Odoo server and go to the Apps menu. Trigger the debug mode and update the list by clicking on the "Update Apps List" link. Now install the module by clicking on the install button. Requires muk_ai, Enterprise ai, and a PostgreSQL server with the pgvector extension if you want RAG to work.

Upgrade

To upgrade this module, you need to:

Download the module and add it to your Odoo addons folder. Restart the server and log on to your Odoo server. Select the Apps menu and upgrade the module by clicking on the upgrade button.

What's in the box

• muk_ai.agent extension — two Many2many fields, ee_topic_ids (→ ai.topic) for tool reuse and ee_source_ids (→ ai.agent.source) for RAG reuse, plus an Enterprise notebook page on the agent form to pick them.
• muk_ai.session extension — appends a <rag> block to the rendered system prompt when the agent has ee_source_ids set and the latest user message can be embedded, and an <ee_ctx> block when the session's view_context pins a record. Both are no-ops when their inputs are empty.
• muk_mcp.tool extension — when a MuK AI session is running for an agent that has ee_topic_ids set, the bridge injects each Enterprise server action into get_tools() as ee_action_<xmlid_name> and dispatches _call\ s with that prefix through Enterprise's _ai_tool_run. The same extension carries the adapter helpers that resolve a tool name back to its ir.actions.server record, enforce the use_in_ai filter, coerce the action's JSON schema into the MCP shape, run the action against the session's pinned record (or the calling user as a fallback), and serialise the result back through the standard muk_mcp.log audit trail.

Configuration

1. Install MuK AI Enterprise Bridge. It pulls in muk_ai and ai automatically.
2. Open MuK AI > Agents and edit a MuK AI agent.
3. On the new Enterprise notebook page, pick the topics whose server-action tools you want exposed (EE Topics) and the RAG sources you want injected (EE RAG Sources). Both fields default to empty; selecting nothing opts out.
4. Optional: open a record that has a non-trivial _ai_initialise_context override and open the MuK AI chat on it — the per-record context flows into the prompt automatically, no per-agent setting needed.

Tools

Every action in the picked topics that has use_in_ai=True is exposed as a single MCP tool named ee_action_<xmlid_name>. The description, JSON schema and category are read straight from the Enterprise record, so you configure the action once in AI > Configuration > Topics and both surfaces (Enterprise chat and MuK AI chat) see the same tool.

Dispatch routes through Enterprise's ir.actions.server._ai_tool_run under the calling user's environment, so Enterprise's access checks and audit hooks all run unchanged. The MuK AI session's muk_mcp.log records the call exactly like it would for a native MCP tool — including arguments, response, status and timing.

When the MuK AI agent has read_only=True, ee_action_* tools are filtered out of the schema entirely and any direct dispatch raises a UserError, so a read-only agent can never mutate through Enterprise tools.

The action runs against the record pinned in the session's view_context (kind='record'). For sessions without a pinned record, the calling user is used as the fallback record so actions that don't care about a record target keep working unchanged.

RAG

On every user message, the bridge embeds the latest user text via LLMApiService.get_embedding(...), queries ai.embedding._get_similar_chunks(...) against the agent's ee_source_ids, and appends the top hits to the rendered system prompt inside a <rag>...</rag> block. The embedding model and dimensions are read from Enterprise (ai.agent._get_embedding_model and ai.embedding._get_dimensions), so changes on the Enterprise side flow through immediately.

When the source-set is empty, the user message is empty, embeddings fail, or pgvector is missing, the <rag> block is silently skipped — never injected as a half-empty placeholder.

Per-record context

When the MuK AI chat opens on a record, the session's view_context ends up with kind='record' plus the model and id. The bridge intercepts that, calls record._ai_initialise_context('mail_composer', None, None) (the same hook Enterprise uses for its mail composer flow, which returns the record's serialised field values plus any model-specific augmentation) and stores the result in view_context.ee_init_context. The system prompt rendering then appends it inside an <ee_ctx>...</ee_ctx> block.

Models without an _ai_initialise_context override fall through silently. Records inheriting mail.thread get the chatter history mixed in for free, courtesy of Enterprise's existing mail.thread._ai_initialise_context override.

Coexistence

The bridge depends hard on muk_ai and ai but on no other Enterprise ai_* satellite. Optional satellites — ai_documents, ai_livechat, ai_fields, ai_server_actions, ai_knowledge, ai_website, ai_crm, etc. — simply contribute more ai.topic and ai.agent.source records that admins can then pick from the new Enterprise notebook page. Nothing else needs to change.

Uninstalling a satellite cleans up its M2M references through Odoo's default ondelete behaviour, so a MuK AI agent that used to expose ai_crm.topic_create_lead simply stops seeing ee_action_topic_create_lead after ai_crm is uninstalled — no crash, no orphaned tool entry.

Credits