Trong bài (1), Py từng đề cập đến quan điểm cá nhân rằng “AI diffusion” hiện đang mắc kẹt ở giai đoạn chuyển giao từ usage (sử dụng) sang workflow (quy trình). Điều này có nghĩa là dù người dùng đã thực sự tiếp cận và sử dụng AI thường xuyên, quy trình làm việc của họ về cơ bản vẫn không thay đổi, chỉ là mỗi thao tác được thực hiện nhanh hơn đôi chút. Đó là góc nhìn từ bên ngoài. Trong bài viết này, Py muốn đổi sang lăng kính của những người trực tiếp xây dựng quy trình cho người khác, cụ thể là các công ty làm product. Bởi lẽ, nếu quá trình lan tỏa AI thực sự đang chững lại, một phần nguyên nhân có lẽ xuất phát từ chính những sản phẩm tương tự như dự án Py đang làm.

(Phần tổng hợp nghiên cứu trong bài được thực hiện với sự hỗ trợ của AI.)

Case study: từ usage sang workflow

Vào năm 2024, Hostinger ra mắt Kodee, một trợ lý AI tích hợp trong trang admin nhằm giúp người dùng tìm kiếm hướng dẫn và giải pháp cho các vấn đề thường gặp. Thành thực mà nói, bước đi này chưa có gì quá đột phá. Việc gắn chatbot vào sản phẩm hay tích hợp AI vào thanh tìm kiếm để tra cứu tài liệu giờ đây gần như ai cũng làm. Đó chính là tầng usage. Dù hữu ích và đáng làm, nó vẫn chưa đủ sức thay đổi cách thức công việc được thực thi. Người dùng vẫn phải tự mình lặn lội qua nhiều tầng tính năng và tự tay thao tác, chỉ khác là họ tìm được hướng dẫn nên có thể làm nhanh hơn.

Sự thay đổi thực sự bắt đầu ở chặng tiếp theo. Đến năm 2025, Kodee không chỉ dừng lại ở việc trả lời câu hỏi mà đã có khả năng thực hiện hơn 350 tác vụ, từ đăng ký tên miền, chuyển hosting từ nhà cung cấp khác, tối ưu tốc độ cho đến xử lý các sản phẩm WooCommerce. Chỉ tính riêng tháng 8/2025, Kodee đã xử lý 750.000 cuộc hội thoại và giải quyết trọn vẹn 75% trường hợp mà không cần sự can thiệp của con người (tăng so với mức 50% hồi đầu năm). Đến tháng 9/2026, thế hệ AI Agent mới của họ đạt mốc xử lý khoảng 1,5 triệu cuộc hội thoại mỗi tháng và tự động giải quyết 91% yêu cầu.

Dù đây là những con số do chính công ty công bố, chúng vẫn phần nào minh chứng cho việc Kodee đã thực sự “làm thay” người dùng thay vì chỉ “hướng dẫn cách làm”. Sự dịch chuyển từ tư duy “đây là cách bạn tự làm” sang “để tôi làm giúp bạn” không đơn thuần là việc bổ sung thêm một tính năng. Đó chính là bước nhảy vọt từ usage sang workflow.

Cũng cần nhìn nhận một thực tế sòng phẳng: phần lớn các công ty hiện nay vẫn dậm chân ở phiên bản tương tự Kodee năm 2024. Họ có chatbot, có AI tích hợp vào tìm kiếm rồi dừng lại. Khi phân loại cách doanh nghiệp ứng dụng AI, OECD cũng chỉ ra xu hướng tương tự. AI thường được đưa vào dưới dạng point solution (giải pháp điểm) để xử lý một vấn đề cụ thể và triển khai độc lập với các chức năng khác, và đây gần như luôn là bước đi đầu tiên.² Khởi đầu như vậy không sai, cái sai là họ chỉ dừng lại ở bước đầu đó.

Key findings

Phần mềm truyền thống thường vận hành theo trình tự: người dùng hiểu hệ thống → tự tìm đến đúng chỗ → bấm nút. Trong khi đó, phần mềm AI-native đảo ngược quy trình này: người dùng nói điều mình cần → hệ thống tự tìm đúng công cụ → trực tiếp thực thi. Điều này có nghĩa là trong các sản phẩm hiện đại, AI đã trở thành yếu tố bắt buộc phải có để trút bỏ gánh nặng phức tạp mà UX trước nay vẫn bắt người dùng tự gánh. Nếu họ vẫn phải vất vả hiểu hệ thống như cũ và chỉ được hưởng lợi ở chỗ bấm ít nút hơn, thì AI lúc này vẫn chỉ là yếu tố “có cũng được”.

Và đã gọi là AI-native, thì ít nhất AI Agent cần được treat như một đối tượng tương tác với sản phẩm. Py tạm mô tả bằng hình dưới đây, cho dễ hình dung vị trí của lớp sản phẩm dành cho AI agent:

Lâu nay, phần mềm thường mở ra hai lớp giao tiếp với bên ngoài: một lớp UI dành cho con người và một lớp API dành cho lập trình viên cùng các hệ thống khác. Phần mềm theo hướng agentic sẽ bổ sung lớp thứ ba hoàn toàn khác biệt. Lớp này bao gồm các công cụ (tools) để agent gọi lệnh, cấu trúc (schema) để agent hiểu dữ liệu, phân quyền để giới hạn phạm vi hoạt động, cùng với các rào chắn (guardrail) và nhật ký kiểm toán (audit trail) để giám sát những gì agent đã làm. Vào cuối năm 2024, Anthropic đã giới thiệu MCP như một chuẩn mở cho quy trình này nhằm tránh việc mỗi bên tự xây dựng phương thức kết nối riêng lẻ.³ Hostinger đã đi đúng con đường đó để đưa Kodee chạm sâu vào tầng server.

Về điểm này, McKinsey từng đưa ra một con số phản ánh rất sát thực tế: có đến 62% tổ chức đang thử nghiệm hoặc chạy pilot AI agent, nhưng không quá 10% ở bất kỳ mảng nghiệp vụ nào khẳng định họ đang thực sự scale (mở rộng quy mô).⁴ McKinsey cũng chỉ ra một nguyên nhân cốt lõi mà người làm sản phẩm nên lưu tâm kỹ. Đó là agent không thể tự bù đắp cho những hệ thống dữ liệu thiếu nhất quán hoặc không có quyền sở hữu rõ ràng. Nói cách khác, những khu vực lâu nay chúng ta thiết kế tạm bợ với tư duy “con người nhìn vào tự hiểu”, thì nay AI agent hoàn toàn không thể tự suy luận thay được.

Thú thực, bản thân Py cũng chưa xây dựng được hệ thống nào đạt chuẩn agent-ready một cách hoàn chỉnh. Dưới góc độ của một người làm sản phẩm, Py tự yêu cầu bản thân gánh trách nhiệm cần quan sát và biết cách đặt câu hỏi để đánh giá xem sản phẩm đã đủ “tốt” cả về khả năng đáp ứng nhu cầu người dùng lẫn tiềm năng mở rộng hay chưa. Chẳng hạn, Py thường phải đưa ra các thách thức cho đội ngũ kỹ thuật: Agent đã có đủ ngữ cảnh để hiểu tình huống chưa? Các hành động trong hệ thống đã được mô tả đủ rõ để gọi lệnh chưa, hay vẫn đang nằm rải rác trong logic của từng màn hình? Cơ chế phân quyền đã được chia đủ nhỏ chưa, hay chỉ đơn thuần là bật và tắt? Tác vụ nào có rủi ro cao bắt buộc phải có người duyệt? Tác vụ nào lỡ sai thì có thể hoàn tác? Và quan trọng nhất, nếu ba tháng sau có người thắc mắc vì sao hệ thống lại xử lý như vậy, chúng ta có truy vết lại nguồn gốc được không?

Cũng phải thừa nhận rằng Py chỉ đang trên hành trình hướng tới việc xây dựng sản phẩm AI-native chứ chưa hẳn đã chạm đến đích. Do đó, những câu hỏi trên đa phần bộc phát từ kinh nghiệm cá nhân và trực giác kỹ thuật (technical intuition) nhiều hơn là từ một framework đã được chứng minh hiệu quả. Biết đâu một ngày “đẹp trời”, khi đã tích lũy đủ góc nhìn, Py sẽ tổng hợp lại thành một bài viết mang tên AI-native product 101 (manifesting…).

Ở đoạn kết của bài này, Py muốn đề cập thêm một góc nhìn khác. Gartner dự báo rằng hơn 40% dự án agentic AI có thể sẽ bị hủy bỏ trước cuối năm 2027 do chi phí đội lên cao nhưng giá trị kinh doanh mang lại không rõ ràng, đồng thời việc kiểm soát rủi ro vẫn chưa tìm được điểm cân bằng hợp lý.⁵

Dự báo này hoàn toàn không mâu thuẫn với những phân tích ở trên. Nó chỉ nhấn mạnh đúng một nguyên tắc ưu tiên cốt lõi: bước chuyển mình từ usage sang workflow chỉ thực sự đáng làm khi AI giúp gỡ bỏ được sự phức tạp cho người dùng. Ngược lại, nếu cố gắng xây dựng cả một lớp hạ tầng đồ sộ cho agent ở những tính năng mà AI chỉ đóng vai trò “có cũng được”, thì dự án đó rất có nguy cơ sẽ rơi vào nhóm 40% thất bại kia.

Tiếp nối mạch suy nghĩ này, một câu hỏi lớn sẽ được đặt ra: khi AI agent đã đảm nhiệm toàn bộ phần thực thi, con người sẽ còn lại phần việc gì? Lời giải đáp cho câu hỏi này hiển nhiên sẽ được Py trình bày chi tiết trong bài (3) của chuỗi chủ đề này.

1. Hostinger — thông cáo báo chí tháng 9/2025, thông cáo ngày 3/9/2026, và bài giới thiệu Kodee.
2. OECD/BCG/INSEAD, The Adoption of Artificial Intelligence in Firms.
3. Anthropic, Introducing the Model Context Protocol.
4. McKinsey, Reimagining tech infrastructure for (and with) agentic AI.
5. Gartner, dự báo hơn 40% dự án agentic AI bị hủy trước cuối 2027 (6/2025).

Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.

Chúc bạn nhiều may mắn và bình an.

Anpy