Draf berubah setelah kamu setujui. Bolehkah agen tetap menerbitkannya?

Kamu tentu ingin persetujuanmu berlaku untuk draf yang benar-benar kamu baca. Bayangkan agen menyiapkan draf, editor menyetujuinya, lalu proses otomatis mengganti angka sebelum diterbitkan. Catatan ya atau tidak, yang disebut boolean approved, belum bisa menjawab apakah versi baru itu sudah disetujui.

Serah terima pekerjaan antara manusia dan agen disebut handoff. LangGraph memberi contoh cara menjeda proses untuk menunggu masukan melalui interrupts. Ada juga penyimpanan keadaan kerja, atau persistence, supaya proses bisa dilanjutkan kemudian.

Titik keadaan yang disimpan biasa disebut checkpoint, sedangkan melanjutkannya disebut resume. Kita akan memakai gagasan itu untuk merancang alur serah terima redaksi. Rancangan ini tidak bergantung pada kerangka pemrograman tertentu.

Tunjukkan dengan jelas apa yang akan disetujui

Permintaan menyetujui “hasil agen” perlu disertai hasil yang sudah jelas. Tampilkan judul, isi, sumber, berkas pendukung, tujuan pengiriman, dan tindakan berikutnya. Jika pekerjaannya mengirim pesan, sertakan penerima dan lampirannya.

Simpan penanda pekerjaan job_id, revisi hasil, revisi sumber, dan statusnya. Kalau sumber berubah sementara teks masih sama, editor tetap perlu menilai apakah hasil lama masih sesuai. Aturan tim bisa menentukan bagian yang harus diperiksa ulang.

Kesepakatan data pekerjaan bisa dicatat seperti contoh berikut. Isinya menjelaskan revisi dan tindakan yang menunggu pemeriksaan:

{
  "job_id": "PUB-042",
  "state": "waiting_review",
  "output_revision": 3,
  "source_revisions": ["S01:r7", "S02:r2"],
  "action": "publish_article",
  "destination": "website",
  "review_deadline": "2026-10-24T00:00:00+00:00"
}

Data tadi adalah contoh catatan aplikasi fiktif, tanpa klaim sebagai isi permintaan resmi LangGraph. Nama publish_article belum menjalankan penerbitan. Pelaksana tindakan tetap membutuhkan izin dan pemeriksaan status.

Tentukan perpindahan status yang boleh terjadi

Aturan tentang status dan perpindahannya disebut state machine. Tulis alurnya dengan jelas, misalnya drafting → waiting_review → approved → executing → completed. Jalur lain bisa menuju revision_requested, rejected, atau expired; tentukan perpindahan mana yang boleh dilakukan setiap peran.

Perubahan hasil saat waiting_review perlu membuat revisi baru. Kalau hasil berubah setelah approved, batalkan persetujuan lama dan kembalikan ke pemeriksaan sesuai aturan tim. Status seperti approved_but_maybe_changed menyisakan keraguan tentang apa yang sebenarnya disetujui.

Pisahkan status seluruh pekerjaan dari status setiap tindakannya. Artikel bisa sudah terbit ketika pembuatan versi surel berkala, atau newsletter, masih gagal. Satu status untuk seluruh kampanye menyulitkan pemulihan tanpa mengulang langkah yang sudah selesai.

Cocokkan persetujuan dengan sidik isi

Penanda yang dihitung dari isi bisa dipakai sebagai sidik isi, atau fingerprint. Hasil hitungannya juga disebut digest. Contoh Python berikut membuat digest dari objek data yang sudah sesuai aturan aplikasi:

import hashlib
import json


def review_digest(payload):
    encoded = json.dumps(payload, sort_keys=True, separators=(",", ":"),
                         ensure_ascii=False, allow_nan=False).encode("utf-8")
    return hashlib.sha256(encoded).hexdigest()


def approval_matches(payload, approval):
    return (approval["decision"] == "approve"
            and approval["job_id"] == payload["job_id"]
            and approval["digest"] == review_digest(payload))

Cara mengubah objek menjadi teks, atau serializer, di contoh ini mengikuti aturan aplikasi Python sendiri. Kode itu belum menerapkan standar penulisan JSON yang seragam lintas bahasa, atau canonical JSON. Bila beberapa bahasa perlu menghasilkan sidik isi yang sama, sepakati aturan penyeragamannya atau hitung sidik dari isi mentah berkas akhir yang disimpan.

Isi yang dihitung harus sama antara layar pemeriksaan dan pelaksana tindakan. Digest juga belum membuktikan siapa yang memberi persetujuan dan tidak berfungsi sebagai tanda tangan. Ambil approval dari penyimpanan server setelah identitas diperiksa, peran dicocokkan, dan waktunya dicatat.

Sebelum melanjutkan, periksa juga batas waktu persetujuan, pencabutannya, dan status pekerjaan. Kecocokan sidik isi saja belum menyelesaikan pemeriksaan itu.

Melanjutkan proses bisa menjalankan ulang sebagian kode

Dokumentasi interrupts menjelaskan bahwa awal suatu langkah, atau node, bisa dijalankan lagi ketika proses dilanjutkan. Kalau pengiriman surel diletakkan sebelum titik jeda, pengiriman itu dapat terulang. Rancang tindakan agar pengulangan tetap memberi satu dampak yang sama, atau idempoten.

Pisahkan penyiapan data, permintaan pemeriksaan, dan tindakan yang mengubah sesuatu. Simpan hasil langkah yang mahal atau berdampak ke luar dengan penanda operasi. Saat proses dilanjutkan, baca hasil tersimpan itu daripada menganggap semua kode hanya dijalankan sekali.

Bila ada beberapa proses pekerja, pembaruan status perlu berlaku sebagai satu langkah utuh, atau atomik. Dua permintaan melanjutkan pekerjaan yang datang bersamaan tidak boleh sama-sama mengubah status menjadi executing. Periksa revisi yang diharapkan saat memperbarui; bila berbeda, tampilkan benturannya dan baca keadaan terbaru.

Bantu editor melihat perubahan sejak pemeriksaan terakhir

Saat editor kembali setelah beberapa jam, tampilkan perbandingan isi atau diff, sumber yang berubah, dan alasan pekerjaan menunggu. Dengan begitu, ia tahu keputusan yang dibutuhkan tanpa membaca ulang semua riwayat alat bantu. Informasi berikut bisa kamu sertakan:

Ringkasan perubahan dari agen bisa membantu, asalkan ada tautan ke diff atau bukti yang bisa dibuka. Editor tetap perlu akses ke isi yang sebenarnya untuk mengambil keputusan.

Uji apa yang terjadi ketika persetujuan tidak lagi cocok

Coba kasus editor menyetujui versi 3 ketika versi 4 sudah aktif, persetujuan kedaluwarsa, dan dua permintaan melanjutkan proses datang bersamaan. Uji juga proses yang mati setelah tindakan berhasil tetapi sebelum status disimpan, serta sumber yang dicabut setelah pemeriksaan. Tulis hasil yang diharapkan untuk setiap kasus.

Ketika keadaan kerja lama masih sah, pengguna perlu bisa melanjutkan tanpa membuat pekerjaan baru. Kalau isi yang diperiksa sudah berubah, proses tidak boleh memaksakan persetujuan lama. Pemulihan perlu mempertahankan hasil kerja yang benar sambil menolak keputusan yang sudah tidak berlaku.

Tambahkan satu latihan ketika editor kehilangan hak akses setelah menyetujui. Pelaksana tindakan perlu memeriksa ulang kewenangan keputusan itu menurut aturan aplikasi. Simpan alasan penolakan dan jejak keputusan lama agar pemeriksaan catatan bisa membedakan persetujuan yang pernah sah dari tindakan yang kini tidak diizinkan.

Untuk dampak tindakan dan percobaan kirim ulang, baca antrean, pencegahan tindakan ganda, dan penyimpanan kiriman. Untuk kebiasaan sehari-hari, panduan bekerja dengan agen pemrograman menjelaskan cara menyiapkan kesepakatan tugas dan bukti tes sebelum serah terima.