Pada 10 September, OpenAI merilis Agents API ke dalam tahap beta publik, “menghadirkan harness dan infrastruktur yang sama yang mentenagai Codex kepada para developer melalui API yang sederhana dan fleksibel.” Di ajang DevDay pada 29 September, API ini mendapatkan fitur computer use, saudara native-AWS, serta pendamping baru: fitur dots yang selalu aktif (always-on) milik ChatGPT kini berjalan di atas harness Codex yang sama.
Bagi developer yang sedang membangun produk berbasis agen, ini adalah kabar baik: harness yang tadinya mungkin akan Anda bangun secara serampangan kini menjadi urusan pihak lain. Namun, bagi engineer yang timnya sudah menjalankan Claude Code dan Codex pada basis kode nyata, pertanyaannya jadi berbeda. API ini menjawab “bagaimana cara menjaga agen tetap berjalan selama berjam-jam?” Namun, API ini tidak menjawab “bagaimana tim saya mengetahui apa yang dilakukan oleh enam agen sekaligus, dan siapa yang menyetujui situs web yang baru saja dimasuki oleh salah satu agen tersebut?” Sharkly hadir untuk menjawab pertanyaan kedua.
TL;DR
Agents API menjadi tempat bagi harness Codex: sesi yang persisten (durable session), pemadatan konteks (compaction), pencarian alat (tool search), sub-agen, serta sandbox dari OpenAI, infrastruktur Anda sendiri, atau sembilan mitra lainnya, tanpa biaya tambahan selain token, pemanggilan alat, dan durasi container. DevDay menambahkan fitur computer use—di mana aplikasi Anda menyetujui setiap origin situs web baru dan setiap upaya login (persetujuan origin bukanlah konfirmasi untuk setiap tindakan individual)—serta Bedrock Managed Agents, yang menjalankan kemampuan intinya di dalam AWS. Tak satu pun dari fitur tersebut yang mengelola lapisan tim (team layer): siapa yang menugaskan pekerjaan, agen mana yang mengerjakannya, apa yang sudah selesai, apa yang gagal, dan siapa yang menyetujui hasilnya.
Apa itu Agents API dan apa saja yang dikelola OpenAI
Ringkasan umum dari OpenAI merangkum API ini ke dalam empat konstruksi utama. Agent adalah “model, instruksi, alat, dan server MCP yang tersedia bagi agen.” Environment adalah “sandbox atau komputer opsional tempat agen mengakses file, memuat keahlian (skills), dan menjalankan perintah.” Session adalah “instans persisten dari agen yang mengerjakan tugas dan merespons input.” Sedangkan Events and items adalah input yang Anda kirimkan dan output yang dikembalikan.
Anda membuat sesi dengan konfigurasi agen, memberikannya tugas setelah environment siap, memantau perkembangannya melalui streaming atau webhook, lalu mengirimkan lebih banyak tugas atau arahan ke dalam sesi yang sama. Contoh ringkas dari dokumentasinya:
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Use the docs MCP and web search. Delegate independent research to subagents when useful.",
tools: [
{ type: "programmatic_tool_calling" },
{ type: "mcp", server_label: "openai_docs", transport: { type: "http", server_url: "https://developers.openai.com/mcp" } },
{ type: "web_search" },
],
multi_agent: { enabled: true, max_concurrent_subagents: 4 },
},
environment: { type: "self_hosted", workspace_directory: "/workspace" },
input: [{ role: "user", content: [{ type: "input_text", text: "Research how to connect an MCP server to an OpenAI agent and summarize the setup." }] }],
});
Dua baris kode di atas memuat poin-poin terpenting. multi_agent mengaktifkan ekspansi sub-agen (fan-out) dengan batas konkurensi, dan environment.type menentukan tempat kode dijalankan: openai_hosted, self_hosted, atau salah satu sandbox mitra (Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel).
Dokumentasi resminya merangkum pembagian kerja ini dalam satu kalimat: “OpenAI mengelola sesi, orkestrasi, pemadatan konteks (context compaction), dan pemulihan, sementara aplikasi Anda menyediakan alat serta memilih lingkungan eksekusinya.”
| Dikelola oleh OpenAI | Tetap Anda sediakan |
|---|---|
| Loop agen: pemanggilan model, penggunaan alat, percobaan ulang (retry) | Tugas dan kriteria penyelesaian (definition of done) |
| Pemadatan konteks saat sesi mendekati batasnya | Alat: server MCP, fungsi, fitur bawaan (built-in) |
| Pencarian dan pemuatan alat | Kredensial, melalui ID vault |
| Dekomposisi dan koordinasi sub-agen | Pilihan environment dan pengaturannya |
| Melanjutkan sesi dan pengarahan (steering) | Segala hal yang terjadi setelah sesi berakhir |
Penggunaan model ditagih sesuai tarif API model tersebut, alat ditagih dengan tarif standar, dan sandbox yang di-host OpenAI ditagih berdasarkan tarif container; artikel peluncurannya menyebutkan bahwa “tidak ada biaya tambahan untuk menggunakan Agents API.” Dua batasan dinyatakan dengan jelas di dokumentasinya: API ini “saat ini hanya mendukung residensi data di Amerika Serikat dan tidak mendukung Zero Data Retention (ZDR),” serta memilih sandbox self-hosted tidak otomatis membuatnya memenuhi syarat ZDR. Jika salah satu hal ini krusial bagi kepatuhan (compliance) Anda, memindahkan sandbox ke infrastruktur internal tetap tidak akan mengubah ketentuan tersebut.
Pembaruan yang dihadirkan di DevDay
Computer use. Tambahkan alat computer_use, aktifkan desktop di environment yang di-host OpenAI, dan agen akan mengoperasikan browser ter-host. Panduan computer use merancang alurnya di sekitar peristiwa persetujuan (approval events). Browser akan meminta persetujuan pengguna sebelum mengakses setiap origin situs web baru, termasuk situs publik. Permintaan login akan muncul sebagai permintaan terpisah yang dirender oleh aplikasi Anda untuk kolom email, kata sandi, dan kode verifikasi; passkey dan login dengan kode QR tidak didukung, dan hanya agen utama—bukan sub-agen—yang dapat meminta kredensial. Kalimat yang patut diperhatikan secara seksama: “Persetujuan origin tidak memberlakukan konfirmasi sebelum tindakan individual dilakukan.” Untuk transaksi pembelian atau perubahan yang bersifat destruktif, dokumentasi menyarankan untuk membatasi browser ter-host ke sumber daya yang tidak dapat melakukan tindakan tersebut, atau menggunakan runtime browser yang Anda kendalikan sendiri. Rangkuman DevDay mencatat bahwa fitur computer use tersedia “melalui API serta di Codex dan ChatGPT Work pada paket Pro 500 dan Enterprise.”
Bedrock Managed Agents, powered by OpenAI. OpenAI dan Amazon mengadopsi “kemampuan inti dari Agents API” dan menambahkan kustomisasi agar dapat bekerja secara native di AWS. Halaman produk AWS mencantumkannya sebagai versi preview dan menyatakan bahwa runtime agen serta inferensi model tetap berada di dalam AWS, dengan setiap agen memiliki identitas dan izin AWS tersendiri.
Dots di atas harness yang sama. Decrypt melaporkan bahwa harness Codex “kini mentenagai dots dan bersifat open source.” Dots merupakan agen always-on dari ChatGPT, masing-masing dilengkapi komputer cloud sendiri, dan ulasan kami tentang dots mengupas tuntas keunggulannya.
Kini satu loop yang sama dapat menjalankan agen coding, sesi API, agen AWS, dan asisten yang selalu aktif. Ekosistem harness mulai menyatu. Namun, peristiwa persetujuan adalah bagian yang menjadi beban tim: setiap persetujuan merupakan pertanyaan di dalam satu sesi, yang harus dijawab oleh siapa pun yang sedang memantau alirannya (stream). Ketika ada lima sesi yang meminta persetujuan sekaligus, harus ada yang memutuskan siapa yang berhak menyetujui origin mana, serta di mana keputusan tersebut dicatat. Ini adalah masalah approval gate (gerbang persetujuan), dan kami telah mengupas solusi dari sisi Computer dalam guardrail computer use GPT-6 Astra.
Hal yang tidak dikelola: lapisan tim (team layer)
Sebuah sesi hanya mengetahui dirinya sendiri. Sesi tersebut tidak tahu bahwa ada tiga sesi lain yang sedang menyentuh repositori yang sama, atau bahwa hasil dari sesi keempat dibiarkan belum dibaca sejak hari Selasa. Ini adalah persoalan manajemen, dan masalah tersebut langsung muncul begitu ada lebih dari satu orang yang menjalankan lebih dari satu agen.
Lima pertanyaan yang memang sengaja tidak dijawab oleh API ini:
- Siapa yang menugaskan ini, dan mengacu pada tiket yang mana? Sebuah sesi hanya memiliki ID dan metadata apa pun yang ditulis oleh kode Anda. Pemilik (owner), Sprint, atau tautan ke isu asalnya hanya akan ada jika Anda menyertakannya secara manual.
- Repositori dan branch mana yang diubah? Perubahan kode (diff) harus dibawa ke suatu tempat agar reviewer dapat memeriksanya.
- Apa yang sudah selesai, apa yang gagal, dan apa yang sedang menunggu? Event hanya mengalir selama Anda mendengarkannya, atau tiba melalui webhook. Tidak ada sistem yang mengumpulkannya ke dalam antrean hasil untuk ditinjau seseorang.
- Siapa yang menyetujui hasilnya? Peristiwa persetujuan (approval event) hanya mencakup akses situs web atau login, bukan hasil pekerjaannya. Bagi sistem, “sesi telah berakhir” dan “seseorang telah meninjau buktinya lalu menyetujuinya” adalah peristiwa yang sama, kecuali jika Anda membangun mekanisme kedua secara mandiri.
- Bagaimana dengan agen yang bukan buatan OpenAI? Menggunakan Claude Code untuk satu jenis pekerjaan dan Codex untuk jenis pekerjaan lain berarti ada dua model sesi dan dua tempat berbeda yang harus dipantau.
Anda bisa saja membangun kelima fungsi tersebut di atas data event: membuat papan tugas, webhook, kolom status, dan kolom review. Namun, ketika ada yang bertanya “apakah perbaikan fitur ekspor sudah di-deploy?”, jawabannya ternyata terselip di riwayat scrollback yang tidak sempat disimpan siapa pun. Artikel tentang manajemen tugas agen AI mengulas pendekatan membangun sistem ini sendiri.
Sub-agen di dalam sesi, atau Task di papan kerja?
Parameter max_concurrent_subagents adalah solusi API ini untuk pemrosesan paralel, dan sangat tepat untuk pola pekerjaan yang sesuai. Ini adalah trade-off yang pernah kami bahas ketika Codex menaikkan batas sub-agennya menjadi 64: sub-agen berbagi induk yang sama, melapor kembali ke dalam satu respons terpadu, dan ditinjau sebagai satu hasil utuh.
Gunakan sub-agen di dalam sesi ketika tugasnya didominasi operasi baca (read-heavy), independen, dan hanya jawaban akhirnya yang penting: meriset empat API, memindai pola tertentu pada basis kode, atau mengumpulkan bukti untuk investigasi insiden.
Gunakan Task terpisah ketika setiap bagian menulis kode yang harus ditinjau secara tersendiri oleh seseorang: migrasi database, fitur baru pada suatu modul, atau perbaikan bug yang menyentuh file bersama. Di Sharkly, setiap eksekusi mendapatkan git worktree terisolasi di Computer milik Anda sendiri, dan setiap hasil kembali ke Task-nya masing-masing lengkap dengan diff, log eksekusi, serta reviewer yang ditugaskan. Menyatukan empat perubahan penulisan kode besar (write-heavy) ke dalam satu ringkasan sub-agen sama saja dengan menyembunyikan empat keputusan penting di balik satu rangkuman.
Pertanyaan yang sering diajukan (FAQ)
Model mana yang menjalankan fitur computer use? Contoh di dokumentasi menggunakan gpt-6-astra. Pastikan untuk memeriksa panduannya terlebih dahulu sebelum mengasumsikan model lain dapat berfungsi dengan alat computer_use.
Apakah Sharkly menjalankan sesi Agents API? Sharkly menjalankan agen coding berbasis CLI yang terpasang di Computers Anda, seperti Codex dan Claude Code, sebagai Runtime. Sesi Agents API adalah layanan ter-host, bukan Runtime yang dipasang, sehingga perlu diperlakukan sebagai jalur eksekusi yang berbeda.
Di mana review oleh manusia dilakukan? Pada Agents API, proses ini berada di mana pun Anda membangunnya: peristiwa persetujuan hanya mencakup akses situs web dan proses login, bukan penerimaan atas hasil akhir pekerjaan. Di Sharkly, sebuah Agent dapat menandai Task-nya agar menunggu tinjauan manusia; permintaan tersebut akan masuk ke Inbox penanggung jawab, dan orang tersebut akan mengubah statusnya setelah membaca respons, log eksekusi, dan diff.
Menempatkan setiap lapisan pada porsinya
Sesi persisten (durable session) di infrastruktur OpenAI adalah fitur paling praktis dalam peluncuran ini, sekaligus yang paling mengikat (sticky). Bagi tim engineering, hal ini sangat krusial, karena agen coding terbaik saat ini selalu berubah-ubah. Tim yang status review dan aturan penugasannya bergantung pada penyimpanan sesi satu vendor terpaksa harus membangun ulang alur kerjanya setiap kali pemimpin pasar berganti.
Jika Anda sedang membangun produk berbasis agen atau layanan backend, Agents API adalah lapisan yang tepat, demikian pula Bedrock Managed Agents bagi tim yang membutuhkannya di lingkungan AWS. Anda mendapatkan harness tanpa perlu repot merawatnya serta sandbox tanpa perlu melakukan provisioning manual. Anda bahkan mungkin tidak memerlukan papan tugas sama sekali; aplikasi Andalah papannya.
Namun, jika agen Anda diposisikan layaknya rekan tim pada basis kode internal—dijalankan oleh manusia, ditinjau oleh manusia, dan di-ship melalui repositori serta tracker yang sudah ada—situasinya menjadi sangat berbeda. Codex dan Claude Code bertindak sebagai eksekutor. Sharkly mengelola penugasan di tingkat tim, Computer yang terhubung, konteks tugas, progres, kendala (blocker), hasil akhir, serta review manusia di seluruh alat tersebut. Sharkly bukanlah pengganti bagi Runtime tersebut maupun bagi Agents API. Pertanyaan penempatan lapisan yang sama kini juga berlaku untuk Codex itu sendiri, yang kami bahas dalam Codex cloud vs your own Computers.
Sewa harness jika Anda sedang membangun produk agen. Namun, pertahankan lapisan manajemen tetap di tangan Anda dan netral terhadap vendor jika Anda mengelola agen-agen tersebut sebagai tim.
Jika Anda sudah menjalankan beberapa agen, Sharkly menyediakan satu tempat terpusat untuk mengelola tugas dan hasil kerja mereka. Sharkly tidak menjual token: penggunaan model tetap menggunakan langganan atau API key yang telah dikonfigurasi pada alat yang Anda hubungkan.
