AI agent kantor yang cuma “bot Slack pintar” bakal cepat kelihatan batasnya begitu dipakai lebih dari satu orang.
Artikel ini membahas kenapa multiplayer AI agent butuh fondasi yang beda dari chatbot personal: scope, permission, memory, sandbox, crons, dan audit trail. Pemicu utamanya adalah repo open-source qm, yang menyebut dirinya sebagai “multiplayer agent harness for work”. Buat developer dan founder kecil, pelajarannya bukan “langsung pakai qm”, tapi cara membaca arah baru: AI agent mulai jadi infrastruktur kerja tim, bukan sekadar prompt panjang di chat.
Menurut gua, ini sinyal yang penting karena banyak tim masih memperlakukan agent seperti intern virtual yang dikasih akses besar dan instruksi seadanya. Padahal begitu agent masuk Slack, repo, deployment, keychain, dan cron, masalahnya bukan lagi “modelnya pintar atau nggak”. Masalahnya berubah jadi: siapa boleh ngapain, di scope mana, pakai credential siapa, dan jejak kerjanya bisa dicek ulang atau nggak.
Apa itu qm dan kenapa rame?
qm adalah project open-source dari yc-software/qm yang mendeskripsikan diri sebagai multiplayer agent harness for work. Dari README-nya, qm didesain untuk startup: tiap employee punya workspace terisolasi, tapi tetap bisa kolaborasi dengan agent lewat Slack channel, group message, project, dan web app.
Yang menarik bukan cuma integrasi Slack-nya. README qm menyebut tiap orang dan tiap room punya scoped memory, files, keychain view, permissions, crons, web apps, dan durable sandbox. Mereka juga menekankan pilihan harness/model: Pi, OpenCode, Codex, dan Claude Code bisa menggerakkan core yang sama, jadi deployment tidak harus terkunci ke satu vendor.
Sinyal sosialnya juga kuat. Story “qm – Multiplayer agent harness for work” di Hacker News tembus ratusan poin dan diskusi aktif. Buat gua, angka HN bukan bukti produk pasti matang, tapi cukup buat menunjukkan bahwa problem ini mulai dirasakan banyak orang: agent pribadi gampang dibayangkan, agent tim jauh lebih rumit.
Kenapa chatbot personal tidak cukup buat kerja tim?
Chatbot personal biasanya punya asumsi sederhana: satu user, satu konteks, satu histori percakapan, satu set instruksi. Itu masih relatif aman selama agent cuma bantu mikir, nulis draft, atau menjawab pertanyaan.
Begitu masuk tim, asumsi itu pecah. Room marketing, room engineering, dan room finance tidak boleh punya memory yang sama. Credential deploy staging tidak boleh otomatis bisa dipakai dari semua channel. Cron yang jalan atas nama tim harus punya owner. File internal yang boleh dibaca founder belum tentu boleh dibaca contractor. Agent yang bisa menjalankan command di sandbox juga harus jelas batasnya.
Ini definisi sederhana yang bisa dipakai: multiplayer AI agent adalah agent yang dipakai banyak orang atau banyak ruang kerja sekaligus, dengan context, izin, memory, dan aksi yang harus dipisah berdasarkan user, room, project, atau role.
Kalau boundary itu tidak ada, agent tim berubah jadi satu bot full-access yang kebetulan ramah di chat. Di permukaan terlihat produktif. Di dalamnya, risk model-nya berantakan.
Pelajaran utama: scope lebih penting daripada prompt sopan
Banyak orang masih berharap prompt bisa jadi pagar utama. Misalnya: “jangan akses file sensitif”, “jangan deploy tanpa izin”, “jangan pakai credential production”. Masalahnya, prompt itu bukan permission system.
Prompt berguna buat niat dan kebiasaan kerja. Tapi untuk akses nyata, lu tetap butuh boundary teknis. Kalau agent tidak punya token production, dia tidak bisa deploy production. Kalau room tertentu tidak punya keychain view, agent di room itu tidak bisa asal pakai credential. Kalau sandbox dibatasi, blast radius saat command salah juga lebih kecil.
Ini mirip pelajaran lama di security: jangan menggantungkan keamanan ke “user harus ingat jangan salah klik”. Sistem yang sehat bikin aksi berbahaya sulit dilakukan tanpa approval, bukan cuma menulis aturan panjang di dokumen.
Checklist buat tim yang mulai pakai AI agent bareng-bareng
Sebelum tim lu menaruh agent di Slack, Linear, GitHub, atau dashboard internal, gua akan cek minimal ini:
- Scope per ruang kerja: apakah agent punya konteks berbeda untuk user, room, dan project?
- Permission per aksi: apakah read, write, deploy, delete, dan invite dipisah jelas?
- Credential hygiene: agent pakai credential sendiri atau numpang akun manusia?
- Keychain view: apakah credential sensitif hanya terlihat di scope yang memang perlu?
- Sandbox: command agent jalan di environment tahan banting atau langsung di mesin utama?
- Audit trail: apakah tim bisa melihat file apa yang dibaca, command apa yang dijalankan, dan output apa yang berubah?
- Human approval: aksi irreversible seperti deploy, delete data, atau kirim email eksternal butuh konfirmasi?
- Model/harness portability: kalau provider berubah, apakah workflow dan artifact tetap bisa dipindah?
Checklist ini tidak harus langsung jadi sistem enterprise mahal. Untuk tim kecil, bentuknya bisa sesederhana repo policy, Slack channel khusus, akun service terbatas, folder kerja terpisah, dan log yang disimpan. Intinya: jangan tunggu incident baru sadar agent punya akses terlalu luas.
Hubungannya dengan Hermes, Obsidian, dan workflow builder
Di workflow rafli.dev, gua makin merasa AI yang berguna bukan cuma model yang menjawab bagus. Yang lebih penting adalah operating layer: catatan riset di Obsidian, backlog ide, draft lokal sebelum Ghost, quality gate bahasa, anti-dupe, dan readback API sebelum laporan final.
Itu semua terdengar boring, tapi justru di situ bedanya workflow AI yang bisa dipercaya dan workflow AI yang cuma demo. Agent boleh bantu menulis, meriset, dan mengotomasi. Tapi artifact harus tetap ada: sumber, alasan memilih topik, draft HTML lokal, status Ghost draft, dan perubahan backlog.
qm menarik karena membawa pola serupa ke level tim: agent tidak hidup sebagai chat bubble tunggal, tapi sebagai sistem kerja dengan memory, permission, file, cron, dan sandbox. Sekali lagi, ini bukan berarti qm otomatis jawaban final. Gua belum menulis ini sebagai review teknis hasil instalasi. Gua menulis ini sebagai sinyal arah produk: agent yang dipakai tim butuh desain sistem, bukan cuma personality.
Risiko salah baca: jangan langsung overclaim
Ada dua risiko saat melihat project seperti qm. Pertama, terlalu hype dan menganggap semua tim harus punya multiplayer agent sekarang juga. Kedua, terlalu sinis dan menganggap ini cuma wrapper Slack lain.
Posisi gua di tengah: project seperti qm menarik karena naming problem-nya tepat. Tapi buat production, tim tetap harus menguji maturity, security model, data retention, logging, deployment, dan recovery. Open-source repo yang viral tetap perlu dibaca seperti software biasa: cek issue, arsitektur, batasan, dan apakah sesuai kebutuhan tim lu.
Kalau tim lu cuma butuh asisten personal buat rangkum meeting, mungkin setup besar seperti ini overkill. Tapi kalau agent mulai punya akses ke repo, secrets, internal tools, dan channel tim, lu harus mulai mikir seperti operator sistem.
Takeaway praktis
- AI agent buat tim beda problem dari chatbot personal.
- Prompt bukan permission system. Akses harus dibatasi secara teknis.
- Memory dan credential harus punya scope: user, room, project, atau role.
- Sandbox dan audit trail bukan fitur mewah kalau agent bisa menjalankan aksi nyata.
- Tool seperti qm menarik sebagai sinyal arah: agent infrastructure mulai jadi kategori produk sendiri.
FAQ singkat
Apakah tim kecil butuh multiplayer AI agent?
Belum tentu. Kalau agent cuma bantu personal productivity, chatbot biasa mungkin cukup. Tapi kalau agent masuk Slack, repo, dashboard, atau deployment, tim kecil pun butuh boundary akses yang jelas.
Apakah qm sudah siap production?
Gua tidak akan klaim begitu tanpa uji langsung. Yang bisa dikatakan: README dan diskusi publiknya menunjukkan problem penting yang makin relevan, yaitu agent tim butuh scope, permission, memory, dan sandbox.
Apa langkah pertama yang paling realistis?
Mulai dari inventory akses. Tulis tool apa saja yang bisa diakses agent, credential siapa yang dipakai, aksi apa yang irreversible, dan log apa yang tersedia kalau terjadi masalah.
Penutup
AI agent yang bagus bukan cuma yang terdengar pintar di chat. Buat kerja tim, agent yang bagus harus bisa dibatasi, diaudit, dipindah, dan dimatikan saat perlu.
Kalau lu lagi membangun workflow AI di tim, jangan mulai dari pertanyaan “model mana yang paling pintar?”. Mulai dari pertanyaan yang lebih membosankan tapi lebih penting: scope-nya apa, permission-nya apa, credential-nya siapa, dan jejak kerjanya bisa dicek ulang nggak?
Follow rafli.dev kalau lu mau bahasan AI, developer tools, dan workflow builder yang pro-AI tapi tetap waras.
