Deep Dive: Runtime, Pattern Selection & Loop Maturity

Loop là design; runtime là nơi design được thực thi Thesis

Một CI repair contract có thể chạy trong interactive session, scheduled desktop task, Codex automation, GitHub Actions, shell/cron hoặc durable workflow engine. Điều cần giữ ổn định là objective, permissions, evidence, state, budget và handoff; điều thay đổi là wiring của trigger, workspace, credentials, checkpoint và notification.

Nhầm design với runtime tạo hai dạng lock-in. Technical lock-in xảy ra khi state và transition chỉ tồn tại trong API vendor; conceptual lock-in xảy ra khi team mô tả job bằng feature của tool thay vì objective và evidence. Khi đó, đổi execution surface không chỉ là migration mà buộc team tái khám phá chính operating policy của mình.

Contract-first không có nghĩa runtime là commodity. Runtime quyết định policy có được enforce thật hay chỉ được nhắc trong prompt: schedule có chống overlap không, worktree có sạch không, credential có scope theo job không, checkpoint có atomic không, approval có block side effect không. Cùng contract trên hai runtime có thể cho reliability rất khác nếu enforcement primitives khác nhau.

Vì vậy, runtime selection là một bài toán fit giữa job shape và failure cost. Local session tối ưu cho tốc độ học khi human nearby; CI tối ưu cho repo event và required checks; durable engine tối ưu cho crash recovery và long-lived side effects. Không có runtime “mature nhất” cho mọi loop — chỉ có runtime nhỏ nhất đáp ứng những semantics bắt buộc.

Thứ tự lựa chọn còn bảo vệ economics. Khi bắt đầu từ tool, team dễ sử dụng schedule, multi-agent và durable storage vì chúng có sẵn, trước khi chứng minh recurrence hoặc verified value. Khi bắt đầu từ symptom và finish condition, mỗi capability mới phải trả lời một failure hoặc constraint cụ thể, nhờ đó complexity có business case rõ.

Runtime map Map

Runtime map nên được đọc như một cây loại trừ. Persistence loại các surface không sống qua process; file locality loại cloud clone khi input chỉ có trên máy; event source ưu tiên CI khi work gắn với repository; crash sensitivity đẩy job sang durable execution. Feature comparison chỉ hữu ích sau khi các constraint bắt buộc đã được thỏa.

Persistence có ít nhất ba mức. Session persistence giữ context khi process sống. Cross-run persistence giữ checkpoint giữa các invocation. Durable execution còn đảm bảo timer, retry và transition có thể replay sau crash. Một file progress đáp ứng mức hai cho job nhỏ nhưng không tự cung cấp transaction semantics của mức ba.

flowchart TD
  A["Recurring job"] --> P{"Must survive app / machine / process?"}
  P -->|"no"| L["Interactive session or local starter"]
  P -->|"across runs"| F{"Needs local non-Git files?"}
  F -->|"yes"| D["Desktop scheduled task or controlled local cron"]
  F -->|"no"| G{"GitHub event / repo-centric?"}
  G -->|"yes"| C["CI / agentic workflow / cloud automation"]
  G -->|"no"| X{"Crash-sensitive or long-lived?"}
  X -->|"yes"| W["Custom durable workflow runtime"]
  X -->|"no"| B["Background cloud automation"]
  L --> S["Add worktree / sandbox + external gate"]
  D --> S
  C --> S
  W --> S
  B --> S

File access và isolation thường xung đột. Local runtime thấy uncommitted files, private corpus và desktop apps nhưng dễ inherit môi trường bẩn cùng privilege người dùng. Cloud/CI tạo fresh clone và credential tách biệt nhưng mất local context. Contract phải chỉ rõ source-of-truth; runtime không nên bí mật bù thiếu context bằng cách đọc rộng hơn.

Escalation surface cũng là capability runtime. Report trong inbox phù hợp với maintenance không khẩn cấp; PR comment phù hợp với code review; pager phù hợp với incident. Nếu handoff cần action trong vài phút nhưng runtime chỉ tạo artifact không ai theo dõi, contract có escalation field nhưng operating system chưa có escalation path thật.

Bốn quyết định vận hành Deep Dive

4. Maturity 0–6 là thứ tự dependency, không phải leaderboard

M.1

README.md#loop-maturity-model

Các level là cumulative capabilities. Multi-agent không chữa missing state; verifier không chữa trigger/intake mơ hồ; production automation không an toàn nếu chưa có telemetry, approval, rollback và owner.

Maturity level mô tả phần trách nhiệm từng do con người giữ đã được hệ thống hóa đến đâu. Level 0: người dùng giữ trigger, state và judgment. Level 2: scheduler và intake được externalize. Level 3–4: memory và verification được externalize. Level 5 tách role; Level 6 externalize cả production supervision nhưng vẫn giữ human owner ở control plane.

Dependency order ngăn automation khuếch đại debt. Schedule trước no-work/dedupe tạo duplicate work; state trước identity vẫn lưu nhầm item; verifier trước protected boundary có thể bị actor sửa; multi-agent trước handoff contract tạo coordination noise. Promotion chỉ hợp lý khi failure ở level hiện tại không còn được giải tốt bằng control đơn giản hơn.

Level	Operating model	Capability mới	Ví dụ
0	Manual prompting	Human giữ state và judge	Một fix được review trực tiếp
1	Scripted retry	Bounded feedback wrapper	Rerun pytest tối đa 3 lần
2	Scheduled/event loop	Fresh intake + no-work exit	Nightly docs drift report
3	Stateful loop	Checkpoint + receipts qua runs	Processed feedback IDs + next action
4	Self-verifying loop	External gate kiểm soát exit	CI repair chỉ exit khi original command pass
5	Multi-agent loop	Explicit specialists + handoffs	Explorer/implementer/reviewer
6	Production-supervised	Telemetry, least privilege, approval, rollback	Deploy verifier với release owner

Promotion signal phải là evidence vận hành: frequency đủ lớn cho schedule, lost-context incident cho durable state, false completion cho external gate, coordination bottleneck hoặc independent-review need cho multi-agent, và real user/infra impact cho production supervision. “Framework hỗ trợ” không phải signal; capability unused vẫn mang complexity và attack surface.

Demotion và retirement cũng là maturity. Nếu job ít xuất hiện, verifier drift, operator burden tăng hoặc product workflow đổi, loop có thể quay về report-only, giảm cadence hay bị tắt. Một operating system trưởng thành quản lý vòng đời của automation, không coi mọi loop đã tạo phải tiếp tục tồn tại.

Ưu điểm

• Promotion gắn với recurring failure/operating need cụ thể.
• Ngăn team nhảy thẳng vào orchestration phức tạp.
• Tạo shared language cho risk review và investment.

Nhược điểm

• Level không đo model intelligence hay business value.
• Hai loop cùng level có reliability rất khác.
• Có thể bị dùng như checklist theater nếu không test failure/recovery.

Decision matrix: runtime nào cho job nào? Decision

Matrix đưa ra starting point chứ không thay contract review. Hai job cùng “repo triage” có thể chọn runtime khác nếu một job cần local proprietary corpus còn job kia chỉ đọc public GitHub event. Hãy đọc từng hàng như default khi các constraint khác bằng nhau, rồi override bằng evidence về source, risk và recovery requirement.

Upgrade trigger nên là một failure hoặc SLO không thể đáp ứng ở surface hiện tại. App đóng làm mất schedule, file state gây duplicate sau crash, queue cần timer bền, hoặc external action cần transaction/reconciliation — đây là các lý do nâng runtime. “Muốn scale” quá chung nếu chưa nêu scale của item, concurrency, state hay recovery.

Ngược lại, tránh over-provision. Read-only threshold monitor với command deterministic có thể chạy đáng tin bằng cron, lock và receipt; durable orchestration platform sẽ thêm infra và on-call mà không tăng verified value tương ứng. Runtime tối ưu là runtime làm failure quan trọng nhất observable và recoverable với tổng chi phí thấp nhất.

Migration path: giữ contract, thay execution wiring Migration

Migration an toàn bắt đầu bằng contract equivalence: objective, intake rule, permissions, gate, state semantics, budget và terminal outcomes phải giữ nghĩa trước/sau. Nếu runtime mới không biểu diễn trực tiếp một field, adapter hoặc control bổ sung phải được thiết kế; không được âm thầm làm field yếu đi để migration “thành công”.

State migration là phần rủi ro nhất vì nó mang lịch sử và idempotency. Cần map stable item key, attempt sequence, committed side-effect IDs và active owner; chạy dual-read hoặc shadow mode khi cần; freeze writes trong cutover nếu không reconcile được. Copy progress summary mà bỏ ledger có thể làm runtime mới xử lý lại toàn bộ backlog.

1. 1
   Prototype một iteration

   Interactive/session hoặc executable starter; verifier và receipt phải nhìn thấy.

2. 2
   Thêm trigger + no-work path

   Schedule/event chỉ sau khi intake, dedupe và idempotency rõ.

3. 3
   Externalize state

   Progress ledger → issue/database/checkpoint khi work span nhiều run.

4. 4
   Cứng hóa isolation + permissions

   Worktree/container, scoped secrets, network/action allowlist.

5. 5
   Promote external gates

   CI/eval/policy/human approvals kiểm soát transition và exit.

6. 6
   Durable execution khi cần

   Crash replay, transactional side effects, durable timers và observability.

7. 7
   Production supervision

   SLO, rollback, incident drill, owner, cost controls và retirement plan.

Shadow run là bridge hữu ích: runtime mới intake và verify cùng item nhưng không write, sau đó so decision và receipt với runtime cũ. Disagreement cho thấy khác biệt context, gate hoặc policy adapter. Chỉ chuyển authority sau khi failure paths — không chỉ happy path — cho kết quả tương đương và rollback procedure đã thử.

Migration cũng là dịp xóa debt thay vì bê nguyên abstraction vendor cũ. Giữ semantics của contract, nhưng chuẩn hóa receipt, tách secret, bảo vệ verifier và thêm no-work path nếu trước đây thiếu. Portability không có nghĩa bảo tồn mọi implementation detail; nó nghĩa bảo tồn intent và observable guarantees.

Economics, multi-agent và giới hạn Critical reading

Anthropic khuyến nghị bắt đầu từ solution đơn giản nhất và chỉ tăng agentic complexity khi outcome chứng minh giá trị; agentic systems thường đổi latency/cost lấy flexibility. Addy Osmani cũng lưu ý subagents đốt thêm tokens và human review bandwidth vẫn là trần. Do đó topology và maturity cần một business case, không phải aesthetic preference.

Có thể mô hình hóa thô giá trị mỗi chu kỳ là tần suất × lợi ích của verified outcome, trừ inference, tool, verification, review, failure recovery và platform operations. Từ “verified” là quan trọng: số patch hoặc số run cao không phải value nếu false completion hoặc rework tăng. Economics phải đo ở outcome đã qua gate và chi phí toàn hệ thống.

Multi-agent chỉ đáng thêm vì hai lý do chính: decomposition tạo throughput/quality đo được, hoặc separation of duties giảm một risk cụ thể. Persona đa dạng tự thân không phải benefit. Mỗi handoff thêm serialization loss, token, latency, merge conflict và một boundary cần receipt. Team nên so với single agent có tool/verifier tốt hơn trước khi tăng topology.

Review bandwidth thường là constraint ẩn. Loop có thể tạo candidate nhanh hơn nhưng đẩy hàng chục evidence bundle tới maintainer, làm queue quyết định dài hơn. Metrics nên gồm operator minutes trên mỗi verified outcome, escalation precision và tỷ lệ bundle đủ để quyết ngay. Autonomy tốt nén judgment work; autonomy kém chỉ di chuyển bottleneck.

Giới hạn bằng chứng của repo cũng áp dụng ở đây: pattern matrix, starters và maturity model là design framework mạnh, chưa phải benchmark chứng minh runtime hay level nào tạo ROI phổ quát. Mỗi tổ chức cần chạy pilot, ghi baseline của supervised process và quyết định promotion dựa trên verified value, recovery và risk của chính workload.

Kết luận Wrap

Runtime là nơi policy gặp thực tại. Một contract có thể đẹp trên giấy nhưng chỉ trở thành operating guarantee khi trigger, isolation, credential, checkpoint, verifier và escalation của runtime thực sự enforce được các field tương ứng. Vì vậy selection cần bắt đầu từ semantics bắt buộc và được xác nhận bằng failure drill.

Pattern giữ thiết kế gần recurring value; contract giữ intent qua nhiều run; runtime thực thi; maturity cho biết control nào phải có trước khi tăng autonomy. Chuỗi này ngăn team nhảy từ prompt trực tiếp tới agent platform rồi mới phát hiện không biết success, state hay owner là gì.

Maturity tốt là khả năng chọn đúng điểm dừng. Nhiều loop tạo giá trị tối đa ở Level 2–4 với một actor, state rõ và gate mạnh. Multi-agent hoặc production write chỉ nên xuất hiện khi failure/value case đòi hỏi. Complexity không được xem là bằng chứng của tiến bộ.

Quy tắc thực dụng cuối cùng: prototype trên surface rẻ nhất, externalize contract sớm, đo verified outcome và operator burden, rồi chỉ migrate khi constraint hiện tại đã được chứng minh. Bằng cách đó, runtime phục vụ loop design thay vì định nghĩa ngược operating model của tổ chức.