Guide / AI & Automation
An AI Feature Is a System, Not a Model Call
Design AI features around inputs, retrieval, evaluation and recovery. A model response needs a reliable product workflow before anyone can depend on it.
The prototype accepts a question, sends it to a model and displays an answer. It works well enough in a demonstration that the remaining work appears to be a nicer interface. Then somebody asks a question outside the available documents, another request times out, and a third receives a confident answer based on an outdated policy.
The model call was the visible center of the prototype. The product boundary is larger. It includes deciding which inputs are supported, finding appropriate evidence, managing uncertainty and helping the user recover when the answer cannot be trusted.
The model produces output. The product has to produce a reliable experience.
Begin with the job and its consequences
Define the user’s task before selecting an orchestration pattern. A feature that drafts a product description has different consequences from one that changes a published price. Both may use a language model, but the second requires stronger authorization, validation and recovery boundaries.
Describe what the user can rely on. Is the output a suggestion, a summary grounded in supplied documents, or an action the system will execute? The interface should make that distinction visible. A polished response can otherwise imply authority that the underlying workflow does not support.
Also define unsupported inputs. If the feature only answers questions about an approved document collection, a request outside that collection should produce a useful limitation or route to another workflow. Pretending every question is answerable transfers uncertainty to the user.
This product contract determines the rest of the system: what evidence must be retrieved, which checks are required, when a person reviews the result and how the application behaves when a dependency fails.
Draw the boundary around the whole workflow
A compact architecture for a document-grounded assistant might look like this:
User task
|
Input and permission checks
|
Relevant approved documents
|
Model request with bounded context
|
Output validation and evidence checks
|
Reviewable answer or useful fallback
|
Feedback and evaluation recordsThe diagram is deliberately conceptual. A small application may implement several steps in one service. A larger one may separate them. The important point is that each step has a responsibility independent of the model’s ability to generate convincing text.
Permission checks must happen before retrieving private material. Output validation must happen before a generated instruction becomes an external action. Evaluation records should avoid collecting unnecessary sensitive content. These boundaries belong in application logic rather than depending on the model to remember them on every request.
The model provider remains an external dependency with its own availability and behavior. Design the surrounding workflow so that a temporary failure does not leave the user unable to understand whether work completed.
Retrieval is an evidence selection problem
Retrieval can reduce the need for a model to answer from unsupported memory, but it does not automatically establish that the selected material is current, relevant or authorized. A search result may contain a similar phrase while describing a different product version.
Attach useful metadata to source material: ownership, version, effective date and access scope where relevant. When several documents disagree, the application needs a policy for which source governs. Asking the model to reconcile contradictory policies without authority information invites an answer that sounds reasonable but is operationally wrong.
Evaluate retrieval separately from answer generation. If the necessary evidence never reaches the model, changing response wording may not solve the failure. Conversely, retrieving the correct document does not guarantee the answer accurately represents it.
A user-facing citation should point to the material that supports the claim. A list of vaguely related documents is insufficient. When the feature cannot find support, it should make that absence visible rather than decorating an unsupported answer with references.
Input design changes output quality
A blank text box gives users flexibility while asking them to understand what the system needs. For a repeated business task, a small amount of structure can improve both usability and validation. A description generator might ask for product facts, intended audience and claims that must be avoided.
Do not collect fields merely because they might be useful. Each required input creates work and may expose information unnecessarily. Ask for the minimum context needed for the promised task, then explain why unusual fields matter.
Separate user instructions from quoted source material. A supplied document may contain text that resembles commands. The application should preserve the distinction between material to analyze and authority to change the workflow.
Structured inputs also make evaluation easier. A failure can be traced to missing facts, ambiguous instructions or an unsuitable source rather than treated as one undifferentiated “bad answer.” That clarity helps the team choose an appropriate repair.
Evaluate behavior that users depend on
OpenAI’s evaluation guidance recommends task-specific evaluations and continuing evaluation as systems change. For a product team, the key work is choosing cases that represent the actual promise and its failure modes.
A document assistant needs cases with answerable questions, missing evidence, conflicting versions and irrelevant input. A catalogue assistant needs cases where required facts are absent and where a plausible inference would create an unsupported product claim. Include examples that should produce a limitation or escalation.
Keep evaluation criteria distinct. Factual support, task completion, clarity and appropriate refusal are different properties. A single score can hide a serious regression if improvements in style compensate numerically for worse factual grounding.
A convincing answer is only one possible outcome of a successful workflow.
Sometimes the correct outcome is a request for a missing identifier or a clear statement that the supplied documents do not support a conclusion. The evaluation-plan essay explains why those cases belong before the public demonstration, not after it.
Budget latency and cost across the path
The user waits for the entire workflow: input handling, retrieval, model processing, validation and rendering. Optimizing one model call may have limited effect if retrieval or a repeated repair loop dominates the elapsed time.
Set bounded attempts and an overall deadline. A retry can help with a transient failure, but unlimited retries can multiply cost and leave the user waiting without a meaningful state. If the operation has side effects, retries also require a strategy for avoiding duplicate actions.
Measure cost per completed task, including retries and rejected outputs, rather than only cost per request. The appropriate budget depends on the value of the task and the expected usage. Avoid presenting a low demonstration cost as evidence of sustainable production economics.
Expose progress in terms the user understands. “Searching the approved documents” communicates a meaningful stage. A generic spinner provides less information, especially when a task can take long enough that the person may consider submitting it again.
A release evaluation should record the versions of the model configuration, retrieval collection and application rules used in the test. Changing any of these can alter behavior without changing the visible interface. Keep a representative evaluation set available so that a provider update or a new document batch can be assessed against the same product expectations. This gives the team a way to distinguish a regression in retrieval from a change in generation or validation.
Design the fallback before launch
A fallback should preserve useful work where possible. If generation fails after the user supplied a detailed brief, keep that brief available. If retrieval fails, explain whether the user can retry or use a manual source list. If validation rejects an answer, do not silently display the rejected output as a best effort.
The fallback also needs an owner. A button labelled “Contact support” is incomplete if nobody receives the request with enough context to help. A manual review path should define what information is retained and what the reviewer is authorized to do.
Keep operational evidence proportional and private. Record the stage, revision, timing and failure category needed to investigate. Full prompts and documents may contain sensitive information and should not be logged by default simply because they are convenient for debugging.
Before calling the feature ready, walk through an ordinary success, an unsupported request and an interrupted operation. Check what the user sees and what the operator can diagnose. If those paths are understandable, the model call has become part of a product rather than the product’s entire reliability strategy.