Ketika Keahlian Satu Orang Harus Tetap Tinggal di Tim

Studi Kasus Membangun Agent untuk Peran Learning Developer di Perusahaan A

Series 5 dari 5, Level Intermediate (L3), Membangun Agent Sendiri

Pendahuluan

Di banyak organisasi, cara kerja terbaik sering melekat pada satu orang: ia tahu standar mutu, tahu pertanyaan yang harus diajukan, dan tahu jebakan yang biasa muncul. Ketika orang itu pindah, pengetahuan tersebut ikut pergi. Agent AI menawarkan cara untuk menyimpan sebagian pengetahuan itu, tetapi hanya bila dirancang dengan disiplin. Kasus ini mengikuti seorang Learning Developer yang membangun agent untuk perannya sebelum pindah unit.

Latar Belakang Kasus

Perusahaan A sedang menjalankan program pembelajaran personal dengan target ribuan konten dalam berbagai format. Tokoh utama kasus ini adalah seorang Learning Developer senior. Ia menjadi rujukan tim untuk memetakan permintaan ke kompetensi dan level, mereview hasil vendor, dan menyusun dokumen pengadaan. Tim learning development dan para manager, sekitar sepuluh sampai lima belas orang, terbiasa bertanya kepadanya.

Pemangku kepentingan utamanya ada tiga. Atasan langsung ingin target program tetap tercapai. Anggota tim, termasuk beberapa intern, ingin tetap punya tempat bertanya. Vendor ingin umpan balik yang konsisten supaya tidak bolak-balik revisi. Learning Developer itu sendiri punya motivasi sederhana: ia tidak ingin tim kembali ke cara lama setelah ia pergi, tetapi ia juga tidak ingin membuat sesuatu yang hanya bisa dipelihara olehnya.

Pemicunya adalah kabar mutasi. Learning Developer itu akan pindah unit dalam beberapa minggu, sementara program masih berjalan dan beberapa project paralel belum selesai. Atasannya meminta satu hal: tim harus tetap bisa bekerja dengan standar yang sama setelah ia pergi.

Masalah yang Dihadapi

Gejalanya terlihat jelas. Hasil review berbeda-beda tergantung siapa yang mereview, soal vendor sering tidak sesuai level, dan tim ragu mengambil keputusan tanpa validasi darinya. Setelah ditelusuri, akar masalahnya bukan kurangnya dokumen. Panduan modul dan direktori kompetensi sudah ada. Yang tidak tertulis adalah cara menimbang: kapan bertanya dulu, kapan maju dengan asumsi, dan temuan mana yang wajib diperbaiki.

Masalah turunannya muncul ketika ia pertama kali mencoba memakai AI. Asisten tanpa briefing cenderung selalu setuju, menebak level kompetensi teknis dari band jabatan, dan kadang menulis referensi yang tidak bisa diverifikasi. Hasilnya terlihat rapi tetapi tidak bisa dipercaya.

Batasan dan Kendala

Ruang geraknya terbatas. Waktunya hanya beberapa minggu, di sela pekerjaan rutin. Ia bukan pengembang perangkat lunak, sehingga tidak bisa membangun aplikasi sendiri. Agent tidak boleh mengakses portal kebijakan perusahaan, jadi kebijakan yang dibutuhkan harus ditempelkan oleh pengguna. Data kompetensi bersifat internal dan tidak boleh keluar dari lingkungan perusahaan. Selain itu, platform otomasi akhirnya belum diputuskan, sehingga ia tidak bisa mengikat desain pada satu sistem.

Batasan itu memaksa beberapa kompromi. Ia memilih tidak mengotomasi seluruh alur sekaligus; setiap skill dijalankan manual dengan review manusia di antaranya. Ia juga menerima bahwa beberapa hal tetap terbuka, misalnya siapa yang akan memelihara agent setelah ia pergi.

Ada juga kompromi pada asesmen. Pada salah satu program, desain idealnya meminta peserta merekam penjelasan ulang yang dinilai dengan rubrik. Platform hanya mendukung pilihan ganda, dan penilaian di luar platform terlalu mahal untuk lebih dari empat ribu peserta. Pengalaman itu membuatnya menetapkan kebiasaan baru di briefing: selalu usulkan bentuk ideal dulu, lalu siapkan versi yang sesuai kemampuan platform, dan hitung biaya per peserta untuk populasi besar.

Penyelesaian

Langkah Pertama: Wawancara dan Briefing

Ia meminta asisten mewawancarainya: tanggung jawab, konteks kerja, pain point, gaya komunikasi, dan hal yang tidak boleh dilakukan. Hasilnya ditulis menjadi briefing dengan bagian tetap: peran, konteks, tujuan, sikap asisten, standar review per format, pengetahuan inti, aset, batasan, dan pertanyaan terbuka. Ia memilih briefing sebagai langkah pertama karena sikap dan konteks berlaku untuk semua pekerjaan, sedangkan skill hanya untuk satu jenis keluaran.

Ia sempat mempertimbangkan alternatif lain: langsung membuat skill produksi tanpa briefing, karena hasilnya lebih cepat terlihat. Alternatif itu ditolak setelah percobaan awal menunjukkan bahwa skill tanpa briefing tetap menebak hal-hal yang seharusnya ditanyakan. Ia juga menulis aturan gaya yang terlihat sepele tetapi penting bagi identitas tim, seperti bahasa yang sederhana dan larangan memakai tanda pisah panjang.

Langkah Kedua: Uji dengan Kasus Nyata

Ia menguji agent dengan tiga kasus: roadmap pengembangan untuk satu role teknis, desain awal program talenta AI, dan review modul vendor. Di setiap kasus ia mencatat di mana jawaban agent melenceng. Agent sempat langsung membuat draf desain tanpa riset, dan melewatkan ketidaksesuaian jalur karier pada role teknis. Koreksi itu ditulis sebagai pola keputusan di briefing, lengkap dengan alasannya.

Ia juga meminta penilaian jujur dari dirinya sendiri sebagai pemilik peran. Pada kasus roadmap, ia menilai jawaban agent relatif sesuai. Pada kasus review modul, agent justru menemukan kesalahan isi yang ia lewatkan, seperti definisi metrik yang keliru dan rumus yang terbalik. Temuan itu mengubah desain: agent wajib mengecek kebenaran isi, bukan hanya aspek format, dan menandai temuan yang belum pasti sebagai perlu konfirmasi SME.

Langkah Ketiga: Mengubah Prosedur Berulang Menjadi Skill

Pekerjaan yang dilakukan berulang dengan cara yang sama, seperti course design, modul, dan soal, dijadikan skill: instruksi langkah demi langkah, template, dan contoh hasil terbaik. Bahan acuan seperti direktori kompetensi dibundel sebagai data, sehingga agent mengambil kode dan key behaviour dari sumber, bukan dari ingatan.

Ia sengaja tidak membuat semua skill sekaligus. Urutannya mengikuti alur produksi: course design lebih dulu, lalu modul, lalu aset turunan. Setiap skill diuji dengan satu contoh nyata dan dibandingkan dengan hasil terbaik buatan manusia sebelum skill berikutnya dibuat. Untuk tiap skill, ia juga menyiapkan paket portabel dan instruksi siap tempel bagi rekan yang memakai platform AI lain.

Langkah Keempat: Memindahkan Aturan ke Validator

Ia menyadari bahwa instruksi tertulis mudah dilanggar. Aturan yang bisa dihitung, seperti jumlah topik, panjang opsi soal, sebaran kunci, dan usia referensi, dipindahkan ke skrip pemeriksa yang menolak output yang salah. Pemicunya sebuah batch soal yang opsi benarnya hampir selalu paling panjang, sehingga jawaban mudah ditebak dan perbaikannya butuh beberapa putaran.

Pertimbangannya sederhana: setiap aturan ditanya apakah bisa diperiksa mesin tanpa penilaian manusia. Bila bisa, aturan itu masuk validator. Bila membutuhkan penilaian, seperti apakah sebuah contoh relevan dengan peserta, aturan itu tetap di instruksi dan menjadi tugas reviewer. Pembagian ini membuat review manusia lebih fokus pada hal yang memang membutuhkan manusia.

Tabel 1. Matriks keputusan penempatan aturan (ilustratif)

Hasil dan Pembelajaran

Dalam beberapa minggu, tim punya briefing dan sembilan skill yang bisa dipasang sendiri. Review mulai memakai format yang sama, dan soal diperiksa terhadap standar per level yang sebelumnya belum disepakati. Namun hasilnya belum lengkap: skill audio dan orkestrasi otomatis belum ada, model konten baru mencakup tiga level pertama, sebagian instruksi masih menunjuk folder pribadi pembuatnya, dan PIC pemelihara belum ditetapkan. Semua angka dan rentang waktu dalam kasus ini ilustratif.

Kendala yang tersisa justru bersifat organisasi, bukan teknis. Dashboard tracking membutuhkan pendaftaran email anggota tim. Folder kerja masih berada di penyimpanan pribadi. Keputusan platform otomasi belum diambil. Learning Developer itu mencatat semua hal tersebut di bagian pertanyaan terbuka briefing, supaya penerusnya tahu persis apa yang belum selesai.

Pengguna awal memberi masukan yang beragam. Sebagian anggota tim merasa terbantu karena agent bertanya hal yang biasa ditanyakan senior. Sebagian lain merasa langkah persetujuan memperlambat pekerjaan. Learning Developer itu mempertahankan titik persetujuan pada tahap yang mahal diulang, tetapi melonggarkan riset untuk level rendah demi efisiensi, dengan dokumen riset tetap disimpan untuk audit.

Pembelajaran Utama

• Mulai dari briefing, karena sikap dan konteks berlaku untuk semua pekerjaan.
• Uji dengan kasus nyata, lalu tulis koreksinya sebagai pola keputusan beserta alasannya.
• Jadikan skill hanya untuk prosedur yang berulang, dan sertakan contoh hasil terbaik.
• Pindahkan aturan yang bisa dihitung ke validator, karena instruksi saja mudah dilanggar.
• Tetapkan pemilik dan buat jalur folder yang umum sejak awal, supaya agent tetap terpelihara setelah pembuatnya pergi.

Kasus ini menunjukkan bahwa membangun agent bukan soal teknologi yang canggih, melainkan soal menuliskan cara menimbang yang selama ini tidak tertulis. Tantangan terbesarnya justru terjadi setelah agent jadi: siapa yang menjaganya tetap relevan ketika standar dan orang di tim berubah.

Daftar Pustaka

Telkom Corporate University (2026) CLAUDE.md: Briefing Asisten Learning Development. Dokumen internal, School of Go To Market (SoGTM).