The Services Stay, the Interface Transforms
Why we need orchestration, semantic APIs and composable interfaces.
There’s a lot of discussion about SaaS being dead. The argument goes that AI agents will replace traditional software platforms entirely.
I don’t think that’s what’s happening. Let’s really think about what SaaS platforms provide. They give us reliable, deterministic processing, structured data storage with proper relationships, validations, processes for verifying that things actually work. There’s enormous value embedded in these systems. Do we really want to rebuild all of that from scratch?
The problem isn’t that these systems don’t work. They do. The problem is that the interface layer has become the constraint. You still need the underlying functionality—the business logic, the data models, the integrations, the compliance frameworks. But the way we access that functionality is fundamentally shifting.
The “We Don’t Need Photoshop” Fallacy
There’s a tempting argument making the rounds: we don’t need Adobe Photoshop anymore, we can just build smaller, focused tools that do exactly what we need. AI makes it easy to build software, so why not create exactly what you want instead of wrestling with bloated legacy applications?
The problem is you probably do need Photoshop. Or more precisely, you need the thousands of functions that Photoshop provides, most of which you don’t even realize you’re using until they’re not there.
Photoshop isn’t just a collection of filters and adjustment layers. It’s decades of edge case handling, color management systems, file format support, print production workflows, plugin architectures, and domain knowledge embedded in code. When you crop an image, you’re not just cutting pixels—you’re preserving metadata, maintaining aspect ratios, handling different color spaces, managing resolution for different output targets.
Most users only consciously use a fraction of Photoshop’s features. But their workflows depend on many processes they don’t realize exist. When you export a file, you’re relying on color profile conversion, compression algorithms, format specifications, and compatibility layers that took years to get right.
You could build a simpler image editor that handles your current workflow. But workflows change. You start doing print work and suddenly you need CMYK support. You collaborate with someone who uses a different tool and you need to handle their file formats. You take on a project with specific color requirements and you need proper color management.
And here’s the real issue: when your workflow changes, do you want to build new features? Some will. Many won’t. Most people don’t want to be software developers. They want to get their work done.
The alternative isn’t building a simpler Photoshop. It’s having a composable UI that leverages Photoshop’s existing functions in an interface you feel comfortable with, that’s intuitive to you. Not a monolithic interface designed for every possible user, but a dynamic one that surfaces exactly the capabilities you need, when you need them, in a way that makes sense for how you work.
The functions stay. The interface becomes fluid. This is what agents can do now, and it’s extremely reliable because we replace and customize the front end, not all the background processing that’s invisible to the user. The complex, battle-tested logic that handles edge cases, maintains data integrity, ensures compliance—all of that stays intact. What changes is how you interact with it.
What We Actually Need
If these systems already exist and work reliably, why rebuild them? You don’t want to recreate Salesforce or SAP from scratch. These systems represent decades of domain logic and integrations that actually work. They’ve solved real problems—managing customer relationships, handling complex financial workflows, maintaining audit trails. That knowledge doesn’t become obsolete because we have better language models.
What we need are two things: semantic APIs and interfaces for agents, and composable UI for humans.
For agents to orchestrate across systems, they need interfaces designed for machine understanding, not just machine consumption. Most APIs today were built for human developers reading (often partial) documentation. The semantics are implicit—you understand what an endpoint does because you’re human and you understand the domain or your own internal systems logic. An agent needs that structure to be explicit. The structure needs to carry meaning. Responses need to be well-structured and token-efficient.
This isn’t about inventing new protocols. It’s about adding semantic richness to what we already have. APIs need to describe themselves, their capabilities, their constraints and, importantly, where things go wrong and how to fix it to allow for agent error management.
For humans, we need composable interfaces. The UI that adapts to what you’re trying to do, that surfaces the functions you need without forcing you to learn where they live in a menu structure designed for someone else’s workflow. This is different from customizable interfaces where you manually configure what appears where. A composable interface is generated for the task at hand, drawing on the full function library of the underlying system but only exposing what’s relevant right now.
Current SaaS Can Stay in the Game
I believe we’ll see disruption, but I think current SaaS companies can stay in the game if they focus on three things: more semantic APIs, supporting native or (more likely) third party extensibility via orchestration and vibe-coded platforms, and fluid composable UI.
The practical path is extension, not replacement. Extend existing systems via API, cutting down the UX to what you specifically need with vibe-coded extensions and integrations. Support the connective tissue—the agents that orchestrate across systems, the custom interfaces that surface exactly what you need, the workflows that compose multiple services together. The heavy lifting stays with the existing platforms. The value shifts to the integration layer.
Not all of this will be built into the platforms themselves. I think we will see new platforms emerge specifically to augment their services—platforms for agent orchestration (see coda below) that sit between users and the existing SaaS infrastructure. These orchestration platforms become the layer where workflows are composed, where multiple services are coordinated, where the composable UI is generated. The underlying SaaS provides the functions. The orchestration platform makes them accessible and composable.
This is already happening (as I wrote about last year). I’ve seen teams build lightweight wrappers around legacy systems that expose just the functionality they need in a form that agents can work with. They’re not migrating off Salesforce. They’re making Salesforce accessible to their agents while building custom workflows on top.
The economics make sense. These existing platforms have absorbed enormous development costs. They handle edge cases you haven’t thought of. They maintain compliance with regulations you might not even know exist. Throwing that away to build something new from scratch is wasteful.
Orchestration platforms don't replace these underlying services—they coordinate them. The workflow logic "when a customer submits this form, check their account status in System A, validate their request against policies in System B, create a ticket in System C, and notify the team in System D" still relies entirely on those systems to do the actual work. What changes is how you compose them together. These workflows are currently implemented through manual processes or rigid point-to-point integrations. Orchestration platforms make them flexible, visible, and manageable without replacing any of the underlying functionality.
The Evolving SaaS Landscape
We may see a change in the SaaS landscape, but I think initially we’ll see more focused, point-based APIs made for agents evolve. This may come from existing SaaS companies adapting, or from new services built specifically for agent orchestration. But I doubt every vibe-coded project will build this from zero—at least for a while.
We’re moving from “users interact with UIs that call services” to “users interact with agents that compose services.” The UI becomes fluid, generated on-demand for specific tasks, rather than a fixed interface you have to learn and navigate.
This doesn’t mean visual interfaces disappear. It means they become composable and context-specific rather than monolithic and permanent. You don’t learn Salesforce’s UI anymore—you tell an orchestration layer what you need, and it figures out how to make Salesforce do it, possibly generating a minimal interface for the specific task at hand.
The interface adapts to the task instead of forcing the task to adapt to the interface. If you need to review a specific set of customer data, the agent generates a view that shows exactly that data, with exactly the controls you need for this specific task. Next time you have a different task, you get a different interface.
This is a fundamental inversion of how we’ve built software for decades. We’ve always built the interface first and then taught users how to navigate it. Now we’re building systems where the interface is a consequence of the task, not a precondition for it.
We’re going to rely on specialized services just like we do now with SaaS. But they’ll be API-driven with composable UX rather than fixed UI. The services persist. The interaction layer transforms.
Coda: this is what we are building for the publishing sector at pure.science