I Run a Fleet of AI Agents Across Three Machines. Here's What Broke.

1. Đội agent chạy trên ba máy, mỗi ngày

Kyle mở đầu rất thẳng: anh là Kyle, mỗi ngày anh vận hành một đội (fleet) AI coding agent trải trên ba cái máy, và talk này là câu chuyện về những gì đã hỏng. Và thứ hỏng đầu tiên, như anh nói, là chính anh. Talk này không phải về một tool cụ thể nào, cũng không phải một platform của công ty. Đây là một bản báo cáo thực địa (field report) trung thực từ hệ thống cá nhân mà anh dùng như công cụ làm việc hằng ngày (daily driver): những thứ chạy ngon trên một máy thì vỡ ra sao khi scale lên nhiều máy, cần gì để giữ một setup như vậy sống, và mọi thứ đang hội tụ về đâu.

Đây là đội của anh: ba cái máy chạy mỗi ngày. Chiếc MacBook là nơi anh làm phần coding nặng và các project cá nhân, và nó sẽ ngủ (sleep), vì, nói cho cùng, nó là laptop. Sau đó là hai máy Linux, cả hai đều headless (không có màn hình, không ai ngồi trước) và luôn bật (always-on). Linux A nhận các task coding chạy dài (long-running). Linux B chạy các side project cá nhân sống ngắn (short-lived). Hai hệ điều hành, và một control plane duy nhất buộc tất cả lại với nhau.

Anh nhấn mạnh để mọi người hiểu rõ: đây không phải một bản demo dựng lên cho talk này. Đây là thứ anh thật sự dùng cả ngày, mỗi ngày. Và đây là nó đang chạy thật, toàn bộ hệ thống trên một màn hình. Agent thật, việc thật. Với anh, đây là một ngày thứ Ba bình thường.

2. Thứ hỏng đầu tiên không phải cái máy, mà là chính tôi

Kyle kéo câu chuyện về điểm xuất phát, vì trước khi bất kỳ cái máy nào hỏng, anh đã hỏng trước. Lúc mới bắt đầu, chỉ có anh và một cái terminal. Vài pane tmux, vài agent, rồi thêm vài cái nữa, và rất nhanh anh thấy mình ngồi trước bốn, năm, sáu context đang sống cùng một lúc.

Và đây là điều không ai cảnh báo bạn. Đến thời điểm đó, anh không còn là người chạy agent nữa. Anh đã trở thành scheduler, người quyết định ai làm gì. Anh là memory, người phải giữ trong đầu từng agent đang làm gì. Và anh là reviewer, người kiểm tra tất cả mọi thứ. Một con người, ba vai trò, sáu context. Cách đó không scale được.

Rồi anh chiếu cảnh thật: một màn hình chia thành nhiều pane, mỗi pane là một agent đang làm một việc khác, log lỗi chạy xen với báo cáo tiến độ. Đây là mớ hỗn độn đã đánh gục anh (the mess that broke me). Anh đơn giản là không thể giữ trong đầu sáu agent đang làm gì cùng một lúc. Sự chú ý (attention) của chính anh đã trở thành nút thắt cổ chai (bottleneck).

3. Insight: biến đống agent thành một tổ chức

Thế là anh tự hỏi một câu hơi lạ: làm thế nào một nhóm nhỏ vài vị điều hành (executive) lại vận hành được một công ty hàng nghìn người? Họ không giữ tất cả trong đầu. Họ tách context ra. Mỗi người chỉ bao giờ nhìn thấy phần (slice) của riêng mình.

Đó là chìa khoá mở ra mọi thứ. Nếu các agent của anh không phải là một đống phẳng (flat pile) thì sao? Nếu chúng là một tổ chức thì sao? Và đó chính là thứ anh xây: một hierarchy gồm CEO, VP, manager và worker.

Kyle xin mọi người nghe kỹ chỗ này: đây là những loại thực thể (entity type) có thật trong hệ thống, không phải một phép ẩn dụ cho vui. Mỗi entity là một agent riêng, có context được giới hạn phạm vi (scoped context) của riêng nó và ranh giới phê duyệt (approval boundary) của riêng nó. Context chảy xuống: mỗi tầng chỉ nhận đúng phần nó cần. Kết quả chảy ngược lên, và anh chỉ review những gì lên tới tầng cao nhất. Thế là thay vì giữ sáu context trong đầu, anh chỉ còn giữ đúng một.

4. State sống trong file, không bị nhốt trong một model

Vấn đề tiếp theo: state của một agent thật ra nằm ở đâu? Bình thường, nó nằm bên trong context window của model, và cái window đó sẽ đầy. Nên anh dời nó ra ngoài.

Mỗi entity có một workspace riêng trên đĩa. Context dùng chung mà ai cũng phải tuân theo nằm trong thư mục shared. State gắn với từng máy nằm dưới machines. Và bên trong mỗi workspace có ba thứ: mission (nhiệm vụ), status hiện tại, và một thư mục handoff, chứa sản phẩm công việc thật sự được chuyền tay cho bước sau. State sống trong file. Nó không bị nhốt bên trong một model nào.

5. Đừng compact, hãy reset

Kyle gọi đây là điều thực tế nhất anh học được trong cả năm. Khi context window đầy, cách xử lý có sẵn là compact: tóm tắt lịch sử lại để lấy chỗ. Anh đã thôi làm vậy. Compact chậm, anh không chọn được thứ gì được giữ lại, và bất cứ thứ gì nó vứt đi là mất luôn.

Nên thay vào đó, anh không compact, anh reset. Reset ở đây nghĩa là ngay bên trong Claude, anh xoá sạch context hoàn toàn, rồi agent chỉ việc đọc lại thư mục handoff và các file lịch sử mà chính nó đã viết cho mình, rồi tiếp tục đúng chỗ nó đã dừng. Context có thể bị xoá, thậm chí cái máy có thể crash, mà công việc vẫn còn, vì nó chưa bao giờ chỉ nằm trong model.

6. Review gateway: một inbox, một điểm kiểm soát

Nhưng vẫn còn một vấn đề: alignment (sự thống nhất về hướng đi). Kế hoạch chảy xuống theo hierarchy, nhưng chúng trôi lệch (drift), và anh chỉ phát hiện được bằng cách tự đi vào từng pane một. Nên anh xây một review gateway.

Bất kỳ tầng nào muốn hành động đều phải nộp plan của nó, rồi block lại. Nó chờ. Không gì chạy cho tới khi anh approve. Và ngay khoảnh khắc anh approve, một hook tự động bắn công việc đi. Một web inbox, một điểm kiểm soát. Anh không bao giờ phải đi vào các cửa sổ làm việc nữa.

Anh cho xem một vòng đầy đủ: một plan đi vào, anh approve, công việc chạy tiếp. Đó là toàn bộ vòng lặp. Và nói thật, anh không tự tay xây cái gateway này. Một team infra bên trong chính đội agent đã xây nó. Agent xây những công cụ dùng để chạy agent. Anh nghĩ đó gần như là toàn bộ ý nghĩa của chuyện này.

Trên một máy, tất cả những thứ này chạy rất đẹp. Và rồi nó không còn chạy nữa.

7. Một máy không còn đủ: failure 1 và failure 2

Rồi một máy không còn đủ. Năm thứ đã hỏng.

Failure 1: agent tự làm việc thay vì dispatch xuống

Các agent của anh cứ tự mình làm việc thay vì giao (dispatch) nó xuống cho một worker. Orchestrator đáng lẽ phải uỷ quyền (delegate). Thay vào đó, nó xắn tay áo lên và tự làm task. Sai. Nên anh ép nó: một CLI harness, cùng các skill gọi tới những CLI đó, để việc dispatch trở thành con đường duy nhất nó có thể đi.

Phần help trên slide cho thấy hình dạng của lệnh đó:

Usage: overlord dispatch [options] <team> <message-or-file>

Dispatch a task to a team (creates a task + trace, notifies manager)

Arguments:
  team              Target team name
  message-or-file   Task message or path to a .md file

Options:
  --priority <level>  Priority: low/normal/high/urgent (default: "normal")
  --from <sender>     Sender name (default: "ceo")
  -h, --help          display help for command

Failure 2: pane quá nhỏ

Failure thứ hai, theo anh, gần như buồn cười. Khi anh cứ ném thêm task cho các manager, chúng cứ mở thêm ngày càng nhiều pane worker bên trong một cửa sổ duy nhất, tới mức chật cứng, các pane nhỏ đến không đọc nổi. Ngay cả tmux capture-pane, thứ anh dùng để đọc nội dung một pane bằng code, cũng không lấy ra được gì có nghĩa từ chúng nữa. Anh đã thật sự hết chỗ để nhìn xem chính đội của mình đang làm gì.

8. Failure 3, 4, 5: hết RAM, credential đá nhau, laptop chết

Failure 3: hết bộ nhớ

Failure thứ ba là out of memory. Anh bảo mọi người nhìn vào màn hình: Activity Monitor bị chôn vùi hoàn toàn dưới các process của Claude Code và MCP. Swap gần đầy. Gần như không còn chút bộ nhớ trống nào. Các session cứ chồng lên nhau cho tới khi cái máy không thở nổi nữa.

Failure 4: Git credential đụng nhau

Failure thứ tư là Git credential. Kỳ vọng thì gọn gàng: credential A cho workspace A, credential B cho workspace B, một đối một. Thực tế thì chúng va chạm, bắt chéo, bị gắn nhầm vào workspace khác. Cách sửa là một môi trường sạch, tách biệt hoàn toàn cho từng workspace.

Failure 5: laptop chết

Và failure thứ năm, cái thật sự đau. MacBook là laptop, nên ngay khoảnh khắc nó mất điện hoặc rớt khỏi mạng, mọi job đang chạy dở chết theo nó. Có một lần, anh đã đẩy quá nhiều worker lên nó tới mức cả cái máy gục luôn. Anh quay lại sau đó, mở nắp lên, và nó đã tự khởi động lại rồi. Mọi thứ đang chạy dở, mất sạch.

Vì vậy việc đầu tiên anh làm là xây một lệnh boot: chỉ một lệnh overlord boot, và cả đội dựng lại ngay lập tức, vì toàn bộ state vẫn nằm sẵn trong file. Nhưng một cái máy có thể biến mất trước mặt bạn như vậy, đó là lúc anh biết một máy sẽ không đủ. Từng failure một trong năm cái đều chỉ về cùng một câu trả lời.

9. Thêm máy và chuyển context bằng Git

Thế là anh thêm máy. Đây là cách chia việc: chiếc MacBook đang gánh mọi thứ, cả heavy coding lẫn project cá nhân, nên anh giảm tải cho nó. Task coding chạy dài chuyển sang Linux A, project cá nhân sống ngắn chuyển sang Linux B, cả hai luôn bật. Kết quả là nhiều tài nguyên hơn, phần việc chạy dài cuối cùng cũng rời khỏi laptop, và vẫn chỉ có một control plane trên tất cả.

Nhưng bây giờ anh có context nằm trên một máy mà anh cần ở máy khác. Chuyển nó thế nào? Bằng Git. Anh commit các file context rồi push. Sau đó anh "chọc" (poke) máy kia bằng tmux send-keys qua SSH và bảo nó pull. Nó pull về, agent bên đó đọc các file, và tiếp tục đúng chỗ agent đầu tiên đã dừng.

Tất nhiên mọi thứ không gọn như thế. Khi hai máy cùng trỏ vào một thư mục và cả hai đều thay đổi nó, bạn sẽ gặp conflict. Cùng một context lặng lẽ tách làm hai phiên bản khác nhau (diverge). Nên anh tách nó ra: thư mục riêng theo từng máy cho state gắn với máy, còn phần dùng chung chỉ được thay đổi qua một pull request. Nghe thì nhàm chán, nhưng chính sự nhàm chán đó ngăn hai cái máy âm thầm bất đồng với nhau.

10. Gom gateway về một chỗ, Discord làm router duy nhất

Rồi cái gateway quay lại cắn anh. Bây giờ mỗi máy đều có một gateway, nên anh lại phải kiểm tra nhiều inbox cùng lúc, đúng cái tình trạng anh từng muốn thoát. Nên anh gộp chúng lại. Mọi máy gửi review request qua SSH về một gateway chính, và gateway chính đó sống trên một máy Linux luôn bật. Vì hãy nhớ, chiếc Mac sẽ ngủ. Điểm kiểm soát duy nhất của bạn không thể là một thứ biết ngủ gật.

Và rồi tới failure mà anh thích nhất trong cả project. Anh đang phát triển trên tất cả các máy, nhảy qua nhảy lại, và tới một lúc anh đi tìm một feature mình đã build, và anh thật sự không nhớ nổi mình đã build nó trên máy nào. Đó là lúc mọi thứ vỡ lẽ: anh cần một nơi duy nhất để điều phối (route) từ đó.

Thế là Discord trở thành router duy nhất của anh. Mỗi máy một bot: Mac, Linux A, Linux B. Chiếc điện thoại của anh giờ là cái remote điều khiển toàn bộ đội agent.

11. Bốn vấn đề chưa giải, và tại sao câu trả lời là Kubernetes

Vậy bây giờ anh đang ở đâu? Thành thật mà nói, với một đống thứ chưa giải được. Cụ thể là bốn:

• Tính nhất quán (consistency) giữa các máy.
• Trừu tượng hoá những tool chỉ chạy được ở local, hiện vẫn kẹt trên chiếc Mac: các MCP server, cái browser.
• Chuyển giao credential an toàn giữa các instance.
• Quản lý tài nguyên (resource management). Anh thật sự muốn thôi làm người quyết định cái gì chạy ở đâu.

Và khi xếp bốn vấn đề đó cạnh nhau, anh nhận ra đây hoàn toàn không phải câu hỏi mới. Một agent chỉ nên khai báo nó cần gì, chứ không phải nó chạy ở đâu. Phía trên nó là orchestrator, review gate và hierarchy logic. Phía dưới nó là compute, secrets và tools. Một scheduler đặt nó vào chỗ, và các cái máy chỉ việc biến mất bên dưới. Đây chính xác là những câu hỏi mà Kubernetes đã trả lời rồi.

Nên đó là hướng anh đang đi. Anh sẽ không phát minh lại compute, secrets và tools, vì Kubernetes đã làm những thứ đó rất tốt. Anh xếp chúng xuống dưới, và xây orchestration manager của riêng mình ở trên: task orchestration, review flow, context management. Dùng lại những gì đã có, xây phần mới ở trên.

Và đó là trạng thái thật của mọi thứ. Trên một máy, anh đã giải xong. Giữa nhiều máy thì vẫn còn thô, vẫn đang xây. Nếu bạn đang chạy agent ở bất kỳ quy mô nào, anh thật lòng rất muốn trao đổi (compare notes), vì đây là phần mà chưa ai giải được. Anh có mặt trên LinkedIn và X, link nằm trong phần mô tả của video. Anh cảm ơn mọi người rất nhiều.