DevDay: AgentKit, Apps in ChatGPT, and a platform play

OpenAI's developer day delivered a coherent strategy statement, which is more than most developer conferences manage.

the announcements#

AgentKit. A visual agent builder with a node-based canvas, versioning, an evaluation harness with trace grading, and a connector registry. Aimed at people who want to compose agent workflows without writing orchestration code.

Apps SDK. Third-party applications running inside ChatGPT, with interactive UI, built on the Model Context Protocol. Users invoke them by name or the model suggests them contextually.

Sora 2 in the API. Video generation, programmatically.

GPT-5 Pro in the API. The highest-capability tier, available to developers.

Codex GA, with Slack integration and an SDK.

the strategy#

Put together, this is a platform play in the classic sense: OpenAI wants ChatGPT to be the surface where users spend time, and wants third-party functionality to arrive inside it rather than alongside it.

The playbook is well established. iOS did it. Facebook did it. Slack did it. The pattern:

1. Get enormous distribution.
2. Open a developer platform so third parties build the long tail you cannot.
3. Take a cut, or take the data, or take the strategic position.
4. Eventually build the most valuable third-party categories yourself.

Step four is the one developers should think about before investing heavily. It has happened on every platform, without exception, and the companies that got hurt were the ones whose entire product was a feature.

the MCP decision#

Apps SDK is built on MCP, which means an app you build for ChatGPT is substantially portable. The tool definitions, the resource model, and the transport are a standard, not a proprietary format.

That is meaningfully different from previous platform generations and it is worth crediting. An iOS app was an iOS app. An MCP server is an MCP server, and the same one can serve Claude, ChatGPT, an IDE, and whatever comes next.

The lock-in is at the distribution layer, not the code layer. That is a much better deal for developers than the historical norm.

AgentKit, evaluated honestly#

Visual workflow builders have a consistent history: excellent for the first 80% of a use case, painful for the last 20%, and the last 20% is where the actual work is.

The pattern I have watched repeat for twenty years across ETL tools, iPaaS products, and low-code platforms: teams start on the canvas, hit a case the canvas cannot express, add a custom code node, then another, and eventually the canvas is a very expensive way to arrange function calls.

That said, the evaluation and tracing pieces are the genuinely valuable part and they are useful independent of the canvas. Agent evaluation is hard, most teams do it badly or not at all, and a first-party harness with trace-level grading lowers the barrier meaningfully.

Use the evals. Be cautious about the canvas.

what I would actually build#

If you are considering building on this:

• Build an MCP server first. It works everywhere, including ChatGPT via Apps SDK. Start portable.
• Own the user relationship where you can. Distribution through someone else's surface is rented, always.
• Do not build a feature. Build something with data, integrations, or a workflow that is genuinely yours. If your entire product could be a system prompt, it will be.

That last point is the whole thing. Every platform generation produces a wave of companies that were a thin wrapper and a wave that were a real business, and the distinguishing factor is visible from the start if you are honest about it.