What Does Done Even Mean? Agents and Paperclip's Liveness Model

1. Agent nói "looks done to me", nhưng done tới mức nào?

Dotta mở đầu bằng một cảnh rất quen với ai đang chạy coding agent. Một agent mở một pull request. PR đó pass hết test. Agent cập nhật cả documentation. Rồi nó đóng issue và để lại một comment: "Looks done to me."

Câu hỏi của anh là: việc đó thật sự done chưa? Done đủ để merge chưa? Done đủ để deploy chưa? Done đủ để công bố cho khách hàng của bạn chưa? Theo Dotta, đây là những operational claim khác nhau về bản chất, mỗi câu khẳng định một điều khác. Vậy mà phần lớn các hệ thống agent hiện nay chỉ ép phẳng tất cả lại thành một dấu check màu xanh duy nhất.

Anh tự giới thiệu: anh là Dotta, người tạo ra Paperclip, và talk này là những bài học "hard-earned" mà nhóm đã rút ra trong quá trình xây dựng liveness model của Paperclip. Câu hỏi xuyên suốt cũng là tên talk: rốt cuộc "done" nghĩa là gì?

2. Programming đã được giải, và một failure mode mới xuất hiện

Dotta đặt tiền đề rất thẳng: programming is solved. Agent giờ đây có thể tạo ra code và documentation nhanh hơn bất kỳ con người nào có thể verify. Lượng output không còn là vấn đề.

Chính điều đó sinh ra một failure mode mới: agent có thể tạo ra nhiều việc hơn số việc con người có thời gian để kiểm tra. Vì vậy, theo anh, ta cần một cách để xác minh rằng agent đã thật sự xong việc, chứ không chỉ để agent tự tick vào một cái checkbox.

3. Done là một bó claim, không phải một cái status

Ý đầu tiên Dotta muốn tháo ra: done không có nghĩa là agent vừa đổi status của task thành "done". Nói rằng một việc đã done thực chất là đưa ra một bó (bundle) các claim cùng lúc:

• có một artifact đã được tạo ra;
• có evidence cho thấy task thật sự hoàn tất;
• có một rubric để đối chiếu và verify;
• biết chính xác ai là owner của bước tiếp theo;
• và biết chính xác bước tiếp theo là gì.

Khi một người nói "xong rồi", ta ngầm hiểu cả bó đó. Khi một agent nói "xong rồi" bằng cách bật một cờ, hầu hết các claim trong bó đều bị bỏ trống.

4. Done có nhiều tầng

Tiếp theo, Dotta chỉ ra rằng có nhiều mức độ "done", và mỗi mức đòi hỏi một bên khác đứng ra:

• Producer, bên làm ra sản phẩm, có thể tuyên bố là đã hoàn tất.
• Nhưng bạn cần một reviewer, một bên khác nhìn vào và không thấy vấn đề hiển nhiên nào.
• Bạn muốn verify rằng evidence thật sự đáp ứng một standard đã được nêu rõ.
• Bạn muốn một người có thẩm quyền phê duyệt thật sự approve rằng công việc đã xong.
• Bạn muốn có một người thật sự đứng sau quyết định đó, chịu trách nhiệm về nó.
• Và lý tưởng nhất, thứ bạn muốn là kết quả đã sống sót qua điều kiện thực tế (real world conditions).

5. Human review vỡ ở quy mô lớn: verification theater

Vì sao không để con người kiểm hết? Dotta giải thích: human verification kiểu kiểm tất cả (exhaustive) sẽ thất bại khi khối lượng lớn. Bạn có thể verify được vài task mỗi ngày. Nhưng nếu mọi task đều phải có người kiểm và ký duyệt, rốt cuộc thứ bạn nhận được chỉ là một dạng verification theater: một màn trình diễn kiểm duyệt, nơi chữ ký có mặt nhưng việc kiểm thật thì không.

Thứ cần có, theo Dotta, là một protocol định nghĩa cách task thật sự đi qua hệ thống. Bạn muốn task luôn được giữ chuyển động, nhưng không bị kẹt vào những trạng thái không hợp lệ (invalid state). Bạn cần một control plane nơi việc thực thi task được gắn với các contract và constraint cụ thể: hệ thống sẽ làm gì, và nó sẽ giao task tiếp theo cho agent nào.

6. Liveness và assurance: hai lực phải giữ cân bằng

Dotta gọi tên cái thế giằng co mà mọi hệ thống agent phải chơi: giữ cho công việc tiếp tục chuyển động, đồng thời vẫn được verify.

Khi một task đã được người review, bạn có được sự bảo đảm (assurance) rằng nó đúng. Nhưng việc phải chờ người verify cũng có nghĩa là task đó đứng chết tại chỗ. Mặt còn lại là liveness: liveness nghĩa là công việc vẫn tiếp tục, không có blocker. Và bạn luôn phải cố giữ hai thứ này cân bằng với nhau.

Hai đầu cực đoan đều tệ:

• Nếu task hoàn toàn "sống" mà không có approval nào, thứ bạn nhận được là AI slop kinh điển: sản xuất ra rất nhiều thứ mà gần như không có quality control. Theo Dotta, sau một thời gian dài, kiểu đó còn tệ hơn là không tạo ra gì cả.
• Nếu chỉ có review thuần tuý, bạn có một hàng đợi review khổng lồ mà dù sao con người cũng không thể review tay hết được.

Các agent sẽ tạo ra nhiều hơn rất nhiều so với những gì bạn có thể review. Nên ta phải tìm cách tách bó claim nằm trong câu "task này done rồi" ra thành từng phần.

7. Một vòng for loop là không đủ: ba invariant của control plane

Trong Paperclip, nhóm có một loạt cơ chế để giữ cho mọi thứ chạy. Dotta nói trước một ảo tưởng phổ biến: bạn có thể nghĩ rằng chỉ cần viết một for loop chạy qua task manager rồi cho agent làm từng việc là xong. Nhưng bạn sẽ nhanh chóng thấy cách đó sụp đổ.

Ngay khi bắt đầu tích hợp cây phụ thuộc giữa các task (task dependency tree), blocker, nhiều agent cùng lúc, idempotent checkout, tức các lock trên checkout, bạn sẽ thấy sự giằng co giữa liveness và verification trở nên khá phức tạp.

Từ đó, anh đưa ra ba invariant cực kỳ quan trọng khi nghĩ về thứ bạn muốn có ở một control plane cho công việc agentic:

1. Productive work continues: công việc có ích phải tiếp tục chạy.
2. Only real blockers stop work: chỉ blocker thật mới được dừng công việc.
3. Infinite loops are bounded: vòng lặp vô hạn phải bị chặn giới hạn.

8. Các cơ chế của Paperclip

Để giải bài toán này, Paperclip xây một loạt cơ chế. Dotta đi qua từng cái:

• Clear transitions: mỗi task đều có các chuyển trạng thái rõ ràng sang trạng thái kế tiếp có thể có.
• First-class blockers: blocker giữa các task là thực thể hạng nhất, và chính control plane enforce các blocker đó, không phải agent tự giác.
• Interactive human approval: có những thời điểm người duyệt tương tác trực tiếp, và lựa chọn của con người để lại một audit trail.
• Reviewers và approvers: bạn có thể gán reviewer và approver cho task một cách tường minh, nghĩa là khi task này xong, một agent khác có thể review nó.
• Watchdogs: một chế độ "maximizer", với tinh thần "hãy cố hết sức để đảm bảo việc này xảy ra" (phần tiếp theo nói kỹ).

Slide còn nêu hai ý mà phần nói không nhắc tới: evidence không đồng nghĩa với liveness (comment, doc, work product là evidence), và việc chia nhỏ một task thành child issue theo một plan. Tài liệu execution semantics trong repo Paperclip mô tả các trạng thái và chuyển trạng thái này chi tiết hơn.

9. Watchdog: maximizer mode, không phụ thuộc harness

Watchdog là ý Dotta dừng lại lâu hơn. Khi bạn bật một watchdog, đó là một agent khác, được giao một goal. Nó enforce rằng tất cả các agent của bạn tiếp tục làm việc cho tới khi goal đó đạt được. Đây là cái anh gọi là "maximizer mode": thay vì để từng agent tự quyết khi nào dừng, có một bên đứng ngoài giữ cho cả nhóm không bỏ cuộc giữa chừng.

Điểm quan trọng: watchdog trong Paperclip harness agnostic. Bạn có thể dùng nó với Pi, OpenClaw, Hermes, Claude Code, Codex. Dù bạn đang dùng harness nào, bạn có một interface nhất quán để bảo đảm goal được hoàn thành. Cách Paperclip nối control plane với từng runtime được mô tả trong phần adapters của docs.

10. Coi done là một object, không phải Boolean

Một trong những lời khuyên tốt nhất nhóm Paperclip có: đừng coi done là một Boolean nữa, hãy coi nó như một object. Dotta nhấn mạnh lời khuyên này không riêng gì cho Paperclip; nó là cách nghĩ về "done" nói chung.

Con người tự động lấp liếm (paper over) những chi tiết này mà không để ý. Nhưng khi xây hệ thống agentic, điều quan trọng là agent phải phân biệt được từng thành phần trong thứ nó đang claim khi nói một việc đã done:

• artifact mà nó nói là đã hoàn thành;
• scope;
• rubric, hay standard;
• evidence cho thấy đã xong;
• ai đã verify công việc;
• ai có authority để ký duyệt;
• risk nào còn lại;
• và rốt cuộc, next action sẽ là gì.

Khi định nghĩa done, hãy bảo đảm nó không chỉ là một checkbox. Slide minh hoạ bằng chính một "done claim" dạng JSON, có thể dùng làm khuôn:

{
  "artifact": "talk-draft.md",
  "scope": "5-15 minute AIE talk",
  "standard": "acceptance criteria + source accuracy",
  "evidence": ["source check", "timing", "QA read"],
  "verifier": "QA",
  "authority": "CTO",
  "residualRisk": "speaker-specific polish",
  "allowedNextAction": "build slides"
}

11. Checklist nên "steal": định nghĩa done, tách verifier, đòi evidence

"Nếu bạn muốn làm được nhiều việc hơn gấp trăm lần, hãy steal checklist này", Dotta nói. Các điểm anh đi qua:

• Định nghĩa chính xác done nghĩa là gì cho task này.
• Chắc chắn phải tách verifier khỏi author. Thường điều này có nghĩa là dùng một model khác. Nếu bạn code bằng Claude, hãy để Codex verify.
• Yêu cầu agent đưa ra evidence. Đừng chỉ hỏi chúng "việc này xong chưa?". Hãy cho chúng công cụ cần thiết để tự verify rằng việc đã xong: viết code cho một browser harness riêng, viết code để chụp screenshot, bảo đảm chúng có quyền truy cập browser, bảo đảm chúng có custom agent hook hoặc custom agent tooling để tự chạy qua, tự bấm nút, tự thử, và tự verify rằng công việc thật sự đã xong.
• Có một chain of custody rõ ràng: mọi agent đều biết rằng ngay khi xong, chúng phải giao việc cho ai tiếp theo.

12. Chain of custody và lời kết

Dotta kết bằng một lời dặn. Rất dễ để bắn đi một instruction một dòng rồi "vibe" với bất cứ thứ gì agent trả về. Nhưng nếu bạn đang làm việc nghiêm túc mà mình phải chịu trách nhiệm, thì điều cực kỳ quan trọng là:

• định nghĩa done thật sự nghĩa là gì, càng chi tiết càng tốt;
• và có một cấu trúc cho agent, để chúng có thể verify rằng mọi claim nằm trong câu "việc này đã done" đều thật sự được đáp ứng.

Anh cảm ơn người nghe và khép talk ở đó.