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, mail, and base_automation.

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

• ai_agent server-action state — adds the Run AI Agent option to ir.actions.server.state, with _run_action_ai_agent (single record) and _run_action_ai_agent_multi (multi record) handlers that both dispatch through one helper. Available to anything that runs a server action: contextual actions, base.automation rules, and ir.cron scheduled actions.
• ir.actions.server fields — agent_id, agent_prompt (translatable inline template), agent_dispatch_mode (single / per_record), agent_record_source (domain / Python), agent_record_domain, agent_record_code, agent_max_records_per_fire (default 100), the four per-action caps, and agent_chain_strategy (none / per_record).
• muk_ai.session extension — action_server_id, base_automation_id (related), previous_session_id, and res_model / res_id linking each session to the record it was spawned for. A _search / _check_access override grants a non-admin read access to a linked session whenever they can read the underlying business record.
• Chatter mirror — every spawned session linked to a record posts an internal note (mail.mt_note) on that record back-linking to the session form. Records without a chatter are skipped silently.
• AI Sessions chatter box — an OWL component injected into the Discuss chatter listing the AI sessions linked to the current record, live-updated over the bus, with a count badge, expand / collapse, click-to-open (live chat for your own sessions, form view for others'), and a View all link.
• Manage menus — MuK AI > AI Automation Rules (base automation rules whose server action is ai_agent) and MuK AI > AI Scheduled Actions (crons pointing at an ai_agent server action), both restricted to Settings users.

How a server action fires an agent

Create an ir.actions.server and set its Action To Do to Run AI Agent. The AI Agent section then exposes:

• Agent — required when the state is ai_agent. The agent that runs every spawned session; approval mode, system prompt, tool filter, model and read-only flag all come from the agent record.
• Agent Dispatch Mode:
  • Single — one session per fire. The prompt template receives the full records recordset the action resolves.
  • Per Record — one session per resolved record. Each session inherits res_model / res_id from its record and mirrors a note to that record's chatter.
• Agent Record Source — how the target recordset is resolved when the action is not already invoked against records:
  • Domain — a safe-evaluated Odoo domain (agent_record_domain, default []) searched on the action's model.
  • Python — safe-evaluated code (agent_record_code) that must assign a recordset to the records variable. Context exposed: env, now, today, datetime, date, time, timedelta, relativedelta. Invalid code or domains resolve to an empty recordset rather than raising.
• Agent Max Records Per Fire — caps a per-record fire to the first N resolved records (default 100; 0 means no cap).
• Agent Prompt — the initial user message sent to the agent, rendered as an inline template (see placeholders below).
• Agent Chain Strategy — Per Record links each new session to the most recent prior session for the same (action_server_id, res_model, res_id) tuple via previous_session_id; None disables chaining.
• Caps — four per-action hard limits (see below).

When the action runs, the dispatcher first honours any records already in the evaluation context (the records / record passed by a contextual action or automation rule, or the active_ids / active_id in context). Only when no records are supplied does it fall back to the configured domain or Python source. In single mode it spawns one session over the whole recordset; in per-record mode it spawns one session per record (capped by Max Records Per Fire). Each session is created and start()-ed as the action's creator (create_uid, falling back to the admin user when that user is inactive); a failed start() lands the session in the error state with the message rather than bubbling up.

Per-record dispatch and chaining

In Per Record mode the action resolves its recordset on every fire and creates one session per record (capped by Max Records Per Fire). Each spawned session carries:

• action_server_id — the source server action.
• res_model / res_id — the dispatched record. The session posts an internal note to that record's chatter with a back-link to the session form, so every AI run a record spawned stays visible from the record.
• previous_session_id — when Agent Chain Strategy is Per Record, the most recent prior session for the same action and record; unset on the first run. The previous-session proxy lets a recurring agent prompt itself with Last time you said: {{ previous_session.last_text }} and see only the necessary text, not a full transcript.

Caps

Every spawned session is bounded by four limits configured on the action, each falling back to a module-wide default when left at 0:

_agent_effective_caps() resolves the per-action value or the default, and the caps propagate to the spawned session so a runaway agent can never bill unbounded.

Firing from automation rules and crons

Because ai_agent is a normal server-action state, three trigger paths come for free:

1. Contextual / manual actions — run the server action against a selection on a list or a single form record; the selected records flow straight into the dispatcher.
2. base.automation rules — point a rule's server action at an ai_agent action to fire an agent on create / write / unlink / time-based triggers. The session exposes the originating rule via the related base_automation_id. MuK AI > AI Automation Rules lists every rule wired this way.
3. ir.cron scheduled actions — attach a scheduled action to an ai_agent server action to fire an agent on a cadence. MuK AI > AI Scheduled Actions lists every cron wired this way.

The AI Sessions chatter box

Any model that inherits mail.thread gains an AI Sessions section in its chatter, listing the sessions spawned for that record. The OWL component loads the linked sessions through get_ai_sessions_summary (most recent first, capped at 10) with a total count, shows a collapsible header with a count badge and a per-session row carrying a state badge, name and timestamp, updates live over the bus when a listed session changes, opens the live chat client for sessions you own or the session form for others', and offers a View all link to the full filtered session list.

Visibility respects record access: the session _search / _check_access overrides let a non-admin read a linked session only when they can read the underlying business record (or own the session), so the box never leaks sessions across records a user cannot see.

Credits