UX Persetujuan Agen AI di Ponsel: Keyakinan, Alasan, dan Kontrol Pengguna

Tentukan momen keputusan sebelum ponsel berubah

UX persetujuan agen AI yang baik dimulai dengan satu pertanyaan: kapan niat pengguna berubah menjadi tindakan nyata? Agen dapat mencari informasi, menyusun pilihan, atau membuat draf tanpa langsung mengubah keadaan ponsel. Persetujuan menjadi penting saat langkah berikutnya akan mengirim pesan, menyimpan acara, menghapus berkas, mengubah pengaturan, atau memengaruhi pihak lain.

Momen keputusan harus ditempatkan sedekat mungkin dengan tindakan tersebut. Jika persetujuan diminta terlalu awal, pengguna belum melihat hasil yang akan diterapkan. Jika muncul setelah perubahan, persetujuan kehilangan fungsinya sebagai kendali. Pada layar ponsel, urutan yang lebih jelas adalah: agen memahami permintaan, menyiapkan hasil, menampilkan target dan konsekuensi, lalu menunggu keputusan pengguna.

Bayangkan permintaan: “beri tahu Rina bahwa saya terlambat lima belas menit”. Agen dapat mencari kontak dan menyusun teks terlebih dahulu. Tepat sebelum pengiriman, layar persetujuan menampilkan nama atau nomor penerima, aplikasi yang digunakan, isi pesan, dan tombol untuk mengirim, merevisi, atau membatalkan. Pengguna tidak perlu menyetujui proses pencarian kontak secara terpisah kecuali akses tersebut memang memerlukan izin Android.

Tampilan status juga harus membedakan pekerjaan yang sedang berlangsung dari keputusan yang menunggu pengguna. Berdasarkan informasi terbaru yang tersedia sejauh ini, FoneClaw memperjelas keadaan tugas berjalan dan menunggu. Ketika sebuah tugas menunggu persetujuan, pengguna dapat melihat alasan jeda tersebut tanpa mengira agen masih memproses atau sudah menyelesaikan tindakan.

Persetujuan merupakan salah satu bagian dari tata kelola tindakan. Identitas, izin alat, dan catatan hasil tetap diperlukan agar keputusan dapat ditelusuri. Pembahasan lebih mendalam tersedia di Identitas Agen AI: Izin, Persetujuan per Alat, dan Jejak Audit Phone Agent.

Bedakan saran, pratinjau, dan penerapan

Antarmuka perlu menjelaskan apakah agen baru memberi saran, sudah menyiapkan perubahan, atau telah menerapkannya. Tiga keadaan ini tidak boleh hanya dibedakan melalui warna atau ikon kecil. Gunakan label dan kata kerja yang langsung menunjukkan hasil: “Saran”, “Siap ditinjau”, “Terapkan”, dan “Selesai”.

Saran berisi pilihan yang belum mengubah apa pun. Pratinjau menunjukkan bentuk akhir perubahan, misalnya isi pesan atau nilai pengaturan. Penerapan menjalankan tindakan setelah syaratnya terpenuhi. Pemisahan tersebut membantu pengguna mengetahui apakah menutup layar akan membuang draf, meninggalkan tugas menunggu, atau membatalkan perubahan.

Pola publik GitHub memberikan contoh yang relevan dari ranah berbeda. Dalam pengumuman GitHub tentang kontrol otomatisasi Issues pada 23 Juli 2026, tindakan Issues tertentu dapat disarankan untuk ditinjau sebelum diterapkan. Fitur tersebut masih berstatus pratinjau publik dan berlaku pada tindakan Issues yang didukung, bukan tindakan ponsel. Pelajaran antarmukanya adalah bahwa pengguna perlu melihat perbedaan antara usulan yang menunggu dan perubahan yang sudah berlaku.

Pada ponsel, tombol utama harus mengikuti keadaan. Draf pesan memakai “Tinjau pesan”, bukan langsung “Kirim”. Usulan perubahan pengaturan memakai “Lihat perubahan”. Setelah target dan konsekuensi ditampilkan, tombol dapat berubah menjadi tindakan yang spesifik, seperti “Kirim ke Rina” atau “Matikan Wi-Fi”.

Jika tindakan diterapkan tanpa layar persetujuan berdasarkan kebijakan yang sudah dipilih pengguna, hasilnya tetap perlu terlihat. Catatan singkat seperti “Pengingat dibuat untuk pukul 15.00” memberi kepastian dan menyediakan pintu menuju pembatalan atau penyuntingan bila tersedia.

Gunakan tingkat keyakinan untuk mengatur peninjauan

Tingkat keyakinan dapat membantu mengarahkan perhatian pengguna, tetapi bukan ukuran kebenaran yang mutlak. Nilai tinggi berarti sistem menemukan lebih sedikit ambiguitas menurut kriteria yang digunakan. Kesalahan masih mungkin terjadi karena konteks tidak lengkap, data lama, nama yang serupa, atau akibat tindakan yang sulit diperkirakan.

GitHub memakai pola keyakinan tinggi, sedang, dan rendah pada tindakan Issues yang didukung dalam pratinjau publiknya. Tindakan dengan keyakinan tinggi dapat diterapkan otomatis sesuai pengaturan otomatisasi, sedangkan tindakan dengan keyakinan sedang atau rendah ditahan sebagai saran. Pola ini menunjukkan cara mengarahkan beban peninjauan, tetapi setiap produk perlu menyesuaikannya dengan jenis tindakan dan dampaknya.

Di ponsel, dampak harus ikut menentukan jalur. Membuka aplikasi yang jelas mungkin dapat diteruskan dengan sedikit gangguan. Mengirim pesan, menghapus berkas, atau mengubah pengaturan penting memerlukan pemeriksaan yang lebih kuat meskipun target tampak meyakinkan. Keyakinan membantu menentukan perhatian yang dibutuhkan; dampak menentukan tingkat kendali yang tepat.

Hindari menampilkan angka keyakinan tanpa penjelasan. Label “Target perlu dikonfirmasi” lebih berguna daripada angka 63 persen jika pengguna tidak mengetahui penyebabnya. Antarmuka harus menyebutkan bagian yang belum pasti dan tindakan yang dapat dilakukan untuk memperbaikinya.

Tampilkan alasan, target, konsekuensi, dan bukti

Sebuah permintaan persetujuan harus dapat dipahami dalam beberapa detik. Pengguna perlu mengetahui mengapa agen mengusulkan tindakan, apa yang akan berubah, siapa atau apa targetnya, dan informasi apa yang mendasari keputusan tersebut. Penjelasan ringkas lebih berguna daripada uraian panjang tentang proses penalaran internal.

Gunakan struktur empat bagian. Pertama, alasan: “Anda meminta pemberitahuan keterlambatan.” Kedua, target: “Rina, nomor berakhiran 4821.” Ketiga, konsekuensi: “Pesan akan dikirim melalui aplikasi pesan.” Keempat, bukti: draf pesan dan sumber waktu yang dipakai. Pengguna kemudian dapat menyetujui, mengubah, atau menolak berdasarkan informasi yang konkret.

Pola alasan GitHub mencatat dasar untuk tindakan Issues yang didukung, baik yang diterapkan maupun yang menunggu peninjauan. Pada ponsel, gagasan serupa dapat diterjemahkan menjadi alasan singkat yang dekat dengan tombol keputusan. Ini merupakan pelajaran desain, bukan pemindahan fitur GitHub ke FoneClaw.

Alasan juga perlu menjelaskan ambiguitas. Bila agen menemukan dua kalender, layar dapat menyatakan: “Ditemukan kalender Kerja dan Proyek; pilih kalender tujuan.” Jika tanggal berasal dari frasa “Jumat sore”, tampilkan tanggal dan waktu yang ditafsirkan. Pengguna tidak perlu membaca riwayat percakapan untuk menemukan asumsi penting.

Untuk tindakan yang memakai data sensitif, tampilkan hanya konteks yang diperlukan. Nama penerima, bidang yang berubah, dan ringkasan sumber biasanya cukup. Detail tambahan dapat dibuka bila pengguna memerlukannya. Pendekatan ini menjaga layar persetujuan tetap ringkas tanpa menghilangkan dasar keputusan.

Catatan alasan tidak menggantikan izin Android atau pengamanan layanan. Persetujuan juga tidak menciptakan kewenangan yang sebelumnya tidak tersedia. Hubungan antara lingkungan terisolasi dan izin perangkat dibahas lebih lanjut dalam Sandbox AI Agent vs Izin Ponsel: Mengapa Batas Tetap Penting.

Ikat persetujuan ke tugas dan percakapan yang benar

Persetujuan harus berlaku untuk usulan yang sedang dilihat, bukan menjadi izin umum bagi tugas lain. Ikatan ini mencakup percakapan, target, isi, alat, dan keadaan saat persetujuan diberikan. Bila salah satu bagian berubah, layar perlu memperbarui pratinjau sebelum tindakan dijalankan.

Masalah mudah muncul ketika pengguna memiliki beberapa tugas. Satu percakapan mungkin menunggu persetujuan untuk mengirim pesan, sedangkan percakapan lain sedang menyiapkan acara kalender. Tombol “Setujui” yang tidak menyebut tugas dapat memicu kebingungan. Label yang lebih tepat adalah “Kirim pesan ke Rina” atau “Buat acara di Kalender Kerja”.

Kemampuan FoneClaw saat ini memperkuat persetujuan yang terikat sesi dan isolasi tugas. Kami menjaga agar keputusan pada satu percakapan tidak digunakan untuk tindakan dari percakapan lain. Status berjalan dan menunggu ditampilkan secara terpisah, sementara antrean yang ketat menjaga urutan pekerjaan tanpa menyiratkan bahwa beberapa tindakan perangkat dijalankan bersamaan.

Jika pengguna menyunting draf setelah layar persetujuan muncul, keadaan lama tidak lagi menjadi dasar yang tepat. Antarmuka perlu menampilkan versi terbaru dan meminta keputusan terhadap versi tersebut. Prinsip yang sama berlaku ketika target kontak, kalender, akun, atau lokasi berubah.

Daftar tugas menunggu sebaiknya menampilkan kata kerja, target, alasan menunggu, dan waktu dibuat. Urutan ini membantu pengguna menentukan mana yang perlu diperiksa terlebih dahulu. Tugas yang menunggu izin harus dibedakan dari tugas yang menunggu persetujuan, sebab langkah pemulihannya berbeda.

Pada ponsel, pusat kendali yang baik menyatukan status tanpa mencampur keputusan. Artikel Kontrol AI Agent di Ponsel: Saat Smartphone Menjadi Pusat Komando membahas cara melihat tugas aktif, keputusan yang tertunda, dan hasil pada satu tempat yang tetap dapat dipahami.

Terapkan pola sesuai dampak tindakan ponsel

Tidak semua tindakan ponsel membutuhkan bentuk persetujuan yang sama. Antarmuka sebaiknya menyesuaikan informasi dan pilihan dengan konsekuensinya. Tujuannya bukan menambah dialog sebanyak mungkin, melainkan memberi keputusan yang tepat pada saat pengguna mempunyai konteks yang cukup.

Pesan dan komunikasi. Tampilkan penerima, aplikasi, isi, serta lampiran sebelum pengiriman. Untuk balas ke semua, sebutkan jumlah dan identitas penerima. Pilihan revisi harus membawa pengguna kembali ke draf tanpa menghapus konteks percakapan.

Pengaturan perangkat. Nyatakan keadaan sekarang dan keadaan setelah perubahan. Tombol “Ubah ke mode senyap” lebih jelas daripada “Terapkan”. Jika perubahan dapat dikembalikan, sediakan tindakan pemulihan yang mudah ditemukan setelah hasil ditampilkan.

Berkas dan data. Bedakan memindahkan, mengganti nama, memindahkan ke sampah, dan menghapus permanen. Tampilkan nama, lokasi, jumlah berkas, serta akibat terhadap pemulihan. Untuk pilihan banyak item, berikan ringkasan dan cara membuka daftar lengkap.

Kalender dan tugas. Periksa akun, tanggal, zona waktu, peserta, pengingat, serta kemungkinan pengiriman undangan. Membuat draf acara berbeda dari menyimpan acara; menyimpan berbeda lagi dari mengirim undangan kepada peserta.

Navigasi dan lokasi. Menampilkan rute dapat berjalan sebagai hasil yang dapat diperiksa. Membagikan lokasi atau mengirim perkiraan waktu tiba menyentuh pihak lain, sehingga target dan isi perlu terlihat sebelum dibagikan. Jika tujuan memiliki beberapa cabang, minta pengguna memilih lokasi yang tepat.

Dalam FoneClaw, kami menghubungkan permintaan dengan tindakan Android yang didukung dan menjaga perubahan penting tetap dapat ditinjau. Izin muncul ketika tugas membutuhkannya, persetujuan mengikuti dampak tindakan, dan hasil akhir menunjukkan apa yang benar-benar terjadi.

Sediakan penolakan, revisi, pembatalan, dan pemulihan

Layar persetujuan belum lengkap jika hanya menawarkan tombol lanjut. Pengguna memerlukan pilihan untuk menolak, merevisi, menunda, atau mengambil alih. Setiap pilihan harus menjelaskan keadaan sesudahnya: apakah draf disimpan, tugas dibatalkan, atau agen tetap menunggu keputusan.

Tolak menghentikan tindakan yang diusulkan tanpa memengaruhi tugas lain. Revisi membuka bagian yang perlu diubah dan mempertahankan konteks yang relevan. Batalkan perubahan digunakan setelah tindakan yang dapat dipulihkan selesai. Ambil alih membawa pengguna ke aplikasi atau layar tujuan untuk menyelesaikan langkah secara manual.

Pemulihan izin memerlukan jalur tersendiri. Jika mikrofon, kalender, lokasi, atau akses lain belum tersedia, antarmuka perlu menyebutkan izin yang dibutuhkan dan alasan penggunaannya. Setelah izin diberikan, FoneClaw dapat kembali ke tugas yang sama selama target dan konteksnya masih berlaku. Penolakan izin harus menghasilkan status yang jelas, bukan pengulangan permintaan tanpa penjelasan.

Kemampuan FoneClaw saat ini memperbaiki pemulihan izin dan pemulihan pelaksanaan melalui Home. Jika perpindahan layar atau keadaan aplikasi memutus langkah yang didukung, pengguna dapat kembali ke titik yang dapat dipahami. Isolasi tugas menjaga agar pemulihan tersebut tidak mengambil konteks dari percakapan lain.

Untuk tindakan yang hasilnya belum pasti, jangan mengulang secara otomatis. Periksa keadaan aktual terlebih dahulu. Pesan mungkin sudah terkirim meskipun konfirmasi visual terlambat, atau berkas mungkin sudah berpindah saat aplikasi kehilangan fokus. Verifikasi mencegah tindakan ganda.

Daftar periksa pemulihan yang ringkas mencakup lima pertanyaan: tindakan apa yang diminta, target mana yang dipakai, perubahan apa yang sudah terjadi, keputusan apa yang masih menunggu, dan langkah apa yang dapat dilakukan sekarang? Jawaban tersebut memberi pengguna jalur maju tanpa harus memulai seluruh percakapan dari awal.

UX persetujuan agen AI yang matang membuat tindakan ponsel terasa cepat sekaligus dapat dipahami. Kami membangun FoneClaw agar pengguna dapat melihat status, meninjau perubahan yang berdampak, menjaga keputusan tetap terikat pada tugas, dan memulihkan alur ketika izin atau aplikasi menghambat langkah berikutnya.