What does an AI workflow need to know before it starts?

The reply was polite, well written and sent within two minutes. It quoted last year’s price.

Nothing was wrong with the AI. It had read the price list it was given. The price list was the one saved in a shared folder in January, and the new one lived in the sales manager’s inbox.

This is the most common kind of AI mistake in a small business, and the least discussed. The model did not reason badly. It answered correctly from the wrong information.

Most of the work in a reliable AI workflow is not choosing the model. It is deciding what the workflow is allowed to know.

A language model arrives knowing how to write, summarise and classify. It does not know your current prices, your opening hours this week, which services you stopped offering in spring, or that one client always pays by bank transfer.

Everything specific to your business has to be given to it: a document, a spreadsheet, a database record, a template, a rule. That material is the workflow’s context. If it is incomplete, old or contradictory, the output will be confidently incomplete, old or contradictory too.

So before asking “which AI tool should we use?”, ask a plainer question: what does this workflow need to know to do the job properly, and where does each piece of that live today?

Take one workflow and write down every fact a correct output relies on.

For a drafted reply to a customer enquiry, that might be:

For an invoice being checked and filed, it might be the supplier list, the approved cost centres and the rules for who signs off what.

This list is usually shorter than people expect. It is also usually the first time anyone has written it down.

For each item on the list, name the one place it should come from.

This is where most SMEs find the real problem. The price exists in three versions: a PDF on the website, a spreadsheet the team uses and the figure the owner quotes from memory. A human copes with that by asking a colleague. An AI workflow cannot ask. It uses whichever version it was given.

Pick one source per fact. If that means retiring a spreadsheet or merging two lists, do it before the AI step goes live, not after the first wrong answer. This is the unglamorous part of the project, and it often delivers value on its own, because the team now has one answer as well.

Where possible, connect the workflow to the live source rather than a copy. A copy starts going out of date on the day it is made.

A source with no owner decays.

For each one, name the person responsible for keeping it accurate and the moment it gets updated: when prices change, when a service is added, when a policy is revised. Make that update part of the change itself. If changing a price means updating the price list the workflow reads, then a price change is not finished until that is done.

This matters more than it sounds. Once a workflow is running, the business keeps moving. The AI does not notice that the world changed. Someone has to tell it, by changing the source it reads.

Every workflow will meet questions its sources cannot answer. A customer asks about a service you have never offered. An invoice arrives from a supplier who is not on the list. The information is simply missing.

The worst outcome is a fluent guess. Language models are good at producing something plausible, and plausible is exactly what a busy reviewer approves.

Design the gap on purpose:

That last step is how the context gets better over time. The gaps show you what to add.

More is not always better. Giving a workflow every document in the shared drive makes it harder, not easier, to find the right answer, and it raises the chance of an old version winning.

Give each workflow the material for its job and nothing else. The enquiry workflow needs the current offer and the conditions. It does not need last year’s board minutes or the draft brochure nobody approved.

Smaller, cleaner context is also cheaper to run and easier to check. When a reviewer sees an odd answer, they should be able to find the sentence it came from in a minute.

When the workflow produces an output, it should be clear which source it relied on: the price list, the customer record, the policy page. Ideally the reviewer sees it beside the draft.

This turns a vague “the AI got it wrong” into something specific: the AI read the right document and the document was out of date, or it read the wrong document, or the answer was not in any document. Each of those has a different fix, and none of them is “try a different model”.

For one AI workflow you run or plan to run, write down:

If you cannot answer the first three, the workflow is not ready to build. That is not a setback. It is the most useful thing you can learn before you start, and the fix usually helps the whole team, not just the AI.

A well-chosen model with poor information will be wrong in a polished way. A modest model with clean, current, owned information will usually be right, and when it is not, you will know why.