Before reaching for an agent, know what your system already does.<\/strong><\/p>\n Odoo has automated actions, scheduled jobs, approval thresholds, follow-up levels and reordering rules. A workflow tool handles multi-step logic across systems.<\/p>\n Both are predictable.<\/strong> You know exactly what will happen.<\/p>\n An agent is the right answer when the steps cannot be written in advance<\/strong> \u2014 because they depend on what is found along the way.<\/p>\n That is a narrower set of situations than the marketing suggests<\/strong>, and being clear about it saves money.<\/p>\n Three characteristics. A task needs all three.<\/p>\n The path varies by case.<\/strong> Not “do these five steps” but “find out what is going on, then decide what to do”.<\/p>\n It needs several sources.<\/strong> Gathering from three or four places, where what you find in one determines where you look next.<\/p>\n The output is preparation, not commitment.<\/strong> A draft, a list, a summary \u2014 something a person acts on.<\/p>\n If a task has fixed steps, use a workflow.<\/strong> Cheaper, predictable, and far easier to debug.<\/p>\n FIGURE 1: WORKFLOW OR AGENT<\/p>\n Use a workflow<\/p>\n Use an agent<\/p>\n The agent<\/strong> reviews overdue invoices, checks each customer’s payment history, notes open disputes or credit notes, and drafts appropriately different messages \u2014 firmer for a repeat late payer, softer for a good customer with one late invoice.<\/p>\n A person<\/strong> reviews the drafts and sends.<\/p>\n Why it fits:<\/strong> the right message depends on what the history shows, which you cannot decide in advance.<\/p>\n The agent<\/strong> reads a new ticket, gathers the customer’s orders, previous tickets and delivery status, and produces a summary with a suggested category and route.<\/p>\n A person<\/strong> picks it up with the context already assembled.<\/p>\n Why it fits:<\/strong> what is relevant depends on what the ticket says.<\/p>\n The agent<\/strong> runs the standard checks \u2014 unbilled deliveries, unmatched receipts, unusual balances \u2014 investigates what it finds, and assembles an exception list.<\/p>\n A person<\/strong> works the list.<\/p>\n Why it fits:<\/strong> each exception needs a different follow-up depending on what it is.<\/p>\n The agent<\/strong> gathers everything known about a party before a meeting or a decision \u2014 orders, payments, disputes, delivery performance \u2014 from several places.<\/p>\n Why it fits:<\/strong> it is gathering, which is most of the time and none of the judgement.<\/p>\n Gather, investigate, prepare, stop.<\/strong><\/p>\n The agent does the collecting and the assembling.<\/strong> A person does the deciding.<\/p>\n That split is not a compromise while the technology matures.<\/strong> For anything with consequences it is the correct design, because accountability does not transfer to software.<\/p>\n FIGURE 2: THE DESIGN THAT WORKS<\/p>\n Gather from several places<\/p>\n Investigate what it finds<\/p>\n Prepare an output<\/p>\n Stop before committing<\/p>\n An agent is only as capable as the tools it has<\/strong>, and this is where most of the design effort goes.<\/p>\n Read tools are low risk.<\/strong> Search records, fetch a customer, list overdue invoices.<\/p>\n Write tools are where care is needed.<\/strong> Create a draft, update a field, send a message.<\/p>\n Three rules:<\/strong><\/p>\n Give read access broadly, write access narrowly.<\/strong> Most useful agents need to see a lot and change very little.<\/p>\n Prefer draft-creating tools over committing ones.<\/strong> A tool that creates a draft quotation is safe. One that confirms an order is not.<\/p>\n Name and describe tools precisely.<\/strong> An agent chooses tools from their descriptions. A vague description produces wrong choices.<\/p>\n An agent runs as a user, and inherits whatever that user can do.<\/strong><\/p>\n Which means:<\/strong><\/p>\n Create a dedicated account<\/strong>, not a person’s login.<\/p>\n Give it the minimum.<\/strong> If it never needs to delete, it should not be able to.<\/p>\n Assume it will do anything it can do.<\/strong> Not maliciously \u2014 through a misjudged step. Permissions are the real control<\/strong>, not instructions.<\/p>\n And note:<\/strong> 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.<\/p>\n FIGURE 3: SAFE AND UNSAFE SETUP<\/p>\n Safe<\/p>\n Unsafe<\/p>\n Non-negotiable, and more important than for a single-step AI feature.<\/strong><\/p>\n Log every step:<\/strong> what the agent decided, which tool it called, what came back, what it did next.<\/p>\n Why:<\/strong> when the outcome is wrong, the question is where<\/em> it went wrong. Without the trail, an agent is a black box that produced something odd.<\/p>\n And for anything an auditor might examine<\/strong>, that trail is what lets you explain how a result was reached.<\/p>\n An agent working through two hundred records needs to be stoppable immediately.<\/strong><\/p>\n Three things to have:<\/strong><\/p>\n A way to halt it mid-run.<\/strong><\/p>\n A limit on how many steps it can take<\/strong>, so a loop terminates.<\/p>\n A limit on how many records it processes in one run<\/strong>, so a mistake is contained.<\/p>\n Test all three before you rely on it.<\/strong> A stop mechanism nobody has used is a mechanism that has never worked.<\/p>\n Anything that posts to the ledger.<\/strong><\/p>\n Anything sent to a customer unread.<\/strong><\/p>\n Anything with a fixed procedure<\/strong> \u2014 use a workflow.<\/p>\n Anything you cannot log and explain.<\/strong><\/p>\n Anything where nobody will review the output.<\/strong> An agent producing drafts nobody reads is worse than no agent, because the drafts get used anyway.<\/p>\n Do not start with a task that writes.<\/strong> Start with one that reads and reports \u2014 you learn how it behaves with nothing at stake.<\/p>\n An agent fits where the path depends on what is found<\/strong> \u2014 investigation-shaped work, across several sources.<\/p>\n Everything with fixed steps should be a workflow instead.<\/strong> Cheaper and predictable.<\/p>\n Read broadly, write narrowly, log everything, and stop before the commit.<\/strong><\/p>\n And control it with permissions rather than instructions.<\/strong> If you do not want something to happen, remove the ability.<\/p>\n Work that is mostly gathering before somebody can decide?<\/p>\n Get in touch. That is where agents genuinely help \u2014 assembling the picture, with the decision staying with your team.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":3,"featured_media":9483,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-9482","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai"],"yoast_head":"\nWhere an agent genuinely fits<\/h2>\n
\n
\n
Four realistic uses<\/h2>\n
Collections preparation<\/h3>\n
Support triage<\/h3>\n
Month-end preparation<\/h3>\n
Supplier or customer research<\/h3>\n
The pattern in all four<\/h2>\n
\n
\n
\n
\n
Giving it tools<\/h2>\n
Permissions<\/h2>\n
\n
\n
Logging<\/h2>\n
The stop button<\/h2>\n
Where not to use one<\/h2>\n
Starting sensibly<\/h2>\n
\n
The short version<\/h2>\n