Your business software should be a tool your AI can use

Most business software was designed around a person clicking. Thirty years of ERP, POS and warehouse systems have trained us to accept that if you want to know something, you find the screen, set the filters, and read it. If the screen does not exist, you file a ticket.

That assumption is now optional, and I think it is the most underrated change happening in enterprise software this year.

What actually changed, and why it is not another chatbot

The change is a protocol, not a feature. MCP, the Model Context Protocol, is a standard way for an application to expose its capabilities to an AI assistant: here are the things you can read, here are the things you can do, here is what you need permission for.

Once your system speaks it, an assistant can use your software the way a colleague would. Not a chatbot pasted onto the corner of your dashboard. The actual system, with its actual data and its actual rules.

The difference matters. A chatbot bolted onto an app is a new screen. An MCP server is a new interface to every screen you already have, including the ones nobody ever built.

What does this look like in practice?

The question I could never answer quickly used to be a version of this: what is sitting in the warehouse that has not moved in sixty days, and what did we pay for it?

That question spans inventory, purchase history and landed cost. No report covered exactly that, so the honest answer was always "give me a day".

With the system exposed properly, it is a sentence. You ask, the assistant calls the right reads, and you get the answer with the numbers traced back to records you can open. Then you ask the follow-up, which is the part that never survives the ticket process, because by the time the report arrives you have forgotten why you wanted it.

At Cubitrek we did this to our own systems first, which is the only honest order to do it in. Our AI operations platform exposes itself over MCP: a set of tools covering the agents we run, their recent runs, the clients they belong to, the model routing behind them, and what they cost us in model spend. I can ask what every agent did yesterday and what it cost, instead of opening the dashboards one at a time. We have also published an MCP server for working across multiple Shopify stores under the MIT license, because the pattern is more useful to everyone if it is not proprietary. Our warehouse platform is next.

Is this just a faster report builder?

No, and this is the part I think people will underestimate.

A report is a question someone anticipated. The value of this shift is the questions nobody anticipated: the odd cross-cutting one you ask twice a year, the sanity check before a supplier call, the "is this number right" at eleven at night. Those questions never justify a development ticket, so today they simply do not get asked. The operational knowledge inside your own systems stays locked behind the cost of asking.

Lower that cost to a sentence and people ask more. That is the whole gain.

What has to be true before you let an assistant near your operations?

This is where I would push back on most of the enthusiasm, including some of my own.

An assistant is only as safe as the system underneath it. If your stock ledger does not balance, an assistant will now tell more people, faster, with more confidence. Speed is not a virtue on top of a system that is quietly wrong.

Three things we insist on before connecting anything.

The data has to be provably correct, not assumed correct. Our warehouse platform does not store stock as a counter. The source of truth is a lot and receipt ledger, and the per-product quantities everyone reads on screen are derived caches. A broken integration rarely throws an error. It quietly leaves the cache disagreeing with the ledger, and you find out at month end when the valuation is wrong. So we run an invariants harness against that ledger before and after any integration work.

One detail in that harness matters more than the harness itself. A long-lived database carries historical drift that predates any check you add, so a test that is red on day one gets ignored inside a week. Ours snapshots a baseline and fails on new violations only. It answers the question you can act on: did this change make it worse? I would rather have that than a green tick nobody believes.

Writes have to be gated and attributable. Reading is low risk. Changing a record is not. On the Shopify server we published, this is not a policy in a document, it is a type in the code: a mutation aimed at a store marked production raises an error unless the caller passes an explicit confirmation flag. The assistant has to look at what will change and say so before anything moves. Every automated step we run has a named human on the other side of anything that touches money or reaches a customer.

Somebody has to decide where the model is not allowed to go. This is the part that gets skipped, and the research is clearer than the marketing.

In a Harvard Business School and BCG field experiment with 758 consultants, those using GPT-4 completed 12.2 percent more tasks, 25.1 percent faster, at higher quality, across eighteen tasks chosen to sit inside what the authors called the jagged technological frontier. On one task chosen to sit outside it, consultants using AI were 19 percentage points less likely to produce a correct solution than those working without it.

A separate randomized trial by METR followed sixteen experienced open source developers across 246 real tasks in repositories they maintain themselves. They were 19 percent slower with AI tools available. Afterwards they estimated they had been 20 percent faster.

That last gap is the one to sit with. The border between where these tools help and where they quietly hurt is invisible from the inside, including to the people doing the work. That is not an argument against adopting them. It is an argument about who decides, and how often they check.

What we would not automate

We do not let a model decide what to work on next. Prioritization looks like a perfect AI task and is not: a confident wrong answer about sequencing costs a client relationship, and you find out weeks later.

We do not let anything activate ad spend without a human click.

We do not let an assistant write to a production system without an approval trail. Not because it will always be wrong, but because "usually right" is not a standard you can run an operation on.

Where should you start?

If you run on internal software, the first step is not buying anything. It is asking two questions.

First: what do people in the business ask for that no screen answers? Those questions are the business case, and they are usually already sitting in your support queue.

Second: would I trust an assistant to read from this system today? If the answer is no, fix that first. The connection is the easy part. The system being right is the work.

The companies that get value from this will not be the ones that adopted it first. They will be the ones whose systems were in good enough shape to be worth talking to.

Faizan Khan is the CEO of Cubitrek. Cubitrek builds and runs the software behind operations for clients in the United States, Europe and the Gulf, and publishes some of it as open source.