Don't Buy a Chatbot

Most SaaS software you pay for works the same way. You put your data in, the vendor does something useful with it, and you look at the result through the screens they built. The data is yours on paper. In practice it lives on someone else's servers, and the only way to use it is the interface the vendor chose to give you.

Over the past year nearly every one of these products has grown a chatbot. You can now ask questions in plain language, which is useful. But your questions rarely fit inside one product.

Ask about a customer and the answer might depend on deals in the CRM, unpaid invoices in finance, and open tickets in support. Each bot sees its own slice. So you ask three bots three questions and carry the answers between them yourself.

You are the integration layer.

Three products, three bots, three partial views of your business.

A better deal: a door for my agent

For individuals and small teams, running your own data infrastructure is out of the question. The useful next step is to let your own assistant connect to the services you already use. Vendors can enable this by publishing an MCP server: a standard interface that AI agents can connect to. Your own agent, whichever one you like to use, connects to each of your services and does the carrying for you.

Your agent talks to each service through its MCP server and does the joining. The data still lives with the vendor.

Notice what changed and what did not. The data still lives with each vendor. You still depend on them keeping that door open. But the assistant is yours, it sees everything you have granted it, and the vendor no longer has to build a chatbot frontend or pay for the model behind it. That is a good deal for both sides, which is why we expect it to become the norm within a couple of years.

If you have infrastructure of your own, ask for the data

Connecting your agent to each service solves the carrying. For a company with its own data platform, the next question is where the joining should happen.

Every system you buy should hand its raw data over to you, continuously and in a usable form. The data platform joins them into a coherent whole. On top of that you build a semantic layer. It describes what a customer is, what an order is, what a machine or a shift is, and how they join across sources. That work gets done once. Every agent, report and application you build afterwards starts from the same coherent picture.

Raw data flows from every vendor into your own platform. The agent works from the combined picture, under your access rules and your definitions.

Now the agent works completely on your side of the line. It talks to the one place that already holds the combined truth, with your access controls and your definitions. The SaaS products still exist and still do their jobs. They have simply stopped being the place where your data is stuck.

What to ask the next vendor

When the next vendor demos their assistant, ask whether your own agent can connect directly, through an MCP server or an equivalent open interface.

If you run a data platform, ask a second question: can the vendor deliver your raw data continuously, on a schedule, without an export button and a spreadsheet?

If both answers are no, the assistant mainly benefits the vendor. Your data is doing the work and their invoice is collecting the value.

At Pareto we build the platform side of this: the landing zone, the semantic layer, and the agents that run on top of them. If you are working out what to ask for in your next contract, we are happy to compare notes.