Loop Engineering: Mendesain AI Agent Tanpa Infinite Loop

Agent customer support memanggil lookup_order, menerima not_found, lalu memanggil tool yang sama dengan order ID yang sama. Hasilnya tetap not_found. Ia mengulangi langkah itu sampai batas waktu habis. Dari luar terlihat seperti agent sedang bekerja keras. Sebenarnya tidak ada progress.

Di workflow lain, agent memperbaiki draft berkali-kali. Setiap versi mengganti kata, tetapi acceptance criteria tetap gagal karena tanggal sumber tidak ada. Loop terus berjalan sebab sistem hanya punya max_steps, bukan definisi kemajuan.

Loop engineering adalah pekerjaan mendesain siklus observe-decide-act-verify pada AI agent, termasuk state kemajuan, feedback, retry, budget, recovery, dan kondisi berhenti. Tujuannya bukan membuat agent terus bergerak. Tujuannya membuat setiap iterasi mendekatkan pekerjaan ke hasil atau berhenti dengan status yang jujur.

Konsep loop sendiri mapan dalam software. Label loop engineering untuk AI agent masih emerging. Istilah ini berguna karena loop generatif membawa masalah yang berbeda dari for loop biasa: keputusan berikutnya dapat berubah, tool memiliki side effect, hasil tidak selalu deterministik, dan "selesai" perlu dibuktikan dari environment.

Bentuk dasar agent loop

Dokumentasi OpenAI function calling menjelaskan alur tool calling: aplikasi mengirim input dan tool definition, model menghasilkan tool call, aplikasi mengeksekusi tool, hasil dikirim kembali, lalu model memberi respons atau tool call lain. Itu sudah membentuk loop multi-step.

Secara sederhana:

observe state + context
 -> decide next action
 -> execute tool or model step
 -> capture result
 -> update state
 -> verify progress and termination
 -> continue, stop, or escalate

Bagian terakhir sering hilang. Implementasi hanya bertanya, "apakah model masih meminta tool?" Jika ya, loop dilanjutkan. Model akhirnya menjadi satu-satunya pihak yang menentukan apakah progress terjadi dan tugas selesai.

Untuk prototipe ringan, pola itu mungkin cukup. Untuk pekerjaan dengan biaya, external write, atau durasi panjang, termination harus dikendalikan aplikasi.

Loop dapat berjalan di satu node graph atau melintasi beberapa node. Harness menyediakan tools, permission, observability, dan proof. Prompt mengarahkan keputusan model; context memberi informasi yang dibutuhkan. Hubungan lengkapnya dibahas di Lima Lapisan Engineering AI Agent. Boundary environment, tools, dan proof dibahas di Harness Engineering untuk AI Agent, sedangkan posisi loop di antara node dibahas di Graph-Based Agent Workflow.

Bedakan loop, retry, workflow, dan graph

Empat istilah ini sering dicampur.

Loop mengulang rangkaian langkah berdasarkan state sampai kondisi tertentu terpenuhi.

Retry mengulang operasi yang sama setelah failure yang dianggap sementara. Retry adalah salah satu perilaku di dalam loop, bukan sinonim loop.

Workflow adalah keseluruhan prosedur dari input sampai outcome. Workflow dapat linear tanpa loop, atau mempunyai beberapa loop lokal.

Graph adalah representasi control flow melalui node dan edge. Graph dapat mengandung cycle, tetapi tidak semua graph harus cyclic. Sequential graph sederhana tidak mempunyai loop.

Google ADK mendokumentasikan workflow agents untuk pola sequential, parallel, dan loop. Loop Agent mengulang sub-agent sampai termination condition. Primitive tersebut berguna, tetapi framework tidak dapat menentukan sendiri apa arti progress bagi bisnis Anda.

Contoh: laporan iklan boleh mengulang pengambilan data bila API timeout. Ia tidak boleh mengulang selamanya ketika account ID tidak ditemukan. Keduanya sama-sama failure tool, tetapi keputusan loop berbeda.

Lima pertanyaan yang harus dijawab sebelum membuat loop

1. Apa unit satu iterasi?

Satu iterasi dapat berarti satu model call, satu tool call, satu putaran draft-review, atau satu siklus lengkap plan-act-observe. Definisi yang kabur membuat metric dan budget tidak konsisten.

2. Apa state yang berubah?

Jika aplikasi hanya menyimpan chat, ia sulit membedakan progress dari pengulangan. State perlu memuat langkah aktif, artifact, failure category, attempt, tool signature, approval, dan score gate yang relevan.

3. Apa indikator progress?

Progress bukan jumlah token atau tool call. Contohnya: satu validation error terselesaikan, jumlah field kosong turun, test failure berubah menjadi pass, source ditemukan, route menjadi valid, atau human memberi approval.

4. Apa kondisi berhenti?

Ada beberapa jenis stop: success, blocked, exhausted, denied, cancelled, unsafe, dan failed. Semuanya perlu status berbeda.

5. Apa yang terjadi setelah berhenti?

Apakah hasil dikembalikan ke user, diteruskan ke node berikutnya, masuk approval queue, atau membuat incident? Berhenti tanpa handoff hanya memindahkan kebingungan.

Termination harus berlapis

Mengandalkan satu max_steps=20 memang mencegah infinite loop literal. Itu belum membuat loop sehat. Termination perlu beberapa lapis.

Success condition

Syarat outcome sudah terpenuhi dan proof lulus. Contoh:

• semua field wajib tersedia dan tervalidasi;
• test yang sebelumnya gagal sekarang lulus;
• draft memenuhi struktur dan sumber;
• record eksternal dapat dibaca kembali dengan nilai yang benar;
• approval valid dan action terverifikasi.

Semantic stop

Agent mendeteksi bahwa tugas tidak dapat dilanjutkan tanpa input baru, permission, atau keputusan manusia. Statusnya blocked, bukan failed dan bukan success.

Safety stop

Action melampaui policy, menyentuh data sensitif tanpa izin, atau membutuhkan approval. Loop berhenti sebelum side effect.

Stall stop

Beberapa iterasi tidak menunjukkan progress. Contoh rule: dua tool call identik menghasilkan hasil identik, atau tiga revisi berturut-turut tidak mengurangi validation error. Rule harus disesuaikan dengan workflow, bukan angka universal.

Budget stop

Batas step, waktu, cost, token, tool call, atau concurrency tercapai. Statusnya exhausted dan perlu ringkasan posisi, bukan pesan sukses palsu.

External stop

User membatalkan, deadline lewat, approval ditolak, atau upstream job dibatalkan.

Termination berlapis membuat diagnosis lebih baik. Operator dapat membedakan "model tidak mampu", "data belum ada", "permission ditolak", dan "budget terlalu kecil".

State loop: jangan jadikan chat sebagai database

Chat history berisi narasi. Loop controller membutuhkan data operasional.

State minimum dapat terlihat seperti ini:

{
 "taskId": "report-2026-07-client-a",
 "workflowVersion": "3",
 "status": "running",
 "step": "validate_data",
 "attempt": 2,
 "maxAttempts": 4,
 "artifactIds": ["dataset-91"],
 "validationErrors": ["missing_currency"],
 "lastToolSignature": "fetch_metrics:client-a:2026-07",
 "lastToolResultHash": "sha256:...",
 "consecutiveNoProgress": 1,
 "approvalId": null,
 "startedAt": "2026-07-31T08:00:00+07:00",
 "deadlineAt": "2026-07-31T08:15:00+07:00"
}

Field persis bergantung pada pekerjaan. Prinsipnya: controller harus dapat menjawab apa yang sudah dicoba, apa yang berubah, mengapa belum selesai, dan apa yang aman dilakukan berikutnya.

Pisahkan state dari context. Model tidak selalu perlu melihat seluruh state. Context builder dapat memproyeksikan validationErrors, artifact terbaru, serta batas attempt, sementara audit data tetap disimpan di runtime. Baca Context vs State vs Memory pada AI Agent untuk pemisahan fungsi ketiganya.

Checkpoint state setelah transisi penting. Jika process mati, workflow tidak perlu mengulang dari awal atau bergantung pada ringkasan chat.

Mendesain progress yang dapat dihitung

Tidak semua output dapat dinilai dengan satu skor. Namun setiap loop perlu signal progress yang lebih kuat daripada "versi baru dibuat".

Progress deterministic

Cocok untuk schema, test, lint, build, jumlah error, field completion, dan status API.

before: 5 validation errors
attempt: fix source and date format
after: 2 validation errors
progress: yes

Progress berbasis rubric

Cocok untuk ringkasan, copy, atau analisis. Rubric perlu dimensi yang konkret: claim attribution, coverage, tone, redundancy, actionability. Gunakan pass/fail threshold atau pairwise comparison, lalu kalibrasi dengan reviewer manusia.

Panduan OpenAI tentang eval menyarankan eval task-specific, logging, dan continuous evaluation. Untuk penilaian model, comparison atau classification biasanya lebih stabil daripada pertanyaan terbuka "apakah ini bagus?".

Progress berbasis state transition

Cocok untuk proses approval dan handoff. Bergerak dari drafted ke validated adalah progress hanya jika gate benar-benar lulus. Mengubah label tanpa bukti bukan progress.

Progress berbasis information gain

Cocok untuk riset. Query baru dianggap berguna jika menambah sumber primer, menyelesaikan konflik, atau mengurangi unknown. Mengumpulkan lima artikel sekunder yang mengulang klaim sama tidak banyak menambah informasi.

No-progress signature

Catat kombinasi action dan result. Jika signature identik berulang tanpa perubahan input atau state, berhenti atau ganti strategi. Ini mekanisme sederhana untuk mencegah agent memukul endpoint yang sama.

Retry engineering: klasifikasikan failure sebelum mengulang

Retry otomatis berguna untuk failure sementara. Ia berbahaya untuk failure permanen dan side effect.

Retryable

Contoh: rate limit dengan Retry-After, network timeout sebelum request diproses, lock sementara, atau service unavailable. Gunakan bounded retry, backoff, jitter, dan deadline.

Conditionally retryable

Contoh: parser gagal karena output format, search tidak menemukan hasil, atau browser element berubah. Retry hanya jika strategi, input, model, atau tool benar-benar berubah. Mengulang request identik jarang memberi nilai.

Non-retryable

Contoh: permission denied, schema field wajib tidak tersedia, account ID salah, policy melarang action, approval ditolak, atau resource memang tidak ada. Escalate atau minta input.

Unknown outcome

Ini kategori kritis. Request write timeout setelah dikirim. Sistem tidak tahu apakah action terjadi. Jangan retry sebelum reconciliation. Cari external ID, cek record, atau gunakan idempotency key.

Backoff tidak menyelesaikan salah input. Model yang lebih kuat tidak menyelesaikan permission denied. Klasifikasi failure membuat loop mengubah strategi dengan alasan, bukan refleks.

Idempotency: syarat sebelum memberi agent tombol write

Operasi read biasanya aman diulang, walau tetap memakan biaya dan dapat terkena rate limit. Operasi write dapat membuat duplikasi.

Contoh side effect yang perlu perlindungan:

• mengirim email atau WhatsApp;
• membuat invoice;
• menambah budget campaign;
• membuka pull request;
• membuat tiket;
• memublikasikan artikel;
• melakukan refund;
• mengubah status kontrak.

Gunakan salah satu atau kombinasi berikut:

1. Idempotency key yang stabil per business action.
2. Read-before-write untuk mengecek apakah outcome sudah ada.
3. External identifier yang disimpan di checkpoint.
4. Compare-and-set atau version check untuk mencegah overwrite race.
5. Outbox pattern agar pencatatan intent dan delivery dapat direkonsiliasi.
6. Human approval yang terikat ke payload hash, bukan approval kosong.

Jangan menganggap "tool call hanya sekali di trace" cukup. Crash dapat terjadi setelah sistem eksternal menerima request tetapi sebelum checkpoint ditulis.

Approval adalah pause, bukan pesan peringatan

Loop yang menyentuh action sensitif harus mampu berhenti dan dilanjutkan.

Dokumentasi LangGraph interrupts menjelaskan pattern pause, checkpoint state, dan resume dengan thread ID yang sama. Implementasi framework lain dapat berbeda. Prinsip umumnya: approval harus berada di control flow, dan state harus persisten saat menunggu.

Approval payload sebaiknya memuat:

• action yang akan dilakukan;
• target dan scope;
• perubahan sebelum/sesudah;
• sumber data;
• risiko atau validation warning;
• artifact preview;
• masa berlaku;
• payload hash atau version.

Jika approver mengubah recipient atau nominal, approval lama tidak lagi valid. Loop kembali ke validation, bukan langsung mengeksekusi payload baru.

Pada resume, periksa ulang data volatil dan policy. Approval kemarin tidak selalu sah untuk harga, saldo, atau recipient hari ini.

Context loop: setiap iterasi tidak harus membawa semua histori

Agent loop menghasilkan banyak data: tool output, intermediate draft, error, dan commentary. Memasukkan semuanya ke setiap model call membuat context tumbuh dan signal turun.

Anthropic dalam effective context engineering menyarankan context yang informatif tetapi ketat, progressive disclosure, just-in-time retrieval, compaction, dan structured note-taking untuk pekerjaan panjang.

Untuk loop operasional:

• simpan raw trace di observability store;
• simpan state ringkas di checkpoint;
• berikan model hasil tool terbaru yang relevan;
• buang atau ringkas raw output lama setelah informasinya dipromosikan ke state;
• pertahankan keputusan, unresolved error, artifact pointer, dan batas;
• ambil source besar dengan pointer dan query spesifik.

Compaction bukan sekadar merangkum chat. Ia harus mempertahankan fakta yang menentukan next action. Uji compaction pada trace yang gagal, bukan hanya percakapan bersih.

Loop pattern yang berguna

Tool-use loop

Model memilih tool, aplikasi menjalankan, hasil kembali ke model. Cocok untuk pencarian, analisis, dan pekerjaan eksploratif. Pasang tool budget, no-progress detection, dan permission.

Draft-critique-revise loop

Draft dibuat, diperiksa terhadap rubric, lalu direvisi. Cocok untuk artikel, proposal, dan analisis. Critique harus menunjuk failure spesifik. Batas iterasi diperlukan karena critic generatif dapat terus menemukan preferensi baru.

Plan-execute-replan loop

Agent membuat rencana, mengeksekusi langkah, lalu memperbarui rencana saat environment berbeda dari asumsi. Cocok untuk task panjang. Simpan plan sebagai artifact berversi; jangan menulis ulang histori sehingga keputusan lama hilang.

Polling loop

Workflow menunggu job asynchronous. Controller memeriksa status sampai terminal state, deadline, atau failure. Gunakan interval dan backoff; jangan memakai model untuk setiap polling bila code deterministic cukup.

Human-review loop

Agent menyiapkan proposal action, human approve/edit/reject, lalu agent melanjutkan. State perlu mengikat approval dengan payload dan workflow version.

Recovery loop

Setelah crash atau timeout, controller membaca checkpoint dan environment, melakukan reconciliation, lalu menentukan resume atau escalate. Recovery loop bukan retry loop.

Evaluator-optimizer loop

Satu komponen menghasilkan output, evaluator menilai, optimizer memperbaiki. Gunakan hanya jika evaluator cukup selaras dengan outcome. Jika evaluator tidak stabil, loop dapat mengoptimalkan artefak agar "menyenangkan hakim" tanpa memperbaiki hasil bisnis.

Fakta sumber, pattern industri, dan rekomendasi kami

Fakta sumber resmi: OpenAI mendokumentasikan alur function calling yang dapat berlanjut melalui beberapa tool call; Google ADK menyediakan primitive Loop Agent dengan termination condition; Anthropic mendokumentasikan compaction dan structured note-taking untuk menjaga context pada pekerjaan panjang. Fakta itu menjelaskan capability dan panduan dari sumber yang disebut, bukan jaminan reliability untuk setiap implementasi.

Pattern industri: bounded retry, checkpoint, idempotency, human approval, stall detection, dan proof of completion berulang muncul pada sistem agent serta distributed workflow. Penerapannya harus mengikuti semantics tool dan dampak salah.

Rekomendasi Rama Digital: letakkan termination di controller, mulai dari batas konservatif, dan jangan aktifkan external write sebelum unknown outcome dapat direkonsiliasi. Ini keputusan desain operasional, bukan hukum universal atau klaim bahwa satu konfigurasi cocok untuk semua proses.

Kapan tidak perlu loop agentic

Tidak semua pekerjaan memerlukan iterasi model.

Gunakan code deterministic bila:

• langkahnya tetap dan input terstruktur;
• error handling dapat diprogram;
• output punya transformasi jelas;
• routing berdasarkan field atau threshold;
• polling tidak membutuhkan interpretasi;
• validation dapat dilakukan dengan schema atau test.

Gunakan satu model call bila:

• tugas sempit;
• context lengkap tersedia sejak awal;
• tidak ada tool atau side effect;
• output langsung diverifikasi;
• retry manual masih murah.

Gunakan loop agentic bila model perlu memilih action berdasarkan hasil yang baru muncul dan jalurnya tidak dapat ditentukan seluruhnya di awal.

Ini sejalan dengan rekomendasi praktis untuk tidak menambah complexity sebelum eval membuktikan kebutuhan. Artikel AI Trainer vs Prompt Engineer vs AI Engineer membantu membedakan pekerjaan instruksi, evaluasi, integrasi, dan sistem yang dibutuhkan di tim.

Contoh workflow Rama Digital: riset dan draft artikel

Outcome: draft artikel berbasis sumber primer, berada di folder yang ditentukan, memenuhi acceptance criteria, dan belum dipublikasikan.

State awal

title, slug, audience, source requirements,
internal-link allowlist, word range, path scope,
status=researching, attempts=0

Loop riset

1. Cari atau fetch sumber primer wajib.
2. Catat klaim yang benar-benar didukung.
3. Identifikasi gap: definisi, limitation, workflow example, failure mode.
4. Lakukan retrieval tambahan hanya untuk gap yang belum tertutup.
5. Berhenti ketika source coverage lulus atau sumber publik tidak tersedia.

Progress diukur dari gap yang terselesaikan, bukan jumlah URL.

Loop drafting

1. Tulis struktur berdasarkan problem, definisi, mekanisme, contoh, failure, dan checklist.
2. Jalankan validator deterministic.
3. Jalankan review editorial terhadap klaim, repetisi, tone, dan link.
4. Revisi hanya failure yang tercatat.
5. Berhenti ketika semua gate lulus atau batas iterasi tercapai.

Termination status

• validated_draft: semua gate lulus.
• blocked_source: sumber wajib tidak dapat diakses atau klaim tidak dapat diverifikasi.
• blocked_scope: kebutuhan mengharuskan write di luar path yang diizinkan.
• exhausted: batas revisi tercapai dengan failure tersisa.
• cancelled: pekerjaan dihentikan operator.

Proof

File dibaca ulang. H1 dihitung. Word count dilaporkan. JSON divalidasi. Placeholder dicari. Public link diperiksa. Status publish tetap tidak berubah.

Contoh loop coding yang lebih spesifik ada di Claude Code Loop untuk Workflow Koding Sehari-hari. Prinsipnya sama: setiap putaran harus menghasilkan evidence, bukan hanya perubahan.

Failure modes loop dan perbaikannya

Infinite tool call

Gejala: action dan argumen sama berulang.

Perbaikan: simpan tool signature dan result hash; hentikan pengulangan identik; minta input atau ganti strategi berdasarkan failure category.

Infinite revision

Gejala: draft terus berubah tetapi gate yang sama gagal.

Perbaikan: critic harus mengembalikan issue ID dan acceptance test; hitung unresolved issue; batasi revisi per issue.

Premature completion

Gejala: model memberi jawaban final sebelum tool atau verification selesai.

Perbaikan: controller menentukan terminal state; final response hanya dapat dibuat setelah postcondition lulus.

Retry storm

Gejala: banyak run mengulang request ke service yang sedang gagal.

Perbaikan: exponential backoff, jitter, circuit breaker, global concurrency, dan respect Retry-After.

Side effect ganda

Gejala: email, invoice, atau ticket terbuat dua kali setelah timeout.

Perbaikan: idempotency key, external ID, reconciliation, dan checkpoint order yang benar.

Context snowball

Gejala: setiap iterasi makin lambat dan keputusan memburuk karena seluruh histori dibawa.

Perbaikan: compaction, tool result clearing, structured state, dan just-in-time retrieval.

Oscillation

Gejala: agent berganti antara dua solusi tanpa convergence.

Perbaikan: simpan rejected approach serta alasan, gunakan deterministic tie-breaker, dan escalate setelah pola berulang.

Goal drift

Gejala: agent menemukan pekerjaan tambahan lalu meninggalkan outcome awal.

Perbaikan: state memuat goal immutable, scope, dan acceptance criteria; temuan samping masuk backlog, bukan langsung dikerjakan.

Approval bypass

Gejala: setelah timeout, workflow masuk jalur write tanpa approval yang masih valid.

Perbaikan: permission check di tool, approval token terikat payload, dan revalidation pada resume.

False progress

Gejala: jumlah file atau kata naik, tetapi kualitas dan kelengkapan tidak berubah.

Perbaikan: ukur outcome gate, bukan volume activity.

Eval loop secara terpisah

Satu end-to-end score sulit menunjukkan sumber masalah. Pisahkan eval:

• decision eval: apakah next action benar?
• tool selection eval: apakah tool yang dipilih tepat?
• argument eval: apakah parameter akurat dan lengkap?
• progress eval: apakah state bergerak menuju acceptance?
• termination eval: apakah agent berhenti pada waktu dan alasan yang benar?
• recovery eval: apakah resume menghindari action ganda?
• approval eval: apakah action sensitif selalu berhenti?
• completion eval: apakah status sukses disertai proof?

Masukkan kasus normal, edge, adversarial, dan historis dari trace. Uji juga failure injection: timeout setelah write, response rusak, rate limit, stale approval, sumber berubah, dan checkpoint tertinggal.

OpenAI menyebut "vibe-based evals" sebagai anti-pattern. Pernyataan "agent terlihat lebih pintar" tidak cukup untuk mengubah retry policy atau menaikkan autonomy.

Observability minimum untuk loop

Operator perlu dapat melihat satu run tanpa membaca seluruh chat.

Catat:

• run ID, task ID, workflow version;
• start, deadline, elapsed time;
• node dan iteration count;
• model serta prompt version;
• context source IDs, bukan data sensitif mentah;
• tool name, normalized arguments, latency, status;
• state transition;
• progress signal;
• retry category dan delay;
• approval event;
• artifact dan proof;
• terminal reason.

Gunakan correlation ID ke sistem eksternal. Tanpa itu, reconciliation menjadi pencarian manual.

Dashboard yang berguna menampilkan loop exhausted, no-progress stop, duplicate prevention, retry volume, approval waiting time, dan verification failure. Token count penting untuk cost, tetapi tidak menjelaskan reliability sendiri.

Checklist sebelum loop masuk production

Goal dan state

• Apakah goal immutable selama run?
• Apakah state menyimpan posisi, artifact, attempt, dan blocker?
• Apakah state dapat dipulihkan tanpa histori chat penuh?
• Apakah workflow version disimpan?

Progress

• Apa perubahan yang dianggap progress?
• Dapatkah progress diperiksa secara deterministic?
• Apakah no-progress dan oscillation dapat terdeteksi?
• Apakah evaluator sudah dikalibrasi dengan human review?

Stop

• Apa success, blocked, unsafe, denied, exhausted, dan cancelled?
• Siapa yang menentukan terminal state: controller atau model?
• Apakah step, time, cost, serta tool budget ada?
• Apakah final response menunggu proof?

Retry dan side effect

• Failure mana yang retryable?
• Apakah backoff dan circuit breaker tersedia?
• Apakah write memakai idempotency atau reconciliation?
• Apa yang dilakukan saat outcome tidak diketahui?

Context

• Apakah hasil tool lama dibersihkan?
• Apakah keputusan dan unresolved issue tetap dipertahankan?
• Apakah source besar diambil just-in-time?
• Apakah context scope dan permission tetap berlaku setiap iterasi?

Human control

• Di mana approval mem-pause execution?
• Apakah approval terikat ke payload dan version?
• Apakah resume memakai checkpoint yang sama?
• Apakah data volatil diperiksa ulang setelah menunggu?

Keputusan implementasi

Mulai dari loop terkecil yang dapat menyelesaikan pekerjaan. Jika satu model call plus validator cukup, jangan buat agent loop. Jika retry bisa ditangani code, jangan meminta model memutuskan. Jika action punya dampak eksternal, pasang idempotency dan proof sebelum menambah autonomy.

Infinite loop bukan hanya proses yang tidak pernah berhenti. Loop yang berhenti karena kuota habis tanpa progress juga gagal. Loop yang keluar terlalu cepat dengan status sukses palsu sama buruknya.

Loop engineering yang matang membuat agent melakukan tiga hal dengan jelas: bergerak, berhenti, atau meminta bantuan. Tidak ada status keempat bernama "masih mencoba" tanpa batas.