Start here.
Keep the ordinary workflow available, explain the specific limitation, and preserve the user’s work. Distinguish missing evidence, ambiguity, a service failure, and an uncertain action result. Each needs a different next step; none should be hidden behind a confident answer or an endless retry.
- Missing evidence and failed services need different next steps.
- A proposal, a confirmed action, and an uncertain result are separate states.
- Preserve the ordinary workflow and evaluate recovery.
Name the kind of failure.
For an illustrative assistant checking a release, a missing release date is a record problem. An inaccessible release is an access boundary. “Check this” without a selected release is an ambiguous request. A model outage is a service problem. Those cases should not all produce the same apology.
The response should identify what is needed without exposing information the user cannot access. It can ask a focused question, link to an ordinary edit screen, show a blocked field, or explain that the assistant is temporarily unavailable.
If the required evidence cannot be obtained, the feature should say so. A confident explanation generated from an empty or unrelated context can be more damaging to the workflow than a visible limitation.
Choose a next step for each case.
The matrix below describes intended behaviour for an illustrative release assistant. It is a design example, not a claim that every response has been demonstrated in Velveteen.
| Condition | Useful response | Work to preserve |
|---|---|---|
| Missing required field | Name the blocker and open its edit location | Selected release and existing draft |
| Ambiguous request | Ask which record or action is intended | Original question and current selection |
| No supporting document | State the source limit and offer an owner or search path | Question and permitted source references |
| Service unavailable | Show the regular workflow and a deliberate retry | Draft input and completed edits |
| Write result uncertain | Check recorded status before repeating the action | Original operation identity and proposal |
Keep proposed work separate from completed work.
A suggestion, an approved edit, and a submitted record have different consequences. A response should name which one happened and show enough detail to check it. “Done” is unsuitable if a tool returned an uncertain result or merely prepared a proposal.
Velveteen’s committed assistant tools explicitly distinguish readiness requests from submission. Its server route separately checks permission, state, and required information when submitting. The product story describes that boundary without treating a scripted public conversation as a live tool run.
If a request times out after changing a record, blindly repeating it can duplicate work. The application needs to retain the operation identity and inspect the authoritative result. Our integration guide explains this recovery problem independently of whether AI suggested the action.
A fallback must fit the same job.
Keep saved input, selected records, source links, and completed edits available when the assistant fails. A person should be able to continue through the ordinary form or review queue rather than reconstruct the task from memory.
An unsupported-answer fallback may be a named owner or a search result. A failed write needs an authoritative status check. A missing permission needs an appropriate access path. The design should not suggest that requesting more model context will solve all three.
In Velveteen’s committed knowledge-base preparation, the no-document case supplies a source-limit instruction and a route to offer help. That is evidence of a planned fallback in source; a prompt instruction alone does not prove that every generated response follows it.
Test failures alongside ordinary examples.
Create a small evaluation set with expected behaviour: a valid question, a missing field, conflicting sources, an inaccessible record, an ambiguous action, an unavailable service, and a timeout whose write outcome is uncertain. Use disposable records to exercise changes.
Judge factual support, the proposed next step, retained work, and whether an action actually occurred. A fluent refusal can still be wrong if the ordinary workflow is missing or the user’s draft disappeared. A successful answer can still be wrong if it used a private source.
Record which implementation version produced the result. Changes to context selection, prompts, tools, or record rules can alter the behaviour even when the visible chat looks the same. Recheck the affected cases when those boundaries change.
Make recovery someone’s responsibility.
Choose who receives unresolved cases and what information they need: the permitted original input, selected record, supporting sources, tool result, and failure reason. Avoid collecting unnecessary sensitive material merely to debug the feature.
Track repeated failures and review effort beside successful jobs. Decide which failures block wider use and which can be repaired. An assistant that regularly sends people back to manual work may need a narrower task or a better ordinary interface.
The goal is a workflow that remains understandable under uncertainty. The model is useful when it helps complete that workflow; its presence does not remove the application’s responsibility for records, permissions, and recovery.
Specify the moment after uncertainty.
Use a concrete failure as a design input.
- Failure
- Which evidence, permission, tool, or service is unavailable?
- Response
- What precise limitation and next step can the user understand?
- Preserved work
- What input, selection, and completed actions remain available?
- Verification
- How can a reviewer tell whether the action happened and recovery worked?
A couple of common questions.
Can a stronger model remove these failure paths?
A different model may improve some outputs, but missing data, access limits, unavailable services, and uncertain write results remain application problems. Keep their recovery paths explicit.
Should the assistant retry automatically?
That depends on the failure and the action. A read retry and a repeated write have different consequences. Check the original operation’s status and repeat safety before retrying a change.