AI integration
When to add an LLM to an existing product — and when you should not
Most LLM programmes fail for a boring reason: the task was never ambiguous enough to justify a probabilistic component. The model is asked to do what a form, a query, or a job queue already does — only slower, dearer, and with a new class of errors. This note is the filter I use before anyone picks a vendor.
The only good reason to add a model
A large language model is useful when the input is messy and the desired output is a structured artefact a downstream system can consume: a classification, an extraction, a draft, a retrieval-backed answer, a tool call. It is not useful when the input is already a schema. 'Summarise this PDF' can be a model task. 'Mark the invoice paid when Stripe says so' is not.
If you cannot describe the task without the words 'intelligent' or 'magic', you do not have a task yet. You have a wish.
Seven questions that kill most proposals
1. Is the task ambiguous, or merely unautomated? If a junior hire following a checklist would be correct 99% of the time, write software. Do not rent a model to impersonate the checklist.
2. What does a wrong answer cost? A wrong tone in a marketing draft is cheap. A wrong refund, a wrong permission, or a wrong medical-adjacent suggestion is not. High-cost errors need validators and a human gate. Prompting 'be careful' is not a control.
3. May the data leave your boundary? If the answer is no, hosted APIs are a non-starter until you have a VPC or on-prem option. Model quality is downstream of this.
4. Where do the facts live? If they live in your documents and tickets, you need retrieval and citations. Fine-tuning will not keep up with last Tuesday's policy. If the facts live in a database, query the database.
5. What is the output contract? Production code cannot parse vibes. JSON schema, tool arguments, or a closed enum. Design the reject-and-repair path.
6. What is the latency and cost envelope? Background jobs tolerate seconds and cents. Page loads do not. A frontier model on a hot path is how inference becomes the largest line item.
7. Who owns evals after launch? If the answer is 'the intern who wrote the prompt', you are not shipping a product component. You are shipping a demo that will rot.
RAG, fine-tuning, and neither
Retrieval-augmented generation is for facts that must be current and attributable. It has its own failure modes: bad chunking, retrieved-but-ignored context, and citations that look like evidence. You need an evaluation set for retrieval quality, not only for final prose.
Fine-tuning is for format, tone, and task following on a smaller model. It is a poor knowledge base. If your team is fine-tuning so the model 'knows our product', stop and put the product in retrieval or in the application.
A surprising number of useful integrations need neither: a constrained schema, a handful of examples, and a validator. Start there. It is cheaper to be wrong about.
Agents are a last architecture, not a first
An agent is a loop with tools. Loops have cost, latency, and the ability to do the wrong thing twice. If you can draw the flowchart, implement the flowchart and use a model at the one messy step. If you cannot, you may have an agent-shaped problem — with caps, permissions in the tool layer, and a human commit for irreversible actions.
What I will not help you do
I will not put an unconstrained chat completion on a write-path to production systems. I will not treat chain-of-thought as a security boundary. I will not pretend a weekend prototype is an integration. If that is the engagement you want, there are cheaper vendors.
Takeaways
- Add a model for residual ambiguity, not as a substitute for product design.
- Decide data boundary and cost of error before you decide the vendor.
- Prefer schema plus retrieval over fine-tuning for facts.
- Prefer a workflow plus one model call over an unbounded agent.
- Ship evals and a fallback, or you have not shipped.