8 분 소요

0. Introduction

Paper link

OpenRath는 agent framework 논문이라기보다 agent runtime state 논문이다. 이 차이가 중요하다. 논문이 겨냥하는 문제는 agent가 tool을 더 잘 부르느냐가 아니라, multi-agent와 multi-session system에서 runtime state가 fragmented되어 fork, merge, replay, audit가 어려워지는 문제다.

현대 agent system은 많은 state를 만든다. Conversation transcript, tool call, sandbox file placement, memory event, pending work, branch provenance, token usage, replay evidence, workflow decision이 모두 서로 다른 곳에 남는다. 이 상태가 framework log, vector DB, workspace file, tool result, orchestration metadata로 흩어지면 나중에 어떤 agent가 어떤 evidence를 보고 어떤 branch에서 어떤 tool output을 만든 것인지 재구성하기 어렵다.

OpenRath의 핵심 abstraction은 Session이다. 논문은 PyTorch analogy를 쓰지만, tensor computation을 닮았다는 뜻은 아니다. PyTorch에서 Tensor가 computation graph를 따라가는 first-class runtime value라면, OpenRath에서는 Session이 agent workflows를 통과하는 first-class runtime value다. Session은 branchable, inspectable, replayable, backend-aware, composable한 runtime value이며, conversation chunks, sandbox placement, lineage metadata, token usage, pending work, tool evidence, memory interaction boundary를 함께 들고 다닌다.

한 줄 요약: OpenRath는 agent system의 transcript, tool effects, memory events, sandbox placement, lineage, replay evidence가 흩어지는 문제를 Session이라는 first-class runtime value로 묶고, fork, merge, replay, backend-aware composition을 명시적 runtime operation으로 만드는 programming model과 architecture report다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

  • Agent memory나 tool use보다 아래 layer인 runtime state abstraction을 다룬다.
  • Multi-agent, multi-session workflow에서 auditability와 replayability를 first-class requirement로 둔다.
  • Session, Sandbox, Tool, Agent, Memory, Workflow, Selector를 runtime model 안에서 정리한다.
  • Branch provenance와 replay evidence를 external trace reconstruction이 아니라 execution value 자체에 넣는다.
  • Selector를 통해 control flow 자체를 runtime-routed decision으로 다룬다.
  • Broad benchmark score보다 controlled runtime properties를 claim scope로 제한하는 점이 systems paper답다.

이 글에서는 OpenRath를 “새 agent framework”보다, agent system의 mutable runtime state를 Session object 중심으로 재구성하는 programming model paper로 읽는다.

1. Problem Setting

1-1. Problem definition

Agent workflow는 여러 stateful component를 통과한다.

\[\mathrm{Agent} \rightarrow \mathrm{Tool} \rightarrow \mathrm{Sandbox} \rightarrow \mathrm{Memory} \rightarrow \mathrm{Workflow}\]

각 component는 state를 남긴다.

  • transcript
  • tool argument와 result
  • workspace files
  • sandbox placement
  • memory read/write event
  • branch와 lineage metadata
  • token usage
  • pending tasks
  • replay evidence

문제는 이 state가 서로 다른 backend나 log에 흩어지면 runtime value가 사라진다는 점이다. 나중에 audit하려면 다음을 물을 수 있어야 한다.

  • 이 answer는 어느 branch에서 생성되었는가?
  • 어떤 tool result가 근거였는가?
  • Memory read/write는 어느 시점에 들어왔는가?
  • Sandbox에는 어떤 file이 있었는가?
  • Forked branch가 merge될 때 무엇이 보존되었는가?
  • Replay를 하려면 어떤 evidence가 필요한가?

OpenRath는 이 state를 Session이라는 runtime value로 통합한다.

\[S = (\mathrm{chunks},\mathrm{sandbox},\mathrm{lineage},\mathrm{tokens},\mathrm{pending},\mathrm{tool\ evidence},\mathrm{memory\ events})\]

1-2. Why previous approaches are insufficient

1) Transcript-only logging

Transcript만 남기면 tool side effect, sandbox placement, memory event, branch lineage가 빠진다. Agent answer를 재현하려면 transcript만으로는 부족하다.

2) External observability only

Observability platform은 log와 trace를 수집한다. 하지만 runtime execution value와 분리되어 있으면 fork, merge, replay를 program operation으로 만들기 어렵다. OpenRath는 trace를 나중에 재구성하는 것이 아니라 Session이 실행 중 state를 들고 가게 만든다.

3) Memory system without runtime boundary

Memory read/write가 runtime record 밖에 있으면, answer가 어떤 memory state를 사용했는지 audit하기 어렵다. OpenRath는 memory interaction boundary를 Session 안에 정의한다.

4) Workflow orchestration without provenance

Workflow engine이 branch, retry, selector, merge를 처리해도 lineage metadata가 first-class가 아니면 debugging과 reproducibility가 약하다.

2. Core Idea

2-1. Main contribution

OpenRath의 기여는 다음 네 가지다.

  1. Session-centered programming model
    • Session은 agent와 workflow 사이를 오가는 runtime value다.
    • Branchable, inspectable, replayable, backend-aware, composable한 value로 설계된다.
  2. Runtime object model
    • Session, Sandbox, Tool, Agent, Memory, Workflow, Selector를 정의한다.
    • 각 component는 loose external trace가 아니라 Session을 통해 상호작용한다.
  3. Explicit fork, merge, replay
    • Branching과 replay가 runtime operation이 된다.
    • State provenance는 Session이 들고 간다.
  4. Evidence protocol
    • Tool evidence, sandbox placement, memory interaction boundary, lineage를 audit 가능하게 기록한다.

2-2. Design intuition

OpenRath의 design intuition은 PyTorch analogy에서 온다. PyTorch Tensor는 단순한 array가 아니라 device, dtype, gradient relation, computation context를 함께 들고 다닌다. 마찬가지로 OpenRath Session도 단순 transcript가 아니라 runtime evidence와 execution state를 함께 들고 다닌다.

Tensor : differentiable computation
Session : auditable agent workflow

이 analogy는 tensor math가 아니라 central runtime abstraction에 관한 것이다.

논문이 던지는 질문은 단순하다. 모든 agent operation이 Session을 입력으로 받고 Session을 반환한다면 어떻게 되는가?

\[S_{t+1} = f(S_t)\]

그러면 fork, merge, replay, audit는 더 이상 외부에서 trace를 다시 맞추는 작업이 아니다. Session value 위에서 수행되는 operation이 된다.

3. Architecture / Method

3-1. Overview

Item Description
Goal Agent runtime state를 first-class이고 auditable하게 만들기
Core abstraction Session
Programming model PyTorch-like central runtime value analogy
Components Session, Sandbox, Tool, Agent, Memory, Workflow, Selector
Key operations Fork, merge, replay, inspect
Runtime records Conversation chunks, sandbox placement, lineage, token usage, pending work, tool evidence
Scope Controlled runtime properties, not broad quality benchmark
Main claim Session이 agent system에 auditable composition을 제공함

3-2. Module breakdown

1) Session

Session은 central runtime value다.

Session은 다음을 포함한다.

Field type Example
Conversation chunks user, assistant, tool messages
Sandbox placement files, paths, runtime placement
Lineage metadata parent branch, fork point, merge relation
Token usage model call accounting
Pending work unfinished task와 work item
Tool evidence arguments, outputs, receipts
Memory boundary read/write event와 memory context

정확한 implementation detail은 paper/code에서 확인해야 한다. Conceptual point는 Session이 실행 이후에 재구성되는 것이 아니라, execution을 통과하면서 전달된다는 점이다.

2) Sandbox

Sandbox는 tool effect가 어디에 남는지를 포착한다. Coding agent나 data agent는 file을 만들고, script를 실행하고, workspace state를 바꾼다. Sandbox state가 Session과 연결되어 있지 않으면 replay가 모호해진다.

3) Tool

Tool record는 textual output만 담으면 부족하다. Argument, result, side effect, error, evidence receipt가 모두 중요하다. Tool call result는 Session evidence의 일부가 된다.

4) Agent

Agent는 Session을 소비하고 updated Session을 만든다. Text만 만드는 것이 아니다.

\[S' = \mathrm{Agent}(S)\]

이것이 programming model의 차이다. Agent execution은 Session 위의 state transformation이다.

5) Memory

Memory interaction은 정의된 boundary를 통해 runtime record에 들어간다. 이렇게 해야 memory가 보이지 않는 external state가 되는 것을 막을 수 있다.

Memory event는 다음을 포함할 수 있다.

  • memory query
  • retrieved item
  • write candidate
  • accepted write
  • memory backend ID
  • timestamp 또는 branch metadata

6) Workflow

Workflow는 agent와 tool을 Session transformation으로 compose한다. 이 구조는 multi-agent, multi-step pipeline을 inspect하기 쉽게 만든다.

7) Selector

Selector는 control flow를 runtime-routed decision으로 바꾼다. State record 밖의 opaque if/else logic 대신, Selector decision을 runtime lineage의 일부로 기록할 수 있다.

4. Training / Data / Recipe

4-1. No model training

OpenRath는 model training paper가 아니다. Programming model과 runtime architecture report에 가깝다.

논문은 다음을 제시한다.

  • programming model
  • component architecture
  • audited milestones
  • evidence protocol
  • controlled runtime property claims

논문은 claim scope를 명확히 제한한다. Broad quantitative comparison, live-provider quality, optional-backend availability, memory quality는 follow-on evaluation으로 남겨 둔다.

4-2. Runtime recipe

Typical OpenRath-style workflow는 다음처럼 요약할 수 있다.

  1. Session을 만든다.
  2. Session을 Agent 또는 Workflow에 전달한다.
  3. Tool call이 evidence와 함께 Session을 update한다.
  4. Sandbox change를 Session에 연결한다.
  5. Memory interaction을 Session boundary를 통해 기록한다.
  6. Session fork로 branch를 만든다.
  7. Alternative branch를 inspect하거나 merge한다.
  8. Replay는 Session evidence와 lineage를 사용한다.

4-3. Engineering notes

  1. Runtime state를 explicit하게 만든다
    • Post-hoc trace reconstruction에 의존하지 않는다.
  2. State를 execution value를 통해 전달한다
    • 모든 agent, tool, workflow step은 Session을 입력으로 받고 Session을 반환해야 한다.
  3. Memory event를 runtime event로 취급한다
    • 그렇지 않으면 memory가 보이지 않는 side channel이 된다.
  4. Branch lineage를 versioning한다
    • Fork와 merge는 state model 안에서 보여야 한다.
  5. Sandbox evidence를 Session에 묶는다
    • File placement와 tool side effect는 replay 가능해야 한다.
  6. Runtime auditability와 model quality를 구분한다
    • 더 나은 Session abstraction이 model answer를 자동으로 개선하지는 않는다.

5. Evaluation

5-1. Reported scope

ArXiv abstract는 이 report가 programming model, architecture, audited milestone, evidence protocol을 제시한다고 설명한다. 또한 claim이 controlled runtime property로 제한된다고 명시한다.

이 점이 중요하다. OpenRath를 benchmark accuracy 개선 논문처럼 평가하면 안 된다. OpenRath의 claim은 auditable composition에 관한 것이다.

5-2. What should be evaluated next

논문이 broad quantitative comparison을 follow-on evaluation으로 남겨 두었기 때문에, 실제 adoption에서는 다음을 확인해야 한다.

Axis Question
Replay fidelity Session이 관련 workflow evidence를 재현할 수 있는가
Branch correctness Fork와 merge semantics가 잘 정의되어 있는가
Memory auditability 어떤 memory가 read/write되었는지 trace할 수 있는가
Sandbox reproducibility Workspace state를 restore하거나 inspect할 수 있는가
Backend portability Backend가 바뀌어도 Session이 유지되는가
Developer ergonomics Session abstraction을 쉽게 사용할 수 있는가
Overhead Latency, storage, token logging overhead가 어느 정도인가

5-3. Why runtime property matters

Agent system은 점점 더 audit trail을 요구한다.

  • Enterprise workflow에는 accountability가 필요하다.
  • Coding agent에는 patch provenance가 필요하다.
  • Research agent에는 reproducibility가 필요하다.
  • Safety system에는 tool evidence가 필요하다.
  • Long-running agent에는 branch와 memory lineage가 필요하다.

Session-centered runtime state는 이런 requirement의 전제 조건이다.

5-4. What really matters in the experiments

1) Runtime abstraction 자체가 product다

핵심은 model quality가 아니다. 가치는 explicit state composition에 있다.

2) Replay는 first-class requirement다

Workflow를 replay하거나 inspect할 수 없다면 agent behavior를 신뢰하기 어렵다.

3) Memory는 runtime boundary 안에 있어야 한다

Memory system은 강력하지만 read/write가 execution state로 기록되지 않으면 위험하다.

4) Controlled claim이 적절하다

논문은 broad benchmark superiority를 과장하지 않고 controlled runtime property로 claim을 제한한다.

6. Limitations

  1. Broad quantitative benchmark가 없다
    • 논문은 quality comparison을 future work로 남긴다.
  2. Memory quality는 평가하지 않는다
    • OpenRath는 memory가 runtime에 들어오는 위치를 정의하지만, memory retrieval이 좋은지는 평가하지 않는다.
  3. Backend availability 검증이 필요하다
    • Optional backend support와 portability는 follow-on validation이 필요하다.
  4. Live-provider variability가 있다
    • Agent model과 tool provider behavior는 바뀔 수 있다.
  5. Runtime overhead가 생긴다
    • Session recording은 storage와 latency cost를 추가할 수 있다.
  6. Security model이 중요하다
    • Session record는 sensitive transcript, tool output, sandbox path를 포함할 수 있다.
    • Access control과 redaction이 중요하다.
  7. Branch merge semantics가 필요하다
    • Agent workflow에서 fork와 merge는 복잡할 수 있다.
    • Conflict policy가 명시되어야 한다.
  8. Universal agent framework는 아니다
    • OpenRath가 다루는 것은 runtime state abstraction이지, 모든 agent orchestration 문제는 아니다.
  9. Replay는 determinism이 아니다
    • Model call과 external tool은 여전히 nondeterministic할 수 있다.
  10. Developer adoption이 필요하다
    • First-class Session abstraction은 ecosystem integration을 요구한다.

7. My Take

7-1. Why this matters for my work

OpenRath의 핵심은 “Session object를 만들자”보다, agent system에서 runtime state를 first-class programming value로 올려야 한다는 점이다.

많은 agent failure는 model failure가 아니라 state management failure다.

  • 이 answer는 어느 branch에서 나왔는가?
  • 어떤 tool result가 사용되었는가?
  • Agent가 stale memory를 읽었는가?
  • 이 file은 어디에서 왔는가?
  • Workflow를 replay할 수 있는가?

System이 이 질문에 답할 수 없다면 production agent deployment는 어려워진다.

7-2. Reuse potential

Coding agents

Session은 patch lineage, test output, file placement, branch provenance를 들고 갈 수 있다. 이는 generated code를 review할 때 중요하다.

Research agents

Paper review, experiment analysis, data science agent에는 replayable evidence가 필요하다. Session-centered state는 analysis provenance를 보존할 수 있다.

Enterprise agents

Enterprise workflow에는 audit trail, memory boundary, tool receipt, pending work tracking이 필요하다. Session은 자연스러운 accountability unit이 될 수 있다.

Multi-agent orchestration

Agent가 delegate, fork, retry, merge할 때 state graph는 visible해야 한다. Session은 그 shared substrate가 될 수 있다.

7-3. Production considerations

  • Session field를 encrypt하고 redact한다.
  • Retention policy를 정의한다.
  • User-visible transcript와 internal evidence를 분리한다.
  • Replay evidence는 portable하게 만들되 bounded하게 유지한다.
  • Memory read/write를 ID와 timestamp와 함께 기록한다.
  • Fork와 merge를 auditable event로 취급한다.
  • Tool evidence와 sandbox artifact에 governance를 추가한다.

7-4. Follow-up papers

  • MemGPT / Letta
  • OpenRath follow-on evaluation
  • Proof-Carrying Agent Actions
  • SafeAgent
  • Agent runtime governance papers
  • MCP and agent protocol papers
  • LangGraph and workflow state management
  • Zep and agent memory infrastructure

8. Summary

  • OpenRath는 Session을 agent system의 first-class runtime value로 다룬다.
  • Session은 transcript, sandbox placement, lineage, token usage, pending work, tool evidence, memory interaction boundary를 들고 간다.
  • Fork, merge, replay, inspect가 explicit runtime operation이 된다.
  • 논문의 claim은 model quality가 아니라 controlled runtime property에 관한 것이다.
  • 핵심 가치는 multi-agent, multi-session system을 auditable하게 compose하는 데 있다.

댓글남기기

참고