Làm việc như dân chuyên: giải thích AI agent team

1. Tiệm tóc chạy bằng AI: một agentic system

Video mở bằng một câu ngắn: "khoan đã, xem thử ví dụ nhanh này". Hãy hình dung một cô thợ làm tóc điều hành toàn bộ việc đặt lịch của tiệm bằng AI. Một yêu cầu gửi tới, và AI cứ thế xử lý nó (demo trong video đăng ngày 15/10/2026). Trong đoạn hoạt hình mở đầu, cô đứng cắt tóc cho khách, còn trên bàn cạnh cửa sổ là một chiếc laptop và một thiết bị nhỏ hình robot với hai mắt xanh, tượng trưng cho AI của tiệm.

Đoạn mở đầu của video đăng ngày 15/10/2026 kể lần lượt những gì AI xử lý. Lịch 10 giờ 30 ngày mai bị huỷ; một khách khác đã nhận chỗ đó; đặt lịch xong. Tin nhắn nhắc lịch hẹn cho ngày mai sẽ được gửi đi lúc 3 giờ, như mọi khi. Gặp một vấn đề, hay một thay đổi trong lịch làm việc, nó cũng biết cách xử lý. Và nó biết khi nào cần gọi cô vào: "Có một việc cần chị", màu nhuộm của một khách bị ngả vàng (brassy). Câu kết của đoạn mở đầu: đó chính là một agentic system.

Anh nói rõ đây chỉ là một ví dụ, nhưng là ví dụ của một agentic system đang làm việc. Bạn thấy cô thợ vẫn tiếp tục làm công việc của mình, trong khi tất cả phần việc kia được AI quản lý. Nghe thì có vẻ viển vông, nhưng Matt khẳng định những gì bạn thấy ở đó là điều đã làm được rồi, theo anh tính đến lúc video đăng (15/10/2026): không có chi tiết nào trong ví dụ đó là không làm được.

2. Chỉ cần một agentic system

Theo Matt (video đăng ngày 15/10/2026), để làm được như vậy bạn không cần học thêm kỹ năng mới nào, không cần mua thứ gì mới, cũng không cần nghĩ ra những cách thật sáng tạo để vận hành một hệ thống. Tất cả những gì cần là một agentic system. Và đó là chủ đề của video này.

Anh nói toàn bộ sức mạnh đó đã nằm sẵn trước mặt bạn nếu bạn đang dùng AI (theo Matt, tính đến 15/10/2026). Anh muốn chia sẻ nó để bạn bước lên nấc tiếp theo trong cách những người dùng AI hiệu quả nhất đang làm việc lúc này. Theo mô tả của Matt ở thời điểm video đăng (15/10/2026), những người đó không còn chỉ gửi một yêu cầu vào một agent rồi lặp đi lặp lại theo kiểu ấy nữa. Họ làm việc với các agentic system: chia nhỏ vai trò (roles), quy tắc (rules) và trách nhiệm (responsibilities), rồi làm việc theo kiểu hợp tác giữa nhiều agent. Matt nói việc này dễ hơn bạn nghĩ rất nhiều, và tốt hơn bạn có thể tưởng tượng rất nhiều.

Trong video đăng ngày 15/10/2026, điều Matt muốn làm là nói về các primitive của một hệ thống như vậy: những bộ phận thật sự làm cho nó chạy, và những bộ phận sẽ luôn chạy được. Chúng không nhiều, chỉ có bốn. Anh sẽ chỉ ra bốn primitive đó, đồng thời giải thích vì sao chúng là primitive và vì sao chúng hữu ích về lâu dài. Phần việc hôm nay chỉ là mô tả các primitive của một agentic system, và Matt cam đoan rằng chỉ cần hiểu chúng là bạn có thể tạo ra một agentic system gần như ngay lập tức.

3. Vì sao primitive quan trọng

Trong video đăng ngày 15/10/2026, Matt nói hôm nay anh không đi lại câu hỏi agentic system là gì.

Anh cũng kể ngắn về bản thân để người xem hiểu bối cảnh. Mấy tháng gần đây, tính tới lúc video đăng (15/10/2026), Matt đi khắp nơi trên thế giới dạy AI cho mọi người. Thứ anh dạy là các primitive của AI, chứ không phải agentic system. Video này là nấc cao hơn so với những gì anh đã dạy, nhưng các primitive đó vẫn còn đúng.

Theo Matt (video đăng ngày 15/10/2026), nội dung anh dạy được soạn từ khá lâu rồi, và những gì được dạy trong đó vẫn còn nhiều ý nghĩa. Nó vẫn đứng vững. Primitive thì quan trọng. Và giờ, theo anh, chúng ta sắp khám phá những primitive mới, về những hình dạng mới trong cách người ta đang lấy được việc thật từ AI. Matt nói anh rất nóng lòng chia sẻ điều này, và đi thẳng vào nội dung.

4. Primitive 1: roles and responsibilities

Điều đầu tiên Matt muốn nói (video đăng ngày 15/10/2026): để có một hệ thống, bạn cần chia nhỏ công việc của mình. Anh nhắc lại đoạn demo cô thợ làm tóc và tất cả những thứ AI đang quản lý cho cô. Điểm quan trọng là trong đó chỉ có đúng ba việc.

Việc thứ nhất, theo Matt (video đăng ngày 15/10/2026): các yêu cầu đi vào, và mỗi yêu cầu phải được biến thành một lịch hẹn, hoặc có thể là một câu hỏi gửi ngược lại khách hàng. Việc đó có thể giao cho một agent, hay một role. Việc thứ hai: nếu có khách mới chẳng hạn, ta cần thêm họ vào danh sách khách hàng. Tức là cập nhật client list, lưu ảnh của từng khách, xếp lịch tất cả các buổi hẹn của họ, những việc đại loại như vậy. Việc thứ ba: có một email được gửi đi, hoặc báo cho khách thông tin về lịch hẹn ngày hôm sau, hoặc những thứ khác tương tự.

Theo Matt (video đăng ngày 15/10/2026), đó là ba role riêng biệt, và chúng có những bộ trách nhiệm rất khác nhau. Không có lý do gì để dồn tất cả trách nhiệm đó lên một agent. Nếu bạn đang nói chuyện với một agent duy nhất (và anh nói phần lớn chúng ta đã bắt đầu từ đó và vẫn còn ở đó), thì điều bạn đang làm là cố nhét mọi vấn đề vào cùng một không gian. Mỗi việc đều có nhiều thứ phải làm, chúng có thể chồng lấn lên nhau và khiến nhau mắc lỗi.

Vì vậy bạn không muốn làm thế. Matt nói (video đăng ngày 15/10/2026) rằng nói chung với AI, tách công việc ra thì tốt hơn. Nói chung với mọi loại kỹ thuật (engineering), dễ nhất là tách các mối quan tâm (separate concerns). Thứ đang bàn ở đây là ba role khác nhau, và Matt gọi chúng là roles and responsibilities.

Theo Matt (video đăng ngày 15/10/2026), điều ta muốn là xây một hệ thống có thể nói: tôi có một "người" biết cách xử lý client list của tôi. Role đó được định nghĩa ở đây, trong một file. Nếu việc đó cần làm, hãy dùng file ấy, khởi động một agent mới, để nó đọc file đó, và đó là role nó sẽ nhận. Tôi có một "người" khác lo các yêu cầu đi vào; đó là một file khác mô tả role đó, mọi thứ cần biết về nó. Và tôi còn một "người" nữa biết cách gửi email mỗi ngày, những việc kiểu như vậy.

Như vậy, theo cách Matt mô tả (video đăng ngày 15/10/2026), về cơ bản có ba file, ba file nhỏ rất đơn giản, là file markdown nói mỗi role làm gì. Sau đó bạn khởi động một agent và bảo nó: "khi tôi khởi động bạn, hãy đọc file đó". Matt nói đó về cơ bản là dựng lên một loạt agent, mỗi agent đóng role của riêng nó.

Matt chỉ ra vấn đề nằm ở đây (video đăng ngày 15/10/2026): giờ bạn có tất cả những hệ thống độc lập, những agent ngồi đó, mỗi agent chỉ làm được việc của mình. Làm sao để điều phối chúng?

5. Primitive 2: coordination, một agent đứng trên cùng

Matt nói (video đăng ngày 15/10/2026) khi bạn chia nhỏ công việc là bạn đã bắt đầu xây một hệ thống. Đến lúc đó, bạn bắt đầu tự hỏi: làm sao để việc được làm xong? Bằng cách nào đó, ta cần điều phối tất cả các phần việc khác nhau này. Và theo anh, đây chắc chắn là một trong những phần hay nhất của cả hệ thống.

Theo Matt (video đăng ngày 15/10/2026), ở điểm này ta muốn đi từ những agent độc lập, mỗi agent biết việc của mình, sang một agent lớn hơn đứng trên cùng. Bạn có thể hình dung nó là một agent điều phối công việc. Bạn có thể nghe người ta gọi nó là coordinator, hay manager. Matt gọi agent của mình là producer. Anh nói anh có một lý do cụ thể cho cái tên đó, nhưng không giải thích trong video này.

Theo Matt (video đăng ngày 15/10/2026), agent này là một agent rất thông minh. Thường thì anh đặt nó ở mức intelligence cao nhất mà anh có, vì nó được thiết kế để không làm việc gì cả. Thật ra, mục tiêu của nó chính là không làm việc. Nó cần hiểu vấn đề đang đi vào, dù vấn đề đó là gì, rồi tìm ra việc đó cần giao cho ai, và người làm cần context gì. Vì vậy cuối cùng nó trở thành thứ ta có thể gọi là một router.

Theo Matt (video đăng ngày 15/10/2026), nó giống như một thứ nói rằng: có một vấn đề vừa đến; tôi có hai bên cần biết về vấn đề này, nhưng tôi sẽ không đưa toàn bộ vấn đề cho từng bên, vì họ không cần. Tôi sẽ đưa một phần nhỏ cho agent ở bên này, và gọi một agent ở bên kia lên để xử lý phần còn lại. Matt nói ý tưởng là như vậy. Bạn đang làm việc với một producer (anh sẽ tiếp tục gọi nó như thế), nhưng về cơ bản là một coordinator biết công việc ở tầng trên cần được tổ chức ra sao.

Matt nói coordinator đó gần như là thứ đầu tiên anh muốn có trong một dự án kiểu này. Trong gần như mọi dự án của anh dạo này, tính đến lúc video đăng (15/10/2026), anh cố tìm cách tạo ra đúng một coordinator đó.

6. Sự tách bạch sinh ra parallelization

Lý do Matt đưa ra (video đăng ngày 15/10/2026): khi có một agent chính để anh giao tiếp, điều đó lập tức tạo ra sự tách bạch, kể cả khi bên dưới chỉ có đúng một worker chung chung (generic worker). Cách Matt làm là bảo agent điều phối đó, producer của anh: "bạn không làm việc gì cả; bạn tìm ra việc gì cần làm, rồi tạo một sub-agent, một thread, hoặc thứ gì đó tương tự để làm việc đó". Bạn tìm ra việc đó cần được làm như thế nào, hoặc để agent kia tự làm.

Theo Matt (video đăng ngày 15/10/2026), đó là phiên bản đơn giản nhất của việc tạo một coordinator như vậy. Nó hữu ích vì anh có được một bên mà anh có thể trò chuyện, một bên hiểu hệ thống và hiểu điều gì đang diễn ra ở mọi thời điểm.

Theo Matt (video đăng ngày 15/10/2026), điều khác mà sự tách bạch này tạo ra rất, rất nhanh là parallelization. Matt lấy ví dụ: giả sử anh có một generic worker và một coordinator nói rằng "tôi muốn dùng generic worker để làm X, nhưng tôi cần làm X ba lần, theo ba cách khác nhau". Dù đó là việc gì, có thể ta muốn ba phiên bản của một thứ, hay muốn thử nhiều phiên bản hoặc nhiều loại sản phẩm khác nhau. Anh có thể dùng cùng generic worker đó ba lần, và vẫn có một coordinator ở trên báo cho anh: số một xong rồi, số ba xong rồi, ta vẫn đang chờ số hai, nó đã đi tới đoạn này của quy trình, anh có muốn tôi lái nó theo hướng nào đó không?

Matt nói (video đăng ngày 15/10/2026) có một bên tham gia như thế, ở đó để giao tiếp với bạn và hiểu một cách thông minh điều gì đang diễn ra bên trong cả hệ thống, là thứ rất có giá trị. Anh gọi đó là vàng, và nói anh không thể diễn tả hết tầm quan trọng của riêng điều đó.

7. Primitive 3: evals ở cả hai tầng

Matt tóm lại (video đăng ngày 15/10/2026): ta đã tách các role, phần đó khá thẳng và có vẻ hiển nhiên. Rồi ta có coordinator vừa được tách ra, producer của ta ở thời điểm này, về cơ bản là người bạn hiểu hệ thống và mọi bộ phận đang chuyển động, trong trường hợp này là tất cả các role khác nhau. Câu hỏi tiếp theo: làm sao đảm bảo công việc đang được làm đúng?

Đó là primitive thứ ba, và theo Matt (video đăng ngày 15/10/2026) nó là primitive cả trong AI thông thường lẫn trong agentic system: evaluations, hay evals. Tức là một kiểu giám khảo xem việc đã làm có được làm tốt hay không.

Matt lưu ý (video đăng ngày 15/10/2026) rằng đến đây ta có hai tầng. Một bên là tầng producer, hoặc có thể là cả hệ thống; bạn có thể coi cả hệ thống là một tầng. Bên trong nó, mỗi role là một tầng riêng, với trách nhiệm riêng. Theo Matt, evals thuộc về cả hai tầng.

Bạn có thể nói với producer: "tôi muốn bạn đánh giá xem mọi công việc trả về có đáp ứng đúng yêu cầu đã đi vào hay không". Matt nói đó là một kiểu evaluation khá tốt, vì theo mô tả của anh (video đăng ngày 15/10/2026) producer sẽ tạo ra một phiên bản khác của chính nó chỉ để làm eval đó, để chắc chắn thứ được yêu cầu và thứ trả về khớp nhau. Điều này rất có giá trị, vì không bộ phận độc lập nào bên dưới thật sự làm việc đó.

Ở tầng role, Matt (video đăng ngày 15/10/2026) lấy role xử lý yêu cầu làm ví dụ: agent đó biết cách viết các evaluation về việc xử lý yêu cầu. Bạn có thể dùng chính agent của mình để viết chúng, hoặc tự viết. Các câu hỏi kiểu: bạn đã đọc hết mọi thứ trong hàng đợi (queue) chưa? Bạn có chỉ đọc tối đa ba mục khỏi queue không? Đảm bảo không có mục nào bị trùng trong những thứ bạn đọc từ queue. Mục cuối cùng bạn xử lý có được xử lý đúng không? Đây là một số hướng dẫn về cách chúng ta xử lý các việc. Theo Matt, những thứ như thế là thứ bạn viết cho riêng một role.

Theo Matt (video đăng ngày 15/10/2026), các role độc lập này dĩ nhiên chỉ kiểm tra việc của riêng mình, rồi chuyển phản hồi lên coordinator, tức producer. Lúc đó producer có trách nhiệm ráp tất cả lại, làm phần tích hợp (integration), rồi kiểm tra xem toàn bộ có chạy hay không.

8. Bạn vốn đã viết evals, và khi evals thành luật cứng

Matt thừa nhận (video đăng ngày 15/10/2026) nghe thì có vẻ nhiều, nhưng thật ra nó cực kỳ đơn giản. Thật ra bạn đã đang làm evals rồi. Gần như mỗi lần bạn đưa vào một yêu cầu có chút phức tạp, bạn đều nói cho AI những thứ bạn không muốn nó làm: "khi làm XYZ, đảm bảo đừng để trống trường nào", "tôi không muốn có bản trùng nào trong này". Vì vậy, theo anh, việc này dễ hơn bạn nghĩ rất, rất nhiều; bạn chỉ cần viết chúng thành quy tắc rõ ràng (codify).

Matt đưa ra (video đăng ngày 15/10/2026) một lời cảnh báo về loại evals này: evals có thể biến thành luật cứng (hard rules) rất nhanh. Khi bạn bắt đầu làm việc trong hệ thống và nói "tôi cần một kiểu rule mới cho người, hay agent, xử lý các yêu cầu đi vào; hãy viết một rule ở bên đó nói rằng bạn không được làm X, Y, Z".

Theo Matt (video đăng ngày 15/10/2026), khi bạn bắt đầu viết những thứ này ra, chúng có thể trở thành những luật rất cứng và giới hạn khả năng của hệ thống. Vì vậy bạn nên thỉnh thoảng kiểm tra lại chúng. Hãy hỏi hệ thống: "cho tôi biết tất cả các rule mà ta đang cân bằng, hay các eval mà ta đang tuân theo, ở hệ thống bên kia". Theo Matt, kiểu việc đó sẽ thật sự cứu bạn. Anh nói chính anh có vài vết trầy đầu gối vì chuyện này gần đây, và muốn chuyển lại bài học đó cho người xem.

Rồi đến cái thứ tư. Matt nói còn một cái nữa, và thật ra thế là đủ. Ba primitive bạn vừa thấy sẽ cho bạn một hệ thống chung chung chạy cực kỳ tốt, theo anh (video đăng ngày 15/10/2026), cho tới khi bạn bắt đầu tinh chỉnh nó. Và việc tinh chỉnh ấy mới thật sự là công việc. Nhưng còn một primitive nữa rất có giá trị.

9. Primitive 4: state, giữ lại biên nhận

Matt nói (video đăng ngày 15/10/2026) thứ cuối cùng này, với anh, là một primitive, nhưng không nhất thiết phải thêm vào. Thật ra, nhiều hệ thống của anh không có primitive này. Nghĩa là không phải primitive nào cũng cần. Anh nói thêm: một số hệ thống của anh thậm chí không có evals. Nhưng đáng nói là với bất kỳ hệ thống nào anh biết là không có evals, hoặc không có evals viết ra thật chặt chẽ, thì anh là người chịu trách nhiệm kiểm tra mọi thứ. Như vậy anh vất vả hơn nhiều, vì phải tự kiểm tra mọi thứ mỗi lần. Trong những trường hợp đó, sẽ tốt hơn nếu anh vào và đặt evals phù hợp ở đúng chỗ.

Primitive tiếp theo này là state. State về cơ bản nghĩa là theo dõi điều gì đang xảy ra bên trong hệ thống. Theo Matt (video đăng ngày 15/10/2026), cách tốt nhất anh tìm ra để làm việc này, hay cách đơn giản nhất, là chỉ cần ghi ra một file.

Cách Matt thường làm, theo lời anh (video đăng ngày 15/10/2026): anh nói với producer của mình rằng mỗi lần tôi nhờ bạn làm gì, yêu cầu của tôi gửi cho bạn, tôi muốn bạn ghi nó vào một file như một request. Tôi muốn nó có ID riêng. Tôi muốn nó là duy nhất. Một file, ghi nó vào đó, để những gì tôi đã nói luôn được lưu lại. Sau đó, có lẽ bạn sẽ muốn giữ một trường status trong file để cho biết yêu cầu đã hoàn thành hay chưa, tức là một kiểu theo dõi trạng thái bên trong file đó.

Matt nói (video đăng ngày 15/10/2026) việc này có thể phức tạp hơn thế nhiều. Khái niệm ở đây là giờ đã có một kiểu biên nhận (receipts) cho những gì bạn đã nhờ hệ thống làm, và điều đó rất có ý nghĩa.

10. Một role nhỏ lo state, và chẩn đoán về sau

Theo Matt (video đăng ngày 15/10/2026), rất nhiều lần bạn sẽ bắt đầu với một hệ thống như vậy, để nó làm việc, rồi phải rời đi, hoặc hệ thống được cập nhật, hoặc bạn phải khởi động lại máy, hoặc đi đâu đó, và không thể quay về đúng trạng thái lúc trước. Những biên nhận đó, những file đó, trạng thái của những gì đang dở dang lúc ấy, sẽ cứu bạn. Bạn có thể quay lại với producer và nói: "tôi cần tiếp tục từ chỗ ta đang dừng". Nếu nó theo dõi đúng, những file đó sẽ cho nó biết chính xác nó đang ở đâu.

Matt nói thêm (video đăng ngày 15/10/2026) rằng anh thường có một role riêng để ghi các file state đó. Và thường đó là một model rất nhỏ mà anh dùng để ghi và quản lý các file này. Như vậy, một lần nữa, producer không làm việc đó. Producer tạo ra một role rồi gọi nó: "đây là một yêu cầu tôi vừa được giao, hãy làm việc của bạn". Rồi model rất đơn giản, nhỏ, nhanh đó có thể ghi file, cập nhật trạng thái khi cần, những việc như vậy.

Theo Matt (video đăng ngày 15/10/2026), đây là một pattern rất hữu ích khi có state liên tục như vậy. Nó không thật sự bắt buộc phải đưa vào hệ thống, nhưng nó rất, rất có giá trị.

Anh nói thêm: có những tài liệu state này, có lịch sử request này, sẽ khiến việc chẩn đoán về sau tốt hơn rất nhiều. Nếu bạn thấy mình đang nói "tôi đã bảo bạn chuyện này sáu lần rồi, tôi không hiểu chuyện gì đang xảy ra, có gì đó hỏng trong hệ thống", bạn có thể bảo agent của mình làm một lượt chẩn đoán (diagnostics) trên các request gần đây, xem có gì đã thay đổi ở hình dạng của chúng, hay đại loại như vậy. Và theo Matt (video đăng ngày 15/10/2026), nó có thể dễ dàng đi qua mọi thứ đã được yêu cầu và mọi thứ nó đã làm.

11. Để làm gì? Một người bạn hiểu cả hệ thống

Điều cuối cùng Matt muốn nói trong video đăng ngày 15/10/2026 là: tại sao, tại sao lại làm việc này? Toàn bộ chuyện ghép tất cả những thứ này lại để làm gì?

Trước hết, Matt (video đăng ngày 15/10/2026) nói đáng nhấn mạnh rằng việc này cực kỳ, cực kỳ đơn giản. Điều anh đang nói chỉ là bảo hệ thống của bạn một điều gì đó như: khi tôi nói chuyện với bạn, tôi muốn nói chuyện với một agent điều phối. Tôi muốn agent điều phối đó không làm việc gì cả. Tôi muốn nó chuyển việc tới các role phù hợp. Tôi muốn viết ra hai role mà tôi có cho hệ thống này, bao quát loại công việc ta làm, vân vân. Và thế là bạn có một hệ thống. Theo Matt, đó là tất cả những gì bạn phải làm để tạo một hệ thống, và giờ bạn ở vị trí có thể nhận được một số giá trị từ nó.

Vậy những giá trị đó là gì? Matt nói (video đăng ngày 15/10/2026) có nhiều thứ. Thứ nhất, khía cạnh anh thích nhất, thật lòng, thứ thay đổi nhiều nhất, là nó cho anh một người bạn đồng hành để trò chuyện. Có một partner biết toàn bộ hệ thống. Và nếu bạn đã làm phần state, nó còn biết mọi thứ đã được yêu cầu.

Theo Matt (video đăng ngày 15/10/2026), bạn có thể mở ba, năm hay mười producer nếu cần, và nói chuyện với từng cái để làm một việc cụ thể. Nhưng vì tất cả đều ghi file state, producer thứ mười một mà bạn mở lên và nói "tôi muốn nói về chuyện gì đang diễn ra lúc này, cái gì đang chạy, cái gì bị trễ, sao mọi thứ lâu thế" thì nó thật sự có thể nhìn quanh và tự tìm ra: được rồi, để tôi xem chuyện gì đang xảy ra.

Nó cũng có thể đi xem các thread khác có vẻ đang chạy, vì những request này có vẻ đang dở dang (in flight). Chắc hẳn có những thread khác quanh đây đang làm việc, hoặc đây là các thread "zombie", chúng bị kẹt và tôi cần làm gì đó với chúng. (Theo Matt, video đăng ngày 15/10/2026.)

12. Hyper-tunability: các nút vặn (dials)

Có một người bạn đồng hành như vậy, theo Matt (video đăng ngày 15/10/2026), nghĩa là thay vì chỉ nhờ nó làm việc, bạn có thể đánh giá cùng nó, có những cuộc trò chuyện về chính hệ thống. Ví dụ: tại sao phía này của hệ thống luôn mất nhiều thời gian, còn phía kia thì rất nhanh? Ta có đang dùng các cơ chế parallel thường xuyên như lẽ ra nên dùng không, vân vân. Matt nói có một partner giao tiếp như vậy, luôn sẵn sàng, là thứ rất, rất hữu ích. Với anh, đó có lẽ là lý do số một khiến anh thích những hệ thống này.

Điều đó dẫn tới một thứ khác Matt rất thích (video đăng ngày 15/10/2026) ở các hệ thống này: tính hyper-tunability, khả năng tinh chỉnh tới mức rất chi tiết. Bỗng nhiên bạn có thể làm cho hệ thống chạy đúng theo cách bạn muốn làm việc. Giờ bạn kiểm soát việc một phần nào đó chạy nhanh tới đâu, khi nào một việc bị hoãn lại, việc nào cần chạy theo lịch (schedule) thay vì chạy khi bạn yêu cầu, hay bạn xử lý các yêu cầu thế nào: chúng vào một queue, hay được thực thi ngay? Có đủ loại thứ bạn giờ có thể thay đổi, thay vì nói chuyện với một agent duy nhất mà việc của nó, về cơ bản, là thực thi ngay lập tức.

Theo Matt (video đăng ngày 15/10/2026), giờ bạn đang nói chuyện với một hệ thống, và hệ thống đó do bạn thiết kế để chạy theo cách bạn muốn. Như đã nói trước đó, tất cả sự tách bạch ta đã tạo ra sinh ra thứ mà Matt gọi là dials, các nút vặn. Giờ bạn có các nút vặn để xoay, để tìm cách tinh chỉnh hệ thống theo ý mình.

Matt đưa một ví dụ đơn giản. Nhờ sự tách bạch đã nói, hãy hình dung ta có một agent biết cách nhận các yêu cầu đi vào. Nó đi đọc email, đọc Twitter, đọc bất cứ thứ gì nó cần đọc để lấy các yêu cầu đi vào. Ta nghĩ: được rồi, hệ thống đó cần chạy mỗi năm phút. Đó là một nút vặn. Hãy đặt nó lên một schedule để ta không phải nhờ nó chạy nữa; nó tự làm việc của mình mỗi năm phút. Matt nói như thế là tuyệt, dễ làm, và theo anh (video đăng ngày 15/10/2026) bạn đã làm được điều này rồi: hãy hỏi agent của bạn cách làm.

Nút vặn tiếp theo trong ví dụ của Matt (video đăng ngày 15/10/2026): việc đó khá dễ, mà nó lại chạy rất thường xuyên. Vậy để tôi đặt nó lên một model nhỏ hơn, hoặc mức reasoning thấp hơn, đặt nó lên thứ gì đó có cảm giác nhỏ hơn nhiều, rồi đánh giá xem cách đó có chạy được không. Có thể tôi chạy cả model lớn lẫn model nhỏ một thời gian và so sánh output. Theo Matt, nếu kết quả bằng nhau trong một khoảng đủ dài, anh chỉ việc chọn cái thấp hơn.

13. Role thử nghiệm, rate limit và máy chạy test riêng

Matt nói (video đăng ngày 15/10/2026) có khi anh còn tạo một kiểu role thử nghiệm (experimentation role), biết cách quản lý thí nghiệm đó cho anh, và biết khi nào nên chốt: từ giờ ta chỉ dùng model thấp, hay ta sẽ tiếp tục chỉ dùng model cao vì có khác biệt. Theo anh, bạn không cần biết hết tất cả các bộ phận chuyển động này, và đó chính là mấu chốt. Bạn làm việc với producer của mình để hoàn thành những việc mà có thể bạn không biết cách làm, thậm chí không biết cách yêu cầu. Matt nói đó là lý do bạn đang có thêm một partner, và điều này thật sự quan trọng.

Theo Matt (video đăng ngày 15/10/2026), những nút vặn này rất có ý nghĩa. Có thể nói "tôi muốn role này chạy trên model cao hơn role kia" là thứ rất có giá trị. Có thể nói "role này không được chạy parallel; nó luôn phải chạy sequential, vì tôi có một rate limit ở đâu đó và bạn sẽ làm nổ rate limit của tôi" cũng rất, rất có giá trị. Và hiển nhiên bạn cũng có thể nói với một role khác: hãy chạy parallel thật nhiều, bất cứ khi nào có việc, hãy bật thêm một phiên bản nữa của cùng agent đó và làm việc đó; ta chấp nhận được, phần này đã được làm chắc chắn (hardened). Theo Matt, chỉ riêng sự tách bạch đã cho bạn rất nhiều nút vặn.

Matt nhấn mạnh (video đăng ngày 15/10/2026) đó là mấu chốt. Thật lòng mà nói, sự tách bạch gần như là toàn bộ "nước sốt" mà bạn đang hướng tới ở đây. Nhưng có những thứ khác bạn có thể làm, ít hiển nhiên hơn. Matt kể có những phần trong một hệ thống của anh thật sự chạy job trên phần cứng bên ngoài. Anh có một chỗ khác nơi một số bài test chạy, vì chúng mất nhiều thời gian. Bạn có thể nói: "mỗi khi tôi chạy cái này, tôi muốn nó chạy trên một máy khác".

Theo cách Matt mô tả (video đăng ngày 15/10/2026), bạn đặt rule cho đúng role đó: khoan, khi ta làm X, Y, Z, đây là cái máy đó, đây là cách vào nó, đây là cách kiểm tra xem nó có đang quá tải việc không. Matt nói thật ra, anh hy vọng mình đang giao tiếp việc đó với một hệ thống riêng của nó, ở bên kia, đang quản lý luồng việc đi vào và queue của chính nó. Như vậy anh có thể chỉ việc gửi một trách nhiệm sang một hệ thống khác.

Theo Matt (video đăng ngày 15/10/2026), hệ thống nói chuyện với hệ thống (system to system) lại là một tầng nữa, và nó thật sự quan trọng: đó là lúc mọi thứ bắt đầu biến thành một đồ thị các hệ thống (graph of systems), và điều đó trở nên cực kỳ mạnh mẽ.

14. Những primitive sẽ còn đứng vững

Matt nói (video đăng ngày 15/10/2026): được rồi, thế là khá nhiều. Anh cảm ơn bạn đã xem tới đây. Nếu bạn đã xem tới đây, thì tất cả những gì ta vừa đi qua chỉ là vài khái niệm cơ bản sẽ chạy được bên trong bất kỳ agentic system nào bạn gặp.

Theo Matt (video đăng ngày 15/10/2026), tất cả những khái niệm này đều có mặt trong ChatGPT, trong Claude Code, trong Codex: tất cả những hệ thống thật sự là agentic system, và là agentic system rất phức tạp, đều dùng chính các nguyên tắc này. Chúng còn có những nguyên tắc khác nữa, nhưng theo anh đây là những primitive nền tảng mà anh có thể nói là có lẽ sẽ cứng lại (harden) trong mọi agentic system ta xây, trong một thời gian rất, rất dài. (Phần mô tả của video đăng ngày 15/10/2026 nói cụ thể hơn: các ý này có trong Claude Code, Codex và chế độ Work mode của ChatGPT.)

Matt cũng nghĩ (video đăng ngày 15/10/2026) các công cụ sẽ ngày càng tốt hơn và bắt đầu thay thế một phần những thứ này. Nhưng cho tới khi chúng thật sự cho phép mọi độ linh hoạt mà bạn có thể muốn trong hệ thống của riêng mình, bản thân anh sẽ tiếp tục tự xây hệ thống của mình, vì theo anh chúng đơn giản tới mức đó. Và điều đó tạo ra một thứ dễ sao chép, dễ nhận ra vấn đề và dễ chẩn đoán bên trong. Matt gọi đó là một hệ thống rất có giá trị.

Matt hy vọng (video đăng ngày 15/10/2026) những gì vừa nói đã cho bạn thấy đôi chút về cách khởi động một agentic system, hay những khái niệm giải thích vì sao chúng tồn tại. Anh nói anh thấy chúng rất cuốn hút, và cũng thấy chúng cực kỳ hữu ích.

Anh kể mình đã làm việc với chuyện này khoảng sáu tháng, tính tới lúc video đăng (15/10/2026), từ hồi các model còn chưa đủ tốt để làm việc này. Hồi đó, khi anh làm việc này, suốt quá trình là một cuộc vật lộn. Tất cả những gì anh làm là vật lộn. Nó đổ sập liên tục, không làm theo hướng dẫn, dừng giữa chừng khi đang làm theo hướng dẫn. Theo Matt (video đăng ngày 15/10/2026), chuyện đó đã chấm dứt: các model đã trở nên rất tốt, các framework ta đang làm việc trong đó rất mạnh, các harness rất tuyệt. Vì vậy, theo anh tính đến lúc video đăng, điều đó không còn là vấn đề nữa, và mọi thứ đã hoàn toàn sẵn sàng để bạn làm tất cả những loại việc này.

15. Tham vọng lớn, nhưng bắt đầu nhỏ

Lời khuyên của Matt (video đăng ngày 15/10/2026): hãy tham vọng hết mức bạn từng muốn, và bắt đầu xây một hệ thống lớn, nhưng đừng bắt đầu lớn. Hãy bắt đầu đơn giản.

Hãy tạo producer đó, thứ duy nhất tách "anh ta" khỏi phần việc. Rồi sau đó: à, tôi có hai role trong này. Hoặc có thể tôi đã có hai hay ba dự án code, và mỗi dự án làm một phần nhỏ của vấn đề lớn hơn của tôi. Theo Matt, khi đó chúng trở thành agentic system của bạn; nó không nhất thiết phải nằm trong một folder. Có rất nhiều cách để chia nhỏ việc này, và theo anh (video đăng ngày 15/10/2026), các hệ thống này hoàn toàn có khả năng làm điều đó.

Matt nói (video đăng ngày 15/10/2026) anh biết mình đang rất hào hứng về chuyện này, nhưng với anh đây thật sự là bước tiếp theo. Nếu bạn chưa đầu tư vào những thứ kiểu này, theo anh bạn hoàn toàn cần chuyển sang hướng này, vì anh cho rằng đây chắc chắn là tương lai của việc làm thật với AI. Anh hy vọng bạn đã thấy điều gì đó mình thích, và cảm ơn mọi người đã đồng hành cùng anh trong video này.