Allodi
How it works

A human expert, AI agents, and a fence between them and your money.

This page explains exactly who does what when you open a ticket, what the agent is allowed to touch, and what you can see afterwards. If any of it is unclear, that is a bug in this page. Tell us.

The model

Odoo support work splits into two parts. There is the legwork: reading the ticket, finding the relevant model and view, checking the database, reading the module that overrides the standard behaviour, writing the patch, running the test. And there is the judgment: is this the right fix, will it affect something else, is this something the customer should be asked about first, is it safe to run against a live company's books.

The legwork is what makes support slow and expensive at most partners. It is also what AI coding agents are now very good at, when they have access to the actual system and a person who knows Odoo checking their work. So that is the split. An agent does the legwork. A human Odoo implementer with years of production experience does the judgment, and holds the only keys that can change anything that matters.

The expert stays. The waiting goes.

The approval flow

Every ticket, from a typo in a report to a stuck cron job, goes through the same five steps. Nothing skips step three.

Ticket to AI triage to human approval to change to log Five boxes in a row connected by arrows: 1 Ticket, 2 AI triage with dry run, 3 Human approval, 4 Change applied, 5 Logged in the portal. A dashed return arrow from human approval back to AI triage is labelled rejected, with notes. 1 TICKET You open it in the portal or by email 2 AI TRIAGE Reads code and data, drafts a fix, dry-runs it 3 HUMAN APPROVAL Expert reviews the diff and the dry-run output, approves or sends back 4 CHANGE Applied by the human, from a branch you can read 5 LOG Ticket shows what was looked at and changed rejected, with notes Ticket to AI triage to human approval to change to log Five boxes stacked vertically connected by arrows: 1 Ticket, 2 AI triage with dry run, 3 Human approval, 4 Change applied, 5 Logged in the portal. A dashed return arrow from human approval back to AI triage is labelled rejected, with notes. 1 TICKET You open it in the portal or by email 2 AI TRIAGE Reads code and data, drafts a fix, dry-runs it 3 HUMAN APPROVAL Expert reviews the diff and the dry-run output, approves or sends back rejected, with notes 4 CHANGE Applied by the human, from a branch you can read 5 LOG Ticket shows what was looked at and changed
Step 3 is the only step with production credentials. The agent can read; only a person can write.

  1. You open a ticket

    In the support portal or by emailing the support address. Say what is wrong in your own words. Screenshots help; Odoo jargon is not required.

  2. The agent triages it

    It reads the ticket, then inspects your Odoo read-only: the models involved, the views, any custom module that overrides them, recent changes, and the relevant records. It drafts a proposed change on a git branch and runs it against a copy of your database in dry-run mode, recording what would change. If the ticket is a question rather than a change, it drafts an answer with references. If the ticket touches anything on the fence list below, it stops and writes up what it found for the human.

  3. A human reviews and approves

    The expert reads the diff and the dry-run output, checks it against what he knows of your business and of Odoo, and either approves, amends, or sends it back to the agent with notes. If the change needs a decision from you (which of two behaviours you want, whether to touch historical records), he asks you in the ticket before anything moves.

  4. The change is applied

    By the human, from the reviewed branch, using a deployment script that is itself in your repository. Production credentials never leave that step. For data changes, the same dry-run is repeated against production before it is committed, and the before-and-after is written to the ticket.

  5. It is logged and you are told

    The ticket closes with a plain-language summary, a link to the commit, the dry-run output and the list of records or files touched. Changes are also noted in the record's own chatter inside Odoo, so someone looking at that invoice or product a year later sees what was done and why.

The fences

These are hard limits built into how the agent is connected to your system, not a policy it is asked to follow. The agent's credentials cannot do these things. Only a person's can.

  • MoneyNo posting, cancelling or editing of invoices, bills, payments, journal entries or bank reconciliations. The agent may read them to diagnose a problem and propose what a person should do.
  • TaxNo changes to tax rates, tax groups, fiscal positions, tax reports or anything connected to a tax filing service. These are changed by a person on your written instruction.
  • DeploymentsNo pushing to your main branch and no restarting or upgrading modules on production. The agent works on branches and on copies. A person deploys.
  • Outbound email and messagesNothing is sent from your Odoo to a customer, vendor or employee by the agent. Test runs are done with mail disabled, and we check the outbox afterwards to confirm nothing leaked. This rule exists because we have seen what happens without it.
  • External servicesNo calls to payment processors, shipping carriers, bank feeds or tax services during testing. Anything with a real-world side effect is switched to a logging mode that records what would have been sent.
  • Your data leaving your serverThe agent inspects your system in place. Database dumps are not uploaded to any AI service. What the agent sees to do its work is described in the privacy and data processing note.

The support portal

The portal is where you open tickets and where you see what happened to them. It is deliberately boring. For each ticket you see the request, the agent's write-up of what it looked at, the proposed change as a readable diff, the dry-run output, the human's decision and any notes, and the final summary with a link to the commit.

You also see the standing items for your system: the last successful backup and the last restore test, the current Odoo and module versions, open and recently closed tickets, hours used this month against your block, and the monthly operations summary.

Nothing on the portal is a marketing dashboard. If a number is on it, it is because you would want to check it.

The audit log

Every change to your system, whether code or data, is attributable: who asked for it, who proposed it, who approved it, when it ran, and what it touched. For code, that is a git commit with a human author and a ticket reference. For data, it is a note in the affected record's chatter inside Odoo plus the dry-run and result in the ticket.

This is not just for comfort. When something looks wrong in six months, the first question is always "what changed?" and the answer should take one search, not a week of archaeology.

You can export the whole log at any time. It is your record, not ours.

Plain facts about the agent

The agent makes mistakes. It has invented field names that do not exist and proposed fixes that would have worked on standard Odoo but not on a customized one. That is exactly why step three exists and why it is a person who has run Odoo in production, not a checklist.

Some tickets are not small. When a request turns out to be a real project, we say so and quote it rather than quietly burning your fix hours on it.

We use Claude models from Anthropic for the agent work, with the agent running on infrastructure we control. We say which model in the ticket log. If that changes, the log will say so.

Every change to your system has a named person behind it. That is the whole point of the model, and it is why you can trust the speed.

Want to see a real ticket?

Ask and we will walk you through an anonymized one, start to finish, including a rejected proposal.

Get in touch Back to services