OpenAI's Triple Deprecation: Migrate Your Evals and Agents Before October 31

Three platform services. One shutdown date. Five months — the same five months most teams are heads-down shipping end-of-year product. On June 3, 2026, OpenAI added three infrastructure-level deprecations to its official tracker: the Evals Platform, Agent Builder, and the Reusable Prompts API (v1/prompts). Hard shutdown is November 30, 2026. But the Evals platform goes read-only on October 31 — and that's the date you should actually be planning around.

This isn't a model-ID swap where you change one line in a config file. These are tooling surfaces where teams have built evaluation habits, review workflows, and agent prototypes. The migration cost isn't code — it's the operational knowledge embedded in dashboards, datasets, and visual canvases that nobody bothered to document.

What's Actually Going Away — and Why It's Not Trivial

Agent Builder was a visual, node-based canvas for composing multi-step agent workflows — drag-and-drop tool chaining without writing code. It exported to Python and TypeScript, and you could deploy those exports via the Agents SDK or import them into ChatGPT Workspace Agents. For prototyping, that's genuinely useful. The problem is what happens when a prototype becomes the de-facto production design: decisions about which tools are safe to call, which prompt variants were rejected, and what trace reviewers look for live inside the canvas — not in version control, not in a design doc, not anywhere recoverable after the shutdown.

The Evals Platform is arguably the higher-stakes loss. If your team built review workflows around the dashboard — uploading datasets, running graders, tracking prompt experiment results — that operational muscle memory doesn't automatically transfer. The graders are configuration. The datasets are data. Both need to be exported and re-anchored somewhere before October 31, when the platform goes read-only and you can no longer push new runs.

The Reusable Prompts API (v1/prompts) is the most straightforward: if you're calling prompt objects via the API rather than inlining them, you need to migrate to explicit prompt strings in your SDK calls. It's mechanical, but it touches every integration point.

The vendor-lock pattern here is worth naming directly. I wrote about this dynamic in OpenAI Presence: When Your Model Provider Becomes Your Competitor — when a provider controls both the model and the surrounding tooling, platform retirements like this are predictable. You don't get advance warning that's useful; you get a deprecation date and a migration guide to their new product.

The Eval Replacement Signal You Shouldn't Miss

OpenAI's recommended Evals replacement is Promptfoo — which OpenAI acquired in March 2026 at an $86M valuation. Ian Webster has committed to keeping it MIT-licensed and vendor-neutral, which is the right public commitment to make, and I have no reason to doubt the intent. But the strategic structure is now: your eval harness, owned by your model provider.

If you want genuine eval independence, you run your harness outside any single provider's dashboard — full stop. Promptfoo is a legitimate, capable tool, and its MIT license gives you options. But the moment you let eval infrastructure collapse back into a managed platform (whoever owns it), you're one more deprecation cycle from being here again.

The evaluation harness architecture I'd recommend regardless of which tools you pick:

yaml
# eval-config.yaml — version-controlled, provider-neutral
eval:
  model: "openai/gpt-4.1"  # swappable
  dataset: ./datasets/production-golden-set.jsonl  # yours, in your repo
  graders:
    - type: llm-rubric
      prompt: ./graders/quality-rubric.txt  # yours, in your repo
    - type: exact-match
  thresholds:
    pass_rate: 0.85
  output: ./results/  # yours, versioned

The key principle: datasets and graders belong in your version control system, not in a vendor dashboard. The tool that runs them is replaceable. The data is not.

The October 31 Forcing Function — Plan Backwards From It

November 30 is the headline date. October 31 is the real one. After October 31, Evals goes read-only — you can view historical runs but you can't push new evaluations through the platform. Any team that waits until November to migrate will be debugging their new eval setup while also trying to run evals against whatever they're shipping in Q4. That's an avoidable situation.

Here's a planning table that treats October 31 as the hard deadline:

Workstream	Owner	Target Completion	Notes
Export all eval datasets + graders	Eng lead	Week 3 July	JSON/JSONL, into repo
Audit Agent Builder flows for undocumented decisions	PM + Eng	Week 4 July	Document in ADRs
Re-implement agent flows in Agents SDK	Eng	August	Use exported Python/TS as starting point
Stand up replacement eval harness (Promptfoo or equivalent)	ML Eng	August	Wire to CI/CD
Migrate Reusable Prompts API calls	Eng	September	Mechanical, but don't leave for last week
Validate replacement eval results match historical baseline	ML Eng	October 1–20	Buffer before read-only gate
October 31 gate	—	October 31	Platform read-only

The reason to front-load the Agent Builder audit is the hidden knowledge risk. A visual agent flow can encode decisions that never made it into documentation: which tools are gated behind human approval, which prompt variants were tried and discarded, what edge cases the team reviewed in the eval dashboard before releasing. If you just re-implement the flow from the canvas without doing that audit, you'll lose institutional decisions, not just code.

The Agent Migration: Code-First Is the Right Default

OpenAI's migration path is clear: for workflows that should continue as code, use the Agents SDK; for use cases better served by natural language prompting, use Workspace Agents in ChatGPT. The AgentKit framework replaces Agent Builder as the recommended path.

If your team used Agent Builder to prototype and never shipped the exported code to production, you have a cleaner migration path: the export gives you a Python or TypeScript starting point, and you wire it into the Agents SDK. A competent engineer can do this in days for a straightforward flow. Where it gets complicated is when the agent has meaningful state transitions, tool-calling logic, or human-in-the-loop approval gates — in which case, use the migration as an opportunity to formalize the state machine explicitly rather than recreating the visual flow verbatim.

I've covered the importance of explicit state management in Agent State Machines: Stop Runaway Agents With Explicit States — a visual canvas prototype is exactly the kind of implicit state machine that hides failure modes. Migrating to code is genuinely an upgrade if you approach it correctly.

The trap to avoid: migrating Agent Builder flows straight to code without adding observability. A visual canvas at least makes the flow legible. An undocumented Python implementation of the same flow is harder to debug and harder to hand off. Wire tracing from day one.

The Prompts API Migration — Fastest, But Don't Leave It Last

The Reusable Prompts API deprecation is the most mechanical of the three, and that's exactly why it'll get deprioritized until November. Don't.

If you're storing prompt objects server-side and fetching them via v1/prompts, you have two options:

1. Inline the prompts in your SDK calls and manage versioning in your codebase (simplest, recommended if your prompt management is lightweight).
2. Move to a dedicated prompt management layer — LangSmith, PromptLayer, or a simple database-backed store you control — if you have non-engineers editing prompts and need a UI.

Option 2 makes sense for teams where PMs or content teams own prompt iteration. Option 1 makes sense for everything else. Either way, this should be done by September to leave October clear for validation.

What the Strategic Signal Actually Means

Stripped of the specifics, OpenAI is making a clean statement: we build the model layer and the SDK layer; we are not in the dashboard tooling business. That's a defensible product strategy, and it's broadly the right call — managed dashboards for eval and agent building create false confidence in workflows that need to be owned by engineering teams.

But the lesson for any team building on a single provider's managed platform surfaces is durable: platform features that aren't your code are borrowed infrastructure. When the provider decides to consolidate, you're migrating on their timeline, not yours.

The teams that will feel this least are the ones who already ran their evals in code (pytest-based, Promptfoo, or equivalent), kept their agent logic in SDK-based code rather than a canvas, and managed prompts as versioned strings rather than server-side objects. If that's you — minimal work required. If it's not you — use this migration to build that discipline, because the next deprecation cycle is already in motion somewhere.

What to Actually Do

1. This week: Export every eval dataset and grader from the OpenAI Evals platform to your repo. This is free optionality — even if you keep using the platform until October 31, owning the data costs you nothing.
2. July: Audit every Agent Builder flow for undocumented decisions. Write Architecture Decision Records (ADRs) capturing tool safety gates, approval requirements, and rejected prompt variants. Do this before you touch code.
3. August: Re-implement agent flows in the Agents SDK using the exported Python/TypeScript as a starting point. Add explicit state management and tracing from day one — don't recreate an implicit flow.
4. August–September: Stand up a replacement eval harness (Promptfoo, LangSmith, or a CI-integrated script you own). Validate that your golden test set produces equivalent results to your historical baseline before October 31.
5. September: Migrate all v1/prompts API calls. This is mechanical — don't let it block anything, but don't leave it for week of November 30 either.

October 31 is your real deadline. Build the plan backwards from it, not from the headline date.

The teams that treat this as a boring migration chore will come out the other side with a more robust, more portable stack than they started with — if they do the audit work, not just the code work.