UndoBench 2026: Memisahkan Task Competence dari Recovery Capability pada AI Agents, Bahaya Naive Retry, dan Arsitektur Fault Recovery Lintas 8 Domain Enterprise

1. Ilusi Nominal Competence: Mengapa Happy-Path Benchmark Menjadi Titik Buta Enterprise

Dalam kurun waktu dua tahun terakhir, adopsi AI coding agents dan multi-tool autonomous workflows telah merambah sektor infrastruktur krusial: perbankan core-banking, provisi cluster Kubernetes, mutasi inventaris e-commerce, hingga alur kerja persetujuan faktur korporat. Metrik yang selama ini dijadikan standar acuan oleh industri—seperti persentase penyelesaian isu pada SWE-bench atau akurasi eksekusi tool pada GAIA—hampir seluruhnya mengukur nominal competence.

Nominal competence hanya menjawab pertanyaan: "Jika seluruh dependensi jaringan stabil, database merespons dengan HTTP 200, dan tidak ada timeout, apakah agen mampu menyelesaikan urutan aksi dengan benar?"

Namun, hukum rekayasa sistem terdistribusi menegaskan bahwa di lingkungan produksi riil:

• Koneksi TCP dapat terputus tepat setelah paket commit SQL dikirimkan ke database tetapi sebelum frame ACK sampai ke klien.
• Gateway pembayaran pihak ketiga (seperti Stripe atau Midtrans) dapat merespons dengan HTTP 504 Gateway Timeout padahal otorisasi kartu debit pengguna telah berhasil didebit.
• Operasi komposit (composite mutation) seperti CreateUserAccount() lalu AssignCloudLicense() dapat gagal di langkah kedua karena kuota lisensi habis, meninggalkan akun dalam status setengah matang (dangling state).

Ketika kegagalan ini terjadi, agen tidak dapat lagi bergantung pada prompt statis. Tanpa arsitektur recovery yang terkalibrasi, LLM agen cenderung berhalusinasi atau melakukan blind retry: mengulang kembali pemanggilan API mutasi tanpa memverifikasi apakah efek samping (side-effect) sebelumnya telah terefleksi di server target. Akibatnya, sistem enterprise menderita kerugian finansial nyata dan korupsi integritas data.

2. Metodologi UndoBench: Counterfactual Paired Trials & Wire-Level Effect Oracles

Untuk mengisolasi kapabilitas pemulihan secara saintifik, Sah et al. (2026) merancang UndoBench dengan prinsip pengujian kausal counterfactual:

3. Dekomposisi Tiga Fase Eksekusi: Pre-Mutation, Partial Mutation, dan Lost-Acknowledgment

Salah satu kontribusi terpenting UndoBench adalah bukti empiris bahwa efektivitas strategi recovery sangat bergantung pada fase siklus hidup eksekusi (phase-dependent execution boundaries) ketika fault terjadi:

4. Analisis Kegagalan Empiris: Mengapa Naive Retry Memicu Bencana Duplikasi Efek

Dalam studi frozen lost-acknowledgment pada 12 workflow held-out lintas model open-weight dan commercial frontier API, peneliti mendokumentasikan distribusi kegagalan yang mengejutkan:

Mengapa naive retry menghasilkan tingkat duplikasi hingga 53.33%? Saat agen mengirimkan perintah mutasi (misalnya charge_customer(customerId, $150)) dan menerima status error ECONNRESET atau timeout, prompt eksekusi agen menginstruksikan: "Aksi gagal, coba ulangi kembali." Agen kemudian menerbitkan pemanggilan tool yang identik dengan ID baru, menyebabkan sistem backend menjalankan transaksi untuk kedua kalinya. Karena agen tidak memiliki oracle status lingkungan, agen melaporkan tugas selesai dengan sukses tanpa menyadari bahwa saldo nasabah telah terpotong dua kali.

5. Evaluasi Tiga Paradigma Pemulihan: Journaling, SAGA Compensation, dan Server-Side Idempotency

Riset UndoBench membandingkan tiga pendekatan pemulihan operasional utama yang sering diimplementasikan dalam sistem agen modern:

1. Zero-Privilege Journaling (Pencatatan Audit Pasif): Harness agen mencatat setiap niat aksi sebelum dieksekusi ke dalam log lokal. Pendekatan ini sangat efektif untuk audit forensik dan mendeteksi divergensi state, namun tidak memberikan mekanisme aktif untuk mengembalikan mutasi parsial yang terlanjur terjadi di sistem eksternal.
2. Server-Side Idempotency Keys (IETF Draft): Setiap aksi mutasi disertai header unik Idempotency-Key yang diturunkan dari hash deterministik parameter tugas. Jika jaringan terputus pada fase Lost-ACK, percobaan ulang dari agen akan dikenali oleh server sebagai operasi duplikat dan server mengembalikan respons yang tersimpan di cache tanpa mengeksekusi ulang efek samping. Ini menyelesaikan masalah di Fase 3, namun tidak mampu menangani kegagalan parsial di Fase 2 di mana langkah kedua gagal karena kesalahan logika bisnis.
3. Compensating Transactions (SAGA Pattern): Setiap tool yang memiliki efek samping wajib mendaftarkan fungsi pembalik (compensating action), seperti release_reserved_stock() sebagai pembalik dari reserve_stock(). Jika workflow komposit gagal di tengah jalan, harness secara otomatis mengeksekusi rollback berantai dalam urutan terbalik (backward recovery), mengembalikan sistem ke invariant awal yang konsisten.

6. Implementasi Referensi Produksi: Resilient Agent Harness & Read-Before-Retry Engine (TypeScript)

Berikut adalah implementasi arsitektur produksi TypeScript yang menggabungkan prinsip-prinsip temuan UndoBench: integrasi deterministik SHA-256 Idempotency Keys, pola Read-Before-Retry untuk eliminasi Lost-ACK, dan SAGA Compensation Coordinator untuk proteksi alur kerja komposit.

// Production Architecture: Resilient Tool-Using Agent Harness with SAGA Compensation & State Verification
// Berdasarkan Prinsip Rekayasa UndoBench (arXiv:2610.05622)

import { crypto } from 'crypto';

export type ExecutionPhase = 'PRE_MUTATION' | 'PARTIAL_MUTATION' | 'POST_COMMIT_LOST_ACK';

export interface ToolAction {
  id: string;
  toolName: string;
  parameters: T;
  idempotencyKey: string;
  isMutating: boolean;
  compensatingAction?: (params: T, executionResult: R) => Promise;
  verifyStateOracle?: (params: T) => Promise<{ executed: boolean; actualResult?: R }>;
}

export interface JournalEntry {
  actionId: string;
  toolName: string;
  status: 'PENDING' | 'COMMITTED' | 'FAILED' | 'COMPENSATED';
  payloadHash: string;
  result?: any;
  timestamp: number;
}

export class ResilientAgentExecutionHarness {
  private journal: JournalEntry[] = [];
  private committedMutations: ToolAction[] = [];

  /**
   * Menghasilkan Idempotency Key deterministik berbasis SHA-256 dari parameter aksi
   */
  public generateDeterministicIdempotencyKey(toolName: string, params: any): string {
    const raw = `${toolName}:${JSON.stringify(params)}`;
    return crypto.createHash('sha256').update(raw).digest('hex');
  }

  /**
   * Eksekusi aman aksi mutasi dengan verifikasi pra-kondisi dan penanganan lost-ACK
   */
  public async executeSafeAction(action: ToolAction): Promise {
    const payloadHash = this.generateDeterministicIdempotencyKey(action.toolName, action.parameters);
    
    // 1. READ-BEFORE-RETRY: Verifikasi apakah mutasi sudah mendarat di sistem eksternal
    if (action.verifyStateOracle) {
      const probe = await action.verifyStateOracle(action.parameters);
      if (probe.executed && probe.actualResult) {
        console.warn(`[ORACLE_HIT] Mutation ${action.toolName} already committed. Reusing state without duplicate write.`);
        return probe.actualResult;
      }
    }

    // 2. Catat Jurnal Pra-Eksekusi (Zero-Privilege Journaling)
    const journalRecord: JournalEntry = {
      actionId: action.id,
      toolName: action.toolName,
      status: 'PENDING',
      payloadHash,
      timestamp: Date.now(),
    };
    this.journal.push(journalRecord);

    try {
      // 3. Eksekusi Aksi Mutasi dengan Idempotency Header
      const result = await this.invokeExternalToolAPI(action.toolName, action.parameters, action.idempotencyKey);
      
      journalRecord.status = 'COMMITTED';
      journalRecord.result = result;
      
      if (action.isMutating) {
        this.committedMutations.push(action);
      }
      
      return result;
    } catch (error: any) {
      journalRecord.status = 'FAILED';
      console.error(`[FAULT_DETECTED] Tool ${action.toolName} failed: ${error.message}`);

      // 4. SAGA ROLLBACK: Batalkan mutasi berantai jika terjadi kegagalan parsial
      await this.rollbackCommittedMutations();
      throw error;
    }
  }

  /**
   * Kompensasi mundur (Backward Recovery) untuk mengembalikan status sistem ke invariant valid
   */
  private async rollbackCommittedMutations(): Promise {
    console.log('[SAGA_COMPENSATION] Rolling back partially committed mutations in reverse order...');
    while (this.committedMutations.length > 0) {
      const lastAction = this.committedMutations.pop()!;
      if (lastAction.compensatingAction) {
        try {
          await lastAction.compensatingAction(lastAction.parameters, null);
          console.log(`[COMPENSATED] Successfully rolled back ${lastAction.toolName}`);
        } catch (compensationError: any) {
          console.error(`[CRITICAL_COMPENSATION_FAILURE] Failed to rollback ${lastAction.toolName}: ${compensationError.message}`);
        }
      }
    }
  }

  private async invokeExternalToolAPI(tool: string, params: any, idempotencyKey: string): Promise {
    // Simulasi wire call dengan Idempotency Key
    return { status: 200, success: true, tool, payload: params, idempotencyKey };
  }
}

7. Rekomendasi Rekayasa 2026: Blueprint Desain Sistem Agen yang Tahan Terhadap Bencana Operasional

Berdasarkan temuan saintifik UndoBench, arsitek sistem software dan tim rekayasa AI enterprise wajib menerapkan 5 prinsip desain non-negosiabel berikut sebelum mendeploy agen otonom ke lingkungan produksi:

• 1. Hapus Kebijakan Naive Blind Retry dari Prompt Agen: Jangan pernah membiarkan instruksi ReAct atau prompt sistem mengulang panggilan fungsi secara membabi buta setelah menerima error timeout atau connection reset. Setiap pengulangan aksi mutasi wajib diawali dengan query status (Read-Before-Retry).
• 2. Wajibkan Idempotency Keys Deterministik pada Semua Mutating Tools: Setiap tool yang memodifikasi state (POST, PUT, DELETE, SQL INSERT/UPDATE) harus membungkus payload dengan kunci idempotensi deterministik berbasis hash parameter input.
• 3. Terapkan SAGA Pattern pada Setiap Composite Workflow: Untuk alur kerja yang melibatkan lebih dari satu pemanggilan perkakas mutasi, pasangkan setiap aksi dengan aksi kompensasi (compensating action) untuk mengeksekusi automated backward recovery saat terjadi kegagalan parsial.
• 4. Evaluasi Mandiri dengan Metrik Terpisah (Nominal vs CRSR): Uji sistem agen Anda di CI pipeline menggunakan skenario failure injection. Ukur secara terpisah Nominal Competence, Conditional Recovery Success Rate (CRSR), dan Duplicate Effect Ratio (DER).
• 5. Terapkan Wire-Level Effect Oracles di Lingkungan Uji: Jangan mempercayai laporan teks agen bahwa ia telah memulihkan transaksi. Verifikasi state fisik langsung pada database atau wire network untuk memastikan tidak ada side-effects tersembunyi yang tertinggal.

UndoBench menandai berakhirnya era di mana kemampuan agen hanya dinilai dari keberhasilannya bernavigasi di jalan bebas hambatan. Di era produksi enterprise 2026, kematangan arsitektur sistem agen diukur dari seberapa tangguh ia melindungi integritas data ketika seluruh infrastruktur di sekitarnya runtuh.