There is a familiar sequence. Someone senior asks what the company is doing about AI. A feature is built, usually a chat box. It demonstrates well, gets a paragraph in a newsletter, and six months later the usage figures are embarrassing enough that nobody brings it up.
The failure is almost never technical. Modern models are extremely capable and integrating one is a few days of work. The failure is that the feature was chosen because it was possible rather than because it removed something a user did not want to do.
Start from the drudgery, not the capability
The AI features that stay in products replace specific, boring, repeated work: reading a document to pull four fields out of it, summarising a long thread before a call, drafting the first version of a reply that a person then edits, classifying incoming items so the right person sees them.
The question that finds these is not "where could we use AI" but "what does someone here do repeatedly that requires reading and judgement but not expertise". Ask the people doing the work; they can list it in a minute, and they will be right.
A useful filter: if the output needs to be perfect and cannot be checked, it is a bad first candidate. If a person will review the output anyway as part of their existing job, it is a good one — because the review step already exists and costs nothing to keep.
The chat box is usually the wrong interface
A chat interface puts the burden on the user to work out what the system can do and how to ask for it. In a product where the task is known, that is a step backwards from a button.
Better patterns for most business software: a suggested draft already in the field, ready to be edited. A summary at the top of a long record. A "check this for problems" action with results shown inline. Extracted fields pre-filled on a form with the source highlighted so they can be verified.
Each of these is easier to build than a chat feature, easier to evaluate, and easier for a user to adopt, because it appears inside work they are already doing rather than in a separate place they must remember to visit.
Ground it in your own data
A language model knows nothing about your business, and asked about it, will produce something plausible. For anything answering questions about your own content, retrieval-augmented generation — search your documents first, then answer using what was found — is the pattern that works.
Most of the effort lands on the retrieval half, not the model. If the search returns the wrong passages, a very good model writes a confident answer based on them. Budget for the document handling, the chunking, the quality of the search and, importantly, the behaviour when nothing relevant is found.
That last case is where trust is won or lost. A system that says "I could not find anything about that in your documents" is more useful than one that always produces an answer, and users work this out quickly.
Design for being wrong
The model will occasionally produce something confident and false. That is a property of the technology, not a defect to be fixed, so the design question is what the consequence is when it happens.
Three things make that consequence small: show the source, so a claim can be checked without leaving the screen; keep a person between the output and any irreversible action; and make the AI-generated state visibly distinct from confirmed data, so nobody mistakes a draft for a fact.
Systems that take actions on their own — an AI agent with tools — need more than this: scoped permissions, confirmation on anything destructive, a log of every step, and a limit on how long it may keep going. The capability is genuinely useful and the blast radius has to be bounded before it is switched on.
Model the running cost before you build
Inference is billed per token, so the cost of the feature is a function of how much text moves through it, multiplied by how often. That figure grows with adoption, which makes an AI feature the unusual case where success increases the bill.
Estimate it early with real numbers: average input size, average output size, expected uses per day, current price per million tokens. The result is frequently either reassuringly small or alarming enough to change the design — and it is much better to learn that now than after launch.
The design changes that help are mundane: send only the relevant part of a document rather than all of it, cache answers to repeated questions, and use a smaller model for the easy cases. Rate limiting is worth having from the first day, because a loop calling a paid API is a bug with an invoice attached.
Evaluate it like software, not like a demo
The step teams skip is building a test set: twenty to fifty real inputs with the output you would accept for each. Run it after every change to the prompt or the model, and record the pass rate.
Without this, prompt changes are made on impressions and nobody can tell whether an upgrade improved things or quietly broke a category of input. With it, an AI feature becomes something that can be maintained by ordinary engineering practice rather than by whoever wrote it originally.
A sensible first project
Pick one task, done by one team, many times a week, where a person already checks the result. Build the narrowest version of it that could be useful, put it in front of ten real users, and measure whether they keep using it after the novelty passes.
That project is small enough to fund without a business case, honest enough to teach you something, and — if it works — it will suggest the next three itself. Starting with a platform strategy instead produces a platform, and no users.