Most requests we get for AI features start from the technology. Someone has seen a demo, the board has asked what the company is doing about it, and the brief arrives as "we should add AI to the platform".
That framing produces bad features. The better question is narrower and much more useful: which parts of this job are people still doing by hand because the software cannot help them?
The shape of a good candidate
The workflows worth automating tend to share four traits.
Somebody reads a lot to extract a little. A support agent scrolling three months of ticket history to find one decision. A project manager reading forty comments before a client call. The information exists; finding it is the work.
The output gets reviewed anyway. If a human already checks the result before it matters, you have a natural safety net and the cost of being occasionally wrong is low.
The task is repetitive and low-status. Summarising the same weekly report. Re-keying figures from a PDF that arrived by email. Nobody defends this work.
You can tell whether it worked. If you cannot measure the improvement, you cannot tell a useful feature from an impressive one.
Summarisation, extraction, retrieval over your own records, and drafting-for-review all fit this shape. That is not a coincidence — it is why those are the features that keep succeeding.
The shape of a bad one
The mirror image is just as consistent.
Anything where being wrong is expensive and invisible. Financial calculations, compliance determinations, eligibility decisions. If a rule can be written down, write it down. A deterministic rule you can test beats a probabilistic one you have to trust, every time.
Anything replacing a lookup that already works. If the answer is in a table, query the table. Wrapping a working query in a language model makes it slower, costlier and less reliable.
Anything where nobody will check the output. Automation with no review step is where quiet, compounding errors live.
The unglamorous truth about quality
When an AI feature in a business application disappoints, the model is rarely the reason. The retrieval is.
If the assistant is searching across badly structured data, documents with no metadata, records where half the fields are free text that means different things to different teams, then no model will save it. A modest model over well-organised data outperforms an excellent model over a mess, consistently.
Which leads to something we find ourselves saying often: the groundwork that makes AI possible — a clean API layer, structured data, a coherent permission model — improves the application whether or not you ever ship the AI feature. That work is not a tax. It is the part with lasting value.
Permissions are the thing that gets forgotten
This is the failure mode that causes real damage.
An assistant that can search "your company's data" will happily tell a junior employee what is in the director's private project notes, unless something stops it. Retrieval has to run inside the same permission model as the rest of the application — filtered per user, at query time, not as a post-processing step over results you have already fetched.
If your application's permissions are complex, and in operational software they always are, this is the hardest part of the build. It is also non-negotiable, and it is a good reason to scope the first feature to a single project or a single record type where the access rules are simple and obvious.
On keeping data in-house
Plenty of businesses cannot send customer records, contracts or source code to a third-party service. That is a contractual and regulatory constraint, not a preference, and it is the most common blocker we encounter.
Running open-weight models on infrastructure you control solves it. The trade-offs are real — you need hardware, you own the operations, and the models are generally a step behind the best hosted ones — but for summarisation, extraction and retrieval over your own data, that gap matters far less than people expect.
The sensible sequence is usually: prove the workflow against a hosted API first, confirm it actually saves time, then move the model in-house once you know the feature is worth the infrastructure. Because the application talks to both over HTTP, that migration barely touches your code.
Start with one
Pick one workflow. Ship it. Measure whether it saved anyone any time.
If it did, the same foundation carries the next one. If it did not, say so and stop — that is a cheap, honest outcome, and considerably better than a platform full of features nobody trusts.