Agent Loop Systems

TL;DR

에이전트가 shared state를 읽고, 제한된 작업을 수행하고, 검증 가능한 결과를 다시 기록하는 반복 운영 구조.

Agent loop는 일정이나 이벤트에 맞춰 state를 읽고, work를 수행하고, state를 갱신한 뒤 다시 반복하는 구조로 설명된다. [2]
GitHub Issues나 Linear 같은 control plane은 사람이 autonomous agent의 진행 상태를 inspect할 수 있게 하는 shared state로 제시된다. [2]
Manager loop는 backlog ticket을 risk/type/agent-readiness로 분류하고, worker loop는 agent-ready/low-risk ticket을 code, review, check, PR 생성으로 이어지는 inner workflow에 태운다. [1] [2]
Guardrail은 ticket update 권한 제한, clean branch 확인, issue count limit, automated review, test 같은 방식으로 agent의 권한과 실행량을 좁히는 장치다. [2]
Evaluation 기준으로 ticket rework, first-pass closure, code correctness, human feedback amount가 제시된다. [2]

Matthew Berman 영상은 agent loop를 AI coding agent가 지정된 goal을 향해 자율적으로 일하게 하는 구조로 정의하고, 최소 구성요소를 trigger와 goal로 둔다 [2].
영상은 trigger를 manual, schedule, action으로 나누고, goal을 deterministic하게 검증 가능한 목표와 LLM-as-judge 목표로 나눈다 [2].
Loop Library 사례는 page-load threshold, docs sweep, architecture satisfaction, logging coverage, production error sweep, SEO/GEO audit, full product evaluation처럼 반복 가능한 운영 작업을 loop로 만든다 [2] [3].
영상의 caveat는 goal 설계가 어렵고 LLM-as-judge 목표가 brittle할 수 있으며, 장기 loop가 token budget을 크게 소모할 수 있다는 점이다 [2].

Loop engineering is not an end-to-end product factory; it is a layer above harness engineering that repeats already-verifiable work and separates LLM-autonomous steps from human approval gates [1] [2].
Practical loops need a checkable goal, verification mechanism, persistent state, hard stop, and cost boundary; otherwise they become long-running subjective tasks with weak evidence [4] [6] [7].
GitHub Issues or Linear work as a control plane because they hold ticket state, metadata, labels, evidence comments, and PR links outside a single model context [2] [8] [10].