Most teams that try to make a language model “decide” something end up with the same architecture: a prompt that demands JSON only, an output parser wrapped in a try/catch, a regex fallback for the day the parser fails, and a quiet suspicion that production traffic should not be flowing through this. The failure modes are well documented — schema drift on edge cases, confidence numbers the model invented rather than measured, different answers to byte-identical requests, and latency that swings with how chatty the model feels. Decision AI describes the alternative: a model whose single job is to return a bounded, typed decision that a program consumes directly, with no text to interpret in between.
What Decision AI Actually Is: Bounded Outputs, Calibrated Probabilities
The distinction is architectural, not cosmetic. A generative model receives a prompt and produces a sequence of tokens; whether that sequence happens to parse as valid JSON is a property of the output, checked after the fact. A decision engine inverts the contract. You declare the question and the permitted answer space in code, send the state, and receive a value drawn from that closed vocabulary. There is no prose to strip, no field to hallucinate into existence, and no ambiguity about what an empty string means.
A well-designed decision ai layer exposes this through a small set of answer types rather than one generic object. The most useful taxonomy looks like this: choice, which returns exactly one label from the list you supplied — refund, exchange, escalate; score, a level on an ordered scale such as a 1–5 quality grade; truth, a calibrated probability between 0.00 and 1.00 rather than a hard boolean; number, a value snapped to a defined grid; and point or box, locating something inside an image by coordinates. Each of these maps to a native type in your language of choice, so the boundary between model and application is a schema, not a string.
Two properties separate this from the prompt-and-parse pattern. The first is calibration. A calibrated confidence means the number attached to an answer is empirically meaningful: across the subset of requests scored near 0.85, roughly 85% should be correct. That is what makes thresholding safe — act instantly when confidence clears your bar, and route to a re-check, a human, or a conservative default path when it does not. Without calibration, a model’s “confidence” field is decoration.
The second is determinism. Same request, same answer. That sounds unremarkable until you try to write a regression suite against a system that resamples. Determinism lets you version a decision policy, replay traffic, and diff behaviour between releases the way you would diff any other code change.
DecisionNode implements this as a “System One” model — fast, reflexive, single-pass inference rather than chain-of-thought deliberation. Requests go to one HTTPS endpoint, POST /v1/decide, carrying state as text, JSON, or up to 16 images or video frames, plus the questions defined in code. Answers come back in one pass. Flash runs around 5 ms server-side and 19 ms end to end at $0.035 per 1M input tokens; the MoE model runs roughly 9 ms at $0.042 per 1M input tokens, with output tokens always free.
Where Decision AI Fits: Routing, Risk, and Real-Time Ops
The highest-value deployments are the unglamorous ones — high-volume, low-ceiling judgements that currently live in hand-written rules or in chat-LLM calls that are slower and less consistent than the problem deserves. Ticket routing and triage is the canonical case: a support message arrives, you need a queue label, a priority level, and a probability that the customer is actually angry, all before the first agent looks at it. Rules based on keywords break the moment a customer writes “no rush at all, but…”. A graded decision over the message text handles that without a rule explosion.
Fraud and promo-abuse checks follow the same shape. The useful output is rarely a binary; it is a truth probability your risk service can combine with velocity signals and account age, plus a discrete band that determines whether the request is approved, held, or challenged. Order and shipping decisions — carrier selection, split-shipment, exception handling — benefit from the same treatment, as does moderation, where a score across a defined severity scale is far more actionable than a block/allow verdict.
Physical operations are where the latency budget becomes the design constraint. Quality control on a production line, warehouse monitoring, and traffic analysis all need decisions inside a frame interval, not inside a human conversation. This is also where multimodal state matters: a request can carry a handful of camera frames alongside structured telemetry, and the answer can be a box around a defect plus a choice for the disposition. When the loop exceeds roughly ten decisions per second — drones, robots, simulators, continuous machine monitoring — a request/response endpoint stops being the right shape, and persistent WebSocket sessions are what keep the per-decision overhead flat.
It is worth separating the decision from the perception. Boosters such as human age estimation, AI-generated image detection, face detection and recognition, OCR, depth, and segmentation exist so you do not have to stand up and maintain a separate vision stack for each sub-question. The decision layer composes them: OCR extracts the text, segmentation isolates the region, and the decision model returns the label your workflow branches on.
Engineering Workflow: Contracts, Thresholds, and Cost Control
The practical integration is deliberately boring. You define your questions and label sets as code artifacts, ship them alongside the service, and call POST /v1/decide with state and questions. SDKs exist for TypeScript, Python, Go, and Ruby, with curl as the escape hatch; MCP tools and webhooks cover the cases where the caller is an agent or an external system rather than a request handler. For agent builders, the pattern that matters is decide before acting: the agent asks the decision model whether the proposed tool call is in policy, and only proceeds on a confident yes. That single gate eliminates a large class of expensive mistakes that no amount of prompt engineering fully prevents.
Confidence thresholds deserve real thought rather than a default of 0.5. A workable starting structure is three bands: above the upper threshold, act automatically; between the bands, take a cheap secondary path — a retry with more context, a cross-check against a deterministic rule, or a queue for review; below the lower threshold, fail safe. Because the probabilities are calibrated, these bands can be set directly and then validated against labelled historical data instead of guessed.
Cost modelling is straightforward when output tokens are free. At $0.035 per 1M input tokens for Flash, a request carrying roughly 200 tokens of state and question definitions costs about seven millionths of a dollar — around 5,000 decisions per $0.035 of input spend. That changes the build-versus-buy conversation, because decisions you previously batched to save money can now run inline on the request path. Batch discounts handle offline backfills and re-scoring, and the free daily tier is enough to run a shadow deployment: send live traffic to the decision engine alongside your existing rules, log both outputs, and compare before you cut over.
Migration hygiene matters as much as the call itself. Version your question definitions, treat label-set changes as breaking changes, persist the returned value alongside its confidence so you can audit later, and keep a sample of raw state for every low-confidence path so re-check logic has something to learn from. Teams that follow that discipline get the thing they were actually after when they started prompting a chat model to emit JSON: a decision surface that behaves like a dependency rather than a rumour.
Sofia cybersecurity lecturer based in Montréal. Viktor decodes ransomware trends, Balkan folklore monsters, and cold-weather cycling hacks. He brews sour cherry beer in his basement and performs slam-poetry in three languages.