TypeSafe calls it the most important concept in its guide: break one broad judgment into narrow questions and combine the answers in code. Here is what decomposition buys you (reasons, control, per-signal thresholds), why decision science has recommended it for seventy years, and the case where it made things worse.
Key takeaways
- A broad question hides several judgments behind one number; narrow questions expose them so you can inspect, tune and combine them.
- The broad answer is often right, but only the narrow ones tell you why: which signal fired, which tool argument was wrong.
- Combine in code: weighted sums for factors that trade off, separate hard rules for 'any serious violation'.
- Decision science agrees: simple formulas over separately judged criteria beat holistic judgment (Meehl, Dawes, Kahneman, the Apgar score).
- Decomposition is not magic: it can't turn a System Two problem into System One answers, so validate the combination on labeled data.
Try it with your agent
Paste this into your coding agent:
Pick one broad judgment we ask a model to make (spam, risk, quality, policy violation). Split it into 4-8 narrow questions, each a few-second judgment for an expert, asked in ONE request. Combine them in code: hard rules for vetoes, weights for factors that trade off. Then run both versions on 100 labeled examples and report accuracy, plus 5 examples where the narrow answers explain a decision the broad one got wrong (or right).
Transcript
Intro
If you remember one technique from this course, make it this one. Don't ask one big question. Ask several small ones, and combine the answers in code.
Small questions
Take spam. You could ask one question: is this message spam? Point nine seven. Fine, but why? Split it into narrow questions instead. Does it ask for a password? Point nine nine. Does it promise an unexpected reward? Point nine seven. Does it pressure you to act fast? Point nine eight. Does the sender's name clash with their domain? Point seven two. Now combine them in code, with weights you control.
The TypeSafe guide is blunt about it. 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.
Reasons, not just verdicts
Here's where it pays off. An agent was asked for tomorrow's weather in Seattle, in Fahrenheit. Ask the broad question, are these tool calls correct, and you get point one. Something's wrong, but what? Ask six narrow questions, and five come back near one. One doesn't: does the unit match the request? Point oh two. The agent asked for Celsius.
Simon Willison worried, when Jev launched, that it's a black box. If it marks something as spam, which signals tipped it off? Decomposition is the answer. Each narrow question is a reason you can log, show to a reviewer, and test on its own.
Combine in code
Then combine them in code. For factors that trade off against each other, use a weighted sum. But don't let a weighted sum average away a serious violation. If a message asks for credentials, that should block it on its own, whatever else is true. Rules and weights both live in your code.
Seventy years of evidence
This isn't new. Since Paul Meehl's work in the 1950s, study after study has found that simple mechanical rules beat expert intuition at many prediction tasks. As decision researcher Olivier Sibony puts it: even the simplest rule will typically make fewer mistakes than the humans who think they are much smarter than the simple rule.
The classic example is the Apgar score, from 1952. Instead of a doctor's overall impression of a newborn, five quick judgments: appearance, pulse, grimace, activity, breathing. Each zero to two, added up. Seven or more is normal. Three or below means act now. Narrow judgments, a sum, and bands for action. That's the pattern.
Where it fails
But decomposition is not magic. Mike Ramos tested Jev on poker decisions, where the right move depends on game theory. Six narrow judgments instead of one question changed forty seven actions. Twelve got better. Twenty one got worse. Poker strategy is a System Two problem, and splitting it into fast judgments didn't change that.
Quick check
Quick check. A content policy says: any threat of violence means removal, whatever else the post contains. How should that rule appear in code?
Try it
Try it. Have your agent decompose one broad judgment in your code, and compare it with the original on labeled data.
Recap
So: ask many small questions and combine them in code. You get reasons, not just verdicts, and control over weights and vetoes. Decision science has backed this for seventy years. But it's not magic: validate it on your data. Next: asking all those questions at once.