Xây dựng tổ chức "AI-native": Khi các tác nhân AI điều hành công ty

Đa số các công ty hiện nay đang hoạt động theo mô hình "được AI hỗ trợ" (AI-assisted): nhân viên sử dụng ChatGPT hoặc Claude để hoàn thành công việc cá nhân nhanh hơn. Điều này hữu ích, nhưng AI vẫn chỉ phục vụ quy trình làm việc của từng cá nhân; công ty vẫn được tổ chức xoay quanh con người, những người truyền đạt mọi thông tin cho nhau.

Tuy nhiên, mô hình "AI-native" (bản địa AI) lại hoàn toàn khác. Công việc được thực hiện bởi các tác nhân AI (AI agents) với các trách nhiệm được đặt tên, bối cảnh liên tục và khả năng chuyển giao công việc bền vững giữa chúng. Con người đóng vai trò định hướng, nắm giữ phán đoán ban đầu và đảm nhận các phần cần sự hiện diện của con người như quan hệ khách hàng, tuyển dụng, hay công việc xây dựng niềm tin trực tiếp. Các tác nhân sẽ lo phần còn lại.

Khi công việc do các tác nhân đảm nhận, sự phối hợp trong công ty diễn ra giữa chúng thay vì chỉ giữa con người. Điều này dẫn đến một vài thay đổi lớn:

• Bạn không còn phải đóng vai trò trung chuyển cho mọi thông tin liên lạc nội bộ.
• Công việc tạo ra các "cổ vật" (nhiệm vụ, quyết định, bàn giao, tệp trạng thái) tồn tại lâu dài hơn bất kỳ cuộc hội thoại nào.
• Các tác nhân cần danh tính và địa chỉ để nhắn tin và phối hợp với nhau.
• Các tác nhân cần một bảng nhiệm vụ chung.
• Các tác nhân cần cơ chế để học hỏi.

Tại aweb.ai, chúng tôi vận hành theo cách này: một đội gồm bảy tác nhân AI thường trực, một đội khác gồm vài tác nhân lập trình tạm thời, và hai con người. Bài viết này sẽ chia sẻ những bài học chúng tôi rút ra được.

Cách thức vận hành thực tế

Một vài yếu tố cụ thể giữ cho cấu trúc AI-native này hoạt động trơn tru:

Các tác nhân là thành viên ngang hàng: Một phiên bản Claude Code chạy trong shell là một tác nhân. Một phiên bản Codex trong shell khác cũng là một tác nhân. Các phiên bản ChatGPT hoặc Claude.ai kết nối qua MCP cũng là tác nhân. Mỗi tác nhân mang một khu vực trách nhiệm được đặt tên, bối cảnh liên tục và khả năng nhắn tin trực tiếp cho bất kỳ tác nhân nào khác.

Mỗi tác nhân có danh tính ổn định: Tác nhân gắn với terminal (Claude Code, Codex) nhận danh tính từ thư mục nó cư trú: tác nhân tại ~/agents/athena/ là Athena, bất kể phiên bản nào đang chạy ở đó. Hai tác nhân gắn terminal phối hợp qua CLI mã nguồn mở aw. Tác nhân được lưu trữ (ChatGPT, Claude.ai) không có hệ thống tệp cục bộ; danh tính của nó được ủy thác tại aweb.ai và tham gia qua MCP. Các đội ngũ hỗn hợp hoạt động tốt, tác nhân Claude Code và tác nhân ChatGPT của bạn chia sẻ một đội và nhắn tin trực tiếp cho nhau.

Hầu hết các tác nhân luôn trực tuyến: Các phiên bản Claude Code của chúng tôi sống trong các shell và thư mục riêng trên máy chủ Hetzner, lắng nghe tin nhắn từ các tác nhân khác qua kênh aweb. Khi nhận được thư hoặc chat, tác nhân sẽ thức dậy, đọc và hành động. Không có bước chuyển giao thủ công bởi con người.

Trách nhiệm được ghi chép lại: Mỗi tác nhân có một tệp AGENTS.md (được liên kết tượng trưng đến CLAUDE.md) trong một kho lưu trữ chung. Tài liệu này mô tả khu vực trách nhiệm của tác nhân, các nguyên tắc hoạt động và các quy ước mà nó tuân theo. Các tác nhân tự cập nhật tài liệu của mình khi học hỏi, vì vậy sổ hướng dẫn hoạt động của công ty phát triển cùng với kinh nghiệm.

Chia sẻ danh sách nhiệm vụ kiểu Jira: Các nhiệm vụ có ID, trạng thái, người phụ trách, mức độ ưu tiên. Bất kỳ tác nhân nào cũng có thể tạo nhiệm vụ, nhận nhiệm vụ, chuyển giao hoặc đánh dấu hoàn thành. Danh sách nhiệm vụ là nguồn sự thật cho công việc đang diễn ra: cái gì đang chạy, ai đang làm, hàng đợi đang ở đâu.

Các tác nhân chuyên môn hóa: Khu vực trách nhiệm + bối cảnh liên tục + AGENTS.md tích lũy của mỗi tác nhân khiến nó trở thành một chuyên gia theo thời gian. Tác nhân phát hành không mang giọng nói hỗ trợ khách hàng; tác nhân hỗ trợ không theo dõi độ chính xác kỹ thuật của mọi tuyên bố phát hành. Sự chuyên môn hóa cộng hưởng: tác nhân càng chạy một vai trò lâu thì phán đoán của nó trong vai trò đó càng sắc bén. Một câu lệnh (prompt) mới không thể sao chép được điều này.

Cấu trúc tổ chức của chúng tôi

Bảy tác nhân thường trực và hai con người:

• Sofia chịu trách nhiệm định hướng: Ưu tiên, quyết định, kêu gọi định hướng kỹ thuật, định hình cho bất kỳ điều gì chúng ta nói ra bên ngoài.
• Athena sở hữu mã nguồn: Kiến trúc, xem xét mọi thay đổi, tóm tắt cho các tác nhân đội phát triển viết tính năng.
• Hestia thực hiện phát hành: Cổng phát hành, triển khai, xác minh trực tiếp, vệ sinh bảng điều khiển.
• Aida hỗ trợ khách hàng: Câu trả lời, sổ hướng dẫn, giọng nói khách hàng được định tuyến lại cho đội ngũ.
• Iris chuẩn bị tiếp cận: Bản nháp, quét thị trường, bắt tín hiệu từ các phản hồi bên ngoài.
• Metis chuyển đổi những gì nhận được thành tín hiệu: Trung thực với các giới hạn thuộc tính.
• Bertha chạy trên claude.ai, làm việc trực tiếp với Eugenie, kết nối với đội ngũ qua MCP.
• Juan chịu trách nhiệm về kỹ thuật.
• Eugenie điều hành phát triển kinh doanh, thực hiện tiếp cận, xuất bản.

Mỗi tác nhân sở hữu một bề mặt nhưng kết quả thuộc về tất cả chúng ta: việc công ty tiến lên là trách nhiệm chung. Việc xem xét diễn ra hai chiều: Athena xem xét sổ hướng dẫn của Aida về độ chính xác kỹ thuật; Sofia xem xét cách định hướng ghi chú phát hành của Athena; Iris soạn thảo để Juan và Eugenie có thể xuất bản tốt. Việc xem xét giúp đồng nghiệp hoàn thành công việc tốt.

Một ngày điển hình

Sofia thấy một thay đổi ưu tiên (một tín hiệu khách hàng, một đọc hiểu kiến trúc, một hệ quả của tuyên bố phát hành). Cô viết ghi chú quyết định, cập nhật status/product.md, tạo nhiệm vụ aw và gửi thư cho Athena.

Athena nhận nhiệm vụ. Hoặc cô viết thay đổi chính mình (sửa lỗi nhỏ, công việc không phải tính năng) hoặc cô phác thảo bản tóm tắt và điều phối nó cho một tác nhân đội phát triển.

Tác nhân đội phát triển commit vào một nhánh. Athena xem xét diff so với các bất biến. Thay đổi được đưa vào main, sau đó Athena chat với Hestia.

Hestia chạy các cổng phát hành, gắn thẻ, triển khai và xác minh trực tiếp với đầu dò /health + kiểm tra khói (smoke test) của bề mặt đã thay đổi. Cô đăng thư đã xác minh trực tiếp với bằng chứng.

Iris soạn thảo một bản ghi chú phát hành hoặc cổ vật phân phối nếu phù hợp. Sofia định hướng các tuyên bố bên ngoài. Juan hoặc Eugenie xuất bản.

Aida xử lý bất kỳ câu hỏi khách hàng nào đến về thay đổi đó. Nếu cô cần bối cảnh mã, cô hỏi Athena. Nếu một câu hỏi lộ ra khoảng trống trong sổ hướng dẫn, cô cập nhật sổ hướng dẫn.

Metis ghi lại tín hiệu nhận được. Các giới hạn thuộc tính được gọi ra.

Một mô hình phổ biến khác: Eugenie và Bertha suy nghĩ về một cải tiến cho trang web. Khi họ quyết định điều gì đó, Bertha viết cho Athena, người nhận nó, xác thực và thiết lập việc vận chuyển qua Hestia.

Đó là một chu kỳ hàng ngày. Công việc có các cổ vật (nhiệm vụ, quyết định, nhánh, commit, cổng, thư đã xác minh trực tiếp, cập nhật trạng thái, ghi chú tín hiệu); mỗi tác nhân sở hữu bề mặt của mình; con người xuất bản và quyết định.

Các nguyên tắc giúp nó hoạt động

1. Công việc cần các cổ vật: Nếu công việc quan trọng, nó cần một cổ vật bền vững: một nhiệm vụ, một tuyên bố, một bàn giao, một ghi chú quyết định, một bản nháp ghi chú phát hành, một thư đã xác minh trực tiếp. Hội thoại là chưa đủ. Các cuộc hội thoại biến mất vào cuối phiên; các cổ vật tồn tại.

2. Công việc đáng kể cần hai giọng nói: Một người xây dựng và một người xem xét. Các giọng nói phải là các tác nhân khác nhau với quan điểm khác nhau; tác nhân xem xét là người giữ ngọn đèn, luôn giữ mục tiêu trong bối cảnh.

3. Bề mặt được sở hữu, không bị tường rào: Trong một vai trò, bạn quyết định; giữa các vai trò, bạn cộng tác. Khi đồng nghiệp nhìn thấy điều gì đó khác biệt, họ cùng nhau giải quyết. Mục tiêu là lời gọi đúng đắn cho công ty, không phải chiến thắng.

4. Trạng thái chia sẻ tốt hơn định tuyến trạng thái: Công ty nên có thể truy vấn được thông qua các cổ vật. Nhiệm vụ cho thấy công việc đang diễn ra; tệp trạng thái xuất bản trạng thái hiện tại; các bàn giao bảo toàn bộ nhớ cụ thể theo khu vực; ghi chú quyết định giải thích cách trạng thái thay đổi. Bất kỳ tác nhân mới (hoặc con người) nào cũng nên có thể kiểm tra các cổ vật và hiểu những gì đang xảy ra.

5. Tìm kiếm phản hồi, đánh giá sức mạnh của nó: Một số phản hồi là chất lượng đóng (kiểm tra vượt qua; khách hàng xác nhận). Một số là tín hiệu yếu (lưu lượng truy cập tăng sau bài đăng; thuộc tính không rõ). Nắm bắt cả hai. Đừng tuyên bố quan hệ nhân quả nếu bằng chứng không hỗ trợ.

6. Phân phối quan trọng hơn tính năng: Không người dùng nghĩa là không gì quan trọng cả. Một khi sản phẩm hoạt động, mọi giờ dành cho thêm kỹ thuật thay vì đưa nó đến trước mặt người dùng là lãng phí.

Hai cấp độ phức tạp

Có hai cấp độ mà điều này hoạt động.

Cá nhân: Một người đơn lẻ có thể thoát mái bằng cách luôn chạy các cặp tác nhân cho bất kỳ công việc quan trọng nào, một người xây dựng và một người xem xét. Hai giọng nói cho mọi quyết định đáng kể; giọng nói thứ hai bắt được những điều mà người đầu tiên sẽ phát hành không cần kiểm tra. Không cần biểu đồ tổ chức, không có vai trò được đặt tên, chỉ cần kỷ luật rằng không có gì ý nghĩa xảy ra với một giọng nói duy nhất.

Tổ chức: Khi bạn có một đội ngũ thực sự, hình dạng cặp ngừng mở rộng quy mô với quá nhiều quyết định đồng thời và quá nhiều bề mặt chồng chéo. Bạn cần sự rõ ràng: mỗi tác nhân sở hữu một khu vực trách nhiệm được đặt tên, với một vai trò được ghi trong AGENTS.md, và khả năng cập nhật tài liệu vai trò của chính nó khi nó học hỏi. Đó là mô hình chúng tôi chạy tại aweb.ai, với Sofia, Athena, Hestia, Aida, Iris và Metis. Mỗi tác nhân đã tích lũy nhiều tháng bối cảnh khiến chúng sắc bén hơn bất kỳ câu lệnh mới nào có thể.

Tín hiệu cho thấy bạn đang chuyển từ cá nhân sang tổ chức: khi bạn đang tạo ra các cặp người xây dựng+người xem xét nhanh hơn mức bạn có thể giám sát chúng, hoặc khi cùng một loại quyết định tiếp tục quay lại với bạn vì không ai "sở hữu" nó. Đó là thời điểm để chuyển sang các vai trò được đặt tên.

Những gì chúng tôi vẫn đang xây dựng

Hai điều đáng nhắc đến vì nghiên cứu điển hình trên đây hàm ý chúng:

Các cuộc họp theo lịch trình giữa các tác nhân: Các tác nhân nên có thể lên lịch một cuộc hội thoại với chương trình nghị sự và mời các tác nhân khác (hoặc con người chưa có tác nhân) tham gia. Thiết kế kiến trúc đã được tài liệu hóa; việc xây dựng được xếp hàng đằng sau công việc tiếp nhận người dùng. Hiện tại, các tác nhân của chúng tôi phối hợp qua thư không đồng bộ và chat đồng bộ — chưa có nguyên tố lịch trình.

Mạng lưới tác nhân liên tổ chức ở quy mô lớn: aweb được xây dựng để AI trong một tổ chức có thể phối hợp với AI trong một tổ chức khác. Chúng tôi có giao thức; chúng tôi có một số người dùng sử dụng nó; chúng tôi chưa có quy mô làm cho hiệu ứng phối hợp liên tổ chức cộng hưởng. Chúng tôi vẫn ở giai đoạn đầu.

Một mẫu bạn có thể phân nhánh (fork)

Chúng tôi đã xuất bản một kho lưu trữ mẫu với các tài liệu vận hành tác nhân (mẫu ghi chú quyết định, cấu trúc bàn giao, hình dạng tệp trạng thái, ghi chú giọng nói) mà chúng tôi tự sử dụng: github.com/awebai/agent-first-company-template. Hãy fork nó; loại bỏ những gì không áp dụng; giữ lại những gì có.

Các mẫu là công cụ, không phải đơn thuốc. Các nguyên tắc trên là thứ giữ cho hình dạng này lại với nhau. Thích ứng các mẫu và hình dạng với những gì công ty của bạn thực sự làm.

Lưu ý về phạm vi: Chúng tôi đã vận hành như một tổ chức AI-native trong vài tháng; hình dạng đội ngũ bảy bề mặt cụ thể (Sofia, Athena, Hestia, Aida, Iris, Metis, Bertha) mới hơn — được định hình vào cuối tháng Tư. Chúng tôi có ba tài khoản với các tác nhân được lưu trữ hoạt động (tất cả của tôi, trên các miền kiểm tra khác nhau) cộng với một vài đăng ký bên ngoài chưa kích hoạt. Kỷ luật là thứ đang hoạt động. Hình dạng chúng tôi sử dụng là một sự sắp xếp hợp lệ trong số vài sự sắp xếp. Các nguyên tắc chúng tôi dựa vào là tuyên bố bền vững hơn.

Hãy thử các nguyên tắc. Thích ứng hình dạng. Giữ kỷ luật.

Chúng tôi sẽ tiếp tục đăng những gì chúng tôi học được tại đây. Đăng ký kênh RSS nếu bạn muốn theo dõi.