OpenAI DevDay 2026: What the Agents API and Decisions API Teach About API Design

OpenAI’s DevDay last week was mostly pitched as an agents event. Persistent agents, cloud Codex, a cheaper model. Fine. But if you’re learning to build and design APIs, two of the smaller releases are worth more of your attention than the headline model, because they say a lot about where API contracts are going.

Here’s what shipped, then what to take from it.

What OpenAI released

The Agents API is now in public beta. It runs agents on OpenAI’s own infrastructure, with memory, tool calling, tool search, context compaction and multi-agent support carried over from Codex. The new piece is computer use: an agent can now drive software through its graphical interface, clicking and typing the way a person would.

Then there’s the Decisions API, in limited preview. It’s small and quite odd for an AI launch. You hand it text or an image plus a fixed list of possible answers, and it picks one. That’s it. OpenAI pitches it for classification, request routing and choosing an agent’s next step, and it runs on the small Luna model.

GPT-6.1 Sol also landed, priced at a fifth of the bigger Astra model per token, with cached input at $0.10 per million tokens. And ChatGPT plugins can now react to events in connected apps through a proposed MCP Events spec.

Lesson one: a closed answer set is a contract

The Decisions API is basically an old API design rule sold as a product. When a caller needs to act on your response, give them a finite set of values they can switch on. Don’t give them prose.

Free text from a model is hard to build on. Your code has to parse it, guess at intent and handle the case where the model gets creative. A response that can only be refund, escalate or close is something a program can trust. You can write a test for every branch.

You don’t need a special endpoint to get this. Any API you design can enforce it with an enum in the schema:

{
  "type": "object",
  "properties": {
    "route": {
      "type": "string",
      "enum": ["billing", "technical", "sales", "human"]
    },
    "confidence": { "type": "number", "minimum": 0, "maximum": 1 }
  },
  "required": ["route"],
  "additionalProperties": false
}

Two habits to pick up here. First, include an escape value like human or unknown so the caller is never forced into a wrong bucket. Second, set additionalProperties: false so nobody quietly starts depending on fields you never promised.

Adding a new enum value later is a breaking change for any client with an exhaustive switch. Version it, or document up front that clients must handle values they don’t recognise.

Lesson two: computer use is what happens when there’s no API

An agent clicking through a UI is slow and brittle. A button moves and the run breaks. It costs more too, since every step needs a screenshot and a model call.

So why build it? Because a huge amount of business software still has no usable API. Old ERPs. Government portals. Internal admin panels nobody documented. Computer use is the fallback for all of that.

For you, the takeaway is commercial. If your product only has a UI, agents will still get in, just badly. If it has a clean, documented API, agents will pick it first because it’s cheaper and more reliable for them. In 2026 a good API is how you stay usable by the software that’s increasingly doing the work.

Lesson three: events are coming to agent protocols

The MCP Events proposal is a webhook story. Until now most agent tooling has been request and response: the agent asks, the tool answers. Events flip that. Something changes in a connected app, and the agent gets told.

If you’ve built webhooks you already know the hard parts, and they don’t go away because the subscriber is an AI:

  • Sign every delivery so the receiver can verify where it came from
  • Send an idempotency key, because deliveries get retried and duplicates will happen
  • Keep payloads thin and let the receiver fetch details, so you don’t leak data into logs
  • Document retry timing and what happens after the last failure

Agents acting on events without these protections will do things twice, or act on forged input. That’s a worse failure than a duplicated email.

What to practise this week

Take one endpoint you’ve built that returns free text or a loose string status. Rewrite its response schema with an enum, add an unknown value, and write a client that switches on it exhaustively. Then add a new value and watch what breaks. That small exercise covers most of what the Decisions API is really selling.

Related