Data vs context: why automated systems still need humans

Automated systems still need humans because most of what runs a business is context, not data. Data is what happened: the order, the quantity, the date, the price. Context is what it means here: that this customer always orders short and calls the next day to increase it, that the discount on this line was agreed as a one off, that this account has quietly become the second largest in the region. Systems have been good at data for thirty years. Context is still held almost entirely in people.

So the reframe worth holding onto is this. Most companies do not have a data problem. They have a context problem, and the two look identical right up until you try to automate something.

What is the difference between data and context?

Data is the record. Context is the operating knowledge that tells you what to do with the record.

A row saying 24 units is data. Knowing that 24 is unusual for this account, that the last time the quantity dropped like that it was because someone ordered against the wrong contract, and that the buyer is covering for a colleague this month, is context. The row is in the ERP. None of the rest of it is anywhere.

This is why data quality projects so often finish and change nothing. The fields get cleaned, the duplicates get merged, the reporting gets faster, and the work still runs the way it ran before. The thing that was slowing the business down was never the accuracy of the fields. It was that the fields never held the reasoning.

Why do automated systems fail when the data is fine?

Because they are given the record and not the reasoning, so they handle the routine case and stall on everything else.

There is a real number behind this now. MIT's Project NANDA published The GenAI Divide: State of AI in Business 2025 in July 2025, based on more than 300 reviewed initiatives, 52 structured interviews and 153 survey responses. Its headline finding is that despite 30 to 40 billion dollars of enterprise investment, 95 percent of organisations saw no measurable return.

The more useful part is the diagnosis. The report attributes the failures not to weak models but to tools that do not learn, adapt or integrate, with no memory of what came before and no feedback loop from what happened after.

Read that as an operator rather than as a technologist and it is very familiar. It is the same complaint you would have about a new hire in their first week. They can do the task in front of them, they do not know the accounts, and they ask you the same question twice. The difference is that the new hire fixes that in a quarter, because the business teaches them without ever writing anything down.

What does this look like in a real business?

A components manufacturer, mid market, quoting from emailed requests for quote.

They automate the quote. It works. Requests come in, the specification is read, the parts are matched, a quote goes out in twenty minutes instead of two days. For about six weeks everyone is delighted.

Then a quote goes out at list price to an account that agreed a frame price in March. The agreement is real. It was signed off by the commercial director, and it lives in an email thread and in the director's memory. It is not in the ERP, because nobody enters frame agreements into the ERP, because until now nobody needed to. The customer is annoyed, someone reissues the quote by hand, and quietly the team starts checking every quote before it goes out.

The automation is now slower than the manual process it replaced, and nothing about it was broken. Every piece of data it used was correct. It simply did not know the one thing that mattered about that account, because the company had never put that thing anywhere a system could reach.

Where does the context actually live?

In inboxes, in phone calls, and in three or four people who have been there a long time.

That is not a criticism of how anyone works. Those are the only places flexible enough to hold it. A shared mailbox will accept "yes, do it this once, but not for the Manchester branch" without complaint. No ERP field has ever accepted that sentence. This is the same pattern as why your inbox becomes your order management system, and it repeats at every stage of the quote to cash cycle, not only at intake.

The risk is not that the information is wrong. It is that it is filed under a person. When they leave, or go on holiday in the week the audit lands, it goes with them.

What should you automate, and what should stay with a person?

Start where the context is already written down, and be honest about where it is not.

Automate the cases where the rule already exists in writing. A contract price in the ERP, a credit limit, a standard lead time, a customer who is always shipped from the same depot. These are safe because the reasoning is already recorded. Most of the volume sits here.

Capture context as a by product of the work, not as a data entry task. When someone approves an exception, the reason should be recorded next to the order because they approved it, not because they later filled in a form. Nobody has ever completed the form.

Route exceptions with their history attached. Good exception handling in order processing is not a queue of blocked items. It is a decision arriving in front of the right person with the account history, the last three similar cases and what was decided then.

Keep the decisions that set precedent with a human. Whether to hold a shipment, whether to honour a price that was agreed verbally, whether to extend terms to an account that has started paying late. These are not hard because they are complicated. They are hard because they create the next rule, and rules should be made deliberately.

Do not try to load everything the business knows up front. That project has a name, it takes eighteen months, and it ends with a document nobody opens.

How does a system learn the context without a two year project?

It accumulates it, one resolved exception at a time.

Every time a person decides something the system could not, that decision is a piece of context that was previously unrecorded. If the decision and its reason are stored with the record, the system has learned something real about how this business runs. Do that for a few months and the exception queue shrinks on its own, not because the automation got cleverer, but because the company finally wrote down what it already knew.

That is a slower story than replacing the work outright. It is also the only version that survives contact with a real order book.

The takeaway

Automation does not usually fail because the data is messy. It fails because the data was never the thing running the business. The operating layer, the rules, the exceptions, the promises made in threads, is what actually decides what happens to an order, and almost none of it has ever been written down in a place a system can read.

So the goal is not a system that needs no people. It is a system that handles the part where the reasoning is already known, and spends your people's attention only on the part that genuinely needs judgment.

That is the part Elentaria works on: running the routine against your rules, and putting the exceptions in front of the person who should decide, with enough history attached that deciding takes a minute.