Define the task before choosing the model
Summarising a support conversation, extracting a delivery date and approving a payment have very different consequences. Describe the task and its failure modes before selecting an implementation. A deterministic rule may be sufficient for part of the workflow.
Create representative examples
Collect approved examples that include ordinary cases and difficult exceptions. Keep a separate evaluation set so that improving the prompt does not become a process of memorising the examples used during development. Record the criteria a useful answer must meet.
Show the basis for an answer
Where the task depends on source documents, help reviewers inspect the relevant source material. A fluent explanation is not evidence of correctness. The interface should make review faster without encouraging automatic approval.
Give uncertainty a product state
Design an explicit route for missing context, conflicting sources or unsupported requests. Let the user correct inputs or hand the task to a person. Do not turn a model’s confidence-sounding language into an assurance that the result is accurate.
Limit the consequences
Separate drafting from sending, suggestions from changes, and extraction from approval. Start with reversible actions and appropriate permissions. Observe failures, cost and latency before expanding the feature’s responsibility.
