Prompt Engineering AI Agent 2026

Prompt Engineering 2026: Dari Instruksi ke Tool Schema, Eval, dan Acceptance Criteria

Tim mengubah satu system prompt selama dua minggu. Versi ke-17 terdengar lebih tegas, lebih panjang, dan memuat hampir semua edge case yang pernah ditemukan. Demo membaik. Begitu model di-upgrade atau input production sedikit berbeda, agent kembali salah memilih tool dan menganggap output setengah jadi sebagai final.

Masalahnya bukan prompt engineering tidak berguna. Masalahnya, prompt diperlakukan sebagai naskah sakti yang harus menampung policy, program, data, schema, contoh, test, dan workflow sekaligus.

Prompt engineering pada 2026 adalah pekerjaan merancang dan memelihara kontrak instruksi untuk model, lalu menghubungkannya dengan tool schema, structured output, acceptance criteria, versioning, dan eval. Prompt tetap penting. Ia tidak lagi berdiri sendiri.

Dokumentasi OpenAI tentang prompt engineering mendefinisikannya sebagai proses menulis instruksi efektif agar model secara konsisten menghasilkan konten sesuai kebutuhan. Dokumentasi yang sama menyarankan model snapshot, test, dan evaluation suite karena output model bersifat non-deterministik dan perilaku dapat berubah antarversi.

Prompt engineering adalah istilah mapan. Yang berubah adalah unit kerjanya: bukan mencari "kata paling ampuh", melainkan membangun prompt sebagai komponen software yang punya input contract, output contract, test, owner, dan jalur deployment.

Prompt tidak mati setelah context engineering muncul

Context engineering membahas seluruh set token yang dilihat model: instruksi, tools, hasil retrieval, message history, state projection, contoh, dan output tool. Anthropic menjelaskan bahwa context engineering adalah perluasan alami dari prompt engineering untuk agent yang bekerja multi-turn dan memakai tools.

Artinya bukan prompt diganti context. Prompt adalah bagian dari context yang memberi tujuan, rule, dan interpretasi terhadap informasi lain.

Pemisahannya sederhana:

Prompt: apa yang harus dilakukan model.
Context: informasi apa yang tersedia ketika model melakukannya.
Tool schema: action dan data contract apa yang dapat dipilih.
Harness: bagaimana action dijalankan, dibatasi, diamati, dan dibuktikan.
Loop dan graph: bagaimana langkah diulang, dirutekan, dipause, dan dihentikan.

Kerangka lengkapnya ada di Lima Lapisan Engineering AI Agent. Pemisahan context, state, dan memory dibahas di Context vs State vs Memory pada AI Agent.

Ketika model mengambil harga lama, jangan otomatis mengedit prompt. Periksa retrieval dan source authority. Ketika tool menerima tenant ID sembarang, perbaiki permission boundary. Ketika agent mengulang, perbaiki loop. Prompt hanya tepat sasaran jika failure memang berasal dari instruksi atau interpretasi.

Unit prompt production: satu tanggung jawab, satu kontrak

Prompt besar yang menangani triage, retrieval, analisis, penulisan, dan approval sekaligus sulit dievaluasi. Setiap revisi dapat memperbaiki satu perilaku sambil merusak perilaku lain.

Lebih aman memecah berdasarkan tanggung jawab model call.

Contoh workflow proposal:

classify_request menentukan jenis permintaan.
extract_requirements menghasilkan field terstruktur.
identify_missing_data menentukan gap.
draft_proposal menulis berdasarkan data tervalidasi.
review_claims menandai klaim tanpa bukti.

Setiap prompt memiliki input, output, dan eval sendiri. Beberapa langkah bahkan tidak memerlukan model. Validasi email, threshold discount, dan status approval lebih baik ditangani code.

Prinsip ini bukan ajakan membuat seratus agent. Satu aplikasi dapat menjalankan beberapa model call dengan prompt berbeda. Agent identity dan deployment unit tidak harus sama dengan unit prompt.

Anatomi prompt yang dapat dipelihara

Tidak ada format universal. Dokumentasi OpenAI menyebut penggunaan Markdown dan XML untuk memisahkan bagian logis, serta memberi contoh urutan identity, instructions, examples, dan context. Anthropic juga menyarankan sections yang jelas, tetapi mengingatkan agar prompt berada pada "altitude" yang tepat: tidak terlalu vague dan tidak berubah menjadi if-else brittle.

Struktur kerja berikut cukup praktis:

## Purpose
Tujuan model call ini.

## Inputs
Field dan arti data yang diterima.

## Instructions
Langkah atau heuristic yang perlu dipakai.

## Tool guidance
Kapan memakai tool, kapan tidak, dan batas authority.

## Output contract
Schema atau struktur jawaban.

## Acceptance criteria
Syarat yang harus dipenuhi sebelum output diterima.

## Examples
Beberapa kasus canonical yang beragam.

## Context
Data task yang berubah per request.

Urutan dapat berubah menurut model dan use case. Yang penting, instruction tidak tercampur dengan untrusted source. Dokumen, email, dan halaman web adalah data. Kalimat di dalamnya tidak otomatis boleh mengubah policy.

Tulis purpose yang operasional

Purpose buruk:

Anda adalah AI marketing expert kelas dunia. Berikan analisis terbaik dan mendalam.

Purpose yang lebih operasional:

Bandingkan performa kampanye periode aktif dengan baseline yang diberikan. Laporkan perubahan metrik, kualitas bukti, dan data yang masih kurang. Jangan menyimpulkan penyebab jika data tidak mendukung.

Versi kedua menjelaskan task, unit pembanding, output, dan batas klaim. Ia tidak menjanjikan kualitas lewat adjective.

Identity berguna ketika memengaruhi keputusan: editor klaim, classifier tiket, atau reviewer keamanan. Persona dekoratif jarang memperbaiki contract.

Bedakan instruction, data, dan policy

Production prompt sering memuat tiga jenis informasi.

Instruction mengatur cara model bekerja pada node itu.

Data adalah input yang perlu dianalisis: brief, dokumen, metrik, atau message.

Policy adalah aturan organisasi yang membatasi action: permission, approval, privacy, dan compliance.

Model perlu melihat policy yang relevan agar dapat merencanakan. Namun policy penting juga harus ditegakkan oleh harness atau code. Misalnya, prompt dapat mengatakan "diskon di atas 10% memerlukan approval". Tool pembuatan proposal tetap harus menolak status final tanpa approval ID.

Pisahkan untrusted data dengan boundary jelas:

<customer_message>
...data dari user...
</customer_message>

Instruksi di dalam customer_message tetap data. Ini membantu model memahami batas, tetapi bukan security boundary sendiri. Tool permission dan sanitizer masih diperlukan.

Tool schema adalah bagian dari prompt engineering modern

Tool definition biasanya masuk ke context model. Nama, description, parameter, enum, dan output menentukan bagaimana model memahami capability.

Panduan function calling OpenAI menjelaskan bahwa function tools didefinisikan dengan JSON schema dan alur tool call dieksekusi oleh aplikasi. Schema membantu contract, tetapi desain semantiknya tetap pekerjaan engineering.

Tool buruk:

{
 "name": "manage_customer",
 "description": "Manage customer data",
 "parameters": {
 "type": "object",
 "properties": {
 "action": {"type": "string"},
 "payload": {"type": "object"}
 }
 }
}

Tool ini menyembunyikan scope action dan membuat argument eval sulit.

Tool lebih jelas:

{
 "name": "create_customer_followup_draft",
 "description": "Create an internal follow-up draft. This tool does not send a message.",
 "parameters": {
 "type": "object",
 "properties": {
 "customer_id": {
 "type": "string",
 "description": "Canonical customer ID from CRM"
 },
 "reason": {
 "type": "string",
 "enum": ["missing_document", "approval_pending", "status_update"]
 },
 "language": {
 "type": "string",
 "enum": ["id", "en"]
 }
 },
 "required": ["customer_id", "reason", "language"],
 "additionalProperties": false
 }
}

Perbaikannya bukan hanya format JSON. Nama menyatakan outcome draft. Deskripsi menyatakan tidak ada pengiriman. customer_id harus berasal dari CRM. Enum membatasi reason. Schema mengurangi ruang tebakan.

Tool design juga perlu menjawab:

apakah side effect terjadi;
apakah tool read, draft, atau write;
apakah retry aman;
apakah approval dibutuhkan;
apa status output;
error mana yang retryable;
data apa yang tidak boleh muncul kembali.

Itulah titik temu prompt engineering dan harness engineering. Ketika prompt dijalankan sebagai beberapa tahap dengan route dan approval berbeda, kontraknya menjadi bagian dari graph-based agent workflow.

Structured output: jangan memaksa format lewat prosa bila schema tersedia

Untuk output yang akan diproses aplikasi, format harus menjadi contract. Menulis "jawab dalam JSON valid, jangan tambahkan apa pun" dapat bekerja, tetapi schema lebih kuat.

Dokumentasi OpenAI Structured Outputs membedakan structured output berbasis JSON schema dari JSON mode. Dokumentasi tersebut menyatakan Structured Outputs menjamin adherence terhadap schema yang diberikan pada model yang didukung, sedangkan JSON mode hanya menjamin JSON valid.

Contoh contract ekstraksi:

{
 "type": "object",
 "properties": {
 "request_type": {
 "type": "string",
 "enum": ["report", "revision", "approval", "unknown"]
 },
 "client_id": {"type": ["string", "null"]},
 "period": {"type": ["string", "null"]},
 "missing_fields": {
 "type": "array",
 "items": {"type": "string"}
 }
 },
 "required": ["request_type", "client_id", "period", "missing_fields"],
 "additionalProperties": false
}

Schema tidak menjamin fakta di dalam field benar. Ia menjamin bentuk. Anda tetap perlu validation, source check, dan eval argument accuracy.

Untuk tool use, pakai function calling. Untuk respons terstruktur yang dikonsumsi aplikasi atau UI, pakai structured output sesuai capability provider. Jangan menaruh schema besar sebagai paragraf natural language jika API mendukung enforcement yang lebih langsung.

Acceptance criteria: definisi selesai sebelum model bekerja

Prompt sering menyebut task tetapi tidak mendefinisikan apa yang membuat hasil diterima. Model lalu mengoptimalkan kelengkapan yang tampak, bukan hasil yang dapat diuji.

Acceptance criteria perlu spesifik terhadap node.

Contoh: ekstraksi brief

output sesuai schema;
setiap field memiliki source span atau null;
tidak mengisi field yang tidak ada di brief;
missing_fields memuat field wajib yang belum tersedia;
client ID harus cocok dengan allowlist dari state.

Contoh: draft artikel

H1 tepat satu;
masalah nyata muncul di opening;
definisi dan status istilah jelas;
klaim vendor ditautkan ke sumber primer;
fakta, pattern industri, dan rekomendasi internal tidak dicampur;
tidak ada publish action;
word count berada pada rentang brief.

Contoh: rekomendasi refund

order berhasil ditemukan;
policy version tercatat;
reason code valid;
nominal berada dalam limit;
output hanya proposal action, bukan eksekusi;
kasus di luar limit diberi status approval_required.

Acceptance criteria tidak semuanya harus berada dalam prompt. Criteria deterministic dijalankan validator. Prompt perlu mengetahui criteria yang memengaruhi proses berpikir dan output; harness menegakkan sisanya.

Few-shot example: gunakan kasus canonical, bukan daftar edge case tanpa akhir

Examples membantu menunjukkan perilaku yang sulit dijelaskan. Anthropic menyarankan contoh yang beragam dan canonical, bukan laundry list seluruh edge case.

Satu set example yang berguna mencakup:

kasus normal;
input ambigu yang harus menghasilkan unknown atau pertanyaan;
kasus dengan data konflik;
kasus yang tampak lengkap tetapi gagal policy;
kasus adversarial yang mencoba mengubah instruksi;
kasus boundary antar-route.

Jangan memasukkan contoh yang sangat mirip lalu mengira coverage sudah luas. Diversity harus mengikuti failure distribution production.

Examples juga memakan context. Jika perilaku dapat dijamin schema atau code, tidak perlu memberi sepuluh contoh formatting.

Prompt versioning: perlakukan seperti code

Prompt production harus punya:

identifier dan version;
owner;
model snapshot yang diuji;
changelog ringkas;
fixture set;
eval result sebelum dan sesudah;
rollout serta rollback path;
observability ke trace.

Dokumentasi OpenAI per Juli 2026 menyarankan menyimpan production prompt di application code, memakai typed input atau schema, code review, test, dan deployment process. Dokumentasi tersebut juga mencatat deprecation reusable prompt objects di platformnya. Detail timeline adalah kebijakan produk OpenAI dan dapat berubah; prinsip yang lebih umum adalah prompt harus mengikuti lifecycle software.

Jangan mengubah prompt langsung di production UI tanpa audit bila workflow berisiko. Perubahan satu adjective pun dapat menggeser tool selection atau refusal. Gunakan feature flag atau staged rollout saat dampaknya besar.

Pin model snapshot jika provider menyediakan dan stabilitas lebih penting daripada update otomatis. Ketika model berubah, jalankan suite yang sama. Model upgrade bukan hanya improvement; ia adalah dependency change.

Eval prompt: test perilaku, bukan keindahan wording

OpenAI evaluation best practices menekankan eval-driven development, task-specific dataset, logging, automation, dan continuous evaluation. Mereka juga mengingatkan bahaya vibe-based eval.

Eval prompt sebaiknya dibagi menurut failure surface.

Instruction following

Apakah model mengikuti tujuan node, larangan, dan authority? Uji input yang mencoba mengubah role atau meminta action di luar scope.

Functional correctness

Apakah output menyelesaikan task dan fakta sesuai ground truth?

Tool selection

Apakah tool yang dipilih tepat? Uji boundary antara dua tool yang fungsinya mirip.

Argument precision

Apakah parameter diambil dari input yang benar, termasuk tenant, tanggal, unit, dan identifier?

Output schema

Apakah output dapat diparse dan field wajib terisi sesuai aturan? Schema enforcement mengurangi failure format, tetapi semantic validation tetap perlu.

Abstention dan escalation

Apakah model mengatakan tidak tahu, meminta data, atau menaikkan approval ketika bukti kurang? Banyak eval hanya menghukum jawaban salah, tetapi tidak menguji kemampuan berhenti.

Robustness

Apakah variasi redaksi, urutan data, typo, dokumen panjang, dan konflik sumber mengubah outcome secara tidak semestinya?

Regression

Apakah perbaikan failure baru merusak kasus lama? Setiap incident production yang representatif perlu masuk fixture.

Gunakan exact match untuk label, executable check untuk code atau SQL, schema validator untuk struktur, rubric dan pairwise untuk editorial, serta human review untuk judgement yang belum dapat diotomasi. Kalibrasi model judge dengan label manusia sebelum dipercaya sebagai gate.

Membangun dataset eval yang nyata

Dataset tidak perlu langsung besar. Ia perlu mewakili distribusi risiko.

Mulai dari:

kasus historis yang berhasil;
kasus historis yang gagal;
boundary antar-kategori;
input dengan field hilang;
konflik data lama dan baru;
prompt injection di dalam dokumen;
tenant atau account yang mirip;
action yang membutuhkan approval;
tool timeout dan malformed result;
perubahan model atau prompt yang pernah menimbulkan regression.

Pisahkan train atau development cases dari holdout. Jika engineer terus membaca dan menyesuaikan prompt terhadap semua kasus, skor dapat naik karena overfitting terhadap fixture.

Jangan mengarang target angka universal. Threshold ditetapkan berdasarkan baseline, biaya salah, dan review kapasitas. Tool selection untuk refund memerlukan bar yang lebih ketat daripada variasi gaya pada draft internal.

Fakta sumber, pattern industri, dan rekomendasi kami

Fakta sumber resmi: dokumentasi OpenAI menjelaskan message authority, function calling, Structured Outputs, model snapshot, dan evaluation practices pada platformnya. Anthropic menjelaskan prompt sebagai bagian dari context yang lebih luas. Detail API dan deprecation adalah fakta produk yang dapat berubah, sehingga perlu diperiksa lagi saat implementasi.

Pattern industri: prompt berversi, tool schema sempit, structured output, fixture, regression eval, dan staged rollout semakin diperlakukan seperti praktik software delivery. Pattern ini kuat, tetapi pilihan tool dan threshold tetap bergantung pada risiko workflow.

Rekomendasi Rama Digital: pecah prompt per tanggung jawab, pindahkan invariant deterministic ke code, dan jangan menerima perubahan prompt tanpa failure case serta acceptance criterion. Ini standar kerja yang kami sarankan, bukan statistik atau standar resmi lintas vendor.

Workflow Rama Digital: prompt untuk follow-up project

Kasus: agent membaca update project, menentukan apakah follow-up dibutuhkan, lalu menyiapkan pesan spesifik. Agent tidak boleh mengirim ke topic yang salah atau menanyakan status yang sudah dijawab.

Node 1: normalize update

Input: pesan dalam periode yang ditentukan, topic ID, project ID, dan waktu.

Instruction: ekstrak progress, blocker, PIC, ETA, decision, dan open question. Jangan menyimpulkan informasi yang tidak dinyatakan.

Output: schema terstruktur dengan source message ID.

Acceptance: setiap fakta punya provenance; field yang tidak ada bernilai null.

Node 2: decide follow-up

Input: state project, update terstruktur, follow-up log, dan policy cadence.

Instruction: pilih no_action, ask_gap, escalate_blocker, atau request_approval.

Tool guidance: tool send tidak tersedia. Node hanya membuat proposal.

Acceptance: tidak meminta ulang field yang sudah dijawab; alasan route menunjuk gap konkret.

Node 3: write draft

Input: route, missing fields, recipient role, topic, dan tone.

Instruction: tulis satu pesan ringkas yang menyebut konteks dan pertanyaan spesifik.

Acceptance: tidak ada generic "ada update?"; tidak membuat ETA; tidak menyebut data proyek lain.

Gate deterministic

Controller memeriksa topic ID, deduplication window, dan allowlist recipient. Approval atau policy menentukan apakah draft boleh dikirim.

Perhatikan pembagiannya. Prompt mengatur ekstraksi dan bahasa. State menyimpan posisi project. Context builder memilih pesan relevan. Harness membatasi topic dan tool. Graph mengatur route. Loop mencegah follow-up ganda.

Artikel Setiap Staf Punya AI Agent memberi konteks organisasi, tetapi implementasi per staf tetap membutuhkan contract dan boundary seperti di atas.

Failure modes prompt engineering

Prompt monolitik

Satu file mengatur seluruh workflow. Perubahan kecil sulit diuji dan context penuh rule yang tidak relevan.

Perbaikan: pecah per model call atau responsibility; letakkan control flow di graph atau code.

Adjective-driven instruction

"Teliti, tajam, mendalam, profesional" tidak mendefinisikan output.

Perbaikan: sebut unit analisis, source requirement, format, limitation, dan acceptance.

Policy hanya di prompt

Model diminta tidak melakukan write, tetapi tool write tetap tersedia.

Perbaikan: enforce permission di harness; prompt hanya membantu planning.

Formatting lewat ancaman

Prompt berulang kali menulis "WAJIB JSON VALID".

Perbaikan: gunakan structured output, schema validation, dan retry yang dibatasi.

Edge-case accretion

Setiap failure menambah satu aturan. Prompt membengkak dan aturan konflik.

Perbaikan: kelompokkan failure; pindahkan deterministic rule ke code; gunakan beberapa contoh canonical; hapus rule obsolete.

Context dan instruction bercampur

Dokumen user diletakkan tanpa delimiter di bawah system instruction.

Perbaikan: pisahkan role dan data boundary; sanitize; jangan anggap delimiter sebagai security enforcement.

Tidak ada abstention path

Model harus selalu memberi jawaban, sehingga gap diisi tebakan.

Perbaikan: sediakan unknown, missing_fields, blocked, atau approval_required dalam output contract.

Eval terlalu umum

Reviewer memberi skor "bagus" tanpa dimensi.

Perbaikan: pecah correctness, source, tool selection, argument, tone, dan escalation; gunakan pass/fail untuk critical criterion.

Prompt upgrade tanpa model pinning

Prompt diperbaiki pada satu model, production memakai model alias yang berubah.

Perbaikan: catat model version, jalankan regression pada upgrade, dan staged rollout.

Memperbaiki lapisan yang salah

Sumber lama diselesaikan dengan kalimat "gunakan sumber terbaru". Infinite loop diselesaikan dengan "jangan mengulang".

Perbaikan: audit context retrieval, loop controller, permission, dan harness proof.

Anti-pattern "prompt yang semakin panjang pasti semakin baik"

Prompt minimal bukan berarti pendek secara paksa. Prompt harus cukup lengkap untuk mengarahkan perilaku, tetapi tidak menampung seluruh knowledge base.

Anthropic menyarankan "minimal set of information that fully outlines expected behavior". Ini adalah prinsip optimasi signal, bukan target jumlah token.

Cara memangkas prompt:

hapus latar belakang yang tidak mengubah keputusan;
pindahkan data dinamis ke context builder;
pindahkan schema ke API mechanism;
pindahkan invariant deterministic ke code;
pindahkan SOP panjang ke retrieval just-in-time;
ganti edge-case list dengan heuristic dan contoh canonical;
hapus aturan yang tidak punya eval;
tandai policy source of truth, jangan duplikasi versinya.

Setelah dipangkas, jalankan eval. Jangan mengandalkan rasa bahwa prompt "lebih bersih".

Checklist prompt production

Scope

Apakah model call punya satu tujuan?
Apakah bagian deterministic sudah dikeluarkan?
Apakah input dan authority jelas?
Apakah ada jalur unknown, blocked, atau approval?

Instruction

Apakah instruksi konkret tanpa adjective kosong?
Apakah conflict dan priority dijelaskan?
Apakah data eksternal dipisahkan dari instruction?
Apakah contoh beragam dan canonical?

Tools dan output

Apakah tool name, description, schema, dan side effect jelas?
Apakah tool set minimum dan tidak overlap?
Apakah output memakai schema bila diproses aplikasi?
Apakah semantic validation terpisah dari format validation?

Acceptance

Apakah syarat selesai dapat diperiksa?
Apakah proof berasal dari source atau environment?
Apakah critical criterion pass/fail?
Apakah agent dilarang menyatakan sukses sebelum gate lulus?

Lifecycle

Apakah prompt, model, tool schema, dan eval berversi?
Apakah change melewati review dan rollout?
Apakah trace mencatat version yang dipakai?
Apakah rollback tersedia?

Evals

Apakah dataset mewakili normal, edge, adversarial, dan historical failure?
Apakah tool selection dan argument diuji terpisah?
Apakah escalation dan abstention diuji?
Apakah model judge dikalibrasi dengan manusia?

Urutan perbaikan prompt yang lebih disiplin

Reproduksi failure dengan input dan model version yang sama.
Klasifikasikan lapisan: instruction, context, tool, harness, loop, atau graph.
Tentukan expected behavior dalam acceptance criterion.
Tambahkan eval case yang gagal sebelum perubahan.
Buat perubahan terkecil pada prompt atau schema.
Jalankan suite penuh, bukan hanya kasus baru.
Review trace untuk memastikan perbaikan terjadi lewat mekanisme yang diinginkan.
Rollout bertahap bila dampaknya besar.
Pantau production distribution dan masukkan failure representatif ke regression suite.

Proses ini lebih lambat daripada mengedit kalimat lalu mencoba demo. Namun ia mencegah prompt menjadi tumpukan ritual yang tidak diketahui efeknya.

Prompt engineering tetap penting, tetapi harus dapat diuji

Prompt adalah interface antara intent manusia dan perilaku model. Interface itu perlu jelas. Namun production reliability datang dari kombinasi: context yang tepat, tool schema yang sempit, output contract, eval, guardrail, loop, dan proof.

Pada 2026, prompt engineer yang hanya mengoptimalkan wording akan kesulitan menangani agent. Pekerjaannya menyentuh data contract, eval design, tool semantics, dan failure analysis. Bukan berarti setiap prompt engineer harus membangun seluruh platform. Tim harus paham boundary agar masalah dikirim ke lapisan yang benar.

Tulis prompt seperti code yang akan berubah: punya owner, version, test, acceptance criteria, dan rollback. Jika tidak, prompt panjang hanya membuat kegagalan terlihat lebih resmi.

Tags: #Prompt Engineering #AI Agent #Tool Calling #Structured Output #Evaluation #Acceptance Criteria

Rama Aditya

Founder Rama Digital. Menulis tentang digital marketing, web development, AI, dan sistem operasional untuk bisnis Indonesia.

Tentang Rama Digital