Skip to content
HJ ConsultHJ Consult
esc
Start a brief
Services
Work
Field notes
About
Brand
Norsk
Englishen
Switch mode·Nordlys
Switch mode·Systems
↑↓ select · ↵ open · esc close⌘K
Mode

AI · Automation · Operations

LLM agents in a small business – what actually works?

What works today is narrow jobs with an answer somebody can check: a draft a human approves, information pulled out of a mess and into a form, an enquiry routed to the right place, a question answered from your own documents. What does not work yet is the agent that “runs the business” unsupervised. And the most common failure is not the model being wrong – it is the system around it throwing away an answer that was right.

Published · September 10, 2026

Four things that work today

Drafts a human approves. Quotes, replies to enquiries, product descriptions, meeting notes. The model does the first ninety per cent, you do the last ten and press send. The gain is real and the risk is nil, because nothing leaves without somebody looking at it.

Extraction from a mess. An email, a PDF, a photo of a delivery note in – fields out, in the right format, ready for your system. This is the most underrated use and the one that pays back fastest, because it replaces retyping.

Sorting and routing. What kind of enquiry is this, how urgent is it, who should see it. A misrouting costs little and is noticed immediately.

Answers from your own documents. Price lists, procedures, contracts, past cases. It requires the documents to be tidy enough to retrieve from, and that is usually where the actual work turns out to be.

The common thread: the task is bounded, the answer has a shape, and somebody can see whether it is right.

Three things that do not work yet

The agent acting alone where money is involved. Sending an invoice, changing an order, refusing a claim. Not because the model is always wrong, but because its mistakes do not look like mistakes.

Anything where a wrong answer is silent. If nobody notices the answer was wrong for three weeks, the task was chosen badly. Pick jobs where the error is visible the same day.

One agent for everything. Four small jobs that each do one thing, each with its own check, beat one large agent every time – both on accuracy and on your ability to find out what went wrong.

What actually goes wrong

Here is an example from this site, measured and fixed.

The free AI review asks the model for a structured answer: quick wins, automations, what is worth renewing, a roadmap. The renewal field is optional – some businesses have nothing that needs replacing. We used constrained decoding, meaning the model is only allowed to emit text that fits the schema. That sounds like a guarantee.

It is not. Constrained decoding secures the shape, but it does not enforce rules that have to be counted – “at least one item”, “at most four” – and it trips over the empty list. Six of twenty-four Norwegian reviews died at exactly the same place: the model wrote the beginning of an empty list and could not find its way back out.

The fix was to remove the empty branch altogether: the field is either present with content, or absent. Twenty-four out of twenty-four afterwards.

The point is not the renewal field. The point is that none of the first five tests caught it, and that the failure looked like “the AI is flaky” when it was a detail in our own schema.

Measure it as a rate

One successful demo says nothing about a fault that hits one time in four. Five in a row passed while the defect was live in production; twenty-four runs reproduced it twice.

So: run the task at least twenty times on real, varied inputs before you believe it. Log what was rejected and why – not what the visitor wrote, but which field failed. And turn on a debug log locally, never in production, when the content comes from something a person typed.

Where the data lands is a decision

It is not a technical detail, it is a promise you either make or do not.

Our rule: what a visitor types does not leave the EU. No consent button opens that door. Where something genuinely has to cross a border – reading generated text aloud, for example – it is off by default, only the generated text is sent and never what the visitor wrote, and it is stated plainly on the privacy page.

Ask your vendor that question before you choose. “It happens in the browser” does not always mean it happens on the machine.

Start with one task

Pick the job somebody does by hand every day, with an answer you can tell is right. If you want a list of which ones are worth taking first in your particular operation, the free AI review looks at the business and gives you quick wins, what could be automated and a roadmap – in a couple of minutes, without anyone phoning you.

Field notes

Questions we get

The same questions, every time. These are the answers we give across a table.

Do we need to train our own model?

Almost never. For almost every task in a small business the answer is a good model, your own data pulled into the question, and a strict format on the response. Training your own costs a lot, is made obsolete by the next model generation, and rarely solves the problem people think it solves.

What about it making things up?

Treat the answer as data, not as text. Ask for a fixed structure, validate it against a schema, and let the system refuse to show anything that does not pass. Then “made something up” becomes a rejected answer and a retry rather than something a customer reads. For anything that costs money or leaves the building: a human approves.

Where does our data end up?

That is a choice you make, and it should be written down. On this site everything a visitor types goes to Mistral’s EU endpoint, is stored in Supabase in Stockholm and served by functions in the same region. No consent button unlocks anything else. If you are building your own, ask the vendor that question before you pick, not after.

What does it cost to run?

The model calls themselves are rarely the expensive part for a small business – a couple of thousand requests a month is pocket change. The cost is everything around them: pulling in your own data, validating the answers, handling the failures, and maintaining it when the provider changes something. Budget for that, not for the token price.

Where should we start?

One task somebody does by hand every day, with an answer you can tell is right or wrong. Build it properly, measure how often it lands across at least twenty real attempts, and keep a human approving until the number is boring. Then the next task.

Next step

Want to know what it means for you?

Describe your operation and get an architecture sketch, phases and a range in weeks straight back. Nobody phones you.