Copy English

Why

Most agent systems fail by turning orchestration into prose: one prompt is asked to plan, execute, verify, recover, and decide when it is done. Every extra instruction shares the same context and the same failure surface, so a mistake in planning can quietly become the premise of verification. A graph makes those responsibilities separate nodes with explicit edges and state; a loop makes failure a transition rather than another sentence saying 'please check carefully.'

The distinction matters. A graph answers where does work go next? A loop answers what evidence permits progress, and what happens when the evidence fails? Parallelism is only a graph shape — fan-out and fan-in — and multiplying agents before defining the checker and merge policy multiplies disagreement, cost, and correlated errors. One hundred agents are useful only when their tasks are independent enough to fan out and their outputs have a deterministic or well-scoped way to merge.

Self-improvement should also be read narrowly. The safe version does not let a workflow rewrite itself without a boundary; it records failures, proposes a graph change, evaluates that candidate against a fixed harness, and promotes it only through a gate. The improvement loop is therefore graph → run → trace → evaluate → propose → gated replacement. The evaluator and budget remain outside the graph being improved, just as an agent's spend limit must remain outside the agent. The real upgrade over one giant prompt is inspectable control flow with bounded failure, not autonomy as a slogan.

How it works

Course map

The minimum useful graph

request → planner → worker → checker ──pass──→ result
                         ↑        │
                         └─retry───┘  (bounded)

Each edge carries typed state. The checker returns pass or a structured failure reason; the retry edge has a hard attempt and cost limit. A terminal failure is an expected state, not an infinite loop.

Scale only after the control plane exists

The runtime rule

Do not encode recovery as another paragraph in one agent's prompt. Encode it as an edge that can be traced, counted, bounded, and tested: route → check → repeat or rebuild. Related: the-harness-not-the-model (the deterministic control layer) and agentic-intent-veto (bounds remain outside the agent).

Where it lands in Jayverse

• CI: replace any single do-everything agent prompt with a planner-worker-checker graph. Before adding parallel agents to any Jayverse repo, require one typed handoff and one bounded retry per task, not a single prompt asked to plan, execute and verify at once.
• Auditor: keep the evaluator and budget outside the graph being improved. If agent workflows for Rabbit or Verex are ever allowed to propose their own changes, gate promotion through a fixed Auditor-run evaluation; never let the graph grade itself.
• gitboard: surface retry counts and terminal-failure reasons per agent task. A stuck or looping build should show up as a traced, bounded state on the dashboard, not silent spend.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

Graph & Loop Engineering — 한 프롬프트를 키우지 말고 분기·검사·반복하라

Google의 무료 2시간 강의는 하나의 프롬프트에서 에이전트 그래프, 100개 에이전트 병렬 fan-out, 제어 루프, 자기개선 워크플로까지 이어집니다. 지속되는 기법은 '에이전트를 더 많이'가 아니라 분기·검사·재시도·재구성을 런타임 제어 흐름으로 명시하는 것입니다.

강의를 다섯 체크포인트로 따라가되, '100개 에이전트' 헤드라인을 복제하지 말고 작은 그래프 하나를 출하합니다: 0:35 처음부터 그래프 엔지니어링, 31:17 첫 에이전트 그래프, 43:40 수백 에이전트 병렬 실행, 1:04:58 루프 엔지니어링(route, check, repeat), 1:30:09 자기개선 그래프. planner → worker → checker 세 노드로 만들고, 타입이 있는 handoff 하나, 횟수가 제한된 재시도 하나, 기록되는 실패 이유 하나를 둡니다. checker가 나쁜 결과를 거부하고 merge 단계가 충돌한 결과를 조정할 수 있게 된 뒤에만 병렬 fan-out을 추가합니다. 노트에 강의 링크가 없으므로, 인용 자료로 쓰기 전 Google 공식 출처 링크를 붙여 확인합니다.

왜

대부분의 에이전트 시스템은 오케스트레이션을 산문으로 만들어 실패합니다. 프롬프트 하나에 계획·실행·검증·복구·종료 판단을 모두 시킵니다. 지시를 더할 때마다 같은 컨텍스트와 같은 실패 표면을 공유하므로, 계획의 오류가 조용히 검증의 전제가 될 수 있습니다. 그래프는 이 책임들을 명시적인 edge와 state를 가진 별도 노드로 나누고, 루프는 실패를 '주의해서 확인해'라는 문장 하나가 아니라 상태 전이로 만듭니다.

둘의 차이가 중요합니다. 그래프는 다음 작업이 어디로 가는가?에 답하고, 루프는 어떤 증거가 진행을 허용하며, 증거가 실패하면 무슨 일이 일어나는가?에 답합니다. 병렬 실행은 fan-out과 fan-in이라는 그래프 모양일 뿐입니다. checker와 merge 정책을 정의하기 전에 에이전트 수부터 늘리면 의견 불일치·비용·상관된 오류가 함께 늘어납니다. 100개 에이전트는 작업이 충분히 독립적이고 결과를 결정론적으로 또는 좁은 규칙으로 합칠 수 있을 때만 쓸모가 있습니다.

자기개선도 좁게 읽어야 합니다. 안전한 버전은 워크플로가 경계 없이 자신을 다시 쓰게 하지 않습니다. 실패를 기록하고, 그래프 변경안을 만들고, 고정된 하네스로 후보를 평가한 뒤, 게이트를 통과한 것만 승격합니다. 즉 개선 루프는 graph → run → trace → evaluate → propose → gated replacement입니다. 평가기와 예산은 개선 대상 그래프 바깥에 남습니다 — 에이전트의 지출 상한이 에이전트 바깥에 있어야 하는 것과 같습니다. 거대한 프롬프트 하나보다 나은 진짜 이유는 구호로서의 자율성이 아니라 관찰 가능한 제어 흐름과 제한된 실패입니다.

동작 방식

강의 지도

최소로 쓸모 있는 그래프

요청 → planner → worker → checker ──통과──→ 결과
                       ↑        │
                       └─재시도──┘  (횟수 제한)

각 edge는 타입이 있는 상태를 전달합니다. checker는 pass 또는 구조화된 실패 이유를 반환하고, 재시도 edge에는 시도 횟수와 비용의 단단한 상한이 있습니다. 최종 실패는 무한 루프가 아니라 예상된 상태입니다.

제어면을 만든 뒤에만 확장

런타임 규칙

복구를 한 에이전트 프롬프트의 문단 하나로 넣지 않습니다. 추적·계수·제한·테스트할 수 있는 edge로 만듭니다: route → check → repeat 또는 rebuild. 관련: the-harness-not-the-model(결정론적 제어 계층), agentic-intent-veto(경계는 에이전트 바깥에 둠).

Jayverse에서의 위치

• CI: 모든 걸 한 프롬프트에 맡기는 에이전트를 planner-worker-checker 그래프로 바꾼다. Jayverse 저장소 어디든 병렬 에이전트를 추가하기 전에, 계획·실행·검증을 한 프롬프트에 몰아넣지 말고 타입이 있는 핸드오프 하나와 상한이 있는 재시도 하나를 요구한다.
• Auditor: 평가자와 예산을 개선 대상 그래프 바깥에 둔다. Rabbit이나 Verex의 에이전트 워크플로우가 스스로 변경을 제안하게 하더라도, 승격은 고정된 Auditor 평가를 거치게 한다. 그래프가 자기 숙제를 채점하게 두지 않는다.
• gitboard: 에이전트 작업별 재시도 횟수와 종료 실패 사유를 노출한다. 멈추거나 도는 빌드가 조용한 지출이 아니라 추적 가능한, 범위가 정해진 상태로 대시보드에 나타나야 한다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑