On October 16 I was at OpenAI DevDay Exchange in Bengaluru, a smaller, invite-only regional version of the main DevDay that ran in San Francisco on September 29, built around technical sessions with OpenAI's product and engineering teams. I was lucky to be invited. A week earlier, Sarthi, a ChatGPT app I built over MCP, had placed 3rd at OpenAI's DevDay community hackathon, so I watched the day through one lens: which parts of an agent does OpenAI now want to own, and which are still mine?
The short version: the model is no longer the hard part of building agents. Everything around it is, and OpenAI is now productising each layer of it. I will group what I saw into three layers: build, run and ship.
The keynote
The keynote covered the major announcements: the Decisions API, Codex in the cloud, always-on agents, computer use, and a push to let developers build real businesses on top of ChatGPT. The rest of the day went deeper on each.
Layer 1: Build
Harness as a service and the Agents API
Every team building an agent ends up writing the same thing: a loop that calls the model, runs tools, keeps state and recovers from failure. That scaffolding is the "harness". The session on harness as a service and building with the Agents API argued that you should rent this rather than rewrite it for every project.
As announced, the Agents API now carries much of that loop. OpenAI runs the execution infrastructure, and the API brings tool search, tool calling, context compaction, multi-agent patterns from Codex, and computer use. What it does not take off your plate is the part I think matters most: what the agent is allowed to decide, what it can touch, and where a person has to approve. In Munim, my AI back office for restaurants, the agents have no write path to the books at all. No harness makes that decision for you.
Decisions API
The Decisions API is aimed at the small, frequent calls inside an agent: classification, routing and choosing the next action. It is in limited preview, and instead of writing free text it uses a smaller model, Luna, to pick from a set of answers you define, given text or image context.
That constraint is the feature. I used it in Sarthi as one of two verifiers on every number a user logs. Plain code checks that the number appears in what the user actually said, and the Decisions API can only move a value from "fact" down to "estimate", never up. Because it can only answer from options I wrote, it cannot invent a calorie count, which is exactly the failure I was guarding against. You should not pay a large-model price, or take a large-model risk, for every "which tool next?" decision.
Layer 2: Run
Always-on agents and Codex in the cloud
Codex can now run in cloud environments as well as on your own machine, so a task keeps going when your laptop is closed and can be picked up from another device. The session titled "What will you build with coding agents that don't quit?" was about what changes when an agent can work for hours without you watching it.
My takeaway: the interesting question moved from "can it write code?" to "can it keep going, recover from errors and still be right at hour three?" I have hit this on my own builds. Roomful, my events platform, was built in 17 days and 381 commits through an orchestrated agent build, and what kept the long runs honest was not the model but the process around it: tickets with done-when checks that can actually fail, an adversarial reviewer on every ticket, and fixes accepted only after a test had shown the bug first.
Codex Security
A session was dedicated to Codex Security: scanning repositories and new commits, investigating findings, removing duplicates and preparing fixes, with a review pass on pull requests.
What a security team still has to check by hand is anything that depends on intent. A scanner can flag a query that skips an authorisation check. It cannot know that in Roomful a declined connection request must look exactly like one that hasn't been answered yet. That rule lives in row-level security policies someone had to design, not in a pattern a tool can match.
Computer use
Computer use, now part of the Agents API, lets an agent operate software through its interface when there is no API. It is the escape hatch for the long tail of internal tools and legacy systems. I would still treat it as the last resort: slower and more brittle than a real API call, and worth putting behind the same approvals as any tool that can change data.
GPT Live and image generation
A session covered building with GPT Live (realtime voice) and image generation. I built Bahi, a voice-first ledger for small shops, around the idea that every speech and model vendor is a swappable part behind one eval suite. A realtime voice model is one more adapter, and it has to pass the same evals as the rest.
Layer 3: Ship
This was the part I found the most underrated.
Apps and plugins in ChatGPT
OpenAI is making ChatGPT a place to build a product, not just a tool people chat with. Developers can ship plugins that feel like native ChatGPT apps and are distributed through OpenAI, and the plugin system now supports sidebars, interactive panels inside the conversation and custom file viewers, with events coming through a proposed MCP Events specification.
Sarthi is built this way: a ChatGPT app over MCP with an inline panel, where the model can propose an entry but only a person's tap in the panel can save it.
Sign in with ChatGPT
This is the idea I keep coming back to. As announced, Sign in with ChatGPT does two things. It is a standard OAuth login, and the app receives basic profile details, not the user's conversations. And for users on paid plans, it can let their ChatGPT plan pay for the model usage inside a participating app, with a weekly cap per app.
If that holds up in practice, it changes the unit economics for a solo builder. For those users you do not carry the token bill, so there is no margin problem hiding behind your first thousand users. The caveats are real: it covers paid plans, not everyone, and a badly behaved app could burn through a user's weekly allowance, so expect people to be careful about which apps they connect.
Sites
The Sites session covered what web apps look like when the agent is a first-class part of the product. Sites for Codex builds internal tools and hosts them at a shareable URL with workplace sign-in built in.
The swag: custom Codex pets
Everyone at the event got custom Codex pets. It is a small thing, but it made the day feel like a community of people building with Codex rather than a conference.
What I am taking away
- The edge is system design, not model calls. What the agent can decide, what it can touch and when a human steps in.
- Reliability over a long horizon is the real product. Always-on agents make this the central problem.
- Distribution and economics are now part of the platform. Apps, plugins and Sign in with ChatGPT mean a solo builder can ship inside ChatGPT and, for paying users, without owning the inference bill.
What I will build next
Sarthi already uses the build layer: it is a ChatGPT app over MCP with the Decisions API as a verifier. The next step for it is the ship layer: Sign in with ChatGPT, so people on paid plans can run it on their own plan, with the same rule that nothing estimated is saved without their tap.
If you were in the room or are building along similar lines, I would like to hear which layer you are spending the most time on: build, run or ship?
Notes are from my own recollection of the sessions, with announcement details from OpenAI's Bengaluru DevDay.