Sebelum vs Sesudah JEV: Mengukur Dampak Typed Decision pada AI Agent

AI agent sering terlihat sederhana dari luar: pengguna memberikan instruksi, agent berpikir, lalu sistem menjalankan action. Namun di dalam workflow sebenarnya terdapat banyak keputusan kecil yang harus dibuat secara konsisten.

Apakah transaksi perlu dikirim atau diambil sendiri? Metode pembayaran apa yang tersedia? Apakah pembatalan masih boleh dilakukan? Apakah sebuah klaim perlu diteruskan ke manusia? Cabang mana yang harus digunakan? Apakah agent boleh menjalankan sebuah tool?

Pertanyaan-pertanyaan tersebut tidak selalu membutuhkan reasoning panjang dari LLM. Banyak di antaranya adalah typed decision: keputusan dengan pilihan, skor, atau probabilitas yang bentuk output-nya sudah ditentukan.

Di sinilah JEV dari TypeSafe.ai menjadi menarik.

Artikel ini menggunakan pendekatan before vs after untuk melihat dampak praktis JEV pada workflow AI agent. Fokusnya bukan sekadar “JEV bisa melakukan apa”, tetapi pertanyaan yang jauh lebih berguna bagi engineer dan IT manager:

Apa yang benar-benar berubah setelah decision layer seperti JEV dimasukkan ke dalam workflow?

Catatan metodologi: angka before/after dalam artikel ini berasal dari skenario pada ilustrasi yang menjadi studi kasus. Angka tersebut berguna untuk melihat potensi dampak operasional, tetapi belum merupakan hasil eksperimen production dengan sample size dan statistical test.

JEV dalam satu kalimat

JEV adalah decision layer yang memungkinkan AI menghasilkan keputusan terstruktur—misalnya memilih, memberi skor, atau menghasilkan probabilitas—yang kemudian dapat langsung digunakan oleh software.

Jika Claude digunakan untuk reasoning, planning, generation, dan penggunaan tools, JEV dapat ditempatkan pada titik workflow yang membutuhkan keputusan kecil, terukur, dan memiliki bentuk output yang jelas.

Secara sederhana:

Claude
reasoning + planning + generation
          ↓
JEV
typed decision + probability
          ↓
Application
policy + execution + state

Pembagian ini penting karena tidak semua masalah software membutuhkan LLM generatif.

Dari LLM generatif ke typed decision

Workflow AI tradisional sering terlihat seperti:

Prompt
  ↓
LLM
  ↓
Text / JSON
  ↓
Parse
  ↓
Validate
  ↓
Retry
  ↓
Execute

Untuk banyak pekerjaan, pola tersebut masuk akal.

Namun ada kelas keputusan yang jauh lebih sederhana.

Misalnya aplikasi hanya membutuhkan jawaban:

Apakah klaim ini perlu diteruskan ke human reviewer?
YES / NO

Atau:

Pilih cabang:
A / B / C

Atau:

Berikan skor risiko:
0–100

Inilah wilayah yang cocok dengan konsep typed decision.

Dengan JEV, bentuk keputusan dapat didefinisikan terlebih dahulu. Sistem kemudian memperoleh hasil yang sesuai dengan tipe tersebut.

Contoh konseptual:

claim_requires_review = Noul(...)
selected_branch = Choice(...)
risk_score = Score(...)

Yang menarik bukan hanya format output-nya.

Keputusan tersebut dapat menjadi bagian dari program:

JEV decision
      ↓
business policy
      ↓
execute / review / reject

Dengan demikian AI tidak harus memegang seluruh kendali workflow.

Studi kasus: workflow toko ↔ pembeli

Ilustrasi yang menjadi dasar artikel memperlihatkan enam skenario transaksi:

1. Diantar + transfer
2. Ambil + bayar tunai
3. Uang muka
4. Batal setelah siap diambil
5. Klaim ditolak
6. Pesanan untuk cabang lain

Di dalam ilustrasi tersebut terdapat perbandingan kondisi “Sekarang” dan “Sasaran”, serta pilihan JEV untuk masing-masing skenario.

Kita dapat menggunakannya sebagai studi kasus untuk melihat tiga jenis dampak:

• efficiency — apakah langkah menjadi lebih sedikit;
• control — apakah state dan keputusan menjadi lebih terkontrol;
• experience — apakah pengguna memperoleh informasi dan interaksi yang lebih baik.

1. Diantar + transfer: perubahan kecil yang dapat terakumulasi

Pada skenario ini:

Sebelum

• 10–12 ketukan
• 3 pesan WhatsApp

Sesudah

• 9 ketukan
• 2 pesan WhatsApp

Jika range 10–12 menggunakan midpoint, baseline-nya adalah 11 ketukan.

11 → 9

Pengurangannya sekitar 18%.

Untuk pesan WhatsApp:

3 → 2

atau sekitar 33% lebih sedikit komunikasi eksternal.

Namun kita tidak boleh langsung mengatakan bahwa workflow menjadi 18% lebih cepat.

Satu ketukan UI dan satu pesan WhatsApp memiliki cost yang sangat berbeda.

Satu ketukan mungkin hanya membutuhkan satu detik.

Satu pesan WhatsApp bisa berarti:

1. membuka aplikasi;
2. membaca pesan;
3. memahami konteks;
4. mengetik jawaban;
5. menunggu respons;
6. kembali ke workflow.

Karena itu, pengurangan komunikasi eksternal bisa memiliki dampak yang lebih besar daripada yang terlihat dari click count.

Apa yang sebenarnya menarik dari JEV?

JEV dapat membantu agent memilih jalur transaksi yang sesuai sehingga pengguna tidak perlu melewati percabangan yang tidak relevan.

Konsepnya:

User intent
    ↓
Claude memahami konteks
    ↓
JEV memilih decision path
    ↓
Application menjalankan workflow

JEV bukan sekadar mengurangi tombol.

Ia membantu mengubah reasoning menjadi state transition yang dapat dieksekusi.

2. Ambil + bayar tunai: satu langkah terlihat kecil

Skenario kedua:

Sebelum: 7 ketukan

Sesudah: 6 ketukan

Pengurangan:

7 → 6

atau sekitar 14%.

Pada satu transaksi, satu ketukan mungkin terasa tidak signifikan.

Tetapi software tidak melayani satu transaksi.

Misalnya secara hipotetis ada 10.000 transaksi dengan workflow yang sama:

10.000 transaksi
× 1 ketukan
= 10.000 interaksi yang dihilangkan

Itu belum berarti 10.000 detik yang dihemat karena waktu per ketukan berbeda-beda.

Tetapi ilustrasi ini menunjukkan prinsip penting:

Optimasi kecil menjadi menarik ketika terjadi pada workflow yang sangat sering.

Karena itu evaluasi JEV harus mempertimbangkan volume.

Metrik yang lebih berguna:

• interaction per transaction;
• completion time;
• abandonment;
• error;
• retry;
• support contact.

Bukan hanya “berapa tombol yang hilang”.

3. Uang muka: bukan sekadar satu ketukan lebih sedikit

Pada workflow uang muka:

Sebelum

• 13 ketukan;
• pembeli mengetik sendiri nominal uang muka.

Sesudah

• 12 ketukan;
• tombol “Bayar uang muka Rp D” sudah terisi.

Jika hanya menghitung ketukan:

13 → 12

atau sekitar 8%.

Tidak spektakuler.

Namun justru di sini kita dapat melihat mengapa click count bukan satu-satunya KPI.

Sebelum:

System → tampilkan nominal
User → baca
User → ketik nominal
System → validasi

Sesudah:

System → hitung nominal
System → isi nominal
User → konfirmasi

Workflow kedua mengurangi manual data entry.

Konsekuensinya bisa berupa:

• lebih sedikit typo;
• lebih sedikit correction;
• lebih sedikit validation error;
• lebih sedikit beban kognitif;
• lebih sedikit peluang pengguna memasukkan nominal yang salah.

Jadi manfaat JEV dapat muncul sebagai error prevention, bukan hanya speed.

4. Batal setelah siap diambil: contoh impact terbesar

Di antara enam skenario, ini adalah perubahan yang paling mencolok.

Sebelum: 8–10 ketukan.

Sesudah: 4 ketukan.

Jika midpoint 8–10 digunakan:

9 → 4

Pengurangan sekitar 56%.

Ini bukan lagi optimasi satu tombol.

Workflow-nya hampir terpotong setengah.

Mengapa decision layer bisa sangat membantu di sini?

Karena cancellation merupakan state transition yang mempunyai kondisi.

Misalnya:

ORDERED
   ↓
PREPARING
   ↓
READY_FOR_PICKUP
   ↓
CANCELLATION_REQUEST

Pada titik tersebut sistem harus menentukan:

• apakah pembatalan masih diperbolehkan;
• apakah barang sudah diproses;
• apakah ada biaya pembatalan;
• apakah merchant perlu dilibatkan;
• apakah kasus perlu human review.

Daripada memaksa pengguna menjawab semua pertanyaan tersebut satu per satu, agent dapat mengumpulkan context dan decision layer menentukan jalur yang relevan.

Secara konseptual:

Cancellation request
        ↓
       JEV
        ↓
┌───────┼────────┐
│       │        │
allow  review   reject
│       │        │
↓       ↓        ↓
auto   human    explain
process review  reason

Di sini JEV berfungsi sebagai decision gate.

Nilai JEV bukan karena agent membuat lebih banyak keputusan, tetapi karena agent dapat menghilangkan langkah yang tidak perlu ketika keputusan sudah dapat ditentukan.

5. Klaim ditolak: efisiensi bukan satu-satunya ukuran

Skenario klaim memiliki perubahan yang berbeda.

Sebelum:

pembeli tidak diberi tahu.

Sesudah:

alasan penolakan sampai ke pembeli.

Ilustrasi menunjukkan pilihan JEV sebesar 73%.

Namun angka tersebut tidak boleh langsung disebut sebagai akurasi 73% tanpa mengetahui definisi metriknya.

Ada perbedaan antara:

• confidence;
• probability;
• approval rate;
• decision rate;
• accuracy.

Ini penting dalam setiap implementasi AI.

Pipeline yang lebih baik

Sebuah workflow dapat dipisahkan menjadi:

Claim data
    ↓
JEV decision
    ↓
Business policy
    ↓
Approve / Reject / Review
    ↓
Claude generates explanation
    ↓
Customer

JEV menentukan keputusan terstruktur.

Claude membantu mengubah keputusan dan context menjadi penjelasan yang mudah dipahami.

Application mengubah keputusan tersebut menjadi state transaksi.

Dengan pembagian seperti ini, reasoning, decision, dan execution tidak bercampur menjadi satu prompt raksasa.

6. Pesanan untuk cabang lain: control lebih penting daripada speed

Skenario terakhir menunjukkan:

Sebelum

• staf cabang lain ikut mendapat lonceng/notifikasi;
• cabang dapat berganti secara diam-diam.

Sesudah

• lonceng dan daftar dipisahkan per cabang;
• cabang pilihan pembeli dikunci.

Perubahan ini mungkin tidak menghasilkan pengurangan latency yang besar.

Tetapi dampaknya berada pada control.

Misalnya keputusan cabang dapat dimodelkan:

selected_branch = Choice(
    branch_A,
    branch_B,
    branch_C
)

Kemudian application policy menerapkan:

selected_branch
      ↓
lock branch
      ↓
filter notifications
      ↓
route order

Dengan demikian decision yang sebelumnya implisit menjadi state yang eksplisit.

Ini merupakan salah satu keuntungan typed decision yang sering luput dari diskusi AI:

Keputusan AI dapat dibuat menjadi bagian dari state machine aplikasi.

Before vs After: ringkasan

Angka persentase di atas adalah estimasi dari skenario ilustratif. Untuk range, midpoint digunakan sebagai pendekatan.

Karena itu tabel ini sebaiknya dibaca sebagai:

“Apa potensi perubahan workflow?”

bukan:

“Berapa persen JEV pasti meningkatkan performa production?”

Apakah manfaat JEV signifikan?

Pertanyaan ini sebenarnya memiliki dua jawaban.

Signifikan secara operasional?

Pada beberapa skenario, potensinya terlihat cukup jelas.

Contoh paling kuat adalah:

Batal setelah siap
8–10 → 4 ketukan

Dengan midpoint, sekitar 56% interaksi dapat hilang.

Selain itu ada perubahan yang tidak tercermin dalam jumlah klik:

• manual data entry berkurang;
• komunikasi eksternal berkurang;
• branch selection lebih terkontrol;
• alasan rejection dapat dikomunikasikan;
• workflow dapat langsung diarahkan ke state yang relevan.

Jadi jika definisi “signifikan” adalah cukup besar untuk memberikan alasan melakukan eksperimen production, maka beberapa skenario layak diuji lebih lanjut.

Signifikan secara statistik?

Belum dapat disimpulkan dari ilustrasi.

Untuk menyebut suatu improvement statistically significant, kita membutuhkan data observasi yang cukup dan metode analisis yang tepat.

Minimal:

• jumlah transaksi;
• control group;
• treatment/JEV group;
• completion time;
• interaction count;
• error rate;
• abandonment;
• decision accuracy;
• human override;
• business outcome.

Kemudian kita dapat menghitung confidence interval dan melakukan statistical test sesuai karakter data.

Dengan kata lain:

Illustration
    ↓
hypothesis
    ↓
production experiment
    ↓
measurement
    ↓
statistical analysis
    ↓
conclusion

Jangan melompati empat langkah terakhir.

Mengapa click count saja tidak cukup?

Ini mungkin pelajaran paling penting dari studi kasus ini.

Misalnya:

Workflow A
13 → 12 clicks

dan:

Workflow B
3 → 2 WhatsApp messages

Secara numerik, masing-masing hanya berkurang satu.

Tetapi cost-nya belum tentu sama.

Kita dapat memodelkan secara konseptual:

Total user effort
=
UI interaction cost
+
typing cost
+
context switching
+
waiting
+
decision effort

Maka mengurangi satu field input bisa lebih berharga daripada mengurangi dua tombol.

Begitu pula menghilangkan satu komunikasi eksternal dapat memiliki impact lebih besar daripada beberapa click UI.

Karena itu dashboard evaluasi JEV sebaiknya tidak hanya memiliki:

clicks_before
clicks_after

tetapi juga:

completion_time
typing_time
external_messages
context_switches
abandonment
errors
retries

Confidence JEV bukan accuracy

Ini juga wajib dipahami sebelum membawa JEV ke production.

Misalnya:

JEV:
approve = 0.98

Angka tersebut tidak otomatis berarti:

“Keputusan ini benar 98%.”

Confidence/probability perlu diuji terhadap hasil aktual.

Jika sekumpulan keputusan diberi probability 0.90, kita ingin melihat apakah sekitar 90% dari keputusan tersebut memang benar pada kondisi evaluasi yang relevan.

Itulah inti calibration.

Production workflow dapat menerapkan threshold:

             JEV
              │
       probability
              │
      ┌───────┼────────┐
      ↓       ↓        ↓
    High    Medium     Low
      │       │         │
    Auto    Review     Fallback
   action   human

Threshold harus ditentukan dari data.

Contohnya bukan berarti:

>= 0.90 = selalu aman

Tetapi:

“Pada dataset dan cost structure kita, threshold X memberikan trade-off false positive/false negative yang dapat diterima.”

JEV + Claude: pembagian kerja yang masuk akal

JEV menjadi semakin menarik ketika ditempatkan bersama LLM seperti Claude.

Bukan:

Claude vs JEV

melainkan:

Claude + JEV

Arsitektur sederhananya:

                    User
                     │
                     ▼
               Claude Agent
          reasoning + planning
                     │
                     ▼
                    JEV
          typed decision + confidence
                     │
                     ▼
              Business Policy
                     │
              ┌──────┴──────┐
              ▼             ▼
           Execute      Human Review
              │
              ▼
             State

Claude cocok untuk

• memahami requirement;
• reasoning;
• planning;
• menghasilkan kode;
• menjelaskan keputusan;
• eksplorasi context;
• penggunaan tools;
• iterasi.

JEV cocok untuk

• Choice;
• Score;
• probabilistic yes/no;
• classification;
• routing;
• verification;
• risk signal;
• decision gating.

Application cocok untuk

• authentication;
• authorization;
• transaction state;
• business policy;
• database mutation;
• execution;
• audit trail.

Prinsip sederhananya:

Claude berpikir. JEV memutuskan. Kode menegakkan aturan.

Cara membuktikan manfaat JEV di production

Jika ingin benar-benar mengetahui apakah JEV memberikan manfaat, jangan berhenti pada demo.

Buat eksperimen.

Control vs JEV

                 Users
                   │
          ┌────────┴────────┐
          │                 │
       Control            JEV
     workflow lama    workflow baru
          │                 │
          └────────┬────────┘
                   ↓
               Compare
                   ↓
                 KPI

Metrik yang perlu dikumpulkan dapat dibagi menjadi empat kelompok.

Efficiency

• median completion time;
• p95 completion time;
• interaction count;
• typing effort;
• external messages;
• context switching.

Reliability

• error rate;
• retry rate;
• failed transition;
• invalid state;
• system fallback.

Decision quality

• decision accuracy;
• false positive;
• false negative;
• human override;
• escalation rate;
• calibration.

Business outcome

• abandonment;
• conversion;
• support ticket;
• operational cost;
• customer satisfaction.

Dengan data tersebut kita dapat menjawab pertanyaan yang jauh lebih bernilai:

“Pada workflow mana JEV memberikan impact terbesar, dengan biaya dan risiko berapa?”

Kapan JEV layak digunakan?

JEV paling menarik ketika keputusan memiliki karakteristik berikut:

1. Sering terjadi.
2. Pilihannya relatif terbatas.
3. Output perlu terstruktur.
4. Decision point dapat didefinisikan dengan jelas.
5. Confidence berguna untuk menentukan langkah berikutnya.
6. Kesalahan dapat ditangani dengan policy atau human review.
7. Keputusan tersebut tidak membutuhkan reasoning terbuka yang panjang.

Contohnya:

• routing;
• triage;
• claim classification;
• approval gate;
• tool-call classification;
• context relevance;
• model selection;
• risk signal;
• workflow state decision.

Sebaliknya, JEV tidak perlu dipaksakan untuk pekerjaan seperti:

• menulis artikel;
• brainstorming;
• refactoring kompleks;
• merancang arsitektur dari nol;
• menjelaskan masalah teknis panjang;
• menghasilkan dokumentasi naratif.

Untuk pekerjaan tersebut, LLM generatif tetap lebih natural.

Empat lapisan manfaat JEV

Dari studi kasus ini, manfaat JEV dapat dikelompokkan menjadi empat lapisan.

1. UX

Pengguna dapat melewati langkah yang tidak diperlukan.

2. Operations

Pekerjaan manual dan komunikasi eksternal dapat berkurang.

3. Control

Decision point dan state transition menjadi lebih eksplisit.

4. AI architecture

Reasoning dan decision dipisahkan sehingga keduanya dapat dievaluasi secara berbeda.

Lapisan keempat sebenarnya sangat penting.

Jika semua keputusan berada di dalam prompt Claude, kita mungkin sulit mengetahui:

“Mengapa agent memilih cabang B?”

Dengan decision layer:

Claude context
      ↓
JEV decision
      ↓
probability
      ↓
policy
      ↓
state

Kita memiliki tempat yang lebih jelas untuk melakukan observability.

Summary

JEV bukan sekadar model AI tambahan. JEV dapat menjadi typed decision layer antara reasoning model dan application policy.

Studi before vs after pada workflow toko ↔ pembeli menunjukkan beberapa jenis perubahan:

• pengurangan jumlah interaksi;
• pengurangan komunikasi eksternal;
• pengurangan manual data entry;
• pengurangan langkah pada cancellation;
• peningkatan transparency pada claim rejection;
• peningkatan control pada branch routing.

Perubahan terbesar dalam contoh adalah cancellation workflow, dari 8–10 ketukan menjadi 4 ketukan. Dengan midpoint, itu sekitar 56% pengurangan interaksi.

Namun angka tersebut tetap merupakan skenario ilustratif, bukan hasil benchmark production.

Karena itu kesimpulannya harus dibedakan:

Secara operasional: ada indikasi yang cukup kuat untuk melakukan eksperimen lebih lanjut.

Secara statistik: belum dapat disimpulkan tanpa data eksperimen yang memadai.

Dan inilah mungkin pelajaran paling penting:

Jangan mengukur JEV hanya dari seberapa pintar keputusan AI. Ukur dari seberapa besar keputusan tersebut memperbaiki sistem.

Jika satu decision menghilangkan lima langkah, mengurangi input manual, menurunkan error, dan membuat state lebih deterministic, maka nilai JEV tidak lagi berada di level model.

Nilainya berada di level architecture.

Key Takeaways

• JEV berfungsi sebagai decision layer, bukan pengganti Claude.
• Typed decision membuat output AI lebih mudah dikonsumsi oleh software.
• Pengurangan klik tidak otomatis sama dengan pengurangan waktu.
• External communication dan manual data entry perlu dihitung terpisah.
• Cancellation workflow pada studi kasus menunjukkan perubahan terbesar.
• Confidence tidak sama dengan accuracy.
• Production membutuhkan threshold, fallback, human review, dan audit trail.
• Signifikansi operasional dapat diamati dari perubahan workflow.
• Signifikansi statistik membutuhkan eksperimen dan data.
• Arsitektur yang menarik adalah Claude → JEV → Policy → Execute/Review.
• Ukur outcome sistem, bukan hanya output model.