Not every problem needs a model

Most of the requests we hear now mention AI. Some of them need it. Many are better served by something plainer, and part of our job is telling the two apart before anyone writes code.

Where a model earns its place

Language models are good at work that used to need a person only because the input was messy:

• reading a PDF purchase order that arrives in a different layout from every customer,
• sorting a shared inbox into the requests each team handles,
• writing a first draft of a proposal from the last twenty you sent.

In each case the alternative was a person reading and retyping, and the model's output is checked before it matters.

Where it doesn't

If the input is already structured, a model adds cost and uncertainty for no gain. Syncing a CRM with an accounting system is a matching problem: the records have IDs, the rules can be written down, and a script will apply them the same way every night. A spreadsheet several people edit at once usually needs a small app with a database and permissions, not a chatbot.

Models are also a poor fit for decisions someone has to answer for. Approving a credit limit, changing a price, or sending something to a customer should stay with a person, even when a model has done the reading that informs it.

The question we ask

For each step in a process, we ask what would go wrong if the answer were occasionally, confidently wrong. If the answer is "a person would catch it on review", a model can help. If the answer is "it would go straight to a customer", it shouldn't be making that call alone, and often it doesn't need to be involved at all.