OpenAI Agent Builder: moet je nu migreren naar de Agents SDK?

OpenAI Agent Builder stopt op 30 november 2026. Bouwde je dit jaar een workflow in die visuele canvas, dan moet je hem vóór die datum overzetten naar de Agents SDK of naar een ChatGPT Workspace Agent. Doe je niets, dan werkt je agent na die datum niet meer. Gebruikte je de oudere Assistants API, dan is die al dood: die stopte op 26 augustus 2026, zonder overgangsperiode, zoals OpenAI zelf bijhoudt op zijn deprecatiepagina. Het raamwerk waar je naartoe moet, leeft ondertussen gewoon door: afgelopen week bracht OpenAI binnen twee dagen twee nieuwe versies van de Agents SDK uit, v0.23.0 op 1 oktober en v0.23.1 op 2 oktober 2026. Hieronder: wat er precies verandert, welk migratiepad bij jouw workflow past, en waarom de "exporteer naar code"-knop je niet automatisch veilig door de deadline heen trekt. Wie voor het eerst een AI-agent wil bouwen zonder straks weer te moeten verhuizen, leest ook de sectie over het beslissen tussen de twee migratiepaden.

OpenAI Agent Builder stopt: wat is er precies veranderd?

Op 3 juni 2026 kondigde OpenAI de deprecatie aan van drie producten tegelijk: Agent Builder (de visuele canvas binnen het bredere OpenAI AgentKit, de verzamelnaam voor Agent Builder, ChatKit en de Connector Registry), de Evals-omgeving en de herbruikbare prompt-objecten (v1/prompts). Alle drie staan nu met exacte datums op de officiële deprecatiepagina:

• Agent Builder (de visuele canvas om workflows te bouwen): aangekondigd 3 juni 2026, stopt 30 november 2026.
• Evals (het testplatform voor promptkwaliteit): aangekondigd 3 juni 2026, wordt 31 oktober 2026 read-only, stopt volledig 30 november 2026.
• Herbruikbare prompts (v1/prompts): aangekondigd 3 juni 2026, stopt 30 november 2026.

Dat is geen losse opruimactie. OpenAI trekt zijn platform samen tot twee dingen die overblijven: de Responses API als basis voor alle nieuwe projecten, en de Agents SDK als het code-first raamwerk daarboven. Agent Builder en Evals waren de twee grafische lagen eromheen; die verdwijnen, de onderliggende API's niet. Voor wie de oudere Assistants API gebruikte, ligt de deadline al achter je: die stopte op 26 augustus 2026, een jaar na de aankondiging op 20 augustus 2025, zonder grace period. Een aanroep naar /v1/assistants of /v1/threads geeft vandaag gewoon een foutmelding.

De drie deadlines die je niet mag missen

De volgorde is geen toeval. Evals gaat eerder dicht dan Agent Builder omdat OpenAI wil voorkomen dat je in de laatste weken nog nieuwe testdata op een uitfaserend platform zet. Ben je nu nog aan het testen in Evals, exporteer dan je bestaande eval-resultaten voordat 31 oktober verstrijkt: na die datum kun je ze nog inzien, maar niet meer aanvullen.

Wat dit verandert voor een Nederlands team dat met OpenAI Agent Builder werkt

Voor de meeste Nederlandse teams die in Agent Builder een eerste workflow bouwden (vaak najaar 2025, toen de tool net uit bèta kwam), verandert er niet morgen iets zichtbaars. De workflow blijft draaien tot 30 november. Het risico zit in de aanname dat "het nog werkt" betekent "het is nog veilig om op te bouwen". Twee dingen zijn concreet:

Eén: elke nieuwe stap die je nu nog in de canvas toevoegt, is weggegooide tijd na 30 november. Bouw je deze maand nog uitbreidingen in Agent Builder zelf, dan moet je die zelfde uitbreidingen bij de migratie opnieuw in code of in een Workspace Agent zetten. Beter: vanaf nu nieuwe logica direct in de Agents SDK bouwen, ook als de rest van de workflow nog in de oude canvas staat.

Twee: een workflow die gedeeld wordt met collega's zonder developer-achtergrond, verliest zijn bewerkbaarheid als je 'm zomaar naar code overzet. Daarvoor bestaat het tweede migratiepad (ChatGPT Workspace Agents), zie de beslisregel hieronder.

Waarom haalt OpenAI deze twee grafische lagen weg in plaats van ze te onderhouden? Niet omdat agents minder belangrijk worden, maar het omgekeerde: OpenAI zet alles wat met agents te maken heeft op twee plekken samen in plaats van drie. Agent Builder, de Assistants API en Evals waren elk een eigen laag met eigen onderhoud, eigen documentatie en eigen edge cases. Eén basis (Responses API) plus één code-raamwerk daarboven (Agents SDK) is voor OpenAI zelf goedkoper om te onderhouden, en voor jou betekent het dat nieuwe functies vanaf nu als eerste in de Agents SDK landen, niet in Agent Builder. Wie nu nog uitsluitend in de visuele canvas werkt, loopt dus niet alleen een deadline-risico, maar mist ook functies die alleen via code beschikbaar komen. ChatKit, de losse chat-widget waarmee je een agent in een eigen website of app toont, blijft wel bestaan: dat product valt buiten deze opruiming.

Een voorbeeld: een supportagent die routeert op een vaste regel

Een fictief maar herkenbaar geval: een SaaS-bedrijf bouwde in november 2025 een Agent Builder-workflow die binnenkomende supporttickets verdeelt. De regel in de canvas was een harde conditie-node: als het ticket het woord "factuur", "betaling" of "credit" bevat, route dan naar het Finance-team; in alle andere gevallen naar de algemene supportqueue. Een deterministische if/dan-vertakking, geen AI-beslissing.

De export naar de Agents SDK (via Code > Agents SDK in de canvas) geeft een werkend Python-bestand, maar de conditie-node verdwijnt niet als code. Ze wordt onderdeel van de systeeminstructie van de agent, ongeveer zo:

instructions = (
    "Classify incoming support tickets. If the ticket mentions "
    "invoicing, payment, or credit, route it to the Finance team. "
    "Otherwise, route it to general support."
)

Dat lijkt op het eerste gezicht hetzelfde. Het verschil: de oude conditie-node matchte letterlijk op drie woorden, voorspelbaar en te testen met een simpele lijst. De geëxporteerde instructie is nu een taalopdracht die het model elke keer opnieuw interpreteert. Test je hem met een realistisch ticket als "Ik heb gisteren een upgrade besteld maar zie geen bevestiging binnenkomen, kan iemand checken of de bestelling goed is doorgekomen?", dan routeert de agent dat soms naar Finance (het woord "besteld" en "bestelling" lijken op een betaalvraag) terwijl het eigenlijk een orderstatusvraag voor support is. De oude woordmatch deed dat nooit, want "besteld" stond niet op de lijst.

De reparatie: laat de agent alleen de vrije tekst classificeren in een vaste set categorieën (bijvoorbeeld finance, support, unclear), en zet de routering zelf terug in gewone code buiten het model:

category = agent_classify(ticket_text)  # LLM: alleen classificeren
if category == "finance":
    route_to_finance_queue(ticket)
elif category == "support":
    route_to_general_queue(ticket)
else:
    route_to_human_review(ticket)

Zo blijft de deterministische bedrijfsregel (welke queue bij welke categorie) in code staan, waar hij voorspelbaar en los te testen is, en gebruik je het model alleen voor het stuk waar het goed in is: vrije tekst interpreteren. OpenAI's eigen migratiegids waarschuwt hier zelf voor: "This process does not convert your workflow graph or guarantee that every behavior transfers unchanged", en specifiek dat workflows "with strong determinism at their core may not migrate faithfully".

Beslisregel: welk migratiepad past bij jouw workflow?

Waar het misgaat: vertrouwen dat de export 1-op-1 werkt

De grootste valkuil is niet dat de migratie mislukt. De export werkt bijna altijd: je krijgt een lopend stuk code of een aanmaakbare agent. De valkuil is dat niemand het resultaat test tegen de oude workflow voordat hij live gaat, omdat "het exporteert toch vanzelf" voelt als een garantie. OpenAI zegt zelf, in de sectie "Limitations" van de migratiegids, dat verbonden apps, authenticatie en rechten "require separate review" en dat je de nieuwe configuratie moet valideren voordat je 'm gebruikt. Dat is geen kleine disclaimer onderaan: het is de kern van waarom een geëxporteerde workflow met vertakkingen niet zomaar hetzelfde gedrag heeft als het origineel.

De tweede valkuil: gekoppelde apps en rechten gaan niet automatisch mee

Routeerlogica is niet de enige plek waar de export kan afwijken. Gebruikte je workflow gekoppelde apps (bijvoorbeeld een Slack-integratie, een CRM-koppeling of een eigen tool met API-sleutel), dan zegt OpenAI's eigen migratiegids expliciet dat "connected apps, authentication, publishing, and permission configuration require separate review in ChatGPT." Met andere woorden: de export kopieert de logica van je workflow, niet de rechten en koppelingen die eromheen hingen.

Dat is geen theoretische waarschuwing. Een onafhankelijke engineer die voor AgenticWire de export zelf naliep, bouwde een losse testopstelling met één agent en één tool en verwijderde daarna doelbewust het token van een gekoppelde app. Resultaat: de verbinding faalde meteen met een KeyError, want de geëxporteerde code bevat nooit een extern wachtwoord of token dat niet al in de code zelf stond. Zijn conclusie, letterlijk vertaald: dat is precies het gat dat je bij een echte migratie tegenkomt, de geëxporteerde code kan een extern inloggegeven niet aanleveren dat nooit deel was van de export. Zet je de export zonder die controle live, dan loop je het risico dat de nieuwe agent met bredere of juist te beperkte rechten draait dan de oude workflow had, zonder dat je dat ziet tot iemand een actie probeert die niet meer (of juist wel) toegestaan is. Loop daarom bij elke koppeling na: welke rechten had de oude workflow, en staan die exact zo weer ingesteld in de nieuwe omgeving, voordat je 'm voor echte gebruikers openstelt.

Dit is ook precies waarom onafhankelijke stemmen de deprecatie oppikten als een operationeel, geen dramatisch verhaal. Beveiligingsonderzoeker Johann Rehberger vatte het op X samen als een kwestie van twee concrete migratiepaden kiezen, niet als een noodgeval, kort na de aankondiging van 3 juni 2026, opgetekend door het onafhankelijke MCP.directory. Dat is ook de juiste toon: een deadline van maanden, met twee door OpenAI zelf genoemde vervangingen, geen verrassing waar je vandaag nog iets tegen kunt doen behalve plannen.

Probeer dit vandaag

Open een bestaande Agent Builder-workflow. Klik op Code in de bovenste navigatie, kies Agents SDK en Python of TypeScript, en kopieer de volledige export.

Zet die export in een los testbestand, niet meteen in productie. Verzamel vijf tot tien echte voorbeelden die je workflow eerder verwerkte (echte tickets, aanvragen of invoer, geanonimiseerd), en laat de geëxporteerde agent ze één voor één verwerken. Vergelijk elke uitkomst met wat de oude Agent Builder-workflow er destijds mee deed. Wijkt er één af, zoek dan de node in de oude canvas die die beslissing nam: vrijwel altijd is dat een conditie die nu als taalinstructie in de agent staat in plaats van als code.

Wat je realistisch mag verwachten

Uit onze Agent Sprints zien we dat een eenvoudige, lineaire workflow (twee tot vier stappen, geen vertakkingen) binnen een halve dag te exporteren en te testen is: de export werkt vaak in één keer, en het grootste deel van de tijd gaat naar het opzetten van de testset, niet naar het coderen zelf. Een workflow met twee of meer conditionele vertakkingen kost eerder twee tot drie dagen, vooral omdat je voor elke vertakking apart randgevallen moet verzamelen en vergelijken. Voor workflows die uitsluitend audit-gevoelige, sterk deterministische regels bevatten (bijvoorbeeld in de financiële sector) geldt dit niet: daar kost de migratie meer, omdat je iedere regel handmatig terug in code moet schrijven in plaats van op de export te vertrouwen.

Hoe je na zeven dagen weet of het werkt

• Draait de geëxporteerde workflow een week door op dezelfde testset zonder afwijking? Vergelijk de uitkomsten elke dag met de oude Agent Builder-resultaten die je nog had; verschillen wijzen op een vertakking die nog als taalinstructie staat.
• Hoeveel van je bekende randgevallen (de voorbeelden waar de oude workflow ooit over struikelde) routeert de nieuwe versie goed? Honderd procent is het doel; elke misser wijst naar een regel die terug naar code moet.
• Staan er nog actieve aanroepen naar Agent Builder of de Assistants API in je logs? Zo ja, dan loopt er nog productieverkeer op een onderdeel dat al dood is (Assistants API) of op 30 november stopt (Agent Builder).

Doe dit deze week

1. Inventariseer wat je op Agent Builder, Evals of de Assistants API hebt staan

   Loop je workflows langs en noteer per workflow of hij vertakkingen of vaste bedrijfsregels bevat. Check meteen of er nog actieve Assistants API-aanroepen in je code staan: die geven nu al een foutmelding.

2. Exporteer en test tegen een vaste set echte voorbeelden

   Gebruik de Code-knop in Agent Builder, kies Agents SDK, en vergelijk de uitkomst op minstens vijf tot tien eerdere, echte gevallen met wat de oude workflow er destijds mee deed.

3. Zet elke vaste regel terug in code, niet in de systeeminstructie

   Gebruik het model alleen voor het stuk dat echt interpretatie vraagt (vrije tekst classificeren); laat de routering zelf, de bedragen en de harde grenzen in gewone code staan, zoals in het voorbeeld hierboven.

Het agent-recept dat vandaag werkt: geef het model nooit de volledige beslissing waar een vaste regel voor bestaat. Vraag het alleen om te classificeren in een vaste, beperkte set categorieën, en laat je eigen code bepalen wat er met elke categorie gebeurt.

Wil je deze migratie met je team uitwerken, inclusief de testset en de keuze tussen code en een Workspace Agent? Dat bouw je in de Agent Sprint. Wil je eerst breder kijken welke van je workflows dit risico lopen, dat hoort in een AI-werksessie.

Bronnen

• OpenAI, API deprecations. Zelf geopend. Bron voor alle exacte datums: de aankondiging van 3 juni 2026 voor Agent Builder, Evals en reusable prompts, en de eerdere aankondiging van 20 augustus 2025 voor het stopzetten van de Assistants API op 26 augustus 2026.
• OpenAI, Migrate from Agent Builder. Zelf geopend. Bron voor de exportstappen (Code > Agents SDK), de twee migratiepaden (Agents SDK of ChatGPT Workspace Agent), en de letterlijke beperkingen over workflows met sterke determinisme en de noodzaak om gekoppelde apps en rechten apart te controleren.
• OpenAI, openai-agents-python op GitHub (README en releases). Zelf geopend. Bron voor de omschrijving van de Agents SDK als provider-onafhankelijk raamwerk en voor de actuele releasedatums (v0.23.0 op 1 oktober 2026, v0.23.1 op 2 oktober 2026).
• Mian Uzman Munib, OpenAI Agent Builder Deprecation: What the Export Loses, AgenticWire. Zelf geopend, onafhankelijk van OpenAI: een engineer bouwt een eigen testopstelling met de Agents SDK-export en verwijdert bewust het token van een gekoppelde app. Bron voor de empirische bevestiging dat een extern inloggegeven niet in de geëxporteerde code terechtkomt (KeyError bij het ontbrekende token).
• MCP.Directory, "OpenAI is winding down Agent Builder and Evals: your migration guide". Zelf geopend, onafhankelijk van OpenAI. Bron voor de bevestiging dat alleen Agent Builder en Evals stoppen (niet ChatKit of de Connector Registry) en voor de losse, onafhankelijke reactie van beveiligingsonderzoeker Johann Rehberger op X, kort na de aankondiging van 3 juni 2026.

Netwerktoegang was deze run zwaar beperkt: openai.com, platform.openai.com, dev.to, ecorpit.com en developers.openai.com (rechtstreeks) waren geblokkeerd door de egress-proxy. De officiële OpenAI-bronnen en de twee onafhankelijke bronnen zijn alsnog zelf geopend via DataforSEO's on_page_content_parsing-tool, dat buiten die blokkade om crawlt; de GitHub-pagina's waren rechtstreeks bereikbaar.

Veelgestelde vragen

• Wanneer stopt OpenAI Agent Builder precies?

  OpenAI Agent Builder stopt op 30 november 2026. De deprecatie is aangekondigd op 3 juni 2026, samen met het testplatform Evals en de herbruikbare promptobjecten (v1/prompts), die op dezelfde datum stoppen. Bouwde je een workflow in de visuele canvas, dan moet je die voor 30 november overzetten naar de Agents SDK of naar een ChatGPT Workspace Agent.

• Werkt de OpenAI Assistants API nog in 2026?

  Nee. De Assistants API stopte op 26 augustus 2026, een jaar na de aankondiging op 20 augustus 2025, zonder overgangsperiode. Aanroepen naar /v1/assistants en /v1/threads geven sindsdien een foutmelding. De vervanging is de Responses API in combinatie met de Conversations API.

• Wat is OpenAI AgentKit en hoe verhoudt het zich tot Agent Builder?

  OpenAI AgentKit is de verzamelnaam voor drie onderdelen: Agent Builder (de visuele canvas), ChatKit (een chat-widget voor je eigen website of app) en de Connector Registry (gekoppelde apps en databronnen). Van die drie stopt alleen Agent Builder, op 30 november 2026. ChatKit en de Connector Registry blijven bestaan; alleen het grafische canvas-onderdeel verdwijnt.

• Wat is het verschil tussen de Responses API en de oude Assistants API?

  De Assistants API stopte op 26 augustus 2026 zonder overgangsperiode. De Responses API is de vervanging die OpenAI voor alle nieuwe projecten aanraadt, in combinatie met de Conversations API voor gespreksgeschiedenis. Het belangrijkste verschil: bij de Responses API beheer je de tool-aanroepen en de conversatiestatus zelf in je eigen code, in plaats van dat OpenAI dat achter de schermen voor je bijhoudt zoals de Assistants API deed.

• Wat is het verschil tussen OpenAI Agent Builder en de Agents SDK?

  Agent Builder is de visuele canvas waarin je een workflow bouwt met klikbare nodes, zonder zelf te programmeren. De Agents SDK is het onderliggende, code-first raamwerk waarin je dezelfde soort workflow in Python of TypeScript bouwt. Agent Builder verdwijnt op 30 november 2026; de Agents SDK blijft bestaan en krijgt de investering, net als de Responses API.

• Kan ik een Agent Builder-workflow automatisch omzetten naar code?

  Deels. Via Code > Agents SDK in de canvas krijg je een werkende Python- of TypeScript-export, maar OpenAI zegt zelf dat dit geen garantie geeft dat elk gedrag hetzelfde blijft. Vaste bedrijfsregels (een harde if/dan-vertakking) worden in de export vaak een taalinstructie die het model zelf interpreteert, en dat gaat bij randgevallen soms stil mis. Test de export altijd tegen een vaste set echte voorbeelden voordat je hem live zet.