For the last few years I’ve been building an agent that lives inside an existing SaaS product. During that time we’ve seen the creation of MCPs, general purpose agents like Cowork, and the meteoric rise of AI Native startups. All of this has left me wondering, what is the future of SaaS products in a world where software usage is dominated by agents? This is my attempt to make some sense of that.
I recently read a piece from PostHog that disclosed that 19% of dashboards in the product are created by their embedded agent PostHog AI and 18% are created by external agents via MCP. That ratio is a perfect illustration of what’s on my mind. In a world where most users interact with software via an agent, whose agent do they use and where?
I see three places these interactions will take place:
All three will have their place, but a lot of questions remain about exactly what that will look like. How will usage distribute between them? How much should incumbents invest in their own embedded agents vs. tools for other agents? And what might successful startups look like?
Take any software product you use to get your work done, they are likely building an agent inside their product that can search, synthesize, and act. I call this an embedded agent. The question emerging in the industry is: do you need this? What is the role of an embedded agent as opposed to an MCP which makes a tool accessible to other agents? By other agents I primarily mean the labs’ general purpose agent products: Claude Code, Claude Cowork, Codex, and ChatGPT Work. It’s an important question for incumbents, users, and investors. I think the answer depends both on execution and the nature of the product.
Notion AI is a perfect example of an embedded agent done right. It can access, search, and create items all across Notion. Although they have an MCP, their embedded agent is both more capable and provides a better user experience. Notion AI is built with a deep connection to the core primitives of the product and it has been evaluated and optimized for the exact things you want to do in Notion. For example, I recently had it turn a messy list of work to be done on a side project into a clean Jira-like board and I could watch it manipulate and work on the board live after my request.
Another recent example is Rippling AI. The embedded agent can build reports from a sketch, rank candidates using interviewer panel ratings, relevant work history, even recorded interview transcripts, or clean complex Payroll data. It can access hundreds of underlying data models in the system. This is extremely difficult to replicate via MCP because of the amount of knowledge required about a set of complex underlying data models. The agent can also present work in bespoke UIs that make sense only for Rippling.
Datadog has also entered the embedded agent space and illustrates where the value becomes fuzzy. Most Datadog users are also heavy users of coding agents. Datadog has a strong MCP. As a user, I’m not quite sure when to reach for the MCP vs their embedded agent. If I’m debugging something complex, I’ll often try both. I find that I lean toward using the MCP because I get the benefit of the context I’ve built up in my local environment (like Skills outlining tricky parts of the codebase) and because the agent can actually run code to validate its ideas.
There is indisputable value in these embedded agents and I think incumbents have almost no choice but to try and build them right now, but the path isn’t risk free.
The problem, as illustrated with Datadog, is that it’s not obvious that an embedded agent is better than a general-purpose agent like Claude Cowork or OpenAI’s Codex equipped with an MCP. Just look at the PostHog stat. If the ratio is 50/50 now, how might it trend over time as products like Cowork and Codex continue to rapidly improve and increase in adoption? There is evidence that, done well, these agents can provide more value than general-purpose ones. But it’s an uphill battle.
Competing against the myriad of features that a product like Cowork or Codex rolls out day-to-day is effectively impossible. So if people are to use your embedded agent long-term, it needs to be better than external agents in some meaningful way. This might look like being more trustworthy, doing novel things that external agents can’t do on the platform (like Notion), or having a uniquely useful interface.
Incumbents do have a lot of advantages, to name a few:
I think most companies will ship both an MCP and an embedded agent. This enables them to hedge their bets to an extent. Further, the work is not mutually exclusive. The core thing required for each is creating the set of tools that optimally allow an agent to interact with your product. The risk is that you invest heavily in an embedded agent that users never adopt. But the upside of success, and unknown of what it means to be reduced to a tool for other agents, justifies the risk.
I don’t at all subscribe to the idea of the SaaS apocalypse in the manifestation where most SaaS products just get cloned and built internally by anybody who wants to use them. But I do think there’s a serious chance that existing SaaS products turn primarily into tools for agents and their end users rarely open them directly or have a relationship with the product.
It seems this would be bad news for most SaaS companies’ business models. But users may switch if given a better pricing offer, and we can bet migration will become much easier than it is today.
How bad it is to primarily be a tool for agents depends on the type of product. For example, developer infra (Supabase, Vercel) benefits from this. Every new agent is a potential customer, these tools were already used primarily via API, and the agents can’t replicate the underlying infra. For thin CRUD wrappers around a database, things seem more dire. Their value was a place to store data plus a UI and workflows on top of it. Now it’s just a place to store data. And who says that Anthropic or OpenAI won’t do that some day too? SoR applications have long benefited from high switching costs due to two factors: the investment to learn a tool and data migration. Agents may quickly eliminate the learning curve. If I just talk to this platform via MCP, another can be swapped in pretty easily. For now data migration is still painful, but presumably agents will solve this too.
For this category of products the cost and pricing story is also unclear. An embedded agent adds recurring inference cost that scales with use. An MCP just adds more API calls which is not much of a problem. The question is whether you can adjust per-seat-pricing or add usage based pricing that makes an embedded agent worth it.
Again, Notion’s approach is worth studying. Baseline AI is gated behind a paid tier. This tier is also required for the most useful of their MCP tools, like search. The most autonomous feature, Custom Agents, has usage-based billing that can capture further upside. This hybrid model will likely become far more common.
Incumbents are theoretically well positioned to also charge on a per usage basis for requests via MCP except that it completely breaks the user’s assumed pricing contract.
A concrete example of how this depends on the product is Jira. I use the JIRA MCP all the time to read, create, and search for tickets. There’s no reason I would prefer an embedded agent in JIRA. In contrast, if I was to undertake serious synthesis of data in Notion, I would trust Notion’s AI over accessing Notion via MCP. Does that mean I can swap Jira out tomorrow? No. But is the risk higher? Certainly.
It seems the pattern is that products whose main value is in executing a transactional task (file a ticket, mark a todo, log an expense) are well served by MCP. Products that synthesize, explore, reason, produce work, benefit more from an embedded agent. Notably, AI has actually created the opportunity for the first type of product to shift into that second.
Notion provides an example of how to thrive in the AI transition. Half of its Business and Enterprise customers now pay for AI features, up from 10–20% the year before. They have made this happen by both gating the full featured MCP and their own AI features behind a separate pricing tier.
But Notion is a very unique company. The founder is a hands-on engineer who’s become obsessed with AI. They reportedly rebuilt the underlying product multiple times to support their AI native future. They have some of the best applied AI engineers on earth. Very few companies will replicate their success. Which brings us to the opportunity for startups.
As we shift to a world where software is primarily used by agents, what are the opportunities for startups? Startups approaching an existing market need to beat both the incumbent’s agent and the experience of using the incumbent via MCP. But they also have the advantage of being able to move quickly and explore completely novel types of products.
Startups have many advantages during a period of rapid technological evolution. They don’t need to retrofit old ways of thinking into a new world. They’re not bogged down by complex infrastructure, bureaucracy, sunk-costs, or slow decision making. Maybe most importantly, they can design their own code-bases to be optimized for agents to work in from day one making their speed of execution dramatically faster than incumbents. Combined with increased speed of decision making, this is an enormous advantage.
This path of direct competition requires conviction in two bets. One, you can build a 10x better agent than the embedded ones companies are building. Two, your agent will also be 10x better than cobbling together MCPs and Skills in Cowork / Codex. There is also another path: addressing opportunities that did not exist at all before AI and don’t fit cleanly into any existing product.
How does one make good on these bets? A strong tactic traditionally was to find a wedge to provide immediate value to users and to expand from there. Given the pace at which new software can be built now, might being more ambitious from the start be a better path? I see a number of valid approaches.
The first option is to build a product that relies on integrating with other systems and serves as an intelligent agentic layer. Later, you transition to owning more and more of the context yourself.
This approach arguably made sense a year ago and is already out of date. For one, there’s a huge amount of risk if your platform depends on integrating with any one specific system of record. Your access can be revoked at any moment. Second, if we assume most companies will be forced into exposing an MCP, you need to figure out what your product will provide that a user would not get by integrating the incumbent with their own horizontal agent.
That being said, if you can get initial distribution, advantages can quickly compound. Agent-first products are unique in that once you get usage, you start to immediately get an influx of tremendously useful data. There’s almost no better way to get evidence of what users want than by reading the traces of an agent. Every interaction reveals user intent in natural language. Incumbents will have this data too, but startups have the unique compounding benefit of being able to act on it incredibly quickly. They can add features or even redesign data models and products around what traces reveal because they have no legacy product to protect or loyalty to an outdated roadmap.
Startups in this space would seek to expand capabilities and eventually swap out the dependency on external systems of record and clone them to own the data themselves. This should be easier than expected because they have extremely high-value data about what data models and interactions users care about the most. Most SaaS companies are extremely bloated, and there’s probably a small percentage of users or features that most users care about.
Another option is to start with a narrow end-to-end product that doesn’t depend on integrating with any system of record. Pick a specific painful workflow and build the AI native version of just that from day one. No integration risk. You can ship fast because scope is small. Over time you can expand into adjacent workflows.
This is easier in some ways, harder in others. For one, many of these products will have fierce competition, both from other startups and from incumbents who build the wedge as a feature. Further, the wedge must be picked carefully or you risk shipping the narrow product but never managing to expand. These products may be great acquisition bait for a larger platform, but are unlikely to be huge. Avoiding this requires picking a wedge that is critical, underserved, and a strong foundation for the platform you would eventually build.
A third option, dependent on significant capital, is to build both the system of record and AI layer at once. You go straight for replacing the incumbent. Cursor is the canonical example here. Cursor didn’t build an extension for VS Code, they just built the IDE and it worked. This path is more closely related to the Integration than the Wedge play.
This path has a lot of risks but very high upside. It’s a bet that an AI-native architecture can create so much better of a product that customers will accept the switching cost, that you can build the whole thing fast enough, and that you can get distribution. This path is full of painful grunt work in that much of the effort will be in rebuilding the core underlying components of a SoR as opposed to working on agents. Much of the engineering required is tedious replication of standard SaaS features, data models, and business context.
Depending on the domain, it is also not obvious that an AI-native version of a thing will be significantly better than the thing with AI bolted on. Still, Cursor and others prove this is both possible and extremely valuable if successful.
There is a fourth, and perhaps most interesting, option. This option may also have the strongest evidence from the first wave of mega-successful AI startups: building an entirely new AI layer that doesn’t directly compete with incumbents but augments or obsoletes them.
Rather than compete with the incumbent for users, you work alongside whatever tools the user already has. Some of the inputs and outputs may flow from/to their existing stack but over time more of what used to be distributed across legacy tools happens in the new layer first.
Harvey didn’t necessarily compete with legal research, case management, or contract review tools directly at the start, they built a new AI layer for Big Law legal work. Outputs flow into Word, email, existing matter files. The user didn’t need to choose this or that. But Harvey absorbed a huge share of work that used to happen across them.
Sierra didn’t try to replace Zendesk at launch, they built a new agent layer that worked above the help desk. If help desks become smaller over time for Sierra customers that’s just the natural arc of a category-creation product, where the legacy SoR keeps existing but loses share to the new layer.
These tools didn’t replace something that was already happening but identified something entirely new that could, and should, happen.
There are two structural reasons why this works.
First, AI made a new category of product possible. Not one that stores work, or that you use to create work, but one that does work for you. Incumbent SoR apps will try to transform themselves from stores of work into doers of work. From System of Record to System of Action. Some will succeed, some won’t.
Second, rigid systems of record have always been a tax for enabling large scale coordination. They enable searching, sharing, collaboration in a way that natural artifacts didn’t. AI changes that. An agent can directly infer state from emails, chats, docs, transactions, whatever without forcing humans to adapt their work into a rigid system. In work where rigidity and having to learn to use a tool that only roughly mapped onto what you actually did was always a pain, the SoR category itself may be hollowed out, replaced by an entirely new type of software: AI assistants that meet you where you already work.
Would-be startup founders interested in this path can ask: where was the structured product tolerated rather than loved? And where might an AI assistant that works alongside existing tools take its place?
This is also the path that incumbents are worst-positioned to follow. They’ve built years of structured data models and pieces of business logic that force users to adapt their work to fit the system. A category creation product meets users where they are and infers state from natural artifacts. Most of the accumulated investment becomes a bug, not a feature, and most incumbents won’t ship a product that makes their own foundation irrelevant. The biggest risk for those on this path comes from horizontal agents which already work alongside existing tools and can specialize via skills. The bet is that vertical depth, unique interfaces, and long tail integrations matter enough.
We’re going to see successes in each approach:
The interesting question for any incumbent, founder, or investor isn’t “who wins?” but, “in my domain, where is value likely to accrue across these approaches?”
The embedded agent + MCP approach will sustain many incumbents, but others will flounder on this path. Some due to execution, some due to the structure of the problem they solved. The ones who fumble end up on the MCP-only path by default. The question is whether they can successfully adapt pricing models to this or not. For startups, the viability of each of the four positioning choices will depend on problem space, funding, and risk tolerance. Integrate and expand is fragile but possible. Wedge and grow can produce a solid business, but fewer platforms. Direct replacement requires capital and talent many founders can’t access. Category creation has strong evidence and clear advantages, but the opportunities are hardest to see.
The one obvious thing is that there is no clear answer to how the future of agents and SaaS will shake out. Too many variables are unknown. How fast will incumbents move? Will common business models emerge around MCPs? Are embedded agents actually better than horizontal agents equipped with robust integrations and Skills? The rational response to genuine uncertainty is to find a position with high visibility into where things are going. You can’t think your way to clarity, you iterate your way there.