The Missing Layer After Launch

1. Bạn đã ship agent. Rồi sao nữa?

Raphael mở đầu bằng một kịch bản rất quen: bạn đã build một agent, bạn đã launch nó, mọi thứ chạy khá tốt trong demo, và ai cũng vui. Nhưng giờ anh muốn hỏi vài câu đơn giản. Làm sao bạn biết agent đó thật sự đang chạy tốt ngoài kia? Làm sao bạn theo dõi được hàng trăm, hàng nghìn cuộc hội thoại thật mỗi ngày? Làm sao bạn cảm nhận, hiểu được sức khoẻ (health) của hệ thống? Làm sao bạn làm nó tốt hơn? Và làm sao bạn tìm ra những lỗ hổng mà bạn còn chưa biết là chúng tồn tại?

Slide tiêu đề The Missing Layer After Launch, AI Engineer World's Fair 2026 — Slide mở đầu: "The Missing Layer After Launch", với dòng phụ "Everything important starts after you ship", mọi thứ quan trọng đều bắt đầu sau khi bạn ship.

Theo anh, đó chính là vấn đề. Phần lớn các talk về agent kết thúc đúng vào khoảnh khắc bạn ship: chúng tôi build nó, nó chạy, hết. Nhưng Raphael nghĩ rằng ship mới là lúc công việc thật sự bắt đầu. Vậy mà không hiểu sao chỉ có rất ít người nói về giai đoạn này. Anh gọi nó là "the missing layer", tầng còn thiếu, và cả talk là để đi sâu vào tầng đó.

2. Ship bây giờ là phần dễ

Anh mô tả thế giới chúng ta đang sống: bạn có thể tạo ra cả một sản phẩm, thậm chí cả một startup, trong vài ngày hoặc vài tuần. Bạn có thể viết hàng trăm nghìn dòng code. Bạn có thể tiêu rất nhiều token. Và thành thật mà nói, với sự trợ giúp của các model mới nhất, đó là phần dễ nhất hiện nay.

Slide We shipped it in 3 weeks với ba ô số: 3 wks, ~300K lines, ~$35K spent — "We shipped it in 3 weeks.": trên slide ghi ba con số của chính đội Wandero, 3 tuần tới sản phẩm đầu tiên, khoảng 300 nghìn dòng code, và khoảng 35 nghìn đô la đã tiêu. Dòng chân slide: "Shipping is fast now. That was the easy part", ship giờ nhanh rồi, và đó là phần dễ.

Nhưng anh nhắc lại: ship là lúc công việc thật sự bắt đầu, vì bạn cần khép vòng loop (close the loop) càng sớm càng tốt. Sau khi launch, bạn cần có một mức kiểm soát và hiểu biết nhất định về hệ thống. Từ kinh nghiệm của Raphael, vòng loop đó ít nhất cũng quan trọng ngang với chính sản phẩm, đôi khi còn quan trọng hơn, vì chính vòng feedback chặt (tight feedback) là thứ giúp bạn làm sản phẩm tốt hơn từng ngày. Đó là tầng còn thiếu, và phần còn lại của talk nói về nó.

3. Sau launch: những câu hỏi cũ, độ khó mới

Vậy điều gì xảy ra sau khi bạn launch? Anh nói thẳng là không có gì bất ngờ ở đây. Phần mềm cổ điển cũng có đúng những câu hỏi này: bạn cần monitor những gì đang xảy ra, bạn cần hiểu hệ thống hành xử ra sao, bạn cần có log để phát hiện vấn đề và sửa chúng. Có điều với hệ thống agentic, từng việc một trong số đó đều khó hơn, và đôi khi chúng biến thành một thứ thật sự mới.

Câu hỏi tiếp theo là vì sao việc này khó, và vì sao nó khó ngay bây giờ. Agent không phải phần mềm bình thường. Bạn không có vài tính năng và vài cái nút. Bạn không có một luồng định sẵn (predefined flow) để test trước khi lên live. Và phạm vi bao phủ (coverage) là vô tận. Hãy nghĩ tới Claude Code hay Codex: chúng làm được một dải việc khổng lồ, bất cứ thứ gì user cần. Phần lớn agent khác cũng vậy: bạn đưa instruction, và chúng xử lý. Bạn không thể viết trước tất cả các cuộc hội thoại.

Sơ đồ How do you even know it's healthy? với PRODUCT AGENT ở giữa và bốn câu hỏi Monitor, Understand, Improve, Find the holes — "How do you even know it's healthy?": product agent đứng giữa hàng nghìn cuộc hội thoại và gần như vô số task, với bốn câu hỏi xung quanh: monitor nó, hiểu nó, cải thiện nó, tìm lỗ hổng của nó. Dòng đỏ ở dưới: "You lose the feel for your own system", và chân slide nói rằng lấy lại cảm giác đó chính là mục tiêu.

4. Bạn mất cảm giác về chính hệ thống của mình

Điều này dẫn tới phần sâu nhất của vấn đề, phần khiến Raphael mất ngủ cả đêm: bạn mất cảm giác (lose the feel) về chính hệ thống của mình. Sau khi build sản phẩm, bạn cần có một kiểu hiểu biết nào đó: nó đang tốt lên hay tệ đi? Bạn cần monitor, cần hiểu những gì đang diễn ra.

Và vấn đề là các lưới an toàn (safety net) thông thường không cứu được bạn ở đây. Anh kể đội anh đã thử khá nhiều thứ: viết unit test, dùng regex, dùng các check dựa trên rule (rule-based check), thậm chí viết script để mô phỏng cuộc hội thoại của khách hàng. Những thứ đó có giúp theo một số cách. Nhưng rốt cuộc, mỗi thứ chỉ là một lát cắt của toàn bộ vấn đề, vì khách hàng luôn làm điều gì đó khác. Bạn không thể viết ra hết. Chúng quá nhiều, và chúng đều khác nhau. Đường chân trời (horizon) của task cũng vậy. Bạn không biết agent của mình sẽ làm gì cho tới khi nó ở production.

Slide You're not the only one với ảnh chụp một bài viết của Harrison Chase: You don't know what your agent will do until it's in production — "You're not the only one": ảnh chụp một bài viết của Harrison Chase với tiêu đề "You don't know what your agent will do until it's in production", kèm sơ đồ vòng lặp gồm online evals, annotation queues, datasets và experiments. Chân slide: phần khó bắt đầu sau khi bạn ship, vì bạn không biết agent làm gì cho tới khi nó lên live.

5. Lý do thứ nhất: non-deterministic, task vô tận

Vậy vì sao đây là một vấn đề mới? Như mọi người đã biết, LLM không có tính tất định (non-deterministic). Cùng một input có thể đi theo một đường khác. Ngay cả một chỉnh sửa nhỏ trên input cũng có thể dẫn tới một trajectory khác. Cộng thêm việc coverage là vô tận: bạn không thể liệt kê hết, nên bạn không thể test trước cho tới khi đi vào production.

Một input, nhiều trajectory: với LLM, cùng một yêu cầu (hoặc một yêu cầu chỉ khác chút ít) có thể đi theo những con đường rất khác nhau, nên không có danh sách hữu hạn nào để test trước. Các nhánh ví dụ lấy từ chính những tình huống Raphael kể ở các phần sau.

6. Lý do thứ hai: failure tự giấu mình

Lý do thứ hai, và là lý do đáng sợ nhất: failure tự giấu mình. Hãy nghĩ xem điều gì xảy ra khi agent chạy trong một thời gian dài. Nó vật lộn ở giữa task. Nó gặp vấn đề, nhưng nó gặp may và hồi phục được. Nó tìm ra một cách đi vòng (workaround), thử vài tool call khác hay gì đó, và bạn không nhận được cảnh báo đỏ nào, không có vấn đề gì trên dashboard. Mọi thứ trông ổn.

Nhưng thật ra, đây là một cảnh báo sớm cho bạn. Đây là một vấn đề bị giấu kín, đang sống trong codebase của bạn, và bạn cần sửa nó càng sớm càng tốt. Vì nếu ta đang nói về agent đáng tin cậy (reliable agent), thì nó không được phép phụ thuộc vào may mắn.

Slide 02 Invisible failure: The failure hides itself, với hai trích dẫn từ Anthropic và Northeastern red-team — Lý do 02, invisible failure: "The failure hides itself." Hai bằng chứng trên slide: Claude đánh dấu tính năng là "complete" mà không kiểm xem chúng có chạy thật không (bài "Effective harnesses for long-running agents" của Anthropic), và agent báo thành công trong khi state của hệ thống nói điều ngược lại (một nhóm red-team ở Northeastern). Chân slide: không có gì crash, không có gì chuyển đỏ, không ai biết.

Anh dẫn thêm: như Anthropic đã viết trong một bài blog, đôi khi agent rất thích đánh dấu một tính năng là đã hoàn thành mà không kiểm tra xem nó có thật sự chạy hay không.

7. Lý do thứ ba: tool surface khổng lồ, và "finished" chưa chắc là "helpful"

Lý do tiếp theo là tool calling. Bề mặt tool (tool surface) rất lớn. Một task chạy dài cần hàng trăm tool, thậm chí hàng nghìn. Đôi khi giữa chừng có vài lần summarization. Nó dùng sub-agent, viết rất nhiều code, chắc chắn có dùng terminal. Nó gọi dịch vụ của các công ty khác, các thư viện bên thứ ba, và những thứ đó lúc nào cũng hoạt động theo cách khác nhau. Nói cách khác, bạn thật ra không biết mình đang tìm cái gì.

Slide 03 Huge tool surface: One task. Hundreds of tools. — Lý do 03, huge tool surface: "One task. Hundreds of tools." Agent viết code, chạy terminal, gọi dịch vụ của công ty khác. Chân slide: mỗi tool là một cách mới, lặng lẽ, để hỏng.

Đôi khi "finished" không có nghĩa là có ích cho user. Có thể chẳng có vấn đề gì cả: agent chạy xong, mọi thứ trông ổn, câu trả lời được ghi là thành công. Nhưng anh lấy ví dụ từ chính use case của Wandero: đôi khi user nhờ dựng một lịch trình (itinerary), agent chạy flow và dựng ra một chuyến đi, nhưng nó lại book một dịch vụ khác, và tính giá sai rất nhiều chỗ, nên user không vui. Về mặt kỹ thuật thì thành công, nhưng vẫn thất bại ở chính task đó.

Và như anh đã nói, unit test không cứu bạn ở đây. Production mới là nơi bạn học được mình cần test cái gì ngay từ đầu.

Slide Tests don't fit: Unit tests catch a sliver. — "Unit tests catch a sliver.": unit test chỉ bắt được một lát mỏng. Chân slide: production là nơi bạn học ra mình cần test cái gì.

8. Logs là source of truth, và vận hành agent là một bài toán agent

Vậy sau khi launch sản phẩm, bạn cần monitor, cần hiểu, và cần cải thiện hệ thống. Source of truth ở đây là gì? Là logs. Ai cũng có logs, ai cũng yêu logs. Bạn có thông tin có cấu trúc (structured). Và các cỗ máy hiện nay là thứ giỏi nhất để hiểu và khám phá logs, giỏi hơn bất kỳ con người nào, nhanh hơn nhiều. Chúng có thể viết script để lọc cả một bức tường log khổng lồ. Đây là thứ hiển nhiên nhất mà bạn có thể giao cho agent.

Nhưng ngay khi bắt đầu làm việc đó, có thể bạn build một agent, một skill hay gì đó, bạn sẽ nhanh chóng hiểu ra là nó không dễ như bạn tưởng, vì nó cần rất nhiều reasoning. Bạn cần hiểu vấn đề để phân biệt đâu là bug thật và đâu là nhiễu (noise), để đào sâu vào trace hay trajectory của nó, để hiểu đó là triệu chứng (symptom) hay nguyên nhân gốc (root cause). Thế là bạn nhận ra rằng chính việc vận hành một agent cũng là một bài toán agent.

Slide The shift: Operating an agent is itself an agent problem. — "Operating an agent is itself an agent problem.": "Noise hay bug?", "lần ra nguyên nhân", "root cause hay symptom?", tất cả đều là việc cần reasoning. Chân slide: "So I put agents on the operations", nên anh đặt agent vào việc vận hành.

9. Vòng loop khép kín: từ trace tới pull request

Vậy là bạn có một vòng loop đầu cuối (end-to-end). Bạn có traces, có trajectories, bạn cho agent quyền truy cập codebase. Nó chẩn đoán vấn đề, hiểu chuyện gì đã xảy ra, rồi gửi một PR. Sau đó bạn có thể có một skill, một sub-agent hay bất cứ thứ gì kiểm soát PR đó, vì như mọi người biết, phần lớn agent đều rất hăng gửi PR. Chúng thích sửa vấn đề.

Sơ đồ The closed loop: Production sessions, Logs and traces, Trajectory, Code path, Diagnosis, Pull request, PR review, Human review và merge, Dashboard, Next fix — "The closed loop": production sessions đi qua logs và traces, trajectory, code path, diagnosis, rồi thành pull request do log-monitor mở. PR review (một agent) lặp với PR "until ready", sau đó con người review và merge, kết quả lên dashboard, rồi tới lần fix tiếp theo và quay lại production. Chân slide: "The agents watch and draft. The human decides."

Đội anh thích có một agent riêng với context mới (fresh context). Nó cố gắng kiểm PR từ một góc khác, một cách nhìn khác, chạy các test tập trung (focused test). Nó không bị thiên kiến bởi chính vấn đề ban đầu. Nó cố gắng phê bình, chấm điểm PR, và đôi khi yêu cầu thay đổi. Có thể nó đóng thẳng PR, và như vậy giúp đội lọc bớt những vấn đề đó. Rồi sau đó có human-in-the-loop. Đôi khi thì không có, và anh hẹn sẽ nói thêm về chuyện này sau.

Đây là thứ hiển nhiên nhất mà bạn có thể giao cho agent, và nó có vẻ khá hiển nhiên với phần lớn mọi người. Nhiều đội cũng làm theo cùng cách này. Nhưng anh cho rằng người ta không đánh giá đúng tầm quan trọng của nó. Bạn cần bỏ thời gian vào đó. Bạn cần calibrate, cần làm nó reliable, để có thể tin vào vòng loop. Và đây là vòng loop nhanh nhất mà đội anh từng có.

Sau khi dựng hệ thống đơn giản này, bạn đã có cảm giác và hiểu biết về cách nó hành xử, chuyện gì đang diễn ra. Bạn phát hiện vấn đề và tìm cách sửa càng sớm càng tốt. Bạn có thể có một PR sẵn sàng trong nửa tiếng, và dễ dàng hiểu được chuyện gì đang xảy ra.

10. Cách Raphael làm: bốn operating agent

Tiếp theo anh dẫn người nghe qua cách chính anh xử lý chuyện này. Có thể nó không tối ưu, anh nói, nhưng nó sẽ giúp mọi người nắm được ý.

Về cơ bản, đội anh có hai luồng chính. Luồng thứ nhất là vòng loop nhanh nhất, giúp phát hiện và sửa vấn đề càng sớm càng tốt. Luồng thứ hai thì nhìn rộng hơn (zoom out), giúp bạn có hiểu biết ở mức cao, giúp bạn luôn bắt mạch (hand on the pulse) của hệ thống.

Slide How I handle it: Four operating agents, log-monitor, PR-review, session-analyzer, QA / computer-use — "Four operating agents.": trên slide là bốn agent: 01 log-monitor, phát hiện và sửa nhanh (reactive); 02 PR-review, gác cổng cho bản fix (reactive); 03 session-analyzer, cảm nhận sức khoẻ hệ thống (reactive); 04 QA / computer-use, chủ động đi test (proactive, đang nằm trên roadmap). Chân slide: "One example, not a recipe", một ví dụ, không phải công thức.

Luồng thứ nhất là log monitoring agent, cái anh đã nhắc tới ở trên. Bạn có trajectories, có logs, có quyền truy cập codebase, và agent này chạy mỗi giờ, hoặc mỗi mười lăm phút một lần.

11. Log-monitor: PR và cảnh báo Slack

Log-monitor cố gắng hiểu vấn đề. Nó đào sâu vào logs, xem user có bị kẹt (stuck) ở đâu không, rồi gửi PR, hoặc đôi khi gửi cảnh báo qua Slack. Phần Slack này khá quan trọng, vì có những vấn đề nghiêm trọng tới mức đội cần sửa ngay lập tức. Và theo anh, nó chạy khá tốt.

Slide Log-monitor, the PR it opened: một pull request fix: guard inbound-webhook read during conversation state change, có Log Health Report và sơ đồ flow — "Log-monitor, the PR it opened": một PR thật do agent mở, tiêu đề "fix: guard inbound-webhook read during conversation state change", phần mô tả là một Log Health Report kèm sơ đồ flow cho thấy điểm hỏng. Chân slide: một bản mô tả rõ ràng, một sơ đồ flow, bằng chứng, để review chỉ trong một cái liếc.

Đây là một ví dụ PR trông ra sao. Bạn có một phần mô tả gọn, một lời giải thích ngắn về chuyện gì đang xảy ra. Bạn có metadata. Bạn có sơ đồ đẹp, dạng Mermaid hoặc bảng ASCII. Có thể bạn còn có một HTML artifact giúp bạn nhìn lướt qua vấn đề và nhanh chóng hiểu PR này để làm gì.

Còn đây là ví dụ một thông báo Slack trông ra sao. Nó cho bạn feedback nhanh, giúp phát hiện nếu có vấn đề nghiêm trọng. Đôi khi nó chỉ là một lời báo trước (heads-up): bạn biết có vài cảnh báo, vài vấn đề, và bạn sẽ kiểm chúng khi có thời gian.

Slide Log-monitor, Slack: hai tin Slack, một Log Monitor heads-up có PR, một Log Monitor follow-up về billing không có PR — Hai kiểu tin Slack. Trên: "Our bug, it opens a PR and tells me", một lỗi của chính hệ thống (email inbound bị rơi vĩnh viễn vì một header dài hơn giới hạn của cột) và agent đã tạo PR. Dưới: "Outside billing issue, just a heads-up, no PR", một vấn đề billing ở nhà cung cấp parse tài liệu bên ngoài, agent tự hồi phục qua fallback, không user nào bị chặn, và bước tiếp theo là nâng hạn mức credit chứ không cần sửa code. Chân slide: nó chỉ cảnh báo khi đáng cảnh báo, và biết phân biệt hai loại.

12. PR-review và câu hỏi con người có phải bottleneck

Như đã nói, review agent cực kỳ quan trọng, vì nó cố gắng kiểm vấn đề từ một góc khác. Nó luôn cố phê bình, chấm điểm, và khi đã sẵn sàng thì nó gửi PR cho con người.

Sơ đồ Agent 02 PR-review: Pull request vào Review agent (different angle) gồm checkout the branch, run focused tests, typecheck + lint, root cause or symptom, ra Verdict READY rồi tới Human review + merge — Agent 02, PR-review: pull request đi vào review agent nhìn từ một góc khác. Agent này checkout branch, chạy focused test, typecheck và lint, và trả lời câu hỏi then chốt "root cause, or symptom?". Nếu verdict chưa READY, vòng lặp quay về PR; nếu READY, con người review và merge.

Có người đặt vấn đề là liệu bạn có cần human-in-the-loop không, vì trong trường hợp này con người vẫn là bottleneck. Ở Wandero, PR agent và review agent gửi số PR mỗi ngày gấp mười lần ba người trong đội cộng lại. Nên bạn cần một hệ thống gọn gàng để xử lý lượng đó, để mình không trở thành bottleneck của hệ thống.

Slide The review: hai bài đăng, một về Killing the Code Review, một của Peter Steinberger về autoreview và crabbox.sh — "The review": hai bài đăng về code review trong thời agent. Bên trái là một bài về chuyện bỏ khâu code review của con người ("Killing the Code Review"). Bên phải, Peter Steinberger viết rằng autoreview là skill có tác động lớn nhất anh đã thêm vào stack (cạnh crabbox.sh), tự động review code trước khi landing một PR, tìm ra rất nhiều edge case, đôi khi chạy hàng giờ. Chân slide: "Review is the bottleneck, keep it sharp, and advisory."

Nhưng từ kinh nghiệm của anh, như đã nói, PR agent và review agent giúp anh có phần mô tả đẹp và vài artifact để nhanh chóng hiểu vấn đề. Có thể anh bỏ ra vài phút để ít nhất hiểu chuyện gì đang xảy ra. Anh nghĩ hiện tại như vậy là ổn, nhưng có thể sau này đội sẽ bỏ bước đó. Người ta đang bàn về chuyện này: bạn không nên là bottleneck của bài toán, và một số người chọn bỏ hẳn con người khỏi vòng loop. Nhưng xu hướng là bạn cần khép vòng loop trước. Hãy để bài toán đi tới chỗ chính bạn là bottleneck, rồi sau đó bạn có thể tự rút mình ra khá dễ dàng.

Anh cho xem vài ví dụ feedback của review agent. Như mọi người thấy, nó yêu cầu một số thay đổi. Có phần tóm tắt, có sơ đồ, có giải thích những chỗ có rủi ro, những edge case. Đôi khi sau vài vòng lặp, hai agent đi vào vòng loop cho tới khi code sẵn sàng và không cần thay đổi gì thêm. Sau đó con người mới nhảy vào vòng loop.

Slide PR-review, caught a symptom patch: một review với decision needs changes — "PR-review, caught a symptom patch": một review thật với risk cao, decision là "needs changes", kèm Review Summary, những gì ổn, sơ đồ flow và bảng rủi ro. Chân slide: verdict "needs changes", bug chỉ bị che đi chứ chưa được sửa.

Slide PR-review, the root-cause fix: review với decision ready và checks passed — "PR-review, the root-cause fix": vòng sau, cùng định dạng review nhưng decision là "ready", checks đã pass. Chân slide: verdict "ready", sửa đúng root cause, kèm một test tái hiện được lỗi.

13. Session-analyzer: cảm nhận sức khoẻ của cả hệ thống

Agent trước đó, như anh đã nói, đặc biệt tốt khi bạn muốn sửa các vấn đề cục bộ. Trong trường hợp của Wandero, nó chạy mỗi giờ, chỉ kiểm một cửa sổ log dài một giờ, và nó không có hiểu biết ở mức cao về vấn đề. Nên đội nhận ra họ cần một hệ thống khác, giúp có được lời giải thích ở mức cao hơn, một kiểu sức khoẻ của hệ thống.

Và visibility, khả năng nhìn thấy, là mảnh dễ nhất. Trước khi có agent, việc đó là bất khả: bạn không thể đào sâu hay tóm tắt hàng trăm cuộc hội thoại. Nhưng giờ thì bạn có thể có một hệ thống chấm điểm mọi cuộc hội thoại, hiểu chuyện gì đang xảy ra, và cho bạn một góc nhìn tổng thể về hệ thống. Trên slide, anh trích lời Dev Shah: visibility là mảnh dễ nhất, phần khó là phân tích và hiểu những gì bạn đang quan sát; nhiều đội ghi hơn 100 nghìn trace mỗi ngày nhưng gần như không làm gì với chúng, vì không con người nào đọc và tóm tắt được 100 nghìn trace. Đó là việc của agent tiếp theo.

Đó là session-analyzer, và mục tiêu chính của nó chỉ là cho anh điểm sức khoẻ của hệ thống. Đội cố gắng kiểm tra từng cuộc hội thoại, cho chạy qua rất nhiều sub-agent. Nó tiêu rất nhiều token. Nhưng nó giúp đội phát hiện các pattern, nối các điểm lại với nhau (connecting the dots), và hiểu các pattern ở mức cao. Nó cũng phát hiện các cụm vấn đề (cluster problems): nguyên nhân là gì, dùng bao nhiêu tool call, bao nhiêu sub-agent, bao nhiêu lần summary đã xảy ra, vân vân. Và nó còn đưa ra AI insights, các entity, để đội hiểu được vấn đề.

Sơ đồ Agent 03 session-analyzer: sessions vào session-analyzer, 1 analyse EVERY session theo outcome, quality, cost và issues, 2 collapse into patterns, ra Feel the pulse 77/100 health score — Agent 03, session-analyzer: các session đi vào agent, bước 1 phân tích MỌI session theo outcome, quality, cost và issues; bước 2 gộp thành pattern ("cùng một vấn đề qua nhiều session = MỘT pattern"). Đầu ra là "Feel the pulse": điểm sức khoẻ 77/100, tỉ lệ thành công và xu hướng chi phí. Dòng xanh ở dưới slide là một trích dẫn: Anterior đạt khoảng 95% nhờ model, rồi lên 99% nhờ build đúng loại vòng loop này trên production.

Như anh đã nói, một trong những vấn đề chính là bạn mất kiểm soát sau khi launch lên production. Nên bạn cần một hệ thống giúp bạn kiểm soát, ít nhất là có chút hiểu biết về những gì đang xảy ra, nó trông ra sao, nó có khoẻ hay không.

Slide The gold: Many sessions, one pattern. 200 scattered issues to 6 named root causes, each with an owner. — "Many sessions, one pattern.": trên slide ghi 200 vấn đề rời rạc được gom thành 6 root cause có tên, mỗi cái có một người chịu trách nhiệm. Chân slide: một danh sách không ai đọc trở thành một kế hoạch làm việc.

14. Bên trong dashboard tự build

Rồi anh cho xem hệ thống trông ra sao trong thực tế. Đội tự build nó. Có rất nhiều công ty và công cụ khác cung cấp đúng kiểu hệ thống này, nhưng anh thích tự build hơn, vì anh biết mình quan tâm tới cái gì, mình đang tìm cái gì.

Dashboard System Health Score 77/100 với các ô Sessions Analyzed 97/97, Total Cost, Average Score 7.7, Success Rate 84.5%, biểu đồ xu hướng và danh sách AI Insights — Đầu dashboard: System Health Score 77/100; 97/97 session đã được phân tích; tổng chi phí 216,67 đô la; điểm trung bình 7,7; tỉ lệ thành công 84,5%, partial 15,5%, failed 0%, một session cần review. Bên dưới là ba biểu đồ (score trend, số session mỗi ngày, chi phí mỗi ngày) và danh sách AI Insights, ví dụ dữ liệu tồn kho bị cũ, khẳng định với khách hàng mà không có nguồn, nên nói rõ mức độ chắc chắn (hedge) thay vì đoán, hay một lần lách qua lớp bảo vệ an toàn của hệ thống booking.

Như mọi người thấy, ở đây có sức khoẻ của hệ thống, số session đã được phân tích, chi phí, điểm trung bình, tỉ lệ thành công. Có các xu hướng (trends), có AI insights, và đây là phần quan trọng nhất: khi AI, hay chính xác là khi agent, cố gắng nối các điểm và tìm ra pattern. Nếu có cái nào nghiêm trọng, bạn có mô tả cho từng cái: nó là gì, vì sao quan trọng, root cause là gì, tất cả các session bị ảnh hưởng, và một đề xuất sửa (recommendation fix).

Anh lưu ý rằng dữ liệu đang chiếu là dữ liệu đã được ẩn danh (anonymized), nhưng nó đến từ các cuộc hội thoại thật. Có phân bố điểm (score distribution), số session và chi phí theo từng công ty khách hàng. Có sentiment analysis, có các entity. Có analytics về tool call: tỉ lệ thành công, bao nhiêu cái bị từ chối và vì sao. Và có phân tích chi tiết từng session: hệ thống xếp hạng từng session, chấm điểm, nó chạy bao nhiêu lần, bao nhiêu message, bao nhiêu tool call, bao nhiêu lần summary, kèm một lời giải thích chi tiết cho mỗi session, vấn đề là gì, có phải thứ bạn cần xem kỹ hay không. Anh bảo mọi người hãy tin anh, nó giúp rất nhiều, và nó giúp bạn kiểm tra, theo dõi được hàng trăm cuộc hội thoại.

Báo cáo chi tiết một session s-096 với outcome SUCCESS, score 8/10, các intent, entity, danh sách issues và tools used — Báo cáo chi tiết của một session đã ẩn danh: outcome SUCCESS, điểm 8/10, 29 lượt, 441 tool call. Khách muốn thu thập thông tin hành khách và gửi lịch trình; agent hiểu yêu cầu và đi thẳng tới kết quả. Dù vậy, analyzer vẫn liệt kê năm issue: khẳng định một sự thật không có nguồn rõ, bản ghi cũ cần đối chiếu, đi đường chậm ở một task dài, hỏi lại user một chi tiết đã có, và một lỗi định dạng nhỏ trong deliverable.

Mục tiêu chính của dashboard và của hệ thống này không phải là sửa một vấn đề hay một bug cụ thể. Nó ở mức cao hơn, giúp bạn theo dõi hàng trăm hay hàng nghìn cuộc hội thoại thật. Bạn có thể chạy nó mỗi tuần một lần, hai lần một tuần, hay tương tự.

15. QA / computer-use: đi tìm thứ sắp hỏng

Đến agent tiếp theo. Vấn đề của hai agent trước là thế này: agent thứ nhất giúp bạn phát hiện các vấn đề cụ thể, agent thứ hai cho bạn hiểu biết ở mức cao, nhưng cả hai đều làm việc từ góc nhìn của logs, của code, hay của chính session. Bạn vẫn cần một góc nhìn từ phía user.

Slide Agent 04 QA / computer-use: Go looking for what's about to break, với hai trích dẫn từ Anthropic và Factory — Agent 04, QA / computer-use: "Go looking for what's about to break." Trên slide ghi agent này đang trên roadmap và đang được build lại, nó điều khiển sản phẩm thật như một user. Hai tham chiếu: Anthropic viết rằng công cụ test giúp "cải thiện hiệu năng đáng kể" khi agent dùng app như một user (bài "Effective harnesses for long-running agents"), và Factory có một validator điều khiển app thật qua computer use trong tính năng "missions".

Vì vậy đội có một computer use agent: nó mở browser, đăng nhập, và cố gắng mô phỏng chính khách hàng, vì đôi khi bạn có vấn đề ở UI. Bạn cần kiểm xem mọi thứ trông có ổn không, và đôi khi code với logs không giúp bạn được ở mặt này.

Anh cho xem ví dụ. Đôi khi đội dùng Codex, và nó dùng chính browser. Thật ra cách này khá chậm. Nên đội thử build một skill riêng biết website của họ, biết DOM của họ trông ra sao, và như vậy nhanh hơn nhiều. Agent có thể mở website, đăng nhập, mở một session, gửi message, kiểm tra chuyện gì đang xảy ra, và kiểm cả giao diện trông thế nào, các artifact ra sao. Nó chạy khá tốt. Nhưng anh nhắc bạn cần biết rằng nó sẽ tiêu rất, rất nhiều token.

Demo computer-use: agent điều khiển sản phẩm thật, màn hình hiện một Romania 3-Day Itinerary Work Plan — Demo QA / computer-use chạy live: agent điều khiển sản phẩm thật như một user, ở đây là một phiên tạo kế hoạch lịch trình 3 ngày ở Romania. Chân slide: nó dùng sản phẩm thật như một user, và tìm ra bug trước khi khách hàng gặp.

16. Meta harness: đừng đưa agent một lỗ khoá

Với tất cả những bài toán trên, anh nhắc rằng bạn cần cho agent quyền truy cập mọi loại tool cần thiết. Bạn cần có logs, trajectories và metrics, database, UI, đúng những thứ mà con người cần. Bạn cần đưa toàn bộ context, mọi khả năng, để agent hiểu được chuyện gì đang xảy ra. Ví dụ với computer use agent, khi phát hiện vấn đề, nó phải có khả năng phân tích trajectories, kiểm database để hiểu chuyện gì đã thật sự xảy ra.

Sơ đồ The enabler: Your live product nối tới Logs, Trajectories, Metrics, Database, Live UI, rồi tới Internal harness gồm log-monitor, PR-review, session-analyzer, QA computer-use, rồi tới Slack the nervous system — "The enabler": sản phẩm live cung cấp năm nguồn: logs (cái gì hỏng), trajectories (nó đang nghĩ gì), metrics (bao nhiêu, nhanh ra sao), database (chuyện gì thật sự xảy ra), live UI (user đã thấy gì). Tất cả đổ vào internal harness gồm log-monitor, PR-review, session-analyzer và QA / computer-use (đang trên roadmap), rồi ra Slack, "the nervous system", hệ thần kinh. Dòng viết tay: "Don't give them a keyhole. Give them the whole room." Chân slide: hãy đưa agent tất cả, nếu không chúng chỉ đang đoán.

Đó là lý do anh gọi cả hệ thống này là meta harness: khi mọi thứ được nối lại với nhau, và PR hay câu trả lời từ agent dựa trên vấn đề thật, chứ không phải đoán xem chuyện gì đang xảy ra.

Sơ đồ dưới đây gom bốn operating agent theo hai trục mà Raphael mô tả: vòng nhanh để sửa cục bộ và vòng zoom out để cảm nhận sức khoẻ, cộng thêm góc nhìn của user.

Bốn operating agent của Wandero: hàng trên là vòng loop nhanh (log-monitor mở PR, PR-review gác cổng), hàng dưới là góc nhìn rộng (session-analyzer chấm điểm mọi session) và góc nhìn user (QA / computer-use). Kết quả cuối cùng tới con người qua PR cần merge và tin Slack.

17. Moat không nằm ở model: hãy khép vòng loop trước

Vậy moat, lợi thế phòng thủ, không nằm riêng ở model. Bạn cần build một agent, một hệ thống, hay một harness bao quanh model, thứ tự theo dõi chính nó, tự hiểu, tự cải thiện, và ít nhất là giúp bạn monitor những gì đang xảy ra. Còn trong trường hợp lý tưởng thì nó khép vòng loop: gửi PR tự động, gửi thông báo tới bất cứ đâu, và giúp bạn tăng tốc cả quá trình.

Slide The bigger pattern: The harness that watches itself is the moat, với bài đăng của Greg Brockman: the model alone is no longer the product — "The harness that watches itself is the moat.": slide dẫn bài đăng của Greg Brockman, "the model alone is no longer the product", chỉ riêng model không còn là sản phẩm. Chân slide: model là phần bạn thay được, vòng loop là phần bạn sở hữu.

Ship là phần dễ nhất hôm nay. Nếu bạn muốn build một production agent, bạn cần khép vòng loop trước, vì không hiểu sao người ta không nói về chuyện nó quan trọng thế nào, về những gì xảy ra sau khi bạn launch. Ai cũng có thể có cùng một model, ai cũng có thể có cùng một agent hay harness. Nhưng bạn cần có một hệ thống nội bộ giúp bạn trong quá trình này: phát hiện vấn đề, cho bạn cảm giác về những gì đang diễn ra, và giúp sản phẩm tốt lên. Raphael kết thúc bằng lời cảm ơn.

Slide kết Shipping was the easy part, với câu trích của Raphael và tên Raphael Kalandadze, CTO, Wandero AI — Slide kết: "Shipping was the easy part." Câu trích của chính anh: "you want a production agent? cool. but first, close the loop. the loop is the product", bạn muốn một production agent ư, được thôi, nhưng trước hết hãy khép vòng loop, vòng loop chính là sản phẩm. Kèm tên Raphael Kalandadze, CTO của Wandero AI, và địa chỉ wandero.ai.