OpenRath: Session-Centered Runtime State for Agent Systems

Fukang Wen, Zhijie Wang, Ruilin Xu

OpenRath introduces Session as a first-class runtime value to unify fragmented agent state across branches, tools, and memory.

How can we unify fragmented agent runtime state (transcripts, tool effects, memory) into a single, inspectable, and branchable "Session" object?

Modern agent systems often fragment their runtime state across side channels like controller logs, tool traces, and memory stores, making it nearly impossible to audit how a final answer was produced. OpenRath treats the runtime state as a single, first-class object called a Session that flows through agents and workflows, carrying lineage, tool evidence, and sandbox placement with it. This approach allows developers to fork, merge, and replay agent work as explicit runtime operations rather than reconstructing state from disconnected logs.

Paper Primer

OpenRath adopts a PyTorch-inspired programming model where a central value—the Session—flows through reusable transformations. Instead of agents maintaining private transcripts, every component (Agent, Tool, Workflow) follows a uniform contract: it receives a Session, performs its task, and returns an updated Session containing all relevant evidence and metadata.

Session-centered state enables deterministic lineage export and auditability.

The system provides a JSONL-based lineage export that records parent-child relationships, tool usage, and branch provenance for every execution path. The implementation supports full replayability and inspection of complex multi-agent workflows without requiring external state reconstruction.

The system uses a Selector component to route control flow based on the current Session state. This makes branching and looping decisions explicit runtime events that are captured in the session record, rather than hidden logic inside the controller code.

Why is a "Session" object necessary if existing tracing systems already record agent activity?

Tracing systems are observer-facing and record what happened after the fact; a Session is a live program value that agents themselves fork, merge, and pass forward, ensuring that evidence is attached to the work as it happens.

Does OpenRath replace existing agent frameworks like LangGraph or AutoGen?

No, it is designed to be connective. It complements these systems by providing a standardized runtime value that can be scheduled, traced, and persisted across different agent infrastructures.

By moving agent state from side-channel logs into a first-class runtime value, OpenRath enables a new standard for auditable, branchable, and replayable agent systems.

The Problem of Fragmented State

Agent runtimes suffer from scattered state; OpenRath unifies it with a first‑class Session object.

Modern agent systems scatter their runtime state across logs, tool side‑effects, memory stores, and branch provenance, making inspection and reproducibility painful.

When an agent run writes its conversation, tool calls, sandbox edits, and memory updates to separate channels, no single object can answer “which branch produced this answer?” or “what tool changed which file?”

OpenRath introduces a single, branchable Session object that travels with the program, carrying conversation chunks, tool evidence, sandbox metadata, memory lineage, and token usage—all in one place.

**Figure 1.** OpenRath’s core boundary: side-channel state around an agent loop is promoted into a branchable Session value that can produce release evidence artifacts.

**Table 1.** Three runtime records, three readers. OpenRath's Session is the value written for the agent program itself, which is why fork, merge, and replay are first-class rather than reconstructed.

The shift from fragmented logs to a unified Session object turns runtime state into a first‑class, inspectable value that agents can branch, merge, and replay directly.

Ecosystem Positioning

Positions OpenRath within the agent ecosystem as a connective runtime state object.

Agent ecosystems are converging on durable execution, richer tracing, standardized tool/data protocols, and real‑environment evaluation, with systems such as AutoGen, LangGraph, the OpenAI Agents SDK, and MCP exemplifying these trends.

**Figure 2.** OpenRath’s ecosystem role is a crossing-object boundary. It can work with specialized agent APIs, graph runtimes, tracing SDKs, tool protocols, sandbox providers, and evaluation harnesses by making their effects visible in one Session.

Table 2 enumerates five emerging trends and the remaining object‑boundary questions each raises.

The central claim is simple: multi‑agent systems require a first‑class runtime state, and OpenRath’s Session is the proposed solution.

Related Work

Survey of prior work on tool‑using agents, multi‑agent frameworks, runtime state, memory, and benchmarks.

Tool‑Using and Acting Agents interleave reasoning with external actions; prior work such as ReAct, MRKL, and Toolformer explores this coupling at inference time.

Multi‑Agent Frameworks coordinate several agents, exemplified by AutoGen, CAMEL, MetaGPT, ChatDev, and AgentVerse, each defining distinct orchestration patterns.

Runtime State, Protocols, and Observability research provides checkpointed graph state (LangGraph) and tracing SDKs (OpenAI Agents SDK, OpenTelemetry), but these treat state as an after‑the‑fact observation.

Table 2 summarizes how recent systems elevate various artifacts to first‑class status while leaving the session‑level evidence question open.

Memory and Retrieval literature (Reflexion, Generative Agents, MemGPT, Voyager) focuses on what to remember and how to retrieve it; OpenRath simply records those memory operations on the Session.

Agent Benchmarks and Environments (AgentBench, $\tau$‑bench, SWE‑bench, Terminal‑Bench, WebArena family) evaluate outcomes in realistic settings, prompting OpenRath’s focus on making the production trajectory inspectable.

The Session Programming Model

OpenRath’s programming model defines a tiny object set that transforms a shared Session value.

The programming model is deliberately tiny: every runtime component either transforms or annotates a single Session, never invents its own transcript or log. This discipline lets the system stay inspectable even when branches multiply across agents, tools, and sandboxes.

A Session is the single mutable value that carries all runtime information—inputs, intermediate results, provenance, and pending work—through every component.

Fork: copy the parent Session and set

Tool call: the

Merge: after the tool returns, the child Session’s

Resulting parent Session now contains

The Session makes branching explicit; the audit trail is simply the sequence of copied and merged dicts, not hidden logs.

How is a Session different from a traditional conversation transcript?

A transcript is a linear list of messages; a Session is a structured object that can be forked, annotated, and merged, preserving both the data flow and the provenance of each modification.

Agents are pure Session→Session functions that may invoke providers, tools, or memory. Tools receive the active Session and validated arguments, execute inside a Sandbox, and return new evidence. Workflows compose these primitives, while Sandboxes isolate external execution and Memory offers a persistent, session‑visible store.

A Selector reads the current Session and chooses the next workflow to run, turning control flow into an explicit data‑driven decision.

Why not simply hard‑code the next agent instead of using a Selector?

Hard‑coding embeds the control decision in controller code, which disappears from the Session audit trail. A Selector keeps the decision inside the Session, making it observable, reproducible, and branchable at runtime.

**Table 3.** The compact OpenRath object vocabulary.

**Figure 3.** The PyTorch lens. Each agent-runtime concern maps onto one OpenRath object, with Session as the flowing value (the tensor of the runtime) and Selector routing control flow at run time. The mapping is a teaching device, not a claim that agent systems are neural networks.

Runtime Architecture

Runtime Architecture details how a Session persists, branches, merges, and replays across agents and tools.

Fragmented runtime state makes debugging and audit impossible; OpenRath solves this by keeping a single Session object alive through every agent, tool, sandbox, and storage step.

**Figure 4.** Session lifecycle as a single runtime value: the same object is placed, transformed, branched, merged, persisted, and replayed rather than replaced by a separate orchestration state.

Create a Session from user or agent context.

Place it on a backend via

Transform it through model calls, tool requests, and workflow steps.

Branch the Session for parallel work (fork or detach).

Merge branches back into a single lineage.

Persist the full transcript to a JSONL store.

Release sandbox resources when the Session is no longer needed.

Table 4 lists what becomes auditable at each phase—initial prompts at Create, backend intent at Place, model calls and tool results at Transform, parent links at Branch, provenance at Merge, JSONL rows at Persist, and sandbox ownership at Release.

Branching turns a linear transcript into a graph, letting parallel work diverge and later reconverge without losing provenance.

How does OpenRath’s merge differ from a typical Git merge?

Git merges source‑code trees; OpenRath merges live runtime Sessions. The merge succeeds only if both Sessions can share the same sandbox handle or target the same backend, otherwise the operation is rejected.

Fork:

Tool on

Merge:

Merge preserves both branches’ histories, so later replay can reconstruct exactly which tool produced C versus D.

Session loop handling tool calls

Table 5 enumerates backend boundaries—placement intent, resource lifetime, capability claim, concrete execution, and evidence return—each owned by the Session object.

Persistence appends JSONL rows to the Session store; lineage export flattens the graph into rows containing identifiers, parent IDs, operator type, chunk count, and cumulative usage, making replay trivial with standard CLI tools.

Multi-Agent Composition

Describes the session‑centered mechanism that lets multiple agents share a single runtime state.

Multi‑agent systems frequently break when a second runtime object, hidden message bus, or controller‑only trace is introduced. OpenRath avoids that pitfall by keeping the moving runtime value a single Session object.

Like a shared kitchen counter where multiple chefs place and retrieve ingredients, the Session object holds evidence, placement, lineage, usage, and replay for all agents.

How does this Session‑centered design differ from typical multi‑agent frameworks that rely on a shared mutable object or message bus?

Typical frameworks expose a global mutable store or an implicit bus, which agents can read or write at any time, leading to hidden coupling and nondeterministic traces. OpenRath instead gives every agent a single, explicit Session handle; all state changes go through the Session’s versioned API, so the flow is deterministic and fully observable.

Agent A calls

Agent A returns the updated Session S′ (E = {“fact‑1”}, L = {A:`add_evidence`}).

Agent B receives S′, calls

Agent B also increments a usage counter in S′, then returns Session S″ (E = {“fact‑1”, “search‑result”}, L = {A:`add_evidence`, B:`run_tool`}).

The same Session object flows through both agents, preserving a single, inspectable provenance chain without spawning extra runtime containers.

**Figure 5.** Tool execution boundary: schemas are visible to the model, side effects run through the session’s sandbox and backend, and results return as session evidence.

**Figure 6.** Multi-session runtime and multi-agent workflow share the same boundary: agents route, hand off, and compose work by reading and returning Session state rather than introducing a second runtime object.

Audit-First Evaluation Protocol

OpenRath’s audit‑first evaluation validates runtime claims via reproducible packets.

OpenRath consolidates fragmented runtime state into a single Session object that persists across the agent lifecycle.

OpenRath’s audit‑first evaluation validates ten runtime claims via compact evidence packets.

The claim ledger classifies ten claims: five fully supported, one partially, one prerequisite‑only, one bibliography‑backed, one layout‑smoke, and one evidence‑gated.

Before any leaderboard comparison, the system first checks that every runtime claim is paired with a minimal, reproducible evidence packet.

**Figure 7.** Claim-to-evidence protocol: report claims pass through a ledger, evidence packets, and a smoke suite before becoming supported text, scoped text, or explicit limitations.

Table 8 enumerates the eight runtime claim categories, their current evidence packets, and the explicit scope boundaries each packet proves or does not cover.

Limitations and Scope

Scope limits and final takeaways of OpenRath’s Session‑centered runtime.

The limitations are framed as explicit scope boundaries: the report provides deterministic evidence for a narrow set of runtime claims but does not assert broad benchmark superiority, a verified local‑memory implementation, OpenSandbox availability, fully reproducible live‑model outputs, or any safety property.

**Table 9.** Scoped limitations for the current technical report.

These boundaries separate implemented runtime semantics from optional integrations; a claim can leave the table only when a supporting evidence packet exists and the claim ledger links the text to that artifact.

OpenRath’s contribution is deliberately narrow: it makes the state that agents operate on explicit rather than leaving it scattered across logs and side‑channels.

Session is OpenRath’s proposed boundary for that runtime state, and the programming model stays compact because every major component either transforms a Session, annotates it, dispatches work through its placement, or emits inspectable evidence.

Because the evidence lives in the value the program already passes around instead of in a side channel reconstructed afterward, it is available exactly when a reviewer needs to audit the run.

The durable thesis is that reliable agent systems need a first‑class runtime value, and OpenRath supplies that value as the Session.

Future iterations should only add capabilities that preserve this boundary: they must transform a Session, attach evidence to a Session, or expose a backend effect through a Session, keeping the system honest and composable.

**Table 1.** Workload, Runtime point, and Current evidence status.

Case Studies

Ablation case studies map workloads to the Session runtime model’s expressive coverage.

The case studies connect the audited runtime claims to realistic workload patterns, showing where the Session‑centered model is intended to apply without presenting quantitative performance numbers.

Implementation Milestones

Implementation status of OpenRath’s runtime surfaces and their claim coverage.

OpenRath ships as a Python package that implements the runtime objects introduced earlier: a Session core, an execution‑backend layer, a flow layer of tools, agents, workflows, and compressors, an LLM‑provider layer, and persistence with lineage export.

Table 7 records which of these surfaces are substantiated in the current audited snapshot and where the implementation deliberately bounds its claims.

This table outlines the implementation status of various system surfaces, including Session core, Backend placement, Tool layer, Agent and workflow, Provider layer, Memory plane, and Examples.

The key takeaway is that all these surfaces converge on a single object model: the Session value flows through backends, tool calls become structured events, agents and workflows transform sessions without private transcripts, and persistence makes the resulting state inspectable outside the process.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers