Deep Dive: Loop Contract & Lifecycle

Contract là control plane của recurring agent work Thesis

Khi agent chạy theo schedule, event, queue hoặc goal, người dùng không còn cung cấp policy ở từng turn. Loop Contract externalize các quyết định đó: cái gì cho phép một run bắt đầu, item nào được nhận, action nào hợp lệ, evidence nào đủ, state nào sống qua lần sau và điều gì bắt buộc trả quyền về human owner.

Trong interactive work, người dùng thường là một contract engine không được ghi lại. Họ nhớ mục tiêu, lựa item, sửa scope khi agent lệch, quyết định test nào đáng tin và dừng khi thấy rủi ro. Khi run chuyển sang background hoặc schedule, những phán đoán ấy không biến mất; nếu không được externalize, chúng trở thành hidden defaults mà prompt, model hoặc runtime tự suy đoán theo cách không nhất quán.

Vì vậy, contract không mô tả agent “nên thông minh thế nào”. Nó mô tả quan hệ giữa job và môi trường: authority nào đã được cấp, observation nào được coi là evidence, tài nguyên nào được phép tiêu, và tổ chức chấp nhận loại residual risk nào. Đây là control plane vì nó điều khiển transition và boundary; agent execution chỉ là data plane thực hiện một attempt bên trong các boundary đó.

Một câu như “hãy tiếp tục tới khi xong” che ít nhất bốn ambiguity: “xong” do ai xác nhận, “tiếp tục” với thông tin mới nào, “hãy” trao quyền đến đâu, và nếu không thể xong thì ai chịu trách nhiệm. Loop Contract buộc từng ambiguity trở thành field hoặc policy branch. Nhờ vậy, failure có thể được phát hiện ở design review thay vì chỉ sau khi autonomy đã tạo side effect.

Contract tốt cũng tạo ranh giới trách nhiệm giữa các vai trò. Product owner chịu trách nhiệm với objective và finish; security review authority và blast radius; operator review trigger, state, budget và escalation; builder nối các field vào runtime; verifier owner duy trì gate. Không có artifact chung, những người này thường review những lát cắt khác nhau và bỏ sót assumption nằm giữa hai lát cắt.

Đọc 11 operating parts như ba phase Anatomy

Mười một phần không phải checklist phẳng. Chúng tạo ba phase có dependency. Set up xác lập legitimacy của run; Run kiểm soát cách một item được xử lý; Govern & close quyết định autonomy có được tiếp tục hay không. Một field ở phase sau không thể bù cho field yếu ở phase trước: budget chặt không cứu được intake chọn nhầm việc, verifier mạnh cũng không cứu workspace có credential quá rộng.

Objective và exit nhìn giống hai cách viết cùng một điều nhưng phục vụ hai thời điểm. Objective giải thích giá trị job trước khi chạy; exit biến giá trị đó thành observation đủ để đóng một instance. “Giữ tài liệu cập nhật” là objective; “không còn mismatch theo nguồn A/B, examples chạy và diff chỉ chạm docs” mới là exit condition có thể thực thi.

Trigger và intake cũng phải tách. Trigger chỉ cho biết khi nào hệ thống thức dậy; intake quyết định có item hợp lệ để làm hay không. Một cron lúc 8 giờ không cấp nghĩa vụ phải tạo output. Nếu filter, dedupe và freshness không tìm thấy item, no-op có receipt là hành vi đúng; invent work để “tận dụng run” là scope creep.

Ở phase Run, context là input cho cognition còn state là record của system. Context có thể được tóm tắt, refresh hoặc bỏ bớt theo từng attempt; state phải giữ identity, phase, committed side effect và evidence cần cho resume. Trộn hai khái niệm khiến một summary ngôn ngữ tự nhiên vừa phải giúp model suy nghĩ, vừa làm database — một vai trò mà nó không thể đảm bảo atomicity hay idempotency.

Budget, escalation và exit cùng tạo thành termination policy. Budget nói autonomy còn bao nhiêu; escalation nói loại thiếu hụt nào cần authority hoặc judgment khác; exit nói những terminal state nào có thể được ghi nhận. Nếu chỉ có budget, loop dừng nhưng không biết bàn giao cho ai. Nếu chỉ có escalation, conflict có thể lặp vô hạn. Nếu chỉ có exit success, mọi blocker bị ép thành retry hoặc false completion.

Bốn kỹ thuật thiết kế contract Deep Dive

flowchart TD
  P["Pattern<br/>How should this recurring job operate?"] --> C["Contract<br/>What may it read, change, prove, spend?"]
  C --> R["Runtime<br/>Where and when does it execute?"]
  R --> A["Agent instruction<br/>What should this actor do now?"]
  A --> E["Evidence + receipt"]
  E --> C

{
  "name": "CI repair loop",
  "objective": "Repair one reproducible CI failure",
  "trigger": { "type": "event", "cadence_or_event": "required check fails" },
  "intake": { "sources": ["logs", "artifacts"], "selection_rule": "reproducible only" },
  "workspace": {
    "isolation": "clean worktree at failing SHA",
    "allowed_actions": ["inspect", "test", "narrow patch"],
    "disallowed_actions": ["weaken tests", "broad refactor"]
  },
  "context": { "required_files": ["AGENTS.md"], "runtime_sources": ["CI log URL"] },
  "agents": [{ "role": "Implementer", "responsibility": "smallest evidence-backed fix" }],
  "verification": { "gates": ["original command passes"], "receipts": ["output", "diff"] },
  "state": { "artifacts": ["progress note"], "update_rule": "after every attempt" },
  "budget": { "max_retries": 3, "max_runtime_minutes": 60 },
  "escalation": { "conditions": ["flaky", "out of scope"], "destination": "PR owner" },
  "exit": { "success": "target check passes", "stop_without_success": "blocked or budget exhausted" }
}

3. Transition policy phải coi retry, escalate và stop là các state khác nhau

C.3

DEFINITION.md · MANIFESTO.md · ANTI-PATTERNS.md

Mọi loop đều dễ viết cạnh quay lại; phần khó là điều kiện không quay lại. Repeated evidence, thiếu quyền, ambiguity, verifier failure và budget exhaustion phải dẫn đến terminal/handoff state có receipt.

State machine là nơi contract biến thành behavior. Cùng một evidence “test vẫn fail” không mặc định dẫn đến retry: nếu failure signature mới và hypothesis còn actionable, retry hợp lý; nếu signature lặp lại, stop; nếu log cho thấy thiếu credential, escalate; nếu test infrastructure hỏng, handoff sang owner khác. Transition phụ thuộc evidence, history, authority và budget cùng lúc.

Thứ tự Persist trước Decide giữ causal history qua crash. Observation phải được ghi cùng attempt và input version trước khi policy chọn cạnh mới. Nếu process chết sau external write nhưng trước checkpoint, system cần idempotency record để reconcile. Nếu process chết sau verification nhưng trước decision, run sau phải đọc được evidence thay vì chạy lại action và làm thay đổi môi trường lần nữa.

Decision policy: retry chỉ khi có evidence mới và còn budget

JSCopy

function decide(evidence, state, budget) {
  if (evidence.provesGoal) return "exit-success";
  if (state.noQualifyingWork) return "exit-noop";
  if (evidence.requiresAuthority || evidence.isAmbiguous) return "escalate";
  if (budget.exhausted || evidence.repeatsPreviousFailure) return "stop-with-receipt";
  return "retry-with-new-evidence";
}

Outcome	Điều kiện	Receipt tối thiểu
Exit success	External evidence proves acceptance criteria	Gate output + artifact/diff + final state
Exit no-op	Không có item hợp lệ sau intake/dedupe	Query/filter + checkpoint time
Retry	Failure actionable, evidence mới, còn budget	Attempt + hypothesis + next action
Escalate	Cần authority/judgment/credential hoặc blast radius đổi	Blocker + evidence + named destination
Stop without success	Budget hết, repeated evidence, verifier/runtime hỏng	Attempts + reason + residual risk

“Evidence mới” không nhất thiết là thêm text. Nó có thể là reproduction thu hẹp, log từ environment đúng, kết quả của một diagnostic khác, patch strategy khác hoặc review của role có authority. Ngược lại, model diễn giải lại cùng stack trace bằng từ ngữ khác không tạo information gain. Contract nên lưu normalized failure signature hoặc hypothesis history để policy nhận ra stagnation.

No-op là terminal state quan trọng với scheduled loops. Nó chứng minh trigger đã được xử lý nhưng intake không tìm thấy qualifying work. Nếu no-op không được phân biệt với failure, operator nhận alert thừa; nếu không được ghi receipt, operator không biết scheduler có chạy hay không. Một hệ thống vận hành tốt cần phân biệt “không có việc”, “không làm được” và “đã làm xong”.

Ưu điểm

• Ngăn infinite retry và che giấu blocker.
• Cho phép resume/handoff có ngữ cảnh đủ.
• Biến stop-without-success thành kết quả có giá trị vận hành.

Nhược điểm

• Decision policy cần tune để tránh dừng quá sớm hoặc retry quá lâu.
• Similarity của repeated evidence đôi khi khó xác định chắc chắn.

Recipe: viết contract trước khi chọn runtime Recipe

Recipe nên được thực hiện trong một design review ngắn với owner của objective, verifier và runtime, không phải chỉ bởi người viết prompt. Bắt đầu từ recurring symptom cụ thể và một item đại diện. Nếu team chưa thống nhất verified finish, đó là tín hiệu chưa nên tự động hóa — runtime không thể giải quyết ambiguity của product intent.

1. 1
   Đặt tên recurring job

   Một symptom và outcome hẹp: “repair one reproducible required CI failure”.

2. 2
   Viết evidence gate

   Nêu command/threshold/reviewer decision và bảo vệ gate khỏi actor.

3. 3
   Xác định trigger + intake

   Khi nào được chạy, nguồn item, dedupe/idempotency và no-work behavior.

4. 4
   Khoanh workspace + permissions

   Isolation, allowed/disallowed actions, network/secrets và irreversible boundaries.

5. 5
   Thiết kế state + receipts

   Checkpoint khi nào, key nào chống duplicate, evidence nào sống qua cold run.

6. 6
   Cap autonomy

   Retries, time, cost, concurrency, repeated-evidence stop và escalation destination.

7. 7
   Inject failure trước schedule

   Test timeout, crash, duplicate item, broken verifier và missing authority.

Trình tự “evidence trước actor” là cố ý. Khi pass condition đã rõ, ta mới biết context nào cần đọc, permission nào cần cấp và state nào cần lưu. Nếu bắt đầu bằng capability của agent, contract dễ trở thành danh sách mọi điều tool có thể làm thay vì tập quyền nhỏ nhất cần cho outcome.

Sau khi viết, chạy contract bằng một iteration có người quan sát và ghi mọi quyết định phải bổ sung ngoài artifact. Mỗi lần operator phải nói “đừng làm vậy”, “hãy xem log này” hoặc “trường hợp này hỏi tôi” là bằng chứng một boundary, context source hay escalation rule còn thiếu. Chỉ schedule sau khi các quyết định lặp lại đã được đưa về contract.

Contract review checklist Review

Review contract nên là threat modeling cho recurring behavior. Reviewer không chỉ hỏi từng field có tồn tại; họ đi xuyên một item từ trigger đến exit, rồi đi ngược các failure path: duplicate trigger, stale input, crash trước/sau side effect, verifier unavailable, repeated evidence, permission thiếu và owner không phản hồi.

Các field cần được review theo cặp vì phần lớn bug nằm ở interface: trigger với intake, action với verifier, side effect với checkpoint, budget với escalation, success với stop-without-success. Ví dụ, state “update after every attempt” vẫn mơ hồ nếu external action xảy ra giữa attempt; reviewer cần xác định điểm commit cụ thể.

Contract cũng cần owner và nhịp review như code. Thay test suite, source-of-truth, credential model, escalation team hoặc business risk đều có thể làm policy cũ sai dù file JSON không đổi. Receipts và incidents nên quay lại thành input cho contract revision; nếu artifact không học từ vận hành, nó chỉ là documentation tĩnh.

Kết luận Wrap

Loop Contract là cách chuyển phần steering mà con người từng làm trực tiếp thành một policy có thể đọc, diff và thực thi. Nó không làm model ít xác suất hơn; nó làm consequences của xác suất đó có boundary và tạo evidence để hệ thống biết phải làm gì tiếp theo.

Điểm thiết kế quan trọng nhất là giữ contract ở giữa hai cực: đủ cụ thể để loại hidden defaults, nhưng đủ độc lập để không biến thành bản sao runtime config. Objective, authority, evidence, state và termination là semantics ổn định; schedule syntax, queue client hay vendor-specific tool binding là implementation có thể thay.

Schema giúp completeness có thể kiểm tra bằng máy, nhưng safety vẫn là quan hệ giữa các field và môi trường thật. Một contract chỉ trưởng thành khi đã trải qua failure injection, cold-run resume, evidence review và escalation drill. Validation pass là điểm bắt đầu của operational review, không phải chứng nhận cuối.

Câu hỏi chốt cho mọi contract là: nếu actor sai, process crash, verifier mơ hồ hoặc authority hết, artifact này có dẫn hệ thống tới một trạng thái hữu hạn, truy nguyên được và có owner không? Nếu có, recurring work đã có control plane; nếu không, nó vẫn là một prompt dài đang vay sự an toàn từ người đứng cạnh.