KAIROS: 상시 가동 Persistent Agent 모드

이 과정에서 지금까지 살펴본 모든 기능, boot sequence, tool call, memory, compaction은 근본적으로 반응형 모델에서 동작합니다. 사용자가 입력하면 Claude가 응답하고, 세션은 끝납니다. KAIROS는 이 계약을 깨는 시스템에 붙은 Anthropic 내부 코드명입니다.

KAIROS 아래에서 Claude Code는 상시 실행 daemon이 됩니다. 한 번 부팅되면 재시작을 넘어 persistent session을 유지하고, 스스로 check-in을 예약하고, 사용자가 보고 있지 않을 때 메시지를 보내며, 사용자가 자는 동안 자기 memory를 통합합니다. CLI 도구라기보다 백그라운드에서 일하는 직원에 더 가깝습니다.

Feature Flag 시스템

KAIROS는 단일 스위치가 아닙니다. 코드베이스를 보면 관련 flag들의 가족이 드러나며, 각 flag는 상시 가동 경험의 특정 조각을 서로 독립적으로 출시할 수 있게 합니다.

KAIROS mode의 모든 것은 global state store 안의 단 하나의 boolean을 중심으로 돌아갑니다. bootstrap/state.ts를 보면 다음과 같습니다.

// bootstrap/state.ts (1085번째 줄)
export function getKairosActive(): boolean {
  return STATE.kairosActive  // 기본값: false
}

export function setKairosActive(value: boolean): void {
  STATE.kairosActive = value
}

이 boolean은 런타임에서 "지금 assistant mode인가?"를 나타내는 flag입니다. boot 중 main.tsx에서 설정되며, 어떤 tool의 사용 가능 여부를 검사하기도 전에 켜집니다. 그리고 그 영향은 곳곳으로 퍼져 나갑니다.

proactive 또는 KAIROS mode의 핵심은 tick이라 불리는 heartbeat 메커니즘입니다. 자율적으로 실행 중일 때 모델은 주기적으로 <tengu_tick> XML 메시지를 받습니다. 쉽게 말해 "깨어 있어, 이제 뭘 할까?"라고 가볍게 찔러 주는 신호입니다.

constants/prompts.ts의 system prompt, 즉 getProactiveSection()에는 이렇게 적혀 있습니다.

// proactive가 켜졌을 때 모델이 system prompt에서 실제로 받는 문구

"You are running autonomously. You will receive <tengu_tick> prompts that keep you
alive between turns. Treat them as '깨어 있다, 이제 뭘 할까?' 정도로 받아들이면 됩니다. Each
<tengu_tick> contains the user's current local time."

"Multiple ticks may be batched into a single message. This is normal. Just process
the latest one. Never echo or repeat tick content in your response."

"**If you have nothing useful to do on a tick, you MUST call Sleep.** Never respond
with only a status message like '아직 기다리는 중입니다'. That wastes a turn and burns tokens."

SleepTool, 비용을 의식한 유휴 대기

Sleep tool은 feature('PROACTIVE') || feature('KAIROS')일 때만 로드됩니다. 목적은 단 하나입니다. 놀고 있는 매초마다 API call을 태우지 않고도 모델이 CPU를 양보하게 만드는 것입니다.

// tools/SleepTool/prompt.ts
export const SLEEP_TOOL_PROMPT = `지정한 시간 동안 대기합니다.
사용자는 언제든 이 sleep을 중단할 수 있습니다.

할 일이 없거나 무언가를 기다릴 때 사용하세요.

<tengu_tick> prompt를 받을 수 있습니다. 잠들기 전에 할 만한 일이 있는지 먼저 살펴보세요.

잠에서 깰 때마다 API call 비용이 들지만, prompt cache는 5분 동안 비활성 상태가 이어지면 만료됩니다.
이 점을 감안해 균형을 맞추세요.`

이 prompt에는 세 가지 중요한 설계 포인트가 담겨 있습니다.

• 모델이 sleep duration을 직접 선택합니다. 느린 프로세스를 기다릴 때는 길게, 빠르게 반복 중일 때는 짧게 잡습니다.
• sleep은 Bash(sleep ...)를 호출하는 것보다 명시적으로 더 저렴합니다. shell process를 붙잡고 있지 않기 때문입니다.
• 5분 prompt cache 만료는 단단한 비용 하한선입니다. 그보다 더 자주 깨면 cache 생성 토큰을 낭비하게 됩니다.

Sleep 중단, Priority Queue

사용자가 sleep 도중 메시지를 보내면 types/textInputTypes.ts의 QueuePriority system이 wakeup을 처리합니다.

// types/textInputTypes.ts
type QueuePriority = 'now' | 'next' | 'later'

// 'now'  : 현재 tool call을 즉시 중단 (Esc + send)
// 'next' : 현재 tool이 끝날 때까지 기다린 뒤, tool result와 다음 API call 사이에 주입
//          진행 중인 SleepTool 호출도 깨운다.
// 'later': 턴 종료 시 drain. 이것도 SleepTool을 깨운다.

Terminal Focus 인지

proactive system prompt는 사용자의 terminal에 focus가 있는지 없는지에 대해 모델에게 명시적인 지침을 줍니다. 이 정보에 따라 얼마나 자율적으로 움직일지가 달라집니다.

"**Unfocused**: The user is away. Lean heavily into autonomous action,
make decisions, explore, commit, push. Only pause for genuinely
irreversible or high-risk actions.

**Focused**: The user is watching. Be more collaborative, surface choices,
ask before committing to large changes."

KAIROS는 표준 Claude Code에는 없는 전용 tool 묶음을 도입합니다. 각 tool은 feature flag에 따라 tools.ts에서 조건부로 로드됩니다.

// tools.ts, 조건부 로딩 (단순화 버전)
const SleepTool           = feature('PROACTIVE') || feature('KAIROS')
                             ? require('./tools/SleepTool/SleepTool.js').SleepTool : null

const SendUserFileTool    = feature('KAIROS')
                             ? require('./tools/SendUserFileTool/SendUserFileTool.js').SendUserFileTool : null

const PushNotificationTool = feature('KAIROS') || feature('KAIROS_PUSH_NOTIFICATION')
                             ? require('./tools/PushNotificationTool/PushNotificationTool.js').PushNotificationTool : null

const SubscribePRTool     = feature('KAIROS_GITHUB_WEBHOOKS')
                             ? require('./tools/SubscribePRTool/SubscribePRTool.js').SubscribePRTool : null

// Cron tool들 (AGENT_TRIGGERS, 독립 배포 가능)
const cronTools = feature('AGENT_TRIGGERS')
  ? [ CronCreateTool, CronDeleteTool, CronListTool ] : []

BriefTool 깊이 보기, Entitlement와 Activation

BriefTool은 코드베이스에서 가장 복잡한 enable 로직을 갖고 있습니다. 의도적으로 두 질문을 분리해서 다룹니다.

이렇게 나눈 이유는 분명합니다. 그렇지 않으면 사용자를 tengu_kairos_brief에 등록하는 순간 그 사람의 모든 session에서 Brief가 조용히 켜져 버리기 때문입니다. opt-in인 userMsgOptIn은 --brief, defaultView: 'chat', /brief slash command, 또는 CLAUDE_CODE_BRIEF env var처럼 사용자의 명시적 행동으로만 설정되어야 합니다.

// tools/BriefTool/BriefTool.ts (단순화 버전)
export function isBriefEnabled(): boolean {
  // 최상위 feature() guard는 dead-code elimination에 실제로 필요하다.
  // Bun은 외부 빌드에서 이를 `false`로 constant-fold한다.
  return feature('KAIROS') || feature('KAIROS_BRIEF')
    ? (getKairosActive() || getUserMsgOptIn()) && isBriefEntitled()
    : false
}

cron system은 Claude가 자기 미래 작업을 예약하는 메커니즘입니다. 구현은 전부 utils/cronTasks.ts, utils/cronScheduler.ts, 그리고 세 개의 Cron tool 안에 있습니다.

CronTask 형태

// utils/cronTasks.ts
type CronTask = {
  id:          string
  cron:        string       // local timezone 기준 5필드 cron
  prompt:      string       // task가 실행될 때 enqueue할 prompt
  createdAt:   number       // epoch ms, 놓친 task를 감지하는 기준점
  lastFiredAt?: number      // recurring 실행이 끝날 때마다 설정
  recurring?:  boolean      // true면 실행 후 다시 예약
  permanent?:  boolean      // recurringMaxAgeMs 만료 대상에서 제외
  durable?:    boolean      // 런타임 전용, false는 session 전용, undefined는 디스크 저장
  agentId?:    string       // main REPL 대신 teammate queue로 보냄
}

두 가지 지속성 계층

Jitter 시스템

CronCreate prompt에는 fleet 규모의 부하 분산에 대한 엔지니어링 감각이 담겨 있습니다.

// CronCreateTool prompt에서 발췌 (ScheduleCronTool/prompt.ts)
"'9am'을 요청한 모든 사용자는 `0 9`를 받고, 'hourly'를 요청한 모든 사용자는
`0 *`를 받습니다. 즉 지구 곳곳의 요청이 같은 순간 API에 몰리게 됩니다.

사용자 요청이 대략적이라면 0이나 30이 아닌 minute를 고르세요.
  'every morning around 9' → '57 8 * * *' or '3 9 * * *' (not '0 9 * * *')
  'hourly' → '7 * * * *' (not '0 * * * *')"

모델이 minute offset을 고르는 것에 더해, scheduler 자체도 deterministic jitter를 추가합니다. recurring task는 주기의 최대 10%까지 늦게 실행되고, 최대 15분 한도가 있습니다. :00 또는 :30에 걸린 one-shot task는 최대 90초 일찍 실행될 수 있습니다.

Permanent Task, assistant mode 내장 작업

permanent: true 필드는 assistant mode의 내장 task인 daily catch-up, morning check-in, dream consolidation을 위해 존재합니다. 이 task들은 설치 시점에 src/assistant/install.ts가 scheduled_tasks.json에 기록하며, 나이 기반 만료 대상에서 제외됩니다. writeIfMissing() 패턴 덕분에 다시 설치해도 사용자 커스터마이징을 덮어쓰지 않습니다.

AutoDream은 KAIROS의 백그라운드 maintenance worker입니다. 시간과 session이 충분히 쌓이면 자동으로 실행되어, main session을 방해하지 않고 fork된 sub-agent를 띄워 memory를 통합합니다.

Gate 체인, 가장 싼 검사부터

GrowthBook flag tengu_onyx_plover의 기본 임계값은 마지막 통합 이후 24시간, 최소 5개 session입니다. 둘 다 deploy 없이 실시간으로 조정할 수 있습니다.

통합 prompt, 4단계

dream agent는 services/autoDream/consolidationPrompt.ts에서 구조화된 prompt를 받습니다.

Dream 실행 시 tool 제약

auto-dream sub-agent는 prompt 끝에 더해진 강화된 tool 제약 메모를 받습니다.

"Bash is restricted to read-only commands (ls, find, grep, cat, stat, wc, head, tail).
Anything that writes, redirects to a file, or modifies state will be denied.
Plan your exploration with this in mind, no need to probe."

이 문구는 auto-dream 실행에서만 extra parameter를 통해 덧붙습니다. 수동 /dream skill은 main loop 안에서 일반 권한으로 실행됩니다.

DreamTask, UI에서 보이게 하기

fork된 dream agent는 tasks/DreamTask/DreamTask.ts를 통해 footer pill과 Shift+Down background tasks dialog에 드러납니다. 여기서는 다음을 추적합니다.

• phase: 'starting' | 'updating', 첫 Edit/Write tool call이 들어오면 'updating'으로 바뀝니다.
• filesTouched, 부분 목록입니다. Bash를 통해 쓴 내용은 놓치고 pattern-matched tool call만 잡습니다.
• turns, 최근 30개 assistant turn이며 tool_use block은 개수로 접어 둡니다.

표준 Claude Code memory는 모델이 직접 읽고 쓰는 단일 MEMORY.md index file을 사용합니다. 반면 KAIROS assistant mode는 근본적으로 다른 모델을 씁니다. append-only daily log입니다.

daily log path는 memdir/paths.ts의 getAutoMemDailyLogPath()가 계산합니다.

// memdir/paths.ts
export function getAutoMemDailyLogPath(date: Date = new Date()): string {
  const yyyy = date.getFullYear().toString()
  const mm   = (date.getMonth() + 1).toString().padStart(2, '0')
  const dd   = date.getDate().toString().padStart(2, '0')
  return join(getAutoMemPath(), 'logs', yyyy, mm, `${yyyy}-${mm}-${dd}.md`)
  // → ~/.claude/memory/logs/2026/03/2026-03-31.md
}

KAIROS를 정의하는 대표 기능 중 하나는 persistent session identity입니다. KAIROS session은 다음과 같이 재시작을 넘어 다시 이어갈 수 있습니다.

# 재시작한 뒤에도 같은 대화를 이어감
claude remote-control --session-id=<id>
claude remote-control --continue   # alias: -c

이 flag들은 bridge/bridgeMain.ts에서 파싱되며, 명시적으로 feature('KAIROS') guard 뒤에 놓여 있습니다. 주석에는 이렇게 적혀 있습니다.

// bridge/bridgeMain.ts
// feature('KAIROS') gate: --session-id는 내부 전용이다.
// 이 gate가 없으면 외부 빌드에 아무 일도 하지 않는 인자가 노출된다.
if (feature('KAIROS') && arg === '--session-id' && ...) { ... }
if (feature('KAIROS') && arg.startsWith('--session-id=')) { ... }
if (feature('KAIROS') && (arg === '--continue' || arg === '-c')) { ... }

session은 bridge configuration 안의 perpetual flag로 식별됩니다. session이 perpetual이면, 평소 더 빠른 성능을 주는 env-less bridge path는 재시작을 넘는 연속성을 지키기 위해 env-based path로 되돌아갑니다.

// initReplBridge.ts
// perpetual (bridge-pointer.json을 통한 assistant-mode session continuity)은
// env에 결합되어 있고 아직 env-less에 구현되지 않았다.
// 그래서 이 값이 켜져 있으면 env-based 경로로 되돌아가, KAIROS 사용자가
// 재시작 사이의 연속성을 조용히 잃지 않게 한다.
if (isEnvLessBridgeEnabled() && !perpetual) { ... }

KAIROS는 Claude Code 설정 스키마인 utils/settings/types.ts에 여러 설정 키를 추가합니다.

proactive가 활성화되면 getSystemPrompt()는 평소의 structured section 방식과 완전히 다른 경로를 탑니다.

// constants/prompts.ts, proactive 경로
if ((feature('PROACTIVE') || feature('KAIROS')) && proactiveModule?.isProactiveActive()) {
  logForDebugging('[SystemPrompt] path=simple-proactive')
  return [
    `\n당신은 자율 agent입니다. 사용 가능한 tool을 써서 유용한 작업을 하세요.\n\n${CYBER_RISK_INSTRUCTION}`,
    getSystemRemindersSection(),
    await loadMemoryPrompt(),
    envInfo,
    getLanguageSection(settings.language),
    isMcpInstructionsDeltaEnabled() ? null : getMcpInstructionsSection(mcpClients),
    getScratchpadInstructions(),
    getFunctionResultClearingSection(model),
    SUMMARIZE_TOOL_RESULTS_SECTION,
    getProactiveSection(),   // ← tick loop + Sleep + focus 지침
  ].filter(s => s !== null)
}

표준 경로는 caching과 section identifier를 갖춘 동적 section registry를 사용합니다. 반면 proactive 경로는 평평한 array를 반환합니다. 더 단순하고 더 빠르며, 계속 실행되는 agent의 cache miss 성향에 맞춰 최적화되어 있습니다.

KAIROS의 런타임 동작은 GrowthBook feature flag로 촘촘하게 감싸져 있습니다. 덕분에 Anthropic은 deploy 없이도 세부 시스템을 조정하거나 끌 수 있습니다. 이 패턴은 코드베이스 전반에 걸쳐 일관되게 나타납니다.

// 패턴: 명시적인 주기를 둔 cached refresh
const KAIROS_BRIEF_REFRESH_MS = 5 * 60 * 1000  // 5분
const KAIROS_CRON_REFRESH_MS  = 5 * 60 * 1000  // 5분

// Brief entitlement, GB flag를 확인하고 5분마다 갱신
getFeatureValue_CACHED_WITH_REFRESH('tengu_kairos_brief', false, KAIROS_BRIEF_REFRESH_MS)

// Cron kill switch, 전 구간 비활성화
getFeatureValue_CACHED_WITH_REFRESH('tengu_kairos_cron', true, KAIROS_CRON_REFRESH_MS)

// Durable cron kill switch, 더 좁은 범위, session 전용 cron은 그대로 둠
getFeatureValue_CACHED_WITH_REFRESH('tengu_kairos_cron_durable', true, KAIROS_CRON_REFRESH_MS)

// AutoDream 임계값과 활성화 gate
getFeatureValue_CACHED_MAY_BE_STALE('tengu_onyx_plover', null)

// Cron jitter 설정, 사고 상황에서 ops가 부하를 줄이기 위해 바꿀 수 있음
getFeatureValue_CACHED_WITH_REFRESH('tengu_kairos_cron_config', null, ...)

cronJitterConfig.ts의 주석은 사건 대응 맥락을 직접 설명합니다. "사고가 나면 ops는 tengu_kairos_cron_config를 밀어 넣어, 예를 들어 jitter multiplier를 크게 해서 전체 fleet 부하를 분산시킬 수 있다." 5분 refresh 주기는 GB 변경이 한 cache window 안에서 반영되도록 맞춰져 있습니다. 사고 대응에는 충분히 빠르면서도, 네트워크 압박을 계속 만들 정도로 빠르지는 않습니다.

KAIROS 소스를 따라가 보면 Anthropic이 일관되게 적용한 몇 가지 아키텍처 원칙이 드러납니다.

원칙 1, DCE를 위한 Positive Ternary

모든 feature-gated block은 negative early return이 아니라 positive ternary를 사용합니다.

// CORRECT, DCE가 동작함
return feature('KAIROS') ? doKairosThings() : false

// WRONG, DCE가 실패함 (negative guard가 constant-folding을 깨뜨림)
if (!feature('KAIROS')) return false
return doKairosThings()

원칙 2, 독립 배포 가능성

각 하위 기능은 따로 출시하고 따로 kill switch할 수 있게 설계되어 있습니다. cron 모듈 그래프는 src/assistant/를 import하지 않습니다. BriefTool은 자기 전용 KAIROS_BRIEF flag를 가집니다. 덕분에 전체 assistant mode에 버그가 있어도 cron scheduler 출시는 막히지 않습니다.

원칙 3, 가장 싼 gate부터

모든 KAIROS 하위 시스템은 평가 비용이 가장 싼 gate부터 검사합니다. AutoDream은 session 수를 보려고 filesystem을 읽기 전에, lock을 잡기 전에, 시간 검사를 하기 전에 먼저 kairosActive를 봅니다. 이런 검사는 agent의 모든 turn에서 실행되기 때문에 순서가 중요합니다.

원칙 4, 운영자용 Kill Switch

GrowthBook으로 감싼 모든 하위 시스템에는 이를 이기는 로컬 env var override가 있습니다. CLAUDE_CODE_DISABLE_CRON은 cron scheduler를 끄고, CLAUDE_CODE_BRIEF는 개발과 테스트용으로 Brief를 켭니다. 덕분에 개별 엔지니어는 GrowthBook을 건드리지 않고도 fleet gate를 우회할 수 있습니다.

원칙 5, System Prompt 안의 비용 예산

모델은 API call 비용과 prompt cache 메커니즘을 system prompt에서 직접 전달받습니다. "Each wake-up costs an API call, but the prompt cache expires after 5 minutes of inactivity, balance accordingly." 이런 방식은 꽤 이례적으로 투명한 system-prompt engineering입니다. 모델을 인프라 세부사항에서 격리하는 대신, 비용을 의식하는 참여자로 다룹니다.