Most teams that need a model to make a call inside a running service start with the same shortcut: send a prompt to a chat LLM, ask it to “respond only in JSON,” then parse whatever comes back and hope it matches the expected shape. It demos well and fails in production. The model wraps output in markdown fences, invents an enum value you never defined, adds a friendly sentence before the JSON, or returns a different answer for the same input twice in a row. There is no confidence attached, so your code has no principled way to decide when to act and when to escalate. A decision API replaces that improvisation with a contract: you declare questions in code, send state, and receive schema-valid typed answers in one pass, each carrying a calibrated confidence your service can branch on.
What a Decision API Is and Why Prompted JSON Breaks Down
The difference is architectural, not cosmetic. A generative call produces a stream of tokens, and the structure you care about is a byproduct of phrasing. Everything downstream — parsing, retries, regex repair, fallback prompts — exists to undo that ambiguity. A decision engine inverts the flow. The question set lives in your codebase, so the request already describes the shape of the answer. You send state as text, JSON, or up to 16 images and video frames, plus the questions you want answered, to a single HTTPS endpoint (POST /v1/decide), and the response contains only answers to those questions in one pass. No chain of prompts, no second call to reformat, no model-authored keys.
The failure modes disappear one by one. Invented labels are impossible because the answer space is a closed set you supplied. Markdown fencing is irrelevant because there is no prose channel. Nondeterminism is replaced by determinism: the same request yields the same answer, which makes decisions testable, replayable, and cacheable, and gives you an audit trail a reviewer can re-run months later. Latency stops being a guess. Platforms like DecisionNode expose this as a hosted decision api where the request is a state payload plus typed questions, and the response is a typed decision object rather than text — a fundamental shift from “generate something that looks like an answer” to “answer these specific questions, in this specific format, with a stated probability.”
For platform teams, the practical consequence is that decision logic becomes ordinary software engineering. Questions are versioned alongside the services that call them, changes go through code review, and integration tests assert on answer types rather than string contents. There are official SDKs for TypeScript, Python, Go, Ruby, and plain curl, plus MCP tools, webhooks, and agent integrations, so the decision step slots into existing pipelines instead of becoming its own bespoke subsystem. Ops and automation teams get the same benefit: rules they used to hand-write as sprawling conditionals can be expressed as a small set of declared decisions with explicit confidence handling.
Typed Answer Primitives: Choice, Score, Truth, Number, Point, and Box
The value of a decision contract comes from having a small, well-chosen set of answer types. DecisionNode returns six. Choice picks exactly one label from your enum — a ticket category, an order disposition, a moderation verdict. Score places the input on an ordered scale you define, such as severity 1–5 or risk tier A–F, preserving rank rather than collapsing everything into a binary. Truth returns a calibrated probability between 0.00 and 1.00 for a yes/no claim, and this is the primitive that most changes how teams write code. Number returns a value on a grid when you need a quantitative estimate rather than a class. Point and box return locations inside an image, which turns visual checks into structured data instead of a description of what the model saw.
Calibration is the property that makes confidence usable. A well-calibrated 0.87 means the claim is correct about 87 times out of 100 across similar inputs, so a threshold is a real risk setting rather than an arbitrary cut on an unnormalized logit. That enables the pattern that production systems actually need: act instantly above a threshold, and take a safe path below it. A fraud check might auto-block above 0.95, auto-approve below 0.10, and route the middle band to a human queue with the triggering evidence attached. A quality-control step on a production line might accept a box verdict above a threshold and flag the frame for operator review otherwise, without stopping the line to ask an LLM to explain itself. Gating logic, promo-abuse checks, and content moderation all follow the same shape.
Answer types compose cleanly in a single request: one call can return a choice for routing, a score for priority, and a truth value for whether escalation is warranted, all validated against the schema you declared. When the state includes images, optional boosters add structured perception to the same decision — OCR for scanned documents, face detection and recognition for access flows, human age estimation for age-gated content, AI-generated image detection for authenticity checks, and depth or segmentation for spatial reasoning. Each booster enriches the state; the questions and the typed answer contract stay the same, so downstream code does not need to change when perception requirements grow.
Latency Budgets, Throughput, and Where Decisions Fit in Production
Decision-making inside a request path has a latency budget, and it is usually small. A decision engine that returns in single-digit milliseconds server-side changes what is feasible. DecisionNode Flash runs at roughly 5 ms server-side and 19 ms end to end at $0.035 per 1M input tokens, while DecisionNode MoE runs at roughly 9 ms at $0.042 per 1M input tokens. Output tokens are always free, batch discounts are available, and a free daily tier covers development and small workloads. Compared to a chat completion that may take hundreds of milliseconds to seconds and bills for generated output, this is a different category of cost and timing — cheap enough to run on every ticket, order, or frame, and fast enough to sit in front of a user-facing action without a spinner.
For sustained loops above roughly 10 decisions per second, sessions over WebSocket avoid per-request overhead entirely. That is the regime for drones and robots adjusting behavior in real time, simulators generating environments, and machine monitoring that evaluates sensor and camera state continuously. Warehouse operations can evaluate frames for misplaced pallets or blocked aisles, traffic monitoring can classify conditions from video, and AI agents can call a decide step before acting rather than generating an intent and correcting it afterward — a pattern that keeps autonomous behavior inside declared, testable bounds.
The rollout pattern that works is unglamorous and effective. Start in shadow mode: call the endpoint on live traffic, log the typed answer and its confidence, and compare against existing rules or human outcomes without acting on anything. Because responses are deterministic, the same inputs can be replayed against a revised question set before deployment. Once confidence distributions are visible, set thresholds from observed data — for example, choose the point where precision on auto-approvals matches the policy the business signed off on. Then move the decision into the live path, keeping the below-threshold branch as an explicit, monitored fallback. Ticket routing and triage, fraud and promo-abuse checks, order and shipping dispositions, moderation, scoring, gating, and quality control all benefit from the same sequence: declare the questions, measure calibration on real inputs, then let code act on confidence instead of guessing at prose.
Fortaleza surfer who codes fintech APIs in Prague. Paulo blogs on open-banking standards, Czech puppet theatre, and Brazil’s best açaí bowls. He teaches sunset yoga on the Vltava embankment—laptop never far away.