# Đội agent biết ship: vận hành một everything factory với OpenRig

[Mike Schwarz](https://homus.dev/speakers/mike-schwarz) · [OPENRIG](https://homus.dev/orgs/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.

Topics: Software Factory, Coding Agents, Agents

Canonical: https://homus.dev/talks/agent-teams-that-ship-run-an-everything-factory-with-openrig

## 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.

![Slide A software factory với chuỗi ideas in, plan, build, test, review, ship, working software và mũi tên quay về đầu](https://homus.dev/photos/qccsfUnrQ9w-0103.jpg)

"A software factory. SDLC: Software Development Lifecycle": ý tưởng đi vào, qua plan, build, test, review, ship thành phần mềm chạy được, rồi vòng lại từ đầu (slide trong video đăng ngày 04/11/2026).

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.
```

![Phiên Claude Code: người dùng nhờ cài OpenRig, Claude chạy npx skills add để thêm skill rigs](https://homus.dev/photos/qccsfUnrQ9w-0323.jpg)

Claude Code thêm skill rigs bằng `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.

![Cửa sổ herdr, space kernel, OpenRig operator gợi ý Workshop với lead, builder, QA và reviewer](https://homus.dev/photos/qccsfUnrQ9w-0403.jpg)

Operator viết: "For this project, I suggest Workshop: a lead, builder, QA and reviewer. Codex leads and reviews. Claude Code builds. Pi tests. Shall I start it for OpenRig?" Dòng chú thích ghi "Workshop: a ready-made team, packaged as a bundle" (demo trong video đăng ngày 04/11/2026).

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).

![TUI của OpenRig, tab GRAPH: rig workshop trên demo-host, pod orch có lead, pod dev có build, qa, review](https://homus.dev/photos/qccsfUnrQ9w-0503.jpg)

Tab GRAPH của TUI: rig workshop trên demo-host, pod orch chứa lead, pod dev chứa build, qa và review, mũi tên đi từ lead tới ba seat kia (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).

![Terminal Claude Code của dev-build báo Not logged in, trong khi OpenRig TUI ghi agent dev.build ready](https://homus.dev/photos/qccsfUnrQ9w-0543.jpg)

"One small bug": terminal Claude Code của dev-build@workshop báo "Not logged in · Please run /login", còn OpenRig TUI vẫn ghi "agent dev.build · ready" (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.

![Slide Pods: seat lead ở trên, dev pod gồm build, review và qa, mỗi seat có địa chỉ và tên model](https://homus.dev/photos/qccsfUnrQ9w-0723.jpg)

"Pods. Context domain: the knowledge and skill for one job.": seat lead (orch-lead@workshop, gpt-6-astra) ở trên; dev pod "build, review and test" gồm build (dev-build@workshop, claude-opus-5-5), review (dev-review@workshop, gpt-6-astra) và qa (dev-qa@workshop, claude-sonnet-5-5) (slide trong video đăng ngày 04/11/2026).

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."
```

![Slide A task in the queue: lead chạy rig queue create, tạo qitem-0142 Fix the login bug giao cho dev-build](https://homus.dev/photos/qccsfUnrQ9w-0843.jpg)

"A task in the queue": lệnh tạo ra qitem-0142 với trạng thái pending; thẻ bên phải ghi "Fix the login bug. Not logged in, but shown as ready", giao cho dev-build@workshop (demo trong video đăng ngày 04/11/2026).

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).

![Slide Who, what, and how: bên trái orch pod và dev pod, bên phải cây thư mục project, mission, slice](https://homus.dev/photos/qccsfUnrQ9w-1023.jpg)

"Who, what, and how": WHO là đội (orch pod với lead chạy Codex; dev pod với build chạy Claude Code, qa chạy Pi, review chạy Codex), WHAT là cây thư mục project-name/missions/next-release/slices/01-login-required/SPEC.md (slide trong 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.

![Slide Missions and slices: lead chạy rig scope mission show và rig scope slice ls, ba slice với trạng thái done, building, planned](https://homus.dev/photos/qccsfUnrQ9w-1143.jpg)

"Missions and slices. What the roadmap is made of.": `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.

![Slide The wake: watchdog at a time or on a condition gửi check on this if it isn't done tới một agent đang ngủ](https://homus.dev/photos/qccsfUnrQ9w-1243.jpg)

"The wake. OpenRig types the next message.": watchdog ("at a time, or on a condition") gửi "check on this if it isn't done" tới một agent đang idle; dòng dưới ghi "In OpenRig, that message is a wake." (slide trong video đăng ngày 04/11/2026).

## 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.

Vòng lặp trong vòng lặp theo lời Mike: slice là vòng trong, mission là vòng ngoài gom các slice thành một release, project là vòng ngoài cùng đi từ mission này sang mission khác (theo video đăng ngày 04/11/2026).

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.

![Slide What's in a RigBundle: hộp RigBundle mở, bên phải danh sách rig.yaml, agent specs, skills và onboarding, CULTURE.md, rules; bên trái cây thư mục project](https://homus.dev/photos/qccsfUnrQ9w-1543.jpg)

Trong hộp: rig.yaml, agent spec cho lead, builder, reviewer, qa, "skills & onboarding", CULTURE.md và rules. Bên ngoài hộp là cây project-name/missions/... với workflow.yaml và "project world", kèm dòng "the team sets these up with you, for your project" (slide trong video đăng ngày 04/11/2026).

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).

Teams of teams theo lời Mike: workshop là đội build, thêm các rig docs, product, marketing, testing; giữa các rig chủ yếu là lead nói chuyện với lead, và bạn cũng chủ yếu nói chuyện với lead (theo 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."
```

![Slide Across machines: workshop và các rig trên host mac-mini-1, rig testing trên host vps-1, lệnh rig send ở dưới](https://homus.dev/photos/qccsfUnrQ9w-1803.jpg)

"Across machines": bạn nói chuyện với workshop trên host mac-mini-1, workshop nối với rig testing trên host vps-1 qua một lệnh rig send có tên host trong địa chỉ (slide trong video đăng ngày 04/11/2026).

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.

Ba dòng trên slide "Running the factory.": needs maintaining, you have more leverage, every improvement compounds (slide trong video đăng ngày 04/11/2026).

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

- Tên gốc: Agent Teams That Ship: Run an Everything Factory with OpenRig
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=qccsfUnrQ9w](https://www.youtube.com/watch?v=qccsfUnrQ9w)

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

- 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](https://github.com/mvschwarz/openrig)

- Thư viện rig của OpenRig (đọc ngày 07/11/2026): [openrig.dev/rigs](https://openrig.dev/rigs)

- 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](https://openrig.dev/rigs/workshop)

Nguồn: https://homus.dev/talks/agent-teams-that-ship-run-an-everything-factory-with-openrig · cập nhật 2026-11-07