What you need to know
- A dated sunset, already running. On 3 June 2026 OpenAI announced it is deprecating Agent Builder, the visual workflow canvas, and the Evals platform. The deprecations page sets the dates: existing Evals go read-only on 31 October 2026, and both products are fully unavailable from 30 November 2026.
- Eight months, launch to notice. AgentKit and its visual Agent Builder shipped on 6 October 2025 at DevDay 2025. The deprecation notice landed roughly eight months later.
- ChatKit survives. The embeddable chat UI toolkit is not part of the wind-down.
- Stated migration paths. Agents SDK or ChatGPT Workspace Agents for Agent Builder; for Evals, OpenAI points users towards alternatives such as Promptfoo.
- DevDay is on 29 September. OpenAI DevDay 2026 runs at Fort Mason, San Francisco, with a livestreamed opening keynote from Sam Altman followed by hands-on sessions and technical deep dives.
- Reported, not announced. TestingCatalog and other outlets report, on the basis of codebase inspection and unreleased UI screenshots, that OpenAI is preparing Managed Agents with Environments and Agent Sessions, plus skills and plugins, for DevDay. None of it is confirmed by OpenAI.
Put those items in order and a pattern appears that is more useful than any single one of them. A vendor shipped a visual agent-building layer, withdrew it inside a year, and is now reported to be preparing a managed agent platform that would absorb the same capability into its own runtime. Whether or not the reporting holds, the lesson for anyone building on top of a model provider is the same, and it is a lesson about where you put the durable parts of your stack.
Eight months is not a product lifecycle
Agent Builder arrived on 6 October 2025 with the fanfare that a DevDay keynote confers. It was a visual canvas: you dragged nodes, wired a workflow, tested it and shipped it. For teams without a platform engineer to spare, that is a genuinely attractive proposition, and plenty of teams took it up. The deprecation notice arrived roughly eight months later.
I want to be careful here, because there is a lazy version of this argument and it is not the one worth making. Deprecating a product that did not find its audience is a reasonable thing for a vendor to do, and doing it with dated notice and named migration paths is markedly better than letting a product rot in place. OpenAI has been explicit about the dates and explicit that ChatKit is unaffected. That is how a wind-down should be communicated.
The problem is not the conduct of the deprecation. It is what an eight-month lifespan tells you about how to weight vendor agent-building layers in a build-versus-buy decision. When the same vendor ships a capability, retires it and reportedly rebuilds it one layer up, the visible surface is not the durable thing. The durable thing is the model endpoint and, increasingly, the protocols around it. Everything in between is a product decision that can be revisited, and it will be revisited on the vendor's schedule rather than yours. We made a similar argument during the agent SDK wars between OpenAI, Google and Anthropic, and this is that argument arriving with a calendar attached.
The dates that matter
If you have anything at all running on Agent Builder or the Evals platform, this is your working timeline as of 9 September 2026.
| Date | What happens | Working days from 9 September | What you must have done by then |
|---|---|---|---|
| 29 September 2026 | OpenAI DevDay 2026, Fort Mason, San Francisco | 14 | Nothing forced, but do not let the keynote reset a migration you have already started |
| 31 October 2026 | Existing Evals become read-only | 37 | Evaluation suites exported and running in a system you control |
| 30 November 2026 | Agent Builder and Evals fully unavailable | 58 | Workflows rebuilt in the Agents SDK or ChatGPT Workspace Agents, in production, with a rollback |
30 November 2026 is a hard stop, not a soft one, and it falls on a Monday — which in practice means the last safe deployment window for most teams is the week of 23 November, ahead of a change freeze rather than during one. The read-only cut on 31 October is the more dangerous of the two dates, because it is silent: nothing breaks in production, your evaluation suites simply stop accepting new runs, and a team that only checks its evals before a release can lose a month before noticing. Export first, migrate second.
What the reporting says, and what it does not
Now the part that requires discipline. According to reporting based on inspection of OpenAI's web codebase and unreleased UI screenshots, TestingCatalog and other outlets say OpenAI is preparing a product referred to as Managed Agents, built around two concepts named Environments and Agent Sessions, with skills and plugins alongside them, and that it is being lined up for DevDay. The same reports note that the agents interface is not yet accessible and that self-hosted environments may be supported.
What is absent from those reports is as important as what is in them. There are no official API references. There are no code strings. There is no pricing. OpenAI has not confirmed any of it. Nothing here is announced, and if you are writing a technical strategy document this month, Managed Agents belongs in it as a scenario to be robust against, not as a roadmap item to plan around.
That said, if the reporting holds, the shape it implies is coherent and worth reasoning about. Environments and Agent Sessions read as the two primitives you need for a hosted agent runtime: a place where an agent executes with a defined set of capabilities and boundaries, and a durable handle on a running conversation or task with its accumulated state. Skills and plugins read as the extension surface. Taken together, that is a vendor moving from selling you a way to build agents to selling you a place to run them, which is a fundamentally different commercial position and a fundamentally different lock-in profile. The parallel with the stateless turn in the MCP ecosystem is instructive: the industry has spent a year working out that state is the expensive part, and whoever holds it holds the customer.
What has actually been confirmed
There is a confirmed data point that gets less attention than the rumour and tells you more. On 22 July 2026 OpenAI announced Presence, an enterprise product for deploying and managing realtime voice and chat agents. It bundles policies, system connections, evaluations, guardrails and update processes into one managed offering. Agents built on it can answer questions, access company systems, take approved actions and escalate to human workers, all under company-defined policies, permissions and evaluation standards. It includes testing against common requests and edge cases before production, and monitoring and continuous improvement through a Codex-powered loop, with sandboxed agent access restricted to only the necessary systems. The details are set out in VentureBeat's report of 22 July 2026.
Read that list of components again and notice how much of it overlaps with what a typical in-house agent platform team spends its year building: guardrails, evaluations, connection management, a release process. That is the direction of travel, confirmed, in a shipping product. Managed Agents may or may not be announced on 29 September; the strategic intent behind it is already visible in Presence.
The catch is who can buy it. Presence is a limited general-availability programme rather than a self-service product, and deployments are led by OpenAI Forward Deployed Engineers and select systems integrators. Pricing, geographic limits and contractual terms are not disclosed. A forward-deployed engineering model is, by construction, a model for large accounts. If you are a forty-person services firm in Pune or a Series A fintech in London, you are not in that queue, and you should plan as though you never will be.
The decision that actually matters: what stays in your repo
Strip away the speculation and a builder is left with one useful question. Given that vendor agent layers can appear and disappear on an eight-month cycle, which parts of an agent stack should you happily let a platform own, and which parts must live in a repository you control?
The dividing line is not about trust and it is not about ideology. It is about what is expensive to rebuild. Infrastructure is cheap to swap when it is genuinely commoditised and the interface is narrow. Judgement is expensive to rebuild, because it encodes everything you learned about your own domain, and because nobody wrote it down anywhere else.
| Layer | Vendor-managed is fine | Keep in your repo | Why |
|---|---|---|---|
| Execution hosting | Yes | No | Running a container somewhere is commoditised. Swapping hosts is an infrastructure ticket, not a redesign. |
| Session and conversation state | Yes, with an export path | The schema, not the store | Managed state is genuinely convenient. Define your own conversation and task schema so a migration is a data move rather than a semantic rewrite. |
| Sandboxing and capability limits | Yes | The policy that drives it | Isolation is hard to build well and easy to buy. What the agent is allowed to touch is your risk decision and belongs in code review. |
| Tool and function definitions | No | Yes | Your tool surface is your product. It should be plain code with tests, importable by any runtime, never trapped in a canvas. |
| Prompts and system instructions | No | Yes | Prompts are source. They need diffs, review, blame and rollback like anything else that changes behaviour in production. |
| Routing and orchestration logic | No | Yes | Which model handles which request, when to escalate, when to stop: this is the accumulated judgement that took months to tune. |
| Evaluation suites and datasets | No | Yes, emphatically | Evals are the record of every failure you have already found. Losing them means rediscovering each one in production. |
| Observability and traces | Yes, with export | The instrumentation points | Dashboards are replaceable. Where you emit spans, and what is on them, determines whether any replacement tool can help you. |
The pattern in the right-hand column is consistent: keep whatever encodes a decision you made about your own domain. The vendor cannot regenerate that for you, and neither can the next vendor. The pattern in the second column is equally consistent: hand over the things where the interface is narrow, the semantics are standard and the switching cost is measured in configuration rather than in months.
This is also why the protocol layer deserves more of your attention than the product layer. Work such as the MCP roadmap on agent identity and delegated authority is doing something a proprietary agent canvas structurally cannot: defining an interface that survives a vendor changing its mind. Building against a specification with multiple implementations is the cheapest insurance available in this market, and it costs you almost nothing at design time.
Evals are the sharpest example
Of the two products being retired, Evals is the one whose loss would hurt most, and it is the one teams are most likely to under-plan for. An evaluation suite is not a feature. It is an institutional memory of every way your system has failed: the ambiguous customer phrasing that broke routing in March, the edge case in the refund flow, the prompt injection someone found in a support ticket. Each of those cases was expensive to discover and cheap to keep. Lose the suite and you do not lose a tool, you lose the discovered failures, and you will find them again the slow way.
OpenAI points Evals users towards alternatives such as Promptfoo, and that is a sensible destination. But the migration to do is not tool-to-tool. It is tool-to-repository. Your evaluation cases should be files in version control, in a format you defined, with a thin runner on top. Then the choice of runner is genuinely a choice, and the next deprecation notice costs you an afternoon.
Export every eval case this week, before the 31 October read-only cut, and commit them as plain files to the same repository as the code they test. Use a boring format you own, not the vendor's export shape: one file per case with input, expected behaviour, grading criteria and the date and reason it was added. Then write a fifty-line runner. Once the suite lives in your repo, it runs in CI on every prompt change, it is diffable in review, and it survives any platform decision anyone makes about it. Our guide to cost-aware evals and quality per pound covers how to keep that suite affordable once it starts running on every commit.
A migration plan for the next 37 working days
If you are affected, here is the sequence I would run, in this order, starting today.
Week one: inventory and export. Find every workflow that touches Agent Builder and every eval suite on the Evals platform. In most organisations this list is longer than the platform team expects, because a visual builder is exactly the tool an analyst or a product manager picks up without filing a ticket. Ask around, then export everything. Exports are cheap and the read-only cut is 37 working days away.
Weeks two and three: rebuild the highest-value workflow in code. Not all of them, one of them. Take whichever Agent Builder workflow carries real traffic and reimplement it in the Agents SDK, or in ChatGPT Workspace Agents if the workflow is genuinely a workspace assistant rather than a product surface. The point of doing one first is calibration: you will discover how much implicit behaviour the canvas was providing, and that number is your multiplier for everything else.
Weeks four and five: the rest, plus the evals. With a calibrated estimate, work through the remaining workflows. Run the migrated evaluation suite against both the old and new implementations on the same inputs and diff the outputs. This is the step teams skip, and it is the step that catches the silent behaviour changes.
Weeks six onward: harden and derisk. Buffer for the things you did not anticipate, and use it to make the new implementation more portable than the one it replaced. Pull tool definitions into their own module. Move prompts into files. Put the routing logic behind an interface. If you are going to spend the effort anyway, spend it in a way that means you do not repeat it. While you are in there, applying progressive tool disclosure to the rebuilt agent will usually claw back some of the token cost the migration adds.
Every article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →The dual-market read: Bengaluru and London
The consequences differ by where you sit, and both of our markets have a specific version of this problem.
For an Indian services firm or global capability centre running client agent workloads, the exposure is multiplied by the client count. A Bengaluru firm operating agents for a dozen customers does not have one migration, it has a dozen conversations, each with its own change-approval process, its own testing window and its own commercial question about who pays for the work. That is the uncomfortable part: a deprecation on the vendor's side becomes billable-hours negotiation on yours. The firms that will come out of this well are the ones that built a house framework wrapping the vendor layer, because for them the change is contained in one place. The firms that let each client project adopt the vendor canvas directly are about to learn what that convenience cost. There is a commercial upside available too, if you are quick: a clean, documented migration offer, priced as a fixed-scope engagement and delivered before 30 November, is exactly the kind of work that turns a delivery vendor into an advisor.
For a London fintech or any UK firm under FCA-style change-control expectations, the constraint is different and mostly about time. Replacing a component that sits in a customer-facing path is not a deploy, it is a change with documentation, sign-off, testing evidence and often a slot in a release calendar that is already full for the quarter. Counting backwards from 30 November through a typical approval cycle and a December change freeze leaves considerably less room than 58 working days suggests. If your change-advisory board meets fortnightly, you have perhaps five meetings, and you want the evidence pack ready for the second one, not the fifth.
Both markets share the constraint that matters most: Presence, the one confirmed managed agent product, is delivered through Forward Deployed Engineers and select systems integrators. That is not a route available to a mid-sized firm in Bengaluru or a growth-stage company in London, whatever DevDay announces. Smaller teams in India and the UK need the portable path, not because portability is virtuous, but because the managed path is not on offer to them. The build-versus-buy analysis we ran on the McKinsey state-of-AI data holds up here: buying works when the thing you are buying will still be sold to you next year, at a price you can pay.
What to do before 29 September
DevDay will produce announcements, and if the reporting holds, one of them will be a managed agent platform with a well-made demo. Treat it as information, not as an instruction. The useful posture is to have your migration underway before the keynote, so that whatever is announced becomes a question of whether to adopt something new rather than a rescue plan for something you have already lost.
Three things are worth doing this week regardless of what happens on 29 September. Export your evals and commit them to your repository. Inventory your Agent Builder usage, including the workflows nobody on the platform team knows about. And run a short exercise on your current agent architecture, asking of each layer: if this vendor withdrew this component with six months' notice, what would it cost us? Anything with an answer measured in months belongs in your own repository.
None of this is an argument against using OpenAI's models, or anyone else's. Context worth keeping in view: Anthropic's 2026 State of AI Agents report, drawn from more than 500 technical leaders, found that 57% of organisations run multi-step agent workflows and 16% have cross-functional agents spanning multiple teams. Agents are past the pilot stage, and the systems being built now will still be running when several of today's product layers have been retired. Build them so that a vendor changing its mind is a Tuesday, not a quarter.