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 it may be 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?

A question that never gets answered quickly is usually 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.

The honest order is to do this to your own internal systems first, where a wrong answer costs you rather than a customer. An operations team can expose its automations over MCP as a small set of tools: what ran, what it touched, and what it cost in model spend. Then someone can ask what every workflow did yesterday and what it cost, instead of opening the dashboards one at a time.

Is this just a faster report builder?

No, and this is the part people tend to 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 most of the enthusiasm deserves some pushback.

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 to insist on before connecting anything.

The data has to be provably correct, not assumed correct. Take a warehouse system that 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 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. A useful one snapshots a baseline and fails on new violations only. It answers the question you can act on: did this change make it worse? That beats a green tick nobody believes.

Writes have to be gated and attributable. Reading is low risk. Changing a record is not. The gate should not be a policy in a document, it should be a type in the code: for example, 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. Any automated step that touches money or reaches a customer needs a named human on the other side.

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 would 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 would not let anything activate ad spend without a human click.

We would 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.