AI Agents in 2026: What Changed in Business Software, and What Did Not
Where do AI agents genuinely work inside business software in 2026? The standardised connection layer, agent architecture, security boundaries and the.
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 public MCP servers were live.
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 most projects fail |
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 That Pay Off in the First Week
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 spends three minutes instead of thirty.
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 us build an assistant", but "let us 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 your best 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.
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 conversation usually clarifies two things: which task can be automated today, and which one is not ready yet.
Related reading: