OUROBOROS DEEPDIVE MCP MESH · DISPOSABLE MEMORY

CONTRACT-BASED AGENT OS

Ouroboros 딥다이브:
MCP Mesh와
Disposable Memory

긴 워크플로는 한 번의 대화에 다 담기지 않는다. 뒤로 갈수록 답이 흐려지는 건 모델 탓이 아니라, 기억할 자리가 사라지기 때문이다.

Q00 · 이재규 Context exhaustion · problem framing

20 min · 18 slides
context → contract.

OPENING PROBLEM01 / 16

OUROBOROS DEEPDIVE WHY HARNESS · BITTER LESSON

AI는 스케일로 이긴다. 그래도 ghost는 우리가 잡아야 한다.

SUTTON · BITTER LESSON

인간 지식 주입은 졌다

데이터·연산과 함께 커지는 방법이 이긴다. LLM은 그 승리.

KARPATHY · ANIMALS vs GHOSTS

LLM은 animal이 아니라 ghost다

인간 텍스트에서 소환된 압축물 — 강력하지만 인간 편향에 묶여 있다.

YES

스케일은 이긴다.

BUT

혼자 완결된 작업자는 아니다.

harness가 ghost를 잡는다.

SCALE WINS · BUT WE STILL CONTROL THE GHOST02 / 16

● SPEAKER NOTESSLIDE 02 / 16

Sutton의 Bitter Lesson은 사람이 직접 심은 지식보다 데이터·연산을 먹고 커지는 방법이 길게 이긴다는 관찰이다. LLM은 그 승리처럼 보인다 — pretraining에 쏟은 compute와 데이터가 지금 결과를 만들었으니까.

다만 Karpathy의 표현을 빌리면 LLM은 animal이 아니라 ghost다. 세계와 직접 상호작용하며 자란 생명체가 아니라, 인간 텍스트와 RLHF 피드백을 압축한 존재. Sutton의 Bitter Lesson을 완전히 만족시키지는 못한다.

발표의 첫 전제는 분명하다. LLM은 강력하지만 혼자 완결된 작업자가 아니다. 목표를 끝까지 보존하고, 실패를 감지하고, 스스로 복구하는 능력이 아직 불안정하다. 누군가 옆에서 ghost를 잡아줘야 한다 — 그게 harness다.

OUROBOROS DEEPDIVE WHY HARNESS · CONTEXT LIMITS

ghost를 잡는 첫 시도는 context engineering이다. 여기엔 네 가지 한계가 있다.

01 / ATTENTION

긴 문맥은 기억이 아니다

많이 넣어도 끝까지 따르진 않는다. 중간은 lost in the middle.

02 / REASONING

추론도 예산이다

토큰 예산은 한정된다. 복잡한 작업은 그럴듯한 경로로 수렴.

03 / FORGETTING

지시는 보존되지 않는다

초반 지시는 최근 노이즈에 밀린다. 긴 세션의 기본값.

04 / NEXT-TOKEN

빈칸은 그럴듯하게 채워진다

"물어보기"보다 "채우기"를 고른다 — 환각의 본질.

CONTEXT ENGINEERING IS NECESSARY · NOT SUFFICIENT03 / 16

● SPEAKER NOTESSLIDE 03 / 16

ghost를 통제하는 가장 자연스러운 첫 시도는 context를 잘 채우는 것이다. PRD, architecture doc, AC, 예시, 정책을 다 prompt에 넣는다. 이게 context engineering이고, BMAD나 사내 AI workflow가 가는 기본 방향이다.

그런데 LLM 자체에 네 가지 한계가 있다. 첫째 attention window — 길게 넣어도 중간이 흐려진다. 둘째 reasoning budget — 깊이 생각하려면 토큰을 쓰는데 한정돼 있다. 셋째 instruction forgetting — 긴 작업에서 초기 목표가 최근 노이즈에 밀린다. 넷째 next-token prediction — 빈칸은 "물어보기"보다 "그럴듯하게 채우기"로 메운다.

그래서 context engineering은 필요하지만 충분하지 않다. 더 많이 넣을수록 더 흐려지고, 더 길어질수록 더 잊는다. 이 한계가 가장 노골적으로 드러나는 게 다음 장의 trigger problem이다 — context가 바닥나는 순간.

OUROBOROS DEEPDIVE PART 01

TRIGGER PROBLEM

context가 바닥나면
현재 세션은 혼자 계속하면 안 된다.

답변 품질이 아니라 운영 안정성 문제다.

CURRENT SESSION · CONTEXT BUDGET

STOP. single-session continuation is unsafe.

토큰보다 위험한 건, 무엇을 잊었는지 세션이 모른다는 것.

Seed와 AC는 남아 있다

일은 안 끝났다. 의존성은 살아 있다.

하지만 현재 세션은 오염됐다

결정·실패·평가가 한 대화에 섞였다.

그래서 다음 행동은 분리다

독립 세션으로 책임을 넘긴다.

EXHAUSTION IS THE TRIGGER04 / 16

OUROBOROS DEEPDIVE OPERATIONAL RESPONSE

더 긴 prompt → 격리된 session으로 쪼개기

하나의 AC는 하나의 disposable context로 들어가고, 결과 이벤트만 돌려준다.

SPLIT WORK INTO DISPOSABLE MEMORY05 / 16

OUROBOROS DEEPDIVE CONTRACT CONTINUITY

세션은 갈라져도, contract는 갈라지지 않는다.

자식의 context는 사라지고, contract 이벤트만 ledger로 돌아온다.

RECOMBINE EVENTS, KEEP THE CONTRACT06 / 16

OUROBOROS DEEPDIVE PART 02

세션을 쪼갠 순간, 해법 하나가 의도치 않은 세 가지 결과를 만들었다.

What we intended

context를 아끼려고 세션을 분리했다

AC마다 격리된 자식 세션을 연다.
과정은 자식 context 안에서 소비한다.
메인은 contract 이벤트만 받고 깨끗하게 남는다.

What emerged

분리는 작은 구현이 아니라 구조 전환이었다

도구가 LLM을 쓴다. MCP 내부 코드가 세션을 spawn하고 스케줄한다.
메모리가 일회용이 된다. 자식 세션은 결과를 남기고 사라진다.
실행 구조가 고정된다. 호출 순서와 이벤트 경계는 코드가 강제한다.

SPLIT SESSIONS → UNEXPECTED OUTCOMES07 / 16

OUROBOROS DEEPDIVE UNINTENDED OUTCOME 1/3

#1: 도구가 LLM을 쓰기 시작했다.

CAUSE

세션 분리는 실행 코드를 요구했다

MCP 안에 Python과 Claude SDK가 들어갔다.

OUTSIDE

밖에서는 도구 호출 하나

런타임은 ooo run을 부르고 기다린다.

INSIDE

안에서는 agent가 돈다

AC 파싱 · 의존성 · spawn · 이벤트 수집 · 다음 레벨.

PUNCHLINE 01

도구가 LLM을 쓴다

Skill은 inject. MCP는 execute.

SPLIT SESSIONS → TOOL BECAME AGENT08 / 16

OUROBOROS DEEPDIVE UNINTENDED OUTCOME 2/3

#2: 세션 분리를 구현하자, MCP가 hook을 대체했다.

WITHOUT MCP

Rule과 Skill은 부탁에 가깝다

Codex에는 hook이 없다. Rule은 제약 문장이고 Skill은 프롬프트 텍스트라서 “인터뷰 → Seed → AC → 실행” 순서를 끝까지 잠그지 못한다.

LLM이 피곤하거나 길을 잃으면 그 순서는 플라톤의 이상처럼 보일 뿐, 실행의 운명이 되지는 않는다.

WITH MCP

Python 경계가 순서를 잠근다

독립 세션을 열고 다시 합치려면 spawn, schedule, collect가 필요했고, 그 오케스트레이션이 MCP handler 안으로 들어갔다.

도구 호출 순간부터 인터뷰가 끝나야 Seed가 생기고, Seed가 있어야 AC가 분해되고, AC가 있어야 실행된다. 우회가 아니라 코드 경로다.

SPLIT SESSIONS → HOOK REPLACEMENT09 / 16

OUROBOROS DEEPDIVE UNEXPECTED

#3: 세션을 쪼개자 call structure가 고정됐다.

LLM 답변은 매번 흔들린다. 그래도 contract graph와 dependency edge는 같은 execution coordinate를 남긴다.

Split-session contract input

ROOT · Build feature

AC-1
scaffold

AC-2
schema

AC-3
depends on AC-2

AC-4
frontend

AC-5
depends on AC-3 + AC-4

세션마다 답은 달라져도, contract graph와 dependency edge는 같은 execution coordinate를 남긴다.

→

level
grouping

Deterministic call structure

LEVEL 0

AC-1
session

AC-2
session

AC-4
session

parallel

LEVEL 1

AC-2 done

AC-3
spawn

LEVEL 2

AC-3 done

AC-4 done

AC-5
spawn

#1 tool uses LLM · #2 MCP enforces sequence · #3 calls become fixed → horizontal Contract-based Agent OS

SPLIT SESSIONS → DETERMINISTIC CALL STRUCTURE → AGENT OS10 / 16

OUROBOROS DEEPDIVE WHAT WAS MISSING

더 좋은 Skill → shared coordination layer

EVIDENCE 01

Runtime independence는 Skill 밖에서

Claude Code와 Codex가 같은 엔진을 호출. 차이는 prompt가 아니라 contract.

EVIDENCE 02

Hook replacement는 더 두꺼운 지시문이 아니었다

hook 없는 Codex도 순서를 얻는다. MCP handler가 잡았다.

EVIDENCE 03

Deterministic calls는 세션 사이에서 고정

답은 흔들려도 event boundary는 고정.

NOT

더 긴 vertical skill.

BUT

함께 따르는 shared coordination layer.

PROOF

4-매트릭스 E2E가 같은 contract 위에서 통과.

NOT BETTER SKILLS · SHARED COORDINATION LAYER11 / 16

OUROBOROS DEEPDIVE CONTRACT LAYER

Agent OS란 커널이 아니라, 런타임과 에이전트 사이의 Contract layer다.

Contract primitive	Ouroboros binding	실행 보장
Interfaces	MCP tool schema · SubagentPayload · ResultEvent	같은 entrypoint, 같은 result envelope.
State boundaries	contract_id · ac_id · artifact_ref · child scratchpad	자식 기억은 거기서 끝. ledger엔 contract 필드만.
Execution guarantees	Coordinator dependency graph · level scheduling · blocking/polling	LLM 해석이 아니라 코드가 순서를 잡는다.
Verification hooks	Acceptance criteria · evaluator · qa-judge · pass/fail events	verification event 통과해야 다음 궤도.

OS analogue: Coordinator=scheduler · AC session=process · event sourcing=message passing · MCP=IPC

INTERFACE · STATE BOUNDARY · EXECUTION GUARANTEE · VERIFICATION HOOK12 / 16

OUROBOROS DEEPDIVE MESH + DISPOSABLE MEMORY

MCP Mesh와 Disposable Memory가 horizontal Contract layer를 만든다.

runtime 내부의 프롬프트가 아니라, agent를 가로로 묶는 OS contract primitive다.

Claude Code

MCP client

Codex

hookless · same call

OpenCode

outside runtime prompt

Hermes

same entrypoint

MCP Mesh

tool schema · polling · ResultEvent가 IPC처럼 작동.

Disposable Memory

sub-agent를 process처럼 fork. ledger엔 contract_id · artifact_ref만.

qa-judge

AC verdict
pass/fail event

evaluator

semantic check
artifact scoring

contrarian

risk probe
alternate path

code-executor

bounded work
result envelope

CONTRACT LAYER = MESHED IPC + DISPOSABLE PROCESSES13 / 16

OUROBOROS DEEPDIVE AXIS · ORTHOGONAL

VERTICAL VS HORIZONTAL

vertical fat-skill
→
horizontal contract OS

opposite가 아니라 orthogonal이다. fat-skill의 깊이를 부정하지 않는다. 다만 여러 runtime, 여러 session, 여러 harness가 같은 contract 위에서 공존하는 문제는 다른 축이다.

FAT SKILL THIN HARNESS = VERTICAL / CONTRACT OS = HORIZONTAL14 / 16

OUROBOROS DEEPDIVE TWO AXES

Ouroboros의 두 축: philosophy loop와 OS layer.

위는 일을 굳히는 흐름. 아래는 그걸 누가 어떻게 실행하는가.

Interview

모호함 낮추기

Seed

목표 고정

AC Tree

일 쪼개기

Execute

작게 실행

Evaluate

통과/실패

Wonder · Reflect

기록, 되감기

Philosophy axis

clarify → crystallize → decompose → execute → judge → reflect

Codex

Interview · Seed · Execute

Claude Code

Evaluate · Review · Delegate

Hermes

Super Memory

Agents / Harnesses

Any contract action

User level → MCP

program calls action

MCP → MCP again

action calls another MCP

Contract Kernel

Seed · AC · envelope · audit

Memory Kernel

dispose context · keep events

Scheduler Kernel

levels · polling · retry

Execute → GitHub MCP

repo tools

Evaluate → Browser MCP

render check

Reflect → Agent MCP

new loop

Event Store

contract record

PHILOSOPHY LOOP ABOVE · CONTRACT AND MEMORY KERNEL BELOW15 / 16

OUROBOROS DEEPDIVE END

FINAL · 다음 층

노트북을 닫고 자도 되는가?
그 질문의 다음 층은
contract가 OS가 되는 순간이다.

Q00 · jqyu.lee@gmail.com Ouroboros · repository Q00/ouroboros

Skill은 context를 부르고, harness는 contract를 지킨다.
도구가 LLM을 쓴다 (The tool is using the LLM). Mesh가 호출을 묶고 Memory가 소멸한다.
Ouroboros = Contract-based Agent OS.

FINAL POSITIONING · CONTRACT-BASED AGENT OS16 / 16

Ouroboros 딥다이브:MCP Mesh와Disposable Memory

AI는 스케일로 이긴다. 그래도 ghost는 우리가 잡아야 한다.

인간 지식 주입은 졌다

LLM은 animal이 아니라 ghost다

ghost를 잡는 첫 시도는 context engineering이다. 여기엔 네 가지 한계가 있다.

긴 문맥은 기억이 아니다

추론도 예산이다

지시는 보존되지 않는다

빈칸은 그럴듯하게 채워진다

context가 바닥나면현재 세션은 혼자 계속하면 안 된다.

Seed와 AC는 남아 있다

하지만 현재 세션은 오염됐다

그래서 다음 행동은 분리다

더 긴 prompt → 격리된 session으로 쪼개기

세션은 갈라져도, contract는 갈라지지 않는다.

세션을 쪼갠 순간, 해법 하나가 의도치 않은 세 가지 결과를 만들었다.

context를 아끼려고 세션을 분리했다

분리는 작은 구현이 아니라 구조 전환이었다

#1: 도구가 LLM을 쓰기 시작했다.

세션 분리는 실행 코드를 요구했다

밖에서는 도구 호출 하나

안에서는 agent가 돈다

도구가 LLM을 쓴다

#2: 세션 분리를 구현하자, MCP가 hook을 대체했다.

Rule과 Skill은 부탁에 가깝다

Python 경계가 순서를 잠근다

#3: 세션을 쪼개자 call structure가 고정됐다.

더 좋은 Skill → shared coordination layer

Runtime independence는 Skill 밖에서

Hook replacement는 더 두꺼운 지시문이 아니었다

Deterministic calls는 세션 사이에서 고정

Agent OS란 커널이 아니라, 런타임과 에이전트 사이의 Contract layer다.

MCP Mesh와 Disposable Memory가 horizontal Contract layer를 만든다.

Claude Code

Codex

OpenCode

Hermes

MCP Mesh

Disposable Memory

qa-judge

evaluator

contrarian

code-executor

vertical fat-skill→horizontal contract OS

Ouroboros의 두 축: philosophy loop와 OS layer.

Interview

Seed

AC Tree

Execute

Evaluate

Wonder · Reflect

Codex

Claude Code

Hermes

Agents / Harnesses

User level → MCP

MCP → MCP again

Contract Kernel

Memory Kernel

Scheduler Kernel

Execute → GitHub MCP

Evaluate → Browser MCP

Reflect → Agent MCP

Event Store

노트북을 닫고 자도 되는가?그 질문의 다음 층은contract가 OS가 되는 순간이다.

Ouroboros 딥다이브:
MCP Mesh와
Disposable Memory

context가 바닥나면
현재 세션은 혼자 계속하면 안 된다.

vertical fat-skill
→
horizontal contract OS

노트북을 닫고 자도 되는가?
그 질문의 다음 층은
contract가 OS가 되는 순간이다.