Building AI Features Without Making Everything a Chatbot
AI is often more useful as a small step inside an existing workflow: extract, rank, draft, validate, then let the user decide.
Start with the slow decision
A blank chat box asks the user to translate their job into a prompt. That can be appropriate for research or support, but it is a poor default for a workflow the product already understands.
I look for a narrower moment: a recruiter comparing candidates, an operator reviewing an exception, or a finance user checking extracted invoice fields. The model can prepare the decision by ranking, summarizing, or drafting. The user should still see the underlying record and remain able to correct the result.
An example: candidate sourcing
In a recruiting workflow, the useful unit is not a conversation with a model. It is a structured candidate result with a reason it matched, the source it came from, and enough evidence for a recruiter to verify it. Streaming helps because sources may respond at different speeds; it does not excuse returning an untraceable answer.
Provider fallback also belongs behind the product surface. If one AI or sourcing provider fails, the interface should keep the completed results, show the current status honestly, and allow the user to retry the missing part. This is the approach I took in RecruitAI: fault tolerance and streaming were part of the workflow, not separate demo features.
The contract is smaller than the model
Application code should call a domain-shaped function such as rankCandidates or extractInvoiceLines. That boundary owns the prompt, provider choice, timeout, schema validation, and logging. The rest of the product receives a typed result rather than a blob of model prose.
A useful result contract includes more than the answer. It may need confidence, source identifiers, warnings, and a status that distinguishes complete from partial. Unsupported enum values and malformed output stop at this boundary. They do not leak into billing logic, permissions, or UI state.
I store the model and prompt version with the result when the decision may need investigation later. Without that context, a support report becomes impossible to reproduce after the provider or prompt changes.
What happens when the model is wrong
The answer changes with the cost of the mistake. A low-confidence label can ask for confirmation. A draft can remain editable. A recommendation can show its evidence. Anything that changes money, access, a booking, or an external communication needs an explicit approval step or a deterministic policy around it.
I would rather ship a modest feature with a clear correction path than a magical-looking feature that silently commits errors. Good AI product work is mostly the engineering around the uncertain output.
When chat is actually the right shape
Chat earns its place when the user's intent is genuinely open-ended and follow-up questions improve the result. Even then, the conversation should invoke narrow, permission-aware tools instead of giving the model direct authority over the application.
The test is simple: if the team can name the exact input and output in advance, build that workflow directly. If discovering the intent is part of the task, conversation may be the interface.