The model is not the workflow
A production system needs triggers, retrieval, business rules, tool calls, approvals, state, and destinations. The model may classify, extract, draft, or recommend, but the surrounding software decides when that output is useful and what may happen next.
Draw the end-to-end path before optimizing a prompt. This makes integration gaps and ownership questions visible while they are still inexpensive to change.
Evaluation must follow the handoff
A response can be accurate and still fail the operation because it arrives late, omits a required field, uses stale evidence, or cannot be written into the next system.
Test representative cases through the complete flow. Measure output quality alongside completion rate, latency, human corrections, exceptions, and downstream acceptance.
Permissions are part of product behavior
Define which identity reads each data source, which tools it can use, and which actions require stronger authorization. Keep read, draft, recommend, and write permissions separate.
This boundary should be visible to operators. A person reviewing an action needs to know what the system already did and what approval will allow it to do next.
Recovery makes the system dependable
Integrations time out, documents arrive incomplete, policies conflict, and cases fall outside the expected pattern. A dependable workflow records its state, retries bounded failures, and routes unresolved cases without losing context.
Production readiness is less about removing every failure and more about making failures observable, contained, and recoverable. That is the system layer a convincing demo rarely shows.