What belongs around an AI model

Begin with the result a person needs

Before choosing a model, write down what the user wants to finish. A patient might need a report. A member of staff might need a document prepared. A team might need an exception routed to the right reviewer. Those are product outcomes, not prompts.

This description makes the boundaries visible. It shows which information is required, which decisions belong to the software and where a person should stay involved. It also provides a useful way to decide whether a feature worked.

Give the application a source of truth

A generated sentence is not a database record. If an application needs the status of an order or the details of a report, it needs a defined way to retrieve that information. The model can help interpret a request, but the surrounding system should decide where the authoritative data comes from.

Tool contracts are useful here. A contract describes the required input, the returned fields and the errors a caller needs to handle. It becomes easier to test the integration separately from the conversation.

Make failure understandable

The happy path is usually the easiest part to demonstrate. The more revealing questions are what happens when a record is missing, a request is ambiguous or an external service is unavailable.

Each of these needs a product response. That might be a clarification question, a visible processing state or a message that lets the user retry. Long-running work can be represented as a job rather than hidden inside a request that appears to have stopped.

• Identify missing information before taking an action.
• Give background work a visible state.
• Keep enough context to investigate a failed step.
• Provide a review path when the result needs a person.

Evaluate the whole workflow

A response can sound good while failing the task. Evaluation examples should therefore include the expected retrieval, any permitted actions and the final result—not just whether the wording looks fluent.

A focused starting set can cover ordinary requests, missing data and a few failure cases. As the application receives feedback, that set becomes a record of the behavior the team wants to preserve.

Delivery includes the next engineer

Configuration, deployment and documentation matter because the product will need to change. The next engineer should be able to see which services are running, how a request moves through them and where to investigate a problem.

Hassan Revel’s approach to AI application work puts these surrounding pieces inside the delivery scope. The model is one component of the product; the workflow is what users experience.