The Future Is Domain-Specific Agents

1. Justin Schroeder và Standard Agents

Justin vào thẳng chủ đề: anh sẽ nói về domain-specific agent (agent chuyên cho một lĩnh vực hẹp), và vì sao anh thực sự tin rằng loại agent này sẽ đóng một vai trò quan trọng tới mức khó tin trong tương lai của AI, cũng như trong tương lai của cách chúng ta build agent.

Giới thiệu nhanh: anh tên Justin Schroeder, bạn có thể tìm anh trên X. Anh làm ở một công ty nhỏ tên Standard Agents, công ty mà theo lời anh thì "chưa ai nghe tên", vì hiện vẫn đang ở chế độ stealth. Sau talk, nếu bạn quan tâm, cứ liên hệ, anh sẽ kể thêm một chút.

Phần lớn mọi người biết đến anh qua các dự án open source. Có dmux, một multiplexer rất tốt cho mọi coding agent của bạn. Có ArrowJS, một kiểu UI framework, gần giống React nhưng cho kỷ nguyên agentic. Và còn một loạt dự án nữa mà anh không đi vào chi tiết, nhưng nếu bạn tò mò thì có thể xem thử.

2. Từ máy móc sang agent: harness intelligence

Justin cho rằng tất cả chúng ta đều có thể đồng ý một điều: khoảnh khắc lịch sử mà ta đang sống rất giống thời Cách mạng Công nghiệp. Thậm chí có thể nó là một cuộc Cách mạng Công nghiệp được tăng tốc. Có thể nó còn lớn hơn, nhưng chắc chắn không nhỏ hơn. Anh nói có lẽ anh không cần thuyết phục bạn điều đó nếu bạn đang ngồi nghe một trong những talk như thế này. Dù sao thì đó là thời điểm mà chúng ta đang thấy mình ở trong.

Vì thế anh thấy có ích khi quay lại nhìn xem đâu là chất xúc tác chính của Cách mạng Công nghiệp. Rốt cuộc, đó là việc con người học được cách khai thác năng lượng bằng máy móc. Anh nhắc lại câu này hai lần cho rõ: chúng ta đã học cách harness năng lượng bằng máy.

Điều thú vị là trong kỷ nguyên tiếp theo này, về bản chất chúng ta đang học cách harness intelligence bằng agent. Và theo Justin, có thể xem agent giống như cỗ máy của thời trước. Agent là thứ sẽ sử dụng trí tuệ đó, không hẳn là chúng ta (anh bật cười), mà là các agent.

3. Agent là gì, và agent với harness

Có một điều thú vị ở đây. Justin cá rằng nếu anh đứng trong một căn phòng thật với khán giả và hỏi mọi người giơ tay "agent là gì?", rất nhiều người sẽ lập tức nghĩ ra ví dụ, nhưng có lẽ không rút ra ngay được một định nghĩa. Một số người thì có thể. Nhưng thực tế là chúng ta còn chưa thống nhất được agent là gì, dù đã đi khá sâu vào kỷ nguyên agentic. Anh thấy điều đó khá thú vị.

Đây là định nghĩa của anh, bạn có thể đồng ý hoặc không:

Nói bằng lời: agent là phần mềm deterministic, harness những kết quả non-deterministic do model tạo ra, nhằm theo đuổi một mục tiêu mong muốn nào đó.

Cụm "deterministic software" có thể khiến bạn nghĩ nhiều hơn tới một harness. Justin thật lòng thấy việc phân biệt agent với harness là rất bắt bẻ câu chữ, không có ích lắm, và trong phần lớn trường hợp bạn cứ gộp hai thứ làm một. Harness là agent, và agent là harness. Trong phạm vi talk này, anh đi tiếp với cách hiểu đó. Anh thừa nhận có lẽ bạn đưa ra được vài lập luận hay để nói cái này là cái kia hoặc ngược lại, nhưng điều đó không quan trọng lúc này.

Nếu vừa rồi có ví dụ nào bật ra trong đầu bạn, có thể đó là Claude hoặc Codex, hay OpenClaw, Hermes. Nhưng Justin cá rằng nếu bạn đi ra đường phố của giới văn phòng Mỹ ở bất kỳ thành phố nào, có lẽ trừ San Francisco, và hỏi một người trong một tòa nhà văn phòng "Bạn có kể tên được một agent không?", vài người sẽ nói Claude, vài người có thể nói Codex, và chỉ có vậy. Anh không nghĩ có mấy ai nói OpenClaw hay Hermes. Thậm chí với Claude, anh cũng không chắc mọi người biết đó là một agent. Những thứ này chưa được hiểu rõ.

4. Ai cũng đang build agent. Vì sao?

Vậy mà điều điên rồ là ai cũng đang build agent. Có một công ty bất động sản ngay cuối phố nhà anh đang build agent. Anh biết những môi giới bảo hiểm tư nhân độc lập đang build agent riêng. Anh biết các công ty Fortune 500, rất nhiều công ty, đang build custom agent của họ. Ai cũng đang cố build custom agent riêng.

Anh biết người ta không tin anh, nhưng cứ đi nói chuyện với họ. Cứ đi hỏi mọi người. Họ đang cố build custom agent, và anh không khỏi thắc mắc: vì sao? Dường như không ai đặt câu hỏi này. Vì sao? AI đã có mặt ở khắp nơi. Bạn có thể vào ChatGPT, hoặc xuống tận một open source model nào đó của Trung Quốc trên một website ọp ẹp. Ở giữa thì có đủ mọi thứ. Vậy mà người ta vẫn muốn build custom agent.

Rốt cuộc, câu trả lời nằm ở integration. Doanh nghiệp muốn dữ liệu của họ được tích hợp đúng cách vào AI. Họ tin, và có lẽ họ đúng, rằng nếu tận dụng AI một cách phù hợp, họ sẽ có những bước tăng trưởng đột phá trong kinh doanh, vân vân và vân vân.

Vì thế họ cần tìm cách tích hợp, và build custom agent riêng hiển nhiên là một cách làm điều đó. Đó cũng là một trong những cơ chế đầu tiên họ phát hiện ra để làm việc này.

5. Agent rất khó, và ngoài kia là một mớ hỗn độn

Vấn đề là agent thực sự khó. Bạn phải chăm chút cực kỳ cẩn thận cho agentic loop và bảo đảm nó được orchestrate đúng. Có cả đống provider abstraction bạn cần nghĩ tới; may là đang có vài tool tốt ra đời cho phần này, chẳng hạn Vercel AI SDK rất tốt. Rồi durable execution: bạn cần bảo đảm nếu có lỗi xảy ra thì có thể chạy tiếp từ chỗ dừng. Đây là những bài toán tương đối khó, nhất là khi bạn nghĩ tới chúng ở quy mô lớn. Và thực tế còn nhiều hơn thế nữa: đủ loại validation, stop condition, vân vân.

Vì vậy điều thường xảy ra là: người ta có thử build custom agent, và nó chạy được như một bản demo, nhưng không hơn thế bao nhiêu. Hóa ra đây là một cơn ác mộng thật sự. Build agent robust thì đơn giản là khó. Và nếu bạn đi nói chuyện với bất kỳ ai trong phòng IT (anh cười), họ đang bứt tóc vì có quá nhiều mối lo khác nhau.

Justin đi qua từng ý trên slide:

• Chưa có cách nào được định nghĩa để build agent, thật sự là không có. Thứ gần nhất có lẽ là Eve, vừa được Vercel ra mắt. Nhưng trên thực tế, ai cũng đang tự nghĩ ra cách của riêng mình.
• Telemetry và observability trên những agent này khó tới mức khó tin, nhất là ở quy mô lớn. Nếu bạn muốn biết chính xác cái gì được truyền đi ở mỗi step của mỗi turn trong agent, để chẩn đoán, tinh chỉnh và bảo đảm mọi thứ không trật đường ray, thì việc đó rất khó.
• Agent không portable. Giả sử bạn đã làm được một agent tốt, đã leo lên tới đỉnh ngọn núi này và có một agent cuối cùng chạy ngon. Thì nó chạy ngon trên máy của bạn (anh cười). Khi bạn đưa nó cho người khác, giữa đủ thứ cấu hình environment variable, yêu cầu hệ thống và runtime, khả năng rất cao là nó sẽ không chạy trên máy người kia.
• Agent không composable. Kể cả khi bạn làm được một chatbot thật tốt cho trường đại học của mình, khả năng bạn tái sử dụng nó cho một việc khác là rất, rất thấp. Bạn không thể dễ dàng chia sẻ nó.

6. Lối thoát thứ nhất: MCP, kênh phân phối tool

Thế là chuyện thường xảy ra: sau một thời gian ngắn theo đuổi agent, người ta lùi lại và nói "Thôi được. Không agent nữa, không agent." Thay vào đó, họ sẽ làm cái vụ MCP. Họ đã nghe về nó, và nó chạy được.

Và đúng là Model Context Protocol chạy được. Nó chạy khá tốt để lấy thông tin của doanh nghiệp, chẳng hạn thông tin của Zillow, rồi nhét vào một trong những agent rất lớn có sẵn như Claude hay ChatGPT, thứ mà Justin xếp vào loại large general-purpose agent. Nó chạy được theo kiểu đó, và chạy ở mức tạm ổn.

Nhưng hãy nhìn vào bảng này, lấy từ chính website của MCP: bảng liệt kê những gì được hỗ trợ trong các MCP client trên khắp thế giới. Bạn sẽ thấy chỉ có đúng một cột được điền đầy từ trên xuống dưới, và dĩ nhiên đó là cột Tools.

Vậy là MCP đã trở thành cơ chế phân phối tool trên thực tế cho agent. Nếu bạn cần đưa tool của công ty mình vào một agent khác, MCP là một cách tốt để làm điều đó. Nhưng nó chưa chứng tỏ được là giỏi mang lại những giá trị khác.

Và thẳng thắn mà nói, tool thôi là không đủ. Justin thích đùa rằng chúng ta không đưa được người lên Mặt Trăng bằng cách đưa cho một anh chàng cả đống tool (anh cười). Đó không phải cách thực tế để hoàn thành một dự án thật lớn.

7. Lối thoát thứ hai: skill, một đống tài liệu

Vậy có thể MCP không phải là con đường. Nhưng à há, chúng ta có skill. Chúng ta có skill, và skill rất tuyệt. Justin nói anh thực sự thích skill, và chắc bạn cũng vậy. Chúng ta cài skill liên tục cho đủ mọi việc.

Về cơ bản, một skill là một file markdown, hoạt động như tài liệu. Điều thú vị là có rất nhiều nghiên cứu cho thấy nếu bạn dùng thật nhiều skill, agent của bạn thực ra sẽ tệ đi đáng kể. Nhưng chúng đúng là có tác dụng như tài liệu cho nhiều thứ phức tạp.

Quay lại phép so sánh người lên Mặt Trăng: dùng skill hơi giống việc đưa cho anh chàng kia cả núi tài liệu. Tài liệu sẽ giúp được, nhưng đó không phải là vấn đề gốc.

8. Agent stack: gần như mọi thứ đều là context

Vậy vấn đề gốc là gì? Justin dựng một agent stack cơ bản, từng lớp một.

• Bắt đầu với một model. Mọi agent đều bắt đầu với một model. To hay nhỏ không quan trọng, chúng đều bắt đầu từ model.
• Tiếp theo, bên trên là một thứ như system prompt, nói cho model biết vai trò của nó trong vũ trụ rộng lớn là gì, kiểu như mục tiêu sống của nó.
• Rồi tới tools: những thứ nó thật sự có thể làm, những hành động nó có thể thực hiện.
• Skill được xếp lên trên đó.
• MCP lại xếp lên trên nữa.
• Và cuối cùng là toàn bộ messages của cuộc hội thoại.

Đại khái đó là chồng thông tin được truyền qua lại trong runtime của một agent. Và nếu nhìn kỹ, gần như tất cả đều là context. Về cơ bản là mọi thứ: system prompt, tools, skills, tất cả đều là những thứ cuối cùng nằm trong context của agent.

Vì vậy, về cơ bản người ta đang cố giải bài toán integration bằng cách làm việc trên context hoặc model. Đây là hai khu vực liên tục có tiến bộ mới. Chúng ta cũng thấy những thứ mới ra đời như skill và MCP, những công nghệ mới, những protocol mới. Tất cả chúng đều ra đời trong khu vực của context và model.

9. Bơm phồng context chính là inheritance

Vậy trên thực tế nó vận hành ra sao? Giả sử bạn làm ở một công ty, thỉnh thoảng cần đi công tác, nên bạn cài vài MCP về du lịch. Bạn cũng cài Figma và Playwright. Tất cả những thứ đó chồng dần lên tầng context. Rồi bạn có vài MCP Gmail để kiểm tra thư hộ bạn, và Google Sheets để điền mấy cái báo cáo chi phí hay gì đó.

Rồi tới skill. Bạn là developer, nên bạn có mấy skill sửa lỗi React và linter. Justin nói cái này, theo anh, là MCP server phổ biến số một hoặc số hai hiện có (trên slide, mục React Code Fix & Linter nằm ở tầng Skill). Có thể bạn có skill grill-me của Matt (trong bộ skill của Matt Pocock), hoặc skill GitHub. Về cơ bản, điều bạn đang làm là bơm phồng tầng context.

Trong kỹ thuật phần mềm, chúng ta có một thuật ngữ cho chuyện này: inheritance. Ý tưởng của inheritance là bạn lấy một object, rồi thêm attribute vào để object đó có thêm những thuộc tính khác. Đó chính xác là điều ta đang làm với agent. Ta nói: agent này khá tốt, nhưng nếu thêm tất cả các lớp bổ sung này vào, agent sẽ làm được những việc trước đây nó không làm được. Đó đúng là inheritance.

Và sự thật về inheritance là: nó chạy được. Nó thực sự chạy được. Đó là lý do những thứ này tồn tại ngoài kia, và chúng đang chạy. Nhưng có một câu nói cũ: "Composition over inheritance." Hóa ra điều này cũ như trái đất: tới một lúc nào đó, inheritance bắt đầu đổ vỡ.

Hãy tưởng tượng: bạn có năm skill trên ChatGPT, à không, trên Claude (anh tự sửa lại), và mọi thứ chạy khá tốt. Giờ nếu bạn có 100 skill thì sao? Nếu có 1.000 skill thì sao? Tới một điểm nào đó, bạn sẽ nhận lợi ích giảm dần khi thêm context. Điều đó hiển nhiên, ai cũng ngầm hiểu.

10. Composition: mỗi domain một agent nhỏ, phía trên là coordinator

Vậy có giải pháp thay thế không? Có: composition là giải pháp thay cho inheritance. Nó trông như thế này.

Hãy tưởng tượng ta có một agent nhỏ khác, và một lần nữa ta muốn cung cấp Figma như một thứ mà agent chính có thể làm được. Thứ ta có thể làm là có một agent tí hon mà system prompt của nó được viết riêng để làm một Figma agent. Nó biết mọi thứ về Figma: toàn bộ context của Figma, toàn bộ API, mọi chỗ đúng để bấm, những việc cần làm, những chuyển động chuột cần thực hiện, vân vân. Nó có đúng những tool chính xác cần để thực hiện các hành động đó, không hơn, chỉ vậy thôi. Và có một message history rất nhỏ, chỉ liên quan tới phần Figma của công việc.

Rồi bạn có thể có thêm nhiều agent như vậy. Bạn vẫn có Gmail, travel, Google Sheets và mọi thứ khác, nhưng mỗi cái là một agent riêng biệt, cô lập. Một agent đầy đủ, không chỉ là một server nhỏ gắn vài tool. Nó là một agent hoàn chỉnh, có message history riêng, có agentic loop riêng. Và phía trên những agent này, bạn có một coordinator.

Cơ chế giao tiếp giữa tất cả các agent nhỏ với agent lớn phía trên chỉ đơn giản là tiếng Anh. Chúng nói chuyện với nhau theo cách con người nói chuyện. Ví dụ, agent chính nghĩ "Ồ, mình nên kiểm tra thư xem có gì về một chuyến đi không", thì nó biết phải đi hỏi Gmail agent xem có email mới nào về chuyến đi. Kết quả đi ngược lên: "À đúng rồi, thật ra cuối tuần này có một chuyến đi Los Angeles." Rồi agent chính có thể sang travel agent và bắt đầu đặt chỗ. Đó là hình dung sơ bộ về cách một hệ như vậy có thể vận hành.

11. Chúng ta đã lên Mặt Trăng theo đúng cách này

Thực tế là cách này chạy được, và chúng ta biết nó chạy được vì đây chính là cách chúng ta đã lên Mặt Trăng (anh cười). Có những đội chuyên gia, những đội chuyên gia với gương mặt như thế này, và gương mặt như thế kia, mỗi người có những kỹ năng và năng lực khác nhau, và những gương mặt như thế kia nữa.

Anh nói đây là ngày phóng Apollo 11, rồi chỉ vào một người: "Nhìn ngay đây. Có một agent. Tôi vừa tìm thấy một agent đang ngồi ngay đó" (anh cười). Bộ não của anh ấy là LLM của anh ấy. Còn tool của anh ấy nằm ngay trên bảng điều khiển trước mặt. Đó là những tool. Anh ấy không có tất cả mọi tool. Anh ấy chỉ có những tool đó, và anh ấy cực kỳ, cực kỳ giỏi dùng chúng. Rồi nhìn cái miệng kia: đó là messages.

Chúng ta đã quen với điều này. Chúng ta hiểu được nó. Nó chạy được một cách tự nhiên. Theo Justin, đây gần như là một dạng biomimicry (mô phỏng sinh học) cho thế giới agentic. Và nó chạy được.

Anh gọi chúng là domain-specific agent. Anh không nghĩ mình là người đầu tiên nói ra cụm "domain-specific agent", chắc chắn cũng không phải người đầu tiên có ý tưởng này, nhưng đó là điều anh muốn nói với bạn: những agent chỉ nhắm vào một domain rất cụ thể. Ở Standard Agents, nhóm anh đã build hệ sinh thái này một thời gian khá lâu, nên đã có dịp nhìn rất kỹ từ bên trong cách chúng thực sự vận hành. Anh chưa sẵn sàng ra đây công bố sản phẩm hay gì cả, nhưng có thể cho bạn nhìn lén một chút.

12. Ích lợi 1 và 2: tiết kiệm token, small model dùng được

Thứ nhất, chúng hiệu quả hơn hẳn về token, hiệu quả hơn rất nhiều. Nhóm của Justin thường xuyên thấy mức tiết kiệm token trên 80% cho một task bất kỳ. Điều này phức tạp hơn một chút, vì bạn phải định nghĩa các task đó trước nhiều hơn. Nhưng nếu agent có portability, tức là anh có thể lấy Gmail agent đó, gói gọn lại rồi gửi cho người khác, thì ta có thể tạo ra một hệ sinh thái mà không ai phải tự tạo từng skill và năng lực một. Và bên trong domain đó, bạn sẽ có hiệu quả vượt trội.

Một phần lý do: hãy nghĩ về cách context vận hành. Khi agent nhỏ quyết định làm một việc, nó không cần toàn bộ context của cuộc hội thoại. Thay vào đó, tầng coordinator chính chỉ cần hỏi Gmail agent: "Này, lấy giúp email cuối cùng từ Debbie", và đó là toàn bộ context. Theo nghĩa đen, nó chỉ có system message, tool của nó, và đúng tin nhắn vừa gửi tới. Nhờ vậy nó làm được việc nhỏ xíu, rất nhắm đích, rất chuyên biệt đó mà không cần tất cả context xung quanh.

Thứ hai, chúng thực tế hơn nhiều với small language model. Nếu nhìn sự chênh lệch giữa hai model như DeepSeek V4 Flash và Fable 5, mức chênh chi phí thật khó tin: DeepSeek V4 Flash rẻ hơn Fable 137 lần cho mỗi task. 137 lần.

Tất nhiên, nếu DeepSeek V4 Flash thất bại hết lần này tới lần khác khi làm việc đó, thì nó không chỉ không rẻ hơn bao nhiêu, mà còn khó chịu hơn nhiều khi dùng. Nhưng đó là lý do domain-specific agent tuyệt vời: bạn không cần V4 Flash làm mọi thứ. Nó chỉ cần làm đúng những task đã được chọn riêng cho nó, và với một context tối thiểu, nó có thể thực hiện chúng rất đáng tin cậy.

Vậy là bạn có mức giảm chi phí đột phá, không chỉ nhờ hiệu quả token, mà còn vì bạn có thể dùng language model nhỏ hơn nhiều, và thậm chí cả những model không phải language model. Bạn có thể dùng image generation và diffusion model. Bạn có thể dùng đủ loại model khác cho các task nhỏ hơn.

13. Ích lợi 3 và 4: giới hạn quyền chặt, scale tốt

Thứ ba, bạn có thể áp những giới hạn thật chặt lên năng lực của agent, và Justin nghĩ bạn biết anh đang nói tới điều gì. Anh đang nói tới cái này:

Bây giờ tất cả chúng ta đều đang bay quá gần mặt trời (anh cười), khi ai cũng bypass permission tứ tung. Và tất nhiên là bạn phải làm vậy, vì một coding agent chạy model lớn có thể làm bất cứ điều gì, nên ta dùng nó để làm mọi thứ.

Trong một thế giới được vận hành bởi các domain-specific agent nhỏ hơn, những agent đó không thể làm mọi thứ. Chúng chỉ làm được những việc đã được phê duyệt rõ ràng cho chúng từ trước. Điều đó không có nghĩa là bạn không thể có permission và hộp thoại xin quyền nữa, nhưng bạn đang chọn tham gia một hệ sinh thái được kiểm soát chặt hơn nhiều. Và Justin hứa rằng khi bạn giải thích điều này cho anh Doug bên IT (anh cười), nó sẽ làm Doug yên lòng khi hiểu sự khác biệt giữa hai cách này.

Thứ tư, chúng có đặc tính scale rất tốt. Vì mỗi agent là một môi trường thực thi nhỏ của riêng nó, bạn có thể chạy song song chúng, đưa chúng lên cloud rất dễ mà không cần, kiểu như, một VPC khổng lồ trên đó. Bạn có thể chạy hàng nghìn instance cùng lúc, ở đủ mọi region trên thế giới. Chúng không cần phải đặt cùng một chỗ về mặt địa lý hay gì cả. Nên chúng có đặc tính scale rất, rất tốt.

14. Chúng chưa tồn tại, nhưng đang tới: dự đoán cho 2026 và 2027

Đáng tiếc là chúng chưa tồn tại. Đó là mặt trái (anh bật cười). Những domain-specific agent này chưa thật sự tồn tại, ít nhất là chưa theo cách công khai và rộng rãi. Như anh đã nói, ở Standard Agents nhóm có chúng và làm việc với chúng hằng ngày, nhưng ngoài kia công chúng chưa có nhiều.

Tuy nhiên, điều đó đang thay đổi, và sẽ thay đổi rất nhanh. Chúng ta đang ở khoảng giữa năm 2026, và Justin ở đây để đưa ra một dự đoán công khai: từ thời điểm này tới cuối 2026, chúng ta sẽ thấy số người nói về việc build domain-specific agent tăng vọt, các framework xoay quanh chúng, đủ thứ đang trên đường tới. Và nó không phải một dòng chảy nhỏ giọt. Nó sẽ tăng tốc rất nhanh, và trở thành một trong những thành phần chính của hệ sinh thái agentic.

Còn 2027, theo anh, về cơ bản sẽ là năm của multi-agent orchestration. Đó là một cụm từ khác mà anh nghĩ bạn sẽ bắt đầu nghe rất nhiều. Đó là dự đoán lớn, táo bạo và công khai của anh.

Justin kể anh đã rất hào hứng cách đây vài ngày khi Vercel ra mắt Eve. Đó là lần đầu tiên anh thấy cái thuật ngữ mà mình vẫn gào vào khoảng không (anh cười) dội ngược lại vào mặt mình. Dòng giới thiệu của Eve ghi: framework để build agent, build một company brain, một personal assistant, hoặc một domain-specific agent. Vậy đó. Khoảng giữa năm nay, xu hướng này sẽ bắt đầu lấy đà. Đó là dự đoán của anh.

15. Token không còn rẻ đi, và AI đứng trước khách hàng

Có nhiều lý do cho dự đoán đó. Một trong số đó liên quan tới điều mà hầu hết mọi người hiện đang tin: rằng chi phí của intelligence đang giảm. Justin nói xu hướng đó thật ra đã đảo chiều trong năm 2026. Nhóm anh theo dõi chuyện này trên một website. Token không còn rẻ đi nữa. Chúng thực ra đang tăng, kể cả khi đã điều chỉnh theo IQ. Riêng năm nay, chúng đã tăng 29% sau khi điều chỉnh theo IQ. Mới nửa năm mà đã tăng khoảng 30%.

Điều đó có thể do nhiều nguyên nhân khác nhau. Dĩ nhiên, có cơn khủng hoảng bộ nhớ (memory crunch), và có lẽ xu hướng dài hạn qua một chu kỳ 10 năm hay đại loại vậy là giá intelligence sẽ giảm. Nhưng điều đó không có nghĩa là ta cần trả gấp 137 lần cho một việc có thể làm được hiệu quả không kém. Vấn đề là chia tách những việc đó ra thì khó hơn.

Còn nếu không điều chỉnh theo IQ, token đã tăng 76% trong năm nay, gần như tăng gấp đôi chỉ trong năm nay, mà ta còn chưa đi hết nửa năm. Vậy là chi phí token đang thật sự đi lên. Nên bất cứ điều gì ta làm được để kéo nó xuống, nhất là với doanh nghiệp lớn, sẽ rất quan trọng.

Use case còn lại thật sự cần cân nhắc là đặt AI trước mặt khách hàng. Bạn không thể đặt Fable trước mặt khách hàng, trừ khi khách hàng đó có lifetime value cực lớn. Nó đơn giản là quá đắt. Vì thế bạn cần tìm cách tạo ra hiệu quả công việc tốt trong khi vẫn tiết kiệm, và domain-specific agent sẽ là cách để làm điều đó.

16. Mơ một chút: tầng tool và hooks của một agent lý tưởng

Justin nói sắp để bạn đi rồi, nhưng trước đó hãy cùng mơ một chút. Anh đào sâu hơn vào cách một agent có thể được orchestrate và một agent lý tưởng thực sự trông ra sao, rồi anh hứa sẽ để bạn yên.

Nhớ lại: ta có model, và ta có system prompt. Giờ hãy tách tầng tool ra một chút.

• Một mặt, ta có function. Đây là một hàm thật có thể được thực thi, ví dụ ghi một file xuống file system.
• Rồi ta có prompt. Prompt khá giống system prompt, nhưng là những prompt nhỏ, riêng lẻ, có thể được chèn vào, hay những sub-prompt: bạn có thể chạy một function mà thực ra là gọi một LLM. Ví dụ, agent chính của bạn đang chạy trên GLM 5.2, nhưng bạn muốn dùng Nano Banana chỉ để tạo một bức ảnh. Bạn chỉ cần một tool là một prompt. Theo Justin, nếu làm được vậy thì sẽ rất hay.
• Và một loại tool khác có thể là một agent hoàn chỉnh: cả một domain-specific agent khác có thể chỉ là một trong các tool.

Đó là tầng tool. Rồi bạn có hooks. Hook là gì? Trong thế giới lý tưởng này, hook có thể là thứ harness, thay đổi, biến đổi dữ liệu hoặc tạo side effect.

Anh đưa ví dụ. LLM không biết bây giờ là mấy giờ, ở bất kỳ thời điểm nào. Hóa ra một cách rất hay để cho nó biết giờ là chèn một message nhân tạo, hoặc một tool call nhân tạo, vào message history. Trông như thể ai đó vừa hỏi "Này, mấy giờ rồi?" và người kia đáp "À, 6:45 tối giờ Pacific." Khá đơn giản. Bạn có thể làm việc đó bằng một hook, hoặc dùng hook để kích hoạt một side effect nào đó. Đây là một mảnh quan trọng của agent.

17. Agent rules, file system và code execution

Cuối cùng là agent rules, và agent rules khá phức tạp. Ví dụ: một bên được bao nhiêu lượt? Nó có được chạy 10.000 turn, hay 10.000 step, trước khi hết lượt không? Có đủ loại luật nhỏ thú vị như thế. Khi agent gọi một tool, nó có bắt buộc phải validate toàn bộ hay không? Đủ loại luật rất cụ thể thuộc về một agent nhất định.

Gói tất cả những thứ đó lại, ta gọi đó là một agent. Nhưng nó vẫn còn thiếu vài thứ.

Một, mọi agent thực sự nên có một file system. Nếu bạn từng làm thế này với ChatGPT, Claude hay Codex: không ở trong project nào cả, bạn chỉ hỏi "Này, làm giúp tôi một file PDF cho tiệc sinh nhật con trai tôi". Nó sẽ làm, và sẽ lưu file trong file system nhỏ của riêng nó. Vậy là các lab lớn đã nhận ra rằng để tạo một giao diện chat hiệu quả, chưa nói tới một agent lớn, cần có một dạng file system nào đó. Vì thế mọi agent nên có một sandbox file system nhỏ của riêng nó.

Hai, mọi agent cũng nên có một chỗ chạy code trong sandbox. Nó có thể ghi file, chạy những file đó, và làm việc đó một cách an toàn, không exfiltrate thứ gì, không tương tác với OS ở tầng cao hơn. Điều đó cần được dựng sẵn như một primitive trong mọi domain-specific agent.

18. Sub-agent đệ quy: từ Salesforce tới GDPR

Được rồi, giả sử đó là agent lý tưởng của chúng ta. Giờ hãy nói về cái tool "agent" nhỏ ở kia. Nó là gì? Đó có thể là sub-agent, thậm chí là sub-agent đệ quy. Bạn có thể có một agent gọi một sub-agent, sub-agent đó gọi các sub-agent, rồi các sub-agent đó lại gọi các sub-agent khác. Có thể có một hoặc nhiều sub-agent như vậy ở nhiều tầng khác nhau.

Ví dụ, bạn có thể có một coordinator agent ở trên cùng, rồi có một Salesforce agent. Agent đó biết Salesforce từ trong ra ngoài. Nó biết toàn bộ API, nó có đủ credential để giao tiếp với Salesforce instance của bạn theo mọi cách phù hợp. Rồi nó cần giao tiếp với một Google Workspace agent để làm đủ thứ trong đó, ví dụ chạy spreadsheet. Bạn có thể hỏi: "Này, những nhân viên sales giỏi nhất của tôi năm nay là ai?" Và bùm, nó tra trong Salesforce, phối hợp với sub-agent, tạo một sheet cho bạn và gửi lại. Hoàn hảo.

Nhưng có thể sau đó bạn cần tạo vài asset. Vậy là Salesforce agent có thêm một sub-agent khác mà nó có thể nói chuyện bất cứ lúc nào, và sub-agent này cực giỏi tạo asset. Có thể sub-agent đó không chỉ có image generation của Codex. Có thể nó có Nano Banana, có một SVG generator, đủ thứ, để nó trở thành một asset generator tuyệt vời, và tự thực hiện reflection và QA cho chính nó.

Rồi agent chính có thể cần cả một legal team agent chỉ để kiểm tra những gì các agent kia làm ra. Và có thể legal team agent lại thật sự cần một GDPR compliance agent chỉ dành cho khách hàng châu Âu. Agent chính không có hết tất cả những thứ đó; chúng ta không muốn có 45 megabyte context chỉ về GDPR (anh cười), nên ta tách nó thành một sub-agent riêng. Và có thể legal team cũng cần một OSHA compliance agent, cũng rất phức tạp, nên nó có một agent riêng cho việc đó.

Bạn hiểu ý rồi đấy. Bạn có thể có đủ loại agent nhỏ, hiệu quả cao, cùng làm việc với nhau, nhưng giữ context window nhỏ, tối thiểu ở mọi tầng. Đó là ý tưởng đằng sau domain-specific agent.

Justin cảm ơn mọi người đã nghe. Một lần nữa, Standard Agents là nơi anh đang làm, tại standardagents.ai. Bạn có thể đăng ký early access trên đó; nhóm đang bắt đầu mở dần cho một số ít người. Nếu doanh nghiệp của bạn cực kỳ tham vọng và thật sự muốn thử các domain-specific agent nhỏ, bạn có thể viết thư cho anh. Và tất nhiên anh sẽ rất vui nếu bạn follow anh. Cảm ơn rất nhiều. Tạm biệt.