In 1830s Britain, starting a railway required more than steel and engines. A new line often needed its own Act of Parliament, granting the company power to acquire land and lay track. The distinctive asset was the right-of-way — the route and agreements that made it possible.
Software has rights-of-way too. Stripe connects to financial networks. Twilio connects to telecom carriers. Signing services connect an agreement on a screen to institutions outside it. Their value comes partly from code, but also from licenses, relationships, data, live rules, and responsibility when something goes wrong. Call this the rail.
Many SaaS products bundle the rail with something else: your process, rendered as forms, dashboards, permissions, approvals, and reminders. Call this the train. In that sense, a SaaS product is often two companies stapled together: a rail connecting you to something difficult outside your company, and a train selling seats to your employees.
Some products also encode a third asset: genuinely shared knowledge, such as how ledgers reconcile, inventory moves, or an industry handles obscure cases.
Agents are changing the economics of the train fastest. They lower the lifetime cost of software built around one company’s process, and they can operate software without occupying every human-facing seat. Agents will not end SaaS. They will unbundle it. Companies will keep renting external rails, keep buying mature shared systems, and own more of the processes that make them distinct.
The bargain that built SaaS
SaaS was less a kind of product than a kind of bargain: software is expensive to build and miserable to maintain, so let us build it once and rent it to everyone.
For most of the last twenty years, this was a good bargain. Internal software rarely failed at version one. The trouble arrived in year three, after the business changed, an engineer left, or a forgotten dependency developed a security flaw.
Buying SaaS traded fit for continuity. The product might only approximate how your company worked, but it kept working. The vendor spread engineering, security, support, and operations across thousands of customers.
The subscriptions accumulated. BetterCloud reported that the average company ran 106 SaaS applications by 2024. In Zylo’s 2025 dataset, SaaS spending averaged $4,830 per employee.
The bargain also spread the cost of breadth. Every customer bought roughly the same core product, though each needed a different slice: several currencies, intricate permissions, or an obscure accounting integration. Everyone helped fund the infrastructure and edge cases required to serve everyone else.
That was not a mistake. It was the price of avoiding a permanent software team, and it was cheaper than building and maintaining your own.
The question is whether buying still has enough of a cost advantage to remain the default.
What agents change
Agents change two parts of the calculation at once.
First, they reduce the cost of producing and adapting software. Under supervision, they can turn descriptions into code, inspect unfamiliar systems, write tests, trace failures, and implement changes.
Generated software still has dependencies, security boundaries, migrations, and failures. Someone owns the result. When a refund agent returns the wrong amount, the customer will not care whether a person or a model produced the mistake.
The stronger claim is also the more useful one: agents do not have to make custom software free. They only have to reduce its lifetime cost enough to reopen decisions that used to favor buying.
Second, agents are becoming software users. People need forms, dashboards, and carefully designed paths through a product. Agents can often work through APIs and events instead.
Screens will remain for setting policy, reviewing exceptions, and auditing decisions. But routine work may move underneath them, turning the interface into a control surface.
Seat pricing makes sense when each employee operates a product; less so when agents perform most operations and a few people supervise. Vendors may shift toward usage, outcomes, data, or network pricing.
The process between products
Imagine a distributor handling a damaged delivery.
A customer emails a photograph. A support representative copies the order number into a ticket, checks the ERP and CRM, consults a policy document, asks for approval in chat, creates a carrier label, issues a refund, and updates finance’s spreadsheet.
No one designed this as one process. Support sees a ticket; operations, an order; finance, a refund. Each team sees its part. The process itself lives between them.
An agent could run that invisible thread as one process. It could inspect the email and photograph, identify the order, apply company policy, route exceptions for approval, create the label, issue the refund, and record its reasoning.
The distributor would still rent important services. It would not build a payment network or negotiate with every carrier. It might keep the ERP because accounting and inventory contain a great deal of shared logic.
What the distributor could own is the composition: the policy, sequence, exceptions, tests, and history that define how this company handles a damaged delivery.
The distributor already pays for that process: it pays the people who understand it and bears the consequences when it fails. But it does not control the process as a whole. The knowledge is scattered through vendor workflows, rules, integrations, and employee memory.
This is the layer agents may bring home first.
What to rent and what to own
Keep renting external coordination. Payments, identity, signatures, telephony, tax filing, and logistics connect your company to outside networks and institutions. Their value lies in relationships, data, rules, and liability.
Keep buying genuinely shared knowledge. Accounting, inventory, compliance, and strong vertical software encode lessons accumulated across many customers.
Own more of the process that is particular to you. Approval rules, handoffs, exception policies, and end-to-end workflows are not generic merely because they live in generic products.
Specificity is not strategy. Remove historical accidents, standardize what should be common, and own what creates an advantage, changes often, or helps the company learn faster.
Agents shift the cost curve, not responsibility. Bring a process home only with tests, monitoring, access controls, and an accountable owner.
Ownership means controlling the policies, data, tests, and decision history — and being able to audit, change, and move them without reconstructing the business from screenshots and employee memory.
The choice is not “buy SaaS” or “build everything.” Rent the rails, buy shared knowledge, and own your process.
The real advantage is learning speed
An AI-first competitor may have fewer employees, a smaller software stack, and no established customer base. You have customers, data, relationships, and operating knowledge. But it can design its process around agents from day one; you must thread them through a CRM, ticketing system, and approval suite.
When it finds a better way to handle returns, it changes the process itself. You file a feature request, rewire integrations, renegotiate access, and retrain teams. The competitor begins another learning cycle before you finish the first.
That difference compounds. Faster changes create more experiments. More experiments deepen its understanding of the business. What it learns becomes software again. The AI-first company is not merely automating work. It is accelerating the rate at which it learns how to operate.
The competitor does not have to be smarter. It only needs fewer layers between a decision and its deployment. Your advantages lose value when you cannot act on what you know. The software stack you rented for efficiency can become the reason you cannot change.
More software, fewer destinations
The result will not be less software. Companies may produce more of it than ever — in smaller pieces, shaped around one company, and changed more often.
Much of it will never become a product because it is too specific to sell. It will sit above rented infrastructure, external rails, and systems of record, joining them into something that reflects how one company actually operates.
This only works if those pieces inherit common foundations for identity, data, deployment, and monitoring — rather than becoming another generation of orphaned internal tools.
Vendors will change too. The strongest may separate what they now bundle into a system of record, an agent-accessible service, and an optional interface for people. They will sell capabilities rather than destinations.
Start with one process
Before deciding what to rent and what to own, a company must see where its process lives.
Pick an outcome the business depends on: a signed contract, a filled order, a resolved ticket. Do not begin with a tool to replace. Begin with what has to become true, then trace every system, decision, exception, and manual handoff.
Most companies see the CRM stage, approval queue, and spreadsheet, but not the thread connecting them. Once that thread is visible, ask of each layer:
- Does it connect us to something difficult outside the company?
- Does it encode knowledge genuinely shared across companies?
- Does it represent our process inside someone else’s software?
The first is usually worth renting. The second deserves respect before it is rebuilt. The third is where the make-versus-buy decision has begun to move.
Trace one process this week. Do not replace or automate it yet. First, see it whole.
You already pay for your process. You just don’t own it.
The views expressed here are my own and do not represent those of my employer.