A few months ago, renewing a SaaS subscription was almost a formality. You'd check the price, compare it to the previous year, and unless the increase was too aggressive, approve it without much discussion. That's changing. In several companies we've talked to recently, the renewal conversation is no longer just about price: it's about whether that subscription is still necessary when an agent, properly configured, can do a good part of the same job.
This phenomenon has started to be called "agentic arbitrage": the possibility of replacing a tool that was paid for monthly with an agent that runs the same task at a much lower marginal cost. It makes sense that this is happening. Many software subscriptions solve relatively simple processes (generating a report, moving data between two systems, sending a notification with some logic behind it), and that's exactly the kind of work where an agent performs well. The mistake would be thinking this turns the decision into a simple "building always wins." That's not the case, and treating it as a general rule is where the problems start.
The first thing worth clarifying is that not every SaaS is a candidate for replacement. There's a real difference between a tool that solves a bounded, well-understood process, and one that also brings integrations, regulatory compliance, constant updates, and support behind it. Replacing the first with an agent can be a good business decision. Replacing the second with something built in a hurry usually gets expensive down the road, even if it doesn't show in the first month. The practical criterion shouldn't be "can I build it?", since the answer is almost always yes, but rather "who's going to maintain, update, and secure it once the person who built it has moved on to something else?"
The problem that isn't being discussed enough
That's where a phenomenon we're seeing more often with clients comes in, and one that still doesn't get enough attention in AI adoption conversations. Programming with an agent's help is now so easy that, inside many organizations, almost anyone has become a developer without setting out to be one. We're not talking about a software engineer building an internal tool with real architectural criteria. We're talking about someone from a business area who, with access to Claude or a similar assistant, built a site in Node, with its own database, running on their personal computer, and at some point that process ended up becoming part of the team's actual workflow.
This is different from the shadow AI usually discussed. It isn't an unauthorized tool: IT granted the license, in good faith and trying to encourage adoption. The problem isn't the permission itself, it's what got built with that permission and the lack of visibility into it. An AI assistant running in a browser is relatively easy to govern. An application with its own database, running outside any managed environment, without backups, without formal access control, and without security or IT knowing it exists, is a risk of a different nature. If that application stores customer data, financial information, or any sensitive data, the company has a real exposure that no one consciously decided to take on.
The risk doesn't end with security. It's also a problem of continuity and compliance. If that person changes roles or leaves the company, that process is left orphaned, undocumented, with no one who understands how it holds together. In regulated industries, these kinds of informal tools also tend not to meet the same standards the company demands from its software vendors, simply because they never went through that filter.
Thinking it through with criteria
The conclusion isn't that people should be banned from building anything, nor that every subscription should stay exactly as it is out of fear of the risks. Both extreme positions are comfortable, and both are wrong. There are subscriptions worth replacing, because the process is simple, the volume is low, and an agent solves it better and cheaper. There are others worth keeping, precisely because the complexity, compliance requirements, or integration with other systems make building it internally more expensive than it looks at first glance.
What does need immediate attention is the disorder that can build up along the way: entire teams starting to build software on their own, each with their own criteria, with no minimum level of governance over where that application lives, what data it touches, and who's responsible for maintaining it. The same ease that allows a company to seriously evaluate whether replacing a SaaS makes sense is, without direction, the same thing that can fill an organization with homegrown applications no one audits. The question every company should be asking isn't just which subscriptions are worth replacing with an agent, but who has visibility into everything that's already being built in-house.
