Bạn có 5 agents. Bạn có 20 tasks. Sáng thứ Hai, cả 5 agents “thức dậy” cùng lúc — ai làm gì trước? Chuyện gì xảy ra khi 2 agents cùng muốn nhận 1 task? Và khi 1 agent bị stuck giữa chừng — ai biết, ai xử lý?
Nếu bạn đã đọc bài trước về org chart, bạn biết cách tổ chức AI team: hierarchy, roles, chain of command. Bài này là bước tiếp theo — cách giao việc và vận hành team đó hàng ngày. Đây cũng là nơi Paperclip khác biệt rõ nhất so với việc chạy agents rời rạc: task management có protocol, không phải dựa vào “hy vọng.”
Task lifecycle — 7 trạng thái, không task nào rơi giữa đường
Mỗi task trong Paperclip đi qua 7 trạng thái. Nghe có vẻ nhiều, nhưng mỗi trạng thái mang ý nghĩa rõ ràng — cả agent lẫn con người đều đọc được:
- backlog — đã ghi nhận, chưa ưu tiên. Task nằm đây cho đến khi ai đó quyết định nó quan trọng.
- todo — đã giao cho agent cụ thể, sẵn sàng làm. Agent nhìn inbox sẽ thấy task này.
- in_progress — agent đã nhận và đang làm. Chỉ 1 agent duy nhất giữ task ở trạng thái này.
- in_review — phần implementation xong, chờ review (code review, content review, test verify).
- blocked — gặp vấn đề, agent không tự giải quyết được. Cần ai đó can thiệp.
- done — qua tất cả quality gates, hoàn tất. Không cần thêm action.
- cancelled — hủy, có ghi lý do. Không xóa — lịch sử giữ nguyên.
Bạn mở dashboard lúc 10 giờ sáng. 3 tasks in_progress, 2 blocked, 5 todo. Không cần hỏi ai — bạn biết ngay team đang làm gì, đâu cần can thiệp, đâu đang chờ. Giống Jira board, nhưng agents tự cập nhật status sau mỗi heartbeat. Con người chỉ cần nhìn.
Quy tắc quan trọng: task chỉ chuyển trạng thái theo thứ tự hợp lệ. Agent không thể nhảy từ backlog sang done. Mỗi bước transition đi kèm comment, timestamp, và run ID — audit trail đầy đủ.
Atomic checkout — không ai làm trùng việc
Đây là cơ chế quan trọng nhất trong task management của Paperclip.
Khi agent muốn bắt đầu 1 task, nó không đơn giản chuyển status sang in_progress. Agent gọi checkout — một API call duy nhất thực hiện 3 bước trong 1 transaction:
- Kiểm tra task chưa ai checkout
- Lock task cho agent này
- Chuyển status sang
in_progress
Tất cả atomic — không có khoảng hở để agent khác chen vào giữa.
Trường hợp conflict: Agent A và Agent B cùng thức dậy, cùng thấy task hấp dẫn nhất. Agent A checkout trước — thành công, task thuộc Agent A. Agent B thử checkout cùng task — nhận 409 Conflict. Agent B biết ngay: task đã có người. Không retry, không chờ — pick task tiếp theo trong danh sách.
Tại sao quan trọng đến vậy? AI agents chạy song song qua heartbeat. 5 agents wake up cùng lúc, cùng quét inbox, cùng thấy task priority cao nhất. Không có checkout → 5 agents cùng code 1 feature, tốn 5 lần token, ra 5 kết quả khác nhau, rồi conflict khi merge. Atomic checkout đảm bảo: 1 task = 1 agent = 1 kết quả.
Giống database locking — nhưng cho task management. First come, first served. Ai đến sau thấy “đã có người nhận” và chuyển sang việc khác. Đây là concept mà bài đầu tiên trong series đã giới thiệu — ở đây bạn thấy nó hoạt động trong thực tế.
Một quy tắc tuyệt đối: không bao giờ retry 409. Nếu task đã thuộc agent khác, đó không phải lỗi mạng — đó là hệ thống hoạt động đúng.
Heartbeat — cách agent “thức dậy” và chọn việc
Agents trong Paperclip không chạy 24/7. Mỗi agent hoạt động theo heartbeat — thức dậy, kiểm tra, làm việc, report, rồi ngủ.
Flow mỗi heartbeat:
- Agent thức → xác nhận danh tính qua API
- Kiểm tra inbox — tasks nào được giao cho mình?
- Pick task theo thứ tự:
in_progresstrước (tiếp tục việc dang dở), rồitodo(việc mới) - Checkout task đã chọn
- Làm việc — code, viết bài, test, review
- Comment kết quả + cập nhật status
- Exit heartbeat — ngủ cho đến lần thức tiếp theo
Tại sao heartbeat thay vì always-on? Ba lý do. Tiết kiệm token — LLM chỉ chạy khi có việc, không idle. Kiểm soát chi phí — mỗi heartbeat = 1 run với ID riêng, track được chính xác cost per run. Audit trail rõ ràng — biết agent nào chạy lúc nào, làm gì, mất bao lâu.
Task assignment cũng có quy tắc: Board hoặc CEO giao task bằng cách set assigneeAgentId. Agent chỉ nhìn thấy và chỉ pick tasks giao cho mình. Không tự lấy task của người khác, không browse task pool tìm việc. Bạn giao — agent làm. Rõ ràng và kiểm soát được.
Quy tắc bắt buộc cuối mỗi heartbeat: agent phải comment trước khi exit. Dù đã hoàn thành, dù đang giữa chừng, dù bị stuck — phải để lại dấu vết. Không bao giờ có chuyện agent “biến mất” mà không ai biết nó đã làm gì.
Khi agent bị stuck — blocked task không phải thất bại
Agent bị stuck là chuyện bình thường. Quan trọng là detect nhanh và escalate đúng.
Trong hệ thống chạy agents rời rạc, agent bị stuck sẽ loop — thử đi thử lại, tốn token, rồi timeout. Không ai biết cho đến khi hóa đơn cuối tháng đến. Trong Paperclip, flow khác hoàn toàn:
- Agent gặp vấn đề → viết comment mô tả blocker cụ thể → set status
blocked - Manager (CTO hoặc CEO) nhận heartbeat tiếp theo → thấy task
blocked→ đọc comment → xử lý: fix trực tiếp, re-assign, hoặc escalate lên cấp trên - Nếu manager cũng bị stuck → escalate tiếp theo chain of command đã thiết kế ở Bài 3
- Cuối cùng, nếu cần quyết định của con người → escalate lên Board
Mỗi bước có comment, có timestamp, có audit trail. Task không bao giờ “biến mất” trong hệ thống.
Paperclip cũng ngăn chặn noise. Nếu agent đã post “blocked” và không có comment mới từ ai khác — heartbeat tiếp theo agent sẽ skip task này, không lặp lại comment. Blocked-task dedup — chỉ re-engage khi có context mới: comment mới từ manager, status thay đổi, hoặc event cụ thể.
Cross-team delegation — giao việc xuyên team
Không phải mọi task nằm gọn trong 1 team.
CTO đang triển khai feature mới, cần header image cho landing page. CTO không tự vẽ — tạo subtask, giao cho CMO. CMO nhận task qua heartbeat, làm image, report kết quả. CTO tiếp tục workflow. Hai team khác nhau, cùng phục vụ 1 mục tiêu.
Cách Paperclip xử lý: subtask luôn có parentId — trỏ về task gốc. goalId — đảm bảo mọi subtask xuyên team đều align về cùng 1 mục tiêu chiến lược. Khi task cross-team, gắn billingCode để track chi phí thuộc team nào, project nào.
Quy tắc: không tự cancel task cross-team. Nếu không làm được — giao lại cho manager kèm comment giải thích lý do. Manager quyết định cancel hay re-assign.
Goal alignment giữ mọi thứ coherent khi team scale. 20 subtasks, 5 agents khác nhau, 3 teams — nhưng tất cả trỏ về cùng 1 goal. Dashboard hiển thị progress theo goal, không chỉ theo task riêng lẻ.
5 sai lầm phổ biến khi giao việc cho AI team
Biết cách làm đúng chưa đủ. Biết cách làm sai giúp bạn tránh mất thời gian.
1. Task mơ hồ — “Fix bug login” → Agent không biết bug nào, reproduce bằng cách nào, fix theo hướng nào. Agent sẽ set blocked và hỏi lại — tốn 1 heartbeat vô ích. Viết brief rõ: title cụ thể, description có context, expected behavior.
2. Quên set priority — 20 tasks đều medium. Agent pick theo thứ tự xuất hiện, không phải theo mức quan trọng. Task critical bị delay vì nằm dưới 10 task thường. Dùng đúng 4 mức: critical, high, medium, low.
3. Tạo task nhưng quên assign — Task nằm trong hệ thống nhưng assigneeAgentId trống. Không agent nào thấy. Agents chỉ pick task giao cho mình — không tự tìm việc.
4. Bỏ qua blocked quá lâu — Agent report blocked, nhưng manager không check inbox → task trôi cả tuần. Dashboard có filter blocked — check mỗi ngày, xử lý trong ngày.
5. Bypass checkout — Tự PATCH status sang in_progress thay vì dùng checkout API → mất atomic lock, mất run ID tracking, risk 2 agents làm cùng task. Luôn dùng checkout.
Tiếp theo: Paperclip chạy với AI nào?
Bạn đã biết cách giao task, tránh conflict, handle blocked, delegate xuyên team. Nhưng Paperclip là control plane — nó quản lý workflow, không phải AI model. Điều đó có nghĩa bạn chọn AI nào để “chạy” cho agents: Claude, GPT, Gemini, hay model chạy local. Mỗi lựa chọn có trade-off khác nhau. Trong bài tiếp theo, bạn sẽ thấy so sánh thực tế — không phải benchmark marketing, mà là kinh nghiệm vận hành.
