A roadmap for building the future of SaaS
I really like this slide I saw online from Des Traynor, one of the co-founders of Intercom.. uh I mean Fin. For all the frothy hype and exuberance in the AI<>software discourse, I find this is such a clean and concise summary of what people mean when they talk about “agentic” products and the future of SaaS. I don’t think I’ve ever actually seen the attributes and characteristics laid out this clearly.
This is something I am thinking a lot about, and a constant topic of conversation in our product team, so as I try to think about how we are adapting to this new reality, I thought it would be helpful for me to just step through each of these points and flesh out the thinking and what it really means.
Let’s go through these one by one.
“Own complete domain areas”
From platform suites, to specialisation and best-of-breed, it feels like our industry changes its collective mind every few years as to what the best way to architect a software stack is.
In the age of AI, it is becoming clear that tools and point solutions are in a very vulnerable position, because AI and coding agents place tremendous negative pressure on the pricing power of these “lighter weight” tools. AI is very capable at building tools, so it’s going to be increasingly difficult to justify higher prices and annual contract expansion. For a SaaS company with any level of ambition, this isn’t a feasible way to operate. However, out of these tool-ashes comes a huge opportunity for software companies to own entire domains. To be more than just a tool. To be a solution that doesn’t just enable the work to be done, but increasingly does the work too.
What’s most interesting here is that sufficiently ambitious product teams can start to flex their product development muscles and expand into more of their domains. By the way, for this piece, my definition of a domain is the combination of raw tooling and the (often unwritten) knowledge of how, when and where to use the tools.
Domain = (Tools + Organisational Expertise + Industry Convention)
Let me use a real life example from Komo, where I lead product. Historically, our domain has been customer engagement, but more specifically interactive content, a smaller slice of that broader domain. Our customers, which are large global consumer brands (like Live Nation, NBC Universal or the the New York Comic Con) use our product to design and deploy interactive content to their audiences. This can be competitions, quizzes or micro-games, just to name a few examples.
Generally speaking, Komo has been deployed in an enterprise stack alongside existing tools in the Marketing Automation, CDP and CRM categories. We’ve operated within a wider ecosystem of tools and systems that support our domain.
We’ll always play nice (partner, co-sell, integrate) with other software vendors to be sure, but recently, we’ve been seeing a lot of traction with helping customers consolidate more of these “generic martech” capabilities into Komo. Put simply, more of the stack collapsing into one platform.
Why are customers asking for this? For two reasons:
Less tools is almost always better. Everyone instinctively knows this.
Consolidated tools in a given domain is the only way to reliably deploy agents.
Every big enterprise, including all of our customers, want to deploy agents. They see the vision clearly, they’ve all drank the kool-aid. However, as we have all learned over the past few years, it is just not that easy to get this stuff to work reliably beyond a cool demo. Deploying an agent to run, for example, customer engagement, across 3-5 different software products (CMS, CRM, CDP…), is just not viable. Integration tax, data-sync latency, security concerns, permissions issues and maintaining up to date context are just a handful of the immediate roadblocks here. It’s worth noting that this dilemma exists in practically every domain and software category today.
If you can consolidate all of the tooling (modular capabilities) needed in one place, encode all of the domain expertise (historical learning, what’s been tried and failed, guardrails, playbooks, rules) and then use agents to drive the car, we start to get closer to a true “system of work”-style paradigm.
Five years ago, the prevailing product orthodoxy was to pick a lane and stay in it. It was simply to much effort for a team like ours to expand into new pockets of our domain. “Core business” and all that. Suddenly, there is an opportunity, for strong product teams, with strong customer relationships, to expand quickly into all of the open space in their domain.
“Are fully agentic”
Almost all of the software we use every day, at least until five minutes ago, has been tool-shaped. Tools that enable humans to do work in a more productive manner. The shape of these software tools have been remarkably consistent across multiple generations. Lists, forms, graphs, tables and buttons. Focus-type-point-and-click. I touched on it above, but one really cannot understate just how big of a mental shift it is to think about software as not just tools that help humans do work, but as a system that can do work too.
It’s no surprise to anyone reading this, but we’re of course now at the point where AI is getting fairly good at reasoning, researching, writing, coding and coordination. When these capabilities sit on top of the domain context we talked about above, things start to get very interesting.
This all has obvious implications for pricing power in two distinct ways. Firstly, software can now in theory angle for budget previously tied up in labor costs but secondly, and perhaps most importantly, solutions that do work and achieve outcomes can start to price based on outcomes and the work done. You will no longer want to pay for a tool to help you with project management, you will want to pay for a solution that does your project management.
“Let you interact however you want”
This idea of headless composability has been one of the most common themes of my blog posts over the past year, because I am fairly convinced that it represents a really seismic shift in how we will think about building products in the future.
In the future, product and design teams will consider agents to be as relevant a “user group” to optimise for, as their human counterparts. APIs, CLIs and SDKs are going to be a far bigger priority for product teams than ever before. This will enable customers to use products in totally new ways: from the command line, from a chatbot or via a copilot-style experience in product too.
“Are self-improving”
This is perhaps the hardest one to nail down, largely because there is a massive misunderstanding out there in the community, especially among customers, about how this actually works.
Many buyers assume that the large language models inherently learn on the fly. They expect that every time an end-user chats with a model, it retains that exact conversation and magically gets smarter for the next run. But foundation models don’t improve statically in real-time. If you feed the exact same prompt to a frozen API weights-set, you’re going to get a similar, static level of capability.
This is all trickier than it sounds. For example, we work with a lot of customers in global sport. One of the most common use cases is in-venue activation. But there are a million-and-one little details here which need to be accounted for. Sending some content to fans 5 minutes after their team has just lost an important game and their best player has been injured is a big no-no, but the models won’t inherently understand this domain-specific context. This is the task ahead of product teams today in this era: figuring out how to encode all of the little nuances and details.
The “self-improving” loop doesn’t happen at the model layer; it happens at the application layer. It’s about building the “harnesses” around the model. When a user edits an AI-generated campaign in Komo, or rejects a specific design choice, that telemetry has to be captured, structured, and fed back into a system which attempts to store these “learnings” to better prompt the models next time. This is not out-of-the-box AI capability. True self-improvement in AI-first software means the system is constantly optimising its own prompts, memory retrieval, and domain guardrails based on real-world usage, making the software uniquely better for that specific customer and use case every single day.
“Are strategic systems”
Historically, a platform like Komo has been viewed primarily as a tool for tactical implementation. A marketing team uses us to execute a specific initiative: “We need to launch a quiz for the New York Comic Con by Friday.”
This isn’t unique to Komo tough, this actually goes for almost all enterprise software today. The humans define the strategy in a meeting room somewhere, and the software is just the execution mechanism. The software doesn’t really understand the strategy.
The shift to an agentic world entirely flips this dynamic. We are moving from tactical execution to goal- and strategy-setting.
Instead of telling the software what to build, the team will input a high-level business objective: “We need to increase first-party data capture among Gen Z attendees at Live Nation events by 15% this quarter.” The software then steps up into the strategic role. It analyses historical engagement data, reviews what campaigns worked or failed in the past, designs the optimal interactive experience, schedules the roll out, and monitors performance. The human moves from being the primary builder to being the editor-in-chief. From tool-shaped to strategy-shaped.
“The primary performance vector is the quality and depth of the AI”
The first era of AI copilots, if we are being completely honest, were often extremely dumb. They were largely thin UI skins slapped on top of raw LLM endpoints. We called them “wrappers” back then. Glorified auto-complete bars that lacked any real sense of context, memory, or domain awareness.
In this new era, your core engineering moat isn’t just your UI or your database model. As Des says, “the primary performance vector is the quality and depth of the AI”.
The harness is the product now. We’re already seeing some truly fascinating work here. This world will require moving far beyond stitching together API calls toward building deeply contextual and verticalised systems, and maybe even custom models, similar to what Intercom has done with Fin, or what Canva and Leonardo.ai are doing with visual generation. It means creating sophisticated “cognitive” architectures. The job as a modern product team is no longer just building great software features, the job is building a highly optimised “system” around the AI to maximise its capability to do real work within your specific domain.
These attributes, these new characteristics, form the basis of a new moat. It’s never been more viable to ship internal tools, to rip out overly expensive point solutions and roll tools specifically suited to your needs. This means the bar for what we will consider “premium” software is going to be drastically raised, but the opportunity on the other side may be bigger than any other time in software history.
