People are picking Claude, ChatGPT, or Grok as their day-to-day efficiency pill. Your software used to be the main place they’d go to get work done, but they also had to use a pile of other tools: office tools, ad tools, billing tools. Most of them either figured out ways to move data back and forth by hand or set up integrations and automations as needed, and either way they were stuck being the ones connecting everything inside their company.
Building AI into your tool assumes they’ll keep treating your tool as the primary place they work, and they wanted AI functions in there like the ones they’d seen other people using. That was AI wave 1.0, and it was a real improvement on what was already there. It lets people do things more efficiently inside your software. What it doesn’t let them do is connect that AI to their other systems. The context is isolated. It’s a separate sandbox, and it feels disjointed once the rest of their tools are already connected in their AI flows.
So you want your platform in their AI. When they talk to Claude or ChatGPT and ask about something that lives in your platform, the agent should be able to reach into your platform directly, give them exactly the right information, and make the change for them, securely, without breaking their workflow.
I’ve been writing around this idea since April, when I said the app was becoming less of a destination. That paragraph above is the version I’d say to a friend who runs a small software company and doesn’t follow any of this.
Why I’m doing this now
I’ve always wanted to go out on my own. It’s been a goal for as long as I can remember, going back to right after college. The fear was always that I’d fail, so I needed more experience first. I worked at a series of companies and picked up that experience, and as I took on more responsibility I got good at my job. That meant moving up the ladder, which made the jump that much riskier, especially after getting married and having kids. Eventually it felt like a risk too great to take.
The last couple of years in the Triangle entrepreneurship scene, working with people like Scot Wingo, helped me figure out how I could actually do it. The risk doesn’t feel as great as it used to. Not because it isn’t risky, but because I trust that everything I’ve built my career on will serve me well in what comes next. And the AI wave has accelerated things to the point where I’m doing things I never thought possible. It feels like the early days of the web in the early 2000s, when everything was moving very fast. I felt like I missed that wave because I was too scared to go out on my own. I’m not going to make that mistake twice.
So after a year and change as CPTO at PtEverywhere, I’m stepping out of the day-to-day and staying on as a strategic advisor, and I’m going full-time on Limeade Labs. The practice is about helping software companies figure out how their products should work when agents become the customer’s primary interface. Some of that is putting AI to work inside a company’s own stack. More of it runs the other direction, putting the product’s value inside the AI tools its customers already use.
What I learned building it the first way
At PtEverywhere the AI story started as a simple support chat agent, built on HubSpot, later refactored into a standalone agentic support framework that made real MCP tool calls against the application. Once we saw how quickly it could find answers, the obvious question was why our users should have to go through us to get them. So we started building some of that directly into the app.
That’s where it got harder. Putting a tool in front of your customers is different from putting it in front of your support team. Internally we’d work around shortcomings or know when to double-check something. Customers have high expectations. It has to work well, you have to present something they can depend on, and you have to call out the shortcomings if there are any.
The bigger lesson was about the API. Ours was very large, with a lot of endpoints that powered specific screens and views, and that made it very difficult to build agent flows around. There were too many endpoints to call. So we started bundling them into functionality flows, and the MCP layer let us introduce tool sets aimed at high-value outcomes: the quick change, the thing someone needed to set up for a patient, solved in one step instead of clicking through several screens.
What surprised me was how many therapists started asking the agent to do things we’d never intended to build tools for. We had good metrics on every request the agent couldn’t handle, and before long we had a list of new places to build MCP tools, sorted by how often people were trying to do that workflow.
The agent can only do what you can do
One rule shaped the design early. The MCP couldn’t let a user do something through the agent that they couldn’t do themselves with their own roles and permissions. The agent is authenticated into your exact permission set, with the same boundaries you have. If you can’t change a setting, the agent can’t change it for you. Someone who can change it could use the agent to do it.
That sounds simple. Paul Graham has an essay called “Schlep Blindness” about how good ideas go untouched because the tedious work around them is invisible until you’re standing in it, and this is where the tedious work lives. Wrapping an API is a week. Making sure an agent inherits exactly what a person is allowed to do, across every role and exception that’s accumulated over years, is the schlep. It’s also the part customers will never forgive you for skipping.
Nobody wants to learn to cook the fish
I’ve said this to enough people that I can’t track down where I first heard it. If you go to a restaurant, you’re paying to be served a good meal. You’re not there to learn how to cook one. Self-service software expects customers to come to you and learn to cook. They want the problem solved.
In earlier SaaS eras, tools got popular because they gave people better ways to solve their own problems. With AI there’s no reason to stop there. We need to solve the problem completely, all the way to the end, or it’s just another tool they don’t have time for. And if they’re not going to reach for your tool, they’ll reach straight for the AI and have it solve the problem end to end. So how does your product fit into that? Your platform needs to give the AI a better way to solve that problem on the user’s behalf. Make software that an agent chooses to use.
Where MCP fits
I don’t think MCP is dead. An API or a CLI can work great, and where those exist that’s what a lot of people are going to connect their AI to. What gives MCPs a bad name is the knee-jerk version: we need an MCP for distribution, so wrap the whole API. The moment an agent connects it pulls way too much context about every tool and how to use it, and it breaks.
A well-designed MCP only shows the tool sets an agent needs for the task in front of it. You can split them up. A big platform might have invoicing, clinical areas, and marketing all in one system, but not everyone using AI with it needs every tool, so give them separate MCPs that can hand off to one another. A poorly designed MCP is worse than a CLI or an API. Checking the box is not an improvement.
Not everything needs inference either. A lot of tasks want a deterministic, programmatic flow, and the efficient move is letting the AI decide which deterministic flow to call rather than reasoning its way through every step. Just because an AI can do something doesn’t mean it’s the right tool for the job.
How many companies have done this work? Proven, which scores B2B SaaS vendors on agent readiness, has looked at more than 510 of them, and roughly 1% score above 70. Every number in this category comes from someone selling into it, so I’d treat the decimals as marketing, but the direction matches what I see.
Try to use your product from inside their AI
This is how I first figured out what we should build. I’d try to do something through an AI, and everywhere it failed I knew we had to build better functionality. For PtEverywhere, at the start, it was pretty much nothing. The AI couldn’t log in, couldn’t get to any of the data. It could use browser mode if you logged in for it, then click around, but that’s slow, it isn’t built for repeated flows, and a UI designed for people confuses an agent.
The stack Limeade Labs runs on went the other way. I built it MCP-first, so I don’t think I ever tried it without AI. The tool didn’t exist before AI. The whole platform was written from the perspective that the primary interface would be other AI tools. There’s a UI, and I use it from inside those tools as a better viewer for documents and for status views of agent sessions, but it feels like a tool inside ChatGPT or Claude rather than a place you go.
If you run or lead product for a SaaS company, do the same test. Open ChatGPT, Claude, or Grok and try to use your product from there. Skip the marketing site and the docs. Ask the agent to do the job your customer is actually trying to do, and write down the first thing that breaks. That list is the work.
What would make me wrong
You could argue none of this is necessary. Let the agent use browser mode and drive the UI, and the models will keep getting better at it, which is true. The newest releases, Astra especially, are showing browser mode working more and more often. But I’ve always been able to use browser mode with the different models. What’s new is that Astra does it well for a user who doesn’t know how to prompt the right steps. It’s a game-changing model, and a UI is still the slowest mechanism an AI can operate against. Just because something can work that way doesn’t mean that’s the way it should.
And if an agent is comparing tools to solve a task for a new customer, it may pick your competitor because they provide a clearer, easier MCP to get the job done. I think we’re close to an era where users don’t sign up for your software directly. An agent decides to sign up on their behalf and uses it for them. That sounds a little far-fetched. I already see agent sessions go out, suggest tools, and open an account for me when they can do a task better through that tool than on their own.
That’s the work I’m doing now through Limeade Labs. If you run the test above and want to compare notes on what broke first, reach out here, or via my website. I’d like to talk through it.
MCP design could be a huge field in itself. Data pull from MCP should be pointed and its use case should also be. This is a classic context engineering case where the agent gets overloaded witb context beyond its scope.