OpenAI’s Agent Stack After AgentKit

AgentKit arrived with a visual canvas for composing agent workflows and it read, at the time, like OpenAI’s answer to building agents without writing much code. Eight months later two of its components are being retired.

This is not a crisis — the migration paths are clear and the timeline is generous by industry standards. It is, however, a useful lesson about which layers of a vendor’s stack are load-bearing and which are conveniences that can be withdrawn.

The dates that matter

• 3 June 2026 — deprecation announced. No new Agent Builder agents can be created.
• 31 October 2026 — the Evals platform becomes read-only. You cannot author new evals after this point.
• 30 November 2026 — Agent Builder, Evals and the v1/prompts reusable prompt objects all shut down. Existing Agent Builder agents stop running.

The October date is the one teams underestimate. If your quality gate runs through Evals, your effective deadline is a month earlier than the headline, and you need somewhere else for your test suite to live before you can safely change anything else.

Choosing where to land

OpenAI recommends two destinations depending on the nature of the workflow, and the choice is more consequential than it first appears because the two are not interchangeable.

The Agents SDK

The code-first path, in Python or TypeScript, and the one OpenAI describes as the durable option. You define agents, tools and guardrails in code, deploy it yourself, and get deterministic control over branching, retries and error handling.

Choose this when the workflow is part of a product, when you need behaviour you can test in CI, when execution has to be predictable, or when the thing needs to run somewhere other than inside ChatGPT. For anything customer-facing this is effectively the only sensible answer.

Workspace Agents in ChatGPT

The natural-language path, aimed at internal automation that a non-engineer will own and edit after launch. No code, built-in tools, faster to stand up, and correspondingly less predictable in execution.

Choose this for internal workflows where the person who understands the process is not the person who would maintain the code, and where an occasional unexpected execution path is tolerable.

One piece of advice worth taking seriously: do not split a single workflow across both surfaces. Pick one and keep the whole graph there. A workflow half in code and half in a ChatGPT agent is difficult to reason about and worse to debug.

What the export actually gives you

Agent Builder can export workflows to code, and it is important to be clear about what that export does not include: the visual canvas itself, triggers, and permission wiring all have to be reimplemented by hand. Knowledge bases and custom tools frequently do not map one-to-one, and file search in particular needs reimplementing rather than transferring.

Budget accordingly. The export is a starting point for the agent definition, not a migration.

Replacing Evals

This is the part of the migration with the earliest deadline and the least attention.

OpenAI points to Promptfoo as the migration target, and it is a reasonable one: open source, runs in CI, and expresses graders as assertions in a way that maps onto most existing eval suites. Other options exist — LangFuse, Braintrust, or a plain test suite if your evaluation logic is simple — and the choice matters less than the sequencing.

The order to work in:

1. Export the datasets now, while the platform is writable.
2. Re-express graders in the replacement tool and confirm they produce comparable results on the same data.
3. Wire the new suite into CI so it runs on every change.
4. Only then migrate the agent, with the regression net already in place.

The wider lesson about vendor layers

It is worth separating the two categories of thing OpenAI ships, because the distinction predicts this kind of event.

Foundations are the model APIs and the Responses API. They have wide adoption, other companies depend on them commercially, and they change through deprecation cycles measured in years. Building on them is a normal engineering dependency.

Convenience layers are the visual builders, hosted evaluation platforms and managed tooling. They exist to reduce time to first result, adoption is narrower, and they can be withdrawn when strategy shifts. That is not bad faith — it is the ordinary lifecycle of a product experiment.

The practical implication is not to avoid convenience layers, which are genuinely useful for getting to a working prototype quickly. It is to know which category you are in when you decide to put something into production, and to ask what a migration would cost before you need to do one.

Two habits make this cheap. Keep your prompts, tool definitions and evaluation data in your own repository regardless of what platform runs them, so the assets survive the tool. And keep the boundary between your application and the vendor thin enough that you can see it — a wrapper you wrote is a wrapper you can repoint.

If you are starting fresh today

Use the visual canvas for prototyping if it helps you think, and plan to land in Agents SDK code. Build the evaluation suite in a tool you control from the beginning. Keep the model call itself thin, so switching models or providers is a configuration change rather than a project.

And be honest about whether you need an agent framework at all. A meaningful share of production workflows are a fixed sequence of steps that happen to use a model, and for those a plain function calling the Responses API is easier to test, easier to debug, and impossible to deprecate out from under you.

Boolean Solutions experience with agent platforms

We build on these APIs and we have run several of these migrations, and the pattern that keeps them cheap is consistent: own your prompts, own your evals, and keep the vendor boundary thin and visible.

Teams that treated the hosted platform as the system of record are doing significantly more work this quarter than teams that treated it as a runtime. If you have workflows on Agent Builder and want help scoping the move, or you are choosing where to build something new, get in touch — our AI and ML services page covers how we approach it.

Further reading

• Introducing AgentKit — including the June 2026 wind-down notice at the top
• OpenAI Agents SDK — the recommended long-term path
• OpenAI deprecations — the authoritative timeline, worth checking periodically
• Promptfoo — the suggested destination for evals, and it runs in CI