FDE-Gym (arXiv:2610.22350): The Last Mile of AI Delivery, Mengapa Agen AI Gagal pada Sistem Live Enterprise, dan Evaluasi 95 Task Lintas 18 Sektor Industri

Selama dua tahun terakhir, komunitas AI merayakan lonjakan skor agen otonom pada berbagai tolok ukur rekayasa perangkat lunak seperti SWE-bench, HumanEval, dan Terminal-Bench. Model-model terdepan kini mampu menyelesaikan puluhan commit bug, memodifikasi repositori GitHub besar, dan mengeksekusi pipeline CLI dalam hitungan menit. Namun, ketika agen-agen berdaya tinggi ini diterjunkan langsung ke dalam sistem operasional perusahaan riil (live enterprise systems), sebuah paradoks mencolok terjadi: solusi yang mereka hasilkan kerap mematuhi perintah sponsor secara harfiah, lulus seluruh unit test lokal, namun gagal memberikan perbaikan terukur pada metrik bisnis pelanggan—atau bahkan memperparah kekacauan operasional.

Gambar 1: Konsep Visual FDE-Gym — Menjembatani jurang pemisah antara penyelesaian tiket kode statis dan delivery sistem AI pada lingkungan produksi riil enterprise.

1. Paradoks "The Last Mile of AI Delivery": Mengapa Benchmark Konvensional Menyesatkan

Hampir seluruh benchmark evaluasi agen AI saat ini dibangun di atas asumsi ideal bahwa spesifikasi masalah telah terdefinisi secara sempurna (well-specified tasks). Pada SWE-bench, agen diberikan issue report terperinci dan diuji terhadap test suite tersembunyi. Pada benchmark deployment, agen dibekali dokumen spesifikasi fungsional yang lengkap. Namun, dunia industri nyata bekerja dengan hukum yang sepenuhnya berlawanan.

Penulis mengilustrasikan dinamika ini melalui sebuah kasus nyata di sektor energi (skenario oil_npt): Seorang Vice President pada operator pengeboran minyak lepas pantai meminta vendor AI untuk membangun email ringkasan harian otomatis dan fitur chat box "Ask your wells" untuk presentasi rapat dewan direksi. Sponsor tersebut secara eksplisit menyatakan bahwa modul pelabelan downtime pengeboran (downtime-coding script) sudah berjalan baik dan berada di luar lingkup (out of scope) pekerjaan proyek.

Gambar 2: Skenario pengeboran minyak lepas pantai (oil_npt). Mengikuti permintaan sponsor secara harfiah menghasilkan skor 0. Agen sejati harus menelusuri kontrak kontraktor, mengidentifikasi script downtime yang cacat, berkoordinasi dengan cost engineer, dan merevisi sistem yang awalnya dianggap "out of scope".

Jika agen AI bekerja layaknya kontraktor pasif yang mematuhi permintaan sponsor secara harfiah, agen akan membangun fitur chatbot tersebut tepat waktu dan lulus semua unit test fungsional. Namun, dampaknya terhadap metrik finansial perusahaan bernilai nol. Masalah kritis sebenarnya terletak pada klaim kredit downtime bulanan: skrip berbasis regex kata kunci yang ada saat ini secara keliru mengatribusikan downtime ke kontraktor rig, memicu penolakan klaim senilai ratusan ribu dolar setiap bulannya.

Seorang Forward-Deployed Engineer (FDE) manusia yang kompeten tidak akan sekadar membangun chat box yang diminta. FDE akan memeriksa kontrak legal rig, menginterogasi cost engineer di lapangan, mengidentifikasi bug logika pada modul yang "dilarang disentuh", mendapatkan persetujuan pejabat berwenang (yang mungkin sedang cuti minggu itu), dan merilis perbaikan yang secara terukur mengamankan klaim kompensasi operasional.

2. Arsitektur FDE-Gym: 95 Task, 20 Skenario, dan 18 Sektor Industri

FDE-Gym v1.0 dikembangkan oleh para praktisi industri yang telah mengeksekusi proyek delivery enterprise nyata di Singapura, Tiongkok, dan Amerika Serikat. Skenario yang dihadirkan mencakup perbankan, logistik, manufaktur, jaringan listrik, layanan kesehatan, hingga robotika gudang:

Gambar 3: Pipeline konstruksi FDE-Gym — Dari adaptasi 20 proyek industri riil, variasi fakta kunci anti-hafalan, validasi anchor skor, hingga simulasi lingkungan produksi terisolasi.

3. Isolasi Kegagalan: Eksperimen 4 Tingkat Instruksi (L0 hingga L3)

Untuk mengidentifikasi di fase mana agen AI mengalami kegagalan, FDE-Gym merancang protokol empat tingkat instruksi (Task Instruction Levels). Workspace, basis data legacy, daftar stakeholder, dan evaluator bersifat identik; hanya teks instruksi awal yang divariasikan secara bertahap:

4. Formulasi Skor FDE-Gym: Dari Business Uplift hingga Denda Kontak Stakeholder

Berbeda dengan metrik biner lulus/gagal (pass/fail accuracy), sistem delivery FDE-Gym dinilai berdasarkan seberapa besar ia menggeser metrik bisnis riil pada data produksi held-out:

Gambar 4: Komponen anatomi task FDE-Gym — Input task, tindakan modifikasi sistem oleh agen, deployment tanpa intervensi manusia, evaluasi KPI held-out, dan pemotongan biaya komunikasi stakeholder.

Secara formal, evaluasi FDE-Gym dihitung melalui 4 tahapan deterministik:

5. Hasil Empiris: Skor 13 Model Frontier dan 5 Fakta Mengejutkan

Riset ini mengevaluasi 13 konfigurasi model frontier dari 7 laboratorium AI global (1.976 pengujian terstandarisasi). Setiap agen dibekali antarmuka minimal 5 tools CLI standar (execute_command, read_file, write_file, edit_file, list_files).

Gambar 5: (a) Skor rata-rata L3 seluruh model pada 95 task setelah pemotongan contact cost (bar pekat). (b) Degradasi drastis performa saat informasi instruksi dikurangi dari L0 ke L3.

Gambar 6: (a) Persentase fakta kunci yang berhasil digali agen vs Business Uplift. Meskipun model terdepan menggali 72–85% fakta, skor uplift mentok di 0.60–0.70. (b) Biaya komputasi API vs Skor FDE-Gym (spending lebih besar tidak menjamin skor tinggi).

Gambar 7: Matriks performa 13 model pada 20 skenario industri. Warna merah mengindikasikan kerusakan di bawah baseline do-nothing (< 0), sedangkan biru menunjukkan keberhasilan mendekati referensi ahli.

Gambar 8: Mengapa benchmark lain memberi rasa aman semu — Model yang meraih akurasi 80%+ pada Terminal-Bench 2.1 atau Vibe Code Bench ambruk ketika diuji pada FDE-Gym.

6. Implementasi TypeScript: FDE-Gym Scoring Harness & Stakeholder Penalty Tracker

Di bawah ini adalah implementasi referensi modul evaluasi FDE-Gym dalam TypeScript, mencakup kalkulasi Normalized Business Uplift, Incident Adjustment, degradasi kesabaran stakeholder, denda trial environment, dan agregasi skor benchmark terpotong (truncated average):

// Production Implementation: FDE-Gym Execution Harness, Stakeholder Penalty Tracker & Metric Scorer
// Berdasarkan formulasi formal paper arXiv:2610.22350 (DeepLethe, Tsinghua, SJTU)
// Mengimplementasikan:
// 1. Normalized Business Uplift (Eq. 1: U = (KPI_del - KPI_base) / (KPI_ref - KPI_base))
// 2. Incident Adjustment Guard (Eq. 2: U_adj = incident ? min(U, 0) : U)
// 3. Stakeholder Contact Cost with Patience Depletion & Penalties (Eq. 3: C = sum(c_k))
// 4. Final FDE-Gym Score (Eq. 4: S = U_adj - C) & Resolution Threshold (S >= 0.8 && !incident)
// 5. Truncated Average Aggregator across Scenarios (Eq. 5: max(U_adj, -1) - C)

export interface StakeholderRule {
  id: string;
  name: string;
  role: string;
  costPerMessage: number; // Base cost rate in normalized units
  patienceTurns: number;
  unauthorizedContactPenalty: number;
  requiresEvidence: boolean;
  isAvailable: boolean;
  unavailabilityReason?: string;
}

export interface ContactEvent {
  stakeholderId: string;
  turn: number;
  message: string;
  hasSupportingEvidence: boolean;
  isTrialRun: boolean;
  isWaitingDay: boolean;
}

export interface TaskOutcome {
  scenarioId: string;
  taskLevel: 'L0' | 'L1' | 'L2' | 'L3';
  kpiBaseline: number;
  kpiDelivered: number;
  kpiReference: number;
  metricDirection: 'maximize' | 'minimize';
  incidentOccurred: boolean;
  incidentType?: 'unauthorized_action' | 'data_corruption' | 'safety_violation';
}

export class FDEGymScoringHarness {
  private stakeholders: Map<string, StakeholderRule> = new Map();
  private contactHistory: ContactEvent[] = [];
  private stakeholderTurns: Map<string, number> = new Map();

  constructor(stakeholders: StakeholderRule[]) {
    for (const sh of stakeholders) {
      this.stakeholders.set(sh.id, sh);
      this.stakeholderTurns.set(sh.id, 0);
    }
  }

  /**
   * Evaluasi interaksi stakeholder dan hitung contact cost (Eq. 3)
   */
  public recordContact(contact: ContactEvent): { costIncurred: number; responseMessage: string } {
    const sh = this.stakeholders.get(contact.stakeholderId);
    if (!sh) {
      throw new Error(`Unknown stakeholder ID: ${contact.stakeholderId}`);
    }

    const currentTurns = (this.stakeholderTurns.get(sh.id) || 0) + 1;
    this.stakeholderTurns.set(sh.id, currentTurns);
    this.contactHistory.push(contact);

    let cost = sh.costPerMessage;

    // Check availability
    if (!sh.isAvailable) {
      cost += sh.unauthorizedContactPenalty;
      return {
        costIncurred: cost,
        responseMessage: `[SYSTEM] Stakeholder ${sh.name} is currently out of office: ${sh.unavailabilityReason}. Penalty charged.`
      };
    }

    // Check evidence requirement
    if (sh.requiresEvidence && !contact.hasSupportingEvidence) {
      cost += sh.costPerMessage * 1.5;
      return {
        costIncurred: cost,
        responseMessage: `[STAKEHOLDER ${sh.name}]: I cannot disclose this constraint without verified authorization or diagnostic log evidence.`
      };
    }

    // Check patience threshold
    if (currentTurns > sh.patienceTurns) {
      const overPatienceFactor = (currentTurns - sh.patienceTurns) * 0.5;
      cost += sh.costPerMessage * (1.0 + overPatienceFactor);
    }

    // Trial environment run and calendar waiting day charges
    if (contact.isTrialRun) cost += 0.04;
    if (contact.isWaitingDay) cost += 0.02;

    return {
      costIncurred: cost,
      responseMessage: `[STAKEHOLDER ${sh.name}]: Verified requirement acknowledged.`
    };
  }

  /**
   * Hitung Normalized Business Uplift (Eq. 1), Incident Adjustment (Eq. 2),
   * Stakeholder Contact Cost (Eq. 3), dan FDE-Gym Score (Eq. 4).
   */
  public evaluateDelivery(outcome: TaskOutcome): {
    normalizedUpliftU: number;
    incidentAdjustedUpliftUadj: number;
    totalContactCostC: number;
    finalScoreS: number;
    isResolved: boolean;
    isBelowBaseline: boolean;
  } {
    // 1. Normalized Business Uplift (U)
    let upliftNumerator: number;
    let upliftDenominator: number;

    if (outcome.metricDirection === 'maximize') {
      upliftNumerator = outcome.kpiDelivered - outcome.kpiBaseline;
      upliftDenominator = outcome.kpiReference - outcome.kpiBaseline;
    } else {
      // Minimize metrics (e.g. downtime, cost, errors)
      upliftNumerator = outcome.kpiBaseline - outcome.kpiDelivered;
      upliftDenominator = outcome.kpiBaseline - outcome.kpiReference;
    }

    const U = upliftDenominator !== 0 ? upliftNumerator / upliftDenominator : 0;

    // 2. Incident Adjustment (U_adj)
    const U_adj = outcome.incidentOccurred ? Math.min(U, 0) : U;

    // 3. Stakeholder Contact Cost (C)
    let totalC = 0;
    for (const c of this.contactHistory) {
      const sh = this.stakeholders.get(c.stakeholderId)!;
      let eventCost = sh.costPerMessage;
      if (!sh.isAvailable) eventCost += sh.unauthorizedContactPenalty;
      if (sh.requiresEvidence && !c.hasSupportingEvidence) eventCost += sh.costPerMessage * 1.5;
      if (c.isTrialRun) eventCost += 0.04;
      if (c.isWaitingDay) eventCost += 0.02;
      totalC += eventCost;
    }

    // 4. Final FDE-Gym Score (S)
    const S = U_adj - totalC;

    // A task is resolved if S >= 0.8 and no operational incident occurred
    const isResolved = S >= 0.8 && !outcome.incidentOccurred;
    const isBelowBaseline = S < 0;

    return {
      normalizedUpliftU: Number(U.toFixed(4)),
      incidentAdjustedUpliftUadj: Number(U_adj.toFixed(4)),
      totalContactCostC: Number(totalC.toFixed(4)),
      finalScoreS: Number(S.toFixed(4)),
      isResolved,
      isBelowBaseline,
    };
  }

  /**
   * Average Score across Tasks (Eq. 5): Truncating U_adj at -1 to prevent extreme business disasters
   */
  public static calculateBenchmarkAverage(
    taskScores: Array<{ U_adj: number; C: number }>
  ): number {
    if (taskScores.length === 0) return 0;
    const sum = taskScores.reduce((acc, t) => acc + (Math.max(t.U_adj, -1) - t.C), 0);
    return Number((sum / taskScores.length).toFixed(4));
  }
}

7. Rekomendasi Arsitektur untuk Engineering AI Agent Enterprise

Temuan dari paper FDE-Gym memberikan panduan nyata bagi tim AI platform, pengembang enterprise agent, dan konsultan transformasi digital yang sedang membangun solusi otonom:

1. Validasi Asumsi Sponsor dengan Data Telemetri Sebelum Menulis Kode: Jangan pernah memperlakukan prompt awal sponsor proyek sebagai kebenaran mutlak. Arsitektur agen harus memiliki fase Pre-Delivery Discovery Loop yang melakukan kueri langsung ke log transaksi dan metrik bisnis untuk memverifikasi apakah perubahan yang diminta benar-benar berdampak positif.
2. Pasang Budgeting Guard pada Interaksi Stakeholder: Agen yang mengirimkan puluhan pertanyaan repetitif ke manusia akan menimbulkan kelelahan stakeholder (stakeholder fatigue). Batasi jumlah token interaksi manusia, buat format pertanyaan berbasis bukti (evidence-backed inquiry), dan cegah kontak ke staf yang tidak memiliki wewenang keputusan.
3. Terapkan Incident Prevention Gate yang Mengisolasi Write-Operations: Pelanggaran otorisasi atau modifikasi data produksi tanpa persetujuan langsung menghancurkan skor ke level nol atau negatif. Pisahkan agen ke dalam mode read-only diagnostic dan mintakan persetujuan bertanda tangan digital (out-of-band authorization) sebelum menyentuh entry point kritis.
4. Gunakan "Do-Nothing" Fallback sebagai Safeguard Operasional: Jika tingkat keyakinan agen (confidence threshold) terhadap dampak bisnis di bawah batas aman, agen harus memilih opsi graceful abortion (tidak melakukan modifikasi sistem) alih-alih memaksakan rilis yang berpotensi menyebabkan regresi operasional.