Begin with the branch, not the prompt
Imagine a support inbox. Before writing a prompt, write down what your application could actually do: send a message to billing, send it to technical support, or leave it for a person to review. Those destinations give the model a useful decision boundary.
The question becomes: which of these departments best fits this message? It no longer needs to draft a reply, perform a refund or reason about every possible next step. Each of those is a separate responsibility.
This is our suggested design exercise: sketch the action first, then work backwards to the information needed to choose it. TypeSafe's System One introduction explains the underlying model approach.
Keep four things separate
| Layer | In a support inbox | Who owns it? |
|---|---|---|
| Context | Message text and relevant account facts | Your application |
| Judgment | Which department fits the request? | Jev, against your criteria |
| Policy | Whether to route automatically | Your code and evaluation results |
| Action | Move the ticket to a queue | Your application |
This separation is useful even before you make an API request. You can test the queue-moving code using a fixed answer. You can evaluate the classifier without giving it access to the live inbox. You can change the routing policy without rewriting the message parser.
Choose an action you can undo
For a first project, a suggested label is a better starting point than an irreversible action. Let the interface show the proposed destination and keep the original message accessible. Log enough information to understand a mistake, while respecting the privacy needs of the application.
An explicit review option is useful when the available labels do not fit. There is no advantage in forcing a miscellaneous request into a department merely because the code expects an answer.
Write a small evaluation set
Collect examples that are clearly billing, clearly technical, ambiguous, and outside the intended scope. Include short messages, misspellings and requests that mention multiple subjects. Decide the expected route before seeing the model's prediction.
Then ask two questions: how often does the proposed route match the expected one, and what happens when it does not? These matter more than how persuasive an individual demo looks.
Take the next step
The official building guidance describes how to combine narrow judgments with application logic. Our API quick start turns one of those judgments into a request. For a real community pattern, read the model-routing case.