OpenAI udfaser Agent Builder: Bevar workflowet – ikke kun prompts

Af Greg Nowak. Senest opdateret 2026-07-10.

OpenAI har fastsat en slutdato for Agent Builder. Fra den 30. november 2026 vil det visuelle workflowprodukt ikke længere være tilgængeligt på OpenAI-platformen.

Det betyder ikke, at alle dele af AgentKit forsvinder. Men hvis din virksomhed er afhængig af canvas-miljøet til et aktivt workflow, står I nu med et migreringsprojekt – også selv om ingen endnu har føjet det til leveranceplanen.

Det er ikke nok at kopiere prompts. En fungerende agent afhænger også af routing, tool-definitioner, guardrails, state, godkendelser, fejlhåndtering og test. Bevarer du denne adfærd, har du en specifikation, som løsningen kan genopbygges ud fra. Gemmer du kun teksten i felterne, risikerer du at skulle reverse engineere dit eget system, efterhånden som fristen nærmer sig.

Det har OpenAI annonceret

OpenAI’s opdaterede annoncering af AgentKit oplyser, at Agent Builder og Evals udfases og fjernes fra platformen den 30. november 2026. OpenAI anbefaler Agents SDK til workflows, der skal videreføres som kode. Til opgaver, der egner sig bedre til instruktioner i naturligt sprog, henvises teams til Workspace Agents i ChatGPT.

Forskellen er praktisk. Agent Builder gav teams et visuelt canvas til at forbinde logik, tools, tilpassede guardrails, forhåndsvisninger, inline-evals og versioner. Udfasningen fjerner det sted, hvor disse beslutninger i øjeblikket er udtrykt. Den betyder ikke, at alle de omgivende komponenter skal udskiftes.

Den uafhængige migreringsguide skelner mellem Agent Builder og hostede Evals på den ene side og komponenter, der fortsætter, herunder ChatKit, på den anden. Den bemærker også, at MCP-baserede tool-forbindelser kan flyttes til en anden runtime. Før I genopbygger noget, bør I fastslå præcis, hvilke dele af den nuværende opsætning der er berørt.

Behandl det nuværende workflow som en specifikation

Begynd med en kortlægning. Registrer hvert workflow med ejer, version, miljø og brugere eller systemer, der anvender det. Skeln mellem kortvarige eksperimenter, interne hjælpeværktøjer og kundevendte afhængigheder. Så undgår I, at en forladt prototype får samme opmærksomhed som et workflow, der indgår i en aktiv driftsproces.

Dokumentér hvert aktivt workflow så grundigt, at en udvikler kan rekonstruere dets adfærd uden adgang til canvas-miljøet.

Workflow-aktiv	Det skal registreres	Sådan testes erstatningen
Instruktioner	Systeminstruktioner, opgaveprompts, skabeloner og variabler	Brug repræsentative input, og definer de forventede kvaliteter ved et godt svar
Routing	Forgreninger, betingelser, handoffs, stopregler og iterationsgrænser	Opret mindst én test for hver vigtig rute
Tools	Navne, schemas, autentificeringsafhængigheder, timeouts og fejladfærd	Test gyldige, ugyldige og mislykkede kald op imod tool-kontrakten
Kontroller	Guardrails for input og output, godkendelser og eskaleringspunkter	Medtag tilfælde, der skal godkendes, blokeres eller overdrages til en person
State	Samtalehistorik, sessionsgrænser og bevaret kontekst	Test flertrinsforløb samt genoptagne og udløbne sessioner
Evaluering	Datasæt, graders, kendte fejl og accepterede baselines	Kør de samme fixtures mod det nuværende workflow og erstatningen

En tjekliste til at bevare adfærden omkring prompten – ikke kun selve prompten.

Se også ud over canvas-miljøet. Registrer, hvilken applikation der kalder workflowet, hvem der reagerer, når det eskalerer, og hvilke systemer der ligger bag dets tools. Disse afhængigheder er nemme at overse, fordi de ikke er synlige som noder.

Hvis I bruger hostede Evals, angiver migreringsguiden den 31. oktober 2026 som datoen, hvor eksisterende evals bliver skrivebeskyttede. I praksis bør den betragtes som fristen for at eksportere evalueringsaktiver. Venter I til nedlukningen i november, er der meget lidt tid til at opdage, at en vigtig fixture eller grader mangler.

Vælg en destination for hvert workflow

Der er ingen grund til at presse alle prototyper ind i én erstatningsarkitektur. OpenAI peger på to overordnede retninger, og det fornuftige valg afhænger af, hvem der driver workflowet, og hvor tæt det er forbundet med andre forretningssystemer.

Workspace Agents kan egne sig til enklere internt arbejde, der primært styres med prompts. Overvej denne vej, når en kompetent medarbejder kan beskrive og føre tilsyn med opgaven i naturligt sprog, og der ikke er behov for at køre den som en skræddersyet produktionsservice.
Agents SDK egner sig til workflows, der forvaltes som software. Det passer bedre, når en agent indgår i et website, et produkt eller en driftsproces, kalder tools via definerede kontrakter, vedligeholder kontrolleret state eller kræver test, tracing, deployment og rollback med engineering-teamet som ejer.
Nogle workflows bør ikke migreres. En prototype uden ejer, brugere eller et målbart formål fortjener ikke automatisk at blive genopbygget til produktion. Fristen er en god anledning til at fjerne arbejde, der ikke længere opvejer sine vedligeholdelsesomkostninger.

Træf beslutningen for hvert enkelt workflow. Den samme virksomhed kan med god grund bruge Workspace Agents til en intern lavrisikoassistent og SDK’et til en kundevendt proces.

Genopbyg orkestreringen – ikke billedet af den

Det officielle repository for JavaScript og TypeScript Agents SDK indeholder mange af de byggesten på kodeniveau, som en migrering kan kræve: agents, tools, handoffs, guardrails, menneskelig involvering, sessioner og tracing. De er nyttige destinationer for den logik, som canvas-noderne repræsenterer i dag, men en migrering handler ikke om blot at omskrive bokse til kode.

Når workflowet bliver til applikationskode, skal nogen eje konfiguration, fejl, secrets, releases og observability. Ansvaret fandtes allerede – canvas-miljøet holdt blot dele af det ude af syne.

Et officielt cookbook-eksempel til Node SDK viser ansvarsfordelingen tydeligt. OpenAI kan angive, hvilken funktion der skal kaldes, men applikationen kalder funktionen, sender resultatet tilbage til modellen og styrer loopet. Kørsel af tools er applikationsadfærd. Den kan ikke bevares i en prompt.

Definer hvert tool som et interface. Valider dets argumenter. Skeln mellem fejl, der kan forsøges igen, og fejl, der ikke kan, begræns gentagne kald, og beslut, hvad brugeren skal se, når en afhængighed ikke er tilgængelig. Giv hver forgrening og hvert handoff en eksplicit placering i koden, og tag bevidst stilling til, hvornår sessioner begynder, genoptages og udløber.

Indbygget tracing kan hjælpe med at undersøge enkelte kørsler. Driftslogs og alarmer skal stadig passe til den omgivende applikation, især hvor en teknisk vellykket kørsel kan føre til en forretningsmæssig fejl.

Test adfærden, før indgangspunktet ændres

En agent kan levere et plausibelt svar og stadig fungere forkert i driften. Den kan kalde det forkerte tool, springe en godkendelse over, miste tidligere kontekst eller fortsætte efter en stopbetingelse. Migreringstest skal derfor dække ruter og sideeffekter – ikke kun den endelige formulering.

Opbyg et kompakt sæt fixtures ud fra virkelige eksempler, der kan håndteres korrekt, suppleret med kendte edge cases. Medtag almindelige forespørgsler, tvetydige input, tool-fejl, blokeret indhold, menneskelig eskalering og state på tværs af flere samtalerunder. Kør fixtures mod det nuværende workflow for at fastlægge en baseline, og gentag derefter med erstatningen.

Eksakt tekstsammenligning er sjældent nyttig ved ikke-deterministisk output. Test i stedet de egenskaber, der betyder noget: hvilken rute der blev valgt, hvilke argumenter der blev sendt til et tool, om den rette kontrol blev udløst, og om resultatet levede op til det krævede kvalitetsniveau.

Gennemfør overgangen gradvist. Begynd i et testmiljø. Shadow eller replay trafik, hvor politikker og datahåndtering tillader det. Frigiv løsningen til en begrænset gruppe, undersøg traces, og hold øje med fejl på forretningsniveau, før det primære indgangspunkt flyttes.

Bevar den tidligere vej eller en anden sikker fallback, indtil erstatningen har gennemført en aftalt observationsperiode. Betingelserne for rollback bør skrives ned før lanceringen, mens teamet stadig kan drøfte dem i ro og mag.

Brug fristen til at gøre workflowet lettere at eje

For teams uden ledig leverancekapacitet kan arbejdet håndteres som et fokuseret afklarings- og implementeringsforløb. Greg kan hjælpe med at kortlægge aktive aktiver i Agent Builder og Evals, dokumentere deres afhængigheder, vælge en passende destination og genopbygge kodeejede workflows med JavaScript/TypeScript eller Python Agents SDK.

Arbejdet kan også omfatte test af tool-kontrakter, evalueringsfixtures, tracing, deployment-automatisering, trinvis overgang og planlægning af rollback. Målet er at efterlade et tydeligt ejerskab og klare driftsinstruktioner – ikke at skabe endnu et uigennemsigtigt system, der afhænger af, at én person kan huske, hvordan det fungerer.

Det er vigtigt at overholde fristen den 30. november. Det mere værdifulde resultat er et workflow, som virksomheden kan inspicere, teste og ændre, når en model, et tool eller en forretningsregel ændres.

Relateret indhold på GrN.dk

Har du brug for hjælp til denne type opgave?

Planlæg migreringen fra Agent Builder – kontakt Greg.

Kilder

Sidst ændret

2026-08-26