The CTO’s Next Customer
How the zero-interface revolution will make your SaaS product obsolete — unless you rebuild it for the right user.
The Lobster That Broke My Brain
It is a Thursday evening and I am sitting at my kitchen table with a cup of coffee going cold next to my laptop. I have been hearing whispers about OpenClaw for a few days now. An open-source agent that lives inside your WhatsApp or Telegram. Created by Austrian developer Peter Steinberger, released quietly in November 2025, and now — in early 2026 — amassing over 182,000 GitHub stars and 30,000 forks. I decide to spend an hour with it.
I get it running. And then I spend the rest of the evening testing it.
I type: “Check my calendar for tomorrow and tell me if I have back-to-back meetings.”
And it does it.
I type: “Draft a quick summary of the last three emails from my CEO.”
And it does that too.
I type: “Find the GitHub issue where we discussed the authentication refactor and pull the key decision.”
Done.
I sit back. The coffee is cold. And I realize something. For the last two hours, I have been getting work done. Real work. Calendar checks, email triage, repository searches, task creation. And I have not opened a single application. Not my calendar app. Not my email client. Not GitHub. Not my task manager.
I have just been texting. An assistant that lives on my own machine, connects to the services I already use, and executes whatever I describe in plain language.
My brain does not feel disrupted. It feels embarrassed. Because I realize I have spent 30 years building products with buttons, forms, menus, and onboarding flows — and the most powerful thing I have used in months has none of that.
Why people are losing their minds over the claw
The world’s AI Tik Tokkers are marveling at OpenClaw’s impact. And yes, it is a simple architecture. A local gateway running a WebSocket control plane, connecting an LLM of your choice to the messaging apps you already have on your phone. No new surface to learn. No subscription to a separate product. The model is agnostic — Claude, GPT, DeepSeek, or something running entirely local on a Mac Mini in your office.
But that’s not the interesting part.
The interesting part is why people are losing their minds over it. Not just developers. People. Non-technical users are saying things like “this is my iPhone moment” and “I got up and running and I’ve been blown away.” One user described having their agent submit health reimbursements, find doctor appointments, and surface relevant documents. Another had their instance autonomously write code, run tests, and open pull requests — all without human prompting.
That enthusiasm has a shadow. In February 2026, Cisco’s security team found a third-party OpenClaw skill performing data exfiltration and prompt injection without user awareness. Researchers disclosed CVE-2026-25253 — 42,000 exposed control panels across 82 countries, 386 malicious skills in the community marketplace. One OpenClaw maintainer warned that the project is “far too dangerous for casual users.” An agent that can do anything is only as safe as the boundaries you define for it — which is precisely the argument for building MCP servers with deliberate, scoped permissions rather than handing agents a raw API key and hoping for the best.
Now, if you are a CTO of a 60-person engineering team in a regulated industry, you may be thinking: my customers are nowhere near this. Their procurement teams, their compliance officers, their enterprise security reviews — none of them are ready to let an agent loose on their SaaS stack. And you would be right, today. Enterprise adoption of agentic workflows will lag this developer enthusiasm by three to five years, easily.
But that’s not the question worth asking. The question worth asking is: what does it tell you about where the gravity is pulling?
What is actually happening with OpenClaw is not a new AI model or a clever piece of infrastructure. It is the first widely-adopted proof that you can eliminate the interface entirely from daily work. For thirty years, software has charged users a tax — the cost of learning the product. Every SaaS you have ever built asks your users to pay it. They navigate your UI. They learn your vocabulary. They figure out where the filter is. They go through your onboarding. They submit a support ticket when they can’t find the export button.
OpenClaw collects no daily tax. Once it is running, you never open another app. You describe what you want in the language you already speak, and the system figures out the rest. Calendar, email, GitHub, task management, file searches — all of it happens through conversation. What people are mesmerized by is not artificial intelligence. It is the elimination of every learned behavior they had to acquire to use software. You never navigate someone else’s information architecture again. You never hunt for a feature. You never click through three menus to export a CSV.
You just ask.
We Have Seen This Movie Before
Cast your mind back to 2004. Salesforce had been quietly building APIs since day one in 2000, and they had just turned “Software as a Service” into “Platform as a Service.” Today 90% of Salesforce’s revenue flows through their API.
Twilio launched in 2008 with a single API for making phone calls. By 2018, that had grown to $129 million in quarterly revenue — up 48% year-over-year. Stripe turned payment processing into seven lines of code. By 2015, APIs were responsible for over 60% of all web traffic.
What drove all of it? Someone removed a tax that developers had been quietly paying for years — the cost of standing up your own infrastructure for common problems. Twilio didn’t invent telephony. They made telephony stupid easy to integrate. Stripe didn’t invent payments. They made payments stupid easy to integrate.
Crucially, Twilio and Stripe were API-first from inception. They didn’t have fifteen years of UI-coupled architecture to unpick. They built clean, predictable surfaces and made other systems dependent on their data. That dependency became their moat.
The CTO thinking about agent-native architecture today is not Twilio. They are the enterprise product that watched Twilio emerge and had to figure out what to do with an existing monolith. That is a harder and more honest problem. And it is the problem worth solving.
Your SaaS Has the Wrong Customer
The assumption baked into every SaaS product built in the last twenty years is that a human being will open a browser tab and interact with it through a mouse or a touchscreen. Every design decision you have ever made — your navigation, your information architecture, your feature discoverability, your mobile experience — exists to serve that assumption.
That assumption is cracking.
Anthropic just launched Cowork. OpenAI has its own agentic surfaces. Every major platform is racing toward agent-native workflows. In these models, the thing that integrates with your SaaS is not a person. It is an agent. And agents do not click. They call APIs. They consume structured data. They act on outputs, not on visual interfaces.
Ask yourself: if an agent were your primary user tomorrow, how much of your product would be completely invisible to it? Your beautiful onboarding flow? Gone. Your carefully crafted dashboard? Irrelevant. Your contextual tooltips? Wasted. The agent goes straight for the data and the actions. Everything else is noise.
A simple test: if an agent called your product’s API right now, would it get back structured, actionable data — or frontend scraps? The answer tells you more about your architectural readiness than any roadmap review.
This is not a reason to abandon your UI. Your human users still need it, and will for years. But it is a reason to ask a design question you have probably never asked: is my business logic separable from my visual layer? In a well-architected product, the answer should be yes. If your core functionality is tightly coupled to your frontend — and you would be surprised how many products at scale have exactly this problem — then every agentic integration you try to build will be fighting your own architecture.
The CTOs who will win the next decade are the ones who recognize this now, while they still have time to do something about it without a crisis forcing their hand.
The Protocol That Changes the Question
This is where MCP, the Model Context Protocol, Anthropic’s open standard for connecting agents to data sources, enters the picture. OpenClaw is built to integrate with MCP servers. So is Claude. So is every agent framework worth paying attention to right now.
MCP servers are to agents what APIs were to the Web 2.0 ecosystem. A standardized way for an LLM-powered agent to reach into your product, retrieve your data, and take actions on behalf of a user. When Salesforce opened their API, they were betting on ecosystem stickiness: get other systems dependent on your data and your logic, and you become infrastructure. The agent workflows that integrate your MCP server will become dependent on your data in exactly the same way.
A concrete example: Notion published an MCP server. Now an agent like OpenClaw can create pages, update databases, query your workspace, and surface documents — all without a human ever opening Notion’s UI. Notion’s data became reachable by automated workflows that their product team never had to design or build.
That’s the bet. Not replacing your product. Making your product’s value available to users who have stopped using interfaces.
The Practical Path
You do not need to rebuild your entire product. But you do need to be honest about what the work involves.
The first step is a design conversation, not a technical one. Draw a line between what your product does and what your product shows. The “does” layer, your business logic, your data mutations, your integrations is what agents need. It should be cleanly separable from your visual layer. If it isn’t, you are looking at non-trivial architectural work. Not a rewrite, but refactoring that will require real engineering time. Go into that conversation with your team clear-eyed about the cost.
Second, think about your data as a platform. The API economy taught us that the most durable businesses were the ones whose data other systems needed to function. Plaid doesn’t have a consumer-facing UI to speak of. It is pure data infrastructure. Your product almost certainly has unique data that agent workflows will eventually need. Decide now who should be able to reach it, and under what conditions.
Third, publish an MCP server. Start small. Pick your three most valuable actions, the things your power users do most often and package those as callable tools for an agent. This is exactly how the API economy started. Twilio put a few phone call actions behind a simple endpoint and watched what developers built. The developers who integrated early became dependent on Twilio. The same stickiness applies here.
The honest caveat: if your product’s core logic is tightly coupled to your frontend, step three will be harder than it sounds. You will hit the architectural problem before you hit the MCP server. That is useful information. It tells you something about your codebase that matters beyond agents entirely.
The Last Time We Were Here
There is a generation of CTOs who lived through the Web 2.0 API explosion and watched their competitors who moved early become platform companies. The ones who waited became integrations: dependent on platforms for distribution, at the mercy of their pricing decisions.
OpenClaw crossed 182,000 GitHub stars in under two months. It has been adapted for Chinese super-apps running on DeepSeek. SwitchBot just launched what they call the world’s first local home AI agent with native OpenClaw support. This is moving faster than most of us want to admit.
The zero-friction interface is not a distant trend. It is a working product that people are using right now to automate their lives by texting in plain English. Your enterprise customers may not be there yet. But the developers building tomorrow’s enterprise workflows are experimenting with this today. And the products that are agent-ready when that demand arrives will look an awful lot like infrastructure.
The agent era will sort companies the same way the API era did — into platforms and integrations.
Build the MCP server. Make your data reachable. Separate your logic from your UI.
Don’t become the integration.
With Love and Respect for you
Etienne
Are you rebuilding your SaaS architecture with agents in mind? I’d love to hear how you’re thinking about it. Email me directly or join one of our 7CTOs peer groups where CTOs are wrestling with exactly these questions.