Your support bot can answer questions. Soon it'll need to resolve them.

A customer lands on your site at 11pm. They type: "Where's my order? It said delivered but I don't have it."

Almost every AI support tool on the market today — including the early version of most of them — will respond with something like this:

"I'm sorry to hear that! Orders are typically delivered within 3–5 business days. If your tracking shows delivered but you haven't received it, please wait 48 hours and check with neighbors, then contact us at support@..."

That answer is correct. It's pulled cleanly from your help docs. It's polite, instant, on-brand. And it's almost completely useless to the person asking, because they didn't want the policy. They wanted their order.

This is the wall. Every support bot built on "train it on your documents" hits it eventually, and it's worth being honest about why — because the gap between answering and resolving is about to become the whole game.

The doc-trained chatbot is a commodity now

Two years ago, "upload your docs and get a support bot" was a genuinely impressive product. Today it's a feature you can bolt onto almost anything in an afternoon. The models are good, retrieval is a solved-enough problem, and a dozen tools (ours included) will happily ingest your help center and start answering questions by lunch.

That's not a knock. It's just the reality of where the floor moved. When everyone can do the thing, the thing stops being a differentiator. A support bot that answers questions from your documentation is now the minimum, not the edge.

So the interesting question isn't "can it answer?" anymore. It's: what happens when answering isn't enough?

Answering vs. resolving

Walk through what your support team actually does on a normal day. A surprisingly small slice of it is reciting policy. Most of it is doing things:

• Looking up where a specific order is right now
• Checking whether a particular account is on the right plan
• Issuing a refund, or starting one
• Updating a shipping address before the package leaves the warehouse
• Pulling a customer's last three tickets to understand context
• Creating a ticket in the system and routing it to the right person

None of that lives in your documentation. It lives in your systems — your store backend, your CRM, your billing tool, your order management system. A bot trained on your docs has no idea any of that exists. It can describe the refund policy beautifully. It cannot issue the refund.

That's the line between answering and resolving. Answering is reading. Resolving is acting. And the entire value of support — the reason a customer contacted you at all — is almost always on the resolving side.

The next generation of support AI is the part that crosses that line.

So why hasn't every tool just done this already?

Because connecting an AI to live systems used to be genuinely painful.

The old way was custom integrations: a hand-built connector for Shopify, another one for Salesforce, another for Zendesk, another for your homegrown internal tool that one engineer wrote in 2021. Each integration was its own project — its own auth, its own quirks, its own maintenance burden. Every new system you wanted the bot to touch was weeks of engineering. And every time one of those systems changed its API, something quietly broke.

This is why most "AI support" tools stayed on the safe side of the line. Answering questions from docs is easy and uniform. Acting on a dozen different backends is hard and bespoke. So the industry mostly didn't, and called the easy version "done."

That constraint is what just changed.

Enter MCP, in plain terms

MCP — the Model Context Protocol — is an open standard for connecting AI to external tools and data, originally introduced by Anthropic and now broadly adopted across the industry.

Strip away the jargon and it's a simple idea: instead of building a fragile one-off integration for every single system, MCP gives the AI a standard way to plug into things — to read live data and take actions through a common interface. Think of it as a universal adapter between the model and the rest of your stack. The same way USB meant you stopped needing a different cable for every device, MCP means an AI agent stops needing a different custom integration for every tool.

For the AI, the difference is night and day. Before, "knowing about your order system" meant someone shipped a custom Shopify connector. After, it means the agent can speak a shared protocol that the order system already understands. Connecting a new tool goes from a multi-week engineering project to something closer to flipping a switch.

That's the unlock. The hard, expensive part of crossing from answering to resolving just got dramatically cheaper.

What this looks like for support specifically

Go back to that 11pm customer. The doc-trained bot recited the policy. Here's the same moment with an agent that can actually reach into your systems:

"I can see order #48213 here — it was marked delivered at 2:14pm today to the front porch. I've opened a delivery investigation with the carrier and emailed you the claim reference. If it hasn't turned up in 24 hours, I've already pre-approved a replacement so you won't have to ask twice."

Same question. Completely different outcome. The customer didn't get information about their problem — they got their problem handled. No human touched it. It's 11pm.

That pattern generalizes across almost everything support does:

• "Am I being charged for the right plan?" → the agent checks the live billing record and tells them, instead of explaining how plans work in general.
• "Can I change my shipping address?" → the agent updates it directly if the order hasn't shipped, instead of telling them to email support.
• "This is the third time I've contacted you about this." → the agent pulls the prior tickets, sees the history, and escalates with full context, instead of asking them to explain it all again.

Every one of those is a resolution a doc-trained bot structurally cannot perform — and a resolution an MCP-connected agent can.

Why this is the real moat

Here's the strategic part, and it's the reason we think this matters more than another round of "our bot answers questions better."

A bot that answers from your docs is easy to replace. There's nothing sticky about it — a competitor can ingest the same docs and produce the same answers. Switching costs are basically zero.

A bot that's wired into your stack is a completely different story. Once an agent is connected to your order system, your CRM, your billing, your ticketing — once it's genuinely doing the work across your tools — ripping it out means unwinding all of those connections and rebuilding them somewhere else. The deeper the integration, the higher the switching cost, and the more valuable the agent becomes the longer it runs.

That depth is the moat. Not the model. Not the doc training. The integration layer — the part that turns a chatbot into something that operates inside your business.

And MCP is what makes building that layer realistic instead of a forever-project.

Where we're headed

We'll be honest about where the whole category sits today, ourselves included: most of the value shipping right now is still on the answering side. Ingest your docs, your site, your help center, answer customers instantly, capture the leads you'd otherwise miss. That's real, and it's where InsiteGPT lives today.

But it's the floor, not the ceiling. The direction we're building toward is the resolving side — an agent that doesn't just know your documentation but plugs into the systems your team actually works in, and handles the things that today still require a human to log in somewhere and click around. MCP is the path that makes that practical, and it's where we think the durable advantage in this category is going to be.

The support tools that win the next few years won't be the ones with the best answers. They'll be the ones that stopped answering and started resolving.