Start with the workflow, not the model
Describe the task a person needs to complete, the decision it supports and what happens today. The application should fit that workflow and make the next step clearer, not add a chat box beside it.
Define what correct means
Write representative questions or tasks and agree what a correct, acceptable or unacceptable result looks like. Use that set to compare models, prompts and retrieval changes before release, and keep it as a regression check afterward.
Design for failure and cost
Decide what the application does when the model is slow, unavailable or uncertain. Set a fallback path, show source context where it helps, and make latency and cost visible enough to operate the feature after launch.
- Permission-aware access to approved data.
- Model and prompt versioning with a rollback path.
- Monitoring for errors, latency, cost and escalation.
- A human route when the system cannot complete the task.
Integrate with the operating environment
Production work crosses system boundaries. Connect approved data sources, identity and permissions, business services and monitoring through interfaces your team can operate. Decide where the application reads from, what it may write, how failures surface and who owns each dependency.
- Approved data sources with freshness and ownership defined.
- Identity, permissions and service-to-service access.
- Latency, retry, rate-limit and failure behavior.
- Logging, cost attribution and escalation paths.
Release to a controlled audience
Start with a defined group and a review rhythm. Expand access when the evidence shows the workflow is dependable, the support burden is understood and the operating cost is acceptable.
Treat evaluation, access control and fallback behavior as part of the feature, not as launch tasks.