OpenAI DevDay 2026: Decisions, Dots, and the New Agent Stack
OpenAI’s DevDay 2026 was less a model launch than a systems announcement. The company used the event to connect product surfaces with decisions, continuity, and execution.
Together, they describe a stack for moving from a model that answers prompts to software that interprets state, selects bounded actions, and continues work across tools.
The announcement is fresh. DevDay took place on September 29, 2026, and OpenAI’s recap was published after the event. Several details remain in preview. Treat the product direction as verified and the implementation contract as provisional.
The number that matters
OpenAI reported more than 20 announcements spanning its product and developer surfaces. The count matters less than the way the announcements connect product surfaces to decisions, continuity, and execution.
The Decisions API turns a model call into a typed choice
The Decisions API is the sharpest technical signal in the announcement. OpenAI’s recap presents it as a near real time decision layer built around user defined questions with finite, predefined answers. That framing points to a bounded classification or routing task. OpenAI DevDay 2026 Recap
That is a different job from asking a general model to write JSON. With structured output, the model still performs an open ended generation task and formats the result inside a schema. With a decision surface, the application defines the answer space before inference. The model chooses from an allowlist.
Consider an intake workflow. A general model might produce a paragraph that says a request looks like a billing issue. The application then parses the paragraph, checks whether the label is valid, and decides what to do. A decision call can ask one narrower question: “Which approved queue owns this request?” The valid outcomes might be billing, account, technical, and manual_review.
The distinction matters because the answer becomes a control signal. The host application can log it, evaluate it, and pass it to deterministic code. It can also reject an outside the set answer, even when a model reports high confidence.
OpenAI’s public recap does not document a public endpoint, pricing, rate limits, calibration method, or stable SDK contract for the Decisions API. Treat those as open implementation questions. A confidence score, if exposed, would be evidence rather than an authorization decision. Code still needs to check permissions, resource scope, validity, and side effects.
Dots package continuity for everyday work
Dots address the other half of the agent problem: persistence.
OpenAI describes a dot as a proactive assistant that can keep working across complex projects and everyday tasks. The product connects to apps, keeps work moving between conversations, and uses auto-review to check actions that could affect accounts or share information against the user’s instructions, Custom Rules, and OpenAI’s safety requirements. Introducing dots
The article treats Dots as a managed experience rather than an API primitive. Developers may not get the same control over the tool surface, cost accounting, model version, or evaluation loop that they get when building an agent through an API. That is an architectural distinction for TPMs to validate against the product contract before adoption.
The value is different. Many recurring jobs never justify a dedicated internal system. A dot can take responsibility for a backlog of small tasks, a recurring research sweep, or a multi step administrative workflow without a team designing a full agent runtime.
The risk is also different. Persistence can hide state. When a dot continues work after the original conversation, the user needs a durable record of what it saw, which rule applied, what it changed, and when it handed work back. A product that feels continuous still needs operational boundaries.
The broader DevDay stack connects models to execution
The recap places the Decisions API beside updates to the Agents API, Codex, computer use, new models, and security tooling. This article uses those announcements to describe an operating model: a decision layer can choose among bounded actions, while an agent runtime executes tools and maintains state. OpenAI’s pages do not establish every boundary in this model as a formal product architecture.
The framework
This article uses five boundaries: interpretation, bounded decision, execution, policy, and human review. Each boundary should produce an observable artifact and a clear handoff.
This creates a useful architectural split:
- Interpretation: a frontier model reads the goal and creates a plan.
- Decision: a bounded layer chooses among approved next steps.
- Execution: an agent runtime uses tools and maintains state.
- Policy: application code checks permissions and side effects.
- Review: a human or review system handles actions that exceed the trust boundary.
That split is more important than any individual model name. Model quality still matters, but the production system depends on the contracts between interpretation, decision, execution, and review.
What this does not solve
- A typed choice does not make a taxonomy complete. Teams still need a manual path for inputs that do not fit.
- Persistent work does not make state visible. Record what the agent saw, changed, and handed back.
- Tool access does not grant authority. Enforce permissions and review high impact actions outside the model.
What technical program managers should watch
First, define the answer space before adopting a decision model. If the team cannot list the valid outcomes, the task may need reasoning or generation rather than a decision endpoint. Add none_of_the_above or manual_review when the world does not fit the first draft of the taxonomy.
Second, separate decision from authority. A model may recommend refund_review; it should not grant a refund. The service that owns the money, data, or account must enforce permission and approval rules.
Third, evaluate the seam. Test representative inputs, ambiguous cases, stale context, missing fields, timeouts, and transport failures. A timeout is not a confident “no.” A high score is not proof that the choice is correct.
Fourth, keep the provider behind an adapter while the preview changes. Verify the request schema, image support, score semantics, pricing, retention, regional access, rate limits, and model versioning before making the endpoint a hard dependency.
The signal that matters most
The strongest signal is the move from a single model call toward explicit operating boundaries. TPMs should ask where a decision is made, where authority is enforced, where state is recorded, and who reviews the result.
If your team is mapping an agent stack, send me the current boundary diagram and the failure case it is meant to prevent through LinkedIn.
The announcement’s real message
OpenAI is packaging intelligence into smaller operational building blocks.
The Decisions API narrows inference into a typed choice. Dots extend an assistant across time and connected tools. The Agents API and computer use connect decisions to execution. The DevDay recap frames these pieces as one developer platform rather than isolated features. OpenAI DevDay 2026
That direction puts pressure on teams to design better boundaries. The next failure will not always be a model that gives a wrong paragraph. It may be a valid-looking choice passed to the wrong tool, a persistent agent that acts on stale context, or a preview contract embedded in production code before its limits are known.
The practical takeaway is simple: use the Decisions API for bounded choices, Dots for managed continuity, and the Agents API for controlled execution. Keep policy, permissions, evaluation, and auditability outside the model. The new stack is promising. Its reliability will depend on the seams.
Evidence status
- Verified: DevDay 2026 occurred on September 29, 2026; OpenAI reported more than 20 announcements; the official recap describes the Decisions API, Agents API, computer use, Codex, and model updates.
- Verified: OpenAI’s Dots announcement describes proactive work across projects and tasks, connected apps, Custom Rules, and auto-review.
- Preview / unverified contract: public endpoint syntax, pricing, rate limits, score calibration, retention, image limits, and stable SDK support for the Decisions API. These details require a primary technical reference before implementation.
- Editorial synthesis: the layered model connecting decisions, execution, policy, and review. The official pages support the product announcements, not every boundary in this operating model.
- Confidence: high for the product direction; medium for implementation details because the public material leaves key contract details open.
Member discussion