OpenAI's DevDay was loud. Always-on agents called Dots, a cheaper GPT-6.1 Sol, a shared workspace called ChatGPT Space, Codex running in the cloud. Most of the coverage went to the agents that get their own computers.
The announcement I'd pay attention to is the quiet one. The Decisions API lets a company hand a narrow, repetitive choice to a model, but only if you give it a fixed set of possible answers. The model picks one. That's it. Per the DevDay coverage, those fixed-option questions get routed to a smaller model called Luna.
Why a boring feature matters
Most of the agent failures we see in production are not reasoning failures. They're open-endedness failures. The model was allowed to say anything, so eventually it said something you didn't plan for.
Think about the decisions inside a typical business workflow:
- Is this support ticket a refund, a bug report, or a sales question?
- Does this order need manual review, yes or no?
- Which of our five warehouses should ship this?
- Should this PR go to the security reviewer or the normal queue?
None of these need a paragraph of prose. They need one of N answers, and a downstream system that knows what to do with each answer. When you constrain the output, you can test it, log it, and route on it. You can also run it on a cheap model, because picking from a short list is a much easier job than writing an essay.
What we'd do with it
If you're building automations, the pattern is worth copying whether you use this specific API or not.
Turn every judgment call into an enum. Take your agent loop and find the places where the model decides something. Write down the allowed outcomes. If you can't list them, you haven't understood the decision yet, and that's useful to find out before launch.
Add an explicit "none of the above" option. A closed list with no escape hatch forces the model to guess. Give it an unsure outcome that routes to a human. Then track how often it fires. That number tells you more about your workflow than any benchmark.
Log the choice and the inputs together. A fixed answer is easy to store. Six weeks from now, when someone asks why order 4471 got flagged, you want a row, not an archaeology project. This is the same audit trail argument we keep making about agents in general.
Run it on the cheap tier. Classification into a short list is where small models do fine. We'd test the smallest model that clears your accuracy bar on your own data, not on a vendor chart.
The catch
A fixed list is only as good as the list. If your categories overlap, the model will split hairs and your accuracy will look worse than it is. If the real world has a sixth option you forgot, you'll see it as a pile of low-confidence guesses. Review the misses every week at the start. The list will change more than you expect.
Also, don't treat this as a reason to lock yourself to one vendor's endpoint. The idea is portable. A schema-constrained call to any decent model gets you most of the way there.
The flashy agents will get the headlines. The teams that ship will be the ones who figured out which decisions never needed an agent at all, just a good list and a fast, cheap pick.
We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!