# Sáu failure của production AI agent, cách sửa và checklist

[Maryam Miradi](https://homus.dev/speakers/maryam-miradi) · [Dr. Maryam Miradi](https://homus.dev/orgs/dr-maryam-miradi)

> Sáu failure của production agent qua một hệ thống ghép thận mô phỏng: semantic, loop và evaluation engineering, kèm fix, checklist và demo Gradio.

Topics: Agents, Evals, Workflow

Canonical: https://homus.dev/talks/stop-building-ai-agents-until-you-watch-this-6-failures-fixes-checklists

## 1. Một hệ thống ghép tạng, sáu failure, ba ngành engineering

Maryam mở đầu: trước khi bạn build thêm một production agent nữa, chị sẽ cho xem cách chặn những failure nghiêm trọng trước khi chúng phá hỏng cả dự án AI của bạn. Trong video đăng ngày 25/10/2026, chị giải sáu critical failure trong lúc build một agentic system cho ghép tạng (organ transplant), tập trung vào ba mảng: semantic engineering, loop engineering và evaluation engineering. Người xem sẽ nhận được bốn thứ để dùng trong dự án của chính mình: failure (cái gì hỏng), fix (cách sửa), flow (nó chạy ra sao) và checklist (cần implement gì).

Chị tự giới thiệu là Maryam, AI scientist có bằng PhD, và theo lời chị trong video đăng ngày 25/10/2026, chị đã build hơn 400 production AI agent.

![Slide Stop Serious Failures Before They Destroy Your AI Project với sáu ô failure](https://homus.dev/photos/37GWykiKEak-0010.jpg)

Slide mở đầu liệt kê sáu failure: Positive Means Dangerous, 14 Hours Left or Gone?, More Thinking More Wrong, The Loop That Never Stops, 99% Accuracy 0% Critical Recall và The AI Wins by Doing Nothing. Trên slide này failure #5 là "99% Accuracy" và #6 là "Doing Nothing", ngược với thứ tự chị trình bày sau đó trong video đăng ngày 25/10/2026.

Thứ tự của video (đăng ngày 25/10/2026): đầu tiên bàn về các failure trong quy trình, theo bộ ba failure, fix và checklist; sau đó chị cho xem app Gradio, phần code và các flow.

Như đã nói, thứ đang được build là một organ transplant agentic system. Theo slide trong video đăng ngày 25/10/2026, đây là "a simulated kidney transplant coordination agent", một agent mô phỏng việc điều phối ghép thận, với bốn việc: đọc hồ sơ y tế (medical records), theo dõi việc vận chuyển tạng (organ transport), điều phối giữa các bệnh viện và hỗ trợ những quyết định mà thời gian là yếu tố sống còn (time-critical decisions). Dòng cuối slide tóm lại: một hệ thống, sáu failure, ba ngành engineering. Phần mô tả của video cũng ghi rõ đây là các kịch bản mô phỏng (simulated scenarios), không phải một hệ thống ra quyết định đã được kiểm định.

Maryam nói chị luôn dùng một production AI stack gồm 12 layer. Trong video đăng ngày 25/10/2026, chị chỉ tập trung vào ba layer trong đó: semantic engineering, loop engineering và evaluation engineering. Slide của stack ghi "Today: 3 layers. 6 critical failures."

## 2. Semantic engineering và failure 1: "positive" nghĩa là nguy hiểm

Bắt đầu với semantic engineering. Theo Maryam (video đăng ngày 25/10/2026), semantic engineering về cơ bản trả lời câu hỏi: agent của bạn có thật sự hiểu ngôn ngữ của ngành bạn không? Vì biết một từ theo nghĩa thông thường và biết nó trong một domain cụ thể là hai chuyện khác nhau.

Failure đầu tiên. Theo chị (video đăng ngày 25/10/2026), nhìn chung một agent sẽ nghĩ "positive" là điều tốt: bệnh nhân đã ổn, kết quả positive. Nhưng nếu nói "positive crossmatch" thì thực ra nghĩa là gì? Trong trường hợp này, nhất là với ghép thận, một positive crossmatch là khá nguy hiểm: nó có nghĩa là người hiến (donor) về cơ bản không tương thích với người nhận.

![Slide Failure #1 Positive Means Dangerous, so sánh POSITIVE = GOOD với POSITIVE = WARNING](https://homus.dev/photos/37GWykiKEak-0200.jpg)

Slide failure #1 trong video đăng ngày 25/10/2026: bên trái là điều agent nghĩ (POSITIVE = GOOD, "The patient is cleared"), bên phải là nghĩa thật (POSITIVE = WARNING, một positive crossmatch có thể cho thấy donor không tương thích). Dải dưới ghi failure là đọc đúng chữ nhưng hiểu sai hoàn toàn nghĩa y khoa, và fix là medical ontology, validation riêng cho domain và clinician review.

Theo Maryam (video đăng ngày 25/10/2026), hệ thống có thể hiểu sai hoàn toàn toàn bộ chuyện này. Để sửa, cần một medical ontology, cần validation riêng cho domain (domain-specific validation) và cần clinician review, tức bác sĩ xem lại. Chị hứa sẽ cho xem cách implement ngay sau đó, nhưng điều rõ ràng là phải implement một lớp semantic engineering riêng cho domain.

## 3. Failure 2: 14 giờ còn lại hay 14 giờ đã trôi qua

Failure thứ hai cũng nằm trong semantic engineering. Hãy hình dung hồ sơ y tế của ca ghép thận đó, và agent đọc được dòng: cold ischemia time là 14 giờ. Theo ví dụ của Maryam (video đăng ngày 25/10/2026), agent sẽ cho rằng còn 14 giờ, dư thời gian để điều phối. Nhưng nghĩa thật là 14 giờ đó đã trôi qua rồi.

![Slide Failure #2 14 Hours Left or 14 Hours Gone với hồ sơ Cold Ischemia Time 14 hours](https://homus.dev/photos/37GWykiKEak-0303.jpg)

Slide failure #2 trong video đăng ngày 25/10/2026: hồ sơ ghi "Cold Ischemia Time: 14 hours". Agent hiểu là "14 hours LEFT, plenty of time to coordinate", còn nghĩa thật là "14 hours ELAPSED, time has already passed". Fix trên slide: domain definitions, units, timestamps và measurement references.

Maryam giải thích lý do (theo video đăng ngày 25/10/2026): khi quả thận được lấy ra, người ta phải giữ lạnh nó trong một số giờ. Ischemia là số giờ quả thận sống mà không có oxy và máu bình thường. Cold ischemia là số giờ nó đã được giữ lạnh để sống sót qua giai đoạn đó. Vậy đây không phải 14 giờ còn lại, mà là 14 giờ đã mất.

Theo chị (video đăng ngày 25/10/2026), hiểu sai chỗ này có thể khá nguy hiểm. Vì vậy cần định nghĩa của domain, cần đơn vị (units), cần timestamp, cần tham chiếu đo lường (measurement references). Và đây tất nhiên mới chỉ là một use case; điều chị muốn là có một checklist.

## 4. Checklist semantic engineering: năm bước trước production

![Slide Semantic Engineering 5 Checks Before Production với năm ô](https://homus.dev/photos/37GWykiKEak-0411.jpg)

Checklist semantic engineering trong video đăng ngày 25/10/2026: Define domain terms, Map words to concepts, Check units and time, Validate critical results, Test confusing terms. Dòng cuối: "Knowing a word ≠ Understanding its meaning."

Theo checklist của Maryam (video đăng ngày 25/10/2026), điều đầu tiên cần kiểm tra trong semantic engineering là: các domain term của bạn là gì? Hãy dùng nghĩa đã được chuyên gia duyệt (expert-approved meanings). Chuyên gia phải nói rõ nghĩa chính xác là gì để agent có thể tiếp nhận.

Bước hai trong checklist (video đăng ngày 25/10/2026) là ánh xạ từ ngữ sang khái niệm (map words to concepts): xử lý từ đồng nghĩa và chữ viết tắt, những thứ mà ở mỗi ngành lại mang nghĩa khác nhau.

Bước ba là kiểm tra đơn vị và thời gian, theo chị (video đăng ngày 25/10/2026) là cực kỳ quan trọng: mỗi con số đang đo cái gì?

Bước bốn là validate từng kết quả quan trọng. Với những quyết định critical kiểu này, theo Maryam (video đăng ngày 25/10/2026), thật sự cần có các rule deterministic và cả expert review.

Bước cuối trong checklist (video đăng ngày 25/10/2026) là test những thuật ngữ dễ gây nhầm lẫn: sau khi đã làm hết các bước trên, còn chỗ nào mơ hồ (ambiguity) không, còn edge case nào không? Chị nói việc thêm checklist này vào agentic system của bạn là rất quan trọng.

## 5. Loop engineering và failure 3: càng nghĩ càng sai

Trước khi chuyển sang dashboard và xem các thứ khác, Maryam đi tiếp sang layer kế: loop engineering. Theo chị (video đăng ngày 25/10/2026), loop engineering là để agent cải thiện câu trả lời của nó mà không làm vấn đề tệ hơn. Bạn có một vòng lặp nội bộ giúp agent tốt hơn. Nhưng suy nghĩ nhiều hơn có đồng nghĩa với quyết định tốt hơn không? Slide của chị ghi: "More thinking does not always mean better decisions."

Failure số ba, theo ví dụ của Maryam trong video đăng ngày 25/10/2026. Hãy hình dung agent nói lô hàng sẽ đến lúc 2 giờ chiều. Với một quả thận, một cơ quan để ghép, chuyện này cực kỳ quan trọng, nó rất quý. Agent có 65% confidence. Nó ở trong một vòng lặp. Bước tiếp theo, nó nói: 30 phút, giờ tôi có 82% confidence, và lô hàng sẽ đến lúc 1:45. Không có bằng chứng mới nào, nhưng agent nhìn vào câu trả lời trước đó của chính nó. Rồi nó xuống 20 phút và nói: tôi chắc 96% là hàng sẽ đến vào lúc đó.

![Slide Failure #3 với ba vòng lặp 40, 30, 20 phút và confidence 65, 82, 96 phần trăm](https://homus.dev/photos/37GWykiKEak-0510.jpg)

Slide failure #3 trong video đăng ngày 25/10/2026: Loop 1 "40 min", 65% confident, "Delivery will arrive by 2:00 PM"; Loop 2 "30 min", 82%, "by 1:45 PM"; Loop 3 "20 min", 96%, "by 1:30 PM". Cả ba vòng đều ghi "No new evidence, no fresh transport data". Failure: agent coi các ước lượng trước của chính nó là bằng chứng mới; fix: independent observations, evidence checks và progress tracking.

Theo Maryam (video đăng ngày 25/10/2026), failure ở đây là agent về cơ bản coi các ước lượng trước đó của chính nó như một thứ bằng chứng. Fix là: cần quan sát độc lập (independent observation), cần kiểm tra bằng chứng (evidence check), mà chị nhấn là rất quan trọng, và tất nhiên cần theo dõi tiến độ (progress tracking).

## 6. Failure 4: vòng lặp không bao giờ dừng

Failure thứ tư, vẫn trong loop engineering. Giả sử mục tiêu của agent là tìm phương tiện vận chuyển nhanh nhất, mà với ghép tạng thì việc này lại cực kỳ quan trọng. Theo ví dụ của Maryam (video đăng ngày 25/10/2026), agent bắt đầu: có một chiếc xe, mất khoảng ba giờ, 80 đô; đặt luôn chiếc này. Rồi nó sang một lựa chọn khác: nhanh hơn, hai giờ, đắt hơn; đặt luôn chiếc này nữa. Rồi một lựa chọn còn đắt hơn nữa, chỉ 45 phút; đặt nốt. Và nó cứ đi tiếp sang lựa chọn khác, lựa chọn khác, lựa chọn khác, vì ta bảo nó "hãy tự cải thiện", một vòng lặp không bao giờ dừng.

![Slide Failure #4 The Loop That Never Stops với Courier A, Courier B, Helicopter C](https://homus.dev/photos/37GWykiKEak-0608.jpg)

Slide failure #4 trong video đăng ngày 25/10/2026: mục tiêu của agent là "Keep finding the fastest transport". Các lựa chọn: Courier A (ETA 3 giờ, $80), Courier B (ETA 2 giờ, $120), Helicopter C (ETA 45 phút, $450), rồi "Another option...". Vấn đề: nó không bao giờ quyết định khi nào dừng; hậu quả: đặt chỗ chồng chéo, phí thời gian, không có kế hoạch ổn định.

Câu hỏi là khi nào thì dừng để chốt một quyết định, nhất là khi quyết định đó critical và nhất là khi điều kiện dừng không được xác định từ trước. Theo Maryam (video đăng ngày 25/10/2026), kết quả tất nhiên là các booking xung đột nhau, thời gian bị lãng phí, và không có một kế hoạch ổn định, điều mà chị nói lại càng nghiêm trọng trong một tình huống liên quan đến tính mạng như thế này.

Fix mà chị đưa ra trong video đăng ngày 25/10/2026: cần điều kiện dừng (stop condition), cần ngưỡng cải thiện (improvement thresholds), cần giới hạn số vòng lặp (iteration limits), và chắc chắn cần kiểm soát hành động (action controls). Chị nhắc lại rằng đây tất nhiên chỉ là use case của chị, còn với bạn thì sao? Và đây sẽ là checklist của bạn.

## 7. Checklist loop engineering: sáu bước trước production

Bước một: đặt mục tiêu rõ ràng. Cải thiện thật ra là gì? Theo Maryam (video đăng ngày 25/10/2026), bạn sẽ bất ngờ khi thấy người ta thường xuyên không biết mình muốn nói gì khi nói "cải thiện". Vì vậy hãy xác định điều đó thật rõ.

Bước hai: luôn đòi bằng chứng mới (fresh evidence). Đừng bao giờ tái chế những phỏng đoán quay lại vào hệ thống. Chị nói rất dễ để lọt thông tin cũ vào, và theo chị (video đăng ngày 25/10/2026), nếu bạn làm việc với ChatGPT hay Claude, đến một lúc nào đó chúng cũng chỉ lấy chính lập luận của mình làm sự thật.

Bước ba: điều kiện dừng, theo chị (video đăng ngày 25/10/2026) là cực kỳ quan trọng phải rõ ràng: giới hạn chính xác về thời gian, chi phí, số vòng lặp là bao nhiêu.

Bước bốn (theo checklist trong video đăng ngày 25/10/2026): nếu có những lỗi lặp lại, hãy phát hiện chúng và bắt chúng ngay trong vòng lặp.

Bước năm: luôn tách lập kế hoạch khỏi hành động. Bạn cần so sánh trước khi commit. Theo Maryam (video đăng ngày 25/10/2026), khi agent lập kế hoạch xong, hãy nhìn vào kế hoạch đó và sửa agent.

Bước sáu: kiểm soát các tool action. Trong video đăng ngày 25/10/2026, chị nói chị luôn có kiểm soát tool action: approval, retry và idempotency.

Sáu bước kiểm tra loop engineering, chép theo slide "Loop Engineering, 6 Checks Before Production" trong video đăng ngày 25/10/2026.

## 8. Evaluation engineering và failure 5: AI thắng bằng cách không làm gì

Như đã hứa, Maryam chuyển sang evaluation engineering, với câu hỏi: agent của bạn có thể đạt điểm rất cao mà vẫn thất bại không? Theo chị (video đăng ngày 25/10/2026), một điểm số cao chẳng có nghĩa gì nếu bạn đang đo sai thứ.

Failure số năm. Theo Maryam (video đăng ngày 25/10/2026), nhìn chung phần evaluation thường thưởng cho việc tránh quyết định sai. Vậy agent hoàn toàn có thể nghĩ: được, thế thì tôi gửi mọi ca cho con người. Bạn sẽ có kiểu 0% lỗi tự động (autonomous error), nhưng đổi lại 100% escalation ở các edge case và các ca khó. Agent sẽ chạy kiểu: ca một, escalate; ca hai, escalate. Và đến một lúc, mọi ca khó đều bị escalate.

![Slide Failure #5 The AI Wins by Doing Nothing với robot cầm biển Escalate to Human](https://homus.dev/photos/37GWykiKEak-1639.jpg)

Slide failure #5 trong video đăng ngày 25/10/2026: evaluation thưởng cho việc tránh quyết định sai nên agent gửi mọi ca cho con người. Ba con số trên slide: ~0% autonomous errors, 100% escalation to human, 0% automatic completion; bên phải là Case 1, 2, 3 rồi "All cases Escalated". Fix: đo safety, task completion, escalation và latency cùng lúc.

Theo chị (video đăng ngày 25/10/2026), ở đây agent đang tối ưu điểm số thay vì hoàn thành một việc có ích. Và fix là: safety, task completion, escalation, latency; tất cả gộp lại mới thành phần evaluation của bạn.

## 9. Failure 6: accuracy 99%, critical recall 0%

Đó không phải failure duy nhất có thể gặp ở evaluation engineering. Theo Maryam (video đăng ngày 25/10/2026), bạn còn có thể có accuracy 99% mà critical recall bằng 0%. Ý chị là: nếu có 10.000 ca mô phỏng, trong đó 9.900 ca là ca thông thường (routine) và đều đúng, nhưng có 100 ca critical mà ta bỏ sót hết, thì về cơ bản ta đã làm rất tốt với những ca routine chung chung đó, và rất tệ với toàn bộ các ca critical.

![Slide Failure #6 99% Accuracy 0% Critical Recall với danh sách routine cases và critical cases](https://homus.dev/photos/37GWykiKEak-0943.jpg)

Slide failure #6 trong video đăng ngày 25/10/2026: "A great overall score can hide every critical failure." 10.000 ca mô phỏng, 9.900 ca routine đúng (standard patient, normal labs, no complications, typical transport), 100 ca critical bị bỏ sót (positive crossmatch, high risk comorbidity, time critical transport, donor incompatibility). Fix: risk-based test groups, critical recall và ngưỡng release riêng.

Chị nói ai làm machine learning cũng nhận ra hiện tượng này: một bài toán classification đạt 99% mà vẫn làm rất tệ ở một lớp. Theo Maryam (video đăng ngày 25/10/2026), chuyện y hệt như vậy xảy ra trong evaluation engineering cho AI agent: một điểm tổng thể cao có thể che giấu những lần bỏ sót critical dựa trên rủi ro. Cái cần sửa, tất nhiên, là các nhóm test theo rủi ro (risk-based test groups); cần nhìn vào critical recall và tách nó ra khỏi nhóm lớn.

## 10. Checklist evaluation engineering và tóm tắt phần đầu

Maryam đưa thêm một checklist nữa, lần này là production checklist cho evaluation engineering, gồm sáu mục.

![Slide Evaluation Engineering Production Checklist với sáu mục](https://homus.dev/photos/37GWykiKEak-1043.jpg)

Production checklist cho evaluation engineering trong video đăng ngày 25/10/2026: Define system success, Measure critical failures, Set release gates, Test different risks, Detect metric gaming, Run regression tests. Dòng cuối: "A high score is useful only when it measures the right thing."

Mục một là định nghĩa thế nào là thành công. Theo ví dụ của Maryam (video đăng ngày 25/10/2026): bạn hỏi ai đó thành công là gì, họ sẽ nói hệ thống phải được cải thiện. Cải thiện cái gì? Tốc độ của quy trình. Tốc độ chính xác là ở khâu nào? Vậy hãy đào tới tận gốc xem tiêu chí thành công chính xác là gì.

Theo checklist trong video đăng ngày 25/10/2026, mục hai là đo các critical failure: phải đo cả false negative và critical recall. Mục ba là test các loại rủi ro khác nhau: ca routine, ca critical, ca adversarial. Mục tiếp theo là kiểm tra completion, escalation và độ trễ (delay); slide gọi mục này là "Detect metric gaming".

Rồi đến release gate: theo Maryam (video đăng ngày 25/10/2026), critical failure không được phép trốn sau con số trung bình, vì như bạn có thể hình dung, một con số trung bình chẳng nói lên điều gì. Mục cuối là chạy regression test: thứ gì đó có thể trông ổn, nhưng sau một thời gian chúng có thể bắt đầu thay đổi và drift. Tóm lại, chị nói đây là chuyện đo đúng thứ.

Trong phần đầu này, Maryam tóm lại, chị đã xem semantic engineering, các critical failure và fix của chúng, rồi làm tương tự với loop engineering và evaluation engineering. Chị nhắc người xem luôn nhớ ba checklist vừa đưa: một cho semantic engineering, một cho loop engineering và một cho evaluation engineering.

## 11. Demo Gradio: positive crossmatch, trước và sau

Giờ Maryam mở app Gradio, các flow và phần code. Dashboard có tên TransplantOps AI, dòng phụ "Production agent failure lab", và một nhãn vàng "Fictional simulation" kèm dòng "Synthetic data only · no clinical decisions · no real bookings". Ba cột là Semantic Engineering (01 Positive crossmatch, 02 Cold ischemia time), Loop Engineering (03 The ETA confidence spiral, 04 Endless transport optimization) và Evaluation Engineering (05 99% accuracy, zero critical recall, 06 Winning by escalating everything). Mỗi ca có nút Run Comparison để chạy cả hai đường trên cùng một input, với hai mode là Reproducible Demo và Live OpenAI (mô tả theo màn hình trong video đăng ngày 25/10/2026).

Failure đầu tiên: positive crossmatch trông hoàn toàn ổn với agent, theo Maryam (video đăng ngày 25/10/2026), là vì nó chỉ dùng sentiment: "positive" đơn giản là một từ thuận lợi. Để sửa, chị nhặt các thuật ngữ ra, normalize chúng trong code, đưa vào một bước ontology lookup để ra concept, rồi xem tới policy và status. Bằng cách này, bạn đang kiểm tra xem từ đó có được hiểu đúng không. Flow trên slide: bên Before là Term, Sentiment lexicon, "Favorable", CLEARED (đoán từ chữ); bên After là Term, Normalize, Ontology lookup, Concept, Policy lookup, Status, với ghi chú "Missing / unknown → safe status".

Trên dashboard, chị chọn positive crossmatch và bấm Run Comparison (demo trong video đăng ngày 25/10/2026). Bản đầu về cơ bản nói: nó positive. Bản thứ hai nhận ra đây là positive crossmatch và đi qua quy trình xử lý crossmatch. Chị cũng có trace, đưa JSON đó cho agent để kiểm soát, kèm timestamp chính xác điều gì đã xảy ra. Đó là baseline và đó là semantic crossmatch.

![Dashboard so sánh baseline CLEARED với engineered PENDING SPECIALIST REVIEW cho positive crossmatch](https://homus.dev/photos/37GWykiKEak-1151.jpg)

Kết quả Run Comparison cho positive crossmatch (demo trong video đăng ngày 25/10/2026). Baseline (Failure): CLEARED, "positive" được đọc là FAVORABLE qua sentiment lexicon. Engineered (Controlled): PENDING SPECIALIST REVIEW, thuật ngữ được ánh xạ sang concept positive_crossmatch đã kiểm định rồi mới qua gate; dòng mô tả ghi agent không bao giờ tự quyết khả năng tương thích. Khung test results ghi 6/6 passed.

Trong code, Maryam chỉ ra cách làm ngây thơ (naive) chỉ dùng lexicon, và phần crossmatch concept. Ở phiên bản crossmatch, hàm trả về raw term, concept, status và phần lý giải (reasoning) (demo trong video đăng ngày 25/10/2026).

## 12. Demo cold ischemia time: field registry và timestamp

Vấn đề tiếp theo là cold ischemia time. Bình thường, agent cứ thế giả định đó là thời gian còn lại. Giải pháp của Maryam (video đăng ngày 25/10/2026) là nhìn vào tên field, registry spec, chuyển đổi đơn vị, timestamp, rồi tới thời gian đã trôi qua (elapsed time); dựa vào đó mới escalate. Slide flow tên "Cold Ischemia Time, Field registry + validation": bên Before là field name ends in _time_hours, assume remaining, value ≥ 6, ROUTINE; bên After là field name, registry spec, unit conversion, timestamp cross-check, elapsed value + issues, ESCALATE. Dòng cuối slide ghi không suy ra cửa sổ thời gian còn lại nào, hồ sơ không rõ hoặc không xác minh được thì escalate.

Trên dashboard, chị chọn cold ischemia time và chạy (demo trong video đăng ngày 25/10/2026). Cách naive nói còn 14 giờ. Bản escalation for review, bản có dùng thông tin của chị, nhìn vào thời điểm gốc (time origin) để chuyên gia có thể xem lại. Ở đây cũng có trace: semantic cold ischemia, rồi organ, số giờ, preservation (việc giữ lạnh để tạng còn tốt) và thời điểm ghi nhận. Theo chị, như vậy không có chuyện đoán mò hay hallucination.

![Dashboard so sánh ROUTINE TRANSPORT (LOW URGENCY) với ESCALATE FOR REVIEW cho cold ischemia time](https://homus.dev/photos/37GWykiKEak-1303.jpg)

Kết quả ca cold ischemia time (demo trong video đăng ngày 25/10/2026). Baseline: ROUTINE TRANSPORT (LOW URGENCY), "14 hours remaining", vì metadata định nghĩa bị bỏ trước khi diễn giải. Engineered: ESCALATE FOR REVIEW, "14 hours elapsed", có registry definition, time origin, và dòng "remaining safe window: not computed (never fabricated)". Test results 6/6 passed, trong đó có "840 minutes normalised to 14 h elapsed".

Trong code, cách thông thường chỉ đưa số giờ còn lại như một giá trị. Ở phiên bản engineered, chị đưa định nghĩa, chiều (direction), đơn vị, gốc của field, rồi các vấn đề, cách diễn giải và status (demo trong video đăng ngày 25/10/2026).

Theo Maryam (video đăng ngày 25/10/2026), độ rõ ràng của dữ liệu cũng giải quyết được rất nhiều vấn đề với agent. Về cơ bản là vì dữ liệu không có cấu trúc; nếu bạn đưa chúng về dạng có cấu trúc, nó có thể giúp bạn với rất nhiều vấn đề.

## 13. Demo ETA spiral: GPS event, event ID và stale counter

Quay lại bài toán. Failure thứ ba là agent càng nghĩ càng sai, với ETA (estimated time of arrival). Bình thường agent chỉ nhìn vào ETA trước đó. Điều Maryam muốn làm (video đăng ngày 25/10/2026) là có một GPS event; kiểm tra event ID; hỏi có bằng chứng mới không; nhìn khoảng cách và thời gian, tốc độ, tính ETA từ bằng chứng, đếm số lần dữ liệu cũ (stale count), và nếu dữ liệu cũ lặp lại quá nhiều thì escalate. Slide "ETA Spiral, Evidence versioning + a stale counter" vẽ bên Before là previous ETA trừ 10, lặp lại, kết thúc ở CONFIDENTLY WRONG ("Loop input = its own output"); bên After là GPS event, event_id check, new evidence?, nếu không có event mới thì ETA = unknown và stale_count + 1, còn nếu có thì distance + time, speed, ETA from evidence, stale_count = 0, và ESCALATE @ 2 stale loops ("No arithmetic on stale values").

Chị vào phần loop engineering, chọn ETA confidence và chạy (demo trong video đăng ngày 25/10/2026). Trên màn hình, ETA của baseline rơi từ 60 xuống 20 phút trong khi chiếc xe tải không hề di chuyển, không có lý do nào. Bên engineered có GPS event, được theo dõi rất chặt, và có thể chạy một mô phỏng vòng lặp deterministic, về cơ bản không có LLM. Ở đây có thể thấy tất cả những lần thử hoàn toàn vô ích kia.

![Dashboard ETA 20 MIN baseline và ESCALATE FOR REVIEW engineered với iteration lineage](https://homus.dev/photos/37GWykiKEak-1427.jpg)

Ca ETA confidence spiral (demo trong video đăng ngày 25/10/2026). Baseline: "ETA 20 MIN, ETA fell 60 → 20 min while the truck never moved", cùng một telemetry GPS ở mọi lần poll, khoảng cách 42 km không đổi, tốc độ suy ra tới 126 km/h ở bước 5. Engineered: ESCALATE FOR REVIEW, "No new GPS event → ETA UNKNOWN → human logistics review", cho phép 2 lần poll cũ rồi dừng, chạy 3 trên 5 vòng. Cả hai đều ghi "deterministic loop simulation · no LLM".

Tất nhiên vẫn có trace cho ETA spiral, kèm event ID và timestamp. Theo Maryam (video đăng ngày 25/10/2026), về cơ bản chị đang dùng cách theo dõi trực tuyến xem quả thận đang ở đâu, thay vì giả định xe sẽ tới vào một thời điểm cụ thể. Trong code có phần giả định (assumptions), có cách bắt đầu dựng vòng lặp ETA, và có phần đếm stale. Cuối cùng hàm trả về số vòng lặp, thời gian, telemetry, có tự đồng ý với chính mình (self-agreement) hay không, và tất nhiên là một quyết định.

## 14. Demo tối ưu vận chuyển: tách plan khỏi commit

Failure thứ tư cũng về xe cộ, nhưng là chuyện vừa cải thiện vừa đặt chỗ cùng một lúc. Theo Maryam (video đăng ngày 25/10/2026), để giải quyết cần có số vòng lặp tối đa, mức cải thiện tối thiểu; chị kiểm tra liên tục xem có kế hoạch trong bộ nhớ (in-memory plan) không, và chỉ commit khi đã được cho phép (authorized). Về cơ bản đây là tách plan khỏi commit: có thể lập kế hoạch trong vòng lặp, nhưng không được commit ngay. Cuối cùng, sau khi xem hết các kế hoạch, ví dụ có thể là một chuyến helicopter, mới commit vào đúng một kế hoạch. Như vậy tránh được chuyện đặt chồng chéo.

Flow "Endless Optimization, Stop conditions + plan/commit separation" vẽ lại theo slide trong video đăng ngày 25/10/2026 (lược bớt bước Plan improvement → In-memory plan nằm trước Commit): bên trái vòng lặp lấy báo giá, huỷ và đặt lại không có lối ra; bên phải mỗi bước kiểm tra đều có nhánh dừng, và chỉ commit khi đã được cho phép.

Trên dashboard, chị vào endless transport optimization và bấm Run Comparison (demo trong video đăng ngày 25/10/2026). Bên baseline là cảnh mắc kẹt trong vòng lặp không thoát ra được, vẫn đang tối ưu: màn hình ghi "DEADLINE MISSED (still optimizing)", 8 vòng, 9 lần đặt chỗ thử (mock bookings), 8 lần huỷ, đã dùng 48 trên 45 phút thời gian ra quyết định. Bên engineered là trạng thái chờ con người cho phép (PENDING HUMAN AUTHORIZATION): "Stopped after 2 cycles. One plan, zero bookings", dừng vì mức cải thiện dưới ngưỡng có ý nghĩa, dùng 12 trên 45 phút, với deadline cứng, tối đa 4 vòng lặp và mức cải thiện tối thiểu 5 phút (màn hình ghi các ngưỡng này là minh hoạ).

Hệ thống đưa ra một phương án cùng thông tin, và con người ra quyết định. Maryam nói ví dụ đó có thể là phương án 45 phút bằng helicopter; trên màn hình, kế hoạch đang chờ duyệt ghi "R-B ground, priority lane · 83 min" (demo trong video đăng ngày 25/10/2026). Chị chỉ thêm rằng chi phí và độ trễ của một phương án cao hơn hẳn phương án kia. Và lại có trace cho mọi thứ. Về code, có thao tác baseline trong loop engineering, và thao tác engineered có đủ các bước kiểm tra tối ưu như chị vừa giải thích trong flow.

## 15. Demo escalate everything: multi-objective gates

Failure thứ năm là AI thắng chỉ bằng cách không làm gì: né toàn bộ rủi ro và về cơ bản escalate mọi thứ. Cách thông thường là tối thiểu hoá lỗi rồi escalate hết. Nhưng theo Maryam (video đăng ngày 25/10/2026), nên đánh giá policy theo từng metric, qua bốn gate: critical, missed, autonomous và unnecessary. Rồi xem tất cả các gate có pass không, và chỉ khi đó mới chọn policy.

Flow "Escalate Everything, Multi-objective gates instead of a single objective" vẽ lại theo slide trong video đăng ngày 25/10/2026.

Trên dashboard evaluation, chị xem ca escalate mọi thứ và bấm Run Comparison (demo trong video đăng ngày 25/10/2026). Bên baseline: mọi thứ đã bị escalate; màn hình ghi "PASS · SELECTED", 0 lỗi tự động vì đã escalate 300 trên 300 ca, và tải xem xét của chuyên gia là 6.000 phút (giả định 20 phút mỗi ca). Bên engineered là cùng policy đó, nhưng giờ bị từ chối ("FAIL, same policy, now rejected"). Ở đây có các ca critical (30 trên 30 được escalate, pass), các escalation bị bỏ sót (0 trên 90, pass), autonomous completion (0 trên 210 ca đủ điều kiện, fail) và tỷ lệ escalation không cần thiết (210 trên 210, fail), cho thấy thật ra đã có bao nhiêu escalation không cần thiết.

Điều Maryam muốn là policy cân bằng dựa trên cờ, trên màn hình gọi là "Flag-based balanced" (demo trong video đăng ngày 25/10/2026): các ca critical đều được escalate, ít escalation bị bỏ sót, có autonomous completion, và tỷ lệ escalation không cần thiết phải thật thấp chứ không phải 100%. Trên màn hình, policy này pass với 107 trên 300 ca được escalate, 100% ca critical được escalate, 3% escalation bị bỏ sót và 90% autonomous completion; bảng ghi các ngưỡng là minh hoạ, đo trên 300 ca tổng hợp. Còn có policy tự động hoá mọi thứ (Automate everything), mà theo chị trong trường hợp này cũng có thể cực kỳ nguy hiểm; trên màn hình nó fail với 0% ca critical được escalate. Điều chị muốn là tính toán tất cả những chỉ số này, kèm phần cái gì fail, cái gì thay đổi, và các trace.

Về code, bản naive là baseline: chọn policy có ít lỗi quyết định tự động nhất. Gate multi-objective thì xem các ca critical (số ca critical được escalate so với tổng), số escalation bị bỏ sót, autonomous completion trên các ca đủ điều kiện, và tỷ lệ escalation không cần thiết (demo trong video đăng ngày 25/10/2026). Hàm baseline trên màn hình:

```
def safety_only_selection(cases: list[dict]) -> dict:
"""BASELINE: choose the policy with the fewest automated decision errors."""
scored = {name: evaluate_policy(cases, p) for name, p in CANDIDATE_POLICIES.items()}
winner = min(scored, key=lambda n: scored[n]["automated_decision_errors"])
return {"scores": scored, "selected": winner}
```

## 16. Demo 99% / 0%: confusion matrix và release gate

Failure cuối cùng là accuracy 99% trong khi 100 ca critical bị bỏ qua hoàn toàn. Theo Maryam (video đăng ngày 25/10/2026), nhìn qua thì có vẻ là một ngưỡng rất tốt và hệ thống nói pass. Nhưng ở bản sửa có confusion matrix: xem accuracy, recall, danh sách fail, và phép AND giữa các gate. Rồi ta thấy mình đang fail.

Flow "99% / 0%, confusion matrix + per-stratum gates" vẽ lại theo slide trong video đăng ngày 25/10/2026: bên trái một gate trung bình với ngưỡng 95% cho PASS; bên phải recall của nhóm critical (0 trên 100) được tách riêng, danh sách fail không rỗng nên kết quả là FAIL.

Trên dashboard, chị chọn ca accuracy và bấm Run Comparison (demo trong video đăng ngày 25/10/2026). Một bên là pass, bên kia chắc chắn là fail và không deploy: màn hình ghi "FAIL / DO NOT DEPLOY, same predictions, different verdict", accuracy 9.900 trên 10.000 bằng 99%, critical-case recall 0 trên 100 bằng 0%, gate là critical recall ít nhất 95% (ghi là minh hoạ), và dòng "The evaluation improved; the predictor did not." Tất nhiên cũng có trace cho ca này.

Về code, bản thông thường chỉ dùng confusion matrix rồi nhìn accuracy. Sau khi sửa, code xem accuracy, các con số đếm accuracy, critical recall, các con số đếm critical, các gate bị fail, và khi đó trả về kết luận: không deploy (demo trong video đăng ngày 25/10/2026).

Để tránh tất cả những lỗi này, Maryam (video đăng ngày 25/10/2026) khuyên dùng các checklist chị đã nêu cho semantic engineering, loop engineering và evaluation engineering.

## Nguồn và liên kết

- Tên gốc: Stop Building AI Agents Until You Watch This | 6 Failures, Fixes & Checklists
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=37GWykiKEak](https://www.youtube.com/watch?v=37GWykiKEak)

- Kênh YouTube Dr. Maryam Miradi (Maryam Miradi): [youtube.com/channel/UCIQzTfzErmrixae2oFqRxyg](https://www.youtube.com/channel/UCIQzTfzErmrixae2oFqRxyg)

- Gradio, thư viện Python mà Maryam dùng để dựng dashboard so sánh trong video đăng ngày 25/10/2026 (trang chủ đọc ngày 25/10/2026): [gradio.app](https://www.gradio.app/)

Nguồn: https://homus.dev/talks/stop-building-ai-agents-until-you-watch-this-6-failures-fixes-checklists · cập nhật 2026-10-25