Large prompts are often asked to do two incompatible jobs: generate a useful response and preserve the state of a business process. The first job is probabilistic. The second must be inspectable, repeatable, and recoverable.
That mismatch is manageable in a prototype. At production traffic, it becomes a systems problem: a tiny prompt change alters state transitions, retry behavior becomes ambiguous, and the only debugger is a transcript.
Prompting is not a control plane
A mega-prompt can describe the expected journey, but it cannot guarantee that the model will select the correct next action. It also cannot make an invalid transition impossible. Adding more instructions only increases the number of interactions a maintainer must reason about.
TourFlow puts the invariant in code instead. The model receives a narrow task for the active state, and an application-owned strategy validates what comes back. A state transition is then an explicit event, not an interpretation embedded in prose.
stateDiagram-v2
[*] --> Welcome
Welcome --> SelectTour: tour selected
SelectTour --> AnswerQuestion: route confirmed
AnswerQuestion --> SelectTour: another location
AnswerQuestion --> Complete: tour complete
Complete --> [*]The strategy boundary
Each state owns a small strategy with three responsibilities:
- Assemble only the context required for the present interaction.
- Ask the model for constrained, structured output.
- Validate the result before emitting the next event.
The model can be creative inside the boundary. It cannot silently create a new state or skip a required confirmation. That is the essential division of labor: language models produce candidates; deterministic code decides whether those candidates may alter the system.
What this changes operationally
The resulting traces have names that correspond to the product: SelectTour, AnswerQuestion, Complete. A failed model call is retryable without guessing which part of a massive prompt already took effect. Test suites can enumerate valid transitions, and analytics can distinguish a poor answer from a broken journey.
This pattern does not make a model deterministic. It makes the system around the model deterministic where it matters.