Wiring agentic AI into a business system (Odoo 20, in our case) looks from the outside like "adding a chatty assistant". Engineering-wise it is opening a channel through which automation gets to act with power — and the more power, the more precisely the boundaries need writing. Our agentic_ai engineering ended up as four layers — a core plus a sales bridge, an ERP tools bundle and an MCP bridge — each installed separately, each owning one stretch of the boundary. These five principles come out of the v2 design reviews; the full implementation document lives on the product site (linked at the end).
Principle 1: a tool is a business action, not a database channel
The most tempting design in a tool list — one universal "run any query" tool — is exactly the one to refuse. Every tool maps to a business action with clear semantics: "list unpaid orders for this customer", "create a follow-up task for this order".
Two reasons: permissions can be aligned (business actions have a natural permission owner; "any query" has none), and audit can be explained (the log says "which business object changed", not "some SQL ran"). The engineering counterpart is a trusted registry: tool execution never resolves arbitrary import paths — it takes pre-registered native handlers from an allow-list, and anything unregistered is refused (fail-closed).
Principle 2: permissions align on two levels — natural language is not a bypass
Whether a tool may run is the intersection of two layers:
- The operator's real permissions in Odoo (record rules, multi-company filters all in force);
- The agent's configured tool allow-list.
A natural-language entry point must never become a bypass around any permission — that is the floor for putting an agent into a business system. Any over-reach (even "saw data it should not") is a blocker, not a nice-to-improve.
Principle 3: guardrails in front of the plan, not only before execution
Safety checks run at two layers: filtering during planning + checks at execution.
- Planning-time filtering is the experience layer: tools the operator cannot use, actions unavailable in context — removed while the plan is formed, so users never watch the agent walk into dead ends;
- Execution-time checks are the backstop: the full check chain still runs before every call, preventing bypasses.
Both layers carry rate and cost limits: estimates at the plan layer, deductions at the execution layer.
Principle 4: tier write confirmations by blast radius
"Confirm everything" trains users to click through blindly; "confirm nothing" is an incident in waiting. Tier by impact:
| Risk tier | Examples | Confirmation |
|---|---|---|
| Low | Drafts, internal tasks | Automatic, undo available |
| Medium | Field edits, status moves | Batched confirmation |
| High | Over-threshold amounts, deletions, external sends | Item by item, with before/after |
The tiers themselves are configuration — the confirmation flow is the enterprise's policy made executable, not a hard-coded product behaviour. And every step lands in an immutable audit log: who started it, what was read, what was done, who approved — fully reconstructable afterwards.
Principle 5: honest acceptance — demos do not sign off
An agent is easiest to fool with one beautiful demo. Our acceptance runs in graded task suites:
- Read-only Q&A → single write → multi-step cross-module, each level passed before the next;
- Metrics include an over-reach rate that must be zero, confirmation-trigger accuracy and traceability;
- The suite deliberately contains "should refuse / hand to a human" cases — when the agent is unsure, the correct behaviour is to stop and ask, not to guess; passing those counts as passing.
This is not theory: the product-side agentic_ai module currently holds 13 test files and 133 cases, with the security and confirmation paths taking the largest share — the shape of the test suite is the engineering stance made visible.
In closing
Not one of these five principles is "AI technology" — all of them are engineering boundaries. Which may be the truest picture of agentic AI in practice: model capability sets the ceiling; engineering boundaries decide whether it ships.
We condensed the whole design spec into a full implementation document on Odoo 20 — “Agentic AI for Odoo 20: design and implementation document (v2)”, covering architecture, the tool system, guardrails and acceptance — published on the product site's blog (see the related-articles link below).