Sandbox-First AI Agents: How to Test an Agent on Odoo 20 and MYOB Acumatica Before It Touches Production

Sandbox-first means an AI agent earns production access by running against a copy of your ERP data first. On Odoo 20 that copy is a neutralised duplicate or an Odoo.sh staging branch; on MYOB Acumatica it is a test tenant. Both switch off emails and schedules, and as at 19 October 2026 a neutralised Odoo copy also disables the in-app purchase tokens Odoo’s own AI features run on.

At a glance

• Who it is for: owners, CFOs and ops managers of Australian businesses on Odoo 20 or MYOB Acumatica who have an agent in mind (order drafting, reconciliation exceptions, credit control, service triage) and want to know what “test it first” involves before they sign anything.
• Problem it solves: “we tested it” usually means someone ran ten prompts against production. A real sandbox test tells you how often the agent is right, what it reads, and what it would have changed, before any of that is irreversible.
• Platforms: Odoo 20 Enterprise on Odoo Online (duplicate database in testing mode), Odoo.sh (staging branch) or your own server (a neutralised copy), and MYOB Acumatica (a tenant with Test status, or a copied active tenant).
• What the sandbox switches off: in Odoo, outgoing mail, scheduled actions, bank synchronisation, payment providers, delivery carriers, in-app purchase tokens and search-engine visibility; in a MYOB Acumatica test tenant, all automation schedules, with the Suspend Email Processing option disabled in MYOB’s words and every email and report marked as coming from a test company.
• What you can test there: what the agent reads, what it drafts, how its drafts compare with what a person did on the same records, and whether the approval gate and audit trail behave; on Odoo 20, the MCP server, API keys and permissions behave as they will in production.
• What you cannot test there: anything that depends on a disabled service: real emails, live bank feeds, scheduled runs firing on their own, and Odoo’s own AI features drawing on credits unless you deal with the disabled token first.
• Promotion gate: a person compares the agent’s drafts with the human-made records for the same period, the owner named in the agent register signs off, and the agent goes live drafts-first, still behind an approval gate.
• Audit trail: the sandbox results (sample size, match rate, misses, what the agent read) are kept with the agent’s register entry; the production agent keeps its own log from day one.
• Typical cycle time: two to six weeks in the sandbox for most agents; an Odoo Online duplicate expires after 15 days, so plan on rebuilding it at least once.
• What it never does: write to production during the test, send anything to a customer or supplier from the copy, or carry production API keys into production use without a review.
• Typical cost: the sandbox pilot is the first paid stage of our AI agents for ERP in Australia work, from $5,000 ex GST as at 19 October 2026; the copy itself costs nothing extra on Odoo Online or Odoo.sh, and MYOB’s documentation says test tenants do not count toward your licensed tenant limit.
• Typical timeline: discovery 1 to 2 weeks, sandbox pilot 2 to 6 weeks, drafts-first go-live 1 to 2 weeks, per the hub.
• Last verified: 19 October 2026 against the Odoo 20.0 documentation on neutralised databases, Odoo Online duplicates, Odoo.sh branches and the MCP server, the Odoo 20 community and Enterprise source, MYOB’s Support of Multiple Tenants and test environment help pages, and the National AI Centre’s Guidance for AI Adoption.

Every agent we have put into production started life against a copy. That is not caution for its own sake. An agent that reads purchase orders and drafts sales orders is going to be wrong sometimes, and the only way to know how often, and in which direction, is to run it over a few hundred real records where being wrong costs nothing. Our AI agent governance post lists sandbox-first as one of the four controls that make agents safe to run. This post is the detail: what a sandbox is on each platform, what it quietly switches off, and what you should be measuring while the agent is in there.

The National AI Centre’s Guidance for AI Adoption puts it in five words under its fifth essential practice: “Test before you deploy a system.” The ABS found about 12% of Australian businesses were using AI in 2024-25, released 25 June 2026, and most of the testing we hear about happened in a chat window, not against the business’s own records.

What does sandbox-first actually mean for an AI agent on an ERP?

Sandbox-first is a deployment rule: an AI agent gets no write access to production, and no production API key of its own, until it has run against a copy of real data and a person has compared its output with what the business actually did. The sandbox is the copy. The comparison is the test. The person signing off is the owner named in your agent register. Everything else in this post is about making those three things real on Odoo 20 and MYOB Acumatica.

Two things make an ERP sandbox different from testing a chatbot. First, the copy contains everything production does: customer records, supplier terms, margins, staff details, and on Odoo the API keys and OAuth clients that worked on production the moment before the copy was taken. The sandbox is as sensitive as the system it came from, and the Australian Privacy Principles apply to it in full. Second, an ERP copy has to be defanged. If a duplicate database kept sending invoice emails and syncing bank feeds, you would not have a sandbox, you would have two production systems. Both platforms do this defanging for you, and the details of how are what trip up agent tests.

What does a neutralised Odoo 20 copy switch off?

Odoo’s word for a defanged copy is a neutralised database. The Odoo 20.0 documentation describes it as a non-production copy with certain functions turned off so you can test without triggering automated processes that could affect live data, and lists what is deactivated: scheduled actions, outgoing emails, bank synchronisation, payment providers, delivery methods, in-app purchase (IAP) tokens and website visibility to search engines. A red banner at the top of every screen tells you where you are. Testing backups, Odoo Online duplicates and Odoo.sh staging and development databases are all neutralised.

How you get one depends on hosting. On Odoo Online, the database manager has a Duplicate action with a “For testing purposes” option that is on by default; duplicates expire after 15 days and you can hold at most five per database. On Odoo.sh, a staging branch is a neutralised copy of production in which scheduled actions are disabled but can be triggered by hand or re-enabled, outgoing mail is caught by a mail catcher you can read in the project’s Mails tab, IAP services are disabled, and the database is deleted after one month. On your own server, the command line has a neutralize command and a —neutralize flag on database duplicate and restore. Our Odoo hosting guide covers which of the three you are likely on.

We read what neutralisation does in the Odoo 20 community source, because the documentation’s list is a summary and the detail decides your test plan.

• Scheduled actions. The base neutralisation script in the Odoo 20 source (neutralize.sql) deactivates every scheduled action except the autovacuum. So an agent you have wired to a scheduled action, the pattern in our Odoo 20 scheduled agents post, will never fire on its own in the copy. You run it by hand from the scheduled action’s form, or re-enable that one cron deliberately. That is fine for a test, as long as the test plan says so and nobody mistakes silence for success.
• Webhooks. The same script replaces the URL on every webhook-type server action with a disabled placeholder. If your agent hands off to an outside system through a webhook, that handoff is dead in the copy until you point it at a test endpoint.
• Mail. Mail servers are deactivated and their credentials dropped, and a dummy server is inserted so nothing falls through to a server configured on the command line. Drafts an agent writes into the chatter are fine; emails it would send go nowhere, which is what you want.
• In-app purchase tokens. The IAP module’s neutralisation script rewrites every IAP account token with a “+disabled” suffix, and the account model in the same module does the same to any new account created while the database carries the neutralised flag, with the comment “Disable new accounts on a neutralized database” in the source. Odoo 20’s own AI features run through an IAP service called Odoo AI and draw credits from it, as we set out in the Odoo 20 AI credits post. Put those two facts together and the consequence is plain: in a neutralised copy, Odoo’s built-in agents and Ask AI cannot reach the model as the copy stands. The documentation lists IAP among the disabled services; what it does not spell out is that the AI features sit behind it.

That last point changes how you test an Odoo 20 agent. If the agent is an outside one reading Odoo through the built-in MCP server, the sandbox is close to ideal: the model runs outside Odoo on your own key, the MCP server’s five default tools are read-only, and the API key carries one user’s permissions exactly as it will in production. This is the route we take when the agent is ours to build. If instead you are testing an Odoo-native agent built in the Agents app, with its skills and sources, you are testing its configuration, its permissions and what its tools would touch, but not its answers, until you either take the duplicate out of testing mode (which also re-enables emails and bank feeds, so do not), or ask Odoo support about credits in a test database, or test the native agent’s behaviour on a production database with a user that has no write access anywhere that matters. We prefer the third on Odoo Online and the MCP route whenever the agent is ours to build. One more wrinkle for self-hosted copies, from the Odoo 20 Enterprise source rather than the documentation: the AI request Odoo sends to its service carries a webhook URL built from the database’s own base URL, and the answer comes back to that URL, so a test copy on a server the internet cannot reach would not get its answers even with a working token.

One more thing the copy carries that nobody switches off: API keys. The neutralisation scripts we read do not touch user API keys, or the MCP OAuth clients the Odoo 20 Enterprise source stores, so a duplicate holds working copies of every production key, scoped to the duplicate’s URL. Revoke them in the copy on day one and issue sandbox-only keys with a one-month validity, which is the pattern our approved-tool list and permission review post describes. The 15-day expiry on an Odoo Online duplicate is a feature here: the sandbox and its keys disappear whether you remember or not.

What does a MYOB Acumatica test tenant restrict?

MYOB Acumatica’s unit of isolation is the tenant. MYOB’s Support of Multiple Tenants help page states that a tenant’s configuration and data are not accessible from other tenants of the same application, which is exactly the wall you want between a test and production. Test tenants, the ones with Test status, carry restrictions the page lists: only two concurrent users are allowed, a test tenant cannot be converted back to an active tenant, the Suspend Email Processing option on the Email Preferences form is disabled, all automation schedules on the Automation Schedules form are disabled, all emails and reports are marked as coming from a test company, a footer on every screen says so, and test tenants do not count toward the maximum number of allowed tenants in your licence.

Getting a copy of production into a tenant is documented step by step in MYOB’s test environment activity: create the empty tenant on the Tenants form (SM203520), put the system into maintenance mode on Apply Updates (SM203510), which the page says is needed to avoid data corruption while copying, use Copy Tenant on the source tenant, then stop maintenance and delete what you no longer need on Delete Snapshots and Tenants (SM503000). On MYOB’s hosting, how you get a test tenant and how often it can be refreshed depends on your agreement, so ask your partner what your subscription includes rather than assuming.

Three of those restrictions shape an agent test. The two-user limit means your agent’s integration user and one human tester are the whole population, so plan sessions rather than leaving a team logged in. Disabled automation schedules mean anything the agent relies on a schedule for, including the weekly processing that MYOB’s 2026 R1 release notes describe feeding the AI Assistant from exposed generic inquiries, would have to be run by hand on its processing form. And the test marking on emails and reports is your friend: if an agent draft somehow becomes an email, it leaves the tenant labelled as a test.

MYOB’s own AI sits inside the tenant and is licensed. The 2026 R1 notes say the AI Assistant must be enabled on the Enable/Disable Features form (CS100000) and is subject to licensing, answers only from generic inquiries an administrator has marked Expose to AI Assistant, and has its token usage tracked as AI Units on the License Maintenance form. The 2026.1.1 notes record that AI Studio was renamed AI Automation and moved out of Experimental Features into the Platform group. Whether those features are switched on in a particular test tenant is a licensing question for MYOB, not something we will state here. For an outside agent reading MYOB Acumatica through its REST API, the test tenant is clean: one integration user, a role that reads what the agent needs and nothing else, and MYOB’s AI page as the reference for what the platform already does natively so you are not building something MYOB ships.

“The sandbox stage is where the agent is allowed to be wrong in front of us. We put it on three weeks of real purchase orders and count: drafted right, drafted wrong, and didn’t know. The didn’t-knows are the useful ones. If it can’t tell when it’s unsure, it doesn’t go anywhere near production, however good the match rate looks.”

Josh Craig, Director, Auboros

What should you measure before an agent is allowed near production?

The point of the sandbox is a comparison, so decide what you are comparing before you start. For a drafting agent the test is replay: take the last four to eight weeks of real inputs that already exist in the copy, let the agent draft from each, and compare its draft with the record a person actually created at the time. Four numbers come out of that.

• Match rate. How many drafts a person would have approved unchanged. Count by line, not by document; an order with one wrong quantity is a wrong order.
• Miss rate, by direction. Wrong in which way? An agent that drafts too few lines is a nuisance; one that drafts extra lines or the wrong customer is a liability. Separate them.
• Abstention rate. How often the agent said it could not tell and left the record for a person. We treat this as the most important number of the four: an agent that never abstains is guessing.
• What it read. The log of records and fields the agent touched, compared with what you told staff it would read. Reading more than it needs is a privacy finding even when every draft was right, and the OAIC’s guide to securing personal information expects access to be limited to what the job requires.

Keep the sample honest. Fifteen hand-picked documents tell you nothing; a straight run of everything that arrived in the period, including the messy ones, tells you what Monday morning will look like. And write the numbers into the agent’s register entry alongside its risk register lines, because in six months someone will ask why this agent was trusted and “it seemed fine” is not an answer.

When is an agent allowed to graduate?

Picture a Brisbane industrial supplies wholesaler on Odoo 20, about 60 staff, who wants emailed PDF purchase orders drafted as sales orders, the pattern in our sales order agent post. The team duplicates the Odoo Online database in testing mode on a Monday. First job: revoke the copied API keys and OAuth clients in the duplicate and create one MCP-scope key, one month validity, on a sales user account that can read customers, products and pricelists and create nothing. The agent runs outside Odoo, reading through the MCP server, and writes its drafts to a spreadsheet, not to the copy, because the comparison is against the orders already in there.

Over three weeks the sales manager feeds it the 180 purchase orders that arrived in the previous six weeks, every one, including the handwritten faxes someone scanned. She compares each draft with the order her team keyed at the time. The duplicate expires on day 15, so they rebuild it once and re-issue the key, which turns out to be a useful rehearsal for key rotation in production. At the end she has four numbers, a list of the eleven customers whose order forms the agent cannot read, and a log showing it read nothing outside the three models it was given.

Graduation is a meeting, not a switch. The sales manager, as the agent’s named owner, signs the register entry with the numbers in it. The agent gets a production MCP key on a dedicated user with the same read scope and, now, one server action that creates draft sales orders, exposed to MCP with the Readonly Tool box left unticked so the client asks before every call, and nothing that confirms an order. For the first month every draft is approved by a person before it moves, and the eleven unreadable customers are routed straight to the team with a note. That is drafts-first go-live, and the sandbox is what earned it. Nothing in that story is a client result; it is the sequence we follow and recommend, and the numbers are the kind you should expect to produce, not ones we are claiming for anyone.

What goes wrong in sandbox tests?

The commonest failure is a false pass: twenty tidy documents looked wonderful, and production sent the other eighty percent. The straight-run sample above is the fix. The second is a false fail, where a scheduled agent “did nothing” because scheduled actions are neutralised and a week went by before anyone read the documentation. The third is the quiet one: production API keys riding along in a duplicate that nobody treats as sensitive because it has a red banner. The fourth is Odoo-native AI in a neutralised copy, declared broken when the disabled IAP token means the sandbox is working as designed. The fifth is the MYOB two-user limit, hit when a tester, the integration user and a curious manager all sign in at once.

The sixth is treating graduation as the end. The National AI Centre’s guidance pairs “Test before you deploy a system” with “Monitor your system after you deploy it”, and our hub’s pattern keeps weekly log reviews for the first quarter in production. The sandbox tells you how the agent behaves on last month’s data; only production tells you about next month’s, and the approval gate is what makes that safe to find out.

Goes well with

• Odoo 20’s built-in MCP server: who it runs as and how to keep writes behind a person: the keys, scopes and read-only tools the sandbox test above depends on, and how to set them for production.
• The AI agent register: where the sandbox numbers, the named owner and the graduation sign-off get recorded.
• What an AI agent costs to run: the model, key and credit costs the sandbox weeks let you measure before you commit to them.

Want the agent tested before it touches your ledger?

Auboros runs every agent build sandbox-first from Brisbane, against a neutralised Odoo 20 copy or a MYOB Acumatica test tenant, for businesses across Queensland and beyond. We’ll set up the copy, revoke the keys it carries, run the agent over your real records and show you the numbers before anything goes near production.

If you have an agent in mind and want to see how often it would have been right on last month’s work, book a free consultation. If the numbers say it isn’t ready, we’ll tell you that too.