Define the contract
Build a small evaluation set
Include the prompts you tried in this tutorial: a known order, an unknown order, a follow-up in the same session, a follow-up in a different session, a supported policy question, an unsupported question, and both approval outcomes. Assert the underlying effect and retrieved evidence where possible. For the approval case, the refund counter is a better contract than a substring in the model’s answer. For a real provider, pin the model configuration and record it with the evaluation results. Evaluation covers suites and scorers. Troubleshooting helps distinguish an execution failure from an answer-quality problem.Decide what needs recovery
Conversation persistence preserves history. Queue redelivery schedules another attempt. A checkpoint captures state. None of these alone knows whether a payment provider already accepted a request. Choose the recovery contract before enabling automatic retries for writes.Continue by task
Authenticate and authorize
Bind execution to verified identity and resource ownership.
Plan recovery
Choose history, queues, or durable tasks for the actual failure.
Operate the application
Set budgets, collect traces, handle shutdown, and investigate errors.
Choose more structure
Add a harness, workflow, or team when a concrete requirement calls for it.