OpenAI Agents API: Ketika Agent Tidak Lagi Perlu Dirakit dari Nol

OpenAI baru saja merilis Agents API dalam public beta. API ini membawa harness dan infrastructure yang digunakan di balik Codex ke dalam API yang bisa dipakai developer.1

Buat saya, ini bukan sekadar API baru untuk memanggil model.

Selama ini, ketika ingin membangun AI agent, kita harus merakit banyak bagian sendiri:

• memanggil model,
• mendefinisikan tools,
• menyimpan session state,
• mengatur context window,
• menangani retry,
• menjalankan command di sandbox,
• mengatur subagent,
• menyimpan hasil antara,
• serta memikirkan bagaimana agent melanjutkan pekerjaan setelah gagal.

Agents API mencoba mengurus sebagian besar pekerjaan tersebut.

Pertanyaannya bukan lagi hanya "model apa yang dipakai?", tetapi juga: apakah kita ingin membangun agent runtime sendiri atau memakai runtime yang sudah dikelola provider?

OpenAI sedang menjual harness, bukan hanya model

Model yang pintar belum cukup untuk membuat agent yang berguna.

Agent yang mengerjakan task panjang perlu mengetahui konteks sebelumnya. Ia perlu menggunakan tools secara efisien. Ia perlu bisa membaca file, menjalankan kode, menghasilkan artefak, dan melanjutkan pekerjaan tanpa kehilangan arah.

Menurut OpenAI, Agents API dibangun dari pengalaman menjalankan Codex dan ChatGPT Work dalam skala besar. API ini menyediakan session, orchestration, context management, tool usage, dan recovery yang dikelola OpenAI.1

Dalam dokumentasinya, OpenAI membagi konsep utama Agents API menjadi empat bagian:

1. Agent, yaitu model, instruction, tools, dan MCP server yang tersedia.
2. Environment, yaitu sandbox atau komputer tempat agent bekerja.
3. Session, yaitu instance agent yang menyimpan pekerjaan lintas interaksi.
4. Events dan items, yaitu input serta output yang dihasilkan selama session.2

Pembagian ini penting karena membuat kita bisa memisahkan otak agent dari tempat agent bekerja.

Agent bisa menggunakan model tertentu, tetapi eksekusinya berjalan di environment yang berbeda. Environment tersebut bisa berupa sandbox yang dikelola OpenAI atau infrastructure milik kita sendiri.

Membuat agent dengan satu API call

Contoh paling sederhana dari dokumentasi OpenAI terlihat seperti ini:

import OpenAI from 'openai'

const client = new OpenAI()

const session = await client.beta.agents.sessions.create({
  agent: {
    model: 'gpt-6-astra',
    instructions: `
      Investigate technical issues carefully.
      Explain your findings before proposing changes.
      Never access production secrets.
    `,
    tools: [
      {
        type: 'web_search',
      },
      {
        type: 'mcp',
        server_label: 'observability',
        transport: {
          type: 'http',
          server_url: 'https://observability.example.com/mcp',
        },
      },
    ],
  },
  environment: {
    type: 'openai_hosted',
    capability_directories: [
      '/workspace/capabilities/skills',
    ],
  },
  input:
    `Investigate service-api's elevated 5xx rate over the last 30 minutes.`,
})

console.log(session.id)

Contoh ini membuat session baru, menentukan model, menghubungkan tools, memilih environment, lalu memberikan task awal kepada agent.

Yang menarik bukan hanya jumlah baris kodenya. Bagian yang biasanya membutuhkan banyak glue code sekarang menjadi konfigurasi deklaratif.

Kita memberi tahu:

• model yang digunakan,
• instruction untuk agent,
• tools yang boleh dipakai,
• MCP server yang tersedia,
• environment tempat agent bekerja,
• dan task yang harus dikerjakan.

Setelah itu, aplikasi bisa menerima event dari session, menunggu hasil, atau mengirim input tambahan ke session yang sama.2

Session yang bisa dilanjutkan

Agent yang hanya bisa menjawab satu prompt biasanya belum terlalu menarik.

Masalah nyata sering berjalan lebih lama:

1. agent menerima laporan masalah,
2. agent memeriksa log,
3. agent membaca repository,
4. agent menemukan beberapa kemungkinan penyebab,
5. developer meminta validasi tambahan,
6. agent melakukan perbaikan,
7. developer meminta test dijalankan ulang.

Agents API menyediakan session yang bisa digunakan kembali. Aplikasi dapat mengirim task lanjutan ke session yang sama tanpa membangun ulang seluruh konteks dari awal.2

Untuk workflow seperti incident response atau code review, kemampuan ini cukup penting.

Bayangkan sebuah agent untuk membantu investigasi error production:

Input pertama:
"Periksa kenaikan HTTP 500 pada service-api."

Input kedua:
"Fokus hanya pada perubahan deployment terakhir."

Input ketiga:
"Bandingkan error ini dengan incident minggu lalu."

Input keempat:
"Buatkan rekomendasi mitigasi. Jangan menjalankan perubahan apa pun."

Tanpa session yang tahan lama, setiap input harus membawa ulang konteks. Dengan session, agent dapat melanjutkan pekerjaan sebelumnya.

Namun session yang durable tidak otomatis berarti agent aman. Kita tetap perlu menetapkan berapa lama data disimpan, siapa yang boleh mengaksesnya, dan bagaimana session dihapus setelah tidak diperlukan.

Sandbox memisahkan agent dari sistem utama

Salah satu bagian yang paling berguna dari Agents API adalah environment atau sandbox.

Agent dapat bekerja dengan file, menjalankan kode, memasang package yang diperlukan, dan menghasilkan artefak di dalam environment tersebut. OpenAI menyediakan hosted sandbox, tetapi developer juga dapat memilih self-hosted environment atau sandbox dari partner ecosystem.1

Pemisahan ini lebih sehat daripada memberikan akses langsung ke server aplikasi.

Untuk task seperti:

• menjalankan test,
• memproses file CSV,
• membuat laporan,
• menganalisis repository,
• atau menghasilkan dokumen,

agent tidak harus memiliki akses langsung ke production.

Saya akan mulai dengan prinsip sederhana:

Agent boleh bekerja di sandbox, tetapi sistem utama tetap mengontrol kapan hasilnya boleh masuk ke production.

Misalnya agent boleh membuat patch dan menjalankan test, tetapi tidak boleh langsung melakukan deployment. Hasil kerja agent dikirim sebagai pull request untuk direview manusia atau melewati pipeline dengan approval terpisah.

MCP dan tool search

Agents API mendukung MCP, custom function, dan built-in tools seperti web search.1

Artinya, agent dapat dihubungkan dengan sistem eksternal tanpa semua integrasi harus ditulis sebagai kode khusus di aplikasi utama.

Contoh tool yang mungkin digunakan:

• MCP server untuk dokumentasi internal,
• MCP server untuk observability,
• function untuk membaca status order,
• function untuk membuat issue,
• web search untuk mencari dokumentasi publik,
• tool untuk membaca repository,
• atau service internal untuk mengambil data analitik.

OpenAI juga memperkenalkan tool search untuk membantu agent memuat definisi tool yang relevan hanya ketika diperlukan. Ini dapat mengurangi jumlah token yang dipakai untuk mendeskripsikan semua tools di setiap interaksi.1

Bagi aplikasi yang punya banyak integrasi, pendekatan ini lebih masuk akal daripada memasukkan seluruh definisi tool ke context sejak awal.

Tetap ada satu risiko: semakin banyak tool yang tersedia, semakin besar area kesalahan agent.

Tool untuk membaca data biasanya lebih mudah diberi otonomi. Tool untuk mengubah data, mengirim pesan, menghapus record, atau memicu deployment harus memiliki batas yang jauh lebih ketat.

Multi-agent tanpa membangun orchestration sendiri

Agents API juga mendukung subagent. Task besar dapat dipecah menjadi beberapa pekerjaan independen, lalu dikerjakan secara paralel.1

Misalnya untuk investigasi incident:

• subagent pertama memeriksa deployment,
• subagent kedua menganalisis error log,
• subagent ketiga memeriksa perubahan dependency,
• agent utama menggabungkan hasilnya.

Konfigurasinya terlihat sederhana:

const session = await client.beta.agents.sessions.create({
  agent: {
    model: 'gpt-6-astra',
    instructions: `
      Investigate the incident.
      Delegate independent deployment, error, and dependency analysis.
      Combine the findings into one report.
    `,
    multi_agent: {
      enabled: true,
      max_concurrent_subagents: 3,
    },
  },
  input: `
    Investigate the elevated 5xx rate in service-api
    over the last 30 minutes.
  `,
})

Di sinilah saya akan berhati-hati.

Parallel execution memang bisa mengurangi waktu tunggu, tetapi tidak otomatis membuat hasil lebih benar. Tiga subagent bisa saja mengulang kesalahan yang sama karena membaca data atau asumsi yang sama.

Sebelum memakai multi-agent, pastikan:

• setiap subtask memang independen,
• hasil subagent dapat dilacak,
• agent utama tidak menyembunyikan konflik antarhasil,
• biaya maksimum sudah dibatasi,
• dan ada batas waktu untuk setiap pekerjaan.

Kalau task-nya sederhana, satu agent dengan tools yang tepat mungkin lebih murah dan lebih mudah diaudit.

Apa yang tidak diselesaikan oleh Agents API?

Agents API mengurangi pekerjaan infrastructure. Ia tidak menghapus pekerjaan product dan engineering.

Kita masih harus menentukan:

• data apa yang boleh diakses agent,
• tools apa yang tersedia,
• permission setiap tool,
• kapan approval manusia diperlukan,
• format output yang bisa divalidasi,
• cara menangani data sensitif,
• cara mengukur kualitas hasil,
• serta apa yang terjadi ketika agent gagal.

API juga tidak menggantikan observability. Kita tetap perlu mencatat:

• input yang diberikan,
• tools yang dipanggil,
• argumen tool,
• hasil setiap tool,
• perubahan file,
• jumlah token,
• durasi session,
• dan alasan kenapa suatu tindakan disetujui atau ditolak.

Agent yang tidak bisa diaudit bukan sistem yang siap production, meskipun demo-nya terlihat bagus.

Batasan yang perlu diperhatikan

Agents API saat ini masih public beta. OpenAI menyatakan bahwa tidak ada biaya tambahan khusus untuk penggunaan Agents API, tetapi developer tetap membayar token, tools, dan biaya container sesuai penggunaan.1

Dokumentasi OpenAI juga menyebutkan bahwa Agents API saat ini mendukung data residency hanya di Amerika Serikat dan belum mendukung Zero Data Retention. Memilih self-hosted sandbox tidak otomatis membuat penggunaan Agents API memenuhi syarat ZDR.2

Ini bukan detail kecil.

Untuk developer di Indonesia, pertanyaan yang harus dijawab sebelum menghubungkan data internal adalah:

• Apakah data pelanggan boleh diproses di luar Indonesia?
• Apakah log mengandung email, nomor telepon, atau informasi identitas?
• Apakah repository memuat secret atau konfigurasi sensitif?
• Apakah aturan kontrak client mengizinkan penggunaan managed AI service?
• Berapa lama session dan artefaknya disimpan?

Jangan menunggu sampai agent sudah terhubung dengan database production baru pertanyaan ini dibahas.

Use case yang masuk akal untuk mulai

Saya tidak akan memulai dari agent yang punya akses penuh ke seluruh sistem.

Beberapa use case dengan risiko lebih terkendali:

1. Codebase investigator

Agent membaca repository, mencari file yang relevan, menjelaskan alur kode, dan membuat rencana perubahan.

Output-nya berupa laporan atau draft patch. Tidak ada akses write ke production.

2. Incident summarizer

Agent membaca alert, log yang sudah disaring, dan riwayat deployment. Hasilnya berupa ringkasan penyebab yang mungkin serta rekomendasi langkah berikutnya.

Tindakan pemulihan tetap membutuhkan approval.

3. Documentation agent

Agent membaca perubahan kode dan membuat draft dokumentasi, changelog, atau release note.

Perubahan dapat dikirim sebagai pull request agar tetap melalui workflow biasa.

4. Internal knowledge assistant

Agent menggunakan MCP untuk membaca dokumentasi internal, SOP, dan knowledge base.

Pastikan permission di MCP mengikuti permission pengguna. Jangan membuat agent yang bisa membaca semua dokumen hanya karena lebih mudah saat setup.

5. Data analyst dengan akses read-only

Agent dapat menjalankan query analitik terbatas untuk menjawab pertanyaan bisnis.

Gunakan database replica atau role read-only. Batasi tabel, durasi query, dan jumlah record yang bisa dikembalikan.

Cara saya akan mengadopsinya

Kalau saya harus mengadopsi Agents API sekarang, urutannya kira-kira seperti ini:

1. Mulai dari task read-only.
2. Gunakan sandbox, bukan server production.
3. Hubungkan satu atau dua tools saja.
4. Simpan semua event dan tool call.
5. Ukur kualitas hasil dengan dataset task nyata.
6. Tambahkan kemampuan membuat draft perubahan.
7. Masukkan approval manusia sebelum tindakan yang berdampak.
8. Baru pertimbangkan tindakan otomatis dengan scope kecil dan mudah dipulihkan.

Saya tidak akan langsung membuat agent yang bisa membaca database, mengubah repository, mengirim email, dan melakukan deployment sekaligus.

Bukan karena agent tidak mampu melakukannya. Justru karena agent mungkin cukup mampu untuk melakukan banyak hal sebelum kita menyadari bahwa permission-nya terlalu luas.

Kesimpulan

Agents API membuat pembangunan AI agent menjadi lebih dekat dengan pekerjaan API integration biasa.

Kita tidak perlu selalu membangun sendiri session manager, context compaction, orchestration layer, sandbox lifecycle, dan mekanisme subagent. OpenAI menyediakan semua itu sebagai managed runtime.[1]2

Tetapi kemudahan ini juga bisa membuat kita terlalu cepat memberi akses.

Agent tetap perlu diperlakukan sebagai komponen software yang memiliki permission, failure mode, biaya, dan risiko. Bedanya, perilakunya tidak selalu deterministik seperti service biasa.

Jadi, saya melihat Agents API bukan sebagai alasan untuk membuat agent yang semakin bebas.

Saya melihatnya sebagai alasan untuk membuat agent yang lebih terstruktur:

• task-nya jelas,
• tools-nya terbatas,
• environment-nya terisolasi,
• hasilnya bisa diverifikasi,
• dan tindakan penting tetap membutuhkan kontrol tambahan.

API boleh mengurus harness. Keputusan tentang batas otonomi tetap tanggung jawab kita.

Sources

1 https://openai.com/index/introducing-the-agents-api — Introducing the Agents API | OpenAI

2 https://developers.openai.com/api/docs/guides/agents-api/overview — Agents API | OpenAI API