Most AI systems in production today are asked to generate text and then trusted to mean what they say. A decision engine inverts that contract. You hand it state, you declare the questions in code, and it returns answers that already fit a schema — a label from your own list, a level on an ordered scale, a probability, a number, a coordinate. That single design choice changes what the surrounding system has to do: no parsing layer, no JSON repair, no guessing whether a 0.7 means “probably” or “the model felt like it”.
What a Decision Engine Is — and Why a Chat Model Is Not One
Historically, “decision engine” meant a rules engine: a RETE-style network of hand-authored predicates that fired when conditions matched. Those systems are deterministic and fast, and they fail in a very specific way — every new input shape becomes another branch. Throw in a free-text support ticket, a photo of a damaged pallet, or a noisy transaction record, and the rule tree either ignores the signal or grows into something nobody can safely modify. Rules capture what an engineer already thought of; they do not interpret messy state.
Chat LLMs took the opposite bet. They interpret unstructured input well, but generation is the wrong primitive for a control decision. Asking a model to “reply in JSON” produces a probabilistic formatter: labels drift outside your vocabulary, fields arrive missing, and the retry loop you build around schema validation becomes part of your latency and your cost. Worse, the confidence signal is usually absent, or present as a number that is not calibrated against outcomes — so code cannot safely branch on it.
A modern decision engine constrains the answer space at request time. The questions and their answer types are declared in code, and the model answers within those types: choice (exactly one of your labels), score (a level on an ordered scale), truth (a calibrated probability between 0.00 and 1.00), number (a value on a grid), and point or box (locations inside an image). Because an out-of-vocabulary label is not representable, the class of failure where a model invents a routing queue simply disappears.
The second property is calibration. An answer marked 0.92 should resolve to the positive class roughly 92 times out of 100 across similar inputs. That is the precondition for threshold logic actually working: act instantly above the threshold, re-check or take a safe path below it. Without calibration, a threshold is a guess with extra steps.
The third is determinism. Same request, same answer. It sounds unremarkable until you try to test a probabilistic system in CI, replay last quarter’s decisions during an audit, or diff behaviour after editing a schema. Determinism turns a decision into an artifact you can version, cache and compare rather than a live performance you hope reproduces.
Inside the Decision API: State In, Schema-Valid Answers Out
The integration surface is deliberately small: one HTTPS endpoint, POST /v1/decide. A request carries state — text, JSON, or up to 16 images or video frames — plus the questions you have defined in code. The response returns typed answers for all of them in a single pass, which is the practical difference between one call and a chain of classify-then-extract-then-generate calls whose failure modes multiply at every hop.
Each answer type maps to a real operational need. Choice covers routing and classification where the label set is yours, not the model’s. Score covers severity and priority on an ordered scale, so a triage queue can be sorted rather than bucketed. Truth covers gating and risk, returning that calibrated 0.00–1.00 you can compare against a number in a config file. Number covers quantity estimation on a defined grid. Point and box cover spatial questions — where the defect is, where the object sits in the frame — without a separate vision pipeline. Every answer carries its own calibrated confidence, so different questions in the same request can have different thresholds.
DecisionNode exposes two model tiers. DecisionNode Flash runs around 5 ms server-side and 19 ms end to end at $0.035 per 1M input tokens; DecisionNode MoE runs around 9 ms at $0.042 per 1M input tokens. Output tokens are always free, batch discounts are available, and there is a free daily tier. That pricing shape matters for planning: cost tracks what you send, not what comes back, so a request with six questions costs the same as a request with one. For loops that exceed 10 decisions per second — drones, robots, simulators, machine monitoring — sessions over WebSocket remove per-request handshake overhead from the control path.
Where a decision depends on primitives rather than reasoning, boosters handle them directly: human age estimation, AI-generated image detection, face detection and recognition, OCR, depth and segmentation. SDKs exist for TypeScript, Python, Go, Ruby and curl, along with MCP tools, webhooks and AI agents that decide before acting — useful when an agent needs a typed verdict before it touches a downstream system.
Where Decision Engines Earn Their Place in Production
The use cases that benefit most share a shape: high volume, a small set of allowed outcomes, and a real cost to being wrong. Ticket routing and triage is the canonical example. A request asks for choice over a queue vocabulary, a score for urgency, and a truth probability that the requester is on an enterprise contract. Above 0.90 the ticket auto-routes; between 0.60 and 0.90 it routes with a review flag; below 0.60 it goes to a human queue by default. The confidence is not decoration — it is the branch condition, and the thresholds live in version control next to the schema.
Fraud and promo-abuse checks follow the same pattern with money attached. A request returns a truth probability that the account is a duplicate or synthetic identity, plus a number for estimated order value; the decision layer blocks above one threshold, holds in a middle band, and releases below it. Order and shipping decisions use choice for carrier or exception path and score for delay risk. Moderation and gating use combinations of truth and choice where the label set is policy-defined and must not drift.
Visual inspection is where the typed output earns its keep. Quality control on a production line can send frames and ask for a choice of defect type, a score for severity, and a box locating the flaw — all in one response, all deterministic. Because identical frames return identical answers, a schema change can be evaluated by replaying last month’s captures and diffing outcomes, which is close to impossible when the classifier is a prompted chat model returning prose. Warehouse and traffic monitoring run the same loop at higher frequency through WebSocket sessions, feeding dashboards and alerts rather than batch reports.
For platform and ops teams, the migration story is usually the same: retire a brittle hand-written rule tree or a slow chat-LLM “reply in JSON” call, and replace it with a declared schema against a decision API. Route high-volume, low-ambiguity paths to DecisionNode Flash to keep the request budget tight, and reserve DecisionNode MoE for the cases where reasoning depth changes the answer. Instrument the confidence distribution from day one — a healthy system shows a stable share of decisions landing above threshold, and that curve is the earliest signal that an input distribution has shifted and a schema needs revisiting.
