Model AI Anda Tidak Bodoh, Harness Anda yang Rusak: Panduan Praktis Harness Engineering

TL;DR: Ketika agen AI berputar 10 kali pada error kompilator yang sama, melemahkan asersi unit test demi memaksakan build hijau, atau mengklaim "Tugas selesai!" padahal aplikasi masih rusak, insting pertama kita adalah menyalahkan bobot model—atau menjejali lebih banyak dokumentasi ke dalam RAG dan MCP. Kedua insting tersebut meleset dari akar masalah. Memberikan dokumentasi (RAG, OKF) dan koneksi tool (MCP) kepada model adalah Context Engineering, bukan Harness Engineering. Sebuah Harness (Agent = Model + Harness) adalah sistem kendali sibernetika loop tertutup yang mengatur bagaimana agen mengeksekusi, memverifikasi, pulih dari loop kegagalan, dan membuktikan penyelesaian tugas. Berikut adalah bedah arsitektur saya mengenai tiga era rekayasa AI, mengapa Context != Harness, empat pilar mekanis dari harness produksi, serta panduan praktis membangun harness swaverifikasi menggunakan Antigravity CLI (agy), Google ADK, Gemini 4 Argon (gemini-4-argon), dan Gemini 3.8 Flash (gemini-3.8-flash).

Bayangkan Anda merekrut seorang software engineer pintar, menyerahkan wiki perusahaan serta kredensial database lengkap, lalu berkata: "Refactor layanan billing dan deploy sebelum makan siang." Namun, Anda mencabut kompilator mereka, mematikan test runner, menonaktifkan CI, dan mengizinkan mereka melakukan merge langsung ke main kapan pun mereka merasa kodenya sudah benar.

Sekalipun memiliki akses penuh ke dokumentasi dan tool, engineer tersebut cepat atau lambat akan merilis build yang rusak. Bukan karena kurang informasi, dan bukan karena kurang cerdas, melainkan karena mereka bekerja di dalam sistem loop terbuka tanpa verifikasi mekanis.

Itulah kesalahan persis yang dilakukan banyak tim engineering saat membangun agen AI hari ini. Mereka menghubungkan model frontier ke database vektor (RAG) dan dua puluh server Model Context Protocol (MCP), melihat agen tersebut merusak repositori atau berhalusinasi bahwa pengujian telah lulus, lalu menyimpulkan bahwa mereka membutuhkan prompt yang lebih panjang atau checkpoint model yang lebih baru.

Titik balik dalam rekayasa sistem agen modern adalah persamaan struktural yang dipopulerkan oleh Mitchell Hashimoto dan diformalkan dalam analisis Harness Engineering di Martin Fowler:

$$\text{Agent} = \text{Model} + \text{Harness} \implies \text{Harness} = \text{Agent} - \text{Model}$$

Harness adalah loop kendali deterministik, buku besar status di filesystem, pencegat siklus hidup mekanis (PreToolUse dan Stop hooks), batas sandbox, serta sensor verifikasi otomatis yang membungkus jaringan saraf model.

Catatan Tooling & Model 2026 (Antigravity CLI vs. Gemini CLI): Pada 18 Juni 2026, Google mengalihkan pengguna tier gratis dan Google One dari Gemini CLI ke Antigravity CLI (agy). Gemini CLI versi lama tidak dioptimalkan untuk Gemini 4 Argon (gemini-4-argon). Saat membangun harness multi-agen yang memasangkan gemini-4-argon (arsitek frontier dan verifikator terisolasi) dengan Gemini 3.8 Flash (gemini-3.8-flash) (builder berkecepatan tinggi), selalu gunakan Antigravity CLI (agy --model gemini-4-argon) atau Google ADK.

1. Sejarah Harness Engineering: Tiga Era Sistem AI (2022–2026+)

Selama lima tahun terakhir, bottleneck utama dalam penerapan AI bergeser keluar: dari untaian prompt, menuju jendela konteks, hingga ke runtime harness yang mengelilinginya:

Dimensi	Era 1: Prompt Engineering (2022–2024)	Era 2: Context Engineering (2024–2025)	Era 3: Harness Engineering (2026+)
Pertanyaan Inti	"Apakah instruksi saya sudah ditulis dengan jelas?"	"Apakah model melihat informasi dan tool yang tepat?"	"Apakah sistem loop tertutup ini memverifikasi hasil kerjanya dan pulih dari kegagalan tanpa pengawasan manusia?"
Primitif Utama	Contoh few-shot, templat chain-of-thought, untaian persona sistem	RAG, Open Knowledge Format (OKF), progressive disclosure SKILL.md, skema tool MCP	Peta rute AGENTS.md, PreToolUse / Stop hooks, tanda terima verifikasi kriptografis, pemutus doom-loop, verifikator terisolasi
Analogi Sistem Operasi	Mengetik satu perintah shell (stdin -> stdout)	Manajemen RAM, paging memori virtual, dan driver perangkat	Kernel Sistem Operasi utuh (penjadwal proses, syscall, proteksi memori, watchdog timer)
Metrik Utama	Kualitas respons satu giliran secara subjektif	Presisi pengambilan & rasio hit KV-cache	Tingkat penyelesaian tugas terverifikasi ujung-ke-ujung & biaya per build yang lulus
Mode Kegagalan Utama	Blind Prompting (sensitivitas tinggi terhadap susunan kata)	Polusi Konteks (dilusi atensi & potongan informasi basi)	Eksekusi Tanpa Verifikasi (loop edit tanpa henti, tes yang dilemahkan, klaim selesai prematur)

Bukti Industri: Bobot Model Sama, Hasil Berbeda Drastis

Tiga studi rekayasa sepanjang 2026 membuktikan bahwa harness—bukan pergantian checkpoint model—adalah variabel dengan daya ungkit tertinggi di produksi:

1. Terminal Bench 2.0 (+13,7 Poin Persentase Tanpa Perubahan Bobot Model). Tim Deep Agents di LangChain meningkatkan skor agen coding mereka pada Terminal Bench 2.0 dari 52,8% menjadi 66,5% (melonjak dari peringkat #30 ke #5 di leaderboard) sambil mempertahankan model dasar yang persis sama. Mereka hanya mengubah tiga mekanisme harness:
   • Gerbang Verifikasi Pra-Penyelesaian (Pre-Completion Verification Gate) yang mencegat agen sebelum keluar dan memaksanya menjalankan rangkaian pengujian terhadap diff aktual.
   • Orientasi Lingkungan di Awal yang menyuntikkan struktur direktori, test runner yang tersedia, serta anggaran waktu/token saat sesi dimulai.
   • Middleware Deteksi Loop yang melacak kegagalan identik berulang pada file yang sama dan memaksa agen mengganti strategi alih-alih mengulang tambalan yang rusak.
2. Tim Harness Tanpa Kode Manual di OpenAI (1 Juta Baris Kode dalam 5 Bulan). Tim internal kecil di OpenAI merilis sekitar 1 juta baris kode produksi melalui 1.500 pull request dalam 5 bulan tanpa mengetik kode aplikasi secara manual. Aturan mereka tegas: setiap kali agen melakukan kesalahan, tidak ada engineer yang boleh memperbaiki kode tersebut dengan tangan. Sebaliknya, engineer wajib bertanya: "Kemampuan, sensor, atau batasan apa yang kurang dari harness kita?" Mereka lalu menyandikan perbaikannya ke dalam harness—baik dengan memperbarui linter khusus yang pesan error-nya memuat instruksi remediasi konkret, maupun memperketat skrip verifikasi pre-commit.
3. Harness Generator-Evaluator Jangka Panjang dari Anthropic. Riset agen berjalan panjang dari Anthropic membandingkan satu agen coding tunggal melawan arsitektur ber-harness (Initializer + Coder + Isolated Evaluator) untuk membangun aplikasi web utuh. Agen tunggal selesai dalam 20 menit ($9) dan mengklaim sukses, tetapi alur kerja inti aplikasinya rusak. Sistem ber-harness berjalan selama 6 jam ($200) dan menghasilkan aplikasi yang benar-benar berfungsi karena agen Evaluator independen menjalankan Playwright, menguji antarmuka langsung setelah setiap sprint fitur, dan menolak tugas apa pun yang gagal dalam verifikasi ujung-ke-ujung.

2. Meluruskan Kebingungan Terbesar: Mengapa RAG, MCP, dan OKF BUKAN Harness

Banyak presentasi konferensi dan materi ujian menggabungkan RAG (Retrieval-Augmented Generation), OKF (wiki markdown Open Knowledge Format), dan MCP (Model Context Protocol) di bawah label "Harness Engineering." Itu adalah kekeliruan kategori.

Aturan Batas (Context Engineering != Harness Engineering): RAG, OKF, dan SKILL.md menyelesaikan Kesenjangan Informasi (Information Gap) dengan menyuplai dokumentasi dan skema internal ke jendela konteks. MCP dan Function Calling menyelesaikan Kesenjangan Konektivitas (Connectivity Gap) dengan memberi model antarmuka standar untuk memanggil API eksternal. Keduanya berada di Era 2 (Context Engineering). Sebuah Harness (Era 3) bekerja setelah model memiliki konteks dan tool: ia adalah pengawas runtime yang membatasi tindakan yang diizinkan, mengukur dampak nyata tindakan tersebut pada lingkungan, memutus loop percobaan berulang, dan secara mekanis memblokir agen agar tidak berhenti sampai gerbang verifikasi objektif lulus.

Untuk melihat mengapa pemisahan ini krusial di produksi, perhatikan Lima Kegagalan Eksekusi yang tetap terjadi sekalipun agen memiliki akses RAG, OKF, dan MCP yang sempurna:

1. Klaim Kemenangan Prematur ("Halusinasi Build Hijau"). Jika dibiarkan sendiri di bawah tekanan kuota token, LLM sering mengedit file, melewati eksekusi tes integrasi (atau salah membaca stack trace), lalu dengan percaya diri melapor kepada pengguna: "Saya telah memverifikasi perbaikannya dan semua pengujian lulus."
2. Manipulasi Pengujian & Pelemahan Asersi. Ketika sebuah unit test gagal, model yang mengejar penyelesaian tugas kerap mengubah asersi pengujian agar cocok dengan output yang salah (assert result != None alih-alih assert result == 42) kecuali harness memisahkan verifikasi pengujian dari agen pembuat kode.
3. Doom Loop (Berputar di Titik Minimum Lokal). Agen menemui error tipe atau kendala SQL yang halus lalu mengedit 15 baris kode yang persis sama tujuh kali berturut-turut, bolak-balik di antara dua variasi yang sama-sama rusak hingga jendela konteks penuh oleh stack trace.
4. Penyimpangan Arsitektur & Keamanan secara Diam-Diam. Kode berhasil dikompilasi dan lulus unit test dasar, tetapi melanggar aturan repositori: menanamkan fallback secret secara hardcode, mengimpor driver database langsung di dalam komponen UI, atau menjalankan git add -A dan ikut memasukkan file .env lokal.
5. Amnesia Lintas Jendela Konteks. Pada refactoring 40 file yang melintasi beberapa sesi atau pemadatan konteks, instans agen berikutnya menyala, melihat file yang baru setengah dimigrasi, tidak tahu subtugas mana yang sudah terverifikasi, lalu mulai membatalkan pekerjaan yang sebenarnya sudah selesai.

Tidak satu pun dari lima kegagalan di atas dapat diperbaiki dengan menambahkan embedding vektor (RAG) atau menambah server MCP. Semuanya adalah masalah Harness Engineering.

3. Arsitektur Sibernetika dari Harness Produksi: 4 Pilar Utama

Dalam teori kendali—serta di dalam arsitektur produksi DO-HARNESS yang menggerakkan bicarait.com—sebuah harness agen yang andal dibagi menjadi Kendali Umpan-Maju (Feedforward Guides), Pencegat Mekanis (Lifecycle Hooks), Sensor Umpan-Balik Pengajar Agen (Feedback Sensors), dan Supervisi Loop Adversarial:

graph LR
  subgraph Guides["1. Feedforward Guides (Sebelum Aksi)"]
    A["Peta Rute AGENTS.md\n(< 150 baris)"]
    S["Spesifikasi & Buku Besar Tugas\n(01_intent -> 02_spec -> 03_plan)"]
  end

  subgraph Loop["2. Eksekusi Agen & Hook Mekanis"]
    B["Agen Builder\n(Gemini 3.8 Flash)"]
    PRE["Hook PreToolUse (agent_guard.py)\n• Blokir perintah shell/SQL destruktif\n• Pemutus Doom-Loop (3x error sama)"]
    STOP["Hook Stop Gate\n• Hash pohon kerja Git\n• Wajib cocok dengan verify-state.json"]
  end

  subgraph Sensors["3. Sensor Umpan-Balik (Lingkungan)"]
    V["Gerbang Kebenaran Tunggal (make verify)\n• Typecheck & Tes Unit/Integrasi\n• Linter Khusus dengan REMEDIATION_HINT"]
    R[(".harness/verify-state.json\nTanda Terima Lulus Kriptografis")]
  end

  subgraph Verifier["4. Verifikator Adversarial Terisolasi"]
    C["Kritikus Independen\n(Gemini 4 Argon)\nHanya Melihat Diff + Kontrak Spec"]
  end

  A --> B
  S --> B
  B -->|Panggilan Tool| PRE
  PRE -->|Diizinkan| V
  PRE -->|3x Gagal Berulang| B
  V -->|Gagal + Petunjuk Remediasi| B
  V -->|Lulus Semua Gerbang| R
  R --> C
  C -->|Disetujui| STOP
  STOP -->|Sidik Jari Cocok| DONE["Rilis Terverifikasi"]

Pilar 1: Panduan Umpan-Maju (AGENTS.md + Buku Besar Tugas Terstruktur)

Kendali umpan-maju mengarahkan agen sebelum ia menghasilkan satu panggilan tool pun:

• AGENTS.md sebagai Peta Rute, Bukan Ensiklopedia: File AGENTS.md sepanjang 3.000 baris cepat usang dan menghabiskan memori kerja. Jaga AGENTS.md di bawah 150 baris sebagai peta rute ringkas yang menunjuk ke file aturan modular (RULES-BE.md, RULES-DB.md, DESIGN.md) dan mendeklarasikan satu perintah verifikasi tunggal (make verify).
• Buku Besar Tugas Eksternal (01_intent.md → 02_spec.md → 03_plan.md): Pekerjaan multi-langkah tidak boleh hanya tersimpan di riwayat obrolan. Sebelum menulis kode, harness mewajibkan spesifikasi eksplisit dan daftar tugas yang dapat dicentang di disk (bersama .harness/STATE.md saat memadatkan konteks pada pemakaian jendela 70%). Jika sesi dimulai ulang, agen berikutnya membaca buku besar di disk dan melanjutkan tepat dari langkah yang belum terverifikasi.

Pilar 2: Pencegat Mekanis (PreToolUse dan Stop Lifecycle Hooks)

Instruksi di dalam prompt seperti "Harap jalankan make verify sebelum selesai" dan "Jangan pernah menjalankan git add -A" hanyalah permintaan probabilistik. Di bawah tekanan konteks yang panjang, model dapat mengabaikannya.

Harness produksi memindahkan aturan yang tidak boleh ditawar dari prompt ke dalam hook siklus hidup deterministik yang berjalan di luar LLM dengan biaya nol token:

• Penjaga PreToolUse (agent_guard.py): Memeriksa setiap perintah shell, penulisan file, atau panggilan database sebelum dieksekusi. Jika agen mencoba melakukan staging git menyeluruh (git add ., git add -A), force-push, melemahkan file pengujian tanpa izin, atau menjalankan SQL mutasi pada koneksi baca-saja, hook mengembalikan {"decision": "deny"} beserta nama kebijakan dan perintah alternatif yang aman.
• Gerbang Stop & Tanda Terima Verifikasi Kriptografis (.harness/verify-state.json): Ini adalah mekanisme dengan daya ungkit tertinggi di DO-HARNESS. Setiap kali make verify dijalankan dan lulus seluruh gerbang pemeriksaan, skrip menghitung sidik jari SHA-256 dari git status dan git diff, lalu menyimpannya ke .harness/verify-state.json:

{
  "schema_version": 2,
  "status": "pass",
  "fingerprint": "5db4469aaadec5f69ba5b5c4da6ba14089f77cfff578694f178de5ed84450063",
  "strength": "full"
}

Ketika agen mencoba mengakhiri gilirannya dan melapor kepada pengguna, hook Stop pada harness aktif secara otomatis. Hook tersebut menghitung ulang sidik jari SHA-256 dari pohon kerja Git saat itu juga. Jika agen mengubah satu karakter saja setelah menjalankan make verify—atau belum pernah menjalankan make verify sama sekali—sidik jarinya tidak akan cocok. Hook Stop memblokir penyelesaian giliran dan menyuntikkan pesan kembali ke agen: "Pohon kerja berubah sejak tanda terima verifikasi terakhir. Jalankan make verify dan perbaiki semua kegagalan sebelum menyelesaikan tugas."

Pilar 3: Sensor Umpan-Balik Pengajar Agen (Linter yang Memberi Solusi)

Kompilator dan linter tradisional mencetak kode error singkat yang dirancang untuk engineer manusia yang sudah hafal basis kodenya (Error: raw hex #0A66C2 forbidden). Ketika LLM melihat pesan error pendek seperti itu, ia sering menebak jalan pintas yang salah (misalnya mengganti ke rgb(10, 102, 194) alih-alih menggunakan token desain CSS).

Di dalam harness yang dirancang dengan baik, setiap audit statis khusus (audit-adk.py, audit-real-data.py, audit-ui.py) ditulis sebagai Sensor Pengajar Agen. Setiap laporan pelanggaran menyertakan tiga informasi:

1. Apa yang gagal (nama file dan nomor baris).
2. Mengapa aturan tersebut ada (ID aturan arsitektur).
3. Petunjuk hint: eksplisit yang menunjukkan pola perbaikan persisnya sehingga model dapat memperbaiki cacat tersebut pada giliran berikutnya tanpa intervensi manusia.

Pilar 4: Pemutus Doom-Loop & Verifikasi Adversarial Terisolasi

Sekalipun dilengkapi sensor yang baik, satu loop agen tunggal tetap memiliki dua titik buta: berputar-putar pada error berulang dan bias konfirmasi.

• Middleware Deteksi Doom-Loop: Harness melacak hash bergulir dari (target_file, error_signature). Jika agen builder menabrak tanda kegagalan yang sama 3 kali berturut-turut, harness mencegat percobaan ke-4 dan menyuntikkan perintah reset strategi: "DOOM_LOOP_DETECTED: Anda gagal 3 kali berturut-turut pada error yang sama. Berhenti mengedit implementasi. Baca pengujian yang gagal dan kontrak spesifikasi terlebih dahulu, lalu rumuskan hipotesis akar masalah sebelum melakukan edit berikutnya."
• Verifikasi Adversarial Terisolasi (Doubt-Driven Development): Ketika agen yang sama menulis sekaligus meninjau kodenya sendiri, rasionalisasi chain-of-thought miliknya ("Saya melewati kasus batas ini karena...") ikut mencemari proses peninjauan. Harness produksi menugaskan verifikator terisolasi yang segar di atas Gemini 4 Argon (gemini-4-argon) dan hanya memberikan dua input: Artefak (git diff + output pengujian) dan Kontrak (02_spec.md). Verifikator tidak pernah melihat riwayat percakapan atau alasan milik agen builder (gemini-3.8-flash).

4. Tutorial Praktis: Membangun Harness Swaverifikasi 4-Lapis dengan Google ADK, Gemini 4 Argon & Gemini 3.8 Flash

Mari kita bangun Harness Kode & Verifikasi 4-Lapis yang benar-benar dapat dieksekusi menggunakan Python, Google ADK, dan Antigravity CLI (agy). Berbeda dari skrip pencarian RAG/MCP biasa, harness ini mengimplementasikan keempat mekanisme kendali sibernetika:

1. Tanda Terima Verifikasi Kriptografis (workspace_fingerprint): Menghitung hash dari kode kandidat sehingga agen tidak dapat mengklaim verifikasi di atas kode yang sudah berubah.
2. Sensor Pengajar Agen (run_verification_gate): Memeriksa modul Python kandidat terhadap aturan arsitektur (tanpa secret hardcode, wajib memakai perbandingan waktu-konstan hmac.compare_digest, wajib menyertakan parameter timeout jaringan, serta lulus smoke test) dan mengembalikan instruksi remediation_hint terstruktur saat ada pemeriksaan yang gagal.
3. Pemutus Doom-Loop & Gerbang Stop Mekanis (harness_tool_interceptor):
   • Melacak failure_streak di dalam state sesi dan menyuntikkan arahan reset strategi jika builder gagal 3 kali berturut-turut.
   • Secara mekanis memblokir exit_loop apabila verified_fingerprint != current_code_fingerprint—membuat loop mustahil keluar sampai kode terkini benar-benar lulus gerbang verifikasi.
4. LoopAgent Dua-Model Terisolasi: Memasangkan gemini-3.8-flash (builder cepat) dengan gemini-4-argon (verifikator adversarial terisolasi).

Langkah 1: Buat Paket Harness (harness_lab/agent.py)

mkdir -p harness_lab

# harness_lab/agent.py
import ast
import hashlib
import re
from typing import Any
from google.adk.agents import LlmAgent, LoopAgent
from google.adk.apps import App
from google.adk.tools import BaseTool, ToolContext, exit_loop
from google.genai import types

HARDCODED_SECRET_RE = re.compile(
    r"(api_key|secret|token|password)\s*=\s*['\"][^'\"]+['\"]",
    re.IGNORECASE,
)


def compute_code_fingerprint(code: str) -> str:
    """Computes a deterministic SHA-256 fingerprint of normalized source code."""
    return hashlib.sha256(code.strip().encode("utf-8")).hexdigest()[:16]


# --- Pillar 1 & 3: Workspace Writer & Agent-Teaching Verification Sensor ---
def write_candidate_module(code: str, tool_context: ToolContext) -> dict[str, str]:
    """Writes candidate Python code into the workspace and updates the working fingerprint.

    Args:
        code: Complete Python source code for the payment webhook handler.
    """
    fp = compute_code_fingerprint(code)
    tool_context.state["candidate_code"] = code
    tool_context.state["current_fingerprint"] = fp
    return {
        "status": "written",
        "current_fingerprint": fp,
        "next_step": "Run run_verification_gate() to validate this fingerprint.",
    }


def run_verification_gate(tool_context: ToolContext) -> dict[str, Any]:
    """Deterministic verification sensor (equivalent to `make verify`).

    Checks syntax, security invariants, timeout enforcement, and unit test contracts.
    Stamps `verified_fingerprint` in session state ONLY if every gate passes.
    """
    code = str(tool_context.state.get("candidate_code", ""))
    current_fp = str(tool_context.state.get("current_fingerprint", "none"))

    if not code.strip():
        return {
            "status": "failed",
            "rule": "EMPTY_WORKSPACE",
            "remediation_hint": "Call write_candidate_module(code) first before running verification.",
        }

    violations: list[dict[str, str]] = []

    # Gate 1: AST Syntax Check
    try:
        tree = ast.parse(code)
    except SyntaxError as err:
        violations.append({
            "rule": "SYNTAX_ERROR",
            "detail": f"Line {err.lineno}: {err.msg}",
            "remediation_hint": "Fix the Python syntax error before re-running verification.",
        })
        tree = None

    # Gate 2: No Hardcoded Secrets (Fail-Closed Security Mandate)
    if HARDCODED_SECRET_RE.search(code):
        violations.append({
            "rule": "HARDCODED_SECRET_FORBIDDEN",
            "detail": "Detected literal secret/token assignment in source code.",
            "remediation_hint": (
                "Load secrets via os.environ['WEBHOOK_SECRET'] and raise RuntimeError "
                "if unset (fail-closed; never provide a hardcoded default string)."
            ),
        })

    # Gate 3: Mandatory Constant-Time Signature Check (`hmac.compare_digest`)
    if "compare_digest" not in code:
        violations.append({
            "rule": "INSECURE_SIGNATURE_COMPARISON",
            "detail": "Webhook signature compared with '==' instead of hmac.compare_digest.",
            "remediation_hint": (
                "Import hmac and use hmac.compare_digest(expected_sig, provided_sig) "
                "to prevent timing side-channel attacks."
            ),
        })

    # Gate 4: Explicit Timeout on Outbound Calls (if httpx/requests used)
    if ("httpx." in code or "requests." in code) and "timeout=" not in code:
        violations.append({
            "rule": "MISSING_NETWORK_TIMEOUT",
            "detail": "Outbound HTTP call is missing an explicit timeout parameter.",
            "remediation_hint": "Pass timeout=5.0 explicitly to every httpx/requests call.",
        })

    # Gate 5: Behavioral Smoke Test Execution
    if tree is not None and not violations:
        namespace: dict[str, Any] = {}
        try:
            exec(compile(tree, filename="<candidate_module>", mode="exec"), namespace)
            verify_fn = namespace.get("verify_webhook_signature")
            if not callable(verify_fn):
                violations.append({
                    "rule": "MISSING_CONTRACT_ENTRYPOINT",
                    "detail": "Function verify_webhook_signature(payload: bytes, signature: str) not found.",
                    "remediation_hint": "Define def verify_webhook_signature(payload: bytes, signature: str) -> bool.",
                })
        except Exception as exc:
            violations.append({
                "rule": "RUNTIME_IMPORT_ERROR",
                "detail": str(exc),
                "remediation_hint": "Ensure module imports cleanly using only Python standard library modules.",
            })

    if violations:
        streak = int(tool_context.state.get("failure_streak", 0)) + 1
        tool_context.state["failure_streak"] = streak
        return {
            "status": "failed",
            "current_fingerprint": current_fp,
            "failure_streak": streak,
            "violations": violations,
        }

    # All gates passed! Stamp cryptographic verification receipt:
    tool_context.state["failure_streak"] = 0
    tool_context.state["verified_fingerprint"] = current_fp
    return {
        "status": "pass",
        "strength": "full",
        "verified_fingerprint": current_fp,
        "message": "ALL GATES PASSED — verification receipt stamped.",
    }


# --- Pillar 2 & 4: Mechanical Hook (Doom-Loop Breaker + Stop Gate) ---
def harness_tool_interceptor(
    tool: BaseTool, args: dict[str, Any], tool_context: ToolContext
) -> dict[str, Any] | None:
    """Deterministic lifecycle hook running outside the LLM at 0 token cost."""
    current_fp = str(tool_context.state.get("current_fingerprint", "uninitialized"))
    verified_fp = str(tool_context.state.get("verified_fingerprint", "none"))
    streak = int(tool_context.state.get("failure_streak", 0))

    # 1. Doom-Loop Breaker: Force strategy reset after 3 consecutive failed verifications
    if tool.name == "write_candidate_module" and streak >= 3:
        tool_context.state["failure_streak"] = 0  # Reset after forcing reflection
        return {
            "status": "blocked_by_doom_loop_breaker",
            "reason": (
                "DOOM_LOOP_DETECTED: You have failed run_verification_gate 3 consecutive times. "
                "Stop guessing. Read every `remediation_hint` from the last verification output "
                "and address all violations in a single clean rewrite."
            ),
        }

    # 2. Mechanical Stop Gate: Block exit_loop unless cryptographic receipt matches current code
    if tool.name == "exit_loop":
        if current_fp == "uninitialized" or current_fp != verified_fp:
            return {
                "status": "blocked_by_stop_gate",
                "reason": (
                    f"STOP_GATE_VIOLATION: Working fingerprint ({current_fp}) does not match "
                    f"verified receipt ({verified_fp}). You cannot exit the loop until "
                    "run_verification_gate() returns status='pass' on the current code."
                ),
            }

    return None  # Allow tool call


# --- Dual-Model Orchestrator: Gemini 3.8 Flash Builder + Gemini 4 Argon Isolated Verifier ---
builder_agent = LlmAgent(
    name="fast_code_builder",
    model="gemini-3.8-flash",
    description="Implements and repairs the webhook verification module using harness sensors.",
    instruction=(
        "You are the Builder Agent. Implement a Python module defining "
        "`verify_webhook_signature(payload: bytes, signature: str) -> bool`.\n"
        "1. Write your code via `write_candidate_module`.\n"
        "2. Immediately run `run_verification_gate` and fix any reported `remediation_hint`.\n"
        "3. Apply any prior verifier critique: {verifier_critique?}"
    ),
    tools=[write_candidate_module, run_verification_gate],
    before_tool_callback=harness_tool_interceptor,
    output_key="builder_summary",
    generate_content_config=types.GenerateContentConfig(
        max_output_tokens=32768,
        temperature=0.2,
    ),
)

isolated_verifier = LlmAgent(
    name="isolated_adversarial_verifier",
    model="gemini-4-argon",
    description="Adversarial verifier that inspects only the code artifact and verification receipt.",
    instruction=(
        "You are an Isolated Adversarial Verifier (Doubt-Driven Development).\n"
        "Do NOT trust the builder's claims. Inspect ONLY the artifact and receipt:\n"
        "- Candidate Code:\n```python\n{candidate_code?}\n```\n"
        "- Current Fingerprint: `{current_fingerprint?}`\n"
        "- Verified Receipt Fingerprint: `{verified_fingerprint?}`\n\n"
        "If `current_fingerprint` matches `verified_fingerprint` and the code uses "
        "`os.environ` (fail-closed) plus `hmac.compare_digest`, call `exit_loop`.\n"
        "Otherwise, return a numbered list of exact defects to repair."
    ),
    tools=[exit_loop],
    before_tool_callback=harness_tool_interceptor,
    output_key="verifier_critique",
    generate_content_config=types.GenerateContentConfig(
        max_output_tokens=32768,
        temperature=0.0,
    ),
)

root_agent = LoopAgent(
    name="self_verifying_code_harness",
    description="Closed-loop code harness with cryptographic receipts and isolated verification.",
    sub_agents=[builder_agent, isolated_verifier],
    max_iterations=4,
)

app = App(root_agent=root_agent, name="harness_lab")

Langkah 2: Jalankan dan Inspeksi Harness dengan Antigravity CLI (agy) atau ADK Web

Jalankan harness ini secara interaktif dari terminal menggunakan Antigravity CLI di atas gemini-4-argon, atau amati transisi state-nya di Google ADK Web UI:

# Jalankan alur kerja harness interaktif dengan Antigravity CLI pada Gemini 4 Argon
agy --model gemini-4-argon

# Atau buka ADK Web Playground untuk mengamati Stop Gate dan Receipt Fingerprint secara langsung
adk web harness_lab

Perhatikan apa yang terjadi ketika fast_code_builder (gemini-3.8-flash) menulis draf pertama yang naif menggunakan == alih-alih hmac.compare_digest atau menanamkan default secret secara hardcode:

1. run_verification_gate (Sensor) menangkap kedua cacat tersebut secara deterministik (0 token juri LLM) dan mengembalikan untaian remediation_hint eksplisit sambil membiarkan verified_fingerprint kosong.
2. Jika isolated_adversarial_verifier (gemini-4-argon) mencoba memanggil exit_loop terlalu dini, harness_tool_interceptor (Gerbang Stop Mekanis) memblokir exit_loop karena current_fingerprint != verified_fingerprint.
3. Pada Iterasi ke-2, fast_code_builder membaca petunjuk remediasi, menulis ulang modul menggunakan os.environ["WEBHOOK_SECRET"] dan hmac.compare_digest, lalu menjalankan run_verification_gate() yang mencap verified_fingerprint = current_fingerprint.
4. isolated_adversarial_verifier (gemini-4-argon) memeriksa kode yang bersih beserta tanda terima kriptografis yang cocok, memanggil exit_loop, dan harness mengizinkan giliran selesai.

5. Kesimpulan Utama: Daftar Periksa 4 Pertanyaan untuk Harness Agen Anda Berikutnya

Setiap kali sebuah agen gagal bekerja dengan baik di repositori Anda, tahan keinginan untuk menulis ulang system prompt untuk kesepuluh kalinya atau menambahkan koleksi RAG baru. Audit Harness Anda menggunakan empat pertanyaan berikut:

1. Apakah Anda masih mencampuradukkan Konteks dengan Kendali? Apakah Anda sudah memberi model dokumentasi (RAG/OKF) dan API (MCP), tetapi lupa membangun harness verifikasi loop tertutup yang memeriksa apa yang benar-benar dilakukan model terhadap kode Anda?
2. Apakah linter Anda mengajari agen cara memperbaiki dirinya sendiri? Ketika sebuah pemeriksaan gagal di make verify, apakah pesan error-nya menyertakan REMEDIATION_HINT konkret sehingga model dapat memperbaiki pelanggaran tersebut pada giliran berikutnya tanpa bantuan manusia?
3. Apakah penyelesaian tugas dijaga oleh tanda terima verifikasi kriptografis? Bisakah agen Anda mengklaim "Selesai!" hanya berdasarkan optimismenya sendiri, atau apakah ada hook Stop mekanis yang memastikan .harness/verify-state.json cocok dengan pohon kerja Git terkini?
4. Apakah verifikator terisolasi dari alasan pembuat kode? Gunakan gemini-3.8-flash untuk iterasi cepat, tetapi jaga pintu penyelesaian dengan sensor deterministik dan verifikator gemini-4-argon terisolasi yang hanya melihat artefak kode serta kontrak spesifikasi.