에이전트·장기 실행

이 문서의 영어 스니펫은 공식 문서 원문이다. 번역하지 말고 그대로 복사해 쓴다 — Fable 5는 영어 지시를 그대로 이해하며, 원문이 곧 검증된 표현이다. 스니펫마다 붙여넣는 위치가 다르므로 각 지침의 앞뒤 설명을 따르되, 큰 그림은 다음과 같다.

기본적으로 더 긴 턴 — 과도한 계획 방지

이전 모델 기준으로 잡아둔 짧은 클라이언트 타임아웃은 Fable 5의 정상 작업 중에도 연결을 끊어버린다. 마이그레이션 전에 타임아웃 상향·스트리밍·진행 상황 표시 UI를 먼저 조정하고, 응답을 기다리며 블로킹하는 대신 예약 작업처럼 비동기로 결과를 확인하는 구조로 하네스를 재설계하는 것이 권장된다.

긴 턴의 부작용 하나는, 모호한 작업에서 계획과 옵션 나열만 하며 시간을 태우는 것이다. 아래 스니펫을 시스템 프롬프트(Claude Code라면 CLAUDE.md)에 넣으면, 이미 확정된 사실을 다시 따지거나 선택하지 않을 옵션을 서술하는 대신 곧바로 실행에 들어간다:

When you have enough information to act, act. Do not re-derive facts already
established in the conversation, re-litigate a decision the user has already made,
or narrate options you will not pursue in user-facing messages. If you are weighing
a choice, give a recommendation, not an exhaustive survey. This does not apply to
thinking blocks.

출처: Longer turns by default

진짜 필요한 순간에만 일시정지

자율 실행에서는 모델이 언제 멈추고 사용자에게 물어볼지를 정해줘야 한다. 예전처럼 "이런 경우엔 물어봐라"를 일일이 나열할 필요는 없다 — Fable 5는 지시 이행(instruction following)이 강해 원칙 한 문단이면 충분하다. 아래 스니펫을 시스템 프롬프트에 넣으면 ① 파괴적·비가역 작업 ② 실질적 스코프 변경 ③ 사용자만 줄 수 있는 입력 — 이 세 경우에만 질문하고 턴을 끝내며, "곧 하겠다"는 약속만 남기고 턴을 끝내는 일이 사라진다:

Pause for the user only when the work genuinely requires them: a destructive or
irreversible action, a real scope change, or input that only they can provide.
If you hit one of these, ask and end the turn, rather than ending on a promise.

출처: Strong instruction following

진행 보고를 근거에 기반시켜라

장기 실행에서 가장 위험한 실패는 하지 않은 일을 했다고 보고하는 것이다. 해법은 간단하다 — 보고하기 전에 각 주장을 이번 세션의 실제 도구 결과와 대조하게 시키는 것이다. 아래 스니펫을 시스템 프롬프트에 넣으면, "테스트 통과했습니다" 같은 낙관적 보고 대신 실패는 출력과 함께, 건너뛴 단계는 건너뛰었다고, 검증된 것은 얼버무리지 않고 단정적으로 보고하게 된다:

Before reporting progress, audit each claim against a tool result from this
session. Only report work you can point to evidence for; if something is not yet
verified, say so explicitly. Report outcomes faithfully: if tests fail, say so
with the output; if a step was skipped, say that; when something is done and
verified, state it plainly without hedging.

출처: Ground progress claims during long runs

병렬 서브에이전트를 적극 활용하라

서브에이전트(subagent — 메인 에이전트가 하위 작업을 맡기려고 띄우는 별도 모델 인스턴스)를 Fable 5는 스스로 잘 활용하므로, 하네스가 할 일은 억제가 아니라 위임 기준을 명시하는 것이다. 컨텍스트를 유지하는 장수명 서브에이전트는 캐시 읽기로 시간·비용을 절약하고, 가장 느린 서브에이전트 하나에 전체가 병목되는 것을 피하게 해준다. 오케스트레이터(orchestrator — 서브에이전트들을 지휘하는 메인 에이전트)와 서브에이전트 사이에는 결과를 기다리며 멈추지 않는 비동기 소통이 권장된다.

아래 스니펫을 시스템 프롬프트에 넣으면, 독립적인 하위 작업은 서브에이전트에 위임한 채 본인 작업을 계속하고, 위임한 서브에이전트가 탈선하면 개입한다:

Delegate independent subtasks to subagents and keep working while they run.
Intervene if a subagent goes off track or is missing relevant context.

출처: Parallel subagents

메모리 시스템을 구축하라

세션이 끝나면 모델이 그 세션에서 배운 것도 사라진다. 기록할 장소(마크다운 파일 하나면 된다)를 주고 운영 규칙을 함께 지시하는 것이 공식 예시다. 아래 스니펫을 시스템 프롬프트(또는 CLAUDE.md)에 넣으면, 교훈이 파일당 1건 + 첫 줄 요약 형태로 쌓이고, 저장소·대화 이력에 이미 있는 내용은 중복 저장하지 않으며, 틀린 것으로 판명된 노트는 삭제된다:

Store one lesson per file with a one-line summary at the top. Record corrections
and confirmed approaches alike, including why they mattered. Don't save what the
repo or chat history already records; update an existing note rather than
creating a duplicate; delete notes that turn out to be wrong.

출처: Construct a memory system

과거 세션으로 메모리를 부트스트랩하라

위 메모리 시스템의 초기화 단계다. 이 스니펫은 시스템 프롬프트가 아니라 사용자 메시지로 1회 실행하는 명령이다. [X] 자리에 메모리 파일 경로를 넣어 보내면, 모델이 서브에이전트를 동원해 과거 세션들을 회고하고 핵심 주제·교훈을 [X]에 저장한 뒤 이후 세션에서 참조한다:

Reflect on the previous sessions we've had together. Use subagents to identify
core themes and lessons, and store them in [X]. Make sure you know to reference
[X] for future use.

출처: Construct a memory system

드물게 발생하는 조기 중단을 방지하라

긴 세션 후반부에 모델이 "이제 ~를 하겠다"는 의도만 말하고 실제 도구 호출 없이 멈추거나, 진행할 정보가 충분한데도 허락을 구하는 경우가 드물게 있다. 사람이 지켜보는 인터랙티브 사용이라면 "continue" 한마디로 해결되지만, 지켜보는 사람이 없는 완전 자율 파이프라인에서는 작업이 그대로 멈춘다.

이때는 아래 스니펫을 시스템 리마인더(system reminder — 하네스가 대화 중간에 끼워 넣는 안내 메시지)로 삽입하는 것이 권장된다. 붙이면 모델이 턴을 끝내기 전에 자신의 마지막 문단을 점검하고, 그것이 계획·분석·질문·약속이라면 지금 도구 호출로 그 작업을 실제로 수행한 뒤에야 턴을 끝낸다:

You are operating autonomously. The user is not watching in real time and cannot
answer questions mid-task, so asking "Want me to...?" or "Shall I...?" will block
the work. For reversible actions that follow from the original request, proceed
without asking. Offering follow-ups after the task is done is fine; asking
permission after already discussing with the user before doing the work is not.
Before ending your turn, check your last paragraph. If it is a plan, an analysis,
a question, a list of next steps, or a promise about work you have not done
("I'll…", "let me know when…"), do that work now with tool calls. End your turn
only when the task is complete or you are blocked on input only the user can
provide.

출처: Rare cases of early stopping

컨텍스트 예산 불안을 만들지 마라

하네스 UI가 남은 토큰 카운트다운을 모델에게 노출하면, 모델이 이를 의식해 멀쩡히 진행 중인 작업을 요약하고 새 세션으로 넘기자고 스스로 제안하는 경우가 있다. 가장 좋은 대응은 카운트를 모델에게 보여주지 않는 것이다. 부득이 보여줘야 한다면, 카운트 옆에 아래 안심 문구를 함께 삽입한다 — 컨텍스트 걱정으로 작업을 중단·요약하는 행동이 사라진다:

You have ample context remaining. Do not stop, summarize, or suggest a new session
on account of context limits. Continue the work.

출처: Rare cases of context-budget concern

자기 검증을 명시적으로 요구하라

오래 도는 빌드 작업일수록 끝에 몰아서 검증하면 늦다. 같은 컨텍스트 안에서 스스로를 비판하게 하는 것(self-critique)보다, 작업 이력을 모르는 신선한 컨텍스트의 검증 서브에이전트를 주기적으로 띄우는 쪽이 더 나은 결과를 낸다는 것이 공식 문서의 설명이다.

아래 스니펫을 작업 프롬프트(태스크 지시문)에 넣고, [X]에 원하는 검증 간격을 지정하면 모델이 그 주기마다 서브에이전트로 스펙과 대조 검증한다:

Establish a method for checking your own work at an interval of [X] as you build.
Run this every [X interval], verifying your work with subagents against the
specification.

출처: Recommended scaffolding changes

난이도 상한선에서 시작하라

쉬운 작업으로만 테스트하면 모델의 능력 범위를 과소평가하게 된다. 가장 좋은 성과를 낸 팀들은 Fable 5를 자신들의 "가장 어려운 미해결 문제"에 적용했다고 공식 문서는 강조한다. 작업을 잘게 쪼개 주는 대신, 근본 원인 조사·장애 디버깅·아키텍처 결정처럼 추가 조사와 검증이 보상받는 모호한 문제를 스코핑 단계부터 통째로 맡기는 것이 좋은 출발점이다.

출처: Recommended scaffolding changes

하네스 재설계 요약

이 지침을 잘 적용한 사례

YouTube

coding기타prompt

하루 오후에 만든 3D 멀티플레이어 해적 게임

Adil (Higgsfield AI) · 2026-06-19

build a first person pirate game where I sail a gallion, fire cannons at enemy ships, and board them for a sword fight on the deck.