The interesting question is not whether a model can be inserted into a workflow. It is whether a particular step needs a learned judgment at all. TypeSafe’s System One introduction describes narrow, structured decisions that software can act on. That suggests a useful design rule: let code handle facts and invariants it can determine exactly, and ask a model only where interpretation remains.
Start with the workflow graph
Consider an incoming support request. Code can authenticate the account, fetch the ticket, verify required fields, and check deterministic policy. A model may help decide which specialist queue best matches the customer’s language. Code then applies routing policy and records the outcome. The model’s answer is one edge in the graph, not the graph itself.
This approach makes the decision easier to test. You can collect input examples, specify the allowed outputs, check errors, and decide what to do when the model is uncertain. It also lets you replace a learned step with a simpler rule later if the rule proves sufficient.
Avoid tasks that need exactness or generation
The jev-1.13 limitations advise keeping counting, arithmetic, and date comparison in code. The coding-agent guide says Jev is not a prose or code generator. A model can still classify whether a passage discusses a deadline, while code extracts and validates the actual date. Likewise, a model can suggest a destination, while code checks permissions before calling a tool.
Test the action, not just the answer
A correct label can still lead to a bad outcome if the surrounding branch is wrong. Evaluate the full workflow: accepted inputs, fallbacks, review volume, irreversible actions, and logs. If you are new to the API, work through the quick start and then design state and questions for one narrow step.
Published 24 September 2026. Product capabilities and limitations checked against the linked TypeSafe documentation on that date.