𝗧𝗵𝗲 𝗡𝘂𝗹𝗹 𝗜𝗻𝗽𝘂𝘁 𝗧𝗵𝗮𝘁 𝗕𝗿𝗼𝗸𝗲 𝗠𝘆 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗔𝗴𝗲𝗻𝘁

The demo ran perfectly for three weeks. Every test input worked. Every output went to the right place. I thought the system was reliable.

Then a supplier sent an email with an empty subject line.

The agent expected a string to extract an order reference. Instead, it received a null value. It did not crash. That would have been better. It generated a fake order reference that looked real. The downstream system processed it. Nobody noticed for four hours.

Demos use inputs you expect. Production uses inputs you do not expect.

I run the agent operation at aienterprise.dk. I saw the full trace. The prompt told the agent to extract the order reference from the subject line. This works if the subject line exists.

If the subject line is missing, a large language model fills the gap. It invents something that looks correct. This is not random noise. It is structured noise. It is dangerous because it looks right. You can catch a failure. You cannot easily catch a confident, wrong answer.

I did not retrain the model. I did not change the prompt. I added a guard before the model call.

Now, a simple check runs first. It asks: is the subject field present and non-empty? If the answer is no, the message goes to a hold queue for a human. The agent never sees the bad input.

This guard is twelve lines of code. It is the most important thing I built this year.

The pattern is simple. If an agent assumes structure, production will eventually send unstructured data. The fix is not a smarter model. The fix is a boundary. You need a check that routes bad input to a human instead of letting the model guess.

Reliability is the only feature. A demo shows an agent can do a task. Production shows an agent does the task at 3 AM on bad input. Only the second part matters to your customers.

My agent now processes 200 operations per day without issues. The hold queue triggers twice a week. A human reviews the odd data. I learn what production looks like.

If you build agents for high-risk categories under the EU AI Act, the deadline is December 2, 2027. This includes employment, biometrics, and education. A system that guesses on bad input will fail an audit. This guard is a compliance minimum.

Reliability is not a feature you add later.

Input null yang merusak agent produksi saya dan cara memperbaikinya

Membangun agent LLM (Large Language Model) terasa seperti membangun rumah di atas pasir. Anda bisa menghabiskan waktu berminggu-minggu untuk memastikan fondasinya kokoh, tetapi satu gelombang kecil yang tidak terduga bisa meruntuhkan semuanya.

Bagi saya, gelombang itu adalah input null.

Masalahnya

Saya baru saja meluncurkan sebuah agent produksi yang dirancang untuk membantu pengguna mengelola tugas-tugas mereka melalui chat. Selama fase pengujian (testing), semuanya berjalan mulus. Saya memasukkan berbagai pertanyaan, perintah yang kompleks, bahkan teks yang sangat panjang. Agent saya merespons dengan cerdas dan konsisten.

Namun, beberapa hari setelah peluncuran, sistem pemantauan (monitoring) saya mulai berteriak.

Error: Cannot read property 'trim' of null

Agent saya mati. Bukan hanya sekadar memberikan jawaban yang salah, tetapi ia benar-benar berhenti berfungsi untuk beberapa pengguna.

Akar Masalah

Setelah menyelidiki log, saya menemukan penyebabnya. Ternyata, ada skenario di mana sistem mengirimkan input kosong atau null ke agent saya. Ini bisa terjadi karena kegagalan pada frontend, masalah koneksi, atau pengguna yang secara tidak sengaja menekan tombol kirim tanpa mengetik apa pun.

Kode saya terlihat seperti ini:

async function processUserQuery(query) {
  const cleanedQuery = query.trim(); // Di sinilah letak masalahnya
  const response = await llm.generate(cleanedQuery);
  return response;
}

Logikanya sederhana: saya berasumsi bahwa query akan selalu berupa string. Ketika query bernilai null, pemanggilan .trim() menyebabkan error fatal yang menghentikan eksekusi fungsi tersebut.

Dalam dunia pengembangan perangkat lunak, ini adalah edge case klasik yang sering kita abaikan saat fokus pada fitur utama.

Solusinya

Solusinya tidaklah rumit, tetapi sangat krusial. Saya perlu menerapkan dua hal: validasi input dan mekanisme fallback.

Pertama, saya menambahkan validasi untuk memastikan input adalah string yang valid sebelum melakukan operasi apa pun.

async function processUserQuery(query) {
  // Validasi input
  if (!query || typeof query !== 'string') {
    console.warn("Input tidak valid diterima:", query);
    return "Maaf, saya tidak menerima input yang valid. Silakan coba lagi.";
  }

  const cleanedQuery = query.trim();
  
  if (cleanedQuery.length === 0) {
    return "Anda tidak memasukkan teks apa pun. Apa yang bisa saya bantu?";
  }

  try {
    const response = await llm.generate(cleanedQuery);
    return response;
  } catch (error) {
    console.error("Error saat memanggil LLM:", error);
    return "Maaf, terjadi kesalahan saat memproses permintaan Anda.";
  }
}

Dengan perubahan ini, saya melakukan beberapa hal:

  1. Pengecekan tipe data: Memastikan query ada dan merupakan string.
  2. Pengecekan panjang string: Menangani kasus di mana pengguna hanya mengirimkan spasi.
  3. Error handling (try/catch): Memastikan jika API LLM gagal, agent tidak akan crash secara keseluruhan.

Pelajaran yang Dipetik

Pelajaran terbesar dari kejadian ini adalah: Jangan pernah percaya pada input pengguna (atau sistem lain).

Saat membangun aplikasi berbasis AI, ketidakpastian adalah norma. Input bisa kosong, formatnya bisa salah, atau API bisa mengalami timeout. Membangun guardrails (pagar pembatas) di sekitar logika utama Anda bukan sekadar praktik tambahan, melainkan keharusan untuk menjaga stabilitas di lingkungan produksi.

Sekarang, agent saya jauh lebih tangguh. Ia tidak lagi hancur hanya karena satu input kosong; ia justru mampu meresponsnya dengan sopan.