Every founder I talk to right now is under the same pressure: put AI in the product. A chat sidebar. A "smart" rewrite button. An assistant that knows the customer's data and answers questions about it.
I get why. Agents are the narrative. Investors ask about them. Competitors ship them. Customers screenshot them on LinkedIn.
I'd still push back on the default. If you already have a SaaS product people pay for, the highest-leverage move is probably not another assistant living inside your UI. It's making your product something their agents can use.
That distinction matters more than it sounds.
Built-in assistants are a feature race you will lose
A first-party assistant is easy to demo and hard to defend.
You are competing with every other product's assistant, and with the general-purpose agents customers already live in. Those agents see email, calendars, docs, tickets, code, the whole workday. Your assistant sees your product. That is a thinner context window, every time.
You also inherit a product tax: prompts, tools, evals, safety, cost controls, a UI that doesn't feel embarrassing six months later. That work is real. It rarely becomes the reason someone renews.
So yes, ship a chatbot if it solves a concrete workflow inside your product. Just don't confuse that with strategy.
The stickier play: let their agents in
The better shape, in my view, is the opposite direction. Your product exposes what it can do. The customer's preferred agent calls into it. They stay in the agent they already trust, and your SaaS becomes one of the tools that agent can reach.
MCP is the concrete mechanism people are converging on for that. Not magic, not finished, but the right direction: a protocol surface instead of a one-off chat UI.
Why this is stickier than a built-in assistant:
- Switching costs flip. If their agent already knows how to use your product, ripping you out means rewiring their workflow, not just logging into a different dashboard.
- You stop competing with their favourite agent. You become infrastructure for it.
- Usage compounds with their other tools. The agent that books meetings, updates Linear, and pulls metrics can also act in your product without a context switch.
That is a very different retention story from "we also have a chat box."
The hard parts nobody has solved cleanly
This is not a free lunch. Three problems sit in the way, and they are the interesting ones.
Monetisation. If an agent is the primary interface, what do you charge for? Seats? Actions? Outcomes? API calls the customer never sees? Pricing that assumed humans clicking buttons breaks when a machine is doing the clicking. Founders who invent a clean model here will print money. Everyone else will feel confused and underpaid.
Discovery / "SEO" for agents. Humans find products through Google, marketplaces, word of mouth. Agents will find tools through registries, capability descriptions, trust signals, and whatever ranking layer emerges next. That is a different marketing surface. Most SaaS teams have no muscle for it yet.
Complexity for the average user. Connecting an agent to a product is still a power-user move. OAuth, scopes, which tools to enable, what the agent is allowed to do. Until that feels as boring as "Sign in with Google," the market stays early. The company that makes connection feel obvious wins a disproportionate share.
None of these are reasons to wait. They are reasons to pick one and go deep.
Why this is a founder opportunity
Incumbents will bolt assistants onto existing surfaces. That is the path of least organisational resistance. The path of product leverage is thinner: design your data model, permissions, and actions so an external agent can operate safely and usefully.
That is greenfield-friendly work. A small team can ship a serious MCP surface before a large org finishes arguing about which chat vendor to buy.
History is boringly consistent on this pattern. New interface layers create new distribution and new pricing. The teams that show up early don't need to be perfect. They need to be first to make one painful part feel solved.
I'd rather be early and slightly wrong on MCP than late and polished on a me-too assistant.
What I'd do if I were building SaaS today
- Map the ten actions that matter. Not every button. The verbs customers repeat: create X, update Y, pull Z, approve W. Those become tools.
- Put permissions first. An agent with your customer's access is a liability if scopes are sloppy. Design least-privilege before you design clever prompts.
- Ship the protocol surface before the chat UI. Or alongside it, if you must have both. The chat can be a thin client on top of the same tools.
- Watch how power users actually connect. That friction is your product roadmap for the next eighteen months.
- Revisit pricing with agents in mind. If automation increases volume 10x, a per-seat model may be the wrong default.
The landscape will look different
I don't know which vendors win. I am reasonably sure of the shape: in a few years, a lot of software will be used more through agents than through its own UI. Some products that feel essential today will feel like backends. Some that feel niche will become the default tools agents reach for.
Tech giants that treat this as a feature checkbox may not like that outcome. Founders who treat their product as something agents can operate, not just something humans can look at, might.
The next big thing for SaaS is not another assistant living inside your walls. It is being useful outside them.
Opinion, not a forecast with numbers attached. MCP and agent tooling are moving fast; verify current protocol and marketplace details before you commit architecture.