Is Your Software Scaffolding?
Most SaaS products exist because humans needed an interface. Agents don't.
Much of modern software exists for the same reason: humans are slow at processing structured information, so we build interfaces to help them do it faster.
Dashboards. Forms. Menus. Workflows. Per-seat licences. A huge chunk of SaaS is built on a single assumption: that humans operate software to get work done.
That assumption starts to break over the next few years.
The question nobody's asking
Across a lot of SaaS right now, the conversation seems to be "how do we add AI features?" New copilot. Smarter search. Auto-generated summaries in the sidebar.
Wrong question.
The right question is: does your product exist because humans needed an interface to do work that agents will do directly?
If your roadmap is mostly UI polish and AI features, you may be investing in the layer that gets commoditised first.
Because if it does, you're not selling the building. You're selling scaffolding. And scaffolding comes down when the building is finished.
I can see this from inside Dolla, the accounts payable company I'm building. I started with a very simple thesis: in a lot of operational software, most of the work happens before software. It starts in messy inboxes, PDFs, attachments, email threads, and half-stated instructions. Humans have been the translation layer between that unstructured mess and systems like Xero.
So the first useful thing I built was not a dashboard. It was an invisible workflow: ingest the email, interpret the context, extract the invoice, code it correctly, and push the result into Xero. No app. No portal. Just email in, structured action out.
And building that changed my view of software. Once the interface disappears, you start seeing how much of the product was really just a bridge for a human operator. In plenty of products, the dashboard is not the product. It's the temporary bridge that existed because a human had to drive.
Think about what a lot of B2B SaaS is still organised around. A CRM is a structured database that humans manually update so other humans can manually query it. Project management tools are lists that humans manually reorder so other humans can manually check. In accounting, a lot of the work is still humans translating messy real-world inputs into a ledger that other humans review.
In many categories, those products are bridges between a human and a system of record. The human needed the bridge because they couldn't reliably interpret the upstream mess, apply the right context, and then act on the system underneath.
Over the medium term, agents will increasingly be able to do exactly that through APIs, policies, and system-level interfaces that don't require a human sitting in front of a screen.
Per-seat pricing is the canary
Here's one of the earliest visible symptoms of the structural problem.
Most SaaS companies price per seat. Salesforce, Atlassian, Slack, virtually everyone. The model works because headcount and software usage scale together. More employees, more seats, more revenue.
But what happens when one person with a team of agents does the work that used to require ten people?
The company still needs the same outcomes. Maybe more. But they need one seat, not ten. And the agent doing the work doesn't need a dashboard. It needs an API.
Per-seat pricing assumed that humans were the unit of work. In more and more categories, that assumption weakens over time. And companies priced around it are likely to feel that pressure early.
Some already have. The moment the same outcome can be delivered with fewer humans touching the software, seat expansion stops being a reliable growth engine.
What's actually dying
I want to be precise about this, because "SaaS is dead" is a lazy take and it's wrong.
SaaS isn't dying. But in a lot of categories, the interface layer is becoming dramatically less valuable.
The database underneath your CRM still has value. The integrations your accounting platform maintains still have value. The compliance engine in your HR software still has value.
What gets commoditised is the dashboard sitting on top of all of it. The menus, the clicks, the forms, the carefully designed user experience that helped humans navigate complexity. That layer was built for a user that increasingly won't be the one doing the work.
That doesn't mean every UI vanishes overnight. For a long time, many products will still have one. But it starts looking less like the place work gets done and more like an operator console for exceptions, approvals, and audit. The human stays in the loop, just in a different place.
The scaffolding was never the building. It just looked like it was, because for twenty years, the scaffolding was all anyone could see.
The memory problem nobody's talking about
Here's where it gets interesting, and where my own thinking has moved on since the last post.
In I Don't Consume the Internet Raw Anymore, I argued that context is becoming the scarce layer for the individual. I think that understates the shift. Over a longer horizon, memory becomes infrastructure at the company level.
In a normal SaaS company, organisational memory is scattered everywhere. It's in people's heads. In Slack threads from six months ago. In ticket comments nobody reads. In CRM notes that one sales rep wrote before they left. In the tribal knowledge that walks out the door every time someone quits.
Most software doesn't remember anything. It stores records. That's not the same thing.
When a new employee joins, they spend months absorbing context that exists nowhere in the system. When a customer calls with a problem, the support agent searches through fragmented tools to reconstruct what happened. When a decision needs to be made, the relevant history is scattered across twelve different applications.
This is the part SaaS founders should be paying attention to. Not AI features, not chatbot integrations, not copilots in the sidebar. The fact that the next generation of software treats memory as infrastructure.
What I mean by that: software that observes what happens, reviews patterns, and promotes stable, recurring, decision-relevant knowledge into durable memory that agents can consume. Not random notes in a database. Structured understanding that changes how the system behaves next time.
A record says Supplier X sent an invoice on Tuesday. Memory says this supplier is usually coded to maintenance for this property, except when the line item includes pool chemicals, and confidence should drop if the venue manager overrode the last two suggestions. A record stores history. Memory changes behaviour.
Customer-specific memory that overrides generic rules. Confidence levels that adjust based on history. Context that improves the next decision.
But this doesn't stop at the product. The same principle applies to the entire company.
Think about what a business actually is. It's a set of decisions made repeatedly, under varying conditions, with imperfect information. Hiring, pricing, prioritisation, customer communication, operations. In most companies, the knowledge behind those decisions lives in people's heads. When someone leaves, the company gets dumber. When someone new joins, the company spends months getting back to where it was. The institutional memory is fragile because it was never really institutional. It was personal.
A company built on memory as infrastructure doesn't work like that. Every decision, every correction, every override teaches the system something. A customer complaint doesn't just get resolved. It updates the pattern for how similar complaints should be handled next time. A pricing change that underperforms doesn't just get reversed. The reasoning and the outcome get captured so the same mistake doesn't repeat. An edge case that required human judgment today can become a rule, or at least a lower-confidence branch, the system applies next time.
The whole company becomes a learning loop. Not just the product learning its customers, but the business learning itself. What's working, what's failing, where confidence is high, where it should slow down and ask. Over time, that compounds into something that's genuinely hard to replicate, because the learning is specific to your customers, your market, and your operating history. A competitor can copy your features. They can't copy what your system has learned from years of making and correcting decisions in the real world.
That's a fundamentally different architecture from "store a record and let a human interpret it." And it's the moat that will matter. Not your UI. Not your feature count. Whether your system actually learns.
What I'm seeing from the inside
I mentioned Dolla earlier. Once that invisible workflow existed and the interface disappeared, the next bottleneck became obvious. It wasn't OCR. It wasn't extracting invoice fields. That part is close to solved now. The hard part was operational context. Same supplier, different venue. Same invoice format, different coding treatment. A note in the email body that changes the allocation. A historical override that should reduce confidence this time.
That's the point where a simple automation layer starts becoming something closer to an operating system. The product still processes invoices. But the thing getting more valuable is the system underneath. It learns each customer's patterns. It builds memory of how a specific organisation codes bills. It tracks which suppliers are stable and which are ambiguous. It knows when confidence should rise and when it should slow down and ask for review.
In products like this, the memory becomes more valuable than the dashboard.
It also leaves a trail of reasoning. Not just the answer, but why the answer was chosen. In accounting that matters, because trust comes from explainability as much as accuracy. If a system is going to take action for you, it needs to be reviewable. A customer shouldn't just see that an invoice was coded to maintenance. They should be able to see that the supplier usually lands there for this venue, that the email body included an instruction that changed the allocation, and that confidence dropped because of a recent override. That is what makes automation feel trustworthy rather than magical.
And when the learned behaviour is wrong, someone still has to own that. In accounting, "the system learned from its mistakes" is not an answer your auditor accepts. The accountability has to be as clear as the reasoning.
I should be upfront about my bias here. I'm building Dolla this way, so of course I'd argue this is the future. I'm also describing the categories where this pattern seems strongest to me: software that sits between messy real-world inputs and structured systems of record. I expect those categories to change first.
That's the role I think humans keep. Not clicking around software all day. Setting policy, reviewing exceptions, handling edge cases, and making the judgment calls that shouldn't be automated away.
That's not "SaaS with AI features bolted on." That's a different thing entirely.
The uncomfortable audit
If you're running a software company, here's the question worth sitting with:
If an agent could operate the underlying job through APIs, policy, and audit, would anyone still need your UI?
For a lot of horizontal SaaS, over time, the honest answer may be no. The UI was the product because humans needed it. Agents don't need a drag-and-drop interface to reorder a task list. They don't need a Kanban board. They don't need a settings page with thirty toggles. They need services to act on, context about what matters, and policy about what they're allowed to do.
That last part is important. The future isn't "agents with no guardrails." It's agents operating within explicit policy. Actions classified by risk, reversibility, and confidence. Some things get automatic approval. Some need human sign-off. Some are blocked entirely.
Once software starts acting this way, the valuable layer shifts again. First the interface matters less because the agent can operate the job directly. Then the control layer matters more because someone still has to define what the agent is allowed to do, when it should slow down, and how its actions get reviewed. That governance layer is real software. That's the building, not the scaffolding.
The job is not to keep humans clicking around software. It's to keep human judgment at the boundary where consequences live.
That's not a temporary compromise. It's the architecture.
What survives
Software doesn't disappear. But the valuable layer shifts.
The infrastructure survives. Databases, authentication, payments, communications plumbing. Agents need to act in the world, and they need reliable infrastructure to do it. The pipes matter more than ever.
Customer-specific context survives too. If your software has accumulated years of customer-specific context that makes it smarter over time, that's genuinely hard to replicate. The moat isn't your feature list. It's what your system knows that nobody else's does.
Deep vertical knowledge survives as well. Generic horizontal platforms get squeezed. But software deeply embedded in a specific industry, with domain knowledge that took years to build, still has a reason to exist. Accounting rules, compliance requirements, industry-specific workflows. Agents need that knowledge. They just don't need the same interface layer that currently delivers it.
And policy and governance survive. As agents do more, the question of what they're allowed to do becomes critical infrastructure. Permission systems, audit trails, approval workflows for high-stakes actions. This is real, valuable, lasting software.
You can already see enterprise software moving in this direction. The language varies, but the underlying idea is the same: as agents start acting inside the business, the control layer for visibility, permissioning, and accountability matters more.
If I had to rank the durable moats, I'd put them in this order: customer-specific context first, trusted permission to act second, distribution into real workflows third, and deep vertical knowledge fourth. Those get stronger as UI and code get cheaper.
There's a second-order effect worth noting. It's not just that agents will increasingly use software directly. They'll increasingly write it too. First the agent replaces the user of the software. Then it replaces much of the team writing it. At that point, the scarce thing is no longer the interface, or even most of the code. It's the context the code acts inside: the customer-specific data, the accumulated memory, the permissioning, the audit trail, the operational history, the real-world trust the system has earned. The moat moves from the product to the environment it is generated inside.
The rebuild opportunity
I don't think this is a doom story for software founders. I think it's a rebuild story.
At the company level, this is really the same argument I made in New Zealand's three-year window: the advantage goes to companies built clean from day one, not legacy businesses trying to bolt AI onto architectures designed for a different era.
The companies that pivot from "software humans operate" to "infrastructure agents consume" will be worth more, not less. The total value of work being done isn't shrinking. If anything, it's growing. It's just that the interface between "thing that needs doing" and "thing that gets done" is collapsing.
If your software sits in that collapsing middle, you have a choice. You can keep polishing the dashboard and adding AI features to an interface that's becoming irrelevant. Or you can ask what your software actually knows, what data it's accumulated, what context it holds that nobody else has, and rebuild around that. That's not an overnight flip. Most companies will run both layers for years. But which layer you invest in matters now, because the one you starve is the one you won't have when the shift accelerates.
The SaaS model sold organised interfaces to humans doing manual knowledge work. That was the scaffolding.
The building is software that accumulates context, governs autonomous action, and compounds understanding over time, while keeping human judgment where it actually matters.
The scaffolding comes down. The building is just getting started.
I'm Ben Lynch. I think about founders, AI, and what happens next from New Zealand. Say hello at ben@thinkdorepeat.ai.
If you're new here, Start Here is the best place to begin.
If you know someone whose roadmap is still optimised primarily around humans using the software, send this to them.