Welcome remarks from Kyung-hoon Kim (Harrison Kim). The slide puts September’s DevDay announcements on a single screen.
The message I heard at this event was to focus on building services on top of the harness OpenAI runs, rather than engineering a harness yourself. That’s my takeaway from OpenAI DevDay Exchange, held October 22 at the Raum Art Center in Seoul. It was the first AI event I’d attended in person. Most of the content had already been made public in September, but through the four sessions I sat in, I kept thinking that the builder who borrows a harness and the software engineer who builds the company’s harness are taking on increasingly distinct roles. Where that line falls comes down to who owns the harness.
#My first AI event
No detailed schedule went out ahead of time, so I assumed it started at 2 and showed up around 1:30, and there was already a line at the entrance. Once they let us in at 2, I ate some light catering and talked with one or two people. The main program didn’t start until 3.
DevDay Exchange was a touring event that carried the content of September’s DevDay in San Francisco to eight cities, and Seoul reportedly drew more than 600 people. On the main stage I caught the opening keynote, the loops session and the plugins session. Apart from the welcome remarks, nearly every talk was in English. I followed the keynote and the loops session as delivered, but the third speaker talked so fast that I ended up putting the interpretation receiver in my ear for the plugins session.
A harness here means the runtime framework that runs a model as an agent. It’s everything outside the model that runs the agent, from tool calls and permissions to context management and how it retries after a failure. Albert Yip’s keynote introduced Dots, ChatGPT Space and GPT-6.1 Sol, along with the Agents API, which opens Codex’s execution environment as a managed service. Bonnie Chatterjee’s session was titled “What Comes After Loops?” and covered the move from building an agent around a single loop that calls the model over and over to structures where several agents collaborate. As the starting point, she drew a Codex agent as two boxes, the model and the harness. The model reasons and picks what to do, while the harness holds the instructions, runs the tools and returns the results. Corey Ching’s plugins session demoed building and distributing a ChatGPT plugin, and showed how users can find and use your service from inside ChatGPT and Codex.
A slide from the loops session. Four agent teams divide up one goal, and each team’s result converges into a single solution.
#Building with the harness and the Agents API
At 4:45 I had to pick one of two. The main stage had the Sites session and the breakout room had the Harness session. I’ve been writing my own harness for my work lately, so I moved to the breakout without a second thought. The session was Harness-as-a-Service: Building with the Agents API, and unlike the main stage it ran in Korean, with two engineers, Jaewon Lee and Jungwon Kim, taking turns. Jaewon Lee said OpenAI had started out offering the model’s reasoning through the Responses API and had now reached the point of offering the whole environment where agents run and are managed as a service. Then he asked for a show of hands, first from people who had used the Responses API and then from those who had used Chat Completions.
The Harness session on the breakout stage, a smaller room than the main stage.
Jungwon Kim went next and admitted that, as recently as the Agents SDK launch last year, the team had believed developers wanted to build and configure harnesses themselves. The feedback that kept coming back, though, asked why Codex’s harness, which was already good, wasn’t offered as a service, and the Agents API is their answer. The Responses API sits at the bottom, and Codex is the harness built by putting it together. The Agents API sits on top of Codex, and the developer’s application on top of that. With the Agents API, the developer picks the work to hand off, the instructions, the tools and the environment, and OpenAI maintains the harness that fits them. He added that the burden of tearing out and reworking the harness every time the model improves should drop a lot, at least for OpenAI’s own models. Anyone who has written a harness knows how often you end up re-tuning prompts and tool setups after a model change, and I nodded along at that point.
The Harness session’s layers slide, transcribed. Codex sits on the Responses API, with the Agents API and the application stacked above it.
They named three problems they had to get past before the Codex harness could ship as an API. The first was the execution environment. Codex ran locally, but the Agents API has to send work to an OpenAI-hosted sandbox or a sandbox the customer designates and bring the results back, so they separated the harness from the place where the work runs. The second was how to show users what the agent is doing. Jaewon Lee took over here and explained that an internal team building a product on the Responses API had wanted to see two steps, finding the cause of a payment failure and then raising the timeout to try again, grouped together with their tool calls and results. That’s why the Agents API got a unit called a turn. The third, which Jungwon Kim explained, was work that runs for days. Context compaction is handled inside the API by default, and even if a server dies and comes back, the work picks up the state of the in-progress task and its outputs and carries on.
The slide that restates the three problems in developer terms, reproduced here. The lines read: keep the environment you already run, show useful progress, and delegate all sessions.
The docs state the split between what OpenAI handles and what the developer handles more directly. The Agents API entered public beta on September 10, and its introductory post says OpenAI hosts and maintains the harness so that developers can focus on the tools, knowledge and workflows unique to their own agent. In the agents guide the comparison table is blunter. The Agents API runs on the Codex harness that OpenAI manages and has a low integration burden. The Responses API, at the other end, is for calling the model directly or building an agent from scratch, and has a high integration burden.
The demo was a fictional canceled flight from Incheon to San Francisco. Out of 12 passengers and 18 bookings, they picked two cases, a solo traveler who wanted to leave tomorrow morning and a family of four whose child had to sit next to a guardian and who wanted a rental car if they landed at a nearby airport, and launched a separate session for each. The sessions got the seat availability lookup tool they had been using with the Responses API and the skills needed to book flights, and two subagents split the review of the seating and arrival conditions. The code that created a session was short. It set the environment to an OpenAI-hosted sandbox, turned network access off and streamed the results back. The result came back as a JSON file with proposed replacement flights, and a human approved the final booking change. Partway through, the demo server running locally went down. Jaewon Lee laughed and said our prayers must not have been enough, carried on with the slides, and came back on stage at the end of the talk to finish the demo.
Session creation code from the rebooking demo. The environment is an OpenAI-hosted sandbox, with the network blocked.
What stuck with me longest from this session was what Jaewon Lee said while the demo was stalled. You could do the same thing with the Responses API, but then you’d have to take care of each piece yourself, from when a human steps in to where the agent runs and how its progress is shown. With the Agents API, he said, the developer can focus on the criteria for changing a booking and when a human approves. Earlier, while explaining turns, he had also said that once you offer the harness as a service, you have to work through the boundary case by case, deciding how much to hand off and what the developer handles directly.
#Borrowing the harness and building it
I read the difference between these two APIs as a line between the people who use them. Builders are the people who turn an idea into a service quickly, and for them the efficient path is to borrow the Codex harness as close to as-is as possible and connect through plugins and the Agents API. That’s welcome news for builders. For software engineers, the ambiguity hits first, in the form of a question about what’s left for engineers if Codex takes the harness too. In a sense, though, this talk drew the outline of what’s left more clearly. The part the speaker left to developers, the criteria for changing a booking and when a human approves, consists of rules the company sets even when it uses the Agents API. If the features and connections a managed API provides aren’t enough to enforce those rules the company’s way, the things the speaker said you’d have to handle yourself on the Responses API come back to the engineer. In a customer session I didn’t attend, AWS reportedly advised starting with small tasks and widening the scope, while managing access, usage and cost according to the company’s security policy and governance.
The deciding question is who owns the harness. A managed harness lets you build fast, but it can limit your control over cost and behavior. Building it yourself lets you hold on to both, at the price of taking on that much more development and maintenance. So the first thing to check is whether the tools and environment connections a managed API provides can meet your requirements. Some cases will still need an in-house harness. One is when access has to be tied to the company’s permission system and audit records. Another is when usage and cost have to be controlled per team or per feature, and a third is when specialized tools or data that the managed harness doesn’t handle sit at the center of the work. As these requirements grow, engineers take on the job of offering an in-house harness as a platform, either by wrapping the managed harness or by building on the Responses API. For now the managed harness will probably be more popular, but self-built harnesses may come back into the conversation someday. When they do, I think the in-house harness will cover a narrower scope and be tied more deeply into the company’s permission and cost rules.
This isn’t a picture that applies to everyone, though, and it isn’t something the speakers said. The Agents API can also connect to a customer’s sandbox and the customer’s own tools, so getting the control a company needs doesn’t require building an entire harness. At the end of the same session, Jungwon Kim also said the Codex harness and models would be available on AWS Bedrock as a public preview, which lets you keep data and compute inside AWS infrastructure. The options between managed and self-built are wider than they first look. The message to hand over the harness is also a message that works in OpenAI’s favor, and one write-up from another attendee read the whole talk as a pitch to leave everything to OpenAI. My criteria above are a generalization from a backend engineer in the middle of moving toward AI, and I haven’t verified them. If my team ever has to move something a builder made with Codex onto an in-house harness, I plan to write down what had to change, in the order of permissions, cost and observability.
Over the past year, the louder story was that backend engineers would be replaced, and having worked as a backend engineer myself, I wasn’t immune to it. At this event I started to think engineers could steer toward building and managing the company’s foundational harness, and that one thought is what I took home from my first AI event. Builders borrow the harness, and engineers build the company’s harness. This talk clearly pushed those two roles a little further apart than before.
#Outside the main thread
The customer cases in the Harness session were Notion, Rakuten and Bain. The speaker said Bain & Company’s was a bit more interesting than the others. They use the Agents API to create fictional customer personas and collect survey responses about a new product ahead of time. For the Sites and GPT-Live demos and the outline of the Codex security session, none of which I attended, Digital Chosun’s on-site report, a Korean-language article, has the details.
In his welcome remarks, Kyung-hoon Kim, head of OpenAI Korea, said Korea ranks third in the world in weekly active Dots users and around the top five in ChatGPT Pro users. As examples of feedback from Korean developers that made it into the product, he pointed to Linux support in Codex, handling multiple folders in a single project and improvements to the mobile experience. At the end of his remarks he said every attendee would get 30 days of the ChatGPT Pro 100 plan to mark the event. I plan to spend that month running all kinds of experiments with Codex, and I’m already looking forward to it.
#References
- Introducing the Agents API (OpenAI, Sep 10, 2026). The post that opens the Codex harness and infrastructure as a public beta API and says OpenAI hosts and maintains the harness.
- Agents (OpenAI API docs). The guide that compares the Agents API, the Agents SDK and the Responses API by where they run and how much integration they take.
- OpenAI ‘DevDay Exchange: Seoul’ on-site report (Digital Chosun). A Korean-language report from the Seoul event that covers the session lineup and the Sites and GPT-Live demos in detail.
- OpenAI DevDay Exchange 2026. The official page with the eight-city schedule and the event format.