Odoo 20 Agents in Automated and Scheduled Actions: What Runs Unattended and Where the Person Goes Back In

In Odoo 20, unveiled on 24 September 2026, an AI agent can be summoned by an automation rule or a scheduled action and run with nobody in the chat window, and it can create and update records. Odoo’s documentation says a called tool executes unconditionally, so the approval gate has to be built into the tool, which is how we design the AI agents for ERP in Australia we run.

At a glance

• Who it is for: finance and operations managers on Odoo 19 who are planning the move to Odoo 20, and Odoo 20 administrators who have been asked to “set the agent to run overnight”.
• Problem it solves: Odoo 20 lets AI act on records without a person present. This post separates what runs unattended by default, what you can switch on, and where the person has to be put back.
• Platforms: Odoo 20 (Enterprise; Odoo Online, Odoo.sh and on-premise, with the AI app installed and In-App Purchase credits loaded). MYOB Acumatica is noted for contrast only: its AI Automation feature cannot run on a schedule or an event, per our MYOB AI Automation hand-off note.
• Trigger: an automation rule (on create, on a field change, a timing condition, an inbound email or a webhook) or a scheduled action, with no user session behind it.
• Inputs read: the triggering record and whatever the agent’s skills and sources let it reach; agents with no skills can only answer, per the Odoo 20 AI agents documentation.
• What the agent drafts: whatever the worker tool it calls is written to do. Our tools log a note, schedule an activity for a named person, or create a draft. They do not confirm, post or release.
• Approval gate: in the tool’s Python code, not in the prompt. Odoo 20 shows interactive permission requests in a chat, but there is no chat to answer at 5am.
• Audit trail: the automation chat Odoo 20 keeps for each unattended run (stored for 30 days after the last message per the Odoo 20 release notes), plus the chatter note the tool writes and the ir.logging entry from log().
• Typical cycle time: timing-based automation rules are checked by a scheduled action every 4 hours by default, tightened automatically to minutes when a rule’s delay is under 40 hours, per the Odoo 20 automation rules documentation.
• What it never does: post a journal entry, confirm a sales or purchase order, change a price list, credit limit or tax code, move stock, email a customer, or run against historical records because someone forgot to run the scheduled action manually first.
• Typical cost: every Odoo 20 AI feature consumes IAP credits (release notes); custom code in automation rules is not covered by the Standard or Custom plan and is charged separately per the automation rules documentation. A scoped agent pilot with us starts from $5,000 ex GST per the AI agents for ERP in Australia hub.
• Typical timeline: one unattended agent with one gated tool, built in a staging database, tested against copied records and reviewed for a fortnight: 2 to 4 weeks.
• Last verified: 30 September 2026 against the Odoo 20 release notes, the Odoo 20 AI server actions documentation, the Odoo 20 automation rules documentation and the Odoo 20 AI fields documentation.

Last week we wrote up the Odoo 20 MCP server, which is about an outside assistant reaching into Odoo. This post is the other direction: Odoo itself waking an agent up on a timer or an event and letting it act. That’s the feature the Odoo 20 release notes file under “Agentic automation”, and it’s the one that turns an assistant into something that runs while you sleep.

What changed in Odoo 20 for unattended AI?

Two lines in the Odoo 20 release notes do the work. “Agents can be summoned by automated and scheduled actions” and “Ask an AI agent to update records” sit alongside “Ask an AI agent to create anything for you”. Put together: an agent can be started by an automation rule or a cron job, and it can write.

In Odoo 19 the pieces were separate. You could build a custom agent with tools, and you could build an AI server action that picked a tool for a record, but the agent lived in a chat and the server action was the only unattended piece. We covered how Odoo 19 agents run within the signed-in user’s rights in our guide to AI agents in Odoo. Odoo 20 keeps all of that (Topics are now called Skills, and the preconfigured list includes Update Records and Create Records) and adds the trigger.

A label on the claim, because the freshness rule matters here. The trigger is stated in the release notes, which describe shipped Odoo 20 features. As at 30 September 2026 the automation rules documentation for 20.0 still lists the classic action types (Update Record including Update with AI, Create Record, Create Activity, Send Email, Execute Code, Send Webhook Notification, Multi Actions) and does not yet document an “ask an agent” action, so the documented unattended pattern is the AI server action. Treat the agent-in-a-cron detail as shipped but thinly documented, and test it in staging before you rely on it. The release notes also add that agents “can now update themselves” to suit their use cases, and that is the line we’d switch off for anything unattended until it’s clear what an agent can change about itself.

What already runs without a person in Odoo 20?

Three things, and the first one is on before you touch anything.

Table: the four ways AI acts without a user session in Odoo 20, verified against the 20.0 documentation and release notes on 30 September 2026.

The daily AI fields cron is the one most Australian sites will run without knowing it. It’s harmless when the fields are product descriptions. It’s worth a look when someone has added an AI property field that feeds a report your accountant reads, because the field will be recomputed overnight whether or not anyone checked the prompt.

Where does the approval gate go when nobody is in the chat?

The Odoo 20 AI server actions documentation describes the pattern as a manager and a worker. The AI server action is the manager: it reads the record, interprets the prompt, and picks a tool and its arguments. The tool is the worker: a standard server action with Use in AI ticked, whose Python does the actual write. Then the sentence that should be in every Odoo AI policy: “If a tool is called by the AI server action, it will execute unconditionally, unless the code itself prevents it.” The same page says the manager “does not enforce business rules, modify records directly, or guarantee the correctness of the operation”.

That sentence is unchanged from Odoo 19, and we built our whole approval gate in the code pattern on it. Odoo 20 adds interactive permission requests, where an agent asks and the person clicks a button. That’s a real improvement for a person in a chat, and it’s irrelevant at 5am when the trigger is a scheduled action and there’s no one to click. The tool call limit confirmation in the release notes has the same shape: it “prompts the user for confirmation before proceeding”, which is a person’s job.

So the gate goes in three places, and the prompt is not one of them.

• In the tool list. A manager can only call the tools you attach to it. If no attached tool can confirm an order, no prompt, however badly written, can confirm an order.
• In the tool’s code. The worker checks state, amount, date and who it is about, and raises UserError when the check fails. The documentation’s own troubleshooting list is instructive: “Why did the tool run but nothing happened?” is answered with “business conditions were not implemented in the tool logic”.
• In what the tool is allowed to produce. Our unattended tools produce three things: an internal note, an activity assigned to a named person, or a draft record. Confirm, post, release and send are separate buttons that stay with people.

The same three answers apply to an agent summoned by an automation rule, because the agent’s skills are collections of tools, and the agents documentation is explicit that an agent with no skills “cannot complete tasks or make changes to the database”. Give the unattended agent a skill whose tools stop at a draft, and it stops at a draft.

A worked example: the overnight delivery-instruction agent

A Queensland equipment importer on Odoo 20, invented for this post, confirms forty to sixty sales orders a day. Customers type instructions into the order’s note field: “part shipment fine”, “call site before delivery”, “not before 10am”, “hold until PO 4471 arrives”. Dispatch used to read every note by hand at 6am and miss some.

The build is a scheduled action at 5:30am that runs an AI server action over sales orders confirmed in the previous 24 hours with a non-empty customer note. The manager’s prompt asks it to classify the instruction and choose one of two tools. Tool one, Flag Delivery Instruction, writes a structured internal note (“Instruction: call before delivery. Phone on order: yes.”) and creates an activity for the dispatch coordinator due that morning. Tool two, Request Date Change, takes a proposed date as its only argument, checks in Python that the order is in the sale state, that the proposed date is in the future and no more than 30 days out, logs the proposal as a note and schedules an activity for the coordinator. Neither tool touches the commitment date, the delivery order or the customer.

At 6:05am the coordinator opens her activities. Nine orders have flags. Two have proposed date changes, and she changes one of them and rejects the other because the customer’s “next week” meant something different from what the model assumed. Every date that moved was moved by her. The automation chat for the run shows the eleven decisions and the three orders the agent skipped because the note was a signature block, and the log() calls the tools make sit in ir.logging with the order reference.

“The question I ask about every unattended agent is what happens on the night the model is wrong. If the answer is ‘a person finds a note and an activity in the morning’, it can run. If the answer involves a customer, a journal or a stock move, it waits for the person.”

Josh Craig, Director, Auboros

The first-run warning in the automation rules documentation matters here too: run the check-and-execute scheduled action manually once when you create a timing-based rule, or it can fire against historical records. On a sales order model with two years of history, that is not a theoretical risk.

What should an unattended Odoo 20 agent never be allowed to do?

The list is short and boring, and it should stay that way. No tool attached to an unattended manager should confirm a sale or purchase, post or reconcile a journal entry, change a tax code, price list or credit limit, validate a stock move, create or archive a partner, or send anything outside the company. Each of those is a button a person presses after reading what the agent left for them.

Australian context sharpens two of them. A tool that could change a tax on an invoice line is a tool that could misstate your Business Activity Statement (BAS), which is why the ATO’s tax invoice rules stay on the human side of the gate. And a tool that emails a customer is disclosing personal information on your behalf; the Office of the Australian Information Commissioner’s guidance on commercially available AI products treats what you feed a model as a use or disclosure under the Australian Privacy Principles, and an unattended run feeds it a record every time.

The National AI Centre’s Guidance for AI Adoption makes the same distinction in plain words: a chatbot answering simple questions in business hours under a staff member’s eye is low risk, and “the risks expand” when it “operates 24/7, without human oversight”. Its sixth essential practice, maintain human control, asks for the ability to intervene and a defined way to decommission. For Odoo 20 that translates to: know which scheduled action to deactivate, and who is allowed to.

How do you audit an unattended agent and switch it off?

Odoo 20 gives you more to audit than 19 did. The release notes say you can “check automation chats to see how agents handled them, and ask for changes based on the errors it faced”, and conversations are stored for 30 days after the last message. Thirty days is short for an audit trail, so the tools should also write their decision to the record’s chatter, which persists with the record. Add the log() entries and you have three layers: the chat for the reasoning, the chatter for the outcome, ir.logging for the timing.

Switching off is a scheduled action’s Active checkbox or an automation rule’s toggle, and the person who owns that switch should be named in your AI agent register before the agent runs for the first time. Budget the credits too: because every AI feature draws IAP credits, an overnight rule that fires on a large recordset can spend a month’s allowance in a night, and our running costs guide covers how to cap that. And keep the provider choice open: Odoo 20 documents ChatGPT and Gemini as providers, with your own keys required on Odoo.sh and on-premise, per the AI API keys documentation, so which model handles your customer notes is a decision, not a default.

Finally, the sandbox. Every unattended agent we build runs first in a staging database against copied records, with a person reading every automation chat for two weeks. Only then does it move to production, and it moves with the same tool list, not a bigger one.

Goes well with

• The approval gate is in the code: Odoo AI server actions: the worker-tool patterns this post relies on, with Python examples.
• What an AI agent costs to run: the question that follows “it runs every night”: what it costs every night.
• The AI agent register: who owns the switch, and the 10 December 2026 privacy date that makes the register worth keeping.

Planning to let Odoo 20 agents run overnight?

Auboros designs and runs gated AI agents on Odoo from Brisbane, working with businesses across Queensland and beyond, and we’d rather help you decide what the agent may never touch before it runs than after. If you’re moving to Odoo 20 and want a second pair of eyes on the tool list, book a free consultation and we’ll go through it together, with no obligation either way. Our Odoo partner in Brisbane page covers the rest of what we do on the platform.