Skip to content

Expose capabilities, not a frontier model

I keep saying it, so I’ll say it again.

Embedding frontier AI directly into a SaaS product is one of the dumbest things you can do.

Don’t build out that way.

The stories of bad AI integrations are everywhere. Expensive chat boxes, features nobody asked for, and models bolted onto products because someone decided the roadmap needed more sparkle.

And that’s before someone discovers your order bot also works as a free code generator.

Once you embed frontier AI into your product, you also take on inference costs, model selection, rate limits, outages, moderation, prompt injection, unauthorized use, data leakage, abuse, and all the new attack surfaces created by putting an open-ended language interface inside your application.

That’s a much more expensive problem than securing a defined set of workflows.

Expose the capabilities

The better approach is to expose your product through MCP tools.

Users can bring whichever model, agent, or command surface they prefer, and pay for the intelligence layer themselves. The frontier labs can keep doing frontier-model work, while SaaS providers concentrate on their domain expertise, maintaining reliable data, managing permissions, and turning difficult operations into dependable workflows.

Security still matters. MCP tools need authentication, authorization, validation, sensible limits, and clear boundaries around destructive actions.

But the attack surface is smaller because your product exposes a finite set of capabilities instead of hosting an open-ended intelligence system inside itself.

An interface ordinary users can use

Last year, as MCP began rolling out, the obvious objection was that its main consumers were developers.

Developers, developers, developers.

Unless or until ordinary users adopted these tools, SaaS companies would still need integrated AI.

But today, products like ChatGPT and Claude Cowork are making tool-driven workflows accessible to people who will never know or care what MCP stands for.

They’ll ask for something in the interface they already use, approve the necessary actions, and expect the work to get done.

That opens these workflows to a class of nontechnical users we wouldn’t have seriously considered a year ago.

Tools have always been about people and what they can suddenly do.

Good tools are like falling in love a little.

They fit into your life. They do what they promised. And after a while, you can’t imagine working without them.

Don’t let your users down.