Đội agent biết ship: vận hành một everything factory với OpenRig
Cài OpenRig trong Claude Code, cho đội bốn agent sửa một bug tới PR thật, rồi đi qua seat, pod, queue, wake, workflow, RigBundle và teams of teams.
✓ Đã duyệt độc lập · cập nhật 07/11/2026 · 20 min
1. Một "everything factory"?
Mike Schwarz mở đầu: nếu bạn giống anh, có lẽ bạn đã dành phần lớn đời mình ở một nơi có cảm giác như một nhà máy. Có thể bạn cũng vậy, có thể ngay lúc này bạn đang làm việc trên sàn nhà máy (factory floor). Anh hỏi: bạn đã bao giờ nghĩ rằng có lẽ người hợp để thực sự điều hành một nhà máy lại chính là bạn?
Theo Mike (video đăng ngày 04/11/2026), ý tưởng software factory đang trở nên gần như mainstream. Nhưng anh nghĩ những thứ này còn hơn thế nhiều: anh nghĩ chúng có thể giống những everything factory. Vậy everything factory là gì? Mọi thứ? Đúng nghĩa đen là mọi thứ? Anh nói thật lòng là anh cũng không chắc, nhưng rồi anh giải thích ý mình.
2. Software factory: plan, build, test, review, ship
Theo Mike (video đăng ngày 04/11/2026), hoá ra agent rất giỏi không chỉ ở việc build phần mềm mà còn ở việc vận hành chính quy trình đó. Quy trình ấy gọi là Software Development Lifecycle, hay SDLC: về cơ bản là một chuỗi bước chạy theo vòng lặp, trong đó bạn plan, build, test, review và ship.

Anh build OpenRig theo đúng phương pháp này. Việc đầu tiên anh phải làm cho giỏi là chạy chính vòng lặp SDLC đó một cách đều đặn (consistently). Theo lời anh trong video đăng ngày 04/11/2026, chuyện đó bắt đầu khoảng sáu tháng trước, từ đó vòng lặp này chạy để build chính OpenRig, và trong khoảng một tháng trở lại đây nó tăng tốc thật sự.
Vậy có thể đẩy cách này đi xa tới đâu? Agent thật sự build được bao nhiêu loại thứ theo cách này? Mike nói anh đã thử nghiệm rất nhiều, và nó rộng hơn nhiều so với chỉ phần mềm (theo video đăng ngày 04/11/2026). Anh làm chính video này bằng SDLC, nhưng anh không thực sự biết nó đi xa được tới đâu, và chắc chắn không biết sáu tháng nữa nó sẽ ở chỗ nào.
3. OpenRig, teams of teams và đổi altitude
Vậy OpenRig là gì và vì sao dùng nó? Theo Mike (video đăng ngày 04/11/2026), OpenRig đặt các coding agent của bạn vào những đội gọi là rig, rồi cho bạn một cách vận hành các đội đó như một nhà máy hay một tổ chức. Dùng vòng lặp SDLC này, bạn thôi quản lý từng agent riêng lẻ, bắt đầu quản lý các đội, rồi đội của các đội (teams of teams).
Khi chuyện đó xảy ra, anh nói bạn phải đổi độ cao (altitude) của chính mình. Ý anh là thay vì ở dưới sàn nhà máy tự kiểm từng PR, bạn như đang ở trên mission control, điều hành nhà máy. Ở độ cao lớn hơn, bạn vận hành bức tranh lớn và bắt đầu tin để nhà máy lo phần chi tiết (theo Mike, video đăng ngày 04/11/2026).
Theo Mike (video đăng ngày 04/11/2026), cách nhanh nhất để một nhà máy như vậy chạy được là một rig bundle: một đội làm sẵn (off-the-shelf team) mà ai đó đã làm cho chạy được. Anh nói bạn không cần biết nhiều để cài một bundle, nhưng nếu nắm được những điều cơ bản thì bạn khai thác được nhiều hơn rất nhiều.
4. Phần 1: cài OpenRig ngay trong coding agent
Mike cài OpenRig từ đầu và cho nó chạy vòng lặp này trên một project thật. Mục tiêu của anh là đưa cho người xem một mental model dùng được về hệ thống này. Điểm xuất phát là coding agent của bạn, ở đây là Claude Code (demo trong video đăng ngày 04/11/2026).
Anh đang ngồi ở laptop, nhưng terminal agent này chạy trên một VPS, và đội agent cũng sẽ chạy ở đó; laptop chỉ là nơi anh "lái" (pilot) (demo trong video đăng ngày 04/11/2026).
Anh chỉ việc nhờ Claude cài OpenRig, và nó bắt đầu bằng cách thêm skill cài đặt của OpenRig tên là rigs. Slide lúc đó ghi "/rigs is a skill. It tells the agent how to set up OpenRig." Phiên Claude Code trên màn hình (demo trong video đăng ngày 04/11/2026):
❯ Can you please install OpenRig for me?
● I'll add the rigs skill for Claude Code.
● Bash(npx skills add
https://github.com/mvschwarz/openrig/tree/v0.7.5/skills/rigs
--skill rigs --agent claude-code)
└ Found 1 skill: rigs Installation scope: Project
● I'll use this project and confirm the install.
● The rigs skill is installed.
npx skills add từ repo OpenRig (bản v0.7.5 trên màn hình), phạm vi cài là Project (demo trong video đăng ngày 04/11/2026).Chạy xong thì bạn chỉ cần nói điều mình muốn. Với ví dụ này, Mike muốn demo toàn bộ quy trình end to end: set up, bắt đầu một project, sửa một bug và hy vọng ship được một PR thật. Installer dẫn Claude qua các bước cài; theo Mike (video đăng ngày 04/11/2026), lúc này bạn chỉ cần xem, có lẽ không phải làm gì, nhưng muốn lái thêm thì cứ việc.
Cài xong, nó mở Herdr; màn hình ghi "Herdr: several agents' terminals in one window". Theo Mike (video đăng ngày 04/11/2026), khi khởi động, OpenRig chạy ngầm một agent gọi là operator. Nên có một bước chuyển giao (handoff): việc của phiên Claude Code đầu tiên chỉ là cài OpenRig và đưa bạn tới operator, và tới đây nó đã xong.
Theo Mike (video đăng ngày 04/11/2026), operator là một agent đặc biệt có việc là giúp bạn vận hành chính OpenRig. Ở đây nó giúp chọn đội và gợi ý Workshop. Anh mô tả Workshop là một đội khởi đầu làm sẵn, đóng gói thành một rig bundle như vừa nói.

Anh trả lời yes, và operator chạy một lệnh để khởi động Workshop. Anh bảo hãy để ý dòng đó: đó là operator bảo OpenRig dựng cả đội lên. Từ một lệnh ấy Workshop khởi động, rồi operator đặt terminal của các agent vào Herdr cho bạn; trên màn hình, workshop là một space mới trong Herdr ("one tab per rig") với bốn agent orch-lead, dev-build, dev-qa và dev-review (demo trong video đăng ngày 04/11/2026).
Từ đây, lead agent của Workshop là đầu mối liên lạc chính của bạn: operator chạy OpenRig, còn lead chạy project của bạn. Mike nói cả đội như đột nhiên xuất hiện, và bạn có một nhà máy nhỏ sẵn sàng ship. Về cơ bản chỉ là một skill, một lần handoff, và giờ có thể giao việc cho đội (demo trong video đăng ngày 04/11/2026).
5. Xem cả đội, nói chuyện với lead
Trước khi giao việc, Mike đi một vòng qua các tool mà OpenRig cung cấp. Đầu tiên là TUI (Terminal User Interface), anh ví như một dashboard. Bảng trong TUI cho thấy trạng thái của từng agent và việc chúng đang làm; cùng đội đó còn được hiển thị dạng sơ đồ, và anh thấy hình dung chúng như một topology là có ích (demo trong video đăng ngày 04/11/2026).

Theo Mike (video đăng ngày 04/11/2026), lúc này có ba điều cần nắm. Một, bạn theo dõi được cả đội cùng lúc trong TUI. Hai, bạn nói chuyện được với bất kỳ agent nào trong terminal của nó, nhưng quản lý một cuộc trò chuyện thì dễ hơn nhiều, và anh khuyên đó nên là lead agent. Ba, các agent nói chuyện với nhau và làm việc bằng OpenRig CLI.
Slide "Watch the team. Talk to the lead." tóm ba ý đó thành ba cột: Watch (TUI với lead, build, qa đang working và review idle), Talk (bạn hỏi "Can you fix the login bug?", lead đáp "On it. I'll get the team started.") và CLI, nơi rig ps trả về "4 seats running" và rig send dev-build trả về "Message sent" (slide trong video đăng ngày 04/11/2026).
6. Một bug nhỏ: login bug
Mike chọn bug này vì nó dễ thấy bằng mắt và chắc sẽ xác nhận nhanh khi được sửa. Anh gọi nó là login bug. Bối cảnh: anh dùng subscription Claude và Codex của mình cho các agent này chạy (theo video đăng ngày 04/11/2026).
Có người nhận ra rằng nếu bạn bị đăng xuất khỏi subscription đó, OpenRig không cập nhật trạng thái trong TUI. Agent được báo là ready, nhưng nó không thể ready vì đã bị đăng xuất. Nên đội sẽ sửa để trạng thái đó trung thực (demo trong video đăng ngày 04/11/2026).

Để theo dõi cách đội làm việc, anh đi qua ba ý nữa: ai ở trong đội, các agent phối hợp với nhau thế nào, và chúng đang làm gì (theo video đăng ngày 04/11/2026). Anh tháo từng ý một.
7. Giải phẫu một rig: model, harness, session, seat, pod
Trước tiên, các agent này là ai? Workshop chỉ là tên của một rig, và rig là từ của OpenRig cho một đội. Theo Mike (video đăng ngày 04/11/2026), rig này có một lead orchestrator, một builder, QA và một agent review. Mỗi vị trí có tên như vậy là thứ anh và nhóm gọi là seat.
Anh nối với những gì người xem đã biết và chỉ cách các lớp chồng lên nhau. Ở gốc là model, ví dụ Opus 5.5: token vào, token ra. Harness bọc model và cho nó tool: Claude Code, Codex, Pi. Theo Mike (video đăng ngày 04/11/2026), có thể trộn cả ba trong cùng một đội, và điều này rất có ích vì mỗi cái giỏi những việc khác nhau, nên chúng bắt được lỗi của nhau.
Khi harness đang chạy, đó gọi là session: cuộc trò chuyện của một agent. Session nằm trong thứ anh và nhóm gọi là seat; đây là thuật ngữ của OpenRig, và anh nói đây là chỗ mọi thứ có thể bắt đầu mới với bạn. Theo Mike (video đăng ngày 04/11/2026), seat là chỗ của agent trong đội, có một địa chỉ ổn định trông giống địa chỉ email (trên slide "Session and seat" là orch-lead@workshop). Session của agent đến rồi đi, nhưng seat ở lại: cùng tên, cùng role, cùng địa chỉ. Bạn thay session ra vào seat được, và như thể agent chưa bao giờ rời đi.
Các seat cùng làm một phần việc gom lại thành pod. Theo Mike (video đăng ngày 04/11/2026), pod thường được xây quanh một context domain, mà anh giải thích là kiến thức và skill để giỏi đúng việc đó. Rig bọc các pod, là lớp ngoài cùng, cả đội. Kết quả là một hệ thứ bậc với lead ở trên cùng.

Một câu anh thỉnh thoảng được hỏi: sao phải có cấu trúc, sao không để một bầy (swarm)? Theo Mike (video đăng ngày 04/11/2026), cùng lý do các tổ chức con người có cấu trúc: con người đã phát triển khái niệm sở hữu (ownership) và giao việc (delegation). Thiếu nó, agent sẽ thiếu phương hướng. Anh thấy một swarm rồi cũng sẽ tự phát minh ra cấu trúc, nên bạn cứ là người thiết kế nó. Slide "An org chart for agents" đặt "each seat owns a job" cạnh "a flat swarm, nobody owns the job" (slide trong video đăng ngày 04/11/2026).
8. rig send, rig capture và queue
Agent nói chuyện với nhau thế nào? Theo Mike (video đăng ngày 04/11/2026), chúng gõ vào terminal của nhau: rig send đặt một tin nhắn vào prompt của agent khác và bấm Enter thật. Không có SDK, không có plugin; về lý thuyết, cái gì chạy được trong terminal thì có thể vào đội. Chiều ngược lại cũng được: rig capture cho một agent đọc những gì đang có trên màn hình của agent khác ngay lúc đó. Nếu lead orchestrator muốn biết builder đang làm gì, nó không phải tốn token để hỏi, nó chỉ cần nhìn.
Trên slide "rig send", lead (Codex CLI) chạy lệnh dưới đây, và Claude Code ở dev-build@workshop nhận tin "From: orch-lead@workshop" rồi đáp "I'll compare the login screen with the readiness check." (demo trong video đăng ngày 04/11/2026):
rig send dev-build@workshop "Check why an agent waiting for login is reported ready."
Theo Mike (video đăng ngày 04/11/2026), đôi khi agent bận và một tin nhắn có thể bị lỡ, bị quên, lạc đâu đó trong chat. Nên nếu một việc cần được theo dõi, ví dụ công việc, agent dùng một hệ thống queue đơn giản mà OpenRig chạy ở nền. Một queue item ghi việc là gì và giao cho ai. Ở đây có một task tên "Fix the login bug", vừa được giao cho builder (demo trong video đăng ngày 04/11/2026). Lệnh lead chạy trên màn hình:
rig queue create --destination dev-build@workshop --summary
"Say when login is needed" --body "Fix issue #6: a login
prompt must not be reported ready. Keep real timeouts
distinct."
Trong ví dụ, builder sửa bug, và có thể thấy nó làm việc trong terminal. Rồi nó chuyển cho agent QA để test. Theo Mike (video đăng ngày 04/11/2026), mỗi agent cập nhật queue item là đã xong hoặc đã chuyển (handed off), nên bạn lúc nào cũng thấy việc đang ở đâu.
Ba terminal cạnh nhau cho thấy chuỗi đó (demo trong video đăng ngày 04/11/2026): builder (Claude Code) báo "The change is ready for QA." và chạy rig queue handoff qitem-0142 --to dev-qa@workshop --body "Try the login case and a real timeout."; QA (Pi) báo "Both cases checked. I'll send the change and results for review." và chạy rig queue handoff qitem-0143 --to dev-review@workshop --body "Review the change and QA results in the slice."; reviewer (Codex CLI) nhận handoff và viết "I'll read the diff and the QA notes in the slice, then approve it or send it back with changes."
9. Workspace: project, mission và slice
Nếu task này lớn hơn, nó sẽ cần chỗ để theo dõi các plan, spec và test. Task này nhỏ nên không có gì. Nhưng nó dẫn tới file system: theo Mike (video đăng ngày 04/11/2026), workspace về cơ bản là bộ nhớ chung của đội. Anh nói có lẽ bạn đã để ý agent làm việc tốt hơn khi được cho một workspace ngăn nắp để "nghĩ thành tiếng" bằng cách viết file markdown, vì chúng có thể tra lại sau nếu quên, và agent khác có thể xem ở đó nếu cần nhận tiếp việc.
Slide "Think out loud in Markdown" cho ví dụ một SPEC.md với ba mục Goal ("Report when an agent needs to log in."), Keep working ("A real startup timeout stays a timeout.") và Check ("Try both cases before calling it done."), kèm dòng "Written down so another conversation can read it and carry on" (slide trong video đăng ngày 04/11/2026).
Theo Mike (video đăng ngày 04/11/2026), việc được tổ chức trên đĩa trong folder workspace thế này. Trên cùng là các project; file trong đó cho mọi agent một quy ước nhất quán để thấy suy nghĩ của nhau. Trong folder project là mission: một cách gom việc lại thành một kết quả lớn hơn, hoặc như một chủ đề. Ví dụ anh dùng mission để tổ chức từng release của OpenRig.
Trong mission là các slice. Theo Mike (video đăng ngày 04/11/2026), slice cũng chỉ là một folder, nhưng là cách anh cố chia việc thành từng phần quản lý được; anh thường map một slice với một PR, nhưng đó không phải luật cứng. Login fix ở đây là một slice. Lệnh rig scope cung cấp cho agent mọi tool cần để tạo mission và slice, và để cập nhật chúng. Trên màn hình, lead chạy (demo trong video đăng ngày 04/11/2026):
rig scope slice create next-release login-required --template bug-fix └ missions/next-release/slices/01-login-required/ rig scope slice show missions/next-release/slices/01-login-required
File SPEC.md của slice đó ghi: "Report when login is needed. Keep real timeouts distinct. Check both cases." (demo trong video đăng ngày 04/11/2026).
Lùi lại một bước, Mike gom ba điều: who, what và how. Rig cho biết ai ở trong đội. Mission và slice cho biết đội đang làm gì. Queue và những tin nhắn đơn giản trong terminal để phối hợp, đó là how (theo video đăng ngày 04/11/2026).

10. Bản fix được ship
Mike quay lại xem đội đã làm gì với bug. Theo anh, TUI sau khi sửa giờ báo cần đăng nhập thay vì báo ready, đúng điều Claude đã cố báo cho anh, và đó là bug vừa được sửa. Đây là một PR thật trên GitHub; slide ghi "A real PR. On GitHub, open to anyone." (demo trong video đăng ngày 04/11/2026).
Vậy là từ một máy mới tinh chạy trên cloud, anh có một đội tự lên plan được và ship PR cho anh. Nhưng thật lòng, anh nói cả một đội như thế là quá tay (overkill) cho một bug. Theo Mike (video đăng ngày 04/11/2026), chỗ nó bắt đầu hợp lý là khi bạn có một project lớn, nhất là project có thể mất nhiều tuần.
11. Phần 2: khi việc không dừng lại
Thêm nữa, theo Mike (video đăng ngày 04/11/2026), khi bạn làm ra một thứ, thường nó không dừng ở đó: sản phẩm có thêm ý tưởng, bạn tìm ra bug, bạn cần thứ giữ cho việc đó tiếp diễn theo thời gian. Đó là lúc bạn cần một software factory.
Để làm vậy, anh nói bạn chỉ cần chat với lead agent về ý tưởng và những bug đã tìm ra. Theo Mike (video đăng ngày 04/11/2026), bạn sẽ thấy nhiều ý tưởng thực ra đến từ chính các agent khi dùng và test sản phẩm, như một phần của vòng lặp này. Dù theo cách nào, bạn biến chúng thành plan để đội build. Trên slide "Chat with the lead", câu hỏi "What should we improve after the login fix?" được lead trả lời "Make team startup easier to follow. Then make it clearer who has the next task." (demo trong video đăng ngày 04/11/2026).
Theo Mike (video đăng ngày 04/11/2026), lead biến các plan đó thành slice, rồi slice được gom vào mission tiếp theo. Roadmap thực ra chỉ là các mission làm từ slice. Mỗi release là quy trình SDLC này lặp qua các slice, và nó cứ tiếp tục, release này tới release khác, miễn là bạn còn tạo roadmap cho nó build.

rig scope mission show next-release trả về "Goal: make the team easier to run.", còn rig scope slice ls --mission next-release liệt kê 01-login-required (done), 02-team-startup (building), 03-task-handoff (planned) (demo trong video đăng ngày 04/11/2026).12. Going idle và wake
Mike nói có một trục trặc mà có lẽ bạn đã để ý nếu từng thử kiểu này: sau khi làm việc, agent đi vào idle, như đang ngủ, cứ nằm yên trong terminal. Theo Mike (video đăng ngày 04/11/2026), tất cả các agent đó sẽ nằm đó mãi không làm gì cho tới khi bạn tự tay nhắc (nudge) chúng; cái này gọi là babysitting. Orchestrator thực ra có trách nhiệm ngăn chuyện này và giữ cho rig chạy.
Vậy cái gì đánh thức một agent? Hiển nhiên là bạn gõ vào terminal. Theo Mike (video đăng ngày 04/11/2026), OpenRig cho thêm hai cách: agent khác dùng rig send để làm việc đó, và tiến trình server của OpenRig cũng làm được. Tiến trình này không phải agent, chỉ là phần mềm thường chạy control plane ở nền; slide "Who can type into an agent's terminal?" liệt kê ba nguồn: you, another agent (rig send) và OpenRig's daemon (its control plane).
Vậy sửa vấn đề babysitting thế nào? Theo Mike (video đăng ngày 04/11/2026), trên một project dài không ai ở đó để gõ tin tiếp theo, nên OpenRig gõ. Tin đó gọi là một wake. Rig watchdog là một wake theo giờ hoặc theo điều kiện, kiểu "check on this if it isn't done". Anh nói các harness như Claude Code đã làm được việc này, nhưng loại này set up được để dùng cùng một cái cho mọi harness của bạn.

13. Workflow: harness cho orchestrator, vòng lặp trong vòng lặp
Theo Mike (video đăng ngày 04/11/2026), rig workflow được xây trên wake: một graph các bước. Mỗi bước là một queue item có chủ, và khi một agent xong bước của nó, bước tiếp theo vào queue của chủ tiếp theo, rồi OpenRig đánh thức agent đó. Anh nói OpenRig nhắc, không phải anh. Slide "A harness for the orchestrator" vẽ rig workflow gồm wake, queue (fix login đã xong, test it, review it, merge) và graph plan, build, test, review cạnh lead, "the orchestrator".
Một cách khác anh dùng: set up workflow như những reminder, để khi một slice hay một mission xong, những việc orchestrator thường quên như cập nhật docs hay dọn worktree vẫn được làm; anh nói lần nào cũng là một thứ khác. Theo Mike (video đăng ngày 04/11/2026), workflow giữ orchestrator trên đường ray bằng queue và wake để nó không trôi đi hay quên. Nên workflow giống một harness bổ sung, nhưng chỉ dành cho orchestrator.
Và các vòng lặp này lồng vào nhau. Theo Mike (video đăng ngày 04/11/2026), slice là vòng trong: plan, build, test, review, rồi lặp lại. Mission là vòng ngoài: slice này tới slice khác, với lead merge chúng vào code base thành một release. Project là vòng ngoài nữa bọc quanh, đưa bạn từ mission này sang mission khác; với anh, đó là release này tới release khác.
Theo Mike (video đăng ngày 04/11/2026), orchestrator vẫn làm mọi phần suy nghĩ thay bạn, nó chỉ cần thỉnh thoảng được nhắc. Nếu set up như vậy, một workflow có thể giữ một đội chạy nhiều tuần, có khi nhiều tháng.
Đó là software factory: ý tưởng và bug đi vào một phía, phần mềm chạy được đi ra phía kia, đã được test và review. Theo Mike (video đăng ngày 04/11/2026), bạn vẫn là product owner, và bạn quyết định khi nào ship và ship cái gì.
14. Phần 3: mở RigBundle, team as code
Vậy là có một đội tự giữ mình chạy được. Giờ Mike mở cái hộp mà đội đó được đóng vào: rig bundle. Anh nói nó đơn giản đến bất ngờ: mọi thứ anh cho xem tới giờ chỉ là file trên đĩa ở đâu đó, và đội này cũng vậy. Bạn đã nghe infrastructure as code; đây giống như agent teams as code. Theo Mike (video đăng ngày 04/11/2026), anh cố ý mô phỏng nó theo Terraform và Docker.
Theo Mike (video đăng ngày 04/11/2026), rig spec chỉ là một file YAML mô tả đội được sắp xếp ra sao. Agent spec ghi lại role và skill của từng agent. Rig Workshop vừa cài là một rig bundle, một đội hoàn toàn portable: rig spec và agent spec đóng gói cùng nhau để ai có OpenRig cũng khởi động được cùng đội đó.
Bên trong chỉ là những file này trong một folder. Theo Mike (video đăng ngày 04/11/2026), rig là topology của đội: hai pod, bốn seat, mỗi seat chạy harness nào. Nội dung rig.yaml trên slide "What's in a RigBundle?":
name: workshop pods: orch: [lead] dev: [build, review, qa] edges: lead → build culture_file: CULTURE.md
Rồi có một file YAML agent cho mỗi agent trong rig: lead, builder, reviewer và QA. Theo Mike (video đăng ngày 04/11/2026), mỗi YAML liệt kê skill, role và các file onboarding của agent đó. Còn CULTURE.md là nơi bạn định nghĩa các đội nên làm việc với nhau thế nào.
Anh bảo hãy để ý cái không có ở đây: công việc của bạn. Theo Mike (video đăng ngày 04/11/2026), bundle ship đội và cách làm việc của đội, còn mission, slice và workflow là phần bạn set up với lead cho project của chính mình.

Theo Mike (video đăng ngày 04/11/2026), bundle Workshop có một con trỏ đặc biệt tới thứ gọi là project world: một GitHub repo bạn có thể set up để chia sẻ context của project với bất kỳ ai bạn muốn. Với Workshop, anh dùng nó để chia sẻ kiến thức nội bộ về cách làm OpenRig chạy tối ưu. Anh nói cái này hoàn toàn tuỳ chọn, nhưng chia sẻ context như vậy rất hay.
Vậy theo Mike (video đăng ngày 04/11/2026), một rig bundle là cả đội, dưới dạng code, ở một chỗ, với context cũng được làm cho portable. Nó giống một nhà máy chạy SDLC đóng trong một cái hộp.
15. Không chỉ là phần mềm
Mike muốn nhấn một điểm quan trọng. Theo anh (video đăng ngày 04/11/2026), software factory chỉ là một cách hữu ích để cấu hình các primitive của OpenRig; đừng nghĩ đó là mọi thứ nó làm, hay bạn phải dùng nó theo cách đó. Các primitive được cố ý làm linh hoạt và nhắm tới việc tuỳ biến hoàn toàn cho bất cứ nhu cầu nào của bạn.
Đó là lý do anh cứ vật lộn tìm tên cho thứ mình đang chạy: một network, một topology, một population, hay một factory? Anh vẫn đang tìm. Và việc không nhất thiết phải là phần mềm: theo Mike (video đăng ngày 04/11/2026), bất cứ gì bạn nặn được vào quy trình SDLC này thì một rig làm được. Đó là ý tưởng đằng sau everything factory.
Anh nói các bundle này làm anh nhớ tới Docker Compose, hay thậm chí Skills, nhưng cho cả một đội agent. Theo Mike (video đăng ngày 04/11/2026), ai có một setup đội tốt đều có thể chia sẻ nó lên trang rigs của OpenRig.
16. Phần 4: teams of teams
Và đó mới chỉ là một đội. Theo Mike (video đăng ngày 04/11/2026), Workshop có thể tiếp tục là đội build của bạn vì nó giỏi việc đó. Tiếp theo, bạn có thể muốn thêm một rig product management có setup khác hẳn, giúp phát triển roadmap cho bạn. Rồi khi testing, documentation hay marketing thành một việc thật sự, bạn thêm các rig chuyên trách cho từng việc. Đó là ý tưởng teams of teams: một mạng các rig có thể chạy cả một sản phẩm.
Theo Mike (video đăng ngày 04/11/2026), mỗi đội giữ những gì nó học được: note, skill, instruction, kinh nghiệm của nó tích luỹ dần theo thời gian, nên chuyên môn cộng dồn (compounds). Đội làm càng lâu thì càng trở thành chuyên gia trong mảng của nó. Slide "Each team keeps what it learns" đặt workshop ("builds the software") ở giữa docs, product, marketing, testing, nối với AGENTS.md (instructions), NOTES.md (notes), skills/ và LEARNED.md ("what it learned") (slide trong video đăng ngày 04/11/2026).
Theo Mike (video đăng ngày 04/11/2026), giữa các rig, chủ yếu là lead agent nói chuyện với các lead khác, và đó cũng chủ yếu là những agent bạn sẽ nói chuyện cùng. Cách này giúp các agent trong mỗi rig giữ context window tập trung vào công việc.
17. Across machines: đội chạy ở đâu
Đã nói về who, what và how; tiếp theo là where: cái này chạy ở đâu? Theo Mike (video đăng ngày 04/11/2026), nó chạy được trên laptop, nhưng tốt hơn nhiều là chạy trên một server, một Mac mini hay một VPS, để lúc nào cũng sẵn sàng 24/7. Hết compute thì bạn thêm server với bất cứ thứ gì mình có, vì các đội này như những khối xây dựng portable.
Theo Mike (video đăng ngày 04/11/2026), nếu agent bạn cần ở trên một máy khác, bạn chỉ cần thêm tên host vào địa chỉ, rồi OpenRig route tin nhắn cho bạn; cả topology nói chuyện với nhau theo cách đó. Trên slide "Across machines", lead của workshop trên host mac-mini-1 gửi tới rig testing trên host vps-1:
rig send orch-lead@testing@vps-1 "Check the release candidate."

Theo số đo của Mike (video đăng ngày 04/11/2026), setup chạy OpenRig và làm ra video này giờ chạy trên khoảng 18 host như vậy; nó đúng là những gì anh vừa cho xem, chỉ scale ra một chút. Anh nói có khoảng 300 agent được set up, và dù con số dao động, thường có khoảng 100 tới 200 agent làm việc trong ngày, trên khoảng 60 rig. Slide lúc đó ghi "The fleet that builds OpenRig. 300+ agents."
Theo Mike (video đăng ngày 04/11/2026), cách này scale một cách tự nhiên nhờ hình dạng khối xây dựng lặp lại được; anh gọi chúng là "shippable units of competence".
18. Ghép lại, và điều hành nhà máy
Mike tóm lại cách mọi thứ khớp với nhau (theo video đăng ngày 04/11/2026): nhờ agent của bạn set up, khởi động một đội, và đội đó làm được bất cứ gì có thể build như phần mềm. Workflow giữ nó chạy, rig bundle cho bạn chia sẻ nó, rồi bạn có thể lớn dần một cách tự nhiên, từng rig một. Việc của bạn là nói chuyện với một nhúm agent rồi lái.
Liệu nó cứ thế chạy mãi? Theo Mike (video đăng ngày 04/11/2026), không, bạn phải bảo trì nó. Có thể khởi động rig rồi bỏ đi và in tiền không? Anh không nghĩ vậy. Điều hành nhà máy, anh nói, có khi bạn còn bận hơn lúc chỉ làm việc trong đó, nhưng bạn có đòn bẩy (leverage) lớn hơn rất nhiều, vì mỗi cải tiến bạn làm cho đội đều cộng dồn.
Anh bảo hãy nghĩ về một lúc thế giới của bạn đột nhiên rộng ra. Ở đây bạn không chỉ nghĩ "làm sao review PR này nhanh hơn", mà nghĩ "làm sao đưa thêm một nhà máy nữa vào hoạt động càng sớm càng tốt" (theo video đăng ngày 04/11/2026).
Nguồn và liên kết 7 nguồn
- Tên gốc: Agent Teams That Ship: Run an Everything Factory with OpenRig
- Sự kiện: YouTube
- Video gốc: https://www.youtube.com/watch?v=qccsfUnrQ9w youtube.com
- Kênh YouTube OPENRIG (Mike Schwarz): youtube.com/channel/UCtVTmZdo7U1RzUWm4F0WWBQ youtube.com
- OpenRig, mã nguồn trên GitHub (repo của tài khoản mvschwarz, hồ sơ ghi tên Mike Schwarz, đọc ngày 07/11/2026): github.com/mvschwarz/openrig github.com
- Thư viện rig của OpenRig (đọc ngày 07/11/2026): openrig.dev/rigs openrig.dev
- Trang rig Workshop, mô tả một đội phần mềm bốn seat với lead và reviewer chạy Codex, builder và QA chạy Claude Code theo mặc định (đọc ngày 07/11/2026): openrig.dev/rigs/workshop openrig.dev