Panduan praktis OpenAI untuk membangun agen

• Seiring meningkatnya kemampuan LLM dalam penalaran, multimodalitas, dan penggunaan alat, muncul kategori sistem baru bernama agen, yang dapat menjalankan workflow secara mandiri atas nama pengguna
• Agen terdiri dari tiga komponen inti: model (LLM), alat (API/fungsi eksternal), dan instruksi (pedoman), serta dapat diorkestrasi sebagai sistem agen tunggal maupun multi-agen
• Penerapan agen cocok untuk workflow yang membutuhkan pengambilan keputusan kompleks, sistem aturan yang sulit dipelihara, dan pemrosesan data tidak terstruktur
• Guardrail adalah mekanisme pertahanan berlapis untuk melindungi privasi data, keamanan konten, dan konsistensi merek, serta merupakan elemen penting dalam deployment agen
• Pendekatan iteratif yang dimulai dari agen tunggal lalu diperluas secara bertahap setelah validasi dengan pengguna nyata adalah kunci deployment yang sukses

---

Definisi agen

• Agen adalah sistem yang secara mandiri menjalankan tugas atas nama pengguna, menangani workflow seperti menyelesaikan masalah layanan pelanggan, memesan restoran, melakukan commit perubahan kode, dan membuat laporan
• Aplikasi yang mengintegrasikan LLM tetapi tidak mengendalikan eksekusi workflow (chatbot sederhana, LLM satu giliran, pengklasifikasi sentimen, dll.) bukanlah agen
• Karakteristik utama agen:
  • Menggunakan LLM untuk mengelola eksekusi workflow dan mengambil keputusan, mengenali kapan workflow selesai, serta secara proaktif menyesuaikan tindakan bila diperlukan
  • Menghentikan eksekusi saat gagal dan mengembalikan kendali kepada pengguna
  • Memiliki akses ke berbagai alat untuk berinteraksi dengan sistem eksternal, serta secara dinamis memilih alat yang tepat sesuai status workflow saat ini, namun tetap beroperasi dalam guardrail yang jelas

Kapan perlu membangun agen

• Berbeda dari otomasi konvensional, agen cocok untuk workflow di mana pendekatan deterministik dan berbasis aturan tradisional mulai mencapai batasnya
• Contoh analisis fraud pembayaran: mesin aturan tradisional bekerja seperti checklist yang menandai transaksi berdasarkan kriteria yang telah ditetapkan, sedangkan agen LLM berperan seperti investigator berpengalaman yang menilai konteks, mempertimbangkan pola halus, dan mengidentifikasi aktivitas mencurigakan bahkan tanpa pelanggaran aturan yang jelas
• Tiga jenis situasi di mana agen memberi nilai tambah:
  • Pengambilan keputusan kompleks: workflow yang memerlukan penilaian halus, pengecualian, dan keputusan yang sensitif terhadap konteks (misalnya persetujuan refund dalam layanan pelanggan)
  • Aturan yang sulit dipelihara: sistem dengan kumpulan aturan yang besar dan rumit sehingga pembaruan mahal atau rawan error (misalnya review keamanan vendor)
  • Skenario dengan ketergantungan tinggi pada data tidak terstruktur: interpretasi bahasa alami, ekstraksi makna dari dokumen, dan interaksi pengguna berbasis percakapan (misalnya pemrosesan klaim asuransi rumah)
• Jika kriteria ini tidak terpenuhi dengan jelas, solusi deterministik mungkin sudah memadai

Dasar desain agen

• Tiga komponen inti

  • Model (Model): LLM yang menggerakkan penalaran dan pengambilan keputusan agen
  • Alat (Tools): fungsi eksternal atau API yang digunakan agen untuk bertindak
  • Instruksi (Instructions): pedoman dan guardrail eksplisit yang mendefinisikan cara agen bertindak

• Pemilihan model

  • Tidak semua tugas memerlukan model paling kuat — pencarian sederhana atau klasifikasi intent dapat ditangani dengan model kecil dan cepat, sementara tugas sulit seperti keputusan persetujuan refund lebih cocok dengan model yang lebih kuat
  • Pendekatan yang efektif adalah menetapkan baseline performa dengan model paling kuat pada tahap prototipe, lalu menggantinya dengan model yang lebih kecil untuk melihat apakah hasilnya masih dapat diterima
  • Prinsip pemilihan model:
    • Menyiapkan eval untuk menetapkan baseline performa
    • Fokus mencapai target akurasi dengan model terbaik
    • Mengganti dengan model yang lebih kecil bila memungkinkan untuk mengoptimalkan biaya dan latensi

• Mendefinisikan alat

  • Alat memperluas kemampuan agen dengan menggunakan API dari aplikasi atau sistem yang mendasarinya
  • Jika sistem legacy tidak memiliki API, model computer-use dapat digunakan untuk berinteraksi langsung melalui UI web dan aplikasi
  • Setiap alat harus memiliki definisi yang terstandarisasi, mendukung relasi many-to-many yang fleksibel antara alat dan agen
  • Alat yang reusable, terdokumentasi dengan baik, dan diuji secara menyeluruh membantu meningkatkan discoverability, menyederhanakan versioning, dan mencegah definisi yang duplikatif
  • Tiga jenis alat yang dibutuhkan agen:
    • Data (Data): mengambil konteks dan informasi yang diperlukan untuk menjalankan workflow (misalnya query DB transaksi, sistem CRM, membaca PDF, pencarian web)
    • Aksi (Action): berinteraksi dengan sistem untuk menambahkan informasi ke DB, memperbarui record, mengirim pesan, dan tindakan lain (misalnya mengirim email/SMS, memperbarui record CRM, meneruskan tiket layanan pelanggan ke manusia)
    • Orkestrasi (Orchestration): agen itu sendiri bertindak sebagai alat bagi agen lain (misalnya agen refund, agen riset, agen penulisan)

• Menyusun instruksi

  • Instruksi berkualitas tinggi penting untuk semua aplikasi berbasis LLM, tetapi terutama krusial pada agen
  • Instruksi yang jelas mengurangi ambiguitas dan meningkatkan pengambilan keputusan agen, sehingga workflow berjalan lebih mulus dengan lebih sedikit error
  • Praktik terbaik instruksi agen:
    • Memanfaatkan dokumen yang sudah ada: gunakan prosedur operasional, skrip dukungan, dan dokumen kebijakan yang ada untuk membuat rutinitas yang ramah bagi LLM (dalam layanan pelanggan, rutinitas kira-kira memetakan dokumen individual dalam knowledge base)
    • Prompt pemecahan tugas: berikan langkah-langkah yang lebih kecil dan lebih jelas dari sumber yang padat untuk meminimalkan ambiguitas
    • Definisi aksi yang jelas: nyatakan bahwa setiap langkah dalam rutinitas harus sesuai dengan aksi atau output tertentu (misalnya meminta nomor pesanan, mengambil detail akun melalui pemanggilan API)
    • Menangkap edge case: antisipasi variasi umum seperti pengguna memberikan informasi yang tidak lengkap atau mengajukan pertanyaan tak terduga, lalu sertakan langkah bersyarat atau percabangan untuk menanganinya
  • Dimungkinkan juga menggunakan model canggih seperti o1 atau o3‑mini untuk menghasilkan instruksi secara otomatis dari dokumen yang ada

Orkestrasi

• Sistem agen tunggal

  • Satu agen dapat menangani banyak tugas sambil menambahkan alat secara bertahap, sehingga pengelolaan kompleksitas serta evaluasi dan pemeliharaan menjadi lebih sederhana
  • Semua pendekatan orkestrasi membutuhkan konsep 'run', yang umumnya diimplementasikan sebagai loop tempat agen bekerja hingga mencapai kondisi penghentian
  • Kondisi penghentian yang umum: pemanggilan alat, output terstruktur tertentu, error, atau tercapainya jumlah giliran maksimum
  • Dalam Agents SDK, agen dimulai dengan metode Agents.run(), dan loop berakhir saat terjadi pemanggilan alat output final atau respons model tanpa pemanggilan alat
  • Strategi template prompt: alih-alih banyak prompt terpisah, gunakan satu prompt dasar yang fleksibel dan menerima variabel kebijakan untuk beradaptasi ke berbagai konteks, sehingga sangat menyederhanakan pemeliharaan dan evaluasi

• Kapan beralih ke sistem multi-agen

  • Rekomendasi umum adalah memaksimalkan kemampuan agen tunggal terlebih dahulu
  • Lebih banyak agen memang memberi pemisahan konsep yang intuitif, tetapi juga membawa kompleksitas dan overhead tambahan, sehingga dalam banyak kasus satu agen dengan alat sudah cukup
  • Panduan praktis membagi agen:
    • Logika kompleks: jika prompt berisi banyak kondisi (percabangan if-then-else) dan template prompt sulit diskalakan, pisahkan tiap segmen logika ke agen terpisah
    • Kelebihan alat: masalahnya bukan jumlah alat, melainkan kemiripan atau redundansi — ada implementasi yang berhasil mengelola lebih dari 15 alat yang jelas berbeda, sementara ada juga yang kesulitan bahkan dengan kurang dari 10 alat yang tumpang tindih

• Pola manajer (menggunakan agen sebagai alat)

  • LLM pusat, yaitu "manajer", mengorkestrasi jaringan agen terspesialisasi melalui pemanggilan alat
  • Manajer mendelegasikan tugas ke agen yang tepat pada saat yang tepat tanpa kehilangan konteks atau kendali, lalu mensintesis hasilnya menjadi interaksi yang terpadu
  • Cocok untuk workflow di mana hanya satu agen yang harus mengendalikan eksekusi workflow dan memiliki akses ke pengguna
  • Contoh: agen penerjemahan memanggil agen bahasa Spanyol, Prancis, dan Italia sebagai alat

• Pola terdesentralisasi (handoff antarag en)

  • Agen melakukan transisi satu arah dengan 'handoff' eksekusi workflow ke agen lain
  • Dalam Agents SDK, handoff adalah jenis alat atau fungsi; saat fungsi handoff dipanggil, status percakapan terbaru diteruskan dan eksekusi langsung dimulai pada agen baru
  • Optimal untuk situasi di mana tiap agen mengambil alih eksekusi dan berinteraksi langsung dengan pengguna tanpa perlu satu agen pusat mempertahankan kendali atau sintesis
  • Contoh: agen triase mengevaluasi kueri pengguna dan merutekannya ke agen dukungan teknis, penjualan, atau manajemen pesanan

• Graf deklaratif vs non-deklaratif

  • Beberapa framework mengharuskan semua percabangan, loop, dan kondisi didefinisikan terlebih dahulu dalam bentuk graf berisi node (agen) dan edge (handoff) secara deklaratif (declarative) — jelas secara visual, tetapi menjadi merepotkan saat workflow makin dinamis dan kompleks, serta memerlukan pembelajaran bahasa khusus domain
  • Agents SDK mengadopsi pendekatan code-first, sehingga logika workflow dapat diekspresikan langsung dengan struktur pemrograman yang familier, memungkinkan orkestrasi agen yang lebih dinamis dan adaptif tanpa harus mendefinisikan seluruh graf di awal

Guardrail

• Peran guardrail

  • Membantu mengelola risiko privasi data (misalnya mencegah kebocoran system prompt) dan risiko reputasi (misalnya memaksa perilaku model yang sesuai merek)
  • Satu guardrail saja sulit memberi perlindungan yang cukup; perlu menggabungkan banyak guardrail terspesialisasi untuk membangun agen yang lebih tangguh
  • Guardrail adalah komponen penting, tetapi tetap harus dikombinasikan dengan protokol autentikasi dan otorisasi yang kuat, kontrol akses yang ketat, dan langkah keamanan perangkat lunak standar

• Jenis guardrail

  • Pengklasifikasi relevansi (Relevance classifier): memeriksa apakah respons agen berada dalam cakupan yang dimaksud dan menandai kueri di luar topik (misalnya "berapa tinggi Empire State Building?" ditandai sebagai di luar topik)
  • Pengklasifikasi keamanan (Safety classifier): mendeteksi input tidak aman seperti jailbreak atau prompt injection yang mencoba mengeksploitasi kerentanan sistem
  • Filter PII: mencegah paparan informasi identitas pribadi (PII) yang tidak perlu dalam output model
  • Moderasi (Moderation): menandai input yang berbahaya atau tidak pantas seperti ujaran kebencian, perundungan, dan kekerasan
  • Tool safeguards: memberi peringkat risiko rendah/sedang/tinggi pada tiap alat berdasarkan akses read-only vs write, reversibilitas, izin akun yang diperlukan, dampak finansial, dan lain-lain; lalu memicu aksi otomatis seperti menghentikan pemeriksaan guardrail atau eskalasi ke manusia sebelum menjalankan fungsi berisiko tinggi
  • Perlindungan berbasis aturan (Rules-based protections): langkah deterministik sederhana seperti daftar blokir, batas panjang input, dan filter regex untuk mencegah ancaman yang sudah dikenal seperti istilah terlarang atau SQL injection
  • Validasi output (Output validation): memastikan respons selaras dengan nilai merek melalui prompt engineering dan pemeriksaan konten

• Pendekatan membangun guardrail

  • Mulailah dari guardrail untuk risiko yang sudah teridentifikasi, lalu tambahkan lapisan baru saat kerentanan baru ditemukan
  • Heuristik yang efektif:
    • Fokus pada privasi data dan keamanan konten
    • Tambahkan guardrail baru berdasarkan edge case nyata dan kasus kegagalan
    • Optimalkan keamanan dan pengalaman pengguna sekaligus, lalu sesuaikan guardrail seiring evolusi agen
  • Dalam Agents SDK, guardrail diperlakukan sebagai konsep first-class, dan secara default menggunakan pendekatan optimistic execution — agen utama secara proaktif menghasilkan output sementara guardrail berjalan bersamaan, lalu memicu exception jika terjadi pelanggaran batasan

• Perencanaan human-in-the-loop

  • Keterlibatan manusia adalah pengaman penting yang dapat meningkatkan performa nyata agen tanpa merusak pengalaman pengguna
  • Sangat penting terutama pada tahap awal deployment, membantu mengidentifikasi kegagalan, menemukan edge case, dan membangun siklus evaluasi yang kuat
  • Dua pemicu utama untuk intervensi manusia:
    • Melebihi ambang kegagalan: tetapkan batas pada retry atau tindakan agen, lalu eskalasi ke manusia saat terlampaui (misalnya gagal memahami intent pelanggan setelah beberapa percobaan)
    • Tindakan berisiko tinggi: tindakan yang sensitif, tidak dapat dibatalkan, atau memiliki konsekuensi besar (misalnya membatalkan pesanan pengguna, menyetujui refund besar, memproses pembayaran) memerlukan pengawasan manusia sampai tingkat kepercayaan terhadap agen cukup tinggi

Kesimpulan

• Agen menandai era baru otomasi workflow dengan kemampuan menalar ambiguitas, bertindak melalui alat, dan menangani tugas multi-langkah dengan otonomi tinggi
• Berbeda dari aplikasi LLM sederhana, agen menjalankan workflow end-to-end, sehingga cocok untuk pengambilan keputusan kompleks, data tidak terstruktur, dan sistem berbasis aturan yang rapuh
• Untuk membangun agen yang andal: gabungkan model yang mumpuni, alat yang terdefinisi dengan baik, serta instruksi yang jelas dan terstruktur; gunakan pola orkestrasi yang sesuai dengan tingkat kompleksitas, namun mulailah dari agen tunggal dan perluas ke multi-agen hanya saat diperlukan
• Guardrail penting di setiap tahap, mulai dari pemfilteran input hingga penggunaan alat dan intervensi manusia, untuk memastikan agen beroperasi dengan aman dan dapat diprediksi di production
• Deployment yang sukses bukan pendekatan all-or-nothing, melainkan memulai dari kecil, memvalidasi dengan pengguna nyata, lalu mengembangkan kemampuan seiring waktu

• Tersedia juga dalam PDF