Rangkuman DevDay OpenAI pada tanggal 29 September menjelaskan contohnya secara gamblang: “Anda dapat meminta ChatGPT memantau tugas-tugas baru di papan proyek. Saat ada tugas masuk, ChatGPT dapat membaca dokumen yang ditautkan dan menyusun draf rencana, bahkan ketika Anda sedang tidak di tempat.” Di balik itu semua adalah dukungan ChatGPT untuk proposal spesifikasi MCP Events pada semua paket langganan, yang diluncurkan bersamaan dengan dua fitur tim: team tasks yang berjalan terjadwal atau berdasarkan event, serta @ChatGPT di Slack dan Teams.
Bagi tim yang sudah menjalankan coding agent, papan proyek yang dipantau oleh agen mengubah makna dari sebuah tugas baru. Dahulu, tugas baru harus menunggu tindakan manusia. Sekarang, tugas tersebut dapat mengaktifkan satu atau beberapa agen sekaligus. Jika dua orang masing-masing meminta ChatGPT memantau papan yang sama, sementara papan itu sendiri memiliki Agent yang ditugaskan untuk pekerjaan baru, maka satu tugas baru dapat menghasilkan tiga draf rencana di tiga tempat berbeda, dan belum ada yang memutuskan draf mana yang dianggap sah.
TL;DR
MCP Events memberi ChatGPT mekanisme yang rapi dan terverifikasi (signed) untuk mengetahui perubahan di aplikasi yang terhubung, dan ChatGPT team tasks menghadirkan alur kerja terjadwal serta berbasis event untuk paket Business dan Enterprise. Memanfaatkan event untuk memulai sebuah agen adalah bagian yang mudah, dan OpenAI telah melakukannya dengan sangat cermat. Bagian yang sulit adalah apa yang dihasilkan oleh event tersebut di papan proyek: siapa penanggung jawab dari pekerjaan yang dihasilkan, di mana draf rencana ditempatkan, bagaimana proses peninjauannya, dan bagaimana mencegah dua agen menanggapi event yang sama. Tuangkan itu ke dalam aturan perutean: satu jenis event, satu pemilik, rencana yang dikembalikan ke Task, dan seorang manusia yang menyetujui sebelum apa pun dianggap selesai.
Apa yang diluncurkan di DevDay
MCP Events adalah usulan ekstensi untuk Model Context Protocol yang memungkinkan server MCP memberi tahu ChatGPT ketika terjadi sesuatu di aplikasi yang terhubung, sehingga plugin dapat memulai otomatisasi sebagai responsnya. Panduan MCP Events dari OpenAI menjelaskan aspek sisi server. Server mengumumkan bahwa ia mendukung event dan mengimplementasikan tiga metode: events/list, events/subscribe and events/unsubscribe. ChatGPT hanya mendukung pengiriman melalui webhook, ditandatangani dengan HMAC Standard Webhooks, setelah melalui HTTPS verification challenge, dengan batasan satu event per permintaan hingga 256 KiB. Ketika sebuah event tiba, seperti yang dinyatakan dalam panduannya, “ChatGPT menerima event pada obrolan yang berlangganan dan mengikuti instruksi pengguna tentang cara meresponsnya.”
Detail teknisnya sangat cermat pada bagian-bagian penting. Server harus memberikan ID unik untuk setiap event yang tetap sama pada setiap percobaan ulang. Langganan (subscription) harus bersifat idempoten: identitasnya berasal dari principal, URL callback, nama event, dan argumen, sehingga berlangganan kembali akan memperbarui langganan yang sudah ada, alih-alih membuat langganan baru. Server wajib memblokir alamat callback privat dan lokal serta tidak boleh mengikuti pengalihan (redirect).
| Fitur | Fungsi | Paket | Penentu respons |
|---|---|---|---|
| MCP Events | Server MCP mengirim event; ChatGPT menjalankan otomatisasi yang Anda tentukan | Semua paket | Orang yang obrolannya berlangganan |
| Team tasks | Pekerjaan berulang, seperti pembaruan proyek mingguan, berdasarkan jadwal atau sebagai respons atas event seperti email baru atau pesan Slack | Business, Enterprise | Rekan satu tim menyempurnakan instruksi secara bersama-sama |
| @ChatGPT di Slack dan Teams | Sebut di saluran, utas, atau pesan langsung; menggunakan alat yang terhubung melalui admin, atau alat Anda sendiri sesuai izin Anda | Business, Enterprise | Siapa saja dalam percakapan dapat menambahkan konteks, tanpa memerlukan lisensi ChatGPT individual |
Secara bersamaan, semua ini menjadikan ChatGPT tempat di mana pekerjaan dapat dimulai dari luar percakapan. Ini adalah langkah maju yang nyata, dan untuk banyak pekerjaan berulang, hal ini sudah memadai.
Pemicu hanyalah bagian yang mudah
Coba terapkan contoh dari rangkuman tersebut pada tim nyata. Sebuah tugas baru tiba di papan proyek. ChatGPT membaca dokumen yang ditautkan dan menyusun draf rencana. Empat pertanyaan pun menyusul, dan tidak ada satu pun yang berkaitan dengan protokol transportasi.
Siapa yang memiliki pekerjaan yang dihasilkan? Draf rencana bukanlah sebuah penugasan. Seseorang harus bertanggung jawab atas pekerjaan yang dijelaskan di dalamnya, dan pada sebagian besar tim kepemilikan tersebut dicatat di papan proyek: nama pada tugas dan status yang terus bergerak. Draf rencana yang baik tidak akan mengubah keduanya dengan sendirinya.
Ke mana rencana tersebut dikirim? Event tiba di obrolan yang berlangganan, dan rencana tersebut akan diteruskan ke mana pun instruksi orang tersebut mengarahkannya: balasan di obrolan, atau penulisan kembali ke papan proyek jika plugin menyediakannya dan instruksi memintanya. Tim harus mengetahui hal ini, jika tidak, papan akan terus menampilkan status “baru” sementara rencana yang sudah tersusun matang justru menunggu di suatu tempat yang tidak dibaca oleh siapa pun.
Bagaimana rencana tersebut ditinjau? Sebuah rencana adalah keputusan tentang cakupan kerja. Seseorang selain pembuatnya harus membacanya sebelum kode mulai ditulis, di tempat yang mudah ditemukan oleh orang berikutnya.
Siapa yang menanggapi event tersebut? Idempotensi mencegah satu langganan menduplikasi dirinya sendiri. Namun, mekanisme ini tidak mengoordinasikan dua orang yang berbeda, karena principal merupakan bagian dari identitas langganan, sehingga langganan setiap orang berdiri sendiri. Ditambah dengan Agent yang ditugaskan di papan, tugas yang sama dapat direncanakan lebih dari sekali. Deduplikasi pada lapisan webhook tidak menentukan kepemilikan di lapisan alur kerja.
Ini semua adalah persoalan manajemen. Masalah-masalah ini sudah ada bahkan sebelum era agen AI, seperti ketika tiga orang bisa saja mengambil tiket yang sama, dan kini masalah tersebut muncul kembali lebih cepat ketika pihak yang mengambilnya tidak pernah tidur. Untuk aspek peninjauan pada pekerjaan tanpa pengawasan, lihat agen pengodean saat Anda tidak di tempat.
Tempatkan perutean di papan proyek
Pada papan proyek tempat agen bertindak sebagai Assignee, “pantau tugas baru” sebagian besar berubah menjadi “tugaskan tugas tersebut.” Di Sharkly, Task yang ditugaskan ke sebuah Agent akan memulai eksekusi ketika meninggalkan Backlog dan Computer serta Runtime-nya sudah siap. Slot Assignee eksekusi hanya dapat diisi tepat oleh satu Agent atau Crew, dan Sharkly menggabungkan pekerjaan yang tertunda sehingga komentar bertubi-tubi tidak menciptakan duplikasi eksekusi tertunda untuk Agent dan Task yang sama. Kepemilikan tugas adalah sebuah kolom isian (field), bukan sekadar kebiasaan.
Untuk event yang perlu memulai pekerjaan tanpa penugasan langsung, Sharkly Automations adalah padanannya di sisi papan proyek. Sebuah Automation merupakan satu aturan: instruksi, sebuah Agent atau Crew, satu atau beberapa pemicu, dan riwayat eksekusi, dengan status Active atau Paused. Pemicunya meliputi jadwal (cron dengan zona waktu), Task yang berpindah ke status tertentu, komentar yang memuat frasa tertentu, dan webhook dari layanan eksternal, ditambah opsi Run now untuk pengujian. Setiap eksekusi dimulai secara langsung dan mencatat riwayatnya pada Automation, sehingga instruksi harus menyebutkan di mana hasilnya dicatat. Pencocokan status dan komentar saat ini berlaku di seluruh organisasi, sehingga dokumentasi Automations merekomendasikan instruksi yang memverifikasi Task pemicu sebelum mengambil tindakan.
Berikut tabel pemetaan event ke tugas di salah satu Space:
| Event | Mekanisme | Pelaksana | Tempat hasil dikembalikan | Pengambil keputusan |
|---|---|---|---|---|
| Permintaan dikirim di Slack | Pintasan Slack membuat Task dalam status triase | Belum ada | Task terkait, dalam status Triage | Manusia menerima, menolak, menandai duplikat, atau menundanya |
| Issue GitHub dibuat | Integrasi GitHub: issue baru di repositori tertaut dijadikan Task | Belum ada | Task terkait | Siapa pun yang melakukan triase di Space tersebut |
| Task berpindah ke “Needs plan” | Automation, pemicu status | Planner Agent | Komentar pada Task | Assignee manusia dari Task tersebut |
| Komentar “/replan” pada Task | Automation, pemicu komentar | Planner Agent | Komentar baru pada Task | Assignee manusia dari Task tersebut |
| Task ditugaskan ke coding Agent, keluar dari Backlog | Eksekusi Task | Agent tersebut, di Computer miliknya | Comments, Executions, pull request tertaut | Peninjau, lalu disetujui oleh manusia |
| Webhook kegagalan CI | Automation, pemicu webhook | Triage Agent | Riwayat eksekusi Automation | Petugas siaga (on-call) |
| Hari kerja pukul 09.00 | Automation, pemicu jadwal | Status Agent | Riwayat eksekusi, dan baris Inbox untuk setiap penerima | Team lead |
Dan berikut aturan di baliknya, ditulis di tempat yang terbuka untuk didiskusikan oleh tim:
Routing rule: new work in the ENG Space
1. One event type, one owner. Each event maps to exactly one
Automation or one Agent Assignee. Personal watchers (a chat
subscription, a dot) may read the board; they do not plan on it.
2. New requests enter Triage. A person accepts before any Agent runs.
3. Accepted work that needs a plan moves to "Needs plan", a status in
the Backlog category. The "Draft plan" Automation runs the Planner
Agent, which first checks the Task's Space and type and stops if
the Task is not ours.
4. The plan returns to the Task as a comment. The Planner does not
change status and does not assign anyone.
5. The Task's human assignee reads the plan, assigns the executing
Agent, and moves the Task to Todo. That move starts the run.
6. Done means a person accepted the result. No Agent moves a Task
into a Completed status.
Menempatkan “Needs plan” dalam kategori Backlog adalah detail yang membuat langkah 5 aman: Task yang ditugaskan saat berada di Backlog akan menunggu, sehingga rencana dapat dibaca sebelum eksekusi dimulai. Sebutkan secara jelas dalam instruksi Planner ke mana rencana tersebut dikirimkan, dan uji dengan Run now sebelum memercayai pemicunya. Saat Agent memerlukan keputusan di tengah proses eksekusi, Task akan menampilkan status menunggu balasan manusia dan masuk ke Inbox orang yang bertanggung jawab, yang merupakan titik di mana bagian “bahkan saat Anda sedang tidak di tempat” kembali ke kendali manusia. Task adalah tempat di mana permintaan obrolan grup berubah menjadi pekerjaan yang dapat dilacak, dan hal yang sama juga berlaku untuk issue GitHub yang ditugaskan ke agen AI.
Peran pemantau ChatGPT yang tepat
Gunakan langganan MCP Events ketika seseorang menginginkan pemberitahuan awal dan draf pertama di obrolan pribadi mereka: papan yang Anda pantau tetapi tidak Anda kelola, pelacak milik mitra kerja, atau ringkasan hari Jumat untuk diri Anda sendiri. Gunakan team tasks ketika pekerjaan berulang tersebut berupa pembaruan tim yang terpusat di ChatGPT dan tim Anda menggunakan paket Business atau Enterprise, karena rekan satu tim dapat bersama-sama menyempurnakan satu set instruksi alih-alih masing-masing menulis versinya sendiri. Gunakan aturan di sisi papan proyek ketika event tersebut menghasilkan pekerjaan yang harus dimiliki oleh tim: rencana yang akan dieksekusi seseorang, perbaikan yang akan ditinjau seseorang, atau Task yang harus masuk dalam perhitungan metrik hari Senin.
Agen AI berbasis event hanya akan sebaik aturan yang menentukan agen mana yang menanggapi. Event hanyalah jalur perpipaan (plumbing); perutean, kepemilikan, dan peninjauan adalah urusan manajemen, dan semua itu menjadi bagian dari papan proyek tempat setiap agen melapor, siapa pun vendor pembuatnya. Untuk memutuskan apa yang harus dikerjakan agen selanjutnya setelah antrean terisi, lihat manajemen dan triase backlog AI. Dots, peluncuran pertama dalam rangkuman OpenAI, mengangkat pertanyaan serupa dari sudut pandang agen.
Jika Anda sudah menjalankan beberapa agen, Sharkly memberi Anda satu tempat untuk mengelola tugas dan hasil kerja mereka.
Sumber daya tambahan
- Sharkly Automations: empat jenis pemicu, riwayat eksekusi, dan batasan otomatisasi
- Dari obrolan grup menjadi tugas kode yang dapat dilacak: mengubah pesan menjadi pekerjaan yang memiliki penanggung jawab
- Manajemen dan triase backlog AI: menentukan apa yang dikerjakan agen selanjutnya
- Menugaskan issue GitHub ke agen AI: dari issue menjadi pull request yang siap ditinjau
- Agen pengodean saat Anda tidak di tempat: eksekusi tanpa pengawasan dan antrean peninjauan
- OpenAI dots dijelaskan: agen pribadi yang selalu aktif, dan apa saja yang masih dibutuhkan tim di sekitarnya
