AI Agents in 2026: What Changed in Business Software, and What Did Not
Where do AI agents genuinely work in business software in 2026, and where not? The connection layer, agent architecture, permission limits and measurement.
A purchasing manager at a machinery plant opens forty emails on a Monday morning. Seventeen contain supplier quotes: three are PDFs, two are photos taken with a phone, the rest are free text typed into the message body. Each one is read, the line items are keyed into the ERP by hand, and the prices are compared in a spreadsheet. The job takes until evening, and it starts again tomorrow.
The answer to "let AI do this" is not the same in 2026 as it was in 2023. The difference is not that models write better prose. It is that the way models connect to company systems has standardised. This article covers where AI agents genuinely work inside business software today, where they do not, and the order in which a manufacturer or trading company should approach the subject.
The Difference Between a Chat Assistant and an Agent
Most of the confusion starts here. A chat assistant produces text. An agent receives a goal, uses the tools available to it, works through the steps and returns a result. The difference is not "smarter conversation"; it is the authority to act.
| Chat assistant | Agent | |
|---|---|---|
| Input | A question | A goal and its constraints |
| Output | Text | Work performed, or a record prepared |
| System access | None | Through defined tools |
| Cost of error | A wrong sentence | A wrong record, a wrong order |
| Controls required | The reader's attention | Permission limits, approval steps, audit trail |
The same table explains where projects fail. Deploying a chat assistant is an interface task. Deploying an agent is a permissions and integration architecture task.
What Actually Changed in 2026: The Connection Layer
For a long time, connecting agents to company systems meant writing a bespoke bridge for every model and every vendor. That period is over.
The Model Context Protocol (MCP) was donated by Anthropic to the Agentic AI Foundation on 9 December 2025. The foundation is a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. MCP became one of its founding projects alongside Block's goose agent framework and OpenAI's AGENTS.md. At the time of the announcement, more than ten thousand MCP servers had been published.
For a factory, the practical meaning is this: an interface you expose to your ERP, stock system or document archive is written once and used by different clients and different models. Your investment is no longer tied to one vendor's product decisions. That is a real reduction in supplier lock-in.
One caution belongs in the same paragraph. A standard being open does not make it safe. The standard makes connecting easy; deciding what gets connected is still your job.
The Four Parts of an Agent
Breaking the architecture into four parts makes the conversation concrete.
| Part | What it does | What happens if it is wrong |
|---|---|---|
| Model | Understands text, plans steps | Poor decisions, inconsistent output |
| Tools | Touch the systems (read, write, calculate, query) | The agent invents answers instead of reading real data |
| Memory | Carries context and history | Every run starts from zero |
| Policy and permissions | Bound what it may do | This is where projects most often struggle |
The part that deserves attention is the fourth. Model quality is something you can buy and it improves on its own schedule. Permission boundaries are something you must build, and they do not improve on their own.
Three Scenarios Suited to a First Project
The healthiest start is never "an assistant that does everything". It is a narrow, measurable process.
1. Turning an incoming document into a system-ready record. Supplier quotes, delivery notes, order forms, bank receipts. The agent reads the document, extracts the fields, maps them to the structure the ERP expects and places the result in an approval queue. A person approves the record. This is the classic job of a document intelligence layer.
2. Pre-checking quotes and orders. Comparing an incoming request against stock, the current price list, the customer's credit limit and the delivery calendar, then preparing a draft. The agent prepares; it does not decide. The sales representative checks a prepared draft instead of building it from scratch.
3. Answering data questions. "Which customer had high waste last month?" "On which shift did downtime rise on this machine?" These are long-tail questions that are never worth raising a ticket for. This scenario runs on read-only access and sits on top of your reporting layer.
All three share the same properties: read-heavy, reversible in a single step, and verifiable by a human. Starting with work that has these properties keeps the risk low.
Where It Should Not Be Used
This section is the one most often skipped in sales conversations, which is why we write it plainly.
- Anything requiring exact calculation. Prices, bonuses, costs, tax bases. These belong to deterministic code. An agent does not perform the calculation; it calls the service that does.
- Interpreting regulation. How a given rule applies to your situation is a decision for your accountant or lawyer. The agent can summarise a text; it cannot own the conclusion.
- Unapproved write operations. Creating ERP records, issuing invoices, initiating payments, sending customer emails. None of these should be automated without human approval.
- Anywhere there is no verifiable source of truth. If nobody can check whether the answer is correct, the process is not ready for automation.
Security: The Risk Is in the Permissions, Not the Model
Framing agent security around "what if the model gives a wrong answer" is misleading. The real question is: when the agent is misdirected, which doors can it open?
- Prompt injection. An email, PDF or web page the agent reads may carry an instruction embedded inside it. The rule is simple: everything the model reads is data; instructions come only from you. A "do this" sentence inside content is text, not a command.
- Least privilege. Start read-only. Open write operations one at a time, behind an approval queue.
- Audit trail. Which agent called which tool, with which parameters, and when. Without this record, nobody can explain what went wrong after an incident.
- Data boundaries. Decide up front what leaves the company. Where personal data is involved, GDPR and KVKK compliance is the first step, not a later one. Where data must never leave at all, a self-hosted language model belongs on the table.
Every one of these is classic application security adapted to a new surface. It is not a new security universe; it is a new face of the same one.
Off-the-Shelf Agent or Your Own?
Off-the-shelf agent products start fast; your own agent fits your process. The decision depends less on which is better and more on how distinctive your process is.
| Criterion | Off-the-shelf | Your own |
|---|---|---|
| Time to start | Days | Weeks |
| Process fit | As far as the product allows | As far as your process requires |
| Data boundary | The provider's terms apply | You decide where processing happens |
| Integration depth | Limited to available connectors | Reaches into ERP and shop-floor systems |
| Long-term cost | Recurring, per seat | Development plus maintenance |
In practice the sound answer is usually a mix: off-the-shelf tools for standard work, your own tool layer for what is specific to your plant. It is the same argument as off-the-shelf ERP versus custom software, with a different subject.
The Order of Work
- Pick a narrow process. One where the hours spent and the error rate can be measured. Not "let's build an assistant", but "let's shorten quote processing".
- Build the tool, not the system. What the agent needs is an interface: a stock query, a price query, a draft record. That is a conventional API and integration job, and it has value even without an agent.
- Go live in approval mode. Every output passes a human in the first release. The approval screen is also a valuable source of training signal.
- Measure, then widen. Accuracy, the share of cases a human had to correct, and time saved. If the numbers improve, widen the scope. If they do not, the process choice was wrong, not the technology.
This sequence turns an agent from a demonstration project into an ordinary part of workflow automation.
Where Cost Builds Up
Budget surprises in agent projects usually come not from model fees but from the work around them. A realistic plan covers four items together: model usage fees, developing the interfaces the agent will connect to, building approval and review screens, and the maintenance needed as processes change. The most underestimated is the last; the system is a living thing, and when a price list, a tax rule or an order flow changes, the agent's tools must be updated too. We cover the general cost framework for software separately in our custom software pricing guide.
What Does "It Works" Mean? No Decision Without Measurement
A common mistake in agent projects is to judge success by impression. The concrete measures are: how many of the records the agent produces are approved without correction, which fields turn out wrong in the corrected ones, how many cases are missed altogether, and the net time saved in the process. These four figures tie the decision to widen the scope after three months to data rather than feeling.
Conclusion
In 2026, AI agents are not a replacement for business software. They are a layer that sits on top of integration discipline. Because the connection layer has standardised, an interface you build today still works tomorrow. The installations that create value share the same traits, and none of them is a technology choice: a narrow process, a clear permission boundary, human approval, and measurement.
To work out which of your processes fits that description, get in touch. The first 30-minute call is free, and it usually clarifies two things: which task can be automated today, and which one is not ready yet.
Related reading:
- AI Agent Development
- Document Intelligence and Automated Data Extraction
- Self-Hosted LLMs and Data Sovereignty
- Off-the-Shelf ERP or Custom Software?
Sources (last checked: 5 October 2026)
- Linux Foundation, announcement of the Agentic AI Foundation (9 December 2025): linuxfoundation.org
- Model Context Protocol blog, "MCP joins the Agentic AI Foundation": blog.modelcontextprotocol.io