Tujuh Agen AI Bekerja untuk Kami Setiap Malam: Agen Terjadwal di Luar Coding, Lengkap dengan Prompt-nya

Pada 23 September, seorang pengguna bernama Rob menulis di backlog publik kami: “would love to get examples of how you guys are doing stuff beyond coding”. Pertanyaan yang wajar. Semua yang ada di situs ini membahas agen coding, padahal yang benar-benar kami jalankan setiap malam sebagian besar bukan coding.

Sejak 28 Agustus, tujuh agen mulai bekerja di sebuah Mac mini pukul 20.00. Mereka membaca commit hari itu, Search Console, dashboard admin, backlog, masukan yang dikirim orang, dan laporan malam sebelumnya. Mereka memperbaiki bug, mengoreksi situs web, menulis dan menerjemahkan satu artikel blog setiap tiga hari, memposting di tiga jejaring sosial, memperbarui basis pengetahuan produk, dan pukul 22.00 agen ketujuh membaca apa yang ditinggalkan enam agen lainnya lalu mengirim email 25 baris. Tidak ada yang mengawasi. Pendirinya membaca email itu di ponsel keesokan paginya.

Artikel ini adalah jawaban untuk Rob. Apa yang berjalan, bagaimana semuanya terhubung, bagaimana para agen saling menyerahkan pekerjaan tanpa pernah berbicara, model mana yang mengerjakan tugas mana dan kenapa, empat aturan yang harus dipelajari prompt mereka lewat pengalaman pahit, dan prompt-nya sendiri, diringkas menjadi blok yang bisa kamu salin. Setiap angka di bawah berasal dari repositori: laporannya di-commit di sana, malam demi malam.

Apa yang dihasilkan 33 malam

Folder laporan di repositori berisi 33 direktori bertanggal, dari 28 Agustus hingga 30 September. Membacanya menghasilkan ini:

• 31 email pagi yang dikirim oleh pelapor.
• 51 bug diperbaiki oleh agen perbaikan bug, masing-masing dengan tautan commit di baris laporannya. Beberapa di antaranya dilaporkan pengguna di backlog publik dan mendapat balasan pada rilis berikutnya.
• 7 artikel blog yang ditulis tim SEO sejak 10 September, satu setiap tiga hari, masing-masing dalam bahasa Inggris dan Prancis lebih dulu, lalu dalam 18 bahasa lain pada malam yang sama.
• 29 hari jurnal media sosial: tiga jejaring dan lima grup Facebook setiap malam, ditambah komentar terima kasih di bawah setiap postingan tempat seorang pengguna membagikan AgentsRoom.
• Basis pengetahuan produk berisi sekitar seratus lembar fakta, diselaraskan dengan commit hari itu, yang dibaca asisten di dalam aplikasi dan disajikan situs sebagai llms-full.txt.

Semua ini tidak membutuhkan manusia setelah pukul 20.00. Sebagian membutuhkan manusia pukul 08.00, dan itulah alasan adanya agen terakhir.

Susunan tim: siapa yang berjalan pukul 20.00

Setiap agen adalah sebuah Tugas Terjadwal di AgentsRoom: sebuah prompt, sebuah agen (peran, CLI, model), sebuah mesin, dan sebuah jam. Ketujuhnya menjalankan Claude Code. Dua di antaranya bukan agen tunggal melainkan tim dua langkah, dan kami akan kembali membahas alasannya.

File .md di kolom terakhir semuanya berada di reports/night/<date>/, sudah di-commit dan di-push. Folder itu adalah seluruh sistem koordinasinya, dan bagian berikutnya menjelaskan alasannya.

Bagaimana semuanya terhubung

Masing-masing dari ketujuh agen adalah sebuah Tugas Terjadwal dengan bentuk yang sama:

• Terpicu setiap hari pukul 20.00 (22.00 untuk pelapor). Tanpa ekspresi cron; frekuensinya dipilih di editor.
• Disematkan ke satu mesin. Proyeknya terbuka di beberapa komputer, dan sebuah pemicu terpicu di setiap mesin yang memilikinya kecuali kamu membatasinya. Milik kami dibatasi ke Mac mini, jadi laptop yang dibuka pukul 20.05 tidak memulai CEO kedua.
• Membangunkan mesin. Mac mini-nya tidur. Tugas ini punya opsi “bangunkan mesin”, yang menjadwalkan bangun dengan alat bawaan sistem operasi (pmset di macOS, Task Scheduler dengan wake-to-run di Windows, rtcwake di Linux) beberapa detik sebelum run. Tanpa opsi itu, mesin yang tidur begitu saja melewatkan run.
• Pengejaran aktif atau nonaktif, per tugas. Jika mesin mati pukul 20.00, tugas dengan pengejaran aktif akan terpicu saat aplikasi dibuka berikutnya. CEO, PM, dan pelapor mengaktifkannya. Tugas SEO, perbaikan bug, media sosial, dan dokumentasi menonaktifkannya: run yang dimulai pukul 11.00 keesokan paginya akan bertabrakan dengan pekerjaan siang hari di checkout yang sama.
• Mode izin diatur pada tugas, bukan pada penyedia. Run tanpa pengawasan tidak boleh berhenti di permintaan persetujuan pukul 3 pagi, jadi tugas ini berjalan tanpa persetujuan, sementara agen yang dikendalikan langsung oleh pendiri di CLI yang sama tetap bertanya dulu.
• Konsol tertutup setelah 60 menit tidak aktif. Agen yang sudah selesai tidak diam di sidebar sampai ada yang menutupnya.
• Prompt adalah pesan pertama. Teks setiap prompt disimpan di Pustaka prompt dan sama persis dengan teks di kolom prompt pemicu, jadi mengedit yang satu berarti mengedit keduanya. Prompt-nya ditulis dalam bahasa Prancis, karena pendiri membaca laporan dalam bahasa Prancis. Semua yang lain, dari pesan commit hingga basis pengetahuan, dalam bahasa Inggris.

Ada satu bagian lagi yang dipakai bersama oleh ketujuhnya: sebuah skill bernama “agen malam, aturan bersama”. Setiap prompt dimulai dengan “muat skill ini dan terapkan”, dan skill itu memuat semua hal yang berlaku untuk semuanya: siapa memegang apa, pengaman satu malam, satu run, hak git, format laporan, aturan backlog, dan format email untuk pelapor. Ketika sebuah aturan berubah, ia berubah di satu tempat.

Bagaimana mereka saling menyerahkan pekerjaan tanpa berbicara

Ketujuh agen tidak pernah saling mengirim pesan. Mereka bisa saja, AgentsRoom punya kotak pesan antar agen, tetapi sebuah pesan tidak terlihat keesokan paginya dan tidak bisa di-grep. Semuanya melewati tiga hal yang bertahan melewati malam:

Repositori. Setiap agen menulis reports/night/<date>/<agent>.md, membukanya di menit pertama run-nya, menulis ulang setelah setiap pekerjaan selesai, lalu melakukan commit dan push. Laporan punya empat bagian tetap: “Singkatnya” (daftar poin, satu poin per hal yang dikerjakan), “Perlu diputuskan” (hanya yang disisihkan prompt untuk manusia), “Perlu dicek” (URL lokal atau layar yang perlu dibuka), “Detail” (sepanjang yang diperlukan). Laporan diakhiri dengan penanda run: commit terakhir yang dilihat agen.

Backlog. Agen yang menemukan pekerjaan untuk agen lain tidak mengerjakannya sendiri. Ia membuka tiket dengan tag: ceo-fix untuk bug kecil yang sudah diverifikasi dan akan diambil agen perbaikan bug; ceo-seo untuk pekerjaan konten beserta kueri targetnya; ceo-decision untuk apa pun yang membutuhkan manusia (database, penagihan, auth, enkripsi, harga, URL yang sudah terindeks, perilaku bawaan). Penjaga dokumentasi, saat membaca commit, menemukan fitur yang belum punya halaman di situs: ia membuat tiket ceo-seo, dan SEO mengambilnya malam berikutnya. CEO, saat membaca log error, menemukan bug beserta penyebabnya di kode: ceo-fix, dan agen perbaikan bug mengambilnya malam berikutnya.

Laporan kemarin. Sebelum memulai pekerjaan apa pun, setiap agen membaca laporannya sendiri dari malam sebelumnya, ditambah daftar tiket yang ditutup selama siang hari. Apa yang ditandainya kemarin sering sudah diperbaiki selama siang. Topik yang sudah ditangani tidak diangkat lagi; tiket yang sudah terbuka tidak dibuat ulang.

Lingkarannya ditutup oleh manusia. Email pelapor diakhiri dengan satu baris: untuk menjawab product manager, tambahkan bagian “## Keputusan” di akhir rapport.md (P1 OK / P2 TIDAK: alasan / P3 NANTI), commit, push. PM membaca versi yang sudah di-push pada malam berikutnya dan menjalankan apa yang disetujui: membuat tiket, menggabungkan duplikat, memarkir sisanya beserta alasannya. Keputusan yang tidak mendapat jawaban selama tiga malam adalah sebuah keputusan: usulan itu keluar dari email dan tetap menjadi tiket.

Model mana mengerjakan tugas mana, dan kenapa

Tabel di atas menunjukkan dua model. Ini adalah konfigurasi saat ini, bukan benchmark, dan bisa berubah. Tetapi pembagiannya disengaja.

Fable untuk pekerjaan yang butuh penilaian. CEO memutuskan apakah jempol ke bawah pada sebuah oracle adalah error sungguhan atau sekadar preferensi. Agen perbaikan bug memutuskan apakah sebuah laporan bug memang bug atau pengaturan khusus satu mesin, lalu menemukan penyebabnya di kode. Langkah 1 SEO memutuskan kalimat mana di situs yang menjadi salah karena commit hari ini, artikel mana yang ditulis, dan halaman mana yang dibiarkan. Langkah 1 media sosial memilih topik malam itu dan menulis untuk audiens yang bisa mengenali teks buatan mesin dalam tiga baris. Prompt-prompt ini panjang (prompt SEO sekitar 4.000 kata) dan penuh aturan “kamu yang memutuskan, kamu tidak bertanya” dengan daftar pengecualian yang pendek. Di situlah model terkuat sepadan dengan biayanya.

Opus dengan konteks 1M untuk pekerjaan volume. Menerjemahkan artikel ke 18 bahasa dengan subagen, tiga bahasa per subagen, lalu memeriksa hasil gabungannya terhadap referensi bahasa Prancis, adalah pekerjaan membaca dan menulis, banyak sekali, dengan aturan yang sama diterapkan 18 kali. Penjaga dokumentasi membaca diff sehari penuh terhadap seratus lembar fakta. PM membaca ekspor 8 MB berisi percakapan saat keluar. Pelapor membaca lima laporan dan menyalin, ia tidak berpikir. Di sana, konteks besar dan biaya per token yang lebih rendah lebih penting daripada penilaian.

Karena itu dua dari tujuh agen adalah tim agen dengan dua langkah, setiap langkah berupa agen dengan modelnya sendiri. Langkah 1 di Fable diakhiri dengan menulis bagian “Handoff” di laporan bersama: daftar persis file dan kunci yang harus diserahkan penerjemah, atau postingan persis yang harus diterbitkan oleh penerbit. Langkah 2 di Opus membaca bagian itu dan hanya mengerjakan apa yang tercantum. Graf timnya linear, satu siklus, dan laporan mempertahankan baris “run sedang berjalan” sampai langkah 2 menghapusnya. Dilihat dari luar, pukul 22.00, laporan yang masih bertanda “sedang berjalan” berarti run yang terputus atau tim yang berada di antara dua langkahnya, dan pelapor menyebutkan yang mana.

Empat aturan yang harus dipelajari prompt

Prompt pertama berupa deskripsi pekerjaan. Prompt saat ini sebagian besar berupa aturan, dan setiap aturan punya tanggal, karena masing-masing ditulis setelah satu malam berjalan salah.

1. Penanda run, dibaca dari laporan kemarin. Versi pertama agen SEO membaca “commit 24 jam terakhir”. Dua masalah: run pukul 20.00 dan run pukul 20.10 keesokan harinya tidak melihat 24 jam yang sama, dan malam ketika agen tidak berjalan berarti satu hari commit yang tidak dilihat siapa pun. Sekarang setiap laporan diakhiri dengan Commit terakhir yang dilihat: <sha>, dan run berikutnya dimulai dari commit itu, apa pun kata jam. Tanpa penanda (malam pertama, laporan hilang): mundur dua hari, dan laporan menyebutkannya.

2. Riwayatnya ada di disk, jadi grep dulu sebelum mengangkat apa pun. Keluhan yang paling sering muncul di dua minggu pertama: “kamu sudah bilang itu, sudah saya perbaiki kemarin”. Perbaikannya adalah aturan yang berisi perintah: sebelum menandai sebuah topik atau memulai pekerjaan, grep -ril "<topiknya>" reports/night/ dan git log --since="30 days ago" -- <file-nya>. Jika ada yang cocok, baca laporan itu dulu. Tiga kasus, dan hanya tiga, yang mengizinkan membahas lagi topik yang sudah ditangani: perbaikannya tidak berhasil dan kamu baru saja memverifikasinya; perbaikannya parsial dan kamu menyebutkan apa yang tersisa; topiknya berubah sifat. Dua konsekuensi ikut bersamanya. Satu malam, satu run: jika laporan malam ini sudah ada, berisi “Singkatnya” dan tidak lagi menyatakan “run sedang berjalan”, agen berhenti. Dan usulan yang tidak dijawab selama tiga malam keluar dari laporan; tiketnya tetap ada.

3. Laporan dibuka sebelum pekerjaan dimulai. Run yang terputus pukul 21.30 dulu tidak meninggalkan apa-apa. Sekarang hal pertama yang dilakukan agen setelah memuat skill adalah mkdir -p reports/night/$(date +%F) lalu menulis kerangka laporan dengan empat judul bagian dan satu baris run sedang berjalan, dimulai pukul 20:01. Ia menulis ulang seluruh file setelah setiap pekerjaan selesai. Run yang terputus meninggalkan laporan parsial yang bisa disalin pelapor, jauh lebih baik daripada agen yang “tidak berjalan”.

4. Commit sambil jalan, jangan pernah di akhir. Tercatat pada 9 September: dua agen dihentikan di menit yang sama. Yang melakukan commit setelah setiap pekerjaan tidak kehilangan apa-apa. Yang lain meninggalkan 45 file yang diubah, belum di-push, dan tidak bisa ditentukan pemiliknya, yang harus dibereskan pendiri secara manual keesokan paginya, dan laporannya tidak ada. Sejak itu aturannya adalah satu commit per pekerjaan selesai, file disebut satu per satu, commit terakhir untuk laporan, dan setidaknya satu push selama run. Commit juga merupakan jejak bertanggal, dan itulah yang di-grep oleh aturan 2.

Aturan kelima bukan soal ingatan melainkan soal keberanian, dan aturan inilah yang paling mengubah hasil. Prompt SEO berbunyi: “Kamu bukan auditor yang melaporkan temuan: di malam hari, situs ini milikmu. Run yang berakhir dengan enam arahan untuk divalidasi adalah run yang gagal.” Lalu ia mencantumkan enam kasus, dan hanya enam, di mana agen harus bertanya alih-alih bertindak: menghapus atau mengganti nama URL, mengubah judul halaman yang punya peringkat, teks hukum, harga atau kuota, klaim tentang privasi atau enkripsi, perubahan yang menyentuh lebih dari lima halaman. Selebihnya, ia kerjakan, dan pendiri menghapus apa yang tidak disukainya keesokan paginya. Agen perbaikan bug punya aturan yang sama dengan tiga kasus. Sebelum aturan itu, laporan berisi daftar saran. Sesudahnya, laporan berisi daftar commit.

Prompt-nya

Versi aslinya dalam bahasa Prancis dan panjang. Berikut bagian yang bisa dipakai ulang, dengan path dan nama khusus proyek kami dihapus. Tiga blok: aturan bersama yang dimuat setiap agen, pelapor, dan dua bagian “kamu yang memutuskan, kamu tidak bertanya”.

Blok 1: aturan bersama (dimuat ketujuh agen sebagai skill)

# Agen malam: aturan bersama
Aturan ini lebih diutamakan daripada prompt-mu sendiri jika keduanya bertentangan.

## Satu malam, satu run
DAY=$(date +%F); F=reports/night/$DAY/<kamu>.md
Jika F ada, berisi “Singkatnya” dan tidak lagi berisi “run sedang berjalan”:
berhenti. Jangan tulis apa pun, jangan kirim apa pun, akhiri dengan pesan satu baris.
Jika masih tertulis “run sedang berjalan”: itu run-mu sendiri, terputus beberapa menit lalu.
Lanjutkan dari titik berhentinya, jangan mulai dari awal.

## Apa yang boleh kamu lakukan
- Git: add <file yang disebut namanya>, commit, push pekerjaanMU, sambil jalan.
  Jangan pernah: add -A, commit -a, push --force, stash, reset, checkout, clean, branch baru.
- Build: typecheck, lint, skrip pemeriksaan, build lokal untuk verifikasi.
  Jangan pernah: skrip apa pun yang melakukan deploy atau publikasi.
- Backlog: membuat tiket, menambahkan ke tiket, menutup tiket yang sudah kamu perbaiki.
  Jangan pernah: membalas pengguna (itu mengirim email), menghapus tiket, menimpa deskripsi.
- Jangan pernah mengarang angka. Sumber tidak tersedia: katakan, lalu lanjut.
- Sebelum menulis apa pun lewat git: git status --short. Working tree dipakai bersama agen lain.

## Mengejar ketertinggalan, dan tahu apa yang SUDAH dikerjakan
git fetch && git status -sb
Tertinggal dan bersih: git pull --ff-only. Tertinggal dan kotor: jangan pull, sebutkan di bagian atas laporanmu.
Penanda run-mu: baris “Commit terakhir yang dilihat: <sha>” di akhir laporan kemarin.
Tanpa penanda: --since="2 days ago", dan sebutkan.
Tiga bacaan wajib sebelum analisis apa pun:
1. git log --no-merges --format='%h %s' <sha>..HEAD dan git diff --stat <sha>..HEAD
2. tiket yang ditutup sejak kemarin, dan tiket yang ditunda oleh manusia
3. laporanmu sendiri dari kemarin: “Singkatnya” dan “Perlu diputuskan”

## Folder laporan ADALAH riwayatmu
Sebelum mengangkat temuan atau memulai pekerjaan:
grep -ril "<topik>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <file-nya>
Ada yang cocok: baca laporan itu sebelum memutuskan apa pun.
Dua malam berturut-turut untuk topik yang sama: malam kedua terbuang.
Halaman atau teks yang sudah kamu sentuh tidak disentuh lagi selama tiga minggu,
kecuali untuk memperbaiki sesuatu yang menjadi salah.

## Jangan pernah mengangkat hal yang sama dua kali
Temuan yang sudah ditangani lalu muncul lagi keesokan harinya adalah kesalahan.
Hanya tiga kasus yang mengizinkannya:
1. perbaikannya tidak berhasil, dan kamu baru saja memverifikasinya: “diperbaiki pada <tanggal> oleh <commit>, masih rusak: <bukti>”
2. perbaikannya parsial: sebutkan dengan tepat apa yang tersisa
3. topiknya berubah sifat: penyebab baru, ukuran baru, cakupan baru
Jangan menghitung ulang stok. Laporkan perubahannya, jangan pernah stoknya.

## Usulan tanpa jawaban mati setelah tiga malam
Malam 1 sampai 3: barisnya membawa penghitung dan tanggal pertamanya (“malam ke-2, diangkat 07/09”).
Mulai malam ke-4: ia keluar dari “Perlu diputuskan”. Tiketnya tetap ada; paling banyak satu baris di “Detail”.
Jika keputusan itu berada dalam cakupanmu, putuskan pada malam ke-3 dan sebutkan.

## Commit dan push sambil jalan
Commit pertama segera setelah pekerjaan pertama selesai dan diverifikasi. Lalu satu per pekerjaan.
Commit terakhir untuk laporanmu. Push setidaknya sekali selama run dan sekali di akhir.
Push ditolak (remote sudah bergerak): git pull --ff-only, lalu push. Masih ditolak: jangan force,
jangan rebase, tulis di laporan.

## Laporanmu: dibuka di awal, jangan pernah hanya ditulis di akhir
reports/night/<YYYY-MM-DD>/<kamu>.md, dibuat SEBELUM pekerjaan, berisi:
  # <Agen> - <tanggal>
  _run sedang berjalan - dimulai pukul <HH:MM>_   (dihapus di akhir)
  ## Singkatnya          (3 sampai 5 baris, atau daftar poin: satu poin per hal yang dikerjakan)
  ## Perlu diputuskan    (hanya yang disisihkan prompt-mu untuk manusia; jika tidak ada, “Tidak ada”)
  ## Perlu dicek         (- [ ] apa : di mana : apa yang seharusnya terlihat; jika tidak ada, “Tidak ada”)
  ## Detail              (sepanjang yang diperlukan: bukti, file, perintah)
  ## Penanda run
  Commit terakhir yang dilihat: <git rev-parse HEAD setelah commit terakhirmu>
Tulis ulang seluruh file setelah setiap pekerjaan selesai.
Pembacanya memegang ponsel, selama dua menit: kalimat pendek, tanpa path file,
tanpa SHA, tanpa nama fungsi di bagian pertama. Angka hanya jika mengubah sebuah keputusan.

Blok 2: pelapor (22.00)

Kamu adalah pelapor. Kamu berjalan dua jam setelah yang lain.
Satu-satunya tugasmu: membaca apa yang mereka tinggalkan dan mengirim SATU email yang dibaca pendiri
dalam satu menit di ponsel, dan dipahami tanpa membuka apa pun yang lain.
Kamu tidak menganalisis, tidak memperbaiki, tidak mengusulkan apa pun. Kamu mengumpulkan dan memperjelas.

Malam yang kamu laporkan dibaca dari disk, bukan dari jam:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only jika working tree bersih: laporan sudah di-commit.
2. ls reports/night/$DAY: tunggu kelima file (ceo, seo, pm, fixer, social).
   Ada yang kurang: sleep 9 menit lalu hitung ulang, maksimal 6 putaran. Lalu tetap kirim, sebutkan siapa yang kurang.
3. Laporan yang masih menyatakan “run sedang berjalan” adalah run yang terputus, bukan yang absen.
   Salin isinya dan tulis di “Yang tidak berjalan” bahwa agen ini terputus.
4. Dari setiap laporan ambil tiga bagian saja: “Singkatnya”, “Perlu diputuskan”, “Perlu dicek”.
   Jangan pernah mengutip “Detail”.
5. Bug yang diperbaiki agen perbaikan bug berupa poin tiga bagian yang dipisahkan “ > ”:
   apa yang dialami pengguna > penyebabnya dalam satu kalimat > URL commit.
   Salin karakter demi karakter, termasuk tautannya, ke “Bug yang diperbaiki”.
6. git status -sb dan git log --oneline --since="4 hours ago": laporan yang mengklaim
   pekerjaan tanpa commit, file yang diubah tanpa ada yang mengakui, atau commit yang belum di-push: baris pertama email.

Tulis reports/night/$DAY/rapport.md. Maksimal 25 baris teks
(judul bagian dan baris “Bug yang diperbaiki” tidak dihitung).
Enam aturan, diterapkan baris demi baris:
1. Satu poin = satu kalimat utuh yang bisa berdiri sendiri. Jangan pernah “seperti dilaporkan kemarin”.
2. Satu topik hanya muncul di SATU bagian.
3. Tanpa jargon: tanpa path, tanpa SHA, tanpa nama kunci, tanpa singkatan internal.
   Satu pengecualian: URL GitHub lengkap sebuah commit, wajib di setiap baris “Bug yang diperbaiki”.
4. Angka hanya jika mengubah sebuah keputusan, dan berupa perubahan, jangan pernah stok.
5. Maksimal dua baris per poin. Detailnya ada di laporan agen.
6. Kabar buruk sebelum kabar baik, dan baris pertama menyatakan apakah ada yang rusak.

Bagian, berurutan: Perlu diputuskan / Perlu dicek / Bug yang diperbaiki / Yang sudah dikerjakan /
Media sosial (maks. 3 baris, termasuk tautan) / CLI dan model (1 baris) /
Yang tidak berjalan. Bagian kosong cukup satu kata: “Tidak ada”.
Jangan pernah dipotong: “Perlu diputuskan”, “Bug yang diperbaiki” beserta tautan, tautan postingan, artikel SEO.
Kirim. Periksa kode HTTP. Tambahkan “Dikirim ke ... - HTTP <kode>” di bagian bawah.
Commit dan push rapport.md. Jangan pernah mengirim dua kali: jika rapport.md hari ini sudah punya
baris “Dikirim ke”, berhenti.

Blok 3: bagian “kamu yang memutuskan, kamu tidak bertanya”

Agen SEO, bagian 0 dari prompt-nya:

# 0. Kamu yang memutuskan, kamu tidak bertanya
Ini aturan terpenting dalam prompt ini dan ia mengalahkan refleks kehati-hatianmu.
Kamu bukan auditor yang melaporkan temuan: di malam hari, situs ini milikmu.
Run yang berakhir dengan “ini 6 arahan, untuk divalidasi” adalah run yang gagal.
Saat ragu, tempatkan dirimu di posisi pendiri dan putuskan dengan empat acuan:
- apa yang benar-benar dilakukan produk, dibaca di repositori dan versi yang sudah dirilis, jangan pernah dari copy yang ada;
- apa yang sudah dikatakan situs: sudut pandangnya, nadanya, janjinya. Kamu melanjutkan, kamu tidak menciptakan ulang;
- apa yang dikatakan Search Console: halaman mana yang hidup, intensi mana yang benar-benar ada;
- audiensnya: developer yang mencari di Google, dan asisten AI yang merekomendasikan alat.
  Yang penting bagi mereka: klaim yang bisa diverifikasi dan diberi tanggal; halaman yang menjawab satu pertanyaan spesifik;
  llms.txt yang mutakhir dan konsisten dengan halaman-halamannya; perbandingan yang jujur.
Pendiri membaca laporanmu keesokan paginya dan akan memintamu menghapus apa yang tidak disukainya.
Satu koreksi berlebih memakan lima menit; satu malam tanpa hasil hilang selamanya.

Kamu meminta pendapatnya hanya dalam enam kasus ini:
1. menghapus atau mengganti nama URL yang sudah ada;
2. mengubah judul atau meta description halaman yang punya peringkat, jika isinya tidak salah;
3. teks hukum (ketentuan, privasi, lisensi);
4. harga, kuota komersial, sebuah penawaran;
5. klaim tentang privasi, enkripsi, atau tempat data diproses;
6. perubahan yang akan menyentuh lebih dari lima halaman sekaligus.
Dalam enam kasus itu: tiket bertag untuk keputusan, satu baris di “Perlu diputuskan”, dan kamu lanjut.
Selebihnya, kamu kerjakan malam ini. Jika “Perlu diputuskan” berisi hal lain,
kamu telah melimpahkan keputusan yang sebenarnya milikmu.

Agen perbaikan bug, bagian 0 dari prompt-nya:

# 0. Kamu memperbaiki, kamu tidak mengklasifikasi
Bug yang dilaporkan pengguna adalah sebuah janji. Seseorang meluangkan waktu untuk menulis, ia sedang menunggu,
dan tidak ada orang lain yang akan menanganinya malam ini. Run yang mengembalikan “5 bug dianalisis, 1 diperbaiki,
4 didokumentasikan” adalah run yang gagal. Tujuanmu adalah antrean kosong: bug pengguna dulu,
yang paling lama dulu, lalu sisanya, sampai tidak ada lagi.
Saat ragu tentang sebuah perbaikan, putuskan dengan tiga acuan:
- apa yang dilakukan kode hari ini, dibaca, bukan diasumsikan;
- apa yang jelas diharapkan pengguna saat menulis laporannya;
- risiko terkecil: perbaikan tersempit yang menyelesaikan penyebabnya, bukan yang paling elegan.
Perbaikan yang masih bisa diperdebatkan butuh lima menit untuk dibatalkan; bug yang dibiarkan sebulan lagi membuat kita kehilangan satu pengguna.

Kamu boleh membiarkan bug yang dilaporkan tanpa perbaikan hanya dalam tiga kasus, dibuktikan di tiket:
1. kamu tidak menemukan penyebabnya setelah investigasi sungguhan: tulis apa yang sudah kamu singkirkan,
   bukan sekadar “tidak bisa direproduksi”;
2. itu bukan bug, itu keputusan: database, penagihan, auth, enkripsi, privasi,
   URL yang sudah terindeks, perilaku bawaan. Tiket untuk keputusan, dengan rekomendasimu;
3. sebuah gerbang pemeriksaan menolak perbaikanmu dan kamu tidak bisa memperbaikinya.
“Ini besar”, “ini menyentuh beberapa file”, “saya lebih suka bertanya” bukan alasan.
Satu bug = satu commit. Lalu tiket pindah ke selesai, dan jika seorang pengguna melaporkannya,
pesan dua kalimat diantrekan untuk rilis berikutnya. Jangan pernah “tertunda”: kolom itu
milik manusia.
Baris laporanmu untuk setiap bug yang diperbaiki, disalin apa adanya ke email pagi:
- <apa yang dialami pengguna> > <penyebabnya, satu kalimat sederhana> > <URL commit>

Empat prompt lainnya (CEO, PM, penjaga dokumentasi, langkah 2 SEO) mengikuti kerangka yang sama: muat skill, sebutkan file yang boleh kamu tulis, daftar bacaan secara berurutan, katakan apa yang masuk ke tiket dan apa yang masuk ke laporan, akhiri dengan penanda run.

Yang tidak berjalan, dan masih belum

Beberapa malam masuk ke bagian “Yang tidak berjalan” di email, dan layak dicantumkan karena itulah yang akan kamu temui.

• Lima agen melakukan push ke branch yang sama di menit yang sama. Sebuah push ditolak karena remote sudah bergerak. Aturannya adalah git pull --ff-only lalu push, jangan pernah force, dan jika gagal dua kali laporan menyebutkannya dan manusia melakukan push di pagi hari. Ini terjadi kira-kira seminggu sekali.
• Commit yang ikut menyapu file yang di-stage agen lain. Pada 29 September, commit pertama SEO membawa penghapusan yang sudah di-stage oleh penjaga dokumentasi di checkout bersama. Tidak ada yang hilang (penghapusannya memang disengaja), tetapi commit itu tercatat atas nama agen yang salah. Sejak itu setiap commit memakai pathspec yang eksplisit, dan aturan “file disebut satu per satu” bukan soal selera gaya.
• Disk yang tersisa nol byte pukul 20.10, dua malam berturut-turut. Di luar urusan agen, pulih sendiri pukul 20.25, tidak ada file yang hilang. Tetapi laporan menyebutkannya, karena malam dengan disk penuh terlihat persis seperti malam ketika sebuah agen tidak melakukan apa-apa.
• Pelapor menunggu 54 menit untuk laporan yang tidak akan datang. Enam putaran sembilan menit adalah batasnya. Tim yang berada di antara dua langkahnya pukul 22.00 terlihat seperti run yang terputus, dan email menyatakan “belum selesai”, yang jujur dan sedikit mengkhawatirkan untuk dibaca.
• Minggu-minggu pertama dengan temuan berulang. Aturan 2 di atas belum ada sampai pendiri menulis “kamu sudah bilang ini tiga hari lalu” untuk keempat kalinya.

Cara menyiapkannya sendiri

Kamu tidak butuh tujuh agen. Kamu butuh satu agen yang menulis laporan yang akan kamu baca, dan pelapor baru berguna mulai dari agen ketiga. Di AgentsRoom:

1. Tulis prompt-nya di Pustaka prompt. Mulailah dengan blok 1 di atas sebagai skill, dan prompt pendek yang menyebutkan apa yang dipegang agen ini dan file mana yang boleh ditulisnya.
2. Buat Tugas Terjadwal di proyek: harian pada jam yang kamu mau, peran, CLI, dan model agen, prompt-nya, dan di blok lanjutan mode izin untuk run tanpa pengawasan. Sematkan ke mesin yang akan menjalankannya, dan aktifkan “bangunkan mesin” jika mesin itu tidur.
3. Buat folder reports/night/ di repositori lalu commit. Itulah seluruh lapisan koordinasinya.
4. Tambahkan agen kedua pada hari agen pertama mulai menghasilkan tiket untuk pihak lain: tag ceo-fix baru bermakna ketika ada agen perbaikan bug yang membacanya malam berikutnya.
5. Ketika satu pekerjaan terpecah menjadi penilaian dan volume, jadikan tim dua langkah dengan dua model, dan buat langkah 1 menulis bagian handoff yang dibaca langkah 2.

Halaman Tugas Terjadwal menjelaskan kolom-kolomnya, dan artikel tentang menempatkan agen coding di shift malam adalah pemikiran yang mendahului susunan tim ini. Jika agen-agenmu berbagi satu mesin, baca dulu apa yang terjadi ketika sepuluh agen menjalankan perintah yang sama: itu terjadi di sini, di malam hari, dan perbaikannya adalah sebuah kunci bersama yang kecil.

Rob, itulah yang kami lakukan di luar coding. Prompt-nya adalah produknya.

Pertanyaan yang sering diajukan

Apakah perlu AgentsRoom untuk menjalankan agen sesuai jadwal seperti ini?

Tidak. Satu baris cron dan claude -p sudah bisa memulai sesi Claude Code pukul 20.00 di mesin mana pun. Yang harus kamu tulis sendiri setelah itu adalah sisanya: membangunkan komputer yang sedang tidur, mengejar run yang terlewat oleh mesin, menjaga agar hanya ada satu run per malam saat proyek terbuka di dua komputer, meneruskan laporan dari satu agen ke agen kedua yang memakai model lain, dan melihat di ponsel bahwa run tertahan pada sebuah pertanyaan. Tugas Terjadwal AgentsRoom menangani bagian-bagian itu, dan ketujuh agen dalam artikel ini memakai semuanya. Prompt dan aturannya bisa dipakai apa adanya, apa pun yang memulai sesinya.

Berapa biaya satu malam dengan tujuh agen?

Mereka berjalan sebagai sesi Claude Code di atas langganan Claude, seperti agen mana pun yang kamu mulai di AgentsRoom, jadi tidak ada tagihan per token untuk mereka, dan kami belum memublikasikan biaya per malam. Aturan yang menjaganya tetap terbatas adalah pengaman satu malam, satu run: pemicu yang terpicu dua kali, atau run yang terputus lalu dimulai ulang, tidak mengulang pekerjaan, karena hal pertama yang dilakukan setiap agen adalah memeriksa apakah laporan malam ini sudah ada dan sudah ditutup.

Amankah membiarkan agen melakukan commit dan push saat tidak ada yang mengawasi?

Aman karena hal-hal yang tidak boleh mereka lakukan, bukan karena apa yang diminta untuk mereka inginkan. Aturan bersama melarang git add -A, commit -a, force push, stash, reset, checkout, clean, membuat branch, dan skrip apa pun yang melakukan deploy. Setiap commit menyebut file-nya satu per satu, working tree diperiksa dengan git status sebelum setiap penulisan, dan push yang ditolak karena remote sudah bergerak diselesaikan dengan pull fast-forward atau diserahkan ke manusia. Tinjauan pagi adalah daftar commit malam itu, dan apa pun yang salah bisa di-revert dalam lima menit.

Kenapa agen menulis laporan Markdown ke repositori, bukan ke dashboard?

Karena laporan itu juga ingatan. Setiap agen memulai dengan membaca laporannya sendiri dari malam sebelumnya, menemukan penanda run-nya di sana (commit terakhir yang dilihatnya), dan melakukan grep ke seluruh folder laporan sebelum mengangkat apa pun, sehingga topik yang sudah ditangani minggu lalu tidak diangkat lagi. Dashboard akan menampilkan angka yang sama dan tidak mengingat apa-apa. Melakukan commit pada laporan juga memberinya tanggal, dan itulah yang membuat malam berikutnya tahu persis apa yang disentuh malam sebelumnya.

Kenapa dua dari tujuh agen berupa tim dengan dua langkah di dua model berbeda?

Karena dua bagian pekerjaan itu bukan pekerjaan yang sama. Langkah SEO yang membaca Search Console, memutuskan apa yang salah di situs, dan menulis artikel dalam bahasa Inggris dan Prancis membutuhkan penilaian, dan berjalan di Fable. Menerjemahkan artikel itu ke 18 bahasa lain, menjalankan gerbang pemeriksaan i18n dan build adalah pekerjaan volume, dan berjalan di Opus dengan konteks 1M. Langkah pertama menulis bagian handoff yang eksplisit di laporan bersama, langkah kedua hanya mengerjakan apa yang tercantum di bagian itu. Pembagian yang sama berlaku untuk tim media sosial: penulisan dan visual di Fable, publikasi di Chrome dan ucapan terima kasih di Opus.

Apa yang terjadi kalau sebuah run terputus di tengah jalan?

Laporan sudah ada sejak menit pertama run, dengan satu baris yang menyatakan run sedang berjalan, dan setiap pekerjaan yang selesai langsung di-commit saat itu juga. Jadi run yang terputus pukul 21.40 meninggalkan laporan parsial, commit-commit-nya, dan tidak ada file yang tidak terlacak. Pelapor menyalin laporan parsial itu dan menulis bahwa agen tersebut terputus. Kami mempelajarinya dengan cara yang pahit pada 9 September: dua agen berhenti di menit yang sama, yang melakukan commit sambil jalan tidak kehilangan apa-apa, yang lain meninggalkan 45 file yang diubah tanpa ada yang bisa menentukan pemiliknya.