SaaS Built for AI Agents

A founder in our mastermind asked a question that every SaaS CEO is quietly asking right now: where are the big AI labs headed in the next six months, and what will the mainstream AI interface look like? He runs an AI-native company and has spent the last few years learning what it feels like to build next to companies with far more money. His experience is that you ship a feature and, some months later, a much larger company ships the same thing. After enough of that, he started looking for the gaps the big platforms are unlikely to fill, and he wanted the group's best guesses about where the ground is moving.

Nobody on the call claimed to know the future, and I said so. What we could do was agree on a few things that already look obvious, and argue about the rest. Here is where the conversation landed, and what I think it means if you run a software company today.

Your next wave of users will be agents

The clearest point I made on the call is that the users of SaaS products in three or four years are going to be majority agents, not majority humans. I compared it to 2008, when APIs started to become a big deal. The difference is the timeline. Back then the industry had something like eighteen years to adapt. Now you have maybe eighteen months at the very most, and we are already about halfway through. That leaves roughly nine months to get your integrations working well with agents.

The practical meaning is that the interface that matters most is moving from your dashboard to your API and your MCP connections. An agent does not care how good your onboarding screens look. It cares whether it can authenticate, find the right endpoint, take an action, and get a clear answer back. One of the founders on the call put the trend this way: there will be a lot more headless systems, where the product runs behind the scenes and people never log in. Another pointed out that the AI labs release agents in part because agents consume far more tokens than humans do, so the incentive to build more of them is strong.

• Audit your API and MCP coverage. List every action a customer can take in your product and check which ones an agent can do without a human clicking anything.
• Make errors readable. Agents recover from problems when the messages tell them what went wrong and what to try next. Vague failures stall them.
• Test with a real agent. Connect an AI assistant to your product yourself and try to complete a customer's most common job. Whatever breaks is your to-do list.
• Set a date. With nine months left by my estimate, pick a quarter-end deadline for agent-ready access to your core workflows.

It is also worth thinking about what happens at the edge of your product. One member on the call noted that when all the MCP connections across a company start working together, reports stop matching. You no longer get a consistent view of what is happening, and analytics becomes more important as a result. If agents are acting on your data, you need one place that tells you what they did.

Pricing will move away from the seat

If agents are doing the work, charging per seat makes less and less sense, because an agent is not a person and one agent may do the work of ten. I expect pricing to move toward transactions and usage, which is a little annoying, since all of us like recurring revenue and it is hard to get predictable recurring revenue out of per-token usage. A founder on the call went a step further and said he expects pricing to shift toward outcomes, where a customer pays for a result rather than access. I think he is right, and I think that will take longer to reach.

This is the part I would plan for early. Changing a pricing model with an installed base is a slow, delicate process. You do not want to be doing it in a hurry because a competitor with a usage model is undercutting you on a workload that an agent can run all day.

• Find your unit of value. Decide what your customer is really buying, whether that is a report, a booked meeting, a processed claim, or a resolved ticket.
• Pair a base with usage. A platform fee that covers access, plus variable charges for agent-driven volume, keeps some of the recurring revenue you want.
• Put limits in place. One founder warned that if you let agents or chatty users run unlimited queries, your backend costs can climb while the customer pays nothing extra. Set token or query limits before you launch.

You cannot be a thin layer over someone else's model

The second thing I said plainly is that you cannot just be an AI wrapper. There are a lot of startups that have raised a great deal of money while doing little beyond sitting on top of a large model. That does not hold up. The things that protect a company are the things a model provider does not have: your own data, your own workflows, and a product where AI is built into the work itself, not attached on the outside.

One member shared something he has seen repeatedly. A company announces a product built on the big models and signs its first few customers, and everything works. Around the fourth customer, problems start. Data from one user leaks into the answers of another, suggested features from one account start showing up in a different account, and the team stops sleeping. He said he has seen it often enough that he now asks founders a simple question when they say they have gone live: how many customers do you have, and did the fourth one break things? His conclusion was that the wrapper businesses are the ones that will fade, and that the companies with real engineering behind them will last.

• Own something the model does not. Proprietary data, workflow depth, and integrations with how customers actually work are harder to copy than a prompt.
• Isolate customer data. Multi-customer leakage is a product risk and a legal risk. Design your tenancy carefully before you scale.
• Build the harness. The same member said you need a solid layer around the model that enforces rules, handles edge cases, and puts limits on usage.

The marketing founder who asked the original question added something helpful here. He said that even as the technology improves, there is still a need for human expertise to adopt it. A company that pairs technology with a service, he concluded, is better protected against the changes coming in the next few months than one that only ships software.

Build where the labs are not going

That founder's main problem was deciding where to focus. The big AI companies are putting most of their effort into execution, meaning agents that do the work a person would have done. His company had been building in the same territory, and each time the labs released something similar, he lost ground. So he moved toward the intelligence layer: the process of collecting the right information at the right time, asking the right questions, and feeding useful context into whatever interface the customer prefers. He expects his own interface to matter less over time and wants his product to sit underneath the tools people already use.

He also has a guess that one AI interface will win, and that most people will use it to manage their entire life and all their agents. If he is right, then the job for everyone else is to plug in. I would not bet my company on any single interface winning. I would, though, bet that being available inside the interfaces where people already work matters more than getting them to visit your site.

• Look for gaps, not races. When a big lab ships something, ask whether your product still has a reason to exist. If not, move toward the layer they are unlikely to build.
• Be present where users already are. Build integrations with the assistants your customers use every day, rather than asking them to log in somewhere new.
• Stay close to a domain. Deep knowledge of one market is hard for a general model to match and easy for you to keep growing.

Rebuild how you build

The last piece of my argument concerns your own development process. We have to integrate AI into how we code, into how we design our products and their onboarding, and into the product itself, and I mean more than a basic chatbot. The goal is real intelligence and real judgment inside the workflow. If we do not redesign both our products and the way we make them, then, as I said on the call, we may as well sell our companies in the next nine months and go home. That was partly a joke and partly a warning.

I shared an example from another founder in our community that still surprises me. His customers submit feature requests in Slack. An AI agent picks them up a few minutes later, builds the feature with no human involved in the drafting, and code is pushed to production about thirty minutes after that, without a human review. A process that used to take nine months to prioritize, specify, and build now takes about an hour. Another member was skeptical, noting that most people he knows are paying heavily for tokens, and that a setup that cheap was surprising. It is fair to be cautious. It is also fair to notice how quickly the ceiling has moved.

• Shorten the feedback loop. Measure how long it takes from a customer asking for something to that customer using it. Then cut it in half.
• Let AI into design. Use it for UI and UX exploration and for the onboarding flow, since those are where a fresh set of eyes helps most.
• Think about voice. One member noted that people are being trained to talk to software. He is building a landing page with his marketing manager just by speaking to an assistant, and he is asking how his own application could work the same way.

The voice question deserves care. Natural speech brings slang, accents, and regional language, and that can produce unexpected answers. It also invites long requests that trigger a lot of backend queries, which is another reason to set limits before you ship.

What to do in the next quarter

If you run a SaaS company, there is a short list worth acting on now. Make your core actions available to agents through an API or MCP and test them with a real agent. Start modeling what your pricing looks like when usage and outcomes matter more than seats. Write down what you own that a model provider does not, and invest there. And shorten the path from customer request to shipped feature by putting AI into your build process.

Further out, the frontier is physical. I expect industrial automation and robots connected to AI to arrive over the next four years or so, and I find that both exciting and a little scary. For the next nine months, though, the job is simpler. Get your software ready for users who are not people, and do it before your competitors do.