Coding agents are good at using computers. Should business software meet them on the command line?

[u/Super-Dingo-6906]

Something I keep coming back to after months of using Claude Code and Codex daily, and I'm curious how others see it.

The difference between a chatbot and a coding agent isn't really the model. It's that the agent has hands. ChatGPT in a browser tells you what to do; Claude Code or Codex does it, through the same commands we'd type: `cat` to read a file, `grep` to find something, `sed` or an edit tool to change it, run the tests, read the output, try again. Text in, text out, so the agent can check its own work.

That made me look differently at business software. A lot of the effort in adopting an ERP goes into learning the UI: which menu, which filter, which button. That has little to do with being good at accounting or operations. If an agent can do the navigating, the human part shrinks to what actually needs a human: asking the right question, reading the data, and deciding.

The catch is that most business apps give agents bad hands. With Odoo, which I work with, the options are the web UI (built for eyes, not for agents) or the raw RPC API, where the agent has to know internal model and field names, those names change between major versions, and nothing stops a write.

So I've been experimenting with putting a command-line layer in between, built the way a coding agent likes its tools:
- operations named by business meaning, not by database model
- each operation checked against a stock Odoo, so "it ran" means "it did what Odoo itself would do"
- one structured JSON result, with an error code and a suggested fix the agent can act on
- reads by default; writes are opt-in; risky ones need a human confirmation each time
- a small Python library on top, for notebooks (pandas frames) and scheduled routines an agent summarises each morning; it calls the CLI rather than Odoo, so the same checks apply
- bulk configuration as plan/apply, Terraform style: you review the diff, and apply refuses if the plan changed since you looked

Two things I'm still unsure about, and would like opinions on:

1. Permissions. The agent acts with whatever account it's given, so access control falls back to the ERP's own user rights. Is that enough for a small business, or does an agent need its own narrower layer on top?

2. Who is this actually for? Developers get it immediately. But the people I'd most like to help are accountants and small-business owners who have never opened a terminal. Is "install an agent, then just talk to it" a realistic ask for them today, or is that still too far?

For full disclosure, I build this layer (odoo-cli, open source), but I'm more interested in whether the idea holds up than in pointing anyone to it.

[u/ach25]

Given that Odoo is open source and API enabled, why not just use agentic AI and enable them access via the API? What does this provide that is not already possible via prompt.md or MCP? Is it like prepackaged library of py files AI can use for Odoo?

1.) Yes permission wise I think under the user is good, maybe something to confirm a change will impact the system would be more impactful instead.

2.) Depends on the user, but if you do good installation instructions it make it near single click that will help.

[u/Super-Dingo-6906 → u/ach25]

Why not just give the agent the API? It will run, but running isn't the same as being right. To answer "who owes us money?" the agent has to pick the right model, the right state filter, skip cancelled and draft invoices, and get the sign of the amount right. Miss one and you still get a plausible number, no error, nothing to tell you it's wrong. And the model and field names it relies on shift between major versions.

Why not a prompt.md / skill.md? A markdown file is advice. The agent reads it, interprets it, and may follow it differently on each run. It can't guarantee anything, because it doesn't execute. The CLI does: each operation is fixed code that runs the same way every time, and it was checked against a stock Odoo to confirm it gives the same result Odoo itself shows. Errors come back with a stable code and a suggested fix the agent can act on. To be fair about the limits: "checked" means checked on a standard Odoo, so with custom modules you'd still want to verify. But you start from tested ground, not from the agent's best guess.

Why not MCP? MCP is the transport, not the tool, and odoo-cli speaks it too (odoo-cli mcp serve). It runs locally over stdio, so there's no server of mine in between: the agent talks to the binary on your machine, and the binary talks to your Odoo. The community Odoo MCP servers I've looked at mostly expose generic search_read/write, which is the raw API again. Here the tools are the checked operations, writes are off unless you turn them on, and risky ones (deletes, bank account changes and similar) ask a human every time.

Is it a library of .py files? No, it's a single Go binary, so any agent that can run a command can use it. There's a small Python library on top for notebooks and scheduled reports, but it calls the CLI, so the same checks apply.

On your points:

1. Agreed, and that's the direction I went. For bigger changes there's plan/apply, like Terraform: the agent writes the desired setup, plan shows exactly what would change, and apply refuses to run if the plan changed after you reviewed it. That "show me the impact first" step matters more to me than another permission layer.

2. Since the users are agents, installing is the easy part: you tell your agent "install odoo-cli and connect it to our Odoo" and it does. The one thing you shouldn't do is paste your Odoo password into the chat, so the CLI has you enter it yourself, outside the conversation, into the machine's keychain. The real hurdle for an accountant is getting a coding agent in the first place, and I agree that part isn't one click yet.

One honest caveat on data: odoo-cli adds no middleman between the agent and Odoo, but whatever the agent reads still goes to the model provider (Anthropic, OpenAI…) for processing. If that's not acceptable for a given business, the answer is a local model, not a different tool.

[u/ach25 → u/Super-Dingo-6906]

OK yes I see now, there are a lot of fine points available that need to be navigated with just the who owes us money, good example.

Question back for you, yes we need to filter out canceled ands other varies states, how does the agent know which reference in the go binary to use based on the user’s input?

[u/Super-Dingo-6906 → u/ach25]

Good question. Three layers:

1. It finds operations by business name, not by model. Operations are named like finance.invoice.list or sales.quotation.list. The agent searches them (odoo-cli catalog list --domain finance, or odoo_find over MCP) instead of digging through hundreds of Odoo models and thousands of fields.

2. It reads a short contract before acting. odoo-cli <command> --help --output json and catalog describe tell it what an operation does, what it takes and how risky it is. A few lines of help instead of reverse-engineering the API.

3. For the common questions, the logic is already fixed. "Who owes us money" is check O15 in odoo-cli review: posted customer invoices with an amount still due past their due date at a given day, grouped by customer, bucketed 30/60/90 days. The agent doesn't build that filter; it runs the check. Scheduled routines have the same kind of ready-made "overdue invoices" template.

To be honest about the gap: for a free-form question with no ready-made check, the agent still adds its own filters. finance.invoice.list fixes what counts as an invoice (no stray journal entries), but it doesn't drop drafts or cancelled ones by itself. So the agent can still get a filter wrong there, just from a much smaller and better-described surface than the raw API.

And that's really why it's code and not a prompt. I want the agent to work from a formula, not to reason its way to an answer from scratch each time. When "overdue" is a written rule (posted, amount still due, past the due date, as of a given day), anyone can read it, argue with it, and fix it. When it lives in the agent's head, nobody can.

The review checks are built the same way: each finding carries its formula and thresholds, so you can see why something was flagged and tune it. Several of them came from collecting how people describe real problems on forums and in published cases: duplicate bills, refunds after payment, overdue receivables nobody chased. It's small for now, about twenty checks. But each one that gets written down, tested against Odoo and corrected by someone who knows the domain better than I do is one less thing an agent has to guess.

So if you work with Odoo and have a case where the numbers are easy to get wrong, an issue describing it is the most useful contribution. That's how I'd like this to grow: slowly, one verified piece of business logic at a time.

[u/ach25 → u/Super-Dingo-6906]

That’s value added, mapping even common prompts like what’s owed is great it’s not a gimme as there are so many approaches to get an answer. Thanks for explaining and educating.

[u/Super-Dingo-6906 → u/ach25]

Thanks, and good questions, they made me explain it better than the post did. "Many approaches to one answer" is exactly the problem. If you run into a question where Odoo's numbers are easy to get wrong, I'd like to hear it.

[u/Wooden_Bed3645]

Yeah.. API and a MCP connector to odoo.. build your own 'tools' for the connector

[u/Super-Dingo-6906 → u/Wooden_Bed3645]

Same architecture, yes. The difference is whether the tools are right. Writing a connector that calls search_read takes an afternoon; knowing that "overdue receivables" returns the same number Odoo's own report shows, on both 19 and 20, is the part that takes the work. That's what's in here.

[u/codeagency]

I don't think a CLI/command line is the right tool for every user.

The most elegant solution is to stay inside Odoo and have a native option build in Odoo that can do everything without using external 3rd party tools. There are plenty of modules available already that enhance the whole AI experience significantly so every user has a chatbot inside Odoo with a set of permissions that is correct, with tools and it's permissions and with clear audit tracking so administrators can easy detect problems. As soon as you go external tools, it only becomes exponential more difficult to keep security high

[u/Super-Dingo-6906 → u/codeagency]

Fair point, and for a lot of users I agree: if your team lives in Odoo all day, an assistant inside Odoo is the better experience. I'm not trying to replace that. A few places where I see it differently, though.

The brain is the same; the difference is the harness. Most AI modules for Odoo call the same models over the API, Claude, GPT or Gemini. What differs is what sits around the model. A coding agent works in a loop: it runs something, reads the result, notices it's wrong and tries again, over many steps. It also works across more than one system: Odoo plus spreadsheets, files and email. An in-app chatbot usually answers one question, inside one app.

On security, I'd put it less absolutely. A module runs as Python inside the Odoo server. It can call sudo(), skip record rules and read anything, so a third-party AI module holds more power than an outside client does. odoo-cli goes through Odoo's API as a user, so it's bounded by that user's access rights, and every change shows up in Odoo's own tracking under that user. Admins still have one place to look. And either way, the data goes to whichever model provider you use.

No lock-in to one provider. The same tools work with Claude, Codex, Gemini or a local model. If you switch next year, the operations and checks stay the same. A chatbot module is usually tied to the provider its author picked.

Why the logic is code. The agent can be personal, but the rules it calls shouldn't be. When "overdue receivable" or "duplicate bill" is a written, tested formula, it stays when the person who knew it leaves. A new hire doesn't need to be as experienced as the last one to avoid the same mistakes; they can spend their attention on the new ones.

And it's not really meant for people to learn a CLI. The user talks to their agent in plain language, and the agent is the one using the command line. So it's for anyone who already works with a coding agent, accountants included, not only developers. For everyone else, an assistant inside Odoo may well be the right answer today.

[u/sakesun]

Odoo architecture need major revision for agentic use. With cli, every executions will be bogged down by registry loading. With mcp, every api call will consume workers. The rate of executions by agents for each human users will be much higher than human use.

[u/Super-Dingo-6906 → u/sakesun]

Good point on load, but the first part depends on which CLI you mean. Odoo's own command line (odoo-bin shell, server-side scripts) does load the registry on every run. odoo-cli doesn't: it's a separate Go binary that talks to a running Odoo over its RPC API, like the web client does. Each command is one or a few HTTP requests to a server whose registry is already loaded, so there's no startup cost on the Odoo side.
On workers you're right that every call takes one, but so does every request the web client makes, and a single page view fires several. An operation call is usually one read of the fields it needs. Where it helps, the grouping and sums are done by Odoo itself (--group-by, --aggregate), not by pulling every record across.
Where I agree: agents can make far more calls per person than a human clicking, especially for things like a month's review or scheduled checks. At that point it's a sizing question, how many workers and how often routines run, more than an architecture problem. I'd be curious whether you've seen it hit limits in practice.

[u/sakesun → u/Super-Dingo-6906]

For the web part, I realised that the architectural expectation was really changed while watching below OXP video. In v20, Odoo EE try to resolve this by storing AI invocation state in database table and get away from worker blocking with postcommit, iap, and callback hook. This is a painful workaround for the architecture that's already show its age.

https://www.youtube.com/watch?v=MuVtgrnca34&list=PLfjNFh9EHCPo&index=3

The rate of software being rewritten by AI is mind-boggling. Had this architectural deficiency not being addressed for too long, it will soon be more economical to use AI to port business logic to a more modern lightweight approach.

[u/Super-Dingo-6906 → u/sakesun]

Interesting, I haven't watched that talk yet, thanks for the link. If that's the approach in 20, it actually points to why I kept the agent outside Odoo: the slow part, the model thinking for seconds or minutes, happens on the agent's side, and Odoo only serves short reads and writes like any client. Nothing waits inside a worker for an LLM.
On porting business logic away from Odoo: maybe, over time. My bet is that the hard part isn't the framework but the rules: what "overdue" or "a duplicate bill" actually means. That's why I write them down as explicit formulas, tested so far on a simulated company with planted problems. They still read Odoo's own fields today, so moving platforms would mean rewiring the inputs, but the definitions are the part worth carrying over.