Suara telah menjadi fitur yang dikejar-kejar oleh setiap platform agen AI untuk segera dirilis. Langkah yang tampak jelas adalah membangunnya sebagai saluran (channel) mandiri, sesuatu yang berada di samping aplikasi web, alat CLI, atau bot Telegram Anda. Hal ini terasa intuitif. Anda melihat fitur suara, lalu Anda membuat antarmuka suara. Namun, insting tersebut menciptakan arsitektur yang rapuh. Hal ini menduplikasi pekerjaan, merusak log Anda, dan perlahan-lahan mengacaukan konteks proyek Anda.

Di APC dan APX, kami memilih rute yang berbeda. Suara bukanlah sebuah saluran. Ia adalah sebuah mode. Ia berada di atas sebuah permukaan (surface) alih-alih menggantikannya. Memahami perbedaan ini dengan benar adalah kunci agar sistem tidak terpecah-pecah.

Abstraksi yang Salah

Ketika Anda memperlakukan suara sebagai saluran tersendiri, Anda secara implisit mengasumsikan bahwa berbicara dengan agen adalah percakapan yang secara fundamental berbeda dari mengetik kepadanya. Tim engineering merespons hal ini dengan memecah basis kode (codebase). Tiba-tiba ada saluran CLI dan saluran suara-CLI yang terpisah. Ada saluran web dan saluran suara-web yang sejajar. Masing-masing membutuhkan variasi prompt, aturan pemformatan, dan logika penanganan konteks tersendiri.

Di sinilah kekacauan dimulai. Penyesuaian pada perilaku agen kini harus disalin ke berbagai pohon prompt (prompt trees). Jika tim melupakan satu permukaan, pengalaman pengguna menjadi terfragmentasi. Pengguna mendapatkan nada bicara yang satu melalui teks dan kepribadian yang sedikit berbeda melalui suara. Seiring waktu, ketidakkonsistenan kecil ini menumpuk menjadi penyimpangan sistem (system drift). Lapisan konteks portabel tidak lagi menjadi portabel karena harus memperhitungkan penyampaian vokal di satu cabang dan teks senyap di cabang lainnya. Terjadi kebocoran abstraksi (abstraction leak), dan definisi proyek Anda yang dulunya bersatu kini terurai menjadi kumpulan perbaikan (hacks) khusus saluran.

Memisahkan Konteks dari Runtime

Untuk mencegah hal ini, kami membagi tanggung jawab ke dalam dua lapisan yang tetap terpisah secara ketat.

APC memegang konteks proyek. Ia mendefinisikan agen, aturan, dan keahlian (skills) yang membentuk sebuah proyek. Anggaplah ini sebagai makna stabil dari sistem tersebut. Ia menjawab pertanyaan-pertanyaan struktural. Apa yang diketahui agen ini? Apa yang diizinkan untuk ia lakukan? Alat apa yang dapat ia panggil? APC harus tetap sepenuhnya agnostik terhadap apakah sebuah balasan ditampilkan di layar, dikirim melalui API chat, atau dialirkan melalui speaker.

APX menangani lapisan runtime. Ia mengelola permukaan (surfaces) yang benar-benar Anda gunakan: CLI, aplikasi web, antarmuka desktop, bot Telegram. Ketika pengguna mengirim permintaan, APX memilih di mana dan bagaimana cara menyajikan respons tersebut. Memutuskan apakah akan memformat jawaban untuk dibaca atau mengoptimalkannya untuk diucapkan adalah urusan runtime. Hal itu milik APX, bukan APC.

Pemisahan ini berarti proyek yang didefinisikan di APC tetap utuh tidak peduli berapa banyak permukaan yang diekspos oleh APX. Kontraknya tidak berubah. Hanya lapisan presentasinya yang berubah.

Bagaimana Mode Sebenarnya Bekerja

Dalam implementasi kami, permukaan seperti Telegram, CLI, dan aplikasi web adalah saluran (channels). Sebuah saluran memberi tahu Anda di mana interaksi terjadi. Suara dilapisi melalui metadata saluran sebagai sebuah mode. Sebuah mode memberi tahu Anda bagaimana sebuah balasan harus berperilaku.

Prompt builder menghormati batasan ini. Ia mengambil data dari konteks proyek di APC, lalu memeriksa metadata saluran. Jika permukaan desktop berjalan dalam mode suara, builder akan menambahkan instruksi terarah hanya pada saat itu. Mungkin ia memberi petunjuk pada model untuk menggunakan kalimat yang lebih pendek, tanda baca yang lebih jelas untuk sintesis, atau konvensi angka lisan. Jika permukaan desktop yang sama berjalan dalam mode teks, instruksi vokal tersebut tidak akan pernah masuk ke dalam prompt.

Hasilnya adalah satu pohon prompt tunggal per permukaan. Tidak ada cabang suara-desktop yang terpisah. Tidak ada varian whisper-web. Modifikator hanya diterapkan ketika runtime memintanya, dan hanya pada saat terakhir yang memungkinkan (last responsible moment). Prompt inti tetap konstan.

Apa yang Anda Dapatkan

Arsitektur ini membuahkan hasil dalam tiga cara konkret.

Biaya pemeliharaan yang lebih rendah. Jika suara adalah saluran tersendiri, setiap permukaan akan membutuhkan kembaran. Anda akan memelihara saluran CLI dan saluran suara-CLI, saluran Telegram dan saluran suara-Telegram, dan seterusnya. Setiap kali Anda menyesuaikan prompt sistem, memperbaiki bug pemformatan, atau menyempurnakan deskripsi skill, Anda harus menyebarkan perubahan tersebut ke kedua pohon prompt. Jika terlewat satu saja, pengguna akan menyadari celahnya. Dengan menggunakan mode, Anda menjaga satu pohon prompt per permukaan. Suara menjadi lapisan (overlay) kondisional alih-alih sebuah percabangan jalan, sehingga beban kerja Anda tetap linear saat Anda menambah cara baru untuk berinteraksi.

Pencatatan log yang akurat. Saluran mencatat di mana interaksi terjadi. Mode mencatat bagaimana balasan disampaikan. Interaksi desktop tetap menjadi interaksi desktop baik pengguna membacanya atau mendengarnya. Saat tim Anda melacak bug atau meninjau analitik, mereka tidak perlu menyelaraskan "desktop-voice" dengan "desktop-text" seolah-olah keduanya adalah permukaan produk yang berbeda. Pengenal saluran tetap bersih, dan bendera mode terletak rapi di sampingnya dalam metadata. Log Anda tetap jujur, dan debugging tetap mudah karena lokasi dan perilaku tidak saling terkait.

Konteks proyek yang bersih. APC mendefinisikan kontrak. APC tidak perlu peduli apakah balasan diucapkan, dibisikkan, atau ditampilkan dalam font monospace. Itu adalah masalah runtime. Dengan menjaga pemformatan suara di dalam APX, kita menjaga portabilitas APC. Anda dapat mengambil definisi proyek APC dan memasukkannya ke dalam lingkungan runtime yang sepenuhnya baru tanpa menyeret asumsi pemformatan khusus suara atau beban tambahan optimasi bicara. Batasannya tetap terjaga, dan makna proyek tetap stabil.

Bukti pada Desktop

Jalur desktop kami sendiri mendemonstrasikan hal ini dalam penggunaan sehari-hari. Desktop adalah permukaannya. Saat pengguna mengaktifkan fitur bicara, sistem menjalankan permukaan desktop yang sama dalam mode suara. Karena suara berada di lapisan mode, saluran desktop tetap mempertahankan konteks dan perilakunya secara penuh. Ia tidak menjadi produk berbeda dengan aturan yang berbeda. Prompt builder hanya mendeteksi bendera tersebut dan menambahkan instruksi suara hanya jika diperlukan. Saat pengguna beralih kembali ke teks, instruksi tersebut hilang sepenuhnya. Konteks proyek yang mendasarinya tidak pernah berubah. Desktop tetaplah desktop.

Intisari Utamanya

Ide intinya sederhana. APC mendeskripsikan makna proyek yang stabil. APX mendeskripsikan eksekusi runtime. Suara adalah modifikator pada sebuah permukaan, bukan penggantinya. Perlakukan seperti itu, maka prompt Anda akan tetap ringkas. Log Anda akan tetap jelas. Log Anda