Loop Engineering — Từ một agent run đến hệ thống tự vận hành có kiểm soát

Luận đề: leverage point đã chuyển từ prompt sang operating system Thesis

Loop Engineering là thực hành thiết kế recurring AI-agent systems có thể tìm việc, hành động trong boundary rõ, kiểm chứng bằng bằng chứng bên ngoài, lưu state qua nhiều run và tự quyết định retry, report, escalate hay exit trong một budget hữu hạn. Nó không phải prompt được lặp lại, không phải software event loop, và cũng không đồng nghĩa với cron job có gắn model.

Cách hiểu ngắn nhất là: prompt engineering thiết kế lời yêu cầu, còn Loop Engineering thiết kế điều gì sẽ xảy ra sau lời yêu cầu đó. Khi agent hoàn thành một bước, hệ thống dựa vào đâu để biết nó đã làm đúng? Nếu thất bại, failure nào đáng thử lại và failure nào cần con người? Nếu process chết giữa chừng, lần chạy sau đọc state ở đâu? Nếu không còn việc, loop có biết im lặng hay vẫn tự tạo thêm hoạt động? Những câu hỏi này không nằm trong năng lực ngôn ngữ của model; chúng là quyết định kiến trúc và vận hành.

Ở mô hình làm việc tương tác truyền thống, con người vô thức đảm nhiệm toàn bộ control plane. Ta đọc output, nhớ điều đã thử, copy log mới vào context, quyết định cho agent chạy tiếp, giới hạn scope và dừng khi thấy rủi ro. Khi chuyển sang schedule, background task hoặc run-until-done, các quyết định ấy không biến mất. Nếu không được thiết kế thành contract, chúng trở thành hidden defaults mà model hoặc runtime tự lấp đầy.

Vì vậy, Loop Engineering không chủ yếu hỏi “làm sao để agent thông minh hơn?”. Nó hỏi “làm sao để một hệ thống dùng agent có thể lặp lại mà vẫn reviewable, bounded và accountable?”. Đây là chuyển dịch từ tối ưu chất lượng một câu trả lời sang tối ưu hành vi của một recurring job qua thời gian. Model vẫn quan trọng, nhưng model chỉ là một actor bên trong hệ thống lớn hơn.

Luận đề của báo cáo này là: độ tin cậy của loop đến từ cấu trúc bên ngoài model — work intake có nguồn gốc, workspace có giới hạn, verifier độc lập, state bền, budget hữu hạn, receipt truy nguyên được và human owner có quyền can thiệp. Một model mạnh có thể tăng xác suất thành công của mỗi attempt; nó không tự tạo ra những thuộc tính vận hành đó.

"

Prompt, context và harness cải thiện một run; Loop Engineering quản trị recurring agent work qua thời gian.

Vì sao Loop Engineering xuất hiện lúc này? Context

Khái niệm này xuất hiện khi ba xu hướng hội tụ. Thứ nhất, coding agents và general-purpose agents đã giữ được mạch hành động dài hơn: chúng có thể đọc nhiều file, gọi tool, quan sát lỗi, sửa và kiểm tra lại thay vì chỉ sinh một đoạn text. Thứ hai, runtime đã có các primitive cần cho recurring work — schedule, goal, worktree, skill, connector, sub-agent và background execution. Thứ ba, chi phí generation giảm tương đối nhanh hơn chi phí judgment: tạo thêm một patch dễ hơn, nhưng chứng minh patch đúng và đủ an toàn vẫn đắt.

Bài viết của Addy Osmani mô tả sự chuyển dịch này bằng một hình ảnh trực quan: thay vì liên tục prompt agent, người dùng thiết kế một hệ thống tự tìm việc, giao việc, kiểm tra, ghi nhớ và quyết định bước tiếp theo. Điểm đáng chú ý không phải vòng lặp shell mới lạ; nó là việc các primitive trước đây rời rạc nay trở thành product capabilities phổ biến và có thể ghép thành một operating model.

Hướng dẫn long-horizon của OpenAI cũng cho thấy một run dài không đứng vững nhờ “một prompt khổng lồ”. Nó dùng spec để đóng băng target, plan để chia milestone, runbook để quy định cách hành động, validation ở mỗi mốc và documentation như audit log sống. Đó chính là các mảnh của một loop contract ở quy mô một project: externalized intent, checkpoint, verifier và durable memory.

Tuy nhiên, khả năng chạy lâu không đồng nghĩa khả năng vận hành lặp lại. Một session 25 giờ vẫn có thể dựa vào state của một process và một objective duy nhất. Một operational loop phải xử lý thêm cold start, duplicate item, stale evidence, permission drift, budget theo chu kỳ, no-work outcome và handoff giữa nhiều run. Time horizon dài là điều kiện thúc đẩy Loop Engineering, không phải bằng chứng rằng bài toán đã được giải.

Nói cách khác, leverage point đã dịch chuyển. Khi generation là bottleneck, ta đầu tư vào prompt và model. Khi agent có thể tự tạo nhiều candidate action, bottleneck chuyển sang chọn việc đúng, chứng minh kết quả, giữ state và giới hạn blast radius. Loop Engineering là tên gọi cho phần kỹ thuật quanh bottleneck mới đó.

Giải phẫu định nghĩa: mỗi động từ là một trách nhiệm hệ thống Definition

Working Definition của repo mô tả Loop Engineering là thực hành thiết kế recurring systems có thể discover work, delegate, verify, persist state, decide next actions và run again. Câu này dễ bị đọc như một danh sách feature. Thực chất, mỗi động từ đóng một lỗ hổng reliability khác nhau; bỏ bất kỳ động từ nào cũng làm hệ thống đổi bản chất.

Recurring — sự lặp lại phải được thiết kế trước

Recurring không có nghĩa “agent thất bại nên ta bảo thử lại”. Nó nghĩa recurrence là một phần của operating model ngay từ đầu: có trigger, identity của job, cadence hoặc goal condition, state qua các lần chạy và stop rule. Một retry tình cờ vẫn là thao tác tương tác; một loop biết trước vì sao lần chạy tiếp theo được phép tồn tại.

Discover / receive work — agent không được tự invent backlog

Loop phải nối với một nguồn việc thật: PR đang bị block, CI failure, issue queue, dashboard alert, feedback stream hoặc corpus cần refresh. Intake không chỉ là connector đọc dữ liệu; nó còn có selection rule, dedupe, freshness và no-work behavior. Không có intake rõ, một agent được khuyến khích “luôn hữu ích” rất dễ biến maintenance loop thành cỗ máy tự mở rộng scope.

Delegate và act — authority phải đi cùng responsibility

Delegate không mặc định nghĩa multi-agent. Một single agent vẫn có thể nhận role rõ và được kiểm tra bằng deterministic gate. Khi có maker-checker hay manager-worker, delegation phải nêu ai khám phá, ai thay đổi, ai kiểm chứng và output nào là handoff contract. Số agent không tạo separation of duties nếu tất cả cùng dùng một authority và cùng tin vào một summary không có raw evidence.

Act luôn diễn ra trong một workspace cụ thể. Worktree, branch, container, sandbox hay read-only mode không chỉ là chi tiết runtime: chúng định nghĩa blast radius. Cùng một instruction “fix this” có ý nghĩa rất khác khi agent chỉ được sửa hai file trong branch so với khi nó có credential production và filesystem của người dùng.

Verify — biến output thành claim có thể kiểm tra

Model tạo ra candidate result; verifier quyết định candidate có thỏa điều kiện hay không. Test, typecheck, schema, threshold, frozen benchmark, policy check và reviewer decision là các loại evidence khác nhau. Chúng không hoàn hảo, nhưng chúng đưa completion ra khỏi cảm giác của actor. Nếu cùng agent vừa tạo thay đổi vừa là nguồn duy nhất tuyên bố “đã xong”, hệ thống có feedback nhưng chưa có accountability.

Persist — state là API giữa các run

Conversation context là working memory tạm thời; durable state là contract qua thời gian. Run sau cần biết item ID, phase, attempt count, evidence đã quan sát, side effect đã commit, blocker còn lại và next action. Khi state chỉ nằm trong chat hoặc một summary tùy hứng, cold run không thể phân biệt “chưa làm” với “đã thử và thất bại”, dẫn đến duplicate work và repeated side effects.

Decide và run again — repetition là kết quả của policy

Phần quan trọng nhất của loop không phải cạnh quay lại, mà là các cạnh không quay lại. Evidence mới và budget còn có thể dẫn tới retry; thiếu authority dẫn tới escalation; không có item dẫn tới no-op report; goal được chứng minh dẫn tới exit; failure lặp lại hoặc budget hết dẫn tới stop-without-success. Một vòng lặp vô điều kiện chỉ tự động hóa momentum. Loop Engineering tự động hóa một decision policy có giới hạn.

Bản đồ bằng chứng của repo Corpus

Repo awesome-loop-engineering vừa là một catalog, vừa là một đề xuất chuẩn hóa lĩnh vực. Hai vai trò này cần được đọc tách biệt. Catalog cho biết các paper, tool, benchmark và practitioner pattern nào có liên quan; phần definition, contract schema, pattern library và maturity model là synthesis của maintainer nhằm biến landscape đó thành artifact có thể dùng. Số lượng nguồn cho breadth, nhưng không tự tạo consensus cho taxonomy.

Con số đáng chú ý nhất không phải 579 mà là tỷ lệ giữa direct và enabling. Chỉ 162 rows được gắn direct scope; 381 rows là enabling evidence như harness, memory, orchestration, verifier hoặc runtime. Điều này phản ánh đúng bản chất cross-layer của lĩnh vực, đồng thời nhắc ta không nên lấy thành công của một component làm bằng chứng cho reliability của toàn operational loop.

Ví dụ, một sandbox tool chứng minh khả năng cô lập execution; nó không chứng minh intake sẽ dedupe đúng. Một benchmark agent chứng minh task success trong distribution nhất định; nó không chứng minh scheduled job sẽ resume sau crash, giữ cost budget hoặc escalation đúng owner. Một memory framework chứng minh persistence primitive; nó không đảm bảo state được update ở đúng transaction boundary. Mỗi nguồn trả lời một phần của contract, hiếm khi trả lời cả hệ thống.

Phân bố lifecycle cũng cho thấy field hiện nghiêng về những phần dễ quan sát: verification, workspace, state và context có nhiều tài liệu hơn objective, trigger hay intake. Nhưng trong production, failure ở intake — chọn nhầm item, đọc stale state, xử lý trùng — có thể gây thiệt hại trước cả khi agent bắt đầu reasoning. Báo cáo này vì vậy dùng corpus như evidence map, không dùng nó như bảng xếp hạng mức độ quan trọng.

Bản đồ sáu kỹ thuật nền tảng Overview

Sáu kỹ thuật dưới đây không phải sáu mẹo độc lập. Chúng tạo một chuỗi dependency: xác định đúng layer trước khi thiết kế lifecycle; lifecycle được đóng băng thành contract; contract chỉ đáng tin khi có verification và durable state; sau đó mới chọn pattern/runtime và tăng maturity. Đọc ngược thứ tự thường tạo ra hệ thống nhiều automation nhưng ít control.

Đơn vị thiết kế: recurring job, không phải một prompt Mental model

Prompt có lifetime của một request hoặc một run. Recurring job có lifetime dài hơn model context, process và đôi khi cả model version. Vì thế, job cần một identity ổn định, một nguồn work, state schema, acceptance criteria, budget, owner và lifecycle của riêng nó. Nếu các yếu tố này chỉ nằm trong prompt, mỗi run có thể diễn giải lại operating policy theo context hiện tại.

Hãy so sánh hai câu. “Sửa CI cho tới khi xanh” là một instruction có mục tiêu nhưng còn mơ hồ về authority và evidence. “Khi required check X fail trên PR đang mở, nhận đúng failure đó, tạo clean worktree tại failing SHA, thử tối đa ba narrow patches, không sửa verifier, chỉ success khi original command pass; nếu flaky hoặc vượt scope thì comment receipts cho owner” là một recurring job đã bắt đầu có contract.

Sự khác biệt không nằm ở độ dài câu chữ. Bản thứ hai xác định identity của item, isolation boundary, mutation policy, independent gate, budget và escalation. Những quyết định này có thể được serialize thành JSON, review trong pull request, validate bằng schema và thực thi trên nhiều runtime. Prompt của implementer vẫn có thể ngắn vì operating policy đã sống ở nơi khác.

Mental model hữu ích là ba vòng lặp lồng nhau. Model loop diễn ra bên trong inference; agent loop reason → tool → observe trong một task; operational loop trigger → intake → run → verify → persist → decide qua nhiều session. Mỗi loop có time scale, state và failure mode khác nhau. Thành công ở vòng trong không đủ để chứng minh vòng ngoài đáng tin.

Đây cũng là lý do benchmark task success cần được đọc cẩn thận. Một agent giải được issue trong sandbox chưa cho biết hệ thống sẽ chọn issue nào, tránh xử lý trùng ra sao, có sửa test để “thắng” không, resume sau crash thế nào, chi phí tích lũy bao nhiêu hay ai nhận handoff khi product requirement mâu thuẫn. Operational reliability là một đơn vị đánh giá khác với model capability.

Nền tảng khái niệm Foundation

flowchart LR
  A["Objective + trigger"] --> B["Discover / intake"]
  B --> C["Load state + context"]
  C --> D["Delegate + act"]
  D --> E["External verification"]
  E --> F["Persist state + receipts"]
  F --> G{"Decision policy"}
  G -->|"new evidence + budget"| C
  G -->|"goal proven"| H["Exit"]
  G -->|"authority / ambiguity / budget"| I["Escalate"]
  G -->|"no qualifying work"| J["Report / no-op"]

type Outcome = "retry" | "report" | "escalate" | "exit";

while (budget.remaining()) {
  const work = await intake.discover(trigger);
  if (!work) return receipt.noWork();

  const result = await agent.act({
    work,
    context: await context.loadFresh(),
    workspace: sandbox.scoped()
  });

  const evidence = await verifier.check(result);
  await state.persist({ result, evidence });

  const next: Outcome = policy.decide(evidence, budget);
  if (next !== "retry") return handoff(next, evidence);
}

3. Loop Contract đóng băng 11 quyết định vận hành

F.3

schemas/loop-contract.schema.json · examples/*.json

Khi không còn người steer từng turn, câu hỏi chưa trả lời trở thành hidden default. Contract biến objective, authority, evidence, memory và stopping rule thành policy có thể review trước khi chạy.

Trong một phiên làm việc có người giám sát, contract thường tồn tại trong đầu người dùng. Người đó biết repo nào được sửa, biết “test xanh” chưa chắc đủ, nhớ attempt trước đã thất bại ở đâu và tự dừng khi output bắt đầu lệch mục tiêu. Khi bỏ người khỏi từng turn, các quyết định ngầm ấy phải trở thành dữ liệu có thể review, version và validate. Loop Contract là artifact để làm việc đó.

Mười một operating parts chia thành ba câu hỏi lớn. Set up trả lời loop tồn tại để làm gì, được đánh thức khi nào, nhận item nào và hành động ở đâu. Run quy định context, role, evidence và memory nối các attempt. Govern đặt trần tài nguyên, đường escalation và điều kiện exit. Trường name thứ mười hai trong schema là identity của contract, không phải một quyết định vận hành mới.

Set up objective · trigger · intake · workspace   Run context · agents · verification · state   Govern budget · escalation · exit

Giá trị của contract không nằm ở độ dài. Một contract tốt làm cho omission trở nên rõ: không có no-work behavior, không có disallowed action, không có owner cho escalation, hay exit condition chỉ viết “agent believes done”. Những khoảng trống này dự báo failure mode trước khi chạy. Schema validation chỉ bắt lỗi cấu trúc; design review vẫn phải đánh giá policy có phù hợp với rủi ro thực tế hay không.

Contract cũng tách policy khỏi runtime. Cùng một objective và verifier có thể chạy bằng cron, CI event hoặc một orchestration platform khác mà không thay đổi ý nghĩa của job. Ngược lại, đổi từ single agent sang maker-checker là thay đổi contract vì nó đổi authority và handoff. Tính portable này giúp team review operating model trước khi bị cuốn vào lựa chọn vendor hoặc framework.

Không có “next action” thứ mười ba. Next action là output của decision policy khi kết hợp evidence, durable state, budget, escalation và exit rules; biến nó thành một field tĩnh sẽ làm mất bản chất feedback của loop.

→ Phân tích sâu: 11 operating parts, 12 schema keys, state machine và CI repair case study

Reliability và vận hành Operations

flowchart LR
  A["Recurring symptom"] --> B["Named pattern"]
  B --> C["Adapted Loop Contract"]
  C --> D["Runtime + isolation"]
  D --> E["Agent / workflow execution"]
  E --> F["Evidence + receipts"]
  F --> G{"Policy decision"}
  G -->|"improve contract"| C
  G -->|"retry"| E
  G -->|"handoff / exit"| H["Owner"]

Bốn hướng mở rộng: từ design kit tới operating discipline Deep dives

Ba deep dive nền tảng giải thích contract, reliability và lựa chọn runtime. Bốn bài mở rộng dưới đây đi vào các boundary nơi recurring systems thường vỡ khi chuyển từ prototype sang vận hành: nhận việc, phối hợp nhiều actor, đo outcome/causality và triển khai quyền tự chủ vào production.

Trigger không phải work order

Schedule, event và manual launch chỉ đánh thức runtime. Intake phải chuẩn hóa identity, kiểm freshness, dedupe, eligibility, capacity và lease trước model call. Bài này nối taxonomy của repo với CloudEvents, GitHub Actions concurrency và durable execution để đóng duplicate, stale-work và crash windows.

→ Phân tích sâu: trigger, intake, dedupe, leases và crash-safe scheduling

Multi-agent là protocol phối hợp

Manager, handoff, worker và checker khác nhau ở completion ownership, dependency graph và authority. Bài này chỉ ra khi nào parallelism có lợi, structured handoff cần mang gì và vì sao hai personas chưa tạo được independence.

→ Phân tích sâu: topology, ownership, handoff và coordination cost

Eval và telemetry cần gặp nhau ở receipt

Evaluation đo outcome và consistency; observability dựng lại causal path. Bài này mở rộng workstream shared evaluation protocol của repo thành full-loop fixtures, grader hierarchy, OpenTelemetry spans, recovery metrics và reproducibility bundle.

→ Phân tích sâu: full-loop evals, traces, receipts và longitudinal metrics

Autonomy phải được rollout như production capability

Observe, recommend, approval-gated và bounded action là các permission envelopes khác nhau. Bài này áp dụng canary/SRE, lifecycle risk và agentic security vào promotion, demotion, kill/revoke/rollback, incident drill và retirement.

→ Phân tích sâu: progressive autonomy, canary, incident response và lifecycle governance

Evidence, phản biện và giới hạn Critical reading

Một repo “awesome list” mạnh ở khả năng tổ chức landscape nhưng có giới hạn epistemic riêng. Nó cho ta biết artifact, project và paper nào cùng chạm vào recurring agent systems; nó không phải controlled study chứng minh Loop Engineering làm mọi team nhanh hơn hay an toàn hơn. Vì vậy, cần tách ba mức claim: repo có artifact thật, artifact tạo thành một conceptual framework nhất quán, và framework tạo hiệu quả ngoài thực địa. Hai mức đầu có bằng chứng trực tiếp hơn mức cuối.

Điều repo chứng minh tốt

• Một vocabulary và artifact chain nhất quán cho recurring agent systems.
• Schema, contracts và starters có thể inspect/chạy, không chỉ là essay.
• Coverage rộng về verification, harness, runtime, memory, security và evaluation.
• Anti-patterns và research agenda thừa nhận false completion, infinite loops, cost và human oversight.

Đóng góp thuyết phục nhất là artifact language. Working Definition đặt boundary; pattern matrix nối symptom với control; Loop Contract biến control thành dữ liệu; JSON Schema bắt lỗi cấu trúc; runnable starters cho thấy lifecycle có thể được hiện thực hóa. Chuỗi này cho phép một team tranh luận trên objective, evidence và authority cụ thể thay vì tranh luận chung chung rằng agent “đủ thông minh” hay chưa.

Điều chưa thể suy ra

• Không thể suy ra loop luôn tốt hơn supervised single run hay fixed workflow.
• Không thể lấy số lượng nguồn làm bằng chứng adoption hoặc reliability.
• Schema-valid contract không đồng nghĩa policy đúng hoặc verifier đáng tin.
• Benchmark task success chưa đo đầy đủ recovery, idempotency, auditability, cost và operator burden qua thời gian.

Corpus cũng thiên về component evidence: 381/579 nguồn được xếp enabling và chỉ 162 nguồn direct. Nhiều tài liệu tốt về benchmark, memory, orchestration hoặc security chứng minh một mảnh của stack, nhưng không tự chứng minh recurring system chứa các mảnh đó sẽ recovery tốt, idempotent, tiết kiệm hay dễ vận hành. Đây không phải lỗi của catalog; nó là ranh giới cần giữ khi chuyển từ “có nhiều nền tảng liên quan” sang “operating model đã được xác nhận”.

Khoảng trống nghiên cứu lớn nằm ở longitudinal evidence. Ta cần benchmark đo nhiều run chứ không chỉ task success: tỷ lệ phục hồi sau crash, duplicate side effect, verifier drift, false completion, thời gian human review, chi phí cho mỗi verified outcome và tỷ lệ escalation hữu ích. Một loop thắng benchmark trong sandbox nhưng tiêu tốn quá nhiều operator attention có thể vẫn thất bại về mặt sản phẩm.

Cuối cùng là verification horizon: không verifier nào nhìn thấy toàn bộ thực tại. Test đo behavior đã encode; metric đo proxy; reviewer quan sát một snapshot. Khi loop tối ưu lặp lại theo cùng một proxy, nguy cơ Goodhart tăng lên. Thiết kế tốt phải version verifier, theo dõi drift, dùng nhiều evidence độc lập khi rủi ro cao và giữ đường escalation cho những quyết định không thể nén thành gate.

Playbook: thiết kế loop đầu tiên Apply

Bước đầu tiên không phải chọn framework mà là quyết định công việc có đáng trở thành loop hay không. Candidate tốt có recurrence thật, input có thể nhận diện, action có thể giới hạn, external signal đủ đáng tin và owner sẵn sàng nhận exception. Nếu thiếu một trong các điều kiện này, hãy bắt đầu bằng checklist, dashboard hoặc supervised workflow để học failure mode trước.

Với candidate phù hợp, hãy thiết kế từ cuối về đầu. Viết một câu “verified finish” đủ cụ thể để người khác có thể kiểm tra mà không đọc suy nghĩ của agent. Từ finish condition suy ra verifier; từ verifier suy ra evidence cần thu; từ evidence suy ra state cần lưu; rồi mới xác định actor, prompt và runtime. Trình tự này ngăn generation capability lấn át điều kiện thành công.

1. Chọn một recurring symptom nhỏ. Ví dụ CI failure có command tái hiện được.
2. Viết verified finish trước. Exit code, threshold hoặc named reviewer decision.
3. Đóng băng contract. Intake, allowed/disallowed actions, state, budget, escalation, exit.
4. Prototype một item/một iteration. Chạy trong worktree/sandbox, read-mostly nếu có thể.
5. Inject failure. Timeout, duplicate item, broken verifier, missing credential, repeated evidence.
6. Review receipts và economics. Chỉ tăng cadence/budget/topology khi có measurable benefit.

Prototype tốt nhất là loop nhỏ nhất còn giữ nguyên semantics: một loại item, một workspace cô lập, một iteration, một verifier và một receipt. Chạy nó bằng tay nhiều lần trước khi thêm schedule. Mục tiêu giai đoạn này không phải throughput mà là quan sát xem contract có đủ để một cold run hiểu đúng trạng thái và một operator giải thích đúng mọi transition hay không.

Failure injection là phần của design, không phải QA bổ sung. Hãy cố tình tạo stale input, duplicate trigger, timeout, verifier unavailable, credential thiếu, side effect thành công nhưng checkpoint thất bại và nhiều attempt trả cùng một signature. Mỗi tình huống phải kết thúc bằng retry có thông tin mới, no-op, rollback hoặc escalation có owner — không phải bằng một loop tiếp tục vì “còn budget”.

Chỉ tăng cadence, budget, write permission hoặc topology sau khi receipts cho thấy lợi ích đo được. Promotion review nên so sánh verified outcomes với tổng chi phí và operator burden, đồng thời xem lại false completion và near miss. Autonomy là quyền được cấp dựa trên evidence vận hành, không phải thuộc tính mặc định của model.

Kết luận Wrap

Cách đọc hữu ích nhất: Loop Engineering là control-plane engineering cho agent work qua thời gian. Giá trị của repo không nằm ở khẩu hiệu hay con số 579, mà ở việc nối concept → pattern → contract → schema → runtime → receipt thành một chuỗi có thể review và tái sử dụng. Một loop tốt không “tự chủ càng nhiều càng tốt”; nó làm rõ công việc nào được phép lặp, bằng chứng nào đủ mạnh, state nào phải sống sót và lúc nào con người phải lấy lại quyền quyết định.

Hệ quả sâu hơn là đơn vị kiến trúc cũng thay đổi. Prompt không còn là artifact trung tâm; state schema, verifier, permission boundary và transition policy trở thành first-class. Model có thể được thay thế hoặc nâng cấp, nhưng recurring job vẫn phải giữ identity, history và accountability. Đây là điểm Loop Engineering gặp distributed systems, SRE, workflow orchestration và safety engineering.

Khả năng quan trọng nhất của một loop không phải “chạy mãi”, mà là dừng đúng lý do. Nó phải biết khi goal đã được chứng minh, khi không còn việc, khi attempt tiếp theo không mang thêm thông tin, khi authority không đủ và khi risk đã vượt appetite. Thiết kế cạnh exit, no-op và escalation thường quyết định chất lượng hệ thống nhiều hơn thiết kế cạnh retry.

Vì thế, deliverable thực tế đáng giá không nhất thiết là một “đội agent tự trị”. Nó có thể chỉ là một recurring job nhỏ, có contract đọc được, workspace hẹp, verifier độc lập, checkpoint bền và receipt tốt. Cấu trúc này cho phép team tăng autonomy từng bước mà vẫn giữ khả năng review và rollback — thứ một demo nhiều agent thường không thể hiện.

Nếu chỉ giữ lại một câu hỏi sau báo cáo, hãy dùng câu này: khi không còn người đứng cạnh agent ở mỗi turn, hệ thống nào sẽ thay người đó chọn việc, giới hạn quyền, kiểm tra kết quả, nhớ lịch sử và quyết định dừng? Câu trả lời cụ thể cho năm trách nhiệm ấy chính là Loop Engineering của hệ thống bạn.