TL;DR

88% agent pilot không bao giờ ra production. MIT đo được 95% tỷ lệ thất bại với generative AI ở doanh nghiệp. Lý do không phải model kém - mà là kỹ thuật xung quanh model quá yếu. Bài viết này, viết sau 6 tháng đọc codebase agent thực tế, đặt tên cho vấn đề đó: engineering deficit.

Ba câu hỏi bạn phải tự trả lời

Trước khi tiếp tục, hãy thử trả lời ba câu hỏi này:

  • Nếu agent của bạn cho kết quả sai vào sáng mai - sai câu trả lời, sai hành động, sai người nhận - bạn có biết ngay span nào trong context, tool nào đã gọi, bước nào trong loop gây ra lỗi không? Hay bạn sẽ phải đoán từ complaint của user?
  • Nếu một backend engineer 25 năm kinh nghiệm, chưa từng đụng tới LLM, được đọc codebase agent của bạn - họ sẽ gạch đỏ gì đầu tiên?
  • Nếu một senior engineer mở agent của bạn và gửi hai request song song - request thứ hai có thấy dữ liệu của request thứ nhất không?

Gần như không ai tôi review trong 2026 trả lời được cả ba. Không phải vì họ thiếu năng lực - mà vì cả ngành đang có một khoảng trống kỹ thuật rất cụ thể.

AI agent gặp lỗi trong production với tỷ lệ thất bại 88%

Con số thật không ai tự nói về mình

Đây không phải vấn đề ngoại lệ. Theo các số liệu được trích dẫn nhiều nhất:

  • 88% dự án agent không ra production (IDC/DigitalApplied, tháng 3/2026)
  • 95% tỷ lệ thất bại của generative AI pilot trong doanh nghiệp - MIT, tháng 8/2025
  • 60% dự án AI sẽ bị huỷ bỏ trước cuối 2026 - Gartner
  • Trong khảo sát 1.837 developer cuối 2025, chỉ 95 người (5%) có AI agent đang chạy thật trên production

Điều đáng chú ý: framework không phải vấn đề. LangGraph đang chạy hệ thống AI của Klarna phục vụ 85 triệu user với mức giảm 80% thời gian giải quyết khiếu nại. Cursor đạt mức ARR tăng trưởng nhanh nhất lịch sử B2B SaaS chỉ trong 3 năm - trên cùng model mà mọi người khác đều có access. Harvey ship legal AI cho enterprise law firm với kiến trúc 3 tầng đánh giá dùng LLM-as-judge. AppFolio RealmX tăng gấp đôi response accuracy sau khi chuyển sang LangGraph. Cái không hoạt động là kỹ thuật xung quanh model - không phải model.

Hai loại codebase agent đang ship năm 2026

Sau nhiều tháng review, tôi thường biết mình đang đọc loại nào trong vòng 10 phút.

Loại 1 - Demo codebase: prompt phong phú, nhiều tool, model name hardcode theo version 6 tuần trước. Không có boundary discipline. Tool nhận bất kỳ string nào, trả về list rỗng khi lỗi. Session state là Python dict không có schema. System prompt liệt kê tool không còn tồn tại. Không có ask_user tool. Không có giới hạn MAX_STEPS. Mọi exception đều bị catch và stringify - agent thấy "tool failed, please try again" và không có thông tin gì để hành động. Điểm tự hào của team: video demo.

Loại 2 - Production codebase: ít feature hơn nhưng tất cả đều sống sót qua contact với user thật. Tool validate format ở entry point và raise structured error - cái lỗi đó chính là teaching signal cho model ở lượt kế tiếp. Session state có schema có type, mỗi fact được tag với nguồn gốc. System prompt được generate từ danh sách tool đã đăng ký, không hardcode tay. Có ask_user tool và regression suite để đảm bảo agent gọi nó khi input không rõ ràng. Có spans trên LLM call và tool call. Hard step bound và privilege boundary cho action nguy hiểm. Điểm tự hào của team: eval dashboard.

Biến quyết định duy nhất

Điều đáng buồn về sự phân chia này là nó gần như không liên quan đến team size, model choice hay framework. Tôi đã thấy startup 4 người ship loại 2. Tôi cũng thấy team nhiều tiền từ công ty lớn ship loại 1. Biến quyết định duy nhất: có ai trong team coi kỹ thuật xung quanh model là sản phẩm thật sự không - hay chỉ là plumbing họ sẽ lo sau khi demo xong.

Pattern lỗi lặp lại như nhau qua các team chưa bao giờ nói chuyện với nhau: identifier sai truyền vào tool, state bị nhiễm bởi LLM, "fact" agent tự assert mà user chưa bao giờ nói, hai agent vô tình share một list vì ai đó viết tools: list[Tool] = [] ở class scope, tool error bị nuốt vào conversation như thể đó là kết quả rỗng hợp lệ.

Bốn trụ cột tạo nên sự khác biệt

Bốn trụ cột phân biệt agent demo và agent production: Building, Memory, Harness, Orchestration. Mọi codebase tôi đánh giá ở category demo đều đang fail ít nhất ba trong bốn. Phần tiếp theo của series này sẽ đi sâu vào từng trụ cột, với ví dụ code cụ thể, bug thực tế từ production, và cách fix.

Biểu đồ hiệu suất agentic coding theo effort level - Anthropic internal evaluation

Kết

Câu hỏi đúng nhất không phải "dùng model nào" hay "dùng framework nào". Câu hỏi là: kỹ thuật xung quanh model của bạn có đủ discipline để sống sót qua 6 tháng đầu tiên không? Model là phần dễ. Engineering xung quanh model là nơi reliability sống.

via DigitalApplied · Anthropic Engineering