Start with what already works

Before reaching for an agent, know what your system already does.

Odoo has automated actions, scheduled jobs, approval thresholds, follow-up levels and reordering rules. A workflow tool handles multi-step logic across systems.

Both are predictable. You know exactly what will happen.

An agent is the right answer when the steps cannot be written in advance — because they depend on what is found along the way.

That is a narrower set of situations than the marketing suggests, and being clear about it saves money.

Where an agent genuinely fits

Three characteristics. A task needs all three.

The path varies by case. Not “do these five steps” but “find out what is going on, then decide what to do”.

It needs several sources. Gathering from three or four places, where what you find in one determines where you look next.

The output is preparation, not commitment. A draft, a list, a summary — something a person acts on.

If a task has fixed steps, use a workflow. Cheaper, predictable, and far easier to debug.

Four realistic uses

Collections preparation

The agent reviews overdue invoices, checks each customer’s payment history, notes open disputes or credit notes, and drafts appropriately different messages — firmer for a repeat late payer, softer for a good customer with one late invoice.

A person reviews the drafts and sends.

Why it fits: the right message depends on what the history shows, which you cannot decide in advance.

Support triage

The agent reads a new ticket, gathers the customer’s orders, previous tickets and delivery status, and produces a summary with a suggested category and route.

A person picks it up with the context already assembled.

Why it fits: what is relevant depends on what the ticket says.

Month-end preparation

The agent runs the standard checks — unbilled deliveries, unmatched receipts, unusual balances — investigates what it finds, and assembles an exception list.

A person works the list.

Why it fits: each exception needs a different follow-up depending on what it is.

Supplier or customer research

The agent gathers everything known about a party before a meeting or a decision — orders, payments, disputes, delivery performance — from several places.

Why it fits: it is gathering, which is most of the time and none of the judgement.

The pattern in all four

Gather, investigate, prepare, stop.

The agent does the collecting and the assembling. A person does the deciding.

That split is not a compromise while the technology matures. For anything with consequences it is the correct design, because accountability does not transfer to software.

Giving it tools

An agent is only as capable as the tools it has, and this is where most of the design effort goes.

Read tools are low risk. Search records, fetch a customer, list overdue invoices.

Write tools are where care is needed. Create a draft, update a field, send a message.

Three rules:

Give read access broadly, write access narrowly. Most useful agents need to see a lot and change very little.

Prefer draft-creating tools over committing ones. A tool that creates a draft quotation is safe. One that confirms an order is not.

Name and describe tools precisely. An agent chooses tools from their descriptions. A vague description produces wrong choices.

Permissions

An agent runs as a user, and inherits whatever that user can do.

Which means:

Create a dedicated account, not a person’s login.

Give it the minimum. If it never needs to delete, it should not be able to.

Assume it will do anything it can do. Not maliciously — through a misjudged step. Permissions are the real control, not instructions.

And note: an agent cannot be reliably instructed out of a capability. If you do not want something to happen, remove the ability rather than asking it not to.

Logging

Non-negotiable, and more important than for a single-step AI feature.

Log every step: what the agent decided, which tool it called, what came back, what it did next.

Why: when the outcome is wrong, the question is where it went wrong. Without the trail, an agent is a black box that produced something odd.

And for anything an auditor might examine, that trail is what lets you explain how a result was reached.

The stop button

An agent working through two hundred records needs to be stoppable immediately.

Three things to have:

A way to halt it mid-run.

A limit on how many steps it can take, so a loop terminates.

A limit on how many records it processes in one run, so a mistake is contained.

Test all three before you rely on it. A stop mechanism nobody has used is a mechanism that has never worked.

Where not to use one

Anything that posts to the ledger.

Anything sent to a customer unread.

Anything with a fixed procedure — use a workflow.

Anything you cannot log and explain.

Anything where nobody will review the output. An agent producing drafts nobody reads is worse than no agent, because the drafts get used anyway.

Starting sensibly

1. Pick a gathering task. Something where collecting is most of the work.
2. Give it read tools only, at first.
3. Have it produce a summary a person reads.
4. Run it alongside the manual process for a few weeks.
5. Add draft-creating tools once you trust the gathering.
6. Keep the commit with a person.

Do not start with a task that writes. Start with one that reads and reports — you learn how it behaves with nothing at stake.

The short version

An agent fits where the path depends on what is found — investigation-shaped work, across several sources.

Everything with fixed steps should be a workflow instead. Cheaper and predictable.

Read broadly, write narrowly, log everything, and stop before the commit.

And control it with permissions rather than instructions. If you do not want something to happen, remove the ability.