Where large language models earn their keep in a company

A company buys licences for a chat assistant for every employee. Six months later the picture is mixed. Some people use it every day for emails and meeting summaries. Most tried it a few times and stopped. Someone in finance asked it to reconcile two ledgers and received confident, well-formatted, wrong numbers. When the renewal comes up, nobody can say what it changed, and the decision is made on anecdotes.

The licences were not the mistake. The mistake was deploying a large language model as a general tool for everyone, instead of placing it at specific points in specific processes where its strengths match the work.

Those strengths are real and narrow. A language model is good at language: reading unstructured input, pulling structure out of it, drafting text, summarising, classifying, and translating between the way a person asks a question and the way a system needs to be queried. It is weak at exact arithmetic, at recalling facts it was not given, at keeping a consistent state across a long process, and at being accountable for a decision.

Where they earn their keep

Reading what arrives unstructured. Emails, inbound invoices, delivery notes, complaints and orders sent as attachments. The model turns them into structured fields, each with the passage it was taken from, so a person can check it in seconds. This is the front of the inbound invoice process in Hurukan’s Finance module: captured, coded, approved, exported.

Drafting for a person to send. Replies to customers, first versions of quotes, summaries of a case history before a call. The person edits and sends; the model saves the blank page. The Customer Service module is designed on exactly this rule: agents draft, a person sends.

Turning questions into queries. A manager asks why deliveries to one region are late. The model turns that into a query against a defined model of the business and returns the answer with the query shown.

Classifying and routing. Which team, which priority, which template. Narrow, repetitive and easy to check, which also makes it a good candidate for a smaller model.

Explaining a record. Why is this order on hold? The model reads the record’s history and writes three sentences a person can act on.

Writing changes to the system itself. A new field, a new rule, a new report, drafted by an agent as a change for a person to review. This is how Hurukan is meant to be extended: described, written by an agent, approved by a person, recorded.

Where they do not

Arithmetic and reconciliation. Use code. A model can write or call the code that does the sum, but should not do the sum in its head.

Facts it was not given. Without grounding in the company’s data, a model produces plausible text. What it is grounded in matters as much as the model, as argued in retrieval over the ontology.

Numeric forecasting. Demand, cash and capacity forecasts are a job for classical statistical and machine-learning models with a backtest, as explained in classical ML still beats an LLM at forecasting demand.

Final decisions with consequences. Payments, price commitments, contract terms, anything to do with people’s employment. The model prepares; a person decides.

Anything you cannot check. If an output cannot be verified cheaply, the cost of its errors is hidden until it is large.

How to place them

For each candidate use, ask four questions. Is the input mostly text? Can the output be checked quickly by the person receiving it? Is a mistake reversible? Who approves before anything leaves the company or changes a record? The good uses have text in, a quickly checkable result and a reversible mistake, with an approval wherever that last condition fails.

Then route each task to the model that fits it. Hurukan’s Super Intelligence layer is designed to do that per task, between frontier models and models running on the company’s own hardware, under rules about quality, cost and where data may go. Integrations with Microsoft 365 Copilot, Claude and ChatGPT are planned, not live.

A test you can run today

List the ten tasks that take the most time in one department each week. For each, mark three things:

1. The input is mostly text. Yes or no.
2. The result can be checked in under a minute. Yes or no.
3. A mistake can be undone. Yes or no.

Tasks with three yeses are where a language model is most likely to earn its keep. Tasks with a no in the last column need an approval step designed before anything else. Tasks with a no in the second column need a way to check the output before they need a model at all.