OpenAI Shuts Down Agent Builder, Evals, and Prompt Objects on November 30 — The Migration Guide

On June 3, 2026, OpenAI announced that three platform products would be retired: reusable prompt objects, the Evals platform, and Agent Builder. All three shut down on November 30, 2026. Evals stops accepting changes a month before that.

That was 86 days ago. You have 94 days left, and one of these migrations is considerably more work than the announcement implies.

If you want a preview of how these deadlines land, the Assistants API sunset on August 26 — two days ago — is instructive: it arrived with no automated migration path for existing Threads.

The Dates

Date	What happens
June 3, 2026	Deprecations announced; prompt creation de-emphasized in the platform
August 26, 2026	Assistants API sunset (separate, already passed)
October 31, 2026	Existing evals become read-only
November 30, 2026	v1/prompts, the Evals dashboard and API, and Agent Builder shut down

Two deadlines matter, not one. October 31 is the date you lose the ability to change evals — so anything you intended to export, restructure, or snapshot has to happen before then, not in the November buffer.

ChatKit is not part of this. It remains available.

Migration 1: Prompt Objects → Code

The smallest migration, and a good warm-up.

The old pattern referenced a stored prompt by ID and version, with server-side variable substitution:

const response = await client.responses.create({
  prompt: {
    id: "pmpt_123",
    version: "1",
    variables: {
      customer_name: "Acme",
      issue: "billing question",
    },
  },
});

The replacement is to move the content into your codebase and pass messages directly, with an explicit model:

const response = await client.responses.create({
  model: "gpt-5.6",
  input: [
    {
      role: "system",
      content: "You are a helpful support assistant. Be concise, accurate, and friendly.",
    },
    {
      role: "user",
      content: "Customer name: Acme. Issue: billing question. Write a response to the customer.",
    },
  ],
});

Inlining every call site is not the goal. OpenAI’s recommended shape is a builder function per prompt, which restores the reuse the prompt object gave you:

def build_support_prompt(customer_name, issue):
    return [
        {
            "role": "system",
            "content": "You are a helpful support assistant. Be concise, accurate, and friendly.",
        },
        {
            "role": "user",
            "content": f"Customer name: {customer_name}. Issue: {issue}. Write a response to the customer.",
        },
    ]

response = client.responses.create(
    model="gpt-5.6",
    input=build_support_prompt("Acme", "billing question"),
)

Four things to carry over deliberately:

1. Variables become typed arguments. What was an untyped variables dict becomes a function signature — validated at the boundary rather than silently interpolated server-side.
2. Versioning moves to git. Prompt versions become commits, PR review, release tags, and feature flags. This is the actual upgrade in the change: prompt edits stop being invisible production changes.
3. The model is now explicit. Prompt objects could carry model configuration. Inline calls cannot — every call site needs a model specified, so audit for anywhere that relied on the stored default.
4. Keep static content first. OpenAI’s guidance is explicit: static content first, dynamic content later, to preserve prompt caching. Naive string interpolation that puts a customer name near the top of a long system prompt will quietly destroy your cache hit rate and raise your bill.

Point 4 is the one that bites, because nothing errors — you just pay more.

Migration 2: Agent Builder → Agents SDK or Workspace Agents

Start here. This is where the real work is, and the export button is misleading about how much of it there is.

To export a workflow:

1. Open your workflow in Agent Builder.
2. Select Code in the top navigation.
3. Select Agents SDK in the code dialog.
4. Select TypeScript or Python, then copy the complete export.

Now the part worth reading twice. From OpenAI’s own migration guide:

This process does not convert your workflow graph or guarantee that every behavior transfers unchanged.

The export gives you a starting point, not a port. Your branching logic, routing, and node structure are not carried across mechanically — you get code that approximates the workflow and you own the reconciliation.

Additionally, connected apps, authentication, publishing, and permission configuration require separate review in ChatGPT. None of that is in the export.

Choosing between the two targets

Agents SDK is the code-first path. Take it if your workflow has real branching, deterministic control flow, or anything you need under test.

Workspace Agents in ChatGPT is the lighter path. OpenAI suggests pasting the export with a prompt like:

Please help me convert this workflow into an agent: <paste your exported code here>

But note the constraint OpenAI states directly:

Workflows with strong determinism at their core may not migrate faithfully to a workspace agent.

If your workflow is essentially a state machine, a Workspace Agent is the wrong target. Take it to the SDK.

Either way, validate before you cut over:

1. Review the generated instructions and configured capabilities.
2. Configure required apps, tools, skills, authentication, and connection permissions.
3. Select Preview and test representative inputs from the original workflow.
4. Compare previewed behavior against the original workflow’s expected behavior.

Carry over your original safety practices too, particularly where the agent touches private data or acts through connected tools — a migration is exactly when an over-broad permission gets granted “temporarily” and stays.

Migration 3: Evals → Promptfoo

OpenAI points to Promptfoo. The structural shift is from a hosted dashboard to a config file and CLI — which means your evals become reviewable artifacts in the repo instead of dashboard state.

The concepts map cleanly:

OpenAI Evals	Promptfoo
Test data	Test cases in config
Prompts	Prompts in config
Providers / models	Provider configuration
Scoring criteria	Assertions and metrics
Graders	Assertions

You define a promptfooconfig.yaml carrying prompts, provider, test cases, and assertions, then:

promptfoo validate config -c promptfooconfig.yaml
promptfoo eval -c promptfooconfig.yaml --no-cache
promptfoo view

The --no-cache flag matters while migrating — you want to confirm the eval genuinely reproduces, not replay a cached result.

One caution OpenAI raises explicitly: any manually recreated grader, especially an LLM-as-a-judge grader, should be validated before you rely on it. A judge prompt rebuilt in a new harness can score differently while looking correct. Run both systems against the same fixtures and compare distributions before you trust the new numbers.

The October 31 deadline is the binding one here. After that your evals are read-only, so export test data and grader definitions before then.

Suggested Order

Given 94 days, sequence by risk rather than by ease:

1. Weeks 1–3 — Agent Builder. Longest tail, least mechanical, and the only one where the vendor explicitly warns behavior may not transfer. Export everything now even if you migrate later; the export disappears with the product.
2. Weeks 2–4 — Evals export. Hard-capped at October 31. Get test data and graders out of the platform even before the Promptfoo config is finished.
3. Weeks 4–8 — Prompt objects. Mechanical and safely parallelizable. Do it with the caching guidance in hand.
4. Buffer. November is for validation, not migration. The Assistants sunset is a reminder that these dates arrive with hard errors.

A useful audit to start with:

# Find what still depends on the deprecated surfaces
grep -rn "pmpt_\|prompt_id\|\"prompt\":" ./src
grep -rn "v1/prompts\|/evals" ./src

Limitations

A few honest gaps.

OpenAI has published shutdown dates but not a detailed statement of what happens to stored data after November 30 — whether prompt objects and eval history are exported, retained, or dropped. If you need that history, get it out rather than assuming.

The Promptfoo cookbook maps concepts and gives commands but points to Promptfoo’s own documentation for the YAML specifics, so budget time for that rather than expecting a drop-in template.

And the Agent Builder export’s fidelity varies with workflow complexity in ways no guide can quantify for your case. The only way to size it is to export one representative workflow now and diff the behavior.

For related context on where agent tooling is heading, see our coverage of the MCP stateless spec and roadmap, and on the authorization pitfalls that migrations tend to introduce, the August agent CVE wave.

Conclusion

Two of these three migrations are mechanical. The Agent Builder one is not, and it is the one most teams will discover late because the export button makes it look solved.

Export everything this week — prompts, workflows, evals — while all three products still exist. Migration can follow on your schedule. Extraction cannot.

Sources

• Deprecations — OpenAI API
• Migrate from prompt objects
• Migrate from Agent Builder
• Moving from OpenAI Evals to Promptfoo — OpenAI Cookbook
• Assistants migration guide