Give a large language model a set of tools, a goal and a loop that lets it keep trying until the goal looks met, and you’ve built what the industry now calls an agent. The definition is almost disappointingly short. Everything interesting about agentic AI sits in the details: which tools, how much freedom inside the loop, and who notices when it wanders somewhere odd.
Demos haven’t helped. An agent that books a holiday on stage looks like magic, and the same agent faced with an expired card and a half-loaded airline page looks rather less clever. So it’s worth separating what agents do reliably in business software now from what still needs a person close by.
What agents are good at today
The dependable work is narrow, repetitive and checkable. Triage is the classic case. An agent reading inbound support emails, pulling the customer record, classifying the problem and routing it to the right queue with a draft reply attached is doing something a human can verify in seconds. If it gets it wrong, the cost is a misrouted ticket, not a lost customer.
Similar patterns work in finance and operations. Matching invoices to purchase orders, chasing missing fields in a supplier onboarding form, reconciling two exports that ought to agree: these tasks have clear rules, known data sources and an obvious definition of done. They’re also dull enough that nobody minds handing them over.
The plumbing has improved too. The Model Context Protocol, which Anthropic introduced in late 2024 and which Microsoft and other large vendors have since adopted, gives agents a consistent way to discover and call tools. Low-code builders such as Copilot Studio let business teams connect an agent to SharePoint, Dataverse or a REST API without writing much code. Getting an agent to act is no longer the hard part.
Where they break
Agents fail differently from ordinary software, and that’s what catches teams out. Ordinary code breaks loudly. An agent is more likely to carry on confidently with a slightly wrong idea, with each step building on the last, so a small misreading in step two becomes a perfectly plausible and perfectly wrong action by step nine. Long chains multiply the chances of this, which is why an agent with ten tools and an open-ended brief is far less dependable than one with three tools and a tight one.
Then there’s prompt injection, the problem that won’t go away. An agent that reads emails, web pages or documents is, in effect, taking instructions from its inputs. A line of hidden text in a supplier’s PDF telling the agent to forward the attachment elsewhere is an old trick with new consequences once that agent has permission to send email. Providers have made progress on resisting it, but nobody serious claims it’s solved.
Cost and speed can surprise people as well. An agent that calls a model a dozen times to finish one task is slower and pricier than a single request, and much harder to budget for. Agents also handle the common path nicely and wobble on the odd case, which is irritating, because odd cases are often why a human was involved in the first place. Designing around them is most of the real work, and it’s where the more experienced teams building agentic systems for business processes spend the bulk of their time.
Keeping them on a short lead
The organisations having the least drama with agents treat them less like chatbots and more like new starters with system access. That means giving each agent its own identity rather than letting it borrow a user’s, so its permissions can be limited and its actions traced. It also means scoping tools tightly: read access where reading is enough, and write access to the one table that needs changing rather than the whole database.
Human approval is the other lever, and it works best when it’s applied by consequence rather than by habit. Letting an agent draft a refund is fine. Letting it issue one above a set amount without sign-off should be a deliberate choice. Every action should be logged in enough detail to reconstruct what the agent saw, what it decided and why, which doubles as the best debugging tool you’ll have.
Evaluation matters more than most teams expect. Before an agent goes live, run it against a set of real past cases, including the awkward ones, and rerun that set whenever the model, the prompt or a tool changes. Models get updated underneath you, and an agent that behaved well in March can drift by June without a line of your own code changing.
The harder question is what happens when agents start dealing with each other across company boundaries, with your purchasing agent haggling with a supplier’s sales agent, say. Inside one organisation you can at least control identity, permissions and logs. Between two, there’s no settled way yet for an agent to prove who it acts for, or to decide who carries the loss when a pair of them strike a bad deal at three in the morning.