Summary: build a normal software workflow and insert System One only where AI is needed.
- Keep control flow, deterministic rules, and side effects in code.
- Break broad judgments into narrow, typed questions with explicit instructions and criteria.
- Give each question only the context it needs.
- Use probabilities and confidence to act, ask for review, or escalate.
- Ask independent questions together, then compose their answers in code.
Three software architectures
TypeSafe is designed for building AI-powered software, where code owns the workflow and AI handles narrow, structured decisions.- Traditional software
- LLM agents
- AI-powered software
Traditional code is a complex decision tree made from simple software primitives. Because each primitive is reliable, developers can compose them into higher-level abstractions.


What makes System One composable
Structured
System One is type-safe by construction. Decisions and probabilities conform to the structured software types and JSON schema your code expects, so it never has to recover a value from generated prose.
Parallel
Questions are evaluated independently and in parallel. One primitive’s result does not become hidden context that changes another primitive’s result.
Comparable
Outputs are sortable and can drive smart
if statements, thresholds, and comparisons.Fast
Most queries complete in about 100 ms. System One is fast enough for real-time request paths and user interfaces.
Calibrated confidence
RLCD communicates uncertainty through calibrated probabilities instead of tending toward overconfidence.
Self-consistent
System One is designed to return stable answers across repeated evaluations. See the self-consistency cookbook.
Design a System One workflow
Use code when you can
Keep deterministic work in code. It is reliable and cheap. Avoid agent
Browse the System One patterns for bounded ways to compose model decisions with code.
while loops when a software workflow can express the same behavior.Example: keep deterministic rules in code
Example: keep deterministic rules in code
Decompose the input state
Include only the context relevant to the current questions. This helps the model avoid distractions and context rot. Do not rely on knowledge stored in model weights when current information can come from your own knowledge base.
Example: send only relevant context
Example: send only relevant context
Use structure in the input state
Use nested JSON for the
state and questions fields. Point questions at specific values when that removes ambiguity, and include the backtick characters around each path inside the question.Example: reference a nested value
Example: reference a nested value
Use a backticked dot-and-index path to point a question at a specific nested value, such as
support.tickets[0].message.Decompose the questions
Ask the most explicit, narrow, specific, atomic questions you can. Break down complex or ill-defined questions into separate questions that each evaluate one property.
This is probably the most important concept in this guide. Broad questions hide several judgments behind one answer. Atomic questions expose those judgments so you can inspect, tune, and combine them in code.
Example: decompose spam detection
Example: decompose spam detection
Example: verify a tool-call trace
Example: verify a tool-call trace
Use structure in the questions
Keep atomic questions short. When instructions or criteria need several kinds of guidance, use objects or arrays with named fields instead of flattening everything into a dense prose string. This makes the decision boundary easier to scan, review, and tune.For a Choice, describe what belongs in each option, what belongs in a neighboring option instead, and a few representative examples. Use the same field names across options so the model can compare them directly.
A short, unambiguous question or criterion can remain a string. Add structure when it separates guidance that would otherwise blur together.
Example: define contrastive Choice criteria
Example: define contrastive Choice criteria
Ask a lot of questions
Ask many narrow, independent questions about the same state in one request. This is how you maximize effectiveness and intelligence per dollar with the API: questions run in parallel, and code can combine their signals without adding serial model round trips.See the Speculative Fan-Out pattern and Parallel questions cookbook.
Combine question outputs in code (or feed into a classical ML model)
Combine independent answers with deterministic rules or weighted sums. For learned composition, use the probabilities as features in a downstream classical machine-learning model.
Composite Scoring shows how to preserve individual judgments while combining them. If you do not have labels for a downstream model, use an ensemble of expensive reasoning models to generate them; the AutoResearch cookbook shows how to train a classical model on System One outputs.
Example: combine signals with a weighted score
Example: combine signals with a weighted score
Route on uncertainty
Make code take different actions for confident and unconfident answers. Escalate uncertain cases to a person or a more expensive reasoning model. Test thresholds by plotting confidence against accuracy on your data.
See Confidence and Confidence-Gated Routing for choosing thresholds and matching them to the risk of each action.
Example: route by confidence
Example: route by confidence
Putting it all together
This support-ticket workflow keeps deterministic work in code, sends only relevant structured context, evaluates many atomic questions in one request, and composes the answers with explicit confidence gates.triage_ticket.py

