# Structured Decision-Making: How a New Class of AI Models Is Built for Software, Not Humans
The artificial intelligence landscape has been shaped almost entirely around a single paradigm: a user provides input, and the model returns text. Whether that text is an essay, a code snippet, or a summary, the fundamental operation remains the same — generate the most plausible continuation of language. This has produced extraordinary results in creative writing, customer-facing chatbots, and code generation tools. But underneath that success lies a limitation that is becoming increasingly difficult to ignore.
## The Gap Between Text Generation and Software Decisions
Most software does not actually need a paragraph of prose. When an incoming request arrives at a customer support platform, the system does not need a human-readable explanation of which department should handle it. It needs a label — a structured, predictable value that a program can act on immediately.
Consider these common routing problems:
– Should this support request be directed to billing or technical support?
– Does this document contain personally identifiable information?
– How relevant is this content to a specific search query?
– Is this financial transaction suspicious enough to warrant a manual review?
Each of these is a classification or judgment problem, not a text-generation problem. Yet the dominant approach has been to use large language models — which are fundamentally text generators — to solve them. The result works, but it introduces fragility. A model asked to output “billing” might instead return “The billing department would be best suited for this case.” Or it might produce malformed output, add unexpected categories, or fail in subtle ways that are difficult to catch programmatically.
Structured output formats have improved the situation considerably, but at their core these approaches still rely on generative models performing what is essentially a classification task. This is like using a sledgehammer to drive a nail — it can work, but it is imprecise and wasteful.
## Enter TypeSafe AI and a New Architectural Philosophy
TypeSafe AI was founded by Diogo Almeida, a researcher whose prior work at OpenAI included co-inventing RLHF (Reinforcement Learning from Human Feedback) and InstructGPT — the very techniques that underpin models like ChatGPT. His contributions have been foundational to how modern language models are trained and aligned. With his new venture, Almeida is tackling a different problem: what should AI look like when the consumer of its output is not a human being but another program?
The company’s first release, a model built on what they call a **System One architecture**, represents a departure from the generative paradigm. Instead of producing freeform text, the model returns values from predefined structures. As the company describes the philosophy: “Decisions, not strings.” Input tokens cost a fraction of a cent per million, and output tokens are provided at no charge — making it extraordinarily lightweight for production use.
## System One: Fast Judgments for Machines
The name “System One” draws from the influential work of psychologist Daniel Kahneman, who distinguished between two modes of human thought. System 1 is fast, intuitive, and automatic — the split-second judgment we make when recognizing a face or answering whether 2+2 equals 4. System 2 is slower, deliberate, and analytical — the process we engage in when solving a complex math problem or planning a strategic move.
Current large language models are designed to emulate System 2 reasoning: they think carefully, generate chains of thought, and produce detailed outputs. The System One model, by contrast, is optimized for rapid, probabilistic judgment — the kind of decision a program needs when evaluating data at scale. It is not trying to write a thoughtful essay or engage in extended reasoning. It receives some unstructured state, asks a specific question, and returns a quick, typed judgment.
This architectural choice has profound implications for how AI can be integrated into software systems. Many programs already consist of conditional logic — if-then statements that route data, flag anomalies, or make binary determinations. The challenge is that some of these conditions involve fuzzy, semantic concepts that are difficult to express as hard-coded rules. How do you write a traditional rule that determines whether a customer appears frustrated, or whether a piece of text contains sensitive information? This is where a System One model functions as what might be called a **smart if-statement**: it evaluates the semantic condition, and the surrounding code decides what happens next.
## Three Primitives for Structured Decisions
The model currently organizes its decision-making around three fundamental primitives, each suited to a different type of judgment.
### Choice: Selecting From a Predefined Set
The Choice primitive is used when the output must come from a fixed list of alternatives. For example, if a system needs to classify incoming messages into categories like “billing,” “technical,” and “sales,” the model is given those options upfront and told to choose among them. Critically, it cannot invent a new category or embellish the answer with extra text. The result is guaranteed to be one of the provided options.
Additionally, the model returns not just the selected option but a probability distribution across all alternatives. This allows downstream code to make nuanced decisions — for instance, routing high-confidence results automatically while sending ambiguous cases to a human reviewer.
### Score: Placing Something on an Ordered Scale
When the decision involves a spectrum rather than distinct categories, the Score primitive is used. This defines an ordered scale — such as “routine,” “moderately urgent,” “urgent,” and “critical” — and asks the model to place the input at the appropriate point along that scale. Scores are useful for measuring concepts like document relevance, risk level, severity, customer frustration, or priority. The key distinction is that the meaning of each point on the scale is defined by the developer, and the model evaluates the input against that definition.
### Noul: Estimating the Truth of a Proposition
The third primitive, with the intentionally unusual name Noul, addresses yes-or-no questions by returning a probability that the proposition is true. For instance, asking “Does this document contain personally identifiable information?” yields a value close to 1.0 if the evidence strongly supports yes, close to 0.0 if the evidence strongly supports no, and somewhere near 0.5 if the model is uncertain. This probabilistic output is especially valuable for building layered decision pipelines where different thresholds trigger different actions.
## A Practical Example: Classifying Files for Sensitive Data
One compelling demonstration of this architecture is a file classification system. The goal is straightforward: examine an input file and determine whether it contains sensitive categories of information, such as medical records, personally identifiable information, API credentials, financial data, confidential business plans, legal documents, security-sensitive material, or other private content.
The system uses the Choice primitive to first determine whether the file is a plain text document — since binary files, images, and PDFs need to be handled differently — and then fires off multiple independent Noul queries, one for each sensitive category. Each Noul query returns a probability, and the application’s own logic decides what to do based on those probabilities. For instance, a file flagged with a PII probability above 0.9 might be automatically blocked, while a file with a score between 0.6 and 0.9 might be sent for human review.
This example highlights the architecture’s strength: the model handles the semantic judgment — understanding what constitutes PII or a credential in a given context — while the programmer retains full control over the operational response. The model is not generating text to be parsed; it is returning structured probabilities that a program can consume directly.
## Why This Matters for the Future of AI in Software
The broader significance of this approach extends well beyond any single model or company. The AI industry has invested enormous effort in making language models more fluent, more conversational, and more capable of reasoning step by step for human users. But the vast majority of AI integration in enterprise software does not involve humans in the loop at all — it involves machines calling other machines.
When an application uses AI, it typically needs a decision, a score, or a classification that it can act on programmatically. Returning a paragraph of text for another program to parse introduces unnecessary complexity, uncertainty, and failure modes. By designing models that speak directly in structured, typed outputs, the gap between AI capabilities and software engineering requirements narrows substantially.
Whether the System One approach becomes a dominant architectural pattern remains to be seen, but the core idea — that AI models should be designed around the needs of their consumers rather than the preferences of their users — represents an important shift in how we think about building AI systems for production environments.
## Frequently Asked Questions
**What is the difference between a traditional LLM and a System One model?**
A traditional large language model is designed to generate free-form text as its output. It is optimized for open-ended generation, creative writing, and conversation. A System One model, by contrast, is designed to return structured, typed decisions — such as a selection from a predefined list, a score on an ordered scale, or a probability that a proposition is true. The System One model is built for speed, predictability, and direct consumption by software systems.
**Why does the cost structure matter?**
Because the model returns structured values rather than long text generations, both the input and output token counts are minimal. Input tokens cost a small fraction of a cent per million, and output tokens are free. This makes the model economical to call at scale, which is essential for applications that need to process millions of requests or classify large volumes of data in real time.
**Can the model’s output be unpredictable?**
The design of the System One architecture specifically reduces unpredictability. For Choice queries, the output is guaranteed to be one of the options provided by the developer. For Noul queries, the output is a probability bounded between 0 and 1. For Score queries, the output falls within the defined scale. The model does not invent new categories or return unexpected formats.
**What kinds of applications benefit most from this approach?**
Applications that involve classification, routing, filtering, scoring, or verification — where the AI’s output is consumed by code rather than displayed to a human — are the best fit. Examples include support ticket routing, content moderation, data loss prevention, fraud detection, document triage, and any workflow that requires fast, structured judgment calls at scale.
**How does the probabilistic output help in practice?**
Returning probabilities rather than binary decisions gives developers flexibility. They can set confidence thresholds to automatically handle clear-cut cases, route uncertain cases for human review, or combine multiple model judgments in a single decision pipeline. This granularity is difficult to achieve when a model simply returns a text label.
## Conclusion
The emergence of models purpose-built for structured decision-making marks an important evolution in how AI is integrated into software systems. By moving away from the text-generation paradigm and toward typed, probabilistic outputs, these models reduce complexity, improve reliability, and lower costs for production workloads. The work pioneered by TypeSafe AI demonstrates that designing AI systems around the needs of machine consumers — not just human users — opens up new possibilities for how intelligent systems can be deployed at scale. As the industry continues to mature, expect to see more architectures that prioritize precision, speed, and programmability over freeform generation.
Thank you for reading
