Start here.
Start with one task that involves language or unstructured information. Give the feature the right context, show users what it used, and decide what happens when the output needs correction or the model cannot answer.
- Define the task before choosing a model.
- Apply the same access rules to AI as to the rest of the app.
- Test realistic examples, including unclear inputs and missing information.
Start with something people need to finish
“Add a chatbot” describes an interface, not a useful outcome. “Help a team member find the right agreement and the clause they need” describes a job. That distinction helps you decide what data is needed and what a good answer looks like.
Our Velveteen product includes an AI assistant alongside music operations. The same principle applies outside music: an assistant should be connected to a task and the information needed to complete it. It should not ask people to reassemble their work in a separate chat.
Choose the smallest feature that helps
Search can help people locate information they already have. Summaries can reduce the time needed to read a long record. A draft can provide a starting point for a reply or report. These are different features, with different ways to check whether they work.
Sometimes the simpler answer is a better filter, a clearer form, or an ordinary automation. We work through those options before treating a model as the default solution.
- Search: show the source records behind the answer.
- Summarize: let people inspect the original material.
- Draft: make editing and approval part of the flow.
- Act: define permissions and review before changing records.
Keep access and evidence in the application
An AI feature should only use records the signed-in user is allowed to see. The application needs to enforce that boundary before information reaches the model, rather than rely on instructions in a prompt.
Show where an answer came from when that evidence matters. If the feature prepares an action, let the user inspect the details before confirming it. Keep a record of what happened so the team can investigate mistakes.
A draft reply needs a review packet
Consider an illustrative project inquiry asking whether work can be finished by Friday. A useful draft should keep the original message, the supplied project details, the approved information it used, and unresolved questions beside the proposed reply. It should not invent availability, scope, or a price.
The reviewer can edit the draft, reject it with a reason, or approve a specific response. Approval should have a clear consequence; a saved draft does not mean a message was sent. If the inquiry needs information the application cannot obtain, route it to the responsible person with that missing fact visible.
This is an illustrative pattern, not a customer implementation. It combines the useful draft-and-evidence questions from the historical content without implying hospitality, winery, or other sector expertise.
Test the awkward examples
Use examples from the actual task: incomplete records, ambiguous requests, conflicting documents, and questions with no answer in the available data. Decide what the feature should say or do in each case, then check its behavior as the implementation changes.
Plan for slow responses, model outages, usage costs, and people correcting the result. The user should have a clear route back to the regular workflow. A feature that works during a demo still needs those details before it belongs in daily use.
Four parts of a useful AI feature
The model is one part of the application. The surrounding experience decides whether people can rely on the feature.
- Task
- A specific job: find a record, summarize a document, or prepare a draft.
- Context
- Relevant information the current user is allowed to access.
- Result
- An answer or suggestion that can be checked, edited, and used.
- Fallback
- A way to continue when context is missing or the feature fails.
A couple of common questions.
Can AI be added to existing software?
Yes, if we can work with the application and its data. Discovery establishes the integration points, permissions, and changes needed in the interface.
Do we need a custom-trained model?
That depends on the task. Start by testing whether an existing model with relevant context can produce a useful result; custom training is a separate decision.