Most AI in a business system does one thing when asked.<\/strong><\/p>\n Read this document. Draft this email. Classify this ticket. One input, one output, done.<\/p>\n An agent is given a goal and works out the steps itself.<\/strong><\/p>\n “Chase the overdue invoices” rather than “send this reminder to this customer”.<\/p>\n To do that it has to:<\/strong> decide what to look at, decide what to do, do it, see what happened, and decide what next.<\/p>\n Multiple steps, with judgement between them.<\/strong> That is the whole distinction.<\/p>\n FIGURE 1: TASK OR GOAL<\/p>\n A normal AI step<\/p>\n An agent<\/p>\n Three things, and understanding them explains both the capability and the limits.<\/p>\n Tools.<\/strong> The agent can call things \u2014 search a database, read a record, send a message, create an entry. Without tools it can only produce text.<\/strong><\/p>\n A loop.<\/strong> It acts, observes the result, and decides again. That loop is what lets it recover from a step that did not work.<\/p>\n A stopping condition.<\/strong> It has to know when the goal is met, or when to give up. Getting this wrong produces an agent that loops indefinitely<\/strong>, which is a real failure mode rather than a theoretical one.<\/p>\n Four concrete examples.<\/p>\n Collections.<\/strong> Review overdue invoices, check each customer’s history and open disputes, draft appropriately different messages, and escalate the ones needing a person.<\/p>\n Purchasing.<\/strong> Notice low stock, check lead times and supplier reliability, prepare purchase orders, and flag those needing approval.<\/p>\n Support triage.<\/strong> Read incoming tickets, gather relevant context, resolve the routine ones, and route the rest with a summary.<\/p>\n Month-end preparation.<\/strong> Run the standard checks, chase missing documents, assemble the exceptions, and present a list.<\/p>\n Each of these is several steps a person currently does in sequence<\/strong> \u2014 and the gathering is usually most of the time.<\/p>\n Some of this works now. Much of it works in demonstrations and needs supervision in production.<\/strong><\/p>\n Working reasonably today:<\/strong> multi-step tasks within a narrow, well-defined boundary, with review before anything commits.<\/p>\n Emerging:<\/strong> longer chains where the agent chooses between genuinely different courses of action.<\/p>\n Not there:<\/strong> anything you would leave unsupervised where being wrong is expensive.<\/p>\n The gap is not intelligence. It is reliability on exceptions.<\/strong><\/p>\n An agent that handles ninety-five percent of cases well and does something odd on the rest is a problem in a system that touches money \u2014 because the five percent is where the money usually is.<\/strong><\/p>\n FIGURE 2: WHERE AGENTS STAND<\/p>\n Works now<\/p>\n Emerging<\/p>\n Not yet<\/p>\n The gap<\/p>\n Four reasons an agent in an ERP differs from one doing research.<\/p>\n Actions are hard to reverse.<\/strong> A posted journal entry needs a reversal. A sent message cannot be recalled. A confirmed order has reached a supplier.<\/p>\n Errors compound quietly.<\/strong> A wrong step produces a wrong record, which the next step treats as fact. By the time anyone notices, several things are wrong.<\/p>\n Explanation is genuinely difficult.<\/strong> When an agent takes fifteen steps and the outcome is wrong, tracing why is hard. In a system an auditor may examine, that matters.<\/p>\n Permissions are inherited wholesale.<\/strong> An agent with the ability to post entries can post wrong ones. There is no partial capability.<\/strong><\/p>\n Let the agent prepare. Stop before anything irreversible.<\/strong><\/p>\n Draft the emails and present them. Prepare the purchase orders as drafts. Assemble the exception list.<\/p>\n A person confirms.<\/strong><\/p>\n This captures most of the value.<\/strong> The steps that take the effort are the gathering, checking and preparing \u2014 not the final click.<\/p>\n And it removes most of the risk<\/strong>, because nothing external happens without review.<\/p>\n FIGURE 3: PREPARE OR COMMIT<\/p>\n Safe \u2014 prepare<\/p>\n Risky \u2014 commit<\/p>\n Six questions. Vague answers tell you something.<\/p>\n That last one matters more than it sounds.<\/strong> An agent working through two hundred records needs a stop that works immediately.<\/p>\n “Autonomous” as a selling point.<\/strong> In a business system, autonomy is a risk to manage, not a feature to maximise.<\/p>\n Demonstrations on clean data.<\/strong> Everything works on clean data. Ask what happens with a duplicate customer, a missing cost, a half-completed record.<\/p>\n Claims without a stop mechanism.<\/strong><\/p>\n Anything posting to your ledger unsupervised<\/strong>, whatever the accuracy figures.<\/p>\n Watch it properly.<\/strong> It is progressing quickly and the direction is real.<\/p>\n Use narrow, supervised versions now.<\/strong> Preparation and gathering, not commitment.<\/p>\n Do not restructure your processes around it yet.<\/strong> Build on what works today.<\/p>\n Keep your data clean.<\/strong> Everything that comes will work better on clean data and worse on bad data \u2014 and that work is worth doing regardless.<\/p>\n An agent is given a goal<\/strong> rather than a task, and works out its own steps.<\/p>\n That is a genuine advance<\/strong>, and in a business system the difficulty is not capability \u2014 it is reliability on the exceptions, and the fact that actions cost money and are hard to reverse.<\/p>\n Narrow the scope. Stop before the commit. Limit the permissions. Log everything.<\/strong><\/p>\n Used that way, agents are useful now. Used as the marketing describes them, they are a risk you will not notice until the exception arrives.<\/p>\n Hearing a lot about AI agents and unsure what is real?<\/p>\n Get in touch. We will look at which of your multi-step processes could be prepared automatically \u2014 and which should keep a person on the commit.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The difference from everything else Most AI in a business system does one thing when asked. Read this document. Draft this email. Classify this ticket. One input, one output, done. An agent is given a goal and works out the steps itself. “Chase the overdue invoices” rather than “send this reminder to this customer”. To […]<\/p>\n","protected":false},"author":3,"featured_media":9480,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-9479","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai"],"yoast_head":"\n\n
\n
What makes it possible<\/h2>\n
What it might do in a business<\/h2>\n
The honest state of it<\/h2>\n
\n
\n
\n
\n
Why business systems are harder<\/h2>\n
The boundary that makes them usable<\/h2>\n
\n
\n
What to ask a vendor<\/h2>\n
\n
What to be sceptical about<\/h2>\n
A realistic position<\/h2>\n
The short version<\/h2>\n