A procurement manager we spoke to last year described her job as "being a very slow API between six systems." She read a number off one dashboard, typed it into another, waited for an approval email, then typed it somewhere else. Nobody designed that job. It accumulated.
That description is the reason the AI agents vs SaaS argument has teeth. The interesting question was never whether agents can write text. It is whether the software you rent by the seat still needs a human sitting in the middle of it.
What actually separates an agent from a feature
Almost every SaaS vendor now ships something labelled AI. Most of it is a feature: summarise this thread, draft this reply, suggest this next step. Useful, but it waits to be invoked and it hands the result back to you.
An agent is defined by what happens after the suggestion. It takes a goal, decides the sequence of steps itself, calls tools to carry them out, checks whether the result matched the goal, and tries again when it did not. The loop closes without you.
That distinction sounds academic until you look at where the money goes. You are not really paying your SaaS vendor for the database — storage is nearly free. You are paying for the interface: the forms, the workflows, the permissions, the reports, all the scaffolding that lets a human operate the data safely.
If an agent operates the data instead, a large share of that scaffolding becomes optional.
Fig. — The interface layer is what you rent. Agents change who uses it.
The prediction that keeps not happening
Every few years someone announces the end of business software. Low-code was going to do it. Then chatbots. Neither did, and the reasons are worth remembering, because they still apply.
Software is not mostly features. It is mostly accumulated decisions about edge cases — the tax rule for one province, the approval threshold that changes at quarter end, the customer who insists on a different invoice format. A vendor spent a decade encoding those. An agent starting from a blank prompt has not.
Compliance is the other anchor. Regulated industries do not just need the right answer; they need a defensible record of how the answer was reached, produced by a system somebody certified. "The model decided" is not an audit trail.
And data lives inside these systems. Salesforce is valuable partly because leaving it is painful. That is not an accident of design.
So what does change
The honest answer is that agents are eating the interface, not the system.
Watch where seat counts fall first. Roles that exist mainly to move structured data between systems — order entry, first-line ticket triage, expense coding, CRM hygiene — are the ones where an agent genuinely does the whole job rather than assisting with it. Vendors know this, which is why several have already shifted from per-seat toward consumption pricing. When the software works without a human logged in, charging per human stops making sense.
The second shift is quieter and more consequential. If agents are the primary users, the API becomes the product and the UI becomes a review surface. Vendors that treated their API as a grudging afterthought are suddenly exposed, because an agent cannot click through a screen that has no programmatic equivalent.
Third, integration stops being plumbing and becomes the actual differentiator. An agent that can only reach one system is a chatbot with extra steps. Its value scales with how many tools it can call, which means the moat moves toward whoever holds the connections.
The integration problem nobody has solved
Here is where the vision meets a wall that has nothing to do with model quality.
An agent operating across your stack needs credentials for every system it touches, and those credentials have to be scoped to what it is allowed to do. Most enterprise software was built on the assumption that a credential belongs to a person who has a manager, a laptop, and a leaving date. Non-human identity — an agent with its own permissions, its own audit trail, and its own revocation path — is genuinely immature in most vendors' products.
The practical result is that early deployments run agents with a service account holding far more access than the task requires, because that is the only way to make them work. That is a security posture nobody would defend if asked directly, and it is currently very common.
The second wall is error handling across systems. When a human hits an unexpected state in one tool, they stop and ask someone. When an agent hits it halfway through a multi-system sequence, you can end up with a purchase order raised, an inventory record updated, and an approval that never fired — a partially completed transaction with no obvious owner. Distributed systems people have known this problem for thirty years. Most agent frameworks are rediscovering it.
Where this genuinely works today
Skip the demos and look at deployments that survived contact with production.
Customer support is furthest along, though not the way it is usually sold. The wins are not full autonomy — they are agents that resolve the top handful of repetitive ticket types end to end, including the refund or the address change, and route everything else to a person with the context already gathered.
Finance operations is the other one. Invoice matching, expense policy checks, and reconciliation are high-volume, rules-heavy, and boring, which is exactly the profile that suits an agent. The failure mode is also contained: a wrong entry is caught at review, not experienced by a customer.
Sales operations sits somewhere in between. Logging calls, updating records, and enriching contacts work well. Deciding what a deal is worth does not, and the teams that blur that line get burned.
Notice what these have in common. Bounded scope, reversible actions, and a human who can inspect the output before it matters. None of them are the fully autonomous digital employee in the keynote. They are narrow jobs with a clear definition of done, which is exactly why they survived past the pilot. The teams reporting the biggest disappointments almost always started somewhere open-ended — "handle our operations" rather than "clear this specific queue" — and concluded the technology was not ready, when the brief was the problem.
What to actually do about it
If you buy software, the near-term question is not whether to replace your stack. It is whether your vendors have an API you could point an agent at, and whether your contract prices seats you may not need in two years. Both are worth raising at renewal, and both are unusual questions to hear from a customer, which is precisely why they get attention.
If you build software, the pressure lands somewhere less comfortable. A product whose value is the convenience of its interface is in a weaker position than it was. A product whose value is proprietary data, a hard-won integration network, or genuine domain logic is in a stronger one. Being honest about which you are is more useful than shipping an assistant into the sidebar.
There is a third group worth naming: the teams who will spend 2026 building internal agents on top of software they already pay for. That is where most of the real value lands this year, and it needs no vendor to change anything. The prerequisite is unglamorous — clean master data, documented APIs, and someone willing to own what the agent is permitted to do.
The stack is not going away. The assumption that a person sits in front of it all day is the part that no longer holds — and most software was designed entirely around that assumption.
