Just use AI and it will fix anything

A paying customer of a large accounting platform, writing on an Australian review site, described trying to lodge a support case and finding a chatbot standing between them and a human being. Not a chatbot that answered the question. A chatbot that occupied the doorway.

That customer is not against AI. Neither are the owners who describe features being made harder to reach, or support that stops answering. What they are against is a business that bought a capability and pointed it at the wrong end of its own operation, and it is worth being precise about why that happens, because the same mistake is available to every business reading this.

Two kitchens

Picture two identical commercial kitchens, mirror images of each other. Same benches, same ovens, same knives. Each is handed the same recipe and the same crate of ingredients. Into one goes a very competent home cook. Into the other goes a three Michelin star chef.

Same platform, same ingredients, same conditions, same rules, same recipe. The two dinners that come out are not close.

Nobody would look at that and conclude the kitchen was the variable. Yet that is the whole of the argument when a business decides that buying access to a model is the same as having built something with it. The model is the kitchen. It is necessary, it is not scarce, and your competitor has the same one. What separates the two dinners is everything the chef brings to a kitchen that is not the kitchen.

For a business, those things have names. The corpus: what the system is allowed to know, which is your material and nobody else's. The rules: what it must do, must never do, and must hand to a person. The persona: how it speaks, to whom, and in what register. And the plumbing: where it reads from, where it writes to, and what happens when one of those is unavailable. In the way we build, the corpus, the rules and the persona are held as data rather than written into code, and the shell around them is shared. That is a deliberate boundary, and it is the reason a configuration belongs to the client who paid for it.

What bolting it on actually does

The chatbot in the support doorway is what happens when a business treats the model as the product. There is a real capability there, and it has been pointed at deflection rather than at resolution, so the only measurable outcome is fewer cases opened. Cases not opened is not the same as problems not had, and the customer can feel the difference immediately.

The same pattern turns up inside businesses. A summarising feature is added to a system nobody trusts, over data nobody has reconciled, and it summarises confidently and wrongly. An assistant is given a corpus that includes three versions of a policy and no way to know which one is current, so it answers with whichever it happened to read. In each case the model behaved exactly as designed. Nothing around it was designed at all.

The failure is not that these businesses used AI. It is that they skipped the four things above and went straight to the kitchen.

Which end you point it at

The useful question is not whether to use AI. It is which job you are handing it, and there is a straightforward way to sort that.

Point it at work where the answer can be checked. Reading fifty supplier invoices a week and proposing the line items against a purchase order is checkable, because a human approves the match and the ledger disagrees loudly when it is wrong. Reading a long document and pulling out the dates and obligations is checkable, because the document is still there. Drafting the same report every month from the same feed is checkable, because the figures either reconcile or they do not.

Be careful handing it work where the answer cannot be checked, or where the cost of a confident wrong answer lands on a customer rather than on you. Standing between a paying customer and a person is the clearest example of that, which is why it reads so badly to the people it happens to.

Where your material sits

The reason those questions matter is that a corpus is the part you cannot get back. Rules can be rewritten and a persona retuned in an afternoon. The body of material a system reasons over is years of your business, and once it has been used to improve somebody else's model there is no undoing it.

So the architecture question and the AI question are the same question. Where the material sits, who can reach it, what it is used for beyond answering you, and what happens to it when the relationship ends. We build inside a client's own tenant for reporting work, and we run our own Australian hosted models wherever personal or sensitive material is read, precisely so that those have concrete answers rather than reassuring ones.

What this means for a business considering it

The kitchen is not the hard part and it is not the expensive part. The corpus has to be gathered and cleaned. The rules have to be written down by someone who knows the business, which is usually the person with no spare hours. The plumbing has to be built and has to fail loudly. The persona has to be agreed. That work is unglamorous and it is the entire difference between the two dinners.

It is also work that can be scoped before anyone commits to a build, which is what an engagement opens with: what your material actually is, what the rules would have to be, and which jobs are checkable enough to hand over.