OpenAI's Decisions API: Real-Time Agentic Decision-Making for Enterprise Workflows, Explained
Buried inside OpenAI's DevDay 2026 announcement list alongside GPT-6.1 Sol and Dots agents was a smaller, more technically specific release: a Decisions API built for real time decision making against predefined answer sets. Where the Agents API and a general purpose agent loop are built for open ended reasoning across an unbounded task, the Decisions API is built for the opposite case, a small number of valid outcomes and a requirement that the choice happen fast. This post works through what that distinction actually means in practice and where a bounded decision primitive fits into an existing agentic workflow.
OpenAI's Decisions API: Real-Time Agentic Decision-Making for Enterprise Workflows, Explained
Inside OpenAI's DevDay 2026 announcement list, alongside the more heavily covered GPT-6.1 Sol pricing cut and Dots agents, was a smaller and more technically specific release: a Decisions API built for real time decision making against predefined answer sets. It shipped alongside an Agents API update adding computer use capability, and the two are easy to conflate because both ship under the same agentic framing. They are built for different jobs, and the distinction matters for anyone deciding which primitive to reach for in a given workflow.
The core distinction
| Capability | Agents API (with computer use) | Decisions API |
|---|---|---|
| Task shape | Open ended, multi step, unbounded reasoning | Bounded choice from a predefined set of valid answers |
| Typical latency profile | Seconds to minutes, depending on task complexity | Built for real time, low latency response |
| Output space | Free form, generated as the agent reasons | Constrained to answers defined ahead of time |
| Best fit | Exploratory or multi step tasks where the path is not known in advance | High frequency decisions where the outcome set is small and known |
Why a constrained decision primitive is not a step backward
It is tempting to read a bounded, predefined answer set as a less capable version of a general agent loop, but that framing misses what actually makes a system reliable in production. A general purpose agent reasoning openly about which action to take next is appropriate when the task genuinely has an unknown number of valid paths to a solution. Most production decisions inside an enterprise workflow are not that. A routing decision, a fraud flag, an approve or escalate choice, an inventory allocation call, these are all situations where the valid outcomes are enumerable ahead of time, and the actual problem is picking the right one quickly and consistently, not discovering what the possible outcomes even are. Building that kind of decision on top of a general agent loop means paying for open ended reasoning capability you do not need and, more importantly, accepting output variance you do not want. A predefined answer set removes an entire class of failure mode: the agent inventing a response that was never a valid option.
Where this fits next to computer use and Dots agents
The Agents API's new computer use capability is the right tool when a workflow genuinely requires navigating an interface, interacting with a UI the way a human would, because no structured API exists for the underlying system. Dots agents, OpenAI's always on persistent agent product, are suited to ongoing, evolving responsibilities where the task itself changes over time based on what the agent learns about a user's priorities. The Decisions API sits apart from both: it is not trying to navigate anything or maintain ongoing state, it is a narrow, fast, constrained decision function you call inside a larger workflow, whether that workflow is orchestrated by a Dots agent, a computer use agent, or conventional application code with no agent framing at all.
The governance angle this actually improves
Contra Collective has written previously about the audit and oversight challenges that come with persistent, always on agent deployments, where the core problem is that an agent's action space is effectively unbounded and its reasoning path is not always fully inspectable after the fact. A Decisions API style primitive is a genuine improvement on that specific axis for the workflows where it applies. When every possible outcome is defined in advance, an audit trail becomes meaningfully simpler: you are checking which of N known outcomes was selected and whether the inputs justified that selection, not trying to reconstruct an open ended reasoning chain to understand why an agent took an action nobody anticipated. For risk sensitive workflows, that is a real governance advantage, not just a performance optimization.
Where it fits in commerce and catalog workflows specifically
For teams working in agentic commerce, structuring product data for AI shopping agents already requires thinking in terms of bounded, well defined attributes rather than free text, because that is what lets an agent make a correct selection reliably. A Decisions API style primitive is a natural fit for decisions inside that pipeline that have a small enumerable outcome set: which fulfillment option to select given inventory and delivery constraints, which promotional offer applies to a given cart state, whether a given order requires manual review. These are exactly the shape of problem a constrained decision API is built for, as opposed to the open ended product discovery and recommendation work that benefits more from a general reasoning agent.
What to actually evaluate before adopting it
Map your existing agentic workflows and separate the genuinely open ended decisions from the ones that already have an enumerable, known outcome set, even if your current implementation routes all of them through a general agent loop. The second category is where a Decisions API style primitive pays off immediately, in latency, cost, output reliability, and auditability. Do not migrate the first category, the truly open ended tasks, onto a constrained decision primitive just because it is faster; that will produce a system that cannot actually handle the cases it was built for.
When this applies to your stack
If your team is running agent based workflows where some portion of the decisions being made are actually bounded and enumerable, even if your current implementation treats them as open ended, a constrained decision primitive is worth evaluating specifically for those cases, independent of whether you are on OpenAI's stack or building the equivalent pattern yourself.
Contra Collective builds and audits production agentic workflows for enterprise clients, including the decomposition work that separates genuinely open ended reasoning tasks from bounded decisions that do not need a full agent loop. If your current agent architecture routes everything through the same general purpose reasoning path, that decomposition is worth doing before latency and auditability become the blocker.
FAQ
Is the Decisions API a replacement for the Agents API? No. They solve different problems. The Agents API, including its new computer use capability, is for open ended, multi step tasks. The Decisions API is for fast, bounded decisions against a predefined set of valid outcomes.
What kind of workflows are a good fit for the Decisions API? Any decision where the set of valid outcomes is known and enumerable ahead of time and speed matters: routing, approve or escalate flags, fulfillment option selection, and similar bounded choices.
Does using the Decisions API remove the need for agent governance and oversight? No, but it changes the shape of that oversight. Auditing a bounded decision against a known outcome set is simpler than reconstructing an open ended reasoning chain, which is a real advantage, but the decision still needs monitoring for whether the right outcome was selected given the inputs.
Can the Decisions API be called from inside a Dots agent or a computer use agent? The announcement frames it as a general purpose primitive usable inside a larger workflow, which would include being called from another agent type, though teams should confirm current integration patterns against OpenAI's own documentation as the API matures.
More from the lab.
The Model Context Protocol's STDIO Problem: Inside the Latest Remote Code Execution Disclosure
Security researchers at OX Security found that the Model Context Protocol's STDIO transport interface runs any process command passed to it on the host system before it ever confirms the subprocess is a valid MCP server, an execute first, validate never pattern that completes an injected command even when the caller eventually gets an error message back. The scope is not small: 150 million downloads across package registries, more than 7,000 publicly accessible MCP servers, and up to 200,000 vulnerable instances across every officially supported SDK, Python, TypeScript, Java, and Rust. Anthropic's response, after OX disclosed in January 2026, was to update documentation and call the behavior intentional. Here is what that actually means if your team runs MCP servers over STDIO.
Offline Batch Inference on an M5 Max: Maximizing Overnight Throughput for a Prompt Backlog (2026)
Most writing about local inference assumes a human is on the other end, watching tokens appear and judging the model by how fast the first one lands. Batch work is the opposite situation, and it is more common than the interactive framing suggests: you have a backlog of tens or hundreds of thousands of prompts, nobody is waiting on any single one, and the only thing that matters is how much of the pile you can clear before morning. Product descriptions for a catalog, classification over a support archive, embeddings and summaries for a corpus, synthetic data for a fine tune. In that regime latency is irrelevant and throughput is everything, and the settings that make a local server feel responsive to a person actively work against you, because they optimize for the wrong number. Running one prompt at a time on an M5 Max leaves most of the machine idle, since a single decode stream cannot saturate the memory bandwidth the chip has to offer. The job is to keep many sequences in flight so the expensive weight reads are amortized across all of them, and to arrange the backlog so the GPU never waits on padding, scheduling, or a slow tail. This post is about doing that deliberately: what actually bounds batch throughput on Apple Silicon, how far batching takes you before memory stops you, and the operational scaffolding that turns a fragile overnight run into one you can resume when it dies at 3am.
Semantic Response Caching for a Local LLM Gateway on Apple Silicon: Cutting Redundant Inference on an M5 Max (2026)
Prompt caching skips the prefill on a repeated prefix, but it does nothing for two users who ask the same thing in different words. On a single Apple Silicon box, where every generation competes for the same unified memory, the cheapest token is the one you never generate. Semantic response caching sits in front of the model, embeds the incoming prompt, and if a past prompt was close enough in meaning it returns the stored answer without touching the GPU. The hard part is not the cache. It is deciding when two questions are actually the same question, because a threshold set too loose will confidently serve the wrong answer. This post builds the gateway, measures the hit rate on a real support workload, and sets the similarity threshold where a wrong answer costs more than a cache miss.