Graph engineering: khi agent không còn cần người prompt

1. "Graph engineering" là gì, và vì sao ai cũng rối

Jason Zhou mở đầu bằng chủ đề đang nóng: graph engineering. Nếu bạn dùng Twitter (X), có lẽ vài tuần qua bạn đã khá bối rối, vì đây là một thuật ngữ mới bỗng xuất hiện ở khắp nơi trên internet. Và càng đọc, có lẽ bạn càng thấy rối hơn, vì người ta đang trộn nhiều thứ khác nhau, nhiều loại "graph" khác nhau, vào cùng một cuộc thảo luận. Trong video này, anh muốn tách bạch ra xem có những điều thực tế nào bạn có thể mang về và bắt đầu áp dụng thật.

Mọi chuyện bắt đầu từ một tweet của Peter Steinberger (đăng ngày 17/07/2026): "Are we still talking loops or did we shift to graphs yet?" (chúng ta vẫn đang nói về loop, hay đã chuyển sang graph rồi?). Không ai thực sự hiểu ý anh ấy khi nói "graph", vì graph có thể mang quá nhiều nghĩa. Đó là lúc cuộc thảo luận trở nên rối thật sự: người ta dùng chữ graph để nói về ba khái niệm hoàn toàn khác nhau.

Nghĩa thứ nhất là control graph. Hãy nghĩ tới LangGraph, hay dynamic workflow. Về cơ bản, hầu hết các tác vụ agentic đều có một dạng SOP (quy trình chuẩn) nào đó đằng sau. Control graph, dù là LangGraph, dynamic workflow gần đây, hay thậm chí chỉ là một SOP bạn viết bằng chữ, đều là những cách để đảm bảo agent cho ra kết quả đáng tin cậy hơn.

Jason nghĩ đây chính là loại graph mà Peter đang nói tới. Lý do: trong một tweet gần đây của Peter, use case anh ấy mô tả về cơ bản là một SOP dạng control flow cho việc ship một thay đổi vào codebase. Vậy đó là control flow.

2. Knowledge graph và graph of loops: hai chuyện khác

Loại graph thứ hai người ta nhắc tới là knowledge graph. Theo Jason, đây là một khái niệm hoàn toàn khác và không liên quan. Chỉ vì Andrew Ng tình cờ ra một khoá học dài một tiếng về xây dựng agentic knowledge graph đúng lúc đó, nên người ta bằng cách nào đó nối hai chuyện lại với nhau.

Knowledge graph là một chuyện khác hẳn. Về cơ bản, graph là một cách rất tốt để biểu diễn quan hệ giữa các entity khác nhau, nhờ đó khi cần truy xuất dữ liệu, bạn lấy được thông tin một cách hiệu quả. Đó là lý do mảng retrieval, từ GraphRAG tới các hệ thống agent memory, đã dùng graph từ nhiều năm nay. Nhưng đó là một chủ đề hoàn toàn khác.

Chủ đề thứ ba mà người ta bắt đầu bàn tới, và Jason thấy rất thú vị, gọi là graph of loops. Khái niệm này do Carlos E. Perez đưa ra, trong bài viết "From Loop Engineering to Graph Engineering?". Câu hỏi là: nếu giả sử công ty của tương lai được vận hành bởi một loạt loop khác nhau, làm sao bạn đảm bảo tất cả các loop đó thực sự chạy tốt và cải thiện liên tục? Chỉ một loop thôi đã khó rồi, và khi có nhiều loop, cả lỗi lẫn cải tiến đều có thể cộng dồn (compound) rất nhanh.

Đây vẫn là một vùng rất mới và chưa ai khám phá nhiều. Thật lòng mà nói, chưa có câu trả lời thực sự cho chuyện giải nó thế nào, vì một lần nữa, đa số các team còn chưa dựng thành công nổi một hay hai loop.

Nhưng team của Jason đã thử nghiệm với loop trong hai tháng qua (tính tới lúc video đăng, 25/08/2026), và họ đã làm một số thí nghiệm mà anh đã viết vào một bài viết trước đó, bạn có thể đọc nếu muốn đào sâu. Tóm lại, đó là ba chủ đề khác nhau mà người ta đang trộn lẫn trên internet khi nói về graph engineering. Còn thứ Peter thực sự muốn nói, theo Jason, là ý tưởng control graph.

Và xét theo chỗ mà phần lớn các công ty đang đứng, Jason cho rằng ý tưởng control graph có rất nhiều giá trị thực tế. Anh lưu ý rằng mọi thứ anh sắp trình bày đều chạy trên các harness hiện đại như Claude Code hay Codex.

3. Từ người prompt agent sang thứ khác prompt agent: loop

Quay lại control graph. Như đã nói, mỗi loại tác vụ thường có một dạng SOP nhất định đằng sau. Và người ta ngày càng cần kết quả đáng tin cậy hơn từ agent.

Động lực chính đằng sau nhu cầu đó, theo Jason, là sự chuyển dịch lớn nhất chúng ta đang trải qua với agent: các team đang chuyển từ chỗ con người prompt agent sang chỗ một thứ khác prompt agent thay mặt con người. Trên bảng anh viết: "Need for reliability increased", với mũi tên từ "You (Human) prompt" sang "Agent/Trigger prompt".

Ví dụ, có hai pattern mà một số công ty AI-native nhất thế giới đang áp dụng và thử nghiệm lúc này. Pattern thứ nhất là loop. Rất nhiều người đã nói về loop, kể cả chính Jason. Ý tưởng cơ bản: thay vì bạn, một con người, prompt agent cho từng tác vụ một, bạn có thể dựng một trigger để prompt agent.

Trigger có thể dựa trên thời gian (time-based), chẳng hạn mỗi ngày đi kéo GitHub issue mới nhất về và sửa nó. Hoặc có thể dựa trên mục tiêu (goal-based), chẳng hạn liên tục tối ưu frontend cho tới khi hiệu năng tăng 200%. Hoặc cũng có thể dựa trên sự kiện (event-based): mỗi khi có một email tới, bạn đánh thức agent dậy để làm việc.

Trong pattern này, con người chỉ tham gia khi agent nghĩ là cần thiết. Thực ra, một trong những điều quan trọng nhất với mỗi loop là định nghĩa những loại việc nào agent tự làm được, và những việc nào thực sự cần có con người tham gia. Đó là pattern đầu tiên các công ty đang thử để khai thác agent được nhiều hơn.

4. Pattern orchestrator: agent prompt agent

Pattern thứ hai đang diễn ra là orchestrator. Nghĩa là bạn, người dùng, không còn nói chuyện với từng agent riêng lẻ để nhờ nó làm việc gì đó. Thay vào đó, bạn nói chuyện với một orchestrator agent, một agent có đầy đủ context về mọi thứ đang diễn ra, và nó có thể dựng lên cả một team agent để thực thi phần việc thật, đồng thời giám sát trong suốt quá trình.

Trong một video, Boris Cherny, người tạo ra Claude Code, cũng nói rằng ngày nay ông chủ yếu nói chuyện với một Claude, và Claude đó nói chuyện với các Claude khác, thay vì ông trực tiếp prompt agent làm phần việc thật. Jason chiếu một đoạn trong video đó, nơi Boris nói đại ý: đây là chỗ agent đang prompt agent; tôi không nói chuyện với agent nữa, agent của tôi nói chuyện với các agent khác, và vì thế bạn có những "tổ chức" lớn gồm agent đang làm việc. Ông kể rằng ngày nay, ở bất kỳ thời điểm nào, ông cũng có tối thiểu vài agent đang chạy. Thường thì qua đêm, ông chạy vài nghìn agent để làm một việc phức tạp nào đó. Điều này, theo Boris, còn không khả thi ngay cả ba tháng trước.

Như Jason đã nói, cả hai pattern này đều đang được một số công ty AI-native nhất thử nghiệm rất mạnh, và team của anh cũng đã thử trong hai tháng qua. Điều anh thật sự nhận ra là: cả hai pattern đều đặt bạn, con người, ở một tầng phía trên phần việc thực tế. Bạn không còn phải "trông trẻ" (babysit) qua từng bước và từng checkpoint của executor agent nữa.

5. Reliability, verifier và ba thành phần của control graph

Chính vì thế, reliability trở nên rất quan trọng để bạn có đủ tự tin áp dụng những pattern đó. Đây là điều Jason đã nói rất nhiều: ít nhất bạn phải dựng một verifier trong codebase, để có thêm tự tin vào thứ agent đang ship. Anh đã đưa các skill dựng verifier vào repo GitHub để mọi người lấy về dùng (xem phần cuối trang).

Nhưng verifier mới chỉ là một phần nhỏ của guardrail. Với mỗi loại quy trình nghiệp vụ khác nhau mà bạn muốn agent tự động hoá, thường sẽ có những guardrail và SOP khác nhau có thể "tiêm" vào. Và đó là lúc control graph trở nên thú vị.

Đây không phải khái niệm mới. Tự động hoá workflow dựa trên graph đã tồn tại hàng chục năm. Nó thường có ba thành phần chính:

• Node: hành động (action) mà nó sẽ thực hiện.
• Edge: về cơ bản là điều gì xảy ra tiếp theo sau mỗi node (flow).
• State: dữ liệu (data) nào sẽ được mang theo qua từng node, từng bước.

Dù khái niệm control graph không mới, cái mới là ý nghĩa của một node. Trong tự động hoá workflow truyền thống, mỗi node là một hành động đơn giản, cơ bản, như chạy một script hay làm một phép kiểm tra điều kiện. Rồi sau đó, khoảng ba năm trước, các nền tảng như n8n cho phép thêm một LLM làm một node, để nó xử lý được nhiều use case "đuôi dài" (long tail) hơn. Và gần đây nhất, một node có thể là cả một agent, có khả năng làm rất nhiều thứ khác nhau.

6. Graph bạn đã dùng: tính năng goal

Jason cho rằng có lẽ bạn đã khá quen với graph rồi, vì bạn đã đang dùng nó. Ví dụ, tính năng goal của Claude Code hay Codex có thể biểu diễn thành một graph như sau.

Ở lõi, nó là một graph: nhận prompt từ người dùng, prompt chạy qua agent loop, và khi Claude Code hay Codex làm xong, nó gọi một LLM để phân loại xem goal đã thoả mãn chưa. Nếu thoả mãn thì kết thúc. Nếu chưa thì gửi một tin nhắn mới trở lại cho agent. Graph này được hiện thực bằng agent loop cộng với hệ thống stop hook.

7. Autoresearch của Andrej Karpathy cũng là một graph

Tương tự, dự án nổi tiếng autoresearch của Andrej Karpathy cũng là một graph. Nếu bạn không nhớ dự án này: về cơ bản, Karpathy đặt agent vào một vòng lặp for để liên tục cải thiện hệ thống LLM. Jason chiếu tweet của Karpathy, kể rằng ông để autoresearch tinh chỉnh nanochat khoảng hai ngày, nó tìm được khoảng 20 thay đổi giúp cải thiện validation loss, kèm biểu đồ các thí nghiệm.

Cách setup đơn giản tới bất ngờ. Nó cũng bắt đầu bằng một prompt, nhưng prompt này được ghi trong một file program.md, mô tả toàn bộ quy trình. Về cơ bản, nó hướng dẫn agent sửa file train.py, tức chính script phần mềm, bằng một ý tưởng thí nghiệm, rồi chạy thí nghiệm và đánh giá kết quả. Nếu kết quả tốt thì giữ thay đổi. Nếu không thì bỏ đi và thử một ý tưởng mới.

Trên trang GitHub của dự án, phần "The experiment loop" trong program.md ghi rõ các bước dưới tiêu đề "LOOP FOREVER": xem trạng thái git, sửa train.py với một ý tưởng thí nghiệm, commit, chạy thí nghiệm, đọc kết quả, ghi kết quả vào file tsv, rồi giữ hoặc reset tuỳ chỉ số có cải thiện không.

Về bản chất, đây là một loop có thể biểu diễn bằng đúng graph này. Mỗi lần, nó nhận file program.md để biết quy trình và thử một ý tưởng mới. Khi xong, nó làm một bước kiểm tra chỉ số (metric check): có tốt hơn không? Nếu có thì commit và đẩy thay đổi. Nếu không thì bỏ và revert. Rồi thử ý tưởng tiếp theo.

State ở đây về cơ bản gồm hai thứ. Một là train.py, phần mềm mà nó đang sửa. Hai là results.tsv, file ghi lại mọi thứ đã từng thử.

Điều thú vị bạn sẽ thấy ở đây: đây là một graph đạt được chỉ bằng cách prompt agent. Nó không dùng cơ chế gì cầu kỳ. Hồi đó, nó thậm chí còn chưa có các cơ chế loop dựng sẵn hay tính năng goal. Nó chỉ đơn giản bảo agent: hãy lặp lại quy trình này mãi mãi. Và agent cứ thế làm.

Đây là phần thú vị mà Jason sẽ nói kỹ hơn, vì việc hiện thực một graph không nhất thiết phải là code. Thực ra, nó có thể chỉ là một SOP được ghi lại, cộng với một loạt script định sẵn và các ranh giới (boundary).

8. Deep research, và hai cách enforce một graph

Một ví dụ khác là deep research. Nếu bạn từng build agent, chắc bạn khá quen với pattern này: khi xây một research agent, pattern phổ biến là nó nhận một prompt, chuyển tới một architect (orchestrator) để lên kế hoạch các chủ đề cần bao phủ, rồi "fan out" ra một loạt sub-agent để nghiên cứu từng chủ đề riêng.

Khi xong, nó "fan in" để review: đã đủ thông tin để đưa vào báo cáo chưa? Nếu chưa thì quay lại bước trước. Nếu rồi thì kết thúc và tạo báo cáo. Và một lần nữa, đây là một graph.

Sau khi đi qua những ví dụ này, Jason hy vọng bạn nhận ra một điều: có nhiều cách để thực sự enforce (ép chạy đúng) một graph.

Cách thứ nhất là cách truyền thống, code-as-graph. Có những thứ như dynamic workflow của Claude Code, code mode của Codex, cũng như LangGraph mà bạn có thể dùng để dựng kiểu workflow dạng graph này. Nó rất hữu ích.

Nhưng mặt khác, rất nhiều khi bạn chỉ cần dùng chính LLM làm graph, LLM-as-graph, và nhiều người trong số các bạn có lẽ đã đang làm vậy. Bạn chỉ cần đưa vào một SOP, có thể là chữ, hoặc JSON, hoặc Mermaid chart, gì cũng được. Model hiện đại đã đủ giỏi để hiểu những SOP workflow đó và làm theo đến cùng.

Vì vậy, nhiều khi bạn có thể chỉ mô tả SOP mình thiết kế bằng chữ, biến nó thành một skill mà agent có thể gọi lên làm context, rồi agent sẽ chạy graph khá tốt, giống hệt autoresearch của Andrej Karpathy.

9. LLM-as-graph: SOP trong skill cộng primitive của harness

Trên bảng, Jason vẽ phần "2. LLM-as-graph" là một khung skill chứa một mục #SOP viết theo cú pháp state diagram, mỗi dòng là một edge có điều kiện: SOP đi từ Scan sang Fix, Verify, Commit; Verify quay lại Fix khi chưa giải quyết xong và còn dưới 3 vòng, và dừng khi đã hết cách hoặc không kiểm được.

#SOP
[*] --> Scan
Scan --> Fix: proceed
Scan --> [*]: preflight failed
Fix --> Verify
Verify --> Fix: unresolved & round < 3
Verify --> Commit: allClear & nothing unverifiable
Verify --> [*]: exhausted / unverifiable
Commit --> [*]

Harness hiện đại cũng đã cung cấp sẵn rất nhiều primitive. Bên dưới khung skill, Jason liệt kê ba thứ và công dụng của từng thứ:

• bash: các coding agent này chạy được bash, nghĩa là nó chạy được một script định sẵn do bạn viết, cho những hành vi và bước mang tính tất định (deterministic).
• Sub-agent / agent teams: có sub-agent và giao thức giao tiếp giữa các agent trong một team, nghĩa là một orchestrator agent chính có thể chia SOP thành từng bước và đánh thức một team sub-agent.
• Hook (như /goal): nếu thật sự muốn, bạn có thể dùng hook để tiêm những checkpoint tất định thật sự vào runtime của agent. Cách tính năng goal được hiện thực là một ví dụ rất hay.

Cả hai phương pháp đều có giá trị thực tế, và Jason sẽ nói qua từng cái. Nhưng với cơ chế LLM-as-graph, có thể nó trông rất cơ bản và đơn giản: về cơ bản bạn chỉ đưa cho nó một prompt. Dù vậy, có một số design pattern mà anh thấy khá hữu ích và quan trọng để đảm bảo SOP thực sự được agent làm theo.

10. Design pattern 1 và 2: tách agent node, dùng code khi hợp lý

Pattern thứ nhất: biết khi nào nên tách agent node riêng. Về mặt kỹ thuật, bạn có thể dồn toàn bộ SOP vào chỉ một agent. Và khi model ngày càng tốt hơn, nhiều khả năng một agent sẽ làm xong được cả việc. Nhưng cũng quan trọng là hiểu giới hạn của model, để đảm bảo bạn có hiệu năng tốt nhất.

Ví dụ, một LLM, dù mạnh tới đâu, cũng không giỏi lắm trong việc tự kiểm tra (self-verify) công việc của chính nó. Đó là lý do verifier thường là một agent node riêng. Thêm nữa, dựa trên nghiên cứu từ OpenAI và Anthropic, với các tác vụ phức tạp thường cần một planner agent chuyên trách, chỉ tập trung vào nghiên cứu, suy luận và nghĩ kỹ mọi thứ.

Mặt khác, bạn có lẽ cũng nên nghĩ xem những việc nào có thể chạy song song, và những việc nào có thể giao cho model mạnh hơn hoặc yếu hơn. Đó đều là những điều bạn có thể cân nhắc khi lên kế hoạch xem những node và bước nào thực sự nên tồn tại.

Pattern thứ hai: cố dùng code khi hợp lý. Đây là một cách rất tốt để tăng reliability, đồng thời giúp agent làm nhanh hơn và mắc ít lỗi không cần thiết hơn. Những tình huống phổ biến mà Jason nghĩ thực sự nên dùng code:

• Data fetching phức tạp: thay vì bắt agent gọi nhiều API khác nhau rồi tự ghép dữ liệu, bạn có thể viết script cho những thao tác lấy và xử lý dữ liệu phức tạp nhưng lặp lại thường xuyên.
• Dev local: bạn có lẽ nên có script để chỉ việc dựng dev server lên chạy, để agent không phải vật lộn với nó.
• Eval và test: khả năng đánh giá kết quả hay chạy end-to-end test.

11. Design pattern 3 và 4: input/output và state, rồi quy trình

Pattern thứ ba: khi có một agent node, bạn thường muốn định nghĩa rõ input và output của agent đó. Vì bạn muốn ranh giới và kỳ vọng về output của mỗi node phải thật rõ ràng.

Pattern thứ tư là state. Dù bạn dùng LLM-as-graph hay code-as-graph, bạn cần một cách để các agent khác nhau nắm được trạng thái hiện tại của công việc thật nhanh. Trên bảng, Jason ghi: "State (Assemble context for each run)", tức gom context cho mỗi lần chạy. Có nhiều cách để làm. Cách dễ nhất là chỉ cần một file markdown ghi lại trạng thái mới nhất (latest state), cùng với một log chỉ-ghi-thêm (append-only) từ mỗi agent hoặc mỗi lần chạy.

Có lẽ còn nhiều thứ nữa, và Jason mời mọi người cho anh biết nếu anh bỏ sót điều gì.

Nhưng nhìn chung, quy trình là thế này. Với bất kỳ tác vụ nào bạn muốn agent lặp lại hoặc làm một cách đáng tin cậy, về cơ bản bạn chỉ cần vẽ ra SOP, nghĩ qua tất cả các bước. Sau đó, bạn bắt đầu gom các thứ lại thành những node và edge khác nhau, theo các design pattern vừa nói. Và cuối cùng, bạn cần định nghĩa một tài liệu artifact để ghi lại state.

Jason nghĩ quy trình này áp dụng cho cả code-as-graph lẫn LLM-as-graph. Khác biệt duy nhất là output. Với cách LLM-as-graph, output có thể đơn giản là một skill, được đánh thức bởi mỗi lần chạy loop hoặc gọi tuỳ lúc (ad hoc). Còn với code-as-graph, output sẽ là một file JavaScript có thể chạy được.

12. Repo superdesign agi: nơi agent biết mọi chuyện của công ty

Giờ tới ví dụ thật. Jason muốn cho xem team anh đang áp dụng hai pattern đã nói ra sao, rồi mỗi phương pháp một ví dụ về cách họ chưng cất graph cho một loại tác vụ cụ thể.

Nhiều người có lẽ biết team anh đã build Superdesign, một nền tảng "vibe design" cho phép người ta thiết kế giao diện người dùng. Họ đang chạy nhiều loop khác nhau trên khắp mảng kinh doanh này. Cách họ làm là có một repo riêng, gọi là superdesign agi.

Repo này được dùng làm nơi theo dõi state và knowledge base cho mọi thứ đang diễn ra trong công ty. Ngày nay, khi Jason muốn sửa gì đó trong codebase, thay vì vào repo thật là nền tảng Superdesign, phần lớn thời gian anh khởi động agent ngay trong repo này. Nó có context về mọi thứ từng xảy ra với Superdesign: mọi sự cố (incident) họ từng xử lý, mọi support ticket từng giải quyết, hay mọi engineering ticket đã ship.

Phía dưới trông hơi lộn xộn, nhưng đó đại loại là kho artifact của họ. Phía trên, repo có một loạt skill, và vài skill trong đó là những graph nhỏ họ dựng bằng skill.

13. Ví dụ LLM-as-graph: skill daily bad design triage

Một ví dụ là skill daily bad design triage. Mục tiêu: mỗi ngày có rất nhiều người dùng tạo design trên nền tảng, và họ muốn bắt được những design tệ mà agent đã làm ra, hoặc những lời phàn nàn của người dùng, để liên tục thu thập một bộ dữ liệu dùng cho việc cải thiện agent.

Vì thế họ build một loop để review toàn bộ design người dùng tạo ra mỗi ngày, chọn ra những cái trông tệ hoặc không đáp ứng kỳ vọng của người dùng, rồi thêm vào một danh sách để team review và đưa vào bộ eval dataset.

SOP, hay graph, họ dựng cho quy trình này đại loại như sau. Mỗi ngày một lần, họ muốn agent lọc ra những design có thể là tệ. Họ có một danh sách các chỉ báo heuristic, để agent kéo dữ liệu thô từ database về thành danh sách ứng viên design tệ. Nếu không có kết quả nào thì kết thúc lượt chạy.

Còn nếu hôm đó có những design có thể là tệ, nó sẽ đi qua quy trình graph. Trước hết, họ tạo một script giúp làm lộ ra những vấn đề có thể đánh giá bằng heuristic: chẳng hạn có lỗi nào không, design có vỡ hoàn toàn không, có không responsive không, thậm chí có script không parse được không. Với những vấn đề đó, nó chạy thẳng qua script và thêm vào danh sách.

Còn với các design khác, họ dựng lên một loạt sub-agent. Mỗi agent xử lý một phần việc: chụp ảnh màn hình design, so với yêu cầu thật của người dùng, đánh giá và trả ra kết quả. Với tất cả thông tin đã gom được, agent sẽ xếp hạng các design tệ và đăng lên danh sách của ngày hôm đó, nằm ngay trong repo này, để team có cái nhìn tổng quan. Từ đó họ có thể thêm vào bộ evaluation, hoặc dựng thêm một nhóm agent khác, mỗi agent cho một vấn đề, để cải thiện chính agent của sản phẩm.

Với graph này, cách họ enforce là một skill. Về cơ bản, họ build một skill, kèm theo vài script họ viết để agent dùng cho những bước tất định. Trong skill, họ ghi lại quy trình (procedure): nó nói agent nên chạy script nào để lấy danh sách ứng viên design tệ, rồi hướng dẫn agent chạy một số script tất định để làm vài phép kiểm tra bằng code, làm lộ vấn đề từ sớm. Sau đó fan out ra một loạt agent làm "vision LLM judge", mỗi agent có một schema rõ ràng cho output. Rồi agent chính xếp hạng những design tệ nhất trong ngày và đưa vào báo cáo. Họ có một output contract cho cả loop, cùng một số guardrail.

Trên màn hình, file SKILL.md của daily-bad-design-triage mô tả skill này: tìm ra những design tệ nhất Superdesign tạo trong 24 giờ qua, kéo các tín hiệu tiêu cực (chấm điểm thấp, lỗi runtime app xác nhận, yêu cầu khôi phục hoặc tạo lại), quét bằng các luật cứng có tính tới thiết bị, cho vision LLM chấm ảnh chụp màn hình, xếp hạng cái tệ nhất, và viết một báo cáo HTML cùng JSON có ghi ngày vào thư mục docs. Bước "Procedure" mở đầu bằng việc đọc skill phân tích dữ liệu của họ trước, rồi chạy script pull-24h.py để kéo và làm giàu dữ liệu ứng viên; thư mục scripts có gen-report.mjs, pull-24h.py và scan.mjs.

Với cách này, mỗi ngày họ chỉ cần khởi động một loop và trỏ agent tới skill cùng các script, để nó biết phải làm những bước nào và dựng thêm agent khi cần. Đây là một ví dụ hiện thực LLM-as-graph. Như bạn thấy, đó là một workflow khá phức tạp, nhưng họ đạt được output rất tốt chỉ bằng cách tiêm vào skill cộng script.

14. Code-as-graph với dynamic workflow: workflow ship-change

Mặt khác, team Jason cũng dùng dynamic workflow theo phương pháp code-as-graph. Nếu bạn chưa quen với dynamic workflow: về cơ bản, agent có thể viết một file JavaScript, vì nó được cấp thêm vài primitive và API mới.

agent(prompt, opts)
pipeline(items, stage1, stage2, ...)
parallel(thunks)

Cụ thể, đó là agent: bạn chỉ cần gọi một hàm để dựng lên một agent. Rồi pipeline: nghĩa là có quan hệ phụ thuộc giữa các stage. Và parallel: nghĩa là bạn fan out ra một loạt agent. Với những thứ này, agent về cơ bản có thể viết bất kỳ đoạn JavaScript nào gọi các hàm primitive đó, để dựng bất kỳ kiểu graph nào nó muốn.

Một ví dụ team Jason có là workflow ship change. Họ kích hoạt workflow này mỗi khi đã có scope và plan khá rõ ràng cho một việc nào đó. Trong workflow, việc được chia thành ba phase: một là setup và implement, hai là verify công việc, và nếu verify qua thì ba là cho agent simplify và mở PR.

Bên trong file JavaScript, nó định nghĩa các schema khác nhau. Cách dynamic workflow, hay hàm agent, hoạt động là bạn chỉ cần mở một session với prompt này, chỉ định model và schema, để khi session agent đó xong, nó thực sự trả kết quả theo đúng schema. Đó đại loại là state output của từng agent node.

Lợi ích của cách này là bạn dễ dàng dựng prompt cho agent node tiếp theo, kèm những context và chi tiết quan trọng từ session agent trước.

15. Ví dụ viết bài hai bước và bản open source deer-workflow

Ví dụ, bạn có thể build một workflow cơ bản để, chẳng hạn, viết bài, gồm hai stage. Một là lập dàn ý (outline) bài viết, hai là viết bài. Với mỗi stage, code chỉ việc đánh thức agent với một prompt cụ thể, kèm schema đã định nghĩa phía trên, ở đây là outline schema, gồm tiêu đề và các gạch đầu dòng cho từng phần.

Rồi phase hai là viết bài dựa trên dàn ý. Bạn chỉ cần viết một prompt tham chiếu tới output của session agent trước để dựng nên prompt mới. Và cuối cùng, hàm này trả về thông tin của cả lượt chạy.

Trên màn hình là file 00-basics.ts trong một thư mục tutorial (cạnh các file như 01-dynamic-fanout.ts, 02-conditional-edges.ts, 03-state.ts, 04-pipeline-vs-parallel.ts). Phase "Outline" gọi agent với prompt viết dàn ý 3 đến 6 gạch đầu dòng, kèm sandbox: "read-only" và schema: outlineSchema; một dòng comment giải thích rằng nhờ có schema nên kết quả có kiểu, còn không có schema thì agent() trả về chuỗi. Phase "Write" gọi agent lần nữa, chèn outline.title và các bullet vào prompt. Cuối hàm trả về:

return {
  runId: context.id,
  title: outline.title,
  wordCount: draft.split(/\s+/).filter(Boolean).length,
};

Tính năng dynamic workflow còn nhiều thứ hơn thế. Và thực ra có một dự án open source tên là deer-workflow, hiện thực dynamic workflow theo cách open source. Nghĩa là mỗi agent node có thể là Claude Code, Codex, hay bất kỳ loại agent nào khác. Trên GitHub, repo này tự mô tả là "An open-source graph engineering runtime that keeps orchestration in TypeScript and delegates semantic work to replaceable Agent runtimes". Jason có vài ví dụ code nằm trong cộng đồng của anh cho ai quan tâm.

Tóm lại, trong repo superdesign agi, team dùng dynamic workflow để có một graph ship code khá đáng tin cậy.

16. Đừng quên verifier, và Jason chọn cách nào

Nhưng có một điều Jason muốn nhấn mạnh lại: chỉ chia nhỏ tác vụ như thế này thôi thì sẽ không chạy. Bạn thực sự cần cho agent công cụ để nó test được mọi thứ đúng cách. Đây có lẽ là một trong những bước bị thiếu lớn nhất mà anh thấy: phần lớn mọi người không làm, rồi thắc mắc vì sao loop của mình không chạy.

Vì vậy anh rất khuyên mọi người đi dựng nó. Nếu không biết dựng thế nào, anh có skill verifier setup trong repo public của AI Builder Club, bạn cứ việc lấy về. Nó sẽ mở khoá rất nhiều thứ khác bạn có thể làm.

Qua hai ví dụ này, Jason hy vọng giờ bạn thấy được cách thực sự làm graph engineering. Có hai phương pháp bạn có thể dùng, mỗi cái cho ra một loại output khác nhau, và cả hai đều hợp lệ.

Cá nhân anh thường chọn phương pháp LLM-as-graph trong đa số trường hợp. Lý do: với dynamic workflow hay code mode của Codex, ở thời điểm hiện tại (tháng 8/2026, lúc video đăng), mỗi lần chạy là bạn khởi động một agent session mới, nên bạn không thể tiếp tục (resume) cuộc hội thoại trước đó, và điều này làm nó có vẻ phiền hơn một chút. Nhưng nếu tác vụ của bạn cực kỳ lớn, code-as-graph thực sự là một phương pháp rất tốt.

Trong video tiếp theo, Jason muốn nói về khái niệm graph of loops: chuyện gì xảy ra khi có rất nhiều loop vận hành công ty bạn, và làm sao đảm bảo chúng cộng dồn hiệu quả cho nhau. Anh mời ai quan tâm để lại bình luận và subscribe, rồi cảm ơn mọi người đã xem.