Cách tránh cái chết trên con đường gạch vàng - lớp ứng dụng vẫn chưa chết

• Mối lo rằng lớp ứng dụng AI sẽ bị các phòng lab lớn như OpenAI và Anthropic nuốt chửng đang lan rộng trong giới sáng lập, nhưng lớp ứng dụng không phải là một cơ hội đơn lẻ mà là một cấu trúc chia thành "Con đường gạch vàng (Yellow Brick Road)" và "Phần còn lại của Oz (Rest of Oz)"
• Con đường gạch vàng là vùng ngang nơi chất lượng được cải thiện chỉ bằng việc nâng cao hiệu năng của chính mô hình, như sinh mã, viết lách, tạo ảnh — con đường mà các lab đang đổ nguồn lực khổng lồ vào
• Phần còn lại của Oz là vùng mà scaffolding phía trên mô hình quyết định độ tin cậy và tính tuân thủ, như các quy trình theo chiều dọc, nhiều bước, nhiều lớp phê duyệt; đây là nơi startup có cơ hội sở hữu khách hàng
• Chính việc OpenAI và Anthropic công bố các liên doanh forward-deployed quy mô lớn để tùy biến cho doanh nghiệp đã cho thấy không thể giải quyết mọi vấn đề chỉ bằng một AI coworker phổ quát
• Phần mềm doanh nghiệp thế hệ tiếp theo sẽ được tạo ra "ngoài con đường" (off the road), và tuyến phòng thủ cốt lõi là: mô hình có thể thay thế được, nhưng system of work thì không

---

Câu hỏi cốt lõi và giả định nền tảng

• Câu hỏi mà tác giả liên tục nhận được từ nhà sáng lập và ứng viên là: "Liệu OpenAI và Anthropic có giết chết mọi thứ không, còn gì để xây trong lớp ứng dụng AI nữa không"
• Một số người kết luận rằng nơi duy nhất tránh được vị thế tầng lớp thấp vĩnh viễn là bên trong các lab lớn hoặc ở biên giới công nghệ như robotics và hard-tech
• Tác giả, từ góc nhìn của một người theo chủ nghĩa tối đa AI, đánh giá rằng họ "đúng một nửa" — quả thực các lab sẽ hấp thụ phần lớn bề mặt ứng dụng
• Tuy vậy, điểm then chốt là lớp ứng dụng không phải một cơ hội đơn nhất — cách đặt vấn đề đúng là bạn đang ở trên con đường gạch vàng hay ở nơi khác của Oz

The Yellow Brick Road — con đường các lab đang đi

• Mẫu hình là gắn các off-the-shelf connector như G Drive, Slack, Salesforce, Notion, GitHub vào mô hình hiệu năng cao, rồi đặt thêm một lớp orchestration tác tử lên trên
• Lý do mẫu hình này nguy hiểm là vì các lab đã làm đúng việc đó với Cowork và Codex
  • Sở hữu mô hình → biên lợi nhuận tốt hơn, quyền kiểm soát cao hơn, và quyền định giá với phần downstream
  • Nắm trong tay quyền chọn kiến trúc được định nghĩa để sản phẩm chạy tốt — cho đến nay họ đã cố ý chọn mẫu "model + tool calls", và điều này khớp chính xác với các tác vụ ngang cấp thấp trên con đường
• Ngay cả khi startup vượt Codex hay Claude Code về hiệu năng, các lab vẫn nắm mạng lưới phân phối khổng lồ và hào quang thương hiệu lớn nhất trong AI
• Công ty ứng dụng AI nào lặp lại playbook này với cùng tập connector, không có sub-agent hay composition, cũng không có phân phối, thì đang đi trên một "con đường không dẫn đến đâu"

The Rest of Oz — cơ hội cho startup

• Đây là vùng xây dựng trải nghiệm tác tử nơi mô hình được đan kết qua mạng lưới phức tạp của công cụ, tự động hóa và tích hợp, và phần lớn tự nhiên sẽ đi đến chiều dọc
• Có thể tập trung vào những công việc nhiều bước, nhiều bên tham gia mà nền tảng ngang không với tới
  • Thu thập ngữ cảnh trên toàn hệ thống, rồi điều phối tới nhiều người cần phê duyệt theo từng bước
  • Liên kết với một hay nhiều hệ thống legacy, cần kết quả mang tính quyết định và không cho phép mơ hồ
  • Thường gắn trực tiếp với kết quả kinh doanh có giá trị
• Các lab cũng nhận ra giá trị của nhóm bài toán này, đó là lý do họ trực tiếp vận hành các outsourced configuration shop, và cũng là lý do tồn tại lớp doanh nghiệp đi lên thị trường của mảng reinforcement learning

Vì sao phần còn lại của Oz sẽ không bị phù thủy nuốt chửng

• Data and learning flywheels (bánh đà dữ liệu và học hỏi)

  • Chuẩn mực ngành ngầm, tiêu chuẩn không được ghi chép, và tri thức bộ lạc (tribal knowledge) nằm trong đầu người làm việc tại hiện trường không tồn tại trên web công khai
  • Hai bánh đà hoạt động chồng lên nhau
    • across-customer: các mẫu hình tích lũy được khi nhìn thấy nhiều biến thể của cùng một vấn đề ở nhiều khách hàng
    • within-customer: lý do đằng sau một quyết định cụ thể, các ngoại lệ ngầm hiểu, và kinh nghiệm đặc thù của chính công ty đó
  • Một công ty đã xử lý 100 bản redline pháp lý, 1.000 hồ sơ underwriting bảo hiểm, hay 10.000 chiến dịch SDR sẽ nội tại hóa hình dạng của bài toán theo cách mà người mới vào thị trường không thể sao chép chỉ bằng một tác tử mới khởi chạy
  • Lý do cốt lõi khiến tác tử ngang không thể tạo cùng hạ tầng học hỏi nằm ở UX — chỉ người chơi theo chiều dọc mới có thể thiết kế chính xác bề mặt quy trình làm việc
  • Bộ eval, đầu ra đã gán nhãn, và hệ phân loại edge case tích lũy thành bánh đà dữ liệu chuyên biệt theo chiều dọc, trở thành nhiên liệu cho fine-tuning

• Managing model variability and complexity (quản lý sự đa dạng và phức tạp của mô hình)

  • Các lab đã nội bộ thực hiện routing và ensemble mô hình theo từng request, nhưng không thể làm routing giữa các vendor, đánh giá mô hình của đối thủ, hay triển khai mô hình fine-tuned mã nguồn mở vào những ngách hẹp
  • Công ty thuộc Rest of Oz chọn mô hình tốt nhất cho từng subtask từ toàn bộ thị trường mô hình, chứ không chỉ các thứ được công ty mẹ là lab tung ra
  • Mỗi lần nâng cấp, họ gánh phần việc "không ai muốn làm": chạy lại eval, hiệu chỉnh lại prompt cho edge case của khách hàng, và rollout mà không làm vỡ production
  • Lab chỉ bán mô hình tiếp theo và bảo "hãy migrate đi"; công ty Rest of Oz sẽ hấp thụ việc migration, mang cho khách hàng trí tuệ tốt nhất trên toàn thị trường cùng tính liên tục qua các đợt nâng cấp

• Cost optimization (tối ưu chi phí)

  • Chạy mọi query bằng Opus 4.7 là con đường ngắn nhất dẫn tới lợi nhuận gộp âm
  • Các công ty Rest of Oz tốt nhất sẽ route mô hình theo tầng
    • Tác vụ khó nhất dùng mô hình frontier
    • Phần lớn tác vụ dùng mid-tier
    • Những phần đủ điều kiện dùng mô hình nhỏ tùy biến hoặc fine-tuned
  • Một số công ty còn tự làm post-training, tối ưu cho lát cắt hẹp mà khách hàng thực sự quan tâm và phục vụ với chi phí chỉ bằng một phần so với API frontier
  • Nếu lab thiết lập mức giá sàn là "mức thông minh tối thiểu với X đô la", thì công ty Rest of Oz bán điều ngược lại: chi phí đô la thấp nhất cho đúng mức thông minh mà workflow thực sự cần

• Governance (quản trị)

  • Có giá trị rất lớn trong việc trở thành control plane cho cách khách hàng vận hành AI trong một chiều dọc cụ thể — nơi hội tụ quyền hạn, kiểm toán, những gì tác tử được phép làm và những gì nó thực sự đã làm
  • Control plane được cấu thành từ guardrail theo từng use case, khác nhau hoàn toàn theo ngành và theo chức năng công việc
  • Vì sở hữu end-to-end công cụ, workflow và dữ liệu, họ có thể cung cấp kết quả mang tính quyết định mà công cụ ngang rất khó làm được
  • Họ là chủ thể hấp thụ độ phức tạp pháp lý thay vì đẩy nó cho người mua cuối
    • Pháp lý: FRCP và quy tắc đạo đức luật sư
    • Y tế: HIPAA
    • Tài chính: SEC và FINRA
    • Bảo hiểm: quy định bảo hiểm theo từng bang
  • CIO muốn có một đối tác chịu trách nhiệm theo hợp đồng về tính tuân thủ của các tác tử mà họ triển khai

• Kết luận chung: tập trung

  • Dù là một chiều dọc như bảo hiểm, pháp lý, kế toán, hay một chức năng được thực hiện rất sâu như bán hàng, hỗ trợ khách hàng, tài chính, đều cần một đội ngũ tận hiến cho workflow, edge case và quy định của một tập khách hàng duy nhất
  • Các lab không thể làm việc này vì cấu trúc của họ buộc phải hiện diện ở mọi nơi cho mọi người — chỉ có thể ở khắp nơi hoặc làm thật tốt một việc

Ví dụ Sales — mẹo thực chiến từ Prabhav Jain, CEO của 11x

• Focus on outcomes (tập trung vào kết quả)

  • Con đường chiến thuật để xây công ty có khả năng chống chịu trước các lab là bắt đầu từ một kết quả cụ thể mà khách hàng thật sự quan tâm — với 11x là tạo pipeline
  • Phân rã từng hoạt động thành task → phân biệt cái nào mang tính agentic và cái nào không, cái nào đòi hỏi hiểu biết domain tinh vi và cái nào không
  • Trong các workflow nhiều bước, đầu vào lộn xộn, trạng thái khó diễn giải và có ràng buộc đời thực, mô hình tốt hơn thôi là chưa đủ; cần kỹ thuật phần mềm truyền thống, và trên bề mặt này các lab không có lợi thế
  • Ví dụ về các task mà 11x xử lý
    • Prospecting lead dựa trên tín hiệu tùy biến, lead enrichment, nghiên cứu account chuyên sâu
    • Trình lấy ngữ cảnh CRM, bộ soạn thông điệp theo từng kênh, tác tử xác thực điều kiện lead, hệ thống đảm bảo khả năng gửi email
  • Công việc của công ty ứng dụng là bơm tri thức domain không có trong dữ liệu huấn luyện chung vào mô hình tại đúng thời điểm trong workflow, và điều đó tích lũy theo thời gian
  • Kỹ năng liên tục lỗi thời theo tiến hóa của doanh nghiệp, nên chính năng lực tiến hóa workflow và ngữ cảnh mới là lợi thế cạnh tranh
    • Ví dụ: từ khi email do AI viết xuất hiện, cảm nhận của người dùng đã thay đổi vài tháng một lần, nên tác tử phải liên tục thích nghi theo động lực thị trường
    • Trong vài tháng gần đây, positive reply rate tăng gấp 4 lần, tạo ra pipeline trị giá hàng trăm triệu đô la cho khách hàng

• Work on problems where complexity is high (làm các bài toán có độ phức tạp cao)

  • Giá trị kinh doanh thực sự được mở khóa ở bài toán phức tạp; nếu không bạn sẽ chỉ là một thin wrapper
  • Ví dụ GTM: quy tắc đơn giản kiểu "không được liên hệ tới contact tại công ty đã là khách hàng" thực tế lại cực kỳ phức tạp
    • CRM có thể có ánh xạ domain, doanh nghiệp có hàng chục công ty con, đôi khi chỉ ghi domain công ty mẹ, và trường đối sánh stale trong Salesforce có thể khiến một cold pitch gửi đến CRO của khách hàng hiện tại
  • Dữ liệu ngoài đời thì lộn xộn và cả con người lẫn mô hình đều không thể giải quyết bằng phép màu — cần tác tử chuyên dụng theo mục đích được kỹ thuật hóa cho đúng hình dạng cụ thể của vấn đề
  • Theo dữ liệu của 11x, chất lượng và độ tươi của dữ liệu nội bộ họ cao hơn phía khách hàng, nên mặc định là neo vào dữ liệu của chính mình

• Guardrails — không phải phần ngăn điều tệ xảy ra mà là phần cốt lõi khiến khách hàng trả tiền

  • Guardrail đang bị đánh giá thấp một cách nghiêm trọng; ngay cả trong cùng một sản phẩm cũng cần bộ riêng cho từng use case
  • Nhu cầu bảo đảm của khách hàng tiềm năng trong dịch vụ tài chính bị quản lý và khách hàng SaaS mid-market là khác nhau; khác biệt đó lan xuống cả cách tác tử viết nội dung, liên hệ với ai, truy cập dữ liệu nào, nói gì trong cuộc gọi, và ghi log quyết định ra sao
  • Hệ thống one-size-fits-all sẽ sụp đổ; cần thiết kế theo từng use case, cấu hình theo từng khách hàng, và kiểm toán liên tục
  • Vì thế họ vận hành FDE (Forward Deployed Engineer) và chiến lược gia triển khai kỹ thuật để tinh chỉnh theo nhu cầu khách hàng
  • Ví dụ tại một tổ chức F1000
    • Thực hiện gọi thoại outbound dựa trên đồng thuận tới số lượng lớn khách hàng SMB
    • Ở vòng lặp ban đầu, tỷ lệ nhấc máy thấp → nhanh chóng học được cách thu hút chủ doanh nghiệp SMB trong 10 giây đầu cuộc gọi
    • Chủ doanh nghiệp SMB hành xử khác với buyer B2B lớn hay người tiêu dùng; hiện tại ở phân khúc này hệ thống tạo ra nhiều cơ hội bán hàng trong một ngày hơn cả đội sales của khách hàng tạo trong một tháng

Ví dụ Insurance — Aman Gour, CEO của FurtherAI

• Một giả định mà ông liên tục bắt gặp khi triển khai AI vào vận hành bảo hiểm — "mô hình là trí tuệ còn workflow chỉ là scaffolding" — càng làm việc với các carrier ông càng tin rằng điều đó ngược lại
• Trong bảo hiểm, phần lớn trí tuệ nằm ngay trong chính workflow
  • Hai carrier có thể cùng đi theo một lộ trình giống nhau (submission → review → quote → bind), nhưng khác biệt nằm ở mọi thứ bên trong
    • Rủi ro nào bị escalation
    • Tín hiệu tổn thất nào là quan trọng
    • Khi quy tắc appetite xung đột thì bên nào thắng
    • Thời điểm cần con người phê duyệt, lúc gọi dữ liệu ngoài, và cách tài liệu hóa quyết định cuối cùng
  • Logic đó không nằm gọn trong một rule engine sạch sẽ mà phân tán trong SOP, review của quản lý, triết lý underwriting, appetite riêng của carrier, và nhiều năm kinh nghiệm vận hành; phần lớn thậm chí không được ghi lại dưới dạng mô hình có thể đọc
• Kết luận luôn là agentic workflows, chứ không phải tác tử thuần túy suy luận lại từ đầu mỗi lần, cũng không phải workflow cứng nhắc sẽ vỡ khi thực tế trở nên bừa bộn
  • Workflow → tính lặp lại, khả năng kiểm toán, kiểm soát chi phí
  • Tác tử → xử lý biến động, phục hồi khi happy path bị phá vỡ
  • Human-in-the-loop → cho các quyết định mà trách nhiệm giải trình là quan trọng
• Ở Day 1 là tự động hóa thủ công; theo thời gian mọi escalation trở thành tín hiệu, mọi ngoại lệ trở thành phản hồi, và mọi chỉnh sửa của con người đều bộc lộ điểm thiếu trong runbook, khiến workflow tiến hóa thành operating memory của carrier
• Các lab sẽ tiếp tục tung ra mô hình tốt hơn và tác tử tổng quát tốt hơn, nhưng việc học được tài khoản nào bị escalation, rủi ro nào bị từ chối, hay vì sao underwriter đảo ngược hướng dẫn appetite rồi vẫn đúng là điều không thể nếu không ở đủ lâu trong production của carrier
• "Workflow phát hành ở Day 1 không phải là hào; chính vòng lặp được tạo ra bởi việc sử dụng trong production theo thời gian mới là hào"

3 bài kiểm tra để biết bạn có thuộc phần còn lại của Oz hay không

• The tools-and-steps test (bài kiểm tra công cụ và bước)

  • Công việc đi qua bao nhiêu bước và các công cụ hỗ trợ phức tạp đến mức nào
  • So sánh
    • Tìm kiếm AI ngang (quét Google Drive): 1 bước, 1 công cụ, kết quả dễ chấp nhận — sai thì hỏi lại
    • Redline pháp lý (đối chiếu với tiền lệ của hãng trong 3 năm): hàng chục bước, nhiều công cụ, đầu ra phải qua review của partner và thậm chí có thể bị tranh tụng tại tòa
  • Cả hai đều là "hình ảnh tác tử đang làm việc", nhưng chỉ một bên đòi hỏi phần mềm sâu do một đội ngũ tập trung xây nhiều năm

• The system test (bài kiểm tra hệ thống)

  • Bạn có đang xây một hệ thống mà khách hàng cho công việc của mình đi qua, hay chỉ là một công cụ nằm trên hệ thống đã có
  • Hệ thống sở hữu end-to-end việc thu thập dữ liệu, quản trị, và ghi nhận thực thi; đó là thứ khách hàng chỉ vào khi nói "đây là nơi công việc thực sự diễn ra"
  • Công cụ chỉ thêm trí tuệ vào workflow mà khách hàng đã vận hành sẵn; vẫn có doanh thu, nhưng đó là vùng lab có thể lấy đi
  • ACV cao thường là tín hiệu của hệ thống nhưng không phải bảo chứng — tiêu chí phân biệt là nếu lab tung ra sản phẩm cạnh tranh trực tiếp, khách hàng có còn cần công cụ của bạn không

• The hedge fund / P&L test (bài kiểm tra quỹ phòng hộ / P&L)

  • Thành quả của lab được đo bằng benchmark; thành quả của Rest of Oz được đo bằng P&L của khách hàng
  • Khách hàng không quan tâm điểm SWE-Bench hay MMLU — họ nhìn xem tác tử có chốt được deal không, có redline hợp đồng đúng không, có bind đúng policy không
  • Khách hàng ám ảnh với kết quả chuyên biệt theo workflow → Rest of Oz; khách hàng trả tiền cho năng lực tổng quát → một seat Claude hay Codex là đủ
  • Các doanh nghiệp tác tử tốt nhất phải cạnh tranh như quỹ phòng hộ: bằng alpha được đo bằng P&L của khách hàng

Cả hai phía đều có thể chiến thắng

• Ngay trên con đường gạch vàng cũng sẽ xuất hiện những người thắng khổng lồ — các lab sở hữu mô hình và cũng sở hữu phân phối cho các công cụ ngang do chính họ thiết kế
• Điều kiện chiến thắng của Rest of Oz là sở hữu system of work — bề mặt nơi công việc của công ty thực sự được thực thi và dữ liệu được ghi nhận
  • Sở hữu việc ghi nhận dữ liệu, hệ thống hành động của workflow, và quản trị
  • Workflow càng phức tạp trong một chiều dọc trưởng thành, nó càng cô đặc thành một trải nghiệm cốt lõi mà khách hàng phụ thuộc
  • Khi các thế hệ mô hình cũ mới được tung ra, doanh nghiệp sẽ trở thành lớp tích hợp và phân phối chúng
  • Mô hình ở phía dưới là fungible, nhưng system of work thì không
• Phần mềm doanh nghiệp thế hệ tiếp theo sẽ được xây dựng "ngoài con đường"