Decision AI: When Your Code Needs an Answer, Not a Conversation

Most teams that tried to bolt an LLM onto a production workflow have lived the same failure mode. The prompt asks for JSON, the model returns JSON wrapped in an apology, a markdown fence, and an extra sentence about being a helpful assistant. The parser breaks. Someone adds a retry loop. Latency climbs from 300 ms to four seconds because the fix was “ask it again with more instructions.” Six weeks later, the workflow is quietly routed back to hand-written if/else rules because nobody trusts the model’s output shape, and nobody can explain why it said “high risk” on Tuesday and “low risk” on Wednesday for identical input.

Decision AI is the architectural answer to that pattern. Instead of treating a language model as a text generator you hope will behave, a decision engine treats it as a function: state goes in, a typed verdict comes out, once, with a measured confidence attached. The output space is constrained by the questions you define in code — not by whatever the model felt like emitting. That distinction matters more to developers than any benchmark score, because it decides whether an answer can be acted on or merely read.

The practical form of this is an endpoint, not a chat window. The system you send work to — the decision ai model behind DecisionNode, for example — accepts state as plain text, as JSON, or as up to 16 images and video frames, plus a set of questions declared in your codebase. You post all of it to a single HTTPS route and get back answers that conform to a schema: choice (one label from the list you supplied), 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 for locations inside an image. No prose. No parsing. No second pass to clean up the first.

The property that changes how you write the surrounding code is calibration. Every returned answer carries a confidence that is meant to be read literally: when the engine says 0.9, roughly nine in ten of those are correct across the distribution. That lets you branch on a threshold instead of guessing — act immediately above it, escalate to a human queue, re-check with a different question set, or follow a deliberately safe path below it. Combined with determinism (same request, same answer, every time) you get something rare in the AI stack: a component you can unit-test, replay from a stored request, and explain to an auditor.

Designing the Contract: Questions in Code, Verdicts Over the Wire

Adopting decision AI is mostly an exercise in interface design, and the interface is the question set. You are not writing prompts in the usual sense; you are declaring a small, stable vocabulary of decisions your system is allowed to make — which queue does this ticket belong to, is this order address deliverable, does this frame contain a defect, what age bracket does this face fall into. Because those questions live in version control next to the code that consumes them, a change to the decision surface becomes a pull request with a diff, a reviewer, and a rollback path rather than a prompt edit in someone’s dashboard.

That contract has practical consequences worth planning for. First, keep the label sets small and mutually exclusive; a choice question with forty options is harder to calibrate and harder to reason about downstream than four questions with five options each. Second, prefer measuring over classifying when the underlying quantity is ordered — a score on a defined scale preserves ranking information that a flat label throws away, which is exactly what you want for prioritisation, gating, and moderation severity tiers. Third, treat the confidence value as a first-class field in your database. Logging it alongside the verdict gives you the raw material for drift detection: if the share of answers sitting at 0.6 climbs week over week, your input distribution has moved and your thresholds need review.

Latency and cost shape the rest of the design. A model tuned for single-pass decisions rather than long generation runs cheaply in wall-clock terms — DecisionNode Flash lands around 5 ms server-side and 19 ms end to end, with DecisionNode MoE around 9 ms — and is priced per input token at roughly $0.035 and $0.042 per million respectively, with output tokens free. For developers, the interesting part is not the headline number but what it permits: you can put a decision call inline in a request handler that a user is waiting on, rather than hiding it behind a queue and a spinner. Batch discounts and a free daily tier make it viable to backfill and evaluate question sets against historical data before switching them on.

The integration surface is deliberately boring, which is a compliment. SDKs exist for TypeScript, Python, Go, and Ruby, plus plain curl for anything else, so the call fits whatever service owns the workflow. Where you exceed roughly ten decisions per second in a tight loop — drone control, robotics, simulation stepping, continuous machine monitoring — a WebSocket session avoids per-request handshake overhead. Webhooks and MCP tools let agents invoke decisions as a tool call, which is the pattern that matters most for autonomous systems: decide before acting, rather than act and then narrate.

Decision AI in Production: Triage, Fraud, Vision, and the Ops Floor

The workflows where decision AI earns its keep share a shape: high volume, a small number of recurring judgement calls, and a real cost attached to being wrong in either direction. Support ticket routing is the canonical example. A choice over your existing queue labels, paired with a score for urgency, replaces a stack of keyword rules that silently rot as product names change. Tickets above the confidence threshold route automatically; the ambiguous remainder goes to a human who now spends their time on the genuinely hard cases instead of the obvious ones.

Fraud and promotional abuse follow the same logic with a different risk profile. Here the truth primitive does the heavy lifting: a calibrated probability that an account, order, or redemption attempt belongs to a class you care about. Because the number is calibrated rather than merely ranked, you can set the auto-block line high and the manual-review band underneath it, and you can tune both against measured outcomes instead of vibes. Order and shipping decisions — address validity, exception handling, fulfilment routing — benefit from the same structure, with the added advantage that a deterministic engine makes post-incident reconstruction straightforward.

Visual decisions are where the input format earns attention. Sending up to 16 images or frames in one request means a single call can answer multi-part questions about a scene rather than stitching together a pipeline of separate models. On a production line, a box answer localises a defect while a choice classifies it and a score grades severity — three typed outputs from one pass, ready to write straight into a quality-control record. In warehouse and traffic monitoring, frame sequences carry the temporal context that single stills lack, so questions about congestion, obstruction, or unsafe proximity become answerable at the edge where the decision has to be made.

DecisionNode also ships focused boosters for sub-problems that would otherwise justify their own vendor: human age estimation, AI-generated image detection, face detection and recognition, OCR, and depth and segmentation. For product and ops teams, the appeal is consolidation — one endpoint, one schema, one confidence semantics, one bill, instead of five integrations with five different output conventions and five failure modes. Moderation queues, KYC-style gating, document intake, and synthetic-media checks stop being separate engineering projects and become additional questions in an existing question set.

The teams getting the most out of this pattern treat decision AI as infrastructure rather than as a feature: they version question sets, monitor confidence distributions, replay stored requests in CI, and keep a documented safe path for every threshold they set. That discipline is what separates a workflow that survives its first messy month in production from one that quietly reverts to rules — and it is the difference between an AI component your on-call engineer trusts at 3 a.m. and one they mute.