[🛠] AI Orchestration #4: Memangkas tugas lanjutan Telegram dari 22 menit menjadi 9 menit

✨ Ringkasan GPT-5.6 Sol

Catatan tentang deadlock mandiri dalam Session yang sama, pencarian berulang, dan verifikasi sekali pakai yang ditemukan lewat canary kerja nyata, lalu memangkas waktu pengembalian file Telegram sebesar 57,6% dengan generator, verifier, dan pengerjaan ulang parsial yang sudah ada.

Deadlock mandiri akibat canary di Session yang sama

Dalam dogfooding sehari sebelumnya, saya hanya memberikan tujuan melalui Telegram lalu menerima PDF dan XLSX. Alurnya sudah mencakup penemuan proyek, pembagian peran, eksekusi paralel, pengerjaan ulang, dan pengembalian file, tetapi membutuhkan 22 menit 6 detik. Jika setiap tindak lanjut kecil memerlukan waktu selama itu, sistem ini akan terasa lambat dalam pemakaian nyata.

Saya tidak membuat benchmark terpisah. Saya mengirim tujuan lain di Topic Telegram yang sama: “pertahankan kualitasnya, tetapi kurangi waktu 22 menit tersebut.” Saya ingin melihat apakah AI Orchestrator dapat menemukan bottleneck yang sebenarnya, memperbaiki Workflow bersama, dan menyelesaikan sendiri tugas lanjutan berbasis file.

Validasi pertama langsung mengalami deadlock. Saat masih menangani permintaan aktif, AI Orchestrator mengirim canary ke Session yang sama lalu menunggu balasannya. Permintaan baru baru bisa berjalan setelah turn saat ini selesai, sementara proses induk tidak dapat selesai karena menunggu permintaan baru tersebut.

Saya hanya menghentikan CLI yang sedang menunggu, lalu memisahkan Topic perubahan produk dari Topic canary. Ini bukan masalah model yang tidak mampu mengerjakan tugas. Masalahnya ada pada batas eksekusi: Orchestrator tidak boleh menunggu tugas berikutnya di dalam Session yang sedang ditempatinya sendiri.

Penggunaan ulang generator dan verifier untuk pengerjaan ulang parsial

Canary pertama di Topic independen mengembalikan file dalam 17 menit 35 detik. Memang lebih cepat, tetapi hasilnya salah menandai Pilot yang sudah disetujui sebagai masih menunggu persetujuan. Waktu yang lebih singkat belum cukup untuk dianggap lulus.

Dengan mengikuti eksekusi sebenarnya, saya menemukan pencarian bukti yang sama berulang kali, polling terhadap pekerjaan turunan, dan pemeriksaan dependency yang baru dilakukan setelah pembuatan artefak dimulai. Ada pula biaya besar karena membuat jalur verifikasi serupa dari awal, padahal generator dan verifier PDF serta XLSX yang tervalidasi sudah tersedia.

Saya hanya menyisakan aturan berikut di Workflow bersama:

• Tetapkan bukti yang diperlukan dalam satu snapshot yang dibatasi.
• Ambil hasil pekerjaan turunan melalui event penyelesaian, bukan polling berulang.
• Gunakan kembali generator atau verifier yang sudah ada daripada membuat implementasi baru.
• Terapkan hanya perubahan pada keputusan dan metrik terbaru, lalu kerjakan ulang hanya bagian yang cacat.
• Jalankan satu validasi akhir terhadap seluruh artefak dan selaraskan Source provenance-nya.

Saya hanya memperbaiki status persetujuan dan kalimat yang salah pada hasil pertama, kemudian mengulangi render penuh serta pemeriksaan buka-simpan independen. Alur baru tidak membangun ulang semuanya dari awal. Alur itu hanya mengubah bagian yang secara makna sudah tidak sesuai, lalu memeriksa kembali integritas seluruh hasil.

Pengembalian file Telegram dalam 9 menit 23 detik dengan batas kualitas tetap utuh

Canary pengerjaan ulang mengembalikan PDF dan XLSX melalui Telegram dalam 9 menit 23 detik tanpa intervensi pengguna. Waktunya 57,6% lebih singkat dari 22 menit 6 detik awal, sementara tool call Orchestration turun dari 56 menjadi 21.

Peningkatan ini bukan hasil dari melewati pemeriksaan. Saya memeriksa ulang render, struktur, isi, rumus, serta open/re-save independen pada PDF dua halaman dan XLSX empat sheet. File yang diunduh ulang dari Telegram juga memiliki hash yang sama dengan hasil asli. Terakhir, sistem menemukan bahwa Workflow provenance di dalam file masih menunjuk ke hash lama dan hanya memperbaiki nilai tersebut tanpa mengubah isi atau strukturnya.

Keputusan terpenting adalah tidak menganggap hasil pertama yang memakan waktu 17 menit sebagai keberhasilan. Jika keputusan terbaru salah, memangkas waktu hanya akan menghasilkan keluaran yang salah dengan lebih cepat. Perbaikan ini lulus karena waktu pengembalian nyata turun sementara Gate kualitas tetap dipertahankan.

Batas antara v0.1 pengguna tunggal dan Pilot multi-pengguna

Versi v0.1 pengguna tunggal saat ini sudah dapat menerima tujuan dalam bahasa alami, menemukan proyek, membagi pekerjaan, memverifikasi hasil, dan mengembalikannya melalui Telegram. Namun, masih terlalu dini untuk menyebutnya operasi tanpa pengawasan penuh. Dalam peran sebagai CEO, saya masih harus menghentikan deadlock mandiri di Session yang sama, menunjukkan kesalahan makna pada hasil pertama, dan meminta commit lokal yang terlewat.

Langkah berikutnya bukan benchmark baru. Saya perlu terus memberikan pekerjaan nyata yang tidak sensitif dengan batas kualitas yang sama, mengumpulkan waktu pemrosesan, lalu mengamati distribusi dan regresinya. Setelah koneksi pengguna lain disetujui, saya juga perlu memastikan dua Cell dapat berjalan bersamaan tanpa mencampur Session, Memory, atau file. Task Flow controller yang lengkap belum menjadi bottleneck kritis pada jalur pengguna saat ini, sehingga tetap menjadi jalur jangka panjang yang terpisah.