Agent Builder OpenAI Ditutup: Migrasi Sebelum 30 Nov 2026

Barisnya di halaman deprecations OpenAI pendek saja: Agent Builder, diumumkan 3 Juni 2026, dijadwalkan berhenti pada 30 November 2026. Dua baris di atasnya, platform Evals mendapat tanggal read-only 31 Oktober. Kalau ada workflow drag-and-drop yang menjawab pelanggan lewat widget ChatKit, atau diam-diam menyetujui purchase order di balik tool internal, artinya tinggal dua bulan dari hari ini untuk memindahkannya, dan satu bulan untuk menyelamatkan test case yang membuktikan workflow itu masih benar.

Tulisan ini membahas penutupan OpenAI Agent Builder sebagai proyek migrasi, bukan sekadar berita: apa yang hilang dan apa yang bertahan, cara menginventaris workflow yang mungkin dirujuk dari kode yang sudah tidak diingat siapa pun, apa sebenarnya hasil export Code, cara membangun ulang dua node yang tidak pernah pindah dengan bersih, dan cara memilih antara Agents SDK dan ChatGPT Workspace Agents untuk tiap workflow. Semua tanggal dan nama API diambil dari pengumuman deprecation, panduan migrasi, node reference dan dokumentasi Agents SDK milik OpenAI sendiri.

Apa yang dihapus oleh penutupan OpenAI Agent Builder, dan apa yang tetap

Cakupan penutupannya lebih sempit daripada kesan dari judul berita, tetapi tiga tenggat jatuh di platform yang sama sekaligus. Canvas visual hilang, tooling eval yang di-host hilang, dan objek reusable prompt yang dipakai banyak workflow juga hilang di hari yang sama. Komponen runtime di bawahnya, yaitu Agents SDK dan ChatKit, tetap ada.

Baris yang paling sering terlewat adalah baris ketiga. Workflow yang sudah dipindah ke kode tetapi masih merujuk objek prompt tersimpan belum benar-benar dimigrasi, hanya dipindah dari satu tenggat 30 November ke tenggat 30 November yang lain. Perlakukan teks prompt sebagai source code: salin ke repository, review seperti kode, dan beri versi bersama agent yang memakainya.

Inventaris semua workflow sebelum meng-export apa pun

Canvas menampilkan workflow apa saja yang ada, tetapi tidak menampilkan di mana workflow itu dipakai. Deployment Agent Builder sampai ke production lewat dua jalan, yaitu session ChatKit yang dibuat dengan workflow ID, atau kode hasil export yang sudah lebih dulu disalin seseorang, jadi inventaris harus dimulai dari sisi pemakai. Untuk setiap workflow, catat lima hal:

1. Workflow ID dan versi published yang benar-benar dijalankan production, karena draft di canvas bukan yang dilihat pengguna.
2. Semua tempat ID itu dirujuk: konfigurasi ChatKit di front-end, pembuatan session di back-end, file environment dan template infrastruktur.
3. Daftar node, dengan perhatian khusus pada kondisi If/else dan While, langkah Human approval, pengaturan Guardrails, dan vector store ID di balik setiap node File search.
4. Setiap koneksi eksternal, yaitu MCP server dan connector, beserta siapa pemilik kredensialnya, karena tidak satu pun ikut terbawa saat export.
5. Test case dan eval run yang mendefinisikan perilaku yang benar, yang harus disalin keluar sebelum Evals menjadi read-only pada 31 Oktober.

# 1. Every Agent Builder workflow your code still points at.
#    ChatKit sessions created against Agent Builder carry a wf_ ID.
grep -rnoE "wf_[0-9a-f]{20,}" \
  --include=*.{ts,tsx,js,py,json,yaml,yml} --include=.env* . | sort -u

# 2. Reusable prompt objects: v1/prompts shuts down on the same day,
#    so a workflow migrated onto a pmpt_ reference just moves the problem.
grep -rnoE "pmpt_[0-9a-zA-Z]+" --include=*.{ts,js,py,json} . | sort -u

# 3. Vector stores the File search nodes read from. These survive the
#    shutdown, but the new code has to name them explicitly.
grep -rnoE "vs_[0-9a-zA-Z]{20,}" . | sort -u

Pencarian di bawah menemukan rujukan yang tidak bisa ditampilkan dashboard. Jalankan di semua repository yang berkomunikasi dengan OpenAI, bukan hanya repository yang Anda kira memiliki agent tersebut. Workflow ID di dokumentasi ChatKit berbentuk wf_, vector store ID diawali vs_, dan rujukan prompt tersimpan diawali pmpt_, jadi tiga pola sudah mencakup semuanya. Apa pun yang muncul di file environment pasti ada pemiliknya, dan orang itu masuk daftar migrasi.

Export Code menghasilkan kode Agents SDK, bukan graph yang dikonversi

Export-nya sendiri hanya butuh satu menit. Buka workflow, pilih Code di navigasi atas, pilih Agents SDK, pilih TypeScript atau Python, lalu salin seluruh output. Panduan migrasi OpenAI sendiri terus terang soal hasilnya: proses ini tidak mengonversi workflow graph dan tidak menjamin setiap perilaku berpindah tanpa perubahan. Hasilnya adalah titik awal dalam bentuk kode, dan panduan itu menyebut control flow, trigger, tool dan permission sebagai hal yang mungkin harus dibuat ulang secara manual.

Cara yang berguna untuk membaca hasil export adalah node demi node, dicocokkan dengan node reference. Sebagian node punya padanan langsung di Agents SDK. Sebagian lagi adalah fitur canvas tanpa objek runtime di baliknya, dan di situlah perilaku bisa berubah tanpa disadari.

Bangun ulang percabangan dan human approval di kode

Dua jenis node lebih layak ditulis ulang daripada sekadar di-review. Node If/else dan While adalah ekspresi CEL yang dievaluasi canvas; di kode keduanya menjadi kondisi biasa, dan itu justru lebih baik, karena konstanta di sebuah module bisa di-unit-test sedangkan kondisi yang tersembunyi di dalam node tidak bisa. Human approval lebih sulit, karena dulu canvas yang menyimpan workflow yang sedang di-pause. Di Agents SDK, pause itu menjadi data: tool yang ditandai needs_approval menghentikan run, panggilan yang tertunda muncul di result.interruptions, dan result.to_state() mengubah seluruh run menjadi string yang Anda simpan sampai ada yang memutuskan. Contoh di bawah adalah rilis purchase order untuk back office ERP.

from agents import Agent, Runner, RunConfig, RunState, FileSearchTool
from agents.decorators import tool

# Was: a CEL expression in an If/else node, e.g. state.amount_idr < 50000000.
# Now: a constant in code, which a unit test can pin down.
AUTO_RELEASE_LIMIT_IDR = 50_000_000

# Was: a Human approval node after the reviewing agent.
# Now: the approval sits on the one tool that has a side effect,
# so the model can read and reason freely but cannot release alone.
@tool(needs_approval=True)
async def release_purchase_order(po_number: str, amount_idr: int) -> str:
    # call the ERP here; this body only runs after a human approves
    return f"PO {po_number} released"

reviewer = Agent(
    name="PO reviewer",
    instructions="Check the purchase order against the budget policy, then release it.",
    tools=[
        FileSearchTool(vector_store_ids=["vs_..."], max_num_results=5),
        release_purchase_order,
    ],
)

async def review(po: dict, store) -> str:
    if po["amount_idr"] < AUTO_RELEASE_LIMIT_IDR:
        return "auto-release"  # this branch never reaches the model

    result = await Runner.run(
        reviewer,
        f"Review PO {po['number']} for {po['amount_idr']} IDR",
        run_config=RunConfig(
            workflow_name="po-release",
            trace_metadata={"migrated_from": "agent-builder"},
        ),
    )
    if result.interruptions:
        # The canvas held this pause for you. Now it is a row in your database,
        # because the approver may answer tomorrow, from another process.
        await store.save(po["number"], result.to_state().to_string())
        return "awaiting-approval"
    return str(result.final_output)

async def decide(po_number: str, approved: bool, store) -> str:
    # Load the snapshot from YOUR storage, never from the request body.
    state = await RunState.from_string(reviewer, await store.load(po_number))
    for item in state.get_interruptions():
        if approved:
            state.approve(item)
        else:
            state.reject(item, rejection_message="Rejected by the finance approver.")
    result = await Runner.run(reviewer, state)
    return str(result.final_output)

Ada dua keputusan desain yang terlihat di kode itu. Cabang yang tidak butuh model dijalankan sebelum model dipanggil, jadi purchase order kecil tidak memakan token dan tidak bisa dibujuk masuk ke jalur lain. Lalu approval dipasang pada satu-satunya tool yang punya side effect, bukan pada seluruh agent, sehingga reviewer tetap bebas membaca kebijakan anggaran dan menjelaskan alasannya, sementara rilisnya sendiri menunggu manusia. Saat approver menjawab, RunState.from_string membangun ulang run, state.approve atau state.reject mencatat keputusan, dan Runner.run melanjutkan dari titik berhenti.

Agents SDK atau Workspace Agent: pilih per workflow

OpenAI menawarkan dua tujuan dan menggambarkannya secara berbeda: Agents SDK paling cocok untuk membangun agent lewat kode, Workspace Agents paling cocok untuk membangun agent lewat bahasa alami dan membagikannya ke tim. Panduan migrasi menambahkan kalimat yang seharusnya menentukan sebagian besar kasus, yaitu bahwa workflow yang intinya sangat deterministik mungkin tidak bermigrasi dengan setia ke workspace agent. Pilah setiap workflow dengan empat pertanyaan:

• Apakah workflow ini tertanam di produk Anda, biasanya lewat ChatKit? Kalau ya, ia butuh server yang Anda kendalikan, dan dari dua pilihan itu hanya Agents SDK yang memberikannya.
• Apakah workflow ini mem-posting, merilis, mengirim atau menghapus sesuatu di sistem lain? Percabangan deterministik dan approval gate yang bisa dites tempatnya di kode.
• Apakah ini asisten internal untuk satu tim yang sebagian besar membaca dan merangkum? Workspace Agent lebih murah dirawat, asalkan Anda memakai ChatGPT Business, Enterprise atau Edu dan punya izin membuat agent.
• Apakah tidak ada yang membukanya sejak demo pertama? Pensiunkan saja. Tenggat adalah momen termurah untuk menghapus workflow yang tidak jelas siapa pemiliknya.

Jalur Workspace Agent juga dimulai dari hasil export. Anda menempelkan kode export ke ChatGPT dengan prompt yang meminta workflow itu dikonversi menjadi agent, membaca perubahan perilaku yang ditunjukkan builder, mengonfigurasi app, skill, autentikasi dan permission yang dibutuhkan, lalu memakai Preview dengan input yang representatif sebelum memilih Create. Panduannya jelas menyebut bahwa connected app, publishing dan permission dikonfigurasi terpisah di ChatGPT, jadi inventaris kredensial dari langkah kedua tetap berlaku.

Mempertahankan front end ChatKit setelah workflow ID-nya mati

ChatKit tetap hidup, tetapi salah satu dari dua jalur integrasinya tidak. Jalur Agent Builder-hosted, tempat Anda meng-embed ChatKit dan mengarahkannya ke workflow ID, kini didokumentasikan hanya untuk pengguna lama. Jalur yang direkomendasikan adalah custom server integration: ChatKit berjalan di infrastruktur Anda sendiri, ChatKit Python SDK melayani percakapan, dan di belakangnya ada agent apa pun yang sudah Anda migrasikan, biasanya kode Agents SDK dari bagian-bagian sebelumnya.

Dalam praktiknya, widget di front-end paling sedikit berubah dan back end paling banyak berubah. Endpoint session yang dulu memberi ChatKit sebuah workflow ID berubah menjadi server yang menjalankan agent Anda dan men-stream output-nya, dan pause approval dari bagian keempat butuh cara untuk muncul di dalam chat. Rencanakan widget dan server sebagai satu perubahan yang di-deploy bersama, bukan mengganti back end di bawah widget yang sedang live pada minggu terakhir November.

Buktikan parity sebelum tanggal read-only Evals

Hasil export yang bisa di-compile tidak membuktikan apa pun soal perilaku, dan bukti tentang seperti apa perilaku yang benar tersimpan di platform yang menjadi read-only pada 31 Oktober. Sebelum tanggal itu, salin dataset dan hasil yang diharapkan untuk setiap workflow, dan simpan sekumpulan input nyata dari traffic production. Lalu jalankan agent hasil migrasi di atasnya dengan pengecekan yang membandingkan hal yang paling penting: apakah approval gate terpicu dan apakah jawabannya masih memuat hal yang wajib ada.

import asyncio, json
from agents import Runner

# cases.jsonl: one line per captured run from the old workflow, e.g.
# {"input": "...", "expect_approval": true, "must_mention": ["budget"]}

async def parity(agent, path: str = "cases.jsonl") -> None:
    failures = []
    for line in open(path, encoding="utf-8"):
        case = json.loads(line)
        result = await Runner.run(agent, case["input"])
        paused = bool(result.interruptions)
        text = "" if paused else str(result.final_output).lower()

        if paused != case["expect_approval"]:
            failures.append((case["input"], "approval gate differs"))
        for word in case.get("must_mention", []):
            if not paused and word not in text:
                failures.append((case["input"], f"missing '{word}'"))

    for inp, why in failures:
        print(f"FAIL  {why}: {inp[:60]}")
    raise SystemExit(1 if failures else 0)

Script seperti ini sengaja dibuat kecil. Ia mengodekan dua failure mode yang paling penting dalam migrasi, yaitu approval yang tidak lagi melakukan pause dan jawaban yang kehilangan fakta wajib, dan ia keluar dengan kode non-zero sehingga bisa memblokir deploy di CI. Untuk suite yang lebih lengkap dengan rubric berbasis model dan assertion untuk tool call, Promptfoo adalah tujuan yang disebut OpenAI sendiri untuk pengguna Evals, dan tulisan lain di situs ini membahas perpindahan itu secara detail.

Tenggatnya pasti, dan tooling-nya membuat langkah pertama terlihat sudah selesai. Aturan yang saya bawa dari migrasi ini: sebuah workflow baru benar-benar termigrasi ketika tiga hal ada di luar Agent Builder, yaitu prompt-nya di repository Anda, percabangan dan approval-nya di kode yang bisa dites, dan parity run terhadap input nyata yang sudah lulus. Workflow yang belum punya ketiganya pada 30 November akan berhenti begitu saja.