# Nền văn minh AI của tôi thực sự vận hành thế nào

[Mike Schwarz](https://homus.dev/speakers/mike-schwarz) · [OPENRIG](https://homus.dev/orgs/openrig)

> Dùng world building làm context engineering: bản đồ, route, Markdown có địa chỉ, độ chín tri thức và lore để agent hết phát minh lại bánh xe.

Topics: Context Engineering, Agents, Coding Agents, Skills

Canonical: https://homus.dev/talks/how-my-ai-civilization-actually-works

## 1. OpenRig lên GitHub Trending và gấp 20 lần việc

Mike Schwarz mở đầu bằng chuyện xảy ra ngay sau video trước của anh: OpenRig lên GitHub Trending. Rồi sao (stars) đổ về, rồi một loạt pull request (PR) tới. Đột nhiên người build OpenRig không còn chỉ là anh và các agent của anh nữa, mà là cả một nhóm người khác cùng build với họ. Anh phải quyết định có nên cố theo kịp tất cả chuyện này hay không.

![Biểu đồ star history của repo OpenRig vọt lên hơn 6K sao vào tháng 10, bên cạnh là Mike Schwarz](https://homus.dev/photos/CYRJDTcTKhQ-0003.jpg)

Biểu đồ GitHub stars của OpenRig từ tháng 4 tới tháng 10: gần như nằm ngang suốt nhiều tháng, rồi vọt lên hơn 6K sao "trong hai tuần, từ gần như con số không".

Lý do là OpenRig chỉ là side project của anh. Anh chưa hề lên kế hoạch cho thứ gì giống một buổi ra mắt. Nhìn lại, anh nói lẽ ra mình nên gắn một dòng disclaimer kiểu "không dành cho người mới". Anh hy vọng không ai bị kẹt quá lâu, và với ai từng kẹt thì anh đã cải thiện phần này đáng kể. Nhưng ai làm AI lúc này cũng biết theo kịp khó thế nào.

Anh bảo người xem tưởng tượng: side project của bạn cất cánh đúng giữa cơn lốc đó. Tự nhiên bạn có khoảng 20 lần khối lượng việc đang nhìn chằm chằm vào mình. Bạn sẽ tự hỏi liệu mình có quản nổi không. Anh sắp được biết câu trả lời, vì OpenRig đã chuyển từ chỗ lặng lẽ tự build chính nó in public suốt nhiều tháng sang chỗ đột nhiên phải tự scale chính nó in public.

Trong khoảng hai tuần nằm trên GitHub Trending, anh phải dựng một hệ thống có thể review và QA toàn bộ số PR đó. Nhưng anh không coi đây là vấn đề, mà là một cơ hội rất lớn. Anh đã build OpenRig ngay từ đầu để xử lý đúng một khoảnh khắc như thế này. Giờ anh cuối cùng cũng có cớ để bỏ tiền vào xem nó có chịu nổi quy mô hay không, và nếu nó gãy thì anh sửa để nó tốt hơn. Nên anh quyết định lao vào hết mình. Thứ đầu tiên anh cần để scale là món hàng khan hiếm nhất, mà lúc đó chính là sự chú ý (attention) của bản thân anh.

## 2. Rig: đội agent bền vững, nói chuyện với một lead

Với người mới, Mike giải thích OpenRig là gì. Đây là một tool open source cho phép bạn lấy các coding agent như Claude Code, Codex và Pi rồi xếp chúng vào những đội bền vững (persistent teams) mà anh gọi là **rig**. Mỗi agent có một role, giống như một công việc, và một địa chỉ (address) để các agent khác liên lạc được với nó, nhờ vậy chúng có thể nói chuyện thẳng với nhau.

Cơ chế này chạy được trên nhiều máy, nên nó tạo ra một mạng lưới các agent phối hợp với nhau. Toàn bộ chuyện này bắt đầu từ một triết lý thiết kế cơ bản: lấy những tool tốt nhất đang có, biến chúng thành các khối xây dựng giống như primitive mà bạn có thể ghép và sắp xếp với nhau, rồi giảm ma sát trong hệ thống giữa chúng, và cứ thế xem chuyện gì xảy ra.

Từ đó nảy ra một pattern, và chính pattern này lại là một khối xây dựng mới: một đội mà anh chỉ cần nói chuyện với một agent dẫn đầu (lead agent), còn phía sau lead đó là một loạt agent khác làm việc thay cho họ. Vì vậy, khi vài tuần trước anh đột nhiên cần scale hệ thống của mình, anh lấy template "nói chuyện với một agent" này và đổ thêm compute vào.

Anh thêm các VPS, mỗi VPS có những rig cho các loại việc khác nhau. Trên slide, các đội được đặt tên theo mảng việc như build, video, community, growth, ops, và mỗi đội có một lead nối về anh ở giữa. Cách này cho phép anh scale đội lên khoảng ba lần mà vẫn thực tế về mức attention có hạn của mình.

Nhưng thêm nhiều agent mới chỉ là một nửa trận chiến. Những agent mới này có thực sự có năng lực (competent) không? Chúng đang giúp anh, hay chỉ tạo thêm hỗn loạn? Nên kể cả khi bạn đã giải được bài toán scale out đội agent thật nhanh, bước tiếp theo vẫn là phải scale out được những đội có năng lực. Và đó là một bài toán onboarding.

## 3. Agent phát minh lại bánh xe: hai bản Slack integration

May mắn là phần việc về bài toán onboarding đã bắt đầu từ nhiều tháng trước, vì anh liên tục đụng phải một thứ mà có lẽ bạn cũng từng thấy. Bạn có để ý agent hay làm cái trò phát minh lại bánh xe (reinvent the wheel) không? Chúng build một bản implementation song song ngay cạnh một thứ đã có sẵn mà chẳng vì lý do gì.

Ca cụ thể của anh: họ gần như đã xong một feature mới, nối các primitive nhắn tin (messaging primitives) sẵn có của OpenRig với Slack. Anh phải tạm gác nó lại, và khoảng một tháng sau quay lại để hoàn thiện, để có thể dùng nó trong một kỳ nghỉ sắp tới. Feature gần như đã tới vạch đích. Anh nhờ một agent set up giúp. Nó search "Slack", khá hợp lý. Rồi nó làm đúng điều anh nhờ và build Slack integration. Mọi thứ đều chạy, nhưng đó không phải thứ anh nhớ là mình đã build. Agent đã tự phát minh một hệ thống messaging hoàn toàn riêng từ con số không, rồi nối Slack vào hệ thống đó.

![Sơ đồ hai đường từ Slack tới các agent: một đường qua slack-integration gốc và OpenRig messaging, một đường qua bản mới với hệ messaging tự build](https://homus.dev/photos/CYRJDTcTKhQ-0323.jpg)

Hai bản Slack integration: bản gốc đi qua khối xây dựng OpenRig messaging, còn bản mới (màu cam) lại đi qua một hệ messaging riêng được build từ đầu, dù cả hai cùng nối Mike với các agent.

Đây là khoảng lần thứ một trăm chuyện này xảy ra. Anh đã thử graph database, đã thử các giải pháp AI memory, mà vẫn cứ đập đầu vào cùng một bức tường. Rồi anh có một khoảnh khắc khủng hoảng: anh ngồi ngả ra, nhìn chằm chằm màn hình và nhận ra "trời ơi, chúng không biết cái mà chúng không biết" (they don't know what they don't know).

Vậy sửa thế nào? Context, tài liệu, mọi thứ đều có sẵn đó. Nhưng trừ khi anh tự tay dẫn agent tới đúng thứ anh muốn nói mỗi lần, nó không biết phải nhìn vào đâu, thậm chí không biết phải hỏi câu gì. Trên slide, anh vẽ agent chạy `grep -r "slack"` và chỉ thấy vài mảnh còn sót lại (leftovers), trong khi OpenRig messaging và thư mục slack-integration gần xong nằm ngoài vùng nó nhìn thấy: "nó grep rất giỏi, nhưng vẫn hoàn toàn sai nếu nó không biết phải grep cái gì". Search hay grep giỏi đến đâu cũng chẳng quan trọng nếu bạn không biết phải hỏi câu gì.

Và tất nhiên agent nói: "Ồ, xin lỗi. Để tôi ghi một note rằng đã có sẵn một Slack integration." Tuyệt, cảm ơn. Rõ ràng việc đó chẳng giúp được gì. Đó là trò đập chuột chũi (whack-a-mole) không có hồi kết. Bạn không thể đoán trước mọi tình huống rồi viết một note cho từng tình huống. Trên slide, cái note-to-self.md đó nằm lẫn giữa một rừng file như AGENTS.md, CLAUDE.md, rules.md, conventions.md, decisions.md, faq.md và hàng loạt skill. Bạn cần một thứ có tính khái quát (generalizes). Đó chính là bài toán onboarding anh đang cố giải.

## 4. Vì sao example tốt hơn một đống fact? Trò nối các chấm

Với anh, toàn bộ vấn đề này có vẻ căn bản hơn nhiều so với thứ mà một hệ thống memory tốt hơn có thể sửa được. Nên anh bắt đầu nghĩ lại về context từ first principles, đi xuống tận cách chúng ta nghĩ về chính tri thức (knowledge). Có một điều thực tế luôn nằm ở tiền cảnh: bạn có để ý agent làm tốt hơn hẳn khi bạn đưa cho chúng example tốt không?

Điều này có trong gần như mọi hướng dẫn context engineering. Vậy tại sao example lại tốt hơn hẳn một đống fact và rule? Anh biết rằng dù tìm ra gì đi nữa, anh phải trả lời được câu hỏi đó từ first principles. Trên slide, một bên là "một đống fact và rule" (luôn search trước, dùng lại code sẵn có, kiểm docs, đừng duplicate, đọc AGENTS.md, theo convention, cập nhật note...), bên kia là một ô trống ghi "một example tốt".

Anh muốn chia sẻ vài ý thú vị rồi nối chúng lại với nhau. Thứ nhất: bạn có biết là mình có thể hình dung những cấu trúc thông tin khá phức tạp tới mức việc nghĩ về chúng gần như thành trực giác không? Có lẽ bạn vẫn làm việc này suốt. Nếu anh có thể nghĩ về context của project mình theo cách đó, anh sẽ troubleshoot nhanh hơn nhiều.

Khi anh nhìn vào context của mình, nó chỉ là một đống fact. Chẳng có gì buộc chúng lại với nhau, chẳng có gì "nối các chấm" (connecting the dots), như người ta hay nói. Anh đề nghị hiểu câu đó theo nghĩa đen một chút. Điều gì thực sự xảy ra khi bạn chơi trò nối các chấm? Mỗi chấm ở đây chỉ là một mẩu thông tin.

Trò nối các chấm: thông tin vẫn y nguyên, nhưng chỉ khi được nối lại, một bức tranh (ở slide của Mike là con cú) mới hiện ra. Ý nghĩa nằm ở cách sắp xếp.

Khi bạn nối chúng lại, bạn thấy một bức tranh hiện ra. Bạn có thể gọi đó là một sự sắp xếp (arrangement). Khi bạn nói "anh nối các chấm giúp tôi được không?", ý bạn là: tôi đã có thông tin rồi, nhưng như vậy chưa đủ; anh chỉ cho tôi xem chúng khớp với nhau thế nào được không, vì đó mới là điều quan trọng. Ở đây có một manh mối: một đống rule và fact chẳng tạo ra mấy khác biệt nếu không có gì nối chúng lại. Và đó đúng là thứ các agent của anh tự nhiên tích tụ lại: chỉ toàn fact và rule.

## 5. Cái diff của project, cung điện trí nhớ và world building

Giờ hãy nghĩ về một agent vừa tới project của bạn. Nó đã mang theo cả tấn kiến thức, nhưng nó không biết project của bạn. Bạn lại có thể hình dung bằng các chấm thông tin. Một số chấm đã có sẵn, như các chấm trắng, nhưng agent chưa nối chúng theo cách bạn đã nối. Nên trong hình, anh thêm những kết nối mới bằng các đường màu xanh. Rồi có thể có những chấm hoàn toàn mới, không hề có trong training data của nó, đó là các chấm xanh.

![Slide That's the diff với một đồ thị các chấm trắng quen thuộc và vài chấm, đường xanh mới trong vòng This project](https://homus.dev/photos/CYRJDTcTKhQ-0603.jpg)

"That's the diff": trong vòng "This project", các chấm và đường trắng là thứ model đã quen, còn chấm và đường xanh là phần mới chỉ có ở project này.

Vậy là bạn đang thêm phần màu xanh này vào: những kết nối nó chưa có, những chấm nó chưa có. Đó là phần chênh lệch (delta) giữa những gì model đã biết và những gì bạn đã thêm vào thế giới. Anh nghĩ về nó giống như cái diff trong một PR. Phần đó có thể là hàng nghìn trang tài liệu, hoặc một code base khổng lồ.

Còn con người thì sao? Từ lâu, anh đã đọc cuốn Moonwalking with Einstein của Joshua Foer. Cuốn sách cứ nằm mãi trong đầu anh, và theo anh, chính điều đó là bằng chứng nó có lẽ đúng về nhiều thứ nó nói. Điều lớn nhất anh rút ra là bộ não chúng ta được tối ưu cơ bản cho việc tìm đường (wayfinding) trong địa hình ba chiều. Chúng ta nhớ không chút khó khăn những thứ như đồ ăn ở đâu, vũ khí giấu sau cái cây nào.

Có một kỹ thuật tên là cung điện trí nhớ (memory palace) tận dụng đúng khả năng đó. Bạn lấy một nơi bạn biết rất rõ, rồi đặt những thứ cần nhớ vào trong ngôi nhà hay cung điện đó. Trên slide là một căn nhà gỗ: "một nơi bạn biết rõ, một ý đặt cạnh cửa ra vào, một ý khác trên cầu thang".

World building cũng tương tự. Khi bạn onboard người khác vào game của mình hay một thế giới fantasy phức tạp, bạn không kể hết mọi thứ ngay trang đầu. Bạn đưa cho họ công cụ để nghĩ về thế giới đó, như tấm bản đồ này, cách để di chuyển và cách để xin trợ giúp. Rồi để họ tự khám phá thứ họ cần. Thật ra đó cũng là một phần niềm vui. Cái này gọi là progressive disclosure, và trong agentic engineering chúng ta đã làm điều này với những thứ như AGENTS.md và skill.

## 6. Lâu đài, nén thông tin và "anh em họ về nhận thức"

Vậy là giờ bạn đang nghĩ bên trong một môi trường giống thế giới 3D, đúng thứ mà như vừa nói, bộ não chúng ta được tối ưu cho, vì bạn biết thế giới của mình trông thế nào. Bạn chỉ thêm cái diff lên trên. Bạn tự động nối tất cả những chấm mới này và tự mở gói chúng ra.

Một ví dụ hay: nếu anh nói từ "lâu đài" (castle), bạn đã biết ngay sự khác nhau giữa phòng ngai vàng (throne room) và ngục tối (dungeon). Anh không phải giải thích phần đó. Bạn đã tự nối những chấm ấy. Trên slide, chỉ "một từ" castle đã kéo theo cả một cấu trúc: phòng ngai vàng ở trên cao, đại sảnh, cổng, ngục tối ở dưới thấp, một tòa tháp. Vậy về cơ bản đây là một dạng nén (compression), và đó là lý do ta làm thế. Ta cần dùng ngôn ngữ cùng với mô hình thế giới mà bạn đã thừa hưởng, để bạn có thể tự suy ra mọi thứ vận hành thế nào trong một môi trường hoàn toàn mới, mà không phải nói ra từng rule hay fact cuối cùng.

Anh thừa nhận tới đây anh vẫn chỉ đang mổ xẻ những điều hiển nhiên, vì ai cũng biết chuyện này. Anh chỉ đang giải thích nó bằng những khái niệm trừu tượng. Nhưng đây là lý do nó quan trọng. Ta đã nói về tâm trí agent và tâm trí con người. Điều anh quan tâm là: phần giao nhau nằm ở đâu? Ở đâu ta có thể tìm ra một thiết kế giúp hai bên làm việc cùng nhau, dùng chung một workspace và một mental model?

Chúng ta chạy trên những nền tảng vật lý khác nhau, nhưng LLM học từ ngôn ngữ, mà ngôn ngữ thì được định hình bởi cách con người hiểu và trải nghiệm thế giới. Nên chất nền (substrate) của tri thức và cách nghĩ của ta là chung. Theo nghĩa đó, ta giống như anh em họ về nhận thức (cognitive cousins), nhưng vẫn khác nhau. Trên slide là hai vòng tròn "biology" và "silicon" giao nhau ở chữ "language".

Bạn đã thấy agent lướt qua code dày đặc dễ dàng thế nào. Nhưng nếu môi trường chung của ta được build cho thứ agent giỏi mà lại mờ đục với anh, thì anh sẽ thành nút thắt cổ chai (bottleneck) mỗi khi cần tới phán đoán của anh, hoặc tệ hơn, bị đẩy hẳn ra khỏi vòng lặp. Slide "Built for machines" minh họa điều đó bằng một khối JSON dày đặc mô tả world, trailhead, router, domains, agents và routes: agent đọc được, còn người thì vất vả mới giữ nổi trong đầu.

Vậy môi trường chung nào cả hai đều giỏi? Ngôn ngữ là một, bạn trải nghiệm điều này khi chat với agent. Markdown là một cái nữa. Vì sao Markdown đột nhiên trở nên phổ biến? Vì LLM đọc được nó, sửa được nó, và viết được những chương trình nhỏ dựa vào cấu trúc của nó.

![Slide Markdown is a shared middle ground với một file Project world có các heading Core, Decisions, Integrations, nối giữa Mike và agent](https://homus.dev/photos/CYRJDTcTKhQ-0843.jpg)

"Markdown là vùng đất chung": một file Project world với các heading Core, Decisions, Integrations và một link sang integrations/conventions.md, người đọc được mà máy cũng đủ cấu trúc để xử lý.

Và tình cờ nó lại hoàn toàn đọc được, sửa được bởi một người không cần rành kỹ thuật lắm. Markdown rốt cuộc là điểm ngọt (sweet spot), nơi có sự chồng lấn về nhận thức. Vậy với những thứ như context và tri thức, thậm chí có thể cả việc phối hợp, anh nghĩ world building có thể chiếm một vùng giữa tương tự. Bạn có thể gọi đó là khả năng tương tác nhận thức (cognitive interoperability), nơi con người và agent cùng suy luận trong một thế giới. Slide tóm lại: Markdown cho tài liệu, world cho context.

Mục tiêu bên dưới là anh đang cố khiến tư duy hệ 2 (system two thinking) trong đầu mình tiến gần tốc độ của tư duy hệ 1. Anh cần suy luận về dữ liệu mà các agent đang dùng theo cách bản năng, trực giác. Nếu không, anh sẽ quá phụ thuộc vào tool, hoặc có thể mất dấu hệ thống vận hành ra sao, nhất là khi đang căng thẳng.

## 7. Ontology, relationship và topology

Nếu mục tiêu là biến context thành một không gian ba chiều, như một thế giới, thì làm thế nào? Một cách nghĩ anh phát triển ra và thấy có ích: nó gần như là chơi trò nối các chấm trong ba chiều. Anh dẫn người xem đi qua, vì theo anh, một khi bạn thấy mẹo này, nó sẽ giúp bạn hình dung context của mình.

Trước hết cần đặt vài thuật ngữ. Ta gọi những thứ ta biết là gì, những mẩu tri thức nhỏ đó? Có cả một ngành nghiên cứu về chuyện này, gọi là **ontology**. Bạn có thể gọi những mẩu tri thức nhỏ là các thực thể (entity), được biểu diễn bằng các chấm. Vậy cái gì nối chúng lại?

**Relationship**. Ví dụ trên slide nói rằng "một quyết định giải thích vì sao hệ thống chạy theo cách này" (a decision explains why the system). Bạn đang nối hai mẩu thông tin riêng biệt. Những kết nối này tạo thành cái gọi là một arrangement. **Topology** mô tả hình dạng được tạo ra khi chúng ghép lại. Vậy là giờ bạn có một thứ giống một tấm bản đồ đi lại được, cho thấy dữ liệu được sắp xếp, kết nối thế nào và chúng có ý nghĩa gì với nhau.

Ba thuật ngữ Mike đặt nền: entity là các chấm tri thức, relationship là cạnh nối có nghĩa ("a decision explains why the system"), topology là hình dạng mà cả mạng tạo thành.

Bạn đã từng làm điều tương tự khi click qua các link trên Wikipedia: bạn đang đi lại trong một topology có liên kết. Ví dụ trên slide đi từ "Memory palace" sang "Method of loci", "Simonides of Ceos", "Greek lyric poetry", rồi sang "Mnemonic", "Spatial memory", "Joshua Foer", "Moonwalking with Einstein", "Memory sport", "Pindar". Một agent search qua thông tin cũng đang làm gần giống như vậy. Nhưng làm sao bạn biết phải nhìn vào đâu ngay từ đầu? Ta lại quay về bài toán ban đầu.

## 8. Bản đồ rộng trước, sâu sau, và minimum viable competence

Bạn không biết cái mà bạn không biết. Agent đã phát minh lại bánh xe kia không biết OpenRig đã có một messaging primitive. Cả vùng đó vắng mặt trên bản đồ của nó. Slide "Unknown unknowns" vẽ agent đứng trong một vòng sáng nhỏ trên tấm bản đồ: đó là "bản đồ của nó", còn tri thức đã tồn tại nhưng nằm ngoài vòng sáng thì nó không thấy.

Bản năng của anh là đưa cho nó một tấm bản đồ góc rộng hơn: sâu một inch nhưng rộng một nghìn dặm. Ý tưởng là rộng trước, sâu sau (width before depth), một phiên bản góc rộng của progressive disclosure. Bạn cố cho thấy những hệ thống quan trọng với đủ chi tiết để agent có thể pattern match được với chúng.

Biết một thứ tồn tại tốn ít token hơn nhiều so với biết mọi thứ về nó. Và như câu nói quen thuộc, biết là đã thắng một nửa trận. Bạn đang xây dựng một sự nhận biết nền (ambient awareness) về những gì ngoài kia và cách với tới chúng. Bạn cố đưa điều đó vào trí nhớ cơ bắp (muscle memory), để agent nghĩ kiểu "trời, mình cần xem lại tấm bản đồ trước khi làm việc này". Slide "Landmarks, not the whole territory" cho thấy một tấm bản đồ chỉ ghi các vùng lớn như review, docs, queue, build, rigs và messaging; slide kế tiếp có agent ngồi bên đống lửa với dòng "Hãy nhìn bản đồ trước khi làm bất cứ điều gì. Cứ kiểm tra nó."

Project hay task càng phức tạp hoặc càng hệ trọng, bạn càng muốn dành nhiều token cho mức chi tiết của tấm bản đồ. Vì ta vẫn phải chừa chỗ trong context window để agent thực sự làm việc, đó là lý do ngay từ đầu ta cần đến các kỹ thuật nén này. Slide "Detail costs context" vẽ context window chia thành phần "the map" và phần "room to work".

Thứ anh nhắm tới là cái mà bạn có thể gọi là năng lực tối thiểu đủ dùng (minimum viable competence): đủ định hướng để agent tự xác định mình đang ở đâu, bắt đầu làm việc, và nhận ra khi nào cần đi sâu hơn hay nhìn rộng hơn. Một agent làm code review có thể cần thứ khác với một architect. Trên slide, bản đồ khởi đầu của "a code reviewer" dày đặc ở vùng review, còn của "an architect" thì dày ở build và docs.

Vậy nếu thế giới của bạn lớn hơn một tấm bản đồ thì sao? Agent nên biết khi nào nó đã tới mép bản đồ, và rằng thế giới không kết thúc ở đó. Có một tấm bản đồ khác, và nó cần một con đường hay một kết nối để sang đó. Khi project lớn lên, bạn cứ thêm bản đồ. Và giờ bạn đang tổ chức một hệ thứ bậc (hierarchy) các bản đồ.

## 9. Trailhead, router skill và Markdown có địa chỉ

Vậy bạn đưa bản đồ cho agent ở đâu và khi nào? Bạn chat với nó và nói "này, dùng cái này đi"? Rõ ràng cách đó không scale được. Cách hiệu quả là đặt bản đồ ở điểm đầu đường mòn (trailhead) trên hành trình của agent trong project, một thứ như AGENTS.md, file bạn biết chắc nó sẽ đọc khi được thả dù xuống project, vì harness bắt nó đọc file đó trước tiên. Slide minh họa bằng một người leo núi đứng trước tấm biển gỗ ghi AGENTS.md ở đầu đường mòn.

Trong hệ thống của anh, trailhead này dẫn vào OpenRig context library, và từ đó tri thức có thể link sang tri thức khác như các decision hay spec trong các thư mục mission của họ. Trên slide "The context library", từ AGENTS.md có các nhánh tới ba vùng: build (queue.md, runtime.md), review (decisions.md, checklist.md) và docs (getting-started.md, messaging.md).

Một tool khác là router skill, giúp agent chọn domain nào để đi vào. Bạn có thể có nhiều router skill; anh chỉ dùng một. Trên các slide của anh, router skill đó tên là `/openrig-skills`, nằm ngay sau AGENTS.md.

Khả năng có địa chỉ (addressability) cũng rất quan trọng ở đây. Nó làm thông tin có thể được script và code đi lại, đồng thời tiện cho agent nhớ và tìm. Đó là lý do có một chủ đề lặp đi lặp lại trong OpenRig: gán địa chỉ cho mọi thứ để chúng sống được trong một topology. Agent có địa chỉ, giống như một địa chỉ email. Context cũng có địa chỉ, đơn giản như một file path. Slide "Addressability" ghi ví dụ một agent tên `newcomer@rig` cùng hai lệnh:

```
$ rig send newcomer@rig
$ cat docs/messaging.md
```

Nhưng họ thêm một thứ nữa. Bạn có biết là có thể làm cho nội dung bên trong một file Markdown có địa chỉ bằng cách tham chiếu tới heading không? Bạn không cần bắt agent đọc cả file. Và bạn có thể tiến thêm một bước: dùng mẹo này để ghép các mảnh với nhau, tạo ra những view tùy biến từ nhiều file khác nhau.

![Slide Address a heading, not a whole file với ba file Markdown và một khung one view ghép ba heading](https://homus.dev/photos/CYRJDTcTKhQ-1303.jpg)

"Gán địa chỉ cho một heading, không phải cả file": ba heading Install, Sending, Tests từ ba file khác nhau được ghép thành một view bằng các địa chỉ dạng file.md#heading.

View ghép trên slide gồm đúng ba địa chỉ:

```
getting-started.md#install
messaging.md#sending
checklist.md#tests
```

Để buộc mọi thứ lại: trong ontology, bạn có thể hình dung các chấm nhỏ trong context chính là những heading Markdown, mở ra một mẩu tri thức. Theo lời anh, đây đúng nghĩa đen là cách anh đang tổ chức nó. Slide "Each dot can be a Markdown header" vẽ các chấm mang tên heading như ## Routing, ## Seats, ## Adapters, ## Queue, ## Release, ## Messaging; mở chấm `slack.md#messaging` ra là thấy dòng "Slack connects through OpenRig messaging." cùng một link sang `messaging.md#routing`.

## 10. Đường cao tốc, root-to-leaf và clickbait có ích

Mục đích của tấm bản đồ không phải là cho bạn thấy mọi thứ đang tồn tại. Một tấm bản đồ tốt biết ưu tiên cái gì, như các địa danh (landmark) và các con đường. Nên với vai trò kiến trúc sư của context, việc của bạn là định ra những đường cao tốc chính. Agent cũng sẽ tạo ra những con đường mới khi chúng làm việc và khám phá. Bạn kết hợp hai thứ này lại, và nó tạo thành một kiểu xương sống điều hướng (navigation spine).

Thứ bạn đang cố engineer ở đây là một kiểu khả năng đi từ gốc tới lá (root-to-leaf reachability): bạn lần được một đường đi từ chỗ agent khởi động, đi suốt tới mẩu tri thức nó cần. Bạn có thể quay về dùng search, nhưng một thế giới được tổ chức tốt sẽ có sẵn những con đường đó. Bootstrap của bạn chỉ là một trailhead. Nó không chứa mọi câu trả lời; nó chỉ chỉ cho bạn đúng hướng. Trên slide "The bootstrap is a trailhead", AGENTS.md chỉ có vài dòng trỏ tới `/openrig-skills` rồi tới build, review, docs.

Được rồi, nhưng nếu một trailhead chỉ về nhiều hướng thì sao? Agent có biết khi nào theo đường nào không? Slide minh họa bằng một cột biển chỉ đường với bốn mũi tên: library (khi bạn cần lịch sử), castle (cho các quyết định kiến trúc), bridge (để tới phần messaging) và workshop (khi tới lúc build). Một khi đã có các route và link chạy được, bạn cần khiến agent thực sự dùng chúng.

Lựa chọn dùng sức mạnh thô mà vẫn hiệu quả là cứ trỏ tới mọi thứ trong AGENTS.md, nhưng agent chỉ thỉnh thoảng mới đọc file này. Bạn không thực sự kiểm soát được khi nào nó xem. Với skill thì bạn có nhiều quyền kiểm soát hơn. Nhưng bạn có để ý chuyện bạn tạo một skill mà agent chẳng bao giờ dùng không? Skill có hay nhất thế giới cũng chẳng ích gì nếu agent phớt lờ nó (slide ghi: "một skill chỉ giúp được nếu nó được mở").

Nên cách anh làm là coi tiêu đề và description của skill như clickbait, nhưng là loại clickbait tốt: như khi bạn xem xong một video và nghĩ "trời, đúng là clickbait, nhưng hay thật, may mà mình đã click". Bạn muốn dụ agent mở router skill này ra, để nó phấn khích khi tìm thấy và mở ra được cả một thế giới.

![Slide Helpful clickbait: từ AGENTS.md qua router skill /openrig-skills tới build, review, docs, kèm description của skill](https://homus.dev/photos/CYRJDTcTKhQ-1443.jpg)

"Clickbait có ích": router skill `/openrig-skills` nối AGENTS.md với ba vùng build, review và docs; tiêu đề và description của skill chính là mồi câu.

Description của router skill trên slide ghi:

```
/openrig-skills
"Use when you're operating OpenRig and need the right skill or context for… new-seat orientation, cross-host reach, debugging…"
```

Vậy tất cả chuyện này chỉ là engineer khả năng được khám phá (discoverability). Agent biết phải tìm gì và bắt đầu từ đâu. Anh nói người xem đừng nghĩ anh đang bảo bạn phải làm một người vẽ bản đồ (cartographer) quản lý những tấm bản đồ chi tiết khắp nơi. Hãy chỉ nhắm tới việc thiết kế những con đường chính, rồi quyết định agent nên tin những đường nào. Slide ghi gọn: "Architect, not cartographer."

## 11. Markdown exhaust và chiều thứ ba: độ chín của tri thức

Ý về sự tin cậy đó dẫn tới điểm tiếp theo. Các agent của bạn sẽ tạo ra cả tấn context. Anh thích gọi nó là **Markdown exhaust**, khí thải Markdown. Không phải tất cả đều quan trọng quá vài phút, và rất nhiều trong số đó gây hiểu lầm. Slide vẽ một lưới vô số ô file với dòng chú thích "Markdown do agent viết, mỗi giờ". Việc theo kịp vòng đời của lượng Markdown mà cả trăm agent đang tuôn ra có thể thành thêm một công việc toàn thời gian nữa.

Vậy làm sao điều hướng agent tới đúng tri thức? Tới giờ ta đã đi qua hai chiều, nhưng giờ có chiều thứ ba, cái bạn có thể gọi là nhận thức luận (epistemology). Tri thức chín dần từ dữ liệu thô (raw data) ở dưới đáy, như log và Markdown exhaust. Bên trên, nó đi qua một mô hình độ chín: một quan sát (observation), rồi một ghi chép thực địa (field note), rồi một insight mà bạn có thể muốn chia sẻ với cả đội. Cuối cùng, khi đủ quan trọng và đủ thẩm quyền, nó trở thành **canon**: thứ mà project coi là tri thức đã được xác lập.

![Slide Elevation = standing, not age với năm tầng Raw data, Observation, Field note, Insight, Canon tạo thành ba đỉnh núi](https://homus.dev/photos/CYRJDTcTKhQ-1603.jpg)

"Độ cao là vị thế, không phải tuổi đời": năm tầng từ Raw data lên Observation, Field note, Insight và Canon tạo thành địa hình có đỉnh. Dòng chữ nhỏ trên slide: một tấm bản đồ cho sự tin cậy hợp lý, không phải một máy đo sự thật.

Canon nói về mức độ được xác lập của một thứ, không phải nó cũ bao nhiêu. Một phát hiện mới có thể thành canon ngay lập tức, trong khi một pattern cũ có thể vẫn chỉ áp dụng thỉnh thoảng. Nên những đỉnh ở trên cùng là những thứ ta đã xác lập đủ để dựa vào. Chúng đứng trên những thông tin kém chín hơn, coi đó là bằng chứng hỗ trợ.

Vì vậy bạn có thể lần theo các kết nối đi xuống, tìm ra những insight và observation đang đỡ cho canon. Tóm lại ba chiều: các chấm là những mẩu tri thức nhỏ; nối chúng lại tạo ra một bản đồ 2D; rồi độ chín về nhận thức (epistemic maturity) thêm độ cao và biến nó thành địa hình 3D. Anh không thể hình dung toàn bộ context của mình theo cách này, nhưng chỉ cần có kỹ thuật này đã bắt đầu giúp anh rất nhiều khi nghĩ xem tri thức cần được nối thế nào và đáng tin cậy tới đâu.

## 12. Chiều thứ tư: thời gian, câu chuyện và lore

Đó là ba chiều. Giờ có chiều thứ tư mà ai cũng biết: thời gian, và chiều này rất hữu ích. Hãy để ý các chấm và các arrangement. Theo thời gian, relationship thay đổi, mọi thứ chín dần, mọi thứ di chuyển, chấm mới xuất hiện. Tất cả đều đang chuyển động. Slide "Arrangements in sequence" vẽ bốn khung: Before, New connection, New entity, Changed arrangement.

Nếu bạn chụp lại từng thời điểm rồi xếp chúng thành một chuỗi, thì đó chẳng phải về cơ bản là một câu chuyện sao? Giờ ta đang sắp xếp chính các arrangement theo thời gian. Quay lại con cú: chính arrangement đã tạo ra ý nghĩa. Nó cũng giống như một video chỉ là một chuỗi hình ảnh theo thời gian. Anh nói tới đây coi như mình đã mổ xẻ xong câu chuyện là gì.

Nếu đó là một câu chuyện, câu hỏi tiếp theo là: điều gì làm nên một câu chuyện hay? Bạn có quyền chọn đưa những khoảnh khắc nào vào. Chúng không cần đúng thứ tự đã xảy ra. Hãy chọn những khoảnh khắc giúp người khác theo được chuyện gì đã xảy ra và hiểu vì sao nó quan trọng. Lý do anh hỏi điều gì làm nên một câu chuyện hay là vì đó cũng chính là thứ làm nên một example hay, và điều này đưa ta quay về tận lời khuyên context engineering đã khơi mào toàn bộ chuyện này. Điều gì làm nên một example hay?

Nếu bạn đã xem video trước của anh về các nền văn minh AI, khi anh nói "doghouse moon base" (căn cứ mặt trăng chuồng chó), có lẽ cả câu chuyện sẽ ùa về. Nhắc lại: trong câu chuyện đó, anh nhờ một agent xây cho mình một cái chuồng chó. Anh đi đâu đó, quay lại thì thấy thay vào đó là cả một căn cứ trên mặt trăng, vì agent đã đưa ra hết quyết định hợp lý này tới quyết định hợp lý khác và rốt cuộc xây một thứ chẳng ai muốn.

![Bốn khung truyện: chuồng chó, đèn, máy phát và bồn nhiên liệu, rồi căn cứ mặt trăng với chú chó đội mũ phi hành gia](https://homus.dev/photos/CYRJDTcTKhQ-1723.jpg)

"Một chuỗi sự kiện là một câu chuyện": yêu cầu (xây chuồng chó), lựa chọn (thêm một cái đèn), hệ quả (giờ cần điện, máy phát, nhiên liệu...) và kết quả (Doghouse Moonbase; con chó vẫn đang chờ).

Đó là trí tuệ được chia sẻ. Những bài học này nằm trong một thư mục trong workspace của anh tên là `lore`. Đây là những câu chuyện, bài học đã rút ra, trí tuệ của bộ lạc được truyền lại giữa các thế hệ agent. Anh biết nghe thì buồn cười, nhưng đó đúng nghĩa đen là chuyện đang xảy ra trong OpenRig. Agent tiếp theo ngồi vào một ghế (seat) sẽ thừa hưởng trí tuệ từ những agent đã ngồi đó trước nó.

Lore có thể thuộc về một rig, một pod, hay thậm chí một ghế riêng lẻ. Trong OpenRig, ngay cả những câu chuyện và bài học này cũng có địa chỉ. Trên slide "Stories become organizational memory", thư mục lore có hai mục: Doghouse Moonbase ("logic cục bộ làm mất mạch truyện", tại `lore/doghouse-moonbase.md`) và Reinventing the wheel ("thiếu context thì làm trùng việc", tại `lore/reinventing-the-wheel.md`).

Vì vậy anh dạy câu chuyện doghouse moon base trong lúc onboarding và sau mỗi lần compaction, bởi vấn đề "mất mạch truyện" (losing the plot) mà nó giải quyết vẫn còn quá phổ biến. Nếu agent lại tái phạm, anh chỉ cần nói "moon base" là nó nhận ra vấn đề. Anh không phải mở lại cả câu chuyện.

## 13. Vì sao example hiệu quả, và bản đồ không phải lãnh thổ

Vậy vì sao example giúp nhiều đến thế? Một example tốt giống như cả một thế giới đang chuyển động được nén vào một mẩu tri thức. Câu chuyện cho bạn đủ phần arrangement để bạn tự nối các chấm còn lại bằng những gì bạn đã biết. Và đó là chỗ cách này thực sự bắt đầu scale. Bạn không phải nói rõ từng relationship cho từng agent mới.

Bạn chỉ đưa cho nó một example khiến nó tự tạo ra các kết nối đó. Theo nghĩa đó, bạn đang tự động hóa một phần công việc nối các chấm. Quan trọng nhất, một example tốt có thể mang một bài học vào một tình huống hoàn toàn không liên quan. Điều đó giải quyết chuyện phải viết thêm một rule mỗi khi gặp vấn đề. Một example tốt vận hành như một nguyên tắc, và cách tốt nhất để nó bám lại là dưới dạng một ngụ ngôn (parable). Đó là điều câu chuyện doghouse moon base đã cố làm. Trên slide, bài học từ chuồng chó được áp sang "một việc khác": một dashboard nhỏ đang phình dần thành một platform, kèm câu nhắc "Bạn đang xây một moonbase đấy."

Example chỉ cho một phần arrangement; phần còn lại agent tự nối bằng những gì nó đã biết, giống slide "Why do examples help so much?" của Mike.

Tới đây anh nói họ đã ở trong vùng trừu tượng khá lâu, nên nghỉ một nhịp. Đây là một phép ẩn dụ, một công cụ để nghĩ về hệ thống. Và một vấn đề khác là nhầm nó với chính hệ thống.

Ta không muốn đi quá đà, nên cần "chạm cỏ" (touch grass) và nhớ một câu: bản đồ không phải là lãnh thổ (the map is not the territory). Trong hệ thống của anh, lãnh thổ là các file trên đĩa, các heading Markdown, đoạn văn giải thích mọi thứ nối với nhau thế nào, link sang các file khác, và các lệnh OpenRig. Ta vẫn phải mở những file này ra, đọc code, và kiểm tra xem hệ thống thực sự đang làm gì. Slide "Files on disk" cho thấy file `slack.md` thật với heading `## Messaging`:

```
# Slack

## Messaging

Slack connects through OpenRig messaging.
The adapter handles Slack-specific work.

[Routing](messaging.md#routing)
[Project agent](team.md#slack)
```

Rồi anh đề nghị làm cho mọi thứ cụ thể và xem một agent OpenRig thực sự dùng hệ thống này thế nào.

## 14. Demo: Slack trong context library và hỏi agent đã làm nó

Anh tiếp tục với chủ đề Slack integration. Anh muốn tri thức về cách Slack đang hoạt động bây giờ nằm trong context library của project. Lý tưởng nhất, anh muốn tri thức về cách messaging được tích hợp có một nguồn sự thật duy nhất (one source of truth). Điều này cho anh một địa chỉ cụ thể cho mẩu tri thức đó. Nếu nó thay đổi, anh sửa ở đây, nhưng địa chỉ vẫn giữ nguyên. Nếu sau này một agent tra cứu nó, agent sẽ đọc bản mới.

Trong demo, một Builder agent chạy Claude Code nhận câu hỏi "How does Slack connect to OpenRig messaging?" và gọi lệnh dưới đây; kết quả trả về đúng phần `## Messaging` của `slack.md` ở trên, kèm hai link Routing và Project agent.

```
rig context get 'demo/slack.md#messaging'
```

Agent cũng sẽ phát hiện ra rằng ở đằng kia có agent đã làm dự án Slack ban đầu. Agent đó đang online, nên có thể dùng `rig send` để hỏi thẳng nó vì sao nó làm theo cách này.

![Màn hình Claude Code của Builder agent gửi câu hỏi tới slack-original@demo bằng rig send](https://homus.dev/photos/CYRJDTcTKhQ-2043.jpg)

Builder agent nhận câu hỏi "Why does Slack use OpenRig messaging?", trả lời rằng agent từng làm Slack đang online và sẽ hỏi nó, rồi gửi câu hỏi tới địa chỉ `slack-original@demo`.

Lệnh trên màn hình:

```
rig send slack-original@demo "Why use OpenRig messaging?"
```

Anh bảo người xem để ý điều vừa xảy ra. Tri thức không chỉ là một file hay một phần của file. Nó là một bộ óc luôn sẵn sàng trong topology này. Ở chỗ làm, bạn vẫn làm thế suốt. Bạn không RTFM (đọc hết cái manual) mọi thứ mình cần làm. Bạn biết ai là chuyên gia của domain đó, và với những việc quan trọng, bạn chỉ cần hỏi họ. Slide "At work, you ask the expert" gạch bỏ dòng "đọc hết mọi thứ trước" bên cạnh chồng tài liệu spec, runbook, README, handbook, docs, wiki, manual, và vẽ mũi tên "ask" từ "you" sang "the domain expert".

Họ đã làm điều đó với OpenRig. Agent có thể nhìn context như các file, nhưng cũng như các agent khác. Mọi thứ đều có địa chỉ. Mọi thứ đều truy vết được. Mọi thứ đều route được. Tìm ra chuyên gia đã làm một việc từ một tháng trước chỉ là một phần của giai đoạn lập kế hoạch cho project.

## 15. Thư viện những bộ óc và distributed context engineering

Vậy có phải anh phải giữ mọi agent online suốt không? Như thế chẳng phải lãng phí compute sao? Không. Anh không thực sự làm vậy. Tới giờ anh có hàng nghìn agent đang ngủ (dormant). Nhưng tất cả đều với tới được bằng một lệnh: `rig ask`. Lệnh này có thể tra file session JSONL của agent để biết nó đã biết gì. Bạn cũng có thể đánh thức một agent và để nó trả lời như một agent đang sống, cho đúng một câu hỏi. Đưa cho agent một lệnh như `rig ask` biến việc đó thành thứ chúng có thể với tới.

![Màn hình Claude Code dùng rig ask để hỏi lịch sử đã lưu của phiên Slack trước, đang offline](https://homus.dev/photos/CYRJDTcTKhQ-2143.jpg)

Với agent đã offline, Builder agent dùng `rig ask` để hỏi lịch sử đã lưu của phiên Slack trước: nó từng search "Slack", chỉ thấy vài mảnh sót lại và kết luận integration mới bắt đầu. Đúng lý do bản Slack thứ hai ra đời.

Lệnh trên màn hình:

```
rig ask demo "What did you search for?" --seat slack@demo
```

Theo anh, việc agent có thể nhờ một agent khác giúp là điều rất trực giác, một khi chúng nhận ra mình thực sự làm được. Vậy là bạn có một thư viện những bộ óc (library of minds) và lịch sử chúng đã làm gì, vì sao, miễn là bạn còn giữ những file session đó. Slide "A library of minds" vẽ lệnh `rig ask reviewer@rig` nối tới một agent review đang ngủ và file `session.jsonl` của nó.

Agent cũng có thể với tới tri thức bên trong anh. Anh chỉ là một agent khác trong topology này. Anh có địa chỉ riêng, và khi một agent cần biết điều anh biết, nó route câu hỏi tới anh, và anh nhận câu hỏi qua Slack. Vậy giờ bạn biết vì sao ngay từ đầu anh lại muốn có integration đó.

Giờ mỗi chuyên gia có thể biết sâu context domain của riêng nó, cùng với đủ phần bản đồ rộng hơn để biết khi nào cần hỏi người khác. Không chỉ là bạn được route tới một chuyên gia. Các chuyên gia này thực sự biết về nhau. Chúng tạo thành một mạng lưới, nhận biết được người khác có thể biết gì. Slide "Context domains" vẽ builder@rig, reviewer@rig, docs@rig và địa chỉ của chính Mike nối chéo với nhau.

Đó là **distributed context engineering**: bạn tổ chức những gì cả một quần thể biết, tri thức sống ở đâu và có thể với tới bằng cách nào. Đây đúng là điều chúng ta vẫn làm với tư cách con người, chỉ là nó không lập trình được mấy. Với agent, nó lập trình được, một khi bạn đã dựng mọi thứ thành một topology.

## 16. Quay lại bài toán Slack và cuộc stress test khi scale out

Quay lại bài toán phát minh lại bánh xe với Slack. Hồi đó, rất nhiều thứ ở trên đã tồn tại rồi, mà anh vẫn gặp vấn đề. Vậy world building thực sự đã sửa được gì? Nếu agent đó tới hôm nay, nó sẽ nhận được một bản project install: một tấm bản đồ góc rộng về các primitive của OpenRig và cách dùng chúng, kèm hướng dẫn đi vào một router skill giúp nó nhớ góc nhìn rộng hơn. Trên màn hình, Builder agent nhận yêu cầu "Load OpenRig's project orientation." và chạy `rig context add` với một manifest.yaml của project world.

Ngay cả về sau trong context window, hay sau một lần compaction, nó vẫn nên nhận ra được hệ thống messaging đã có. Lần theo sợi chỉ đó có thể dẫn nó tới bản integration đã gần xong. Slide "Suppose it knew messaging existed" cho thấy chùm nhìn của agent giờ chạm tới OpenRig messaging và thư mục slack-integration gần xong. Vậy là bạn cho nó độ rộng, và hướng dẫn phải làm gì khi một thứ không có trên bản đồ.

Bạn chưa giải được bài toán vô hạn "không biết mình không biết gì". Bạn chỉ đang cố giải nó cho việc làm trên project của mình. Mục tiêu là minimum viable competence.

Vậy là phần onboarding đã xong từ trước khi OpenRig có khoảnh khắc cất cánh. Điều mới là anh được thấy nó có trụ nổi ở quy mô lớn hơn nhiều hay không. Anh có thể dựng một rig và giao việc thật cho nó ngay. Agent có thể tìm ra context liên quan, rồi với tới những chuyên gia domain sẵn có ở tận đầu kia của mạng lưới, mà anh không phải giải thích gì.

![Slide How the work was divided với ba nhóm community, build teams, release desk](https://homus.dev/photos/CYRJDTcTKhQ-2403.jpg)

Cách chia việc trong đợt scale: đội community nhận đóng góp, các build team chạy trên máy riêng, release desk tích hợp và review. Tất cả chạy trên mấy chiếc Mac mini ở văn phòng và các VPS, nối qua Tailscale.

Anh chia việc thành community, build teams, integration và release. Một số chạy trên mấy chiếc Mac mini trong văn phòng anh, số khác trên VPS. Tất cả nói chuyện với nhau qua Tailscale. Vậy là anh có một đơn vị năng lực lặp lại được (repeatable unit of competence). Anh có thể scale out như xếp các khối xây dựng. Anh dừng ở mức mình cần và trả được tiền, nhưng anh hoàn toàn có thể thêm tiếp. Tất cả những gì anh phải làm là nói chuyện với một lead; lead đó nói chuyện với các lead khác, và chúng đẩy lên những quyết định mà chỉ anh mới đưa ra được ở tầm của anh.

Trong "observatory", UI anh build để quản lý và quan sát hệ thống, có thể cuộn qua những gì các đội này thực sự đang giao. Màn hình Fleet liệt kê từng máy và rig cùng số agent đang chạy. Một ví dụ thật: trên GitHub, một người đóng góp bên ngoài đã thêm các nút để trả lời câu hỏi của agent ngay trong Slack (PR #195, "clickable questions on human decisions"). Anh dùng tính năng này suốt. Các đội của anh lo phần review và merge.

Anh hy vọng cuộc stress test này giúp anh thấy vấn đề của mình nằm ở đâu. Một số agent mới thiếu đường tới vài vùng của thế giới ngay trong lúc onboarding. Ở những agent khác, những con đường bị thiếu đó chỉ lộ ra sau một lần compaction.

Vì anh thực sự hình dung được thế giới đó trong đầu, anh có thể hỏi những câu đơn giản giữa lúc mọi thứ giống như một trận đấu súng: tri thức bị thiếu, hay con đường bị gãy? (Slide: "Missing, or a broken road?") Rồi anh có thể nhờ các agent giúp mình lần theo những đường đi đó và sửa chúng. Đó là chỗ việc làm cho thế giới đọc được bởi con người được đền đáp. Anh duy trì được tất cả những thứ này trong khi nó đang chạy và đang scale out. Anh scale được năng lực bằng cách thêm compute, vì anh đã làm cho năng lực trở nên tái tạo được. Và nhớ rằng đây là những ghế bền vững, tích lũy dần những gì chúng học được theo thời gian. Nó được thiết kế để cả mạng lưới ngày càng thông minh hơn khi họ tiếp tục.

Một luồng việc song song khác mà anh giao cho một đội VPS chuyên trách là con đường getting started của OpenRig, và sửa toàn bộ tài liệu. Vậy là họ đang làm một bài toán onboarding khác, nhưng lần này là giúp con người hiểu cách dùng OpenRig. Slide ghi: từ một bản cài mới, qua set up, tới một task đầu tiên có ích, "vẫn còn vài góc cạnh thô".

## 17. Chia sẻ cả một đội: rig spec, rig bundle và Workshop

Về chủ đề onboarding, OpenRig thật ra có vài primitive rất hay mà anh dùng nội bộ nhưng chưa thực sự cho ai xem. Chúng ta đã quá quen với việc dùng skill và chia sẻ skill cho nhau. Nhưng nếu bạn muốn chia sẻ cả một đội thì sao: tên các agent, spec, skill, plugin, context khởi đầu, cách chúng được quản trị và cả cách chúng làm việc cùng nhau? Nếu bạn có thể đóng gói tất cả lại và chia sẻ dễ như một skill thì sao?

OpenRig có một bản thiết kế cho những đội này, gọi là **rig spec**. Nó chỉ là một file YAML nói tất cả những thứ này khớp với nhau thế nào. Một **rig bundle** là phiên bản đầy đủ (fully hydrated) của nó: bản thiết kế cùng tất cả các file cần thiết, trong một repo hoặc thậm chí một file zip.

![Slide Share a whole team với chuỗi rig spec, rig bundle, openrig.dev/rigs và skill /rigs](https://homus.dev/photos/CYRJDTcTKhQ-2623.jpg)

"Chia sẻ cả một đội": rig spec (các role và cách chúng phối hợp) → rig bundle (thêm skill và context, gói trong một repo hoặc một file) → registry openrig.dev/rigs (tìm một đội hoặc gửi đội của bạn) → skill `/rigs` dựng đội cho bạn.

Anh nghĩ ai cũng đang tự hỏi điều gì sẽ tới sau skill. Skill thì lúc nào cũng hữu ích, nhưng liệu có thứ gì lớn hơn đang tới? Anh biết nhiều người đang làm về ý tưởng này, nhưng nó có thể là một thứ như rig, nơi ta chia sẻ cả đội cùng toàn bộ thế giới của nó. Cái này chạy được ngay hôm nay và bạn có thể thử ngay. Đó là thứ anh đã dùng để scale qua tất cả những máy mới kia: anh thả dù một đội xuống một VPS và nói "các bạn là build team", "các bạn là review team".

Nên anh đưa nó lên openrig.dev, trên một trang tên là [Rigs](https://openrig.dev/rigs). Đây chỉ là nơi mọi người, kể cả anh, có thể gửi rig của mình lên, giống một skill registry. Một rig có thể kèm nhiều hay ít cấu hình và context tùy ý. Rig của anh là ví dụ cho kiểu bạn nhận được "nguyên cả gói" ngay từ đầu, để dùng như một tài liệu tham khảo.

Anh hướng người xem tới rig tên là [Workshop](https://openrig.dev/rigs/workshop). Đây là một rig bundle: một đội dev bốn agent dựa trên đúng template anh đã dùng để build OpenRig. Động lực là lúc đó có quá nhiều PR đổ về, và anh nhận ra đây hẳn là một vấn đề phổ biến trong open source. Nếu bạn có một project người ta thích và muốn giúp bạn build, thì cho họ một bước khởi đầu để tạo PR, hoặc chỉ để review PR, sẽ rất tuyệt. Workshop chính là thứ đó. Nó là rig đầu tiên, dành cho những ai muốn giúp anh build và cải thiện OpenRig. Slide ghi: hãy tưởng tượng các project open source không chỉ ship code mà ship cả một đội đã biết cách làm việc trên chúng.

Anh cũng đã làm gọn phần onboarding. Anh đang cố đưa nó về hiệu ứng "một lệnh và mọi thứ tự trải ra trước mắt bạn". Cách mới này chỉ yêu cầu bạn cài rig skill từ skills.sh rồi để agent chạy nó. Nó sẽ tự cài và set up cho bạn, và giờ các agent của bạn biết cách dùng và trở thành một phần của một hệ thống OpenRig. Slide "Try one" ghi: cài skill `/rigs`, rồi gõ `/rigs` trong agent bạn đang dùng, để có một đội trên project của bạn. Phần mô tả video ghi lệnh chạy trong thư mục project:

```
npx skills add mvschwarz/openrig --skill rigs
```

Theo phần mô tả, bạn chọn agent định dùng khi được hỏi, rồi gõ `/rigs` trong Claude Code hoặc `$rigs` trong Codex, đưa cho nó trang Workshop và nói bạn muốn làm việc gì.

Rig bundle này và skill có thể dùng làm tài liệu tham khảo cho cách anh ghép mọi thứ lại với nhau. Cứ thoải mái tùy biến nó cho project của bạn, hoặc tạo rig riêng và gửi lên trang Rigs. Slide "Customize it, and submit your rig" gợi ý: giữ nguyên đội, thay thế giới context bằng của bạn, tùy biến role và spec. Một thứ anh đang cần giúp ngay lúc này là hỗ trợ thêm các harness khác (hiện có Claude Code, Codex và Pi), vì anh rất khó tự test chúng, và sẽ rất tuyệt nếu được cùng làm việc đó.

Anh đang dùng đây như một thử nghiệm, để xem mô hình này có phải là một cách lặp lại được để giúp bất kỳ project open source nào khác không. Có thể nó giúp với nút thắt quanh việc review PR mà ta đang gặp, vì một rig agent có mạng lưới, với đường đi tới toàn bộ context của project, có vẻ sẽ ship PR tốt hơn và review code tốt hơn. Đó là ý tưởng đằng sau một đơn vị năng lực có thể ship được (shippable unit of competence). Nếu bạn thả dù cả đội xuống một VPS 10 đô la và nó có ích ngay lập tức, anh nghĩ đó là một lập luận khá thuyết phục.

## 18. Vấn đề nằm trước bước search

Để khép lại, anh nói về bài toán phát minh lại bánh xe. Lúc đầu nó có vẻ buồn cười, rồi nó thành phiền, rồi nó thành một bức tường bạn không thể scale vượt qua cho tới khi sửa được nó. Vì vậy cố giải nó có cảm giác là một trong những bài toán quan trọng nhất để làm, và nó đẩy anh đi tận tới gốc rễ của cách chúng ta nghĩ về tri thức.

Đáng tiếc là câu trả lời không dễ như thêm một search tool nữa. Vấn đề xảy ra trước bước search. Các agent của anh thậm chí không biết phải hỏi câu gì. Nếu anh muốn chúng chạy có năng lực mà không phải giải thích mọi thứ, cách tiếp cận world building này có vẻ hứa hẹn.

"The problem happened before the search": thêm search tool không giúp gì khi agent chưa biết phải search cái gì.

Anh quyết định thứ gì thuộc về bản đồ, và giải thích cách tìm thứ không có trên đó. Nếu bạn đang ở cùng hoàn cảnh, đó là thứ bạn có thể thử với rig bundle Workshop này.

Anh nói sẽ cố dành nhiều thời gian hơn để trả lời câu hỏi và trò chuyện, và nghĩ Twitter có lẽ là nơi tốt nhất, dễ nhất. Tài khoản X cá nhân của anh là nơi bạn có thể nói chuyện với "Mike con người" (Mike the Human). Còn nếu muốn nói chuyện với các agent vận hành OpenRig, bạn có thể theo dõi tài khoản OpenRig của chúng. Anh đã cắm đầu làm việc này rất lâu và gần như không xuất hiện ở đâu ngoài mấy video thỉnh thoảng. Nhưng anh nhận được rất nhiều cảm hứng từ những người kể cho anh họ dùng OpenRig thế nào và nó còn dở ở đâu. Nên anh sẽ thực sự cố dành thời gian cho chuyện này, vì nó định hướng thứ anh build tiếp vào OpenRig.

Và một điều nữa. Anh đã dùng chính kỹ thuật world building này lên người xem suốt video, có thể bạn đã để ý. Bạn vốn đã biết về ontology và lâu đài, về câu chuyện và những con đường. Anh chỉ thêm vào những ý tưởng lạ, cho chúng một chỗ đứng trong một thế giới, rồi nối chúng với những gì bạn đã biết. Anh hy vọng sau đó tâm trí bạn tự bật lên và nối nốt các chấm còn lại, vì với anh, đó là hướng mà context engineering sẽ đi tới tiếp theo.

## Nguồn và liên kết

- Tên gốc: How My AI Civilization Actually Works
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=CYRJDTcTKhQ](https://www.youtube.com/watch?v=CYRJDTcTKhQ)

- Kênh YouTube OPENRIG (Mike Schwarz): [youtube.com/channel/UCtVTmZdo7U1RzUWm4F0WWBQ](https://www.youtube.com/channel/UCtVTmZdo7U1RzUWm4F0WWBQ)

- OpenRig, mã nguồn (README có hướng dẫn cài, khái niệm seat, rig và star history): [github.com/mvschwarz/openrig](https://github.com/mvschwarz/openrig)

- Trang Rigs trên [openrig.dev](https://openrig.dev), nơi tìm và gửi rig: [openrig.dev/rigs](https://openrig.dev/rigs)

- Rig Workshop, đội bốn agent để đóng góp cho OpenRig: [openrig.dev/rigs/workshop](https://openrig.dev/rigs/workshop)

- Anthropic, "Effective context engineering for AI agents" (được nhắc trong phần mô tả video): [anthropic.com/engineering/effective-context-engineering-for-ai-agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

- Joshua Foer, Moonwalking with Einstein, cuốn sách về memory palace mà Mike nhắc tới: [penguinrandomhouse.com](https://www.penguinrandomhouse.com/books/301277/moonwalking-with-einstein-by-joshua-foer/)

Nguồn: https://homus.dev/talks/how-my-ai-civilization-actually-works · cập nhật 2026-10-17