Agen AI Anda Sedang Menunggu Anda: Ubah Gerbang Persetujuan Jadi Panggilan Telepon

Daftar Isi

• Seberapa sering sebenarnya insiden agen terjadi?
• Apa yang sebenarnya terjadi ketika agen butuh manusia?
• Peristiwa agen mana yang layak ditelepon?
• Cara menyambungkan gerbang persetujuan agen ke panggilan telepon
• Langkah 1 — Buat saluran Panggilan untuk agen yang terhambat
• Langkah 2 — Kirim webhook dari cabang persetujuan Anda
• Langkah 3 — Pakai hook ketika agennya berupa CLI, bukan pustaka
• Langkah 4 — Tangkap agen yang hanya mengirim email
• Langkah 5 — Tambahkan kondisi agar hanya hambatan nyata yang berdering
• Langkah 6 — Ujilah dengan Do Not Disturb aktif
• Bukankah ini cuma menciptakan ulang kelelahan peringatan dengan lonceng yang lebih keras?
• Yang tidak dilakukan Echobell
• FAQ
• Bisakah saya menyetujui aksi agen langsung dari panggilan teleponnya?
• Peristiwa kerangka kerja mana yang sebaiknya memicu webhook?
• Apakah ini berfungsi dengan agen headless di CI?
• Bagaimana dengan MCP elicitation secara khusus?
• Amankah menaruh keluaran agen di dalam notifikasi?
• Bisakah seluruh tim saya menerima peringatan agen yang sama?
• Apakah ini hanya untuk iOS?
• Apa bedanya dengan penyiapan WebhookMCP?
• Terkait

Setiap kerangka kerja agen otonom yang dirilis pada 2026 punya lubang yang sama. Agen berjalan berjam-jam tanpa Anda, sampai pada sebuah aksi yang tidak boleh ia ambil sendiri, lalu berhenti — dan setelah itu tidak terjadi apa-apa. Run-nya tidak gagal. Tidak mencoba ulang. Ia diam di memori sambil memegang objek state terserialisasi, menunggu manusia yang sama sekali tidak tahu bahwa ia sedang ditunggu. Panduan ini menunjukkan cara menutup celah itu dengan mengubah momen "saya butuh manusia" dari sebuah agen menjadi panggilan telepon yang berdering lewat Echobell.

Celah itu bersifat struktural, bukan bug di satu produk tertentu. Dokumentasi agen OpenAI menjelaskan alur persetujuannya dengan gamblang: ketika sebuah tool butuh persetujuan, "run berhenti sampai Anda menyetujui atau menolaknya", hasilnya mengembalikan interruptions beserta state yang bisa dilanjutkan, dan bila peninjauannya mungkin memakan waktu, Anda diminta menyerialisasi state itu, menyimpannya, lalu melanjutkan nanti (OpenAI, panduan Agents SDK). Tidak ada satu bagian pun dari alur itu yang sampai ke manusia. Memberi tahu si pemberi persetujuan sepenuhnya diserahkan kepada Anda.

Sementara itu, run-nya makin panjang. AWS menggambarkan agen frontier-nya mampu "beroperasi berjam-jam atau berhari-hari tanpa memerlukan intervensi" (About Amazon). Kiro Crew, yang diluncurkan 4 Agustus 2026, mengatakannya terang-terangan: "Mulai sebuah migrasi dan ia terus bergerak melewati checkpoint dan percobaan ulang selagi Anda sedang rapat atau tidur" — sembari mencatat bahwa "permintaan tool bisa memerlukan persetujuan" (Kiro). Kedua paruh itu benar sekaligus. Agen bekerja selagi Anda tidur, dan agen berhenti selagi Anda tidur.

Seberapa sering sebenarnya insiden agen terjadi?

Cukup sering sehingga kebanyakan perusahaan pernah mengalaminya, dan kebanyakan tidak menjalankan agen tanpa pengawasan. Dalam survei terhadap 418 profesional TI dan keamanan yang dilakukan pada Januari 2026 oleh Cloud Security Alliance atas pesanan Token Security, 65% organisasi melaporkan setidaknya satu insiden terkait agen AI dalam setahun terakhir — 61% menyangkut kebocoran data, 43% gangguan operasional, dan 35% kerugian finansial (siaran pers CSA, laporan).

Angka tata kelola dari survei yang sama itulah yang paling relevan bagi sistem peringatan. Hanya 13% yang menjalankan agen sepenuhnya otonom. Sebanyak 53% membiarkan agen bertindak otonom pada tugas berisiko rendah dengan tinjauan manusia untuk aksi berisiko lebih tinggi, dan 24% mempertahankan manusia dalam alurnya untuk sebagian besar tugas. Sebanyak 82% menemukan agen AI bayangan di lingkungan mereka dalam setahun terakhir.

Bacalah itu sebagai fakta operasional, bukan statistik penakut: sekitar tiga perempat organisasi sengaja membangun jeda ke dalam agen mereka. Setiap jeda itu adalah momen ketika sebuah mesin terhambat oleh manusia. Jika manusianya baru tahu pukul 09.00 keesokan paginya, kemampuan agen bekerja semalaman jadi tidak ada artinya.

Apa yang sebenarnya terjadi ketika agen butuh manusia?

Ia menunggu, tanpa suara, dan setiap kerangka kerja menyerahkan urusan notifikasi kepada Anda. Mekanismenya berbeda-beda; hasil akhirnya tidak.

Model Context Protocol menyatakan hal ini secara eksplisit di tingkat spesifikasi. Elicitation ada justru agar sebuah server bisa menanyakan sesuatu kepada manusia di tengah run, dan revisi terkini (2026-07-28) mengingatkan bahwa server "SHOULD NOT assume that elicitation requests will always succeed" dan harus menangani decline, cancel, serta kegagalan klien (spesifikasi MCP). Protokolnya membakukan pertanyaannya. Ia tidak, dan tidak bisa, membakukan cara merebut perhatian manusia.

Di situlah seluruh peluangnya. Setiap lapisan tumpukan agen punya mekanisme jeda yang dirancang baik. Tidak satu pun punya nomor telepon.

Peristiwa agen mana yang layak ditelepon?

Dua, dan Anda harus tegas soal sisanya. Panggilan telepon adalah sumber daya langka; belanjakan hanya di tempat manusia yang tidur benar-benar menjadi penghambatnya.

1. Persetujuan yang terhambat pada run yang tidak bisa lanjut tanpanya. Agennya menganggur, waktunya terus berjalan, dan menunggu berapa lama pun tidak menyelesaikannya. Inilah kasus kanoniknya.
2. Kegagalan terminal pada run panjang tanpa pengawasan. Migrasi enam jam yang mati di jam kedua adalah enam jam yang tidak akan kembali, dan Anda lebih baik tahu di jam kedua.

Sisanya layak masuk saluran yang lebih tenang. "Tugas berhasil diselesaikan" adalah push biasa. "Agen memakai 80% anggarannya" paling banter peka waktu. "Agen mulai berjalan" bukan notifikasi sama sekali. Tiga jenis notifikasi Echobell — Normal, Peka Waktu, dan Panggilan — ada persis untuk triase seperti ini, dan memetakan peristiwa agen ke dalamnya adalah keputusan desain paling penting di sini. Jika Anda sudah kewalahan dengan volume notifikasi, bacalah cara mengatasi kelelahan peringatan sebelum menambah saluran yang berdering.

Cara menyambungkan gerbang persetujuan agen ke panggilan telepon

Echobell mengubah webhook atau email menjadi panggilan telepon — panggilan sungguhan yang berdering dan bergetar, menembus Mode Fokus iOS dan Do Not Disturb seperti panggilan dari anggota keluarga (lihat menembus Mode Fokus iOS). Ia berada di antara agen yang berhenti dan manusia yang bisa menjalankannya lagi.

Langkah 1 — Buat saluran Panggilan untuk agen yang terhambat

Buat sebuah saluran di aplikasi lalu setel jenis notifikasinya ke Panggilan. Beri nama yang tidak ambigu seperti "Agen terhambat — butuh persetujuan" dan jangan pakai untuk hal lain. Salin URL webhook dari detail saluran; bentuknya seperti https://hook.echobell.one/t/<channel-token>. Perlakukan sebagai rahasia — siapa pun yang memegangnya bisa membuat ponsel Anda berdering (panduan webhook).

Setel templat judul dan isinya ke sesuatu yang bisa langsung Anda tindaklanjuti dari layar kunci:

Title: Agent blocked: {{agent}}
Body: Waiting on {{action}} in {{project}} — since {{time}} UTC

{{time}} dan variabel waktu sistem lainnya selalu tersedia dalam UTC tanpa perlu Anda kirimkan.

Langkah 2 — Kirim webhook dari cabang persetujuan Anda

Pada SDK mana pun yang mengembalikan interupsi, jeda itu hanyalah cabang biasa di kode Anda. Kirim POST ke URL saluran sebelum Anda memarkir run-nya:

let result = await run(agent, input, { stream: false });

if (result.interruptions?.length) {
  await fetch(process.env.ECHOBELL_BLOCKED_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      agent: agent.name,
      action: result.interruptions[0].rawItem.name,
      project: process.env.PROJECT_NAME,
      externalLink: `https://ops.example.com/runs/${runId}`,
    }),
  });
  await saveState(runId, result.state); // serialisasi dan lanjutkan setelah disetujui
}

Variabel khusus externalLink menjadi tautan yang bisa diklik di catatan notifikasi, sehingga siapa pun yang menjawab panggilan langsung mendarat di run tersebut alih-alih harus mencarinya.

Langkah 3 — Pakai hook ketika agennya berupa CLI, bukan pustaka

Claude Code menyediakan hook Notification yang matcher-nya menyaring berdasarkan jenis notifikasi, termasuk agent_needs_input dan agent_completed, dan penangan hook bisa berupa perintah shell atau POST HTTP langsung (referensi hook). Penangan command memberi Anda kendali atas bentuk payload, dan itu penting karena Echobell merender kunci JSON apa pun yang Anda kirim:

{
  "hooks": {
    "Notification": [
      {
        "matcher": "agent_needs_input",
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{agent: \"claude-code\", action: .message, project: .cwd}' | curl -sS -X POST -H 'Content-Type: application/json' -d @- \"$ECHOBELL_BLOCKED_URL\""
          }
        ]
      }
    ]
  }
}

Masukan hook datang sebagai JSON lewat stdin untuk penangan command, membawa bidang seperti session_id, cwd, hook_event_name, dan permission_mode. Jenis penangan http mengirim JSON yang sama itu langsung ke sebuah URL tanpa skrip sama sekali, dan itu menggiurkan — tetapi ia juga mengharapkan responsnya berupa dokumen keluaran hook, sedangkan respons Echobell bukan itu. Gunakan command kecuali Anda sudah memastikan http berperilaku seperti yang Anda inginkan di penyiapan Anda.

Langkah 4 — Tangkap agen yang hanya mengirim email

Banyak platform agen, layanan run terjadwal, dan alat internal hanya melapor lewat email. Setiap saluran Echobell bisa punya alamatnya sendiri, jadi satu aturan penerusan mengubah pesan-pesan itu menjadi panggilan (pemicu email, penyiapan email ke panggilan). Pemicu email menyediakan from, to, subject, text, dan html sebagai variabel templat, sehingga Anda bisa membuat kondisi berdasarkan baris subjek tanpa perlu mengurai apa pun sendiri.

Langkah 5 — Tambahkan kondisi agar hanya hambatan nyata yang berdering

Saluran yang berdering pada setiap peristiwa agen berhenti menjadi panggilan telepon dan berubah jadi kebisingan latar. Kondisi Echobell menyaring berdasarkan nilai variabel dengan sintaks ekspresi yang sama seperti templat, sehingga Anda bisa mensyaratkan, misalnya:

blocking == true && risk == "high"

Kirim semua yang di bawah ambang itu ke saluran Peka Waktu yang terpisah. Target yang berguna: saluran Panggilan sebaiknya berdering paling banyak beberapa kali seminggu. Kalau lebih sering, batas otonomi agen Anda ditarik di tempat yang salah dan tidak ada pengaturan notifikasi yang bisa memperbaikinya.

Langkah 6 — Ujilah dengan Do Not Disturb aktif

Picu salurannya dengan curl selagi Do Not Disturb aktif di ponsel yang benar-benar akan menerimanya:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{"agent":"test","action":"deploy to prod","project":"demo","blocking":true,"risk":"high"}'

Aktifkan Coba Ulang Panggilan Gagal di aplikasi agar panggilan yang terhalang Mode Fokus dicoba lagi. Jalur eskalasi yang tidak diuji hanyalah asumsi.

Bukankah ini cuma menciptakan ulang kelelahan peringatan dengan lonceng yang lebih keras?

Memang, kalau Anda melewatkan langkah 5. Mode kegagalannya nyata dan layak disebut. Agen menghasilkan jauh lebih banyak peristiwa dibanding server — setiap pemanggilan tool, setiap checkpoint, setiap percobaan ulang — dan godaan untuk mengalirkan semuanya ke tempat yang terlihat itu besar.

Disiplin yang berhasil: panggilan telepon disisakan untuk peristiwa ketika manusia yang tidur adalah satu-satunya penghalang antara agen dan kemajuan. Itu himpunan yang jauh lebih kecil daripada "hal-hal penting yang dilakukan agen". Jika Anda tidak bisa menjelaskan, dalam satu kalimat, apa yang akan dilakukan orang itu dalam sembilan puluh detik setelah menjawab, peristiwanya tidak layak ditelepon.

Ada juga argumen keamanan untuk menjaga ambangnya tetap tinggi. Survei CSA yang sama menemukan bahwa organisasi menempatkan risiko aksi (63%) dan otorisasi manusia (53%) sebagai sinyal tata kelola utama mereka. Sinyal-sinyal itu baru berarti kalau otorisasi manusianya benar-benar terjadi dengan cepat. Gerbang persetujuan yang rutin dijawab delapan jam terlambat melatih semua orang untuk melebarkan gerbangnya — dan begitulah 13% yang sepenuhnya otonom diam-diam menjadi standar karena alasan yang keliru.

Yang tidak dilakukan Echobell

Bersikap cermat di sini penting, karena infrastruktur agen mengundang klaim berlebihan.

Echobell melakukan: mengubah webhook atau email menjadi panggilan yang berdering, peringatan peka waktu, atau push biasa; menyaring dengan kondisi; menampilkan konteks lewat templat; mengirim pemicu yang sama ke saluran tim bersama tempat setiap pelanggan memilih tingkat urgensinya sendiri.

Echobell tidak:

• Menyetujui apa pun. Ia bukan antarmuka persetujuan dan tidak punya kaitan dengan state agen Anda. Ia membuat ponsel Anda berdering; Anda tetap harus membuka laptop, dasbor, atau terminal untuk menyetujui atau menolak. Tidak ada "tekan 1 untuk menyetujui".
• Melanjutkan run-nya. Menyerialisasi dan memulihkan state agen adalah tugas kerangka kerja Anda. Echobell tidak pernah menyentuhnya.
• Menyediakan kebijakan eskalasi, pengakuan, atau rotasi on-call. Tidak ada "kalau tidak ada yang menjawab dalam lima menit, telepon orang berikutnya". Ia menelepon para pelanggan sebuah saluran. Jika Anda butuh rotasi terjadwal dan pelacakan pengakuan, Anda butuh platform insiden — lihat perbandingan alternatif Opsgenie untuk kelas alat tersebut.
• Mengamankan agen Anda. Tidak ada satu pun di sini yang menjawab soal agen bayangan, izin tool yang terlalu luas, atau celah penonaktifan yang dijelaskan laporan CSA. Perhatian manusia yang lebih cepat adalah mitigasi untuk respons yang lambat, bukan untuk arsitektur yang buruk.
• Menjamin pengiriman. Sebuah panggilan bergantung pada infrastruktur push, jaringan, dan ponsel yang terisi daya. Perlakukan ia sebagai lapisan yang memperpendek waktu tunggu, bukan sebagai kontrol yang bisa Anda andalkan mutlak.

Kerangka yang jujur: batas otonomi agen Anda tidak berubah karena aplikasi mana yang membuat ponsel Anda berdering. Yang diubah sebuah panggilan adalah jumlah jam antara agen berhenti dan manusia menyadarinya — dan pada run semalaman, jam-jam itulah seluruh nilai dari menjalankannya semalaman.

FAQ

Bisakah saya menyetujui aksi agen langsung dari panggilan teleponnya?

Tidak. Echobell mengirim panggilan berisi konten notifikasi dan tautan yang bisa diklik; ia tidak punya jalur respons interaktif kembali ke agen Anda. Pola yang realistis: panggilannya membangunkan Anda, externalLink membawa Anda ke dasbor run atau endpoint persetujuan, dan Anda memutuskan di sana. Jika Anda butuh persetujuan lewat balasan, Anda harus membangun endpoint itu sendiri — Echobell hanya menangani paruh membangunkannya.

Peristiwa kerangka kerja mana yang sebaiknya memicu webhook?

Yang membuat run tidak bisa lanjut. Di OpenAI Agents SDK, itu berarti array interruptions yang tidak kosong. Di MCP, permintaan elicitation/create yang tidak bisa dijawab klien Anda tanpa manusia. Di Claude Code, hook Notification dengan matcher agent_needs_input. Peristiwa penyelesaian layak masuk saluran Normal atau Peka Waktu, bukan saluran Panggilan.

Apakah ini berfungsi dengan agen headless di CI?

Ya, dan justru di situlah paling penting, karena tidak ada yang mengawasi terminal. Langkah CI apa pun yang bisa menjalankan curl bisa memicu sebuah saluran. Kirimlah pada cabang kegagalan dari job yang panjang, bukan pada setiap job, kalau tidak pipeline Anda akan menjadi hal paling berisik yang Anda punya.

Bagaimana dengan MCP elicitation secara khusus?

Elicitation dirancang untuk klien yang penggunanya hadir untuk melihat prompt. Pada run tanpa pengawasan, tidak ada orang untuk melihatnya, dan spesifikasinya secara eksplisit meminta server menangani decline dan cancel alih-alih mengasumsikan ada respons. Pola yang masuk akal: pembungkus klien MCP memicu webhook Echobell ketika menerima permintaan elicitation yang tidak bisa ia jawab secara otonom, lalu menahan atau membatalkannya sesuai kebijakan Anda sendiri.

Amankah menaruh keluaran agen di dalam notifikasi?

Kirim sesedikit mungkin. Utamakan sebuah pengenal dan tautan ketimbang keluaran asli agennya — pakai externalLink untuk menunjuk ke catatan run di sistem yang memang dibangun untuk menyimpannya. Echobell menyimpan isi dan riwayat notifikasi hanya di perangkat Anda, dengan hanya akun, saluran, dan langganan di server (model privasi); itu bagus untuk minimalisasi data, tetapi bukan alasan untuk mengirim lebih banyak dari yang Anda butuhkan.

Bisakah seluruh tim saya menerima peringatan agen yang sama?

Bisa. Bagikan salurannya dan setiap pelanggan menerima pemicunya, masing-masing memilih jenis notifikasinya sendiri. Penyiapan yang lazim: insinyur yang memiliki agen tersebut berlangganan sebagai Panggilan, sisa tim sebagai Peka Waktu.

Apakah ini hanya untuk iOS?

Tidak. Echobell berjalan di iOS dan di Android lewat Google Play (lihat rilis Android-nya). Perilaku peringatan bergaya panggilan berbeda antarplatform, jadi ujilah di perangkat yang benar-benar dibawa orang-orang yang sedang on-call.

Apa bedanya dengan penyiapan WebhookMCP?

WebhookMCP memberi model sebuah tool yang bisa ia pilih untuk dipanggil saat sebuah tugas selesai — berguna, tetapi bergantung pada keputusan agen untuk memberi tahu Anda. Pendekatan di sini terpicu dari kode Anda sendiri atau dari hook kerangka kerja, sehingga tetap bekerja bahkan ketika agennya macet, bingung, atau sudah crash. Pakai keduanya: satu untuk "selesai", satu untuk "terhambat".

---

Terkait

• Dapatkan notifikasi saat tugas AI selesai dengan WebhookMCP
• Cara menembus Mode Fokus iOS untuk peringatan kritis
• Mengatasi kelelahan peringatan: panduan untuk developer
• Peringatan kegagalan cron job
• Panduan integrasi webhook
• Panduan kondisi