Ask a chat model to respond only with valid JSON and you get a probabilistic text generator wearing a schema’s clothing. Sometimes the JSON parses. Sometimes it arrives wrapped in prose, sometimes a label appears that was never in your enum, and sometimes the same request produces a different answer twenty minutes later. For prototypes that is tolerable. For ticket routing, fraud checks, order gating, or a robot deciding whether to move, it is a liability. A decision API takes a different approach: instead of generating language and hoping the shape is correct, it returns a typed, schema-valid decision in a single pass, with a calibrated confidence attached so your code knows whether to act or escalate.
What a Decision API Returns: Typed Answers Instead of Parse-and-Pray Output
The core idea is to separate the question from the answer. With a decision API, developers send state — plain text, JSON payloads, or up to sixteen images and video frames — together with questions that are defined in code, to a single HTTPS endpoint. DecisionNode, for example, exposes a decision api built around one POST route, /v1/decide, so there is no model selection at runtime and no prompt engineering in production. The questions live in your repository, which means a malformed question fails at deploy time rather than at 3 a.m. under load.
What comes back is deliberately narrow. Instead of free-form text, the response contains one of a small set of answer types. A choice is exactly one of the labels you supplied — no near-misses, no invented categories. A score is a level on an ordered scale, which is what you want for severity, priority, or quality bands. A truth is a calibrated probability between 0.00 and 1.00, useful when a downstream service needs a number rather than a verdict. A number is a value constrained to a grid you define, which keeps estimates inside sane bounds. Point and box answers return locations inside an image, which is how visual checks become machine-readable without a separate computer-vision pipeline.
The detail that changes how teams write code is calibration. Every answer carries a calibrated confidence, meaning the number attached to a decision is meant to reflect observed accuracy rather than the model’s internal bravado. That single property enables a pattern most rule engines cannot express: act instantly when confidence clears your threshold, and route to a human, a retry, or a safe default when it does not. You stop treating every prediction as equally trustworthy and start treating confidence as a control signal.
Determinism matters just as much for engineering hygiene. The same request producing the same answer sounds like a low bar until you try to write a regression suite against a chat endpoint. With a deterministic decision API, you can record real production payloads as fixtures, replay them in CI, and get a stable diff when behaviour changes. Audits become a matter of re-running a request rather than re-reading a transcript. DecisionNode explicitly guarantees that property, which is why the outputs behave like a function call rather than a conversation.
Where Decision APIs Fit: Replacing Brittle Rules and Slow Chat Calls
Most teams arrive at a decision API from one of two directions. The first is a hand-written rules layer that has quietly become unmaintainable. What started as three if statements in an order service is now a cascade of nested conditions, exception tables, and undocumented overrides that only one engineer understands. Rules are excellent at expressing policy and terrible at consuming unstructured input: a support message, a photo of a damaged parcel, a frame from a warehouse camera. A decision API lets you keep policy in code while delegating the ambiguous judgement — which queue does this ticket belong to, is this promo code abuse, does this frame show a blocked aisle — to a model that returns a label you can switch on.
The second entry point is the chat-model-in-production pattern. A team wraps a general-purpose model in a retry loop, validates the JSON, and discovers that latency is unpredictable, cost scales with verbose output, and the same input drifts across versions. A decision API inverts those economics: output tokens are effectively free because there are no output tokens, just typed fields. DecisionNode’s Flash model runs at roughly 5 ms server-side and 19 ms end to end, priced at $0.035 per million input tokens, while the MoE model runs around 9 ms at $0.042 per million. For a routing decision inside a request handler, that is fast enough to sit on the critical path rather than in a background job.
The use cases cluster around triage and gating. Ticket routing and triage maps a message plus metadata to a queue and a priority score. Fraud and promo-abuse checks return a truth value that a payment service thresholds. Order and shipping decisions pick a fulfilment path or flag an address for review. Moderation returns a choice plus a severity score. Quality control on a production line turns camera frames into pass, rework, or reject. Warehouse and traffic monitoring ask positional questions about frames. Optional boosters — human age estimation, AI-generated image detection, face detection and recognition, OCR, depth and segmentation — extend those answers without you standing up separate pipelines.
Latency, Determinism, and How Teams Actually Integrate a Decision API
Integration starts small. A single HTTP call with a JSON body is enough for most services, and SDKs for TypeScript, Python, Go, and Ruby (plus plain curl) mean the first decision can land in an afternoon. The architectural work is in deciding where the threshold sits. A common pattern is a two-tier policy: above 0.90 confidence, act automatically; between 0.60 and 0.90, call a second, more expensive decision or attach a review flag; below 0.60, route to a human queue. Because every response is schema-valid, that branching logic is ordinary typed code, not defensive parsing. Teams typically emit the confidence as a metric alongside the decision, which makes it easy to see drift before it becomes an incident.
Throughput shapes the transport. Request-response over HTTPS handles the overwhelming majority of product and ops workloads, where decisions happen per ticket, per order, or per inspection. When the loop exceeds roughly ten decisions per second, session-based connections over WebSocket are the better fit — the pattern that shows up in drones, robots, simulators, and continuous machine monitoring, where a controller needs a fresh decision on every tick and cannot absorb per-call handshake overhead. Batch discounts and a free daily tier make it practical to run shadow mode first: send production traffic to the decision API, log what it would have decided, and compare against your existing rules before switching anything over.
Two real-world shapes illustrate the range. On a support platform, a ticket arrives as text plus structured account data; the service asks for a choice over eight queue labels and a score for urgency, acts immediately above threshold, and pages a human when confidence collapses — replacing a rules file that had grown to thousands of lines. On a manufacturing line, a camera frame becomes a box answer around a defect with a truth value attached; a robotic arm rejects the part when the probability clears 0.85 and flags the frame for review otherwise. The same endpoint, the same typed contract, two very different operating environments.
For teams building AI agents, the decision API has a distinct role: it is the component that decides before the agent acts. An agent that must choose between refunding, escalating, or requesting more information can call a decision endpoint and receive a label with a confidence, then let the language layer handle only the communication. Webhooks and MCP tools let that pattern slot into existing automation without a bespoke orchestration service, and the deterministic contract means an agent’s behaviour is reproducible when you debug it. The practical outcome is a system where judgement is a typed dependency — versioned, testable, observable — rather than a prompt buried in a string constant.
Gothenburg marine engineer sailing the South Pacific on a hydrogen yacht. Jonas blogs on wave-energy converters, Polynesian navigation, and minimalist coding workflows. He brews seaweed stout for crew morale and maps coral health with DIY drones.