Chat and citations won't save your vertical AI

1. Lời hứa của vertical AI và hai giao diện mặc định

Atul mở đầu bằng chính tên talk: chat và citations sẽ không cứu được sản phẩm vertical AI của bạn. Anh đoán rằng nhiều người đang nghe cũng đang xây sản phẩm trong một ngành dọc (vertical industry) nào đó, có thể là y tế (healthcare), pháp lý (legal) hay thuế (taxes). Và khi làm việc đó, chúng ta thường bán cho khách hàng một lời hứa duy nhất: hoặc là giúp bạn tiết kiệm tiền, hoặc là giúp bạn tiết kiệm chi phí. Lời chào hàng quen thuộc thường đi như thế này: AI agent đã đến rồi, chúng sẽ làm việc thay bạn trong lúc bạn ngủ.

Hiện nay, giao diện chính mà chúng ta dùng để tương tác với một AI agent là chat và citations. Chat thường được dùng cho đầu vào (input): nó cho phép bạn linh hoạt, muốn nói chuyện với agent kiểu gì cũng được. Còn citations, tức các trích dẫn nguồn, thường được dùng cho đầu ra (output): chúng cho phép bạn xem kết quả, kiểm tra (verify) kết quả, và vân vân.

Và Atul nói thẳng luận điểm của cả talk: chỉ riêng citations và chat sẽ không giúp bạn giữ được lời hứa đã đưa ra cho khách hàng, lời hứa tiết kiệm thời gian và tiền bạc cho họ.

2. Atul là ai, Filed làm gì

Vậy anh là ai? Atul là CTO và co-founder của Filed. Anh may mắn đã được xây sản phẩm hơn một thập kỷ. Ở Filed, đội của anh xây sản phẩm cho những người làm nghề thuế (tax professionals) tại Mỹ. Công ty đã gọi vốn được hơn mười bảy triệu đô la để làm việc này.

Họ đã làm việc này được khoảng hai năm và chứng kiến thị trường tăng trưởng rất mạnh. Để mọi người hình dung: chỉ riêng tháng vừa rồi, Filed đã chốt được nhiều doanh thu hơn cả những gì họ làm được trong suốt một năm trước đó. Tốc độ tăng trưởng rất lớn, và cả đội đang rất hào hứng.

Trong suốt hành trình hai năm đó, họ đã học được khá nhiều. Và Atul cho rằng phần lớn những bài học từ việc xây AI agent cho ngành thuế về cơ bản có thể chuyển sang bất kỳ sản phẩm agentic nào khác. Ví dụ trong talk là về thuế, nhưng khuôn mẫu là chung.

3. Chat và citations tốt ở chỗ nào

Trước khi phê bình, Atul ghi nhận phần tốt. Chat rất tuyệt. Nó cho phép chúng ta build nhanh. Nó cho phép khách hàng tương tác với sản phẩm theo những cách mà trước đây không làm được. Về bản chất chat là một nền tảng giao tiếp (communication platform): bạn có thể nói chuyện với agent để nó làm các task, những task linh hoạt không bị bó buộc trong các màn hình UI mà bạn đã dựng sẵn.

Citations cũng tuyệt vời. Chúng neo câu trả lời vào sự thật (ground the answers in truth). Ngoài việc cho phép user kiểm tra output, citations còn phục vụ một mục đích khác: chúng giúp chính agent chính xác hơn, vì giờ agent bị buộc phải đưa ra nguồn tham chiếu cho câu trả lời của mình. Agent làm tốt hơn hẳn khi phải có citations, tức là về cơ bản chúng giảm hallucination.

4. Vấn đề: chat thì đồng bộ, citations đẩy việc kiểm tra về lại user

Nhưng có một vấn đề cốt lõi ở đây. Chat là đồng bộ (synchronous). Thử nghĩ mà xem, ngay cả khi bạn đang code, giả sử bạn đang dùng Claude Code. Ngay khi bạn gõ xong request, bạn ngồi chờ agent trả lời. Một kênh giao tiếp đồng bộ như vậy không cho phép khách hàng rời khỏi nền tảng để đi làm việc khác của họ.

Tương tự, citations cũng đẩy gánh nặng kiểm tra (verification burden) ngược trở lại cho khách hàng. Hãy hình dung việc phải đi xem lại công việc của agent, từng mục một, để chắc rằng mọi thứ đều đúng. Đặc biệt trong các ngành dọc như y tế, pháp lý và thuế, điều này trở nên cực kỳ quan trọng, vì nó cộng thêm việc cho user. Và khách hàng thường phàn nàn rằng lời hứa "agent làm việc cho tôi trong lúc tôi ngủ" thật ra không được giữ.

5. Ba tầng abstraction qua ví dụ ngân hàng

Trước khi đi sâu, Atul muốn kể nhanh lịch sử tiến hoá của sản phẩm. Theo anh có ba tầng abstraction. Để cho dễ hình dung, hãy tưởng tượng một ngân hàng.

Tầng một: hiện diện vật lý. Ngân hàng ngày trước có chi nhánh thật. Bạn đến chi nhánh, rút tiền bằng cách nói chuyện với một nhân viên ngân hàng. Điểm mấu chốt là người làm task là nhân viên của công ty. Bạn với tư cách user bước vào, giao task cho một nhân viên, họ làm task đó cho bạn, rồi quay lại với kết quả, dù là rút tiền hay xem số dư còn bao nhiêu. Điều này có nghĩa là nút thắt cổ chai (bottleneck) để tạo ra giá trị là số nhân viên mà công ty có.

Tầng hai: chuyển đổi số (digital transformation). Theo thời gian, kỷ nguyên chuyển đổi số tới, ngân hàng lên online. Giờ user có thể mở app di động hoặc cổng online để tự thực hiện giao dịch, tự xem số dư. Điều này rất tốt, vì bottleneck dịch chuyển từ số nhân viên của công ty sang số user của công ty. Càng nhiều user nghĩa là càng tạo ra nhiều giá trị.

Tầng ba: agentic delegation. Atul cho rằng chúng ta đã chạm tới một tầng chuyển đổi nữa, gọi là agentic delegation, tức giao việc cho agent. User không còn vào sản phẩm của bạn để dùng sản phẩm nữa. Anh nghĩ họ đến để giao ngày càng nhiều việc cho AI agent làm. Nếu một user vào sản phẩm và bắt đầu giao việc, việc kéo dài (long-running work), thì điều xảy ra là ngay cả bottleneck "số user" cũng biến mất. Lượng giá trị bạn tạo ra không còn bằng số lần user ghé vào nền tảng của bạn, vì agent có thể làm việc trong lúc user đã đi ngủ, đã giao task rồi rời đi. Bottleneck đã dịch chuyển, nghĩa là bạn có thể tạo ra cho khách hàng nhiều giá trị hơn bao giờ hết.

6. Sản phẩm là băng chuyền, user là người giám sát

Để dễ hình dung hơn, Atul đề nghị nghĩ về sản phẩm agentic của bạn như một băng chuyền (conveyor belt), còn user là người giám sát (supervisor) của băng chuyền đó.

Hãy nghĩ thế này. Trên một băng chuyền truyền thống, thường có nhiều task đang diễn ra cùng lúc. Có những công nhân làm việc cho bạn, và có một người giám sát giao task và theo dõi mọi thứ đang chạy ra sao. Tương tự như vậy, giờ đây AI agent là công nhân trên băng chuyền đó, còn bản thân băng chuyền và toàn bộ hạ tầng xung quanh nó là sản phẩm của bạn.

Vậy user, tức người giám sát, có thể vào sản phẩm và bắt đầu giao task cho các agent. Cách nhìn này cho bạn một ý niệm về những công cụ bạn cần xây trong sản phẩm để biến điều đó thành hiện thực: sao cho agent làm được việc, và người giám sát, tức user, khá tự tin rằng công việc đang thật sự diễn ra.

7. Design for delegation, not participation: bốn thành phần

Vậy làm sao để xây băng chuyền này? Atul gợi ý một cách nghĩ: khi bạn đang xây một tính năng sản phẩm, hãy hình dung nếu user muốn giao một task thay vì tự mình làm task đó trên nền tảng của bạn, thì giao diện đó sẽ trông như thế nào? Về bản chất, hãy thiết kế cho việc giao việc, không phải cho việc tham gia: design for delegation, not participation.

Để cụ thể hơn, Atul nói có bốn mảnh then chốt khi xây một sản phẩm agentic, bốn tính năng hay thành phần bạn cần có để chiếc băng chuyền mà chúng ta đang hình dung chạy được.

Thứ nhất, cũng là thứ dễ nhất: bạn cần tìm ra task để giao. Những task chạy trên băng chuyền phải là task giao được (delegatable), và có thể tạo ra giá trị cho user. Thứ hai, bạn cần cho user khả năng dạy agent, tức là người giám sát phải có thể vào và dạy công việc cần được làm như thế nào. Và cuối cùng, chẳng có ý nghĩa gì khi có một băng chuyền mà bạn không thể tự theo dõi công việc trên đó (anh bật cười khi nói câu này), và tất nhiên là phải can thiệp được khi có gì đó sai. Trong lời nói, Atul gộp theo dõi và can thiệp vào ý "cuối cùng"; trên slide chúng được tách thành hai thành phần riêng, Monitor và Intervene, nên tổng cộng là bốn.

8. Delegate: tìm việc mất vài giờ và dựng background agent

Bắt đầu với delegation. Giao việc nghĩa là đến và trao task cho một người khác. Hãy nghĩ về user của bạn vào nền tảng và giao, hay chuyển giao (hand off), một task cho AI agent.

Khi xây mảnh này, bạn, với tư cách developer hay product engineer, phải tìm ra những task mà user của bạn làm và tốn hơn vài giờ. Trong trường hợp ngành thuế, đội của Atul đã xác định ba task khác nhau trong một quy trình làm thuế (tax workflow) mà mỗi task tốn của user hơn một giờ để thực hiện. Trong lời nói anh dùng mốc "hơn một giờ", còn trên slide thì ghi rõ từng mốc: hơn 2 giờ, hơn 2 giờ và hơn 4 giờ. Tương tự như vậy, trong ngành của bạn, bạn có thể tìm ra đâu là những task đó.

Điều quan trọng là những task này phải lặp lại được (repeatable), hoặc gần như lặp lại được, nhưng được áp dụng khác nhau cho từng trường hợp sử dụng của mỗi user. Và chính những task này là thứ bạn dùng để xây cái gọi là long-running background agent, agent chạy nền trong thời gian dài. Đây là nơi giá trị cốt lõi nằm, vì bạn đang gỡ hàng giờ công việc ra khỏi tay user.

9. Teach: skills lấp 20% cuối cùng

Tiếp theo là dạy agent. Trong bất kỳ ngành nào, nhất là bất kỳ ngành chuyên môn nào, mỗi user đều có sở thích riêng và cách làm task riêng của mình. Atul lấy ví dụ coding. Mỗi công ty hay mỗi nhóm developer đều có cách riêng để xử lý best practices, có conventions và thói quen làm việc riêng mà họ tuân theo.

Vậy nếu bạn tạo ra một background agent, chẳng hạn một agent làm trọn từ đầu đến cuối (end-to-end) task tạo ra một sản phẩm trong bối cảnh coding, nó chắc chắn sẽ tạo ra output. Nó sẽ đưa bạn đi được phần lớn quãng đường, khoảng tám mươi đến chín mươi phần trăm. Nhưng hãy nghĩ thế này: như vậy vẫn chưa giải quyết được vấn đề của user. Với tư cách user, bạn muốn agent làm việc theo đúng cách mà bạn làm việc.

Đây là lúc skills xuất hiện. Skills đã tồn tại trong thế giới phát triển agentic ngày nay (ví dụ Agent Skills trong Claude Code), nên chúng ta cần đảm bảo sản phẩm của mình cũng có skills để nắm bắt cách làm việc, để bạn có thể dạy agent của mình cách user của bạn làm việc. Đây chính là hai mươi phần trăm cuối cùng của công việc mà bạn cần lo. Đây là nơi giá trị thật sự nằm: những điểm "khác người" (quirks) của công việc mà bạn đang nắm bắt được.

Trong trường hợp của Filed, ở mảng thuế, họ nắm bắt tất cả những skills này một cách tự động. Bạn không cần có một giao diện hoàn toàn riêng nơi user phải vào để tạo skill. Cách đó sẽ không hiệu quả. Trong nhiều trường hợp, bạn cần nhìn vào cách sản phẩm được sử dụng (product usage) và tự tìm ra xem có thể tạo một skill cho trường hợp sử dụng cụ thể đó hay không. Filed làm việc này tự động. Một ví dụ điển hình mà có thể bạn đã dùng là sản phẩm Wispr Flow. Họ cũng có skills tự động: bạn dùng, và sản phẩm cứ tiếp tục học khi bạn dùng nó.

10. Monitor: nơi niềm tin được giữ

Giờ đến monitor. Theo dõi là một phần then chốt. Vì giờ agent chạy trong thời gian dài, sẽ có nhiều task đang chạy song song, và user cần nắm được điều gì đang xảy ra trong thế giới đó (anh lại bật cười).

Ví dụ đơn giản thứ nhất là một danh sách task (task list) để theo dõi việc xử lý của từng task đang tới đâu. Ví dụ thứ hai là xây trace ngay trong sản phẩm, tức là truy vết agent đã làm công việc của nó như thế nào. Vì đây là những task kéo dài, sẽ có nhiều mảnh đang chuyển động, nên bạn cần truy ngược lại được. Ở Filed, họ truy ngược từng giá trị mà AI agent tạo ra, theo một định dạng mà user có thể dễ dàng nhìn thấy.

Đây là nơi niềm tin được xây dựng, và cũng là nơi sự minh bạch (visibility) được xây dựng, nên việc xây phần này cho đúng là cực kỳ quan trọng. Theo Atul, đây cũng là nơi phần lớn những lời phàn nàn có thể được giải quyết, nếu bạn làm nó đúng.

11. Intervene: cầm lại tay lái, không bỏ xe

Và cuối cùng là control, quyền kiểm soát. Khi có việc cần đến phán đoán (judgment), hoặc khi có gì đó trục trặc, nền tảng của bạn phải tạo được sự tự tin rằng user có thể giành lại quyền kiểm soát. Điều này cực kỳ quan trọng, vì sản phẩm tầng ba, tức sản phẩm băng chuyền mà chúng ta đang xây, sẽ cho phép khách hàng lên lịch (schedule) rất nhiều task. Nhưng nếu họ không tự tin rằng khi có gì đó sai họ có thể lấy lại quyền kiểm soát, thì user sẽ mất niềm tin hoàn toàn.

Cảm giác phải là user đang cầm lại tay lái, chứ không phải bỏ chiếc xe lại rồi đi tạo một chiếc xe mới. Lý tưởng nhất, mọi việc diễn ra như sau: bạn dừng băng chuyền, sửa vấn đề, rồi khởi động lại.

Ở Filed, họ làm việc này khá đơn giản: ở bất kỳ chỗ nào agent đang định đưa ra một giả định (assumption), hệ thống dừng lại. Rồi user vào, giống hệt như trong Slack hay bất kỳ nền tảng chat nào khác: họ có thể tag agent và trả lời cách xử lý chỗ xung đột cụ thể đó.

12. Bonus: manual override và plan cho hành động không đảo ngược được

Atul thêm vài điểm cộng (bonus points). Giống như chi nhánh ngân hàng vật lý không biến mất khi mobile banking ra đời, tức là khi tầng hai xuất hiện, anh không nghĩ rằng khi tầng agentic tới, vốn là một abstraction nằm trên hai tầng trước, thì mọi mobile app và những thứ tương tự sẽ biến mất. Điểm mấu chốt là user chỉ đến và giao việc khi họ tin rằng họ luôn có thể lấy lại quyền kiểm soát.

Vậy bước đầu tiên là cho user sự tự tin rằng họ có thể giành lại quyền kiểm soát khi có gì đó sai. Nghĩa là bạn cũng cần xây các tính năng tầng hai vào sản phẩm của mình, tức những màn hình để user tự tay làm. Đó là điểm mấu chốt để xây niềm tin.

Điều thứ hai: có những hành động thường là không đảo ngược được (irreversible) và nguy hiểm. Trong những trường hợp đó, bạn cần trình ra một plan. Hãy nghĩ về giao dịch ngân hàng chẳng hạn: trước khi thực hiện một giao dịch, phải có plan sẵn, nếu một khoản tiền nào đó sắp chuyển đi nơi khác. Tương tự, ở Filed, trước khi nhập dữ liệu (data entry) vào một phần mềm thuế mà việc đó có thể xoá dữ liệu sẵn có của khách hàng, họ tạo một plan để khách hàng duyệt trước khi đi tiếp.

Atul gọi đây là những trụ cột then chốt giúp khách hàng cảm thấy mình đang nắm quyền kiểm soát, và cảm thấy rằng nếu có gì đó sai, họ có thể lấy lại quyền kiểm soát vào bất kỳ thời điểm nào.

13. Đổi cách đo: từ WAU sang WAS

Và cuối cùng, vì giờ chúng ta đang xây sản phẩm theo một cách hoàn toàn khác, không còn xây để user vào và dùng sản phẩm, mà xây để user vào và giao việc, nên điều quan trọng là phải đổi cách đo giá trị.

Thước đo phổ biến nhất mà các sản phẩm dùng hôm nay là weekly active users (WAU), số user hoạt động mỗi tuần. Nó rất hợp trong thời kỳ mà người ta vào nền tảng và tự làm việc ở đó. Nhưng nó không thật sự phản ánh đúng khi chuyển sang agentic delegation. Nên chúng ta phải đổi cách đo.

Atul cho rằng thước đo phù hợp ở đây là weekly active sessions (WAS). Anh coi mỗi session là một task được hoàn thành bởi con người hoặc bởi agent, kể cả khi user không có mặt trên nền tảng của bạn.

Vậy mục tiêu thật sự của bạn nên là weekly active users đi xuống trong khi weekly active sessions đi lên. Lý do: bạn muốn user tin nền tảng của bạn đủ để giao task cho nó càng nhiều càng tốt, và những task đó được thực thi mà không cần con người giúp, càng nhiều càng tốt. Nên số session phải tăng. Weekly active sessions nên tăng, trong khi số weekly active users trên nền tảng lý tưởng nhất là giảm. Tất nhiên không phải về không, nhưng nên giảm.

14. Ba điều cần nhớ

Atul tóm lại ba điều cần mang về.

Thứ nhất, design for delegation, not participation. Thiết kế sản phẩm sao cho user vào để giao việc, không phải để tự làm.

Thứ hai, để làm được điều đó, hãy nghĩ về sản phẩm của bạn như một băng chuyền. User giờ là người giám sát (supervisor), không phải người vận hành (operator). Họ đến để giao việc và theo dõi, phát hiện xem có vấn đề gì không, rồi hành động.

Và cuối cùng, hãy đổi cách đo công việc được hoàn thành, chứ không đo thời gian user ở trên nền tảng: weekly active sessions thay vì weekly active users.

Nếu giữ ba điều này trong đầu, theo Atul, bạn sẽ có thể xây được một sản phẩm vertical AI rất thành công. Anh cảm ơn mọi người đã dành thời gian, và chúc mọi người may mắn ngoài kia.