Graph-Based Agent Workflow: Nodes, State, Routing, Handoff, dan Approval

Agent sales menerima permintaan "tolong revisi proposal dan kirim setelah diskon disetujui". Ia menyusun draft, meminta persetujuan, lalu sesi berhenti. Ketika dijalankan lagi, agent tidak tahu apakah approval sudah diberikan, proposal mana yang aktif, dan apakah email sempat terkirim. Ia mulai ulang dari percakapan dan berisiko membuat action ganda.

Masalah ini bukan kekurangan prompt. Workflow tidak mempunyai state dan control flow yang cukup eksplisit.

Graph-based agent workflow adalah cara memodelkan proses sebagai kumpulan node yang membaca atau memperbarui state, serta edge yang menentukan jalur berikutnya. Node dapat berisi model call, code deterministic, tool, human review, atau side effect. Graph membuat branching, loop, parallel work, pause, resume, handoff, dan approval lebih mudah ditelusuri.

Istilah graph dan state machine mapan dalam computer science. Penerapannya untuk AI agent juga sudah tersedia di framework production, tetapi desainnya masih cepat berkembang. LangGraph menyebut dirinya orchestration framework dan runtime untuk long-running, stateful agents. Google ADK mendokumentasikan workflow sequential, parallel, dan loop, serta mengarahkan workflow baru di versi tertentu ke struktur graph-based dan dynamic.

Graph bukan syarat untuk menyebut sebuah sistem AI agent. Workflow tiga langkah dapat ditulis dengan function biasa. Graph mulai bernilai ketika jalur, state, interruption, atau audit tidak lagi mudah dikelola oleh code linear.

Mental model: nodes bekerja, edges memilih langkah berikutnya

Dokumentasi LangGraph Graph API merangkum tiga komponen:

1. State: snapshot data aplikasi saat ini.
2. Nodes: function yang menerima state, melakukan komputasi atau side effect, lalu mengembalikan update.
3. Edges: transition yang menentukan node berikutnya berdasarkan state.

Node tidak selalu agent. Ini keputusan penting.

validate_invoice seharusnya code deterministic. classify_customer_intent mungkin model call. wait_for_approval adalah pause. send_invoice adalah side effect terkontrol. Menjadikan setiap node sebagai LLM agent hanya menambah nondeterminism.

Graph juga bukan diagram organisasi. Node finance tidak harus berarti ada "finance agent" dengan persona lengkap. Ia dapat berarti rangkaian validator dan satu human approval dari finance.

Hubungan dengan lapisan lain:

• harness menjadi shell environment, tools, policy, checkpoint, dan proof;
• graph mengatur topology dan control flow;
• loop muncul sebagai cycle atau iterasi lokal;
• setiap node model merakit context dan prompt yang sesuai.

Baca peta lengkapnya di Lima Lapisan Engineering AI Agent. Batas environment dan proof ada di Harness Engineering untuk AI Agent; kontrak instruksi pada model node ada di Prompt Engineering 2026; cycle dan termination dibahas di Loop Engineering.

Kapan graph memberi nilai

Gunakan graph ketika proses mempunyai satu atau beberapa karakteristik ini:

• lebih dari satu route yang bermakna;
• parallel branch dengan hasil yang harus digabung;
• task berjalan lama atau menunggu pihak eksternal;
• checkpoint dan resume dibutuhkan;
• human approval berada di tengah proses;
• failure correction mempunyai jalur berbeda dari retry teknis;
• beberapa fungsi atau agent melakukan handoff;
• audit perlu mengetahui node dan transition yang dilewati;
• side effect harus dipisahkan dari perencanaan;
• workflow version perlu dipertahankan saat task lama dilanjutkan.

Jangan memakai graph hanya karena visualnya menarik. Jika flow selalu input -> model -> validator -> output, function biasa lebih mudah dibaca dan dites.

Pattern yang sehat adalah mulai linear, catat branching yang muncul dari kasus nyata, lalu formalisasikan ketika complexity sudah nyata.

State: posisi kerja, bukan tumpukan pesan

State menjawab: pekerjaan sedang berada di mana dan apa yang sudah terjadi?

State bukan seluruh chat. Message history mungkin salah satu field, tetapi task state memerlukan struktur operasional.

Contoh state proposal:

{
 "taskId": "proposal-184",
 "workflowVersion": "4",
 "clientId": "client-a",
 "requestType": "revision",
 "activeProposalId": "prop-91-v3",
 "requirementsStatus": "complete",
 "discountPercent": 12,
 "policyVersion": "discount-2026-07",
 "approvalStatus": "pending",
 "approvalId": null,
 "deliveryStatus": "not_started",
 "retryCount": 0,
 "blocker": null
}

State yang baik memiliki beberapa sifat.

Typed

Field dan nilai terminal jelas. approvalStatus memakai enum, bukan kalimat bebas. Typed state mengurangi branch ambigu dan memudahkan migration.

Minimum tetapi cukup

Jangan menyalin seluruh dokumen ke state. Simpan artifact ID atau pointer. State memegang informasi yang dibutuhkan untuk routing, recovery, dan audit.

Versioned

Task panjang dapat melintasi perubahan workflow. Simpan workflow dan policy version. Tanpa itu, task lama dapat resume ke edge yang tidak lagi kompatibel.

Scoped

Tenant, user, project, dan permission tidak boleh tersirat dari chat. Scope menjadi field wajib dan diperiksa di boundary.

Provenance-aware

Keputusan atau data penting menunjuk sumber. Diskon 12% perlu proposal ID, approver, dan timestamp. Nilai tanpa asal sulit diverifikasi.

Recoverable

Checkpoint memungkinkan task dilanjutkan tanpa memutar ulang side effect. State harus menyimpan external identifiers dan status outcome yang belum pasti.

Untuk membedakan state dari informasi yang dilihat model dan memory lintas sesi, baca Context vs State vs Memory pada AI Agent.

State update dan reducer: hati-hati pada parallel branch

Ketika dua node berjalan paralel, keduanya dapat memperbarui state. Dibutuhkan aturan merge.

LangGraph mendokumentasikan reducer per state key. Tanpa reducer khusus, update dapat mengganti nilai sebelumnya; custom reducer dapat menggabungkan list atau struktur. Konsepnya umum: tim harus menentukan bagaimana concurrent update dipadukan.

Contoh workflow riset menjalankan dua branch:

• research_official_docs menghasilkan official_sources;
• research_existing_articles menghasilkan internal_links.

Keduanya aman karena menulis key berbeda. Masalah muncul jika dua branch menulis status atau findings dengan semantics berbeda.

Aturan praktis:

• hindari beberapa writer pada field terminal;
• gunakan key per branch lalu merge di node khusus;
• deduplicate berdasarkan stable ID;
• jangan mengandalkan urutan completion parallel;
• buat conflict state bila dua sumber berwenang berbeda;
• log update sebelum dan sesudah reducer.

Private state channel bukan otomatis private secara security. Dokumentasi framework dapat mempunyai perilaku streaming tertentu. Sensitive data perlu redaction dan access control di harness, bukan hanya schema input/output.

Node design: satu outcome yang dapat diuji

Node yang terlalu besar menyembunyikan failure. Node yang terlalu kecil membuat graph ramai tanpa nilai.

Boundary node yang baik biasanya berada pada salah satu titik ini:

• perubahan jenis kerja;
• perubahan authority;
• external side effect;
• checkpoint penting;
• human handoff;
• validation gate;
• parallelization boundary;
• kebutuhan prompt atau context yang berbeda.

Contoh node proposal:

validate_request
extract_requirements
retrieve_client_policy
build_proposal_draft
validate_claims
calculate_discount_route
wait_for_approval
apply_approved_change
render_preview
send_proposal
verify_delivery

build_proposal_draft dapat memakai model. calculate_discount_route memakai code. wait_for_approval menghentikan execution. send_proposal adalah tool write yang hanya menerima approval valid. verify_delivery membaca outcome.

Setiap node perlu contract:

• state fields yang boleh dibaca;
• state fields yang boleh ditulis;
• precondition;
• output atau postcondition;
• error categories;
• retry semantics;
• side effect;
• observability event;
• owner.

Node yang menerima seluruh state dan boleh menulis semua field membuat graph hanya terlihat terstruktur di diagram. Secara operasional ia tetap monolitik.

Edge dan routing: deterministic dulu, model bila perlu

Routing dapat ditentukan oleh code atau model.

Deterministic routing

Gunakan ketika branch berdasarkan data yang jelas:

if approval_status == "approved" -> execute
if approval_status == "rejected" -> revise
if amount > approval_limit -> wait_for_approval
if validation_errors not empty -> repair

Keuntungannya: dapat diaudit, dites exact match, dan tidak berubah karena wording.

Model-based routing

Gunakan ketika input natural language memang perlu interpretasi: intent support, kategori risiko kualitatif, atau pemilihan specialist berdasarkan isi. Model menghasilkan route enum terstruktur, bukan nama node bebas.

Lalu pasang:

• allowlist route;
• confidence atau ambiguity handling bila relevan;
• fallback unknown;
• eval boundary antar-route;
• deterministic policy override;
• trace input source dan prompt version.

Jangan meminta model menentukan route yang sebenarnya dapat dihitung dari threshold atau permission. Nondeterminism harus ditempatkan hanya pada bagian yang membutuhkan interpretasi.

Panduan OpenAI evaluation best practices secara khusus menyebut tool selection, argument precision, dan agent handoff accuracy sebagai area eval pada agent architecture. Routing bukan detail implementasi; ia permukaan risiko tersendiri.

Handoff: pindahkan tanggung jawab, bukan seluruh kekacauan

Handoff terjadi ketika satu node, agent, atau fungsi menyerahkan pekerjaan ke pihak lain. Kesalahan handoff sering datang dari context dump atau contract yang tidak lengkap.

Handoff payload minimum:

• task dan correlation ID;
• outcome yang diminta;
• state atau artifact yang sudah tervalidasi;
• scope tenant dan permission;
• keputusan yang sudah final;
• unresolved question atau blocker;
• deadline atau SLA jika ada;
• approval status;
• expected return contract;
• source pointers.

Jangan mengirim seluruh chat sebagai default. Penerima membutuhkan decision-relevant context, bukan semua percakapan.

Contoh handoff dari agent account ke finance:

{
 "taskId": "renewal-42",
 "clientId": "client-a",
 "request": "approve_discount",
 "proposalId": "prop-91-v3",
 "discountPercent": 12,
 "standardLimit": 10,
 "marginImpactArtifact": "calc-332",
 "requester": "account-team",
 "returnRoute": "apply_finance_decision"
}

Finance tidak perlu membaca seluruh proses drafting. Ia perlu melihat keputusan, bukti, dan batas authority.

Handoff juga perlu ownership. Siapa bertanggung jawab saat task pending? Apakah sender tetap owner sampai receiver menerima? Tanpa lifecycle tersebut, graph dapat mempunyai node tanpa operator.

Approval: node yang benar-benar menghentikan execution

Approval bukan pesan "please confirm" yang model boleh abaikan. Ia control point.

LangGraph interrupts mendokumentasikan pola pause: execution dihentikan, state disimpan melalui checkpointer, lalu dilanjutkan dengan thread ID yang sama. Saat resume, node tertentu dapat dijalankan kembali dari awal; akibatnya code sebelum interrupt harus aman atau diposisikan dengan hati-hati. Detail ini spesifik framework, tetapi memperlihatkan kenapa side effect dan approval tidak boleh dicampur sembarangan.

Approval node perlu memuat:

• action yang menunggu;
• before/after atau payload lengkap;
• artifact preview;
• source dan validation result;
• risiko;
• approver role;
• status pending/approved/rejected/expired;
• payload hash;
• expiry;
• comment atau edit.

Edge setelah approval:

approved -> revalidate -> execute
edited -> update_state -> validate -> approval_again
rejected -> close_or_revise
expired -> request_new_approval

Mengapa revalidate setelah approved? State eksternal dapat berubah saat menunggu. Stok, saldo, price, recipient, atau policy mungkin tidak sama. Approval berlaku pada payload tertentu, bukan izin permanen.

Tool write harus memeriksa approval token atau capability server-side. Graph UI saja bukan enforcement.

Parallel branch: percepat yang independen, jangan mem-paralelkan keputusan yang saling bergantung

Google ADK mendokumentasikan parallel workflow untuk sub-agent yang dapat berjalan bersamaan. Graph framework juga dapat melakukan fan-out dan fan-in.

Contoh aman:

• ambil metrik dari dua platform independen;
• periksa broken link dan lint bahasa secara paralel;
• lakukan beberapa retrieval source yang tidak bergantung;
• generate preview desktop dan mobile dari artifact yang sama.

Contoh buruk:

• menghitung diskon sebelum price version tervalidasi;
• mengirim laporan bersamaan dengan approval;
• dua node mengubah field state yang sama tanpa merge rule;
• membuat tiga agent memberi keputusan final dan memilih mayoritas tanpa ground truth.

Parallelism menambah concurrency, rate limit, conflict, dan observability complexity. Ukur latency bottleneck sebelum menambah fan-out.

Fan-in node harus menentukan:

• hasil mana yang wajib;
• bagaimana menangani satu branch gagal;
• conflict resolution;
• timeout;
• deduplication;
• status partial.

Loop dalam graph: cycle harus punya termination

Graph dapat kembali ke node sebelumnya: validation gagal ke repair, review ditolak ke revise, tool result kurang ke retrieval.

Setiap cycle perlu:

• alasan kembali;
• issue atau state yang harus berubah;
• attempt count;
• stall detection;
• max budget;
• escalation edge;
• proof saat keluar.

Contoh:

write_draft -> validate
validate(pass) -> approval
validate(fail, retryable) -> revise
validate(fail, no_progress) -> human_review
revise(attempt_exhausted) -> blocked

Jangan membuat edge failure -> start generik. Ia membuang state dan dapat mengulang side effect.

Pembahasan termination, retry, idempotency, dan recovery ada di Loop Engineering: Mendesain AI Agent Tanpa Infinite Loop.

Durable execution dan recovery

Graph menjadi bernilai ketika task dapat hidup lebih lama daripada satu process. Namun durable execution membutuhkan disiplin lebih dari menyimpan state JSON.

Checkpoint perlu dibuat pada transition penting. Simpan:

• graph dan workflow version;
• node aktif atau transition terakhir;
• input yang sudah tervalidasi;
• artifact IDs;
• tool call dan external IDs;
• side-effect status;
• retry count;
• approval state;
• deadline;
• terminal reason.

Saat resume, controller perlu melakukan reconciliation.

Skenario: send_proposal memanggil provider email, provider menerima, lalu process mati sebelum state berubah menjadi sent. Checkpoint masih menunjukkan sending. Jika graph langsung menjalankan node lagi, proposal terkirim dua kali.

Recovery path:

1. cari external request dengan idempotency key atau correlation ID;
2. jika sudah ada, simpan delivery ID dan lanjut ke verification;
3. jika tidak ada dan aman diulang, execute;
4. jika outcome tidak dapat dipastikan, pause untuk operator.

Persistence framework tidak otomatis membuat side effect idempotent. Itu tanggung jawab harness dan tool design.

Subgraph dan reusable workflow

Subgraph berguna untuk membungkus proses yang benar-benar berulang, misalnya:

• approval_subgraph;
• source_validation_subgraph;
• delivery_verification_subgraph;
• human_review_subgraph.

Tetapi abstraction dini menimbulkan contract generik yang sulit dipakai. Jangan membuat "universal approval graph" sebelum memahami perbedaan approval pembayaran, publish, dan pengiriman pesan.

Kandidat reusable harus memiliki invariant yang sama:

• state input/output serupa;
• risk tier serupa;
• approver semantics serupa;
• expiry dan payload binding serupa;
• audit requirement serupa.

Kalau hanya diagramnya mirip tetapi policy berbeda, code sharing dapat menyembunyikan risiko.

Fakta sumber, pattern industri, dan rekomendasi kami

Fakta sumber resmi: LangGraph mendokumentasikan state, nodes, edges, persistence, dan interrupts pada runtime-nya. Google ADK mendokumentasikan sequential, parallel, loop, serta graph-based workflow pada versi yang disebut. Fakta tersebut menunjukkan capability framework, bukan bukti bahwa graph selalu lebih baik daripada function biasa.

Pattern industri: typed state, deterministic routing untuk policy, checkpoint, payload-bound approval, dan pemisahan execute dari verify membantu workflow panjang menjadi lebih dapat diaudit. Setiap pattern tetap perlu diuji terhadap side effect dan failure mode lokal.

Rekomendasi Rama Digital: mulai linear, formalisasikan branch yang sudah muncul dari pekerjaan nyata, dan izinkan model memilih route hanya ketika interpretasi memang dibutuhkan. Ini pilihan desain operasional, bukan kewajiban memakai LangGraph, Google ADK, atau framework graph tertentu.

Workflow Rama Digital: project progress follow-up

Outcome: membaca update project pada topic yang tepat, menentukan gap, menyiapkan atau mengirim follow-up sesuai policy, lalu membuat ringkasan operasional tanpa duplikasi.

State

project_id
topic_id
window_start
window_end
messages_read
latest_status
blocker
pic
eta
last_followup_at
last_followup_hash
followup_route
approval_status
summary_artifact

Graph

START
 -> load_project_registry
 -> read_topic_context
 -> normalize_updates
 -> detect_gaps
 -> [no gap] write_summary
 -> [gap, duplicate] write_summary
 -> [gap, safe] draft_followup
 -> [blocker, sensitive] approval
 -> validate_topic_and_recipient
 -> send_followup
 -> verify_message
 -> write_summary
 -> END

Node responsibility

load_project_registry deterministic dan menjadi source of truth mapping project-topic. normalize_updates dapat memakai model dengan structured output. detect_gaps menggabungkan rule cadence dan interpretasi update. validate_topic_and_recipient deterministic. send_followup side effect. verify_message membaca message ID. write_summary menghasilkan artifact.

Routing

Kalau status, blocker, PIC, dan ETA sudah cukup, route no gap. Kalau follow-up serupa sudah dikirim dalam window, route duplicate. Jika terdapat gap biasa, buat pertanyaan spesifik. Jika menyangkut escalation sensitif, tunggu approval.

Handoff

Ringkasan operasional membawa project, gap, action, owner, dan next checkpoint. Ia tidak menyalin seluruh percakapan.

Proof

Follow-up dianggap terkirim hanya jika platform mengembalikan message ID pada topic yang benar dan read-back cocok. Summary dianggap selesai jika artifact ada dan merujuk action yang benar.

Contoh ini menunjukkan graph tidak harus menjadi multi-agent. Satu runtime dengan beberapa node deterministic dan model-driven sudah cukup.

Workflow kedua: artikel dari riset sampai draft

Outcome: draft tervalidasi, tidak publish.

START
 -> validate_brief
 -> research_primary_sources
 -> research_internal_links
 -> merge_research
 -> outline
 -> draft
 -> deterministic_checks
 -> [fail] revise
 -> [pass] editorial_review
 -> [review fail] revise
 -> [pass] finalize_draft
 -> END

research_primary_sources dan research_internal_links dapat paralel. merge_research menandai fakta, pattern, dan rekomendasi. deterministic_checks menghitung H1, word count, placeholder, JSON, dan link. editorial_review menilai tone serta klaim. Tidak ada node image, publish, atau deploy karena capability tersebut di luar scope.

Prompt per node dibahas di Prompt Engineering 2026. Harness path allowlist dan proof dibahas di Harness Engineering untuk AI Agent.

Failure modes graph

Graph spaghetti

Terlalu banyak edge silang, condition tersembunyi, dan node generik.

Perbaikan: kelompokkan subflow, gunakan typed route enum, hapus node tanpa boundary nyata, dan dokumentasikan terminal state.

Everything-is-an-agent

Validator, threshold, dan formatting dijalankan model.

Perbaikan: gunakan code deterministic untuk rule yang dapat diprogram. Model hanya pada interpretasi.

State sebagai dump

Seluruh message dan document masuk satu object. Setiap node membaca semuanya.

Perbaikan: typed state, artifact pointers, input projection per node, dan context builder.

Hidden side effect

Node bernama prepare_report ternyata juga mengirim email.

Perbaikan: satu node satu authority boundary; beri nama side effect secara eksplisit.

Route tanpa fallback

Model harus memilih satu specialist walau input ambigu.

Perbaikan: route unknown, ask clarification, atau human triage.

Handoff kehilangan keputusan

Receiver menerima ringkasan, tetapi tidak tahu policy version atau approval.

Perbaikan: schema handoff yang mencakup source, state final, blocker, dan expected return.

Handoff membawa terlalu banyak context

Seluruh histori diteruskan dan data tenant lain ikut masuk.

Perbaikan: projection, scope filter, provenance, dan least-context principle.

Approval tidak mengikat payload

Approver menyetujui draft A; agent mengeksekusi draft B setelah revisi.

Perbaikan: hash atau version binding; perubahan material kembali ke approval.

Resume mengulang side effect

Checkpoint berada sebelum state update dan write tidak idempotent.

Perbaikan: external ID, idempotency key, reconciliation node, serta failure injection test.

Parallel merge conflict

Dua branch menulis status berbeda.

Perbaikan: branch-local fields dan merge node dengan policy eksplisit.

Tidak ada terminal taxonomy

Semua jalur berakhir done, termasuk blocked dan rejected.

Perbaikan: completed, blocked, rejected, cancelled, failed, exhausted, dan unsafe sebagai status terpisah.

Eval graph: ukur node dan transition

End-to-end eval tetap perlu, tetapi debugging membutuhkan granularitas.

Node eval

• input contract valid;
• output schema valid;
• functional correctness;
• tool selection dan arguments;
• side effect sesuai authority;
• postcondition lulus.

Route eval

• expected edge untuk kasus normal;
• boundary dan ambiguous input;
• policy override;
• route unknown;
• no unauthorized path.

Handoff eval

• receiver tepat;
• payload lengkap tetapi minimum;
• source dan scope terjaga;
• expected return contract dipenuhi;
• no tenant leak.

Approval eval

• pause selalu terjadi untuk risk tier tertentu;
• action tidak dapat dieksekusi tanpa token valid;
• edit membatalkan approval lama;
• expiry bekerja;
• resume melakukan revalidation.

Recovery eval

• crash sebelum write;
• crash setelah write sebelum checkpoint;
• timeout dengan unknown outcome;
• workflow version berubah;
• duplicate event;
• branch parallel selesai dengan urutan berbeda.

Graph-level eval

• terminal state benar;
• path tidak terlalu panjang tanpa alasan;
• no infinite cycle;
• artifact dan proof tersedia;
• SLA dan budget sesuai target internal.

Jangan hanya menguji happy path. Nilai graph muncul justru saat pause, failure, dan perubahan state.

Observability graph

Trace perlu menampilkan:

• graph run ID dan workflow version;
• node start/end;
• input/output projection atau hash;
• state diff;
• edge yang dipilih serta reason code;
• tool call dan external correlation ID;
• approval event;
• checkpoint ID;
• retry dan loop count;
• artifact;
• terminal state.

State diff lebih berguna daripada dump state penuh untuk banyak incident. Namun sensitive field tetap perlu redaction. Operator harus dapat menjawab: node mana yang mengubah status, edge apa yang membawa task ke write, dan proof apa yang meloloskannya.

Checklist sebelum memilih graph framework

Workflow fit

• Apakah branching, pause, parallel work, atau recovery benar-benar ada?
• Apakah function linear sudah tidak cukup?
• Apakah graph mempermudah audit atau hanya menambah abstraction?

State

• Apakah schema typed, scoped, minimum, dan versioned?
• Apakah artifact besar disimpan sebagai pointer?
• Apakah concurrent update punya merge rule?
• Apakah terminal state dibedakan?

Nodes

• Apakah setiap node punya satu outcome dan authority boundary?
• Apakah rule deterministic tetap code?
• Apakah precondition, postcondition, dan retry semantics jelas?
• Apakah side effect terlihat dari nama dan contract?

Routing

• Apakah edge deterministic dipakai saat bisa?
• Apakah model route menghasilkan enum allowlist?
• Apakah fallback dan ambiguity tersedia?
• Apakah route punya eval cases?

Handoff dan approval

• Apakah payload handoff minimum tetapi lengkap?
• Apakah owner saat pending jelas?
• Apakah approval mem-pause runtime?
• Apakah approval terikat payload dan expiry?

Durability

• Apakah checkpoint dan workflow version disimpan?
• Apakah resume telah diuji saat crash?
• Apakah external write idempotent atau dapat direkonsiliasi?
• Apakah migration task lama direncanakan?

Framework

• Apakah framework mendukung persistence, interrupt, tracing, dan deployment yang dibutuhkan?
• Apakah tim dapat mengoperasikan dependency tersebut?
• Apakah state dan workflow tetap dapat diekspor?
• Apakah kebutuhan sederhana dipaksa mengikuti abstraction vendor?

Urutan implementasi yang tidak berlebihan

1. Tulis outcome, actor, risk, dan terminal states.
2. Implementasikan happy path linear.
3. Tandai boundary deterministic, model-driven, human, dan side effect.
4. Definisikan state schema serta artifact pointer.
5. Tambahkan branch dari kasus nyata, bukan kemungkinan imajiner.
6. Pisahkan write dan verification.
7. Pasang approval sebagai pause untuk action berisiko.
8. Tambahkan checkpoint dan reconciliation.
9. Buat eval per node, route, handoff, approval, dan recovery.
10. Baru pilih atau perdalam framework berdasarkan capability yang benar-benar diperlukan.

Urutan ini mencegah tim membangun orchestration platform sebelum mengetahui prosesnya.

Graph yang baik membuat control flow terlihat membosankan

Graph-based workflow tidak membuat model lebih pintar. Ia membuat posisi, jalur, authority, dan pause lebih eksplisit.

Nodes melakukan pekerjaan. State menyimpan posisi. Edges mengatur langkah berikutnya. Handoff memindahkan tanggung jawab dengan contract. Approval menghentikan execution sampai keputusan sah tersedia. Harness memastikan tool, permission, checkpoint, dan proof bekerja di dunia nyata.

Jika diagram terlihat canggih tetapi operator tidak dapat menjawab "task ini sedang di mana, siapa owner-nya, mengapa masuk jalur ini, dan apakah action sudah benar-benar terjadi?", graph tersebut belum menyelesaikan masalah operasional.