Atomic questions, composed in code
TypeSafe’s introduction is the design rule in one sentence: each question should ask one specific, well-scoped thing — a gut-check a knowledgeable person could make in a few seconds.
“Does this message convey urgency?” is in-bounds. “Analyze this message and determine the best course of action” is not. The second needs slow reasoning and several independent factors. Split it.
Why decompose
If a judgment weighs market size, technical feasibility, and differentiation, ask those as three Scores (or a mix of types) and combine them in code. When priorities change, you change a coefficient. You do not rewrite a giant prompt and hope the model reweights internally.
Questions in the same request are independent. One answer is not hidden context for another. If a later question truly cannot be built until you have an earlier answer — you need to fetch more data, or the next option list depends on the first Choice — make a second request. Otherwise ask everything together and ignore unused answers.
Speculative questions are cheap
Docs say adding questions barely changes response time and costs only the extra tokens. Ask the severity question even if you might later learn the ticket is not a bug. That pattern is speculative fan-out.
What “atomic” is not
Atomic does not mean “one question per HTTP call.” It means one judgment per question object. Pack many atomic questions into one POST /v1/systemone call.
Coding agents default to one question per call. TypeSafe publishes an agent skill that tells agents to batch.
Sources
Public TypeSafe or adjacent documentation only. No private claims.