PaperlayerView exact revision on arXiv

Source-linked AI summary

OpenRath: Session-Centered Runtime State for Agent Systems

Fukang Wen, Zhijie Wang, Ruilin Xu

arXiv:2606.19409v1cs.SEcs.PL

TL;DR

Agent systems often fragment runtime state across side channels, making branch, tool, memory, sandbox, and replay provenance difficult to inspect. OpenRath instead makes Session the first-class value passed through agents and workflows, with deterministic evidence supporting a narrow set of runtime claims.

  • Problem

    Agent runs often fragment transcripts, tool effects, memory events, sandbox placement, branch provenance, and replay evidence across side channels, hindering reconstruction of runtime state.

  • Method

    OpenRath uses Session as a branchable, inspectable, replayable runtime value that carries agent state, placement, lineage, memory events, and tool evidence through workflows.

  • Results

    Focused tests and examples substantiate deterministic session, sandbox, tool-dispatch, and workflow behavior, while optional backends and live-provider quality remain environment-dependent or out of scope.

  • Takeaways & Limitations

    Session provides OpenRath’s proposed boundary for runtime state, keeping evidence available within the value passed through agent-system components for post-run inspection.

  • Takeaways & Limitations

    The report supports only narrow deterministic runtime claims and does not establish broad benchmark superiority, verified local-memory quality, backend availability, reproducible live-model outputs, or safety properties.

Abstract

from arXiv · show

Modern agent systems often suffer from fragmented runtime state: transcripts, tool effects, memory events, workspace placement, branch provenance, and replay evidence are recorded separately and become difficult to inspect or reproduce. OpenRath addresses this issue with a PyTorch-like programming model for multi-agent, multi-session systems. The analogy concerns the role of a central first-class runtime abstraction, not tensor computation. Its core abstraction is Session, the runtime value passed between agents and workflows. A Session is branchable, inspectable, replayable, backend-aware, and composable. It records conversation chunks, sandbox placement, lineage metadata, token usage, pending work, and tool evidence, while defining where memory interactions enter the runtime record. Since this state is carried by the same value used in program execution, fork, merge, and replay become explicit runtime operations rather than states reconstructed from external traces. OpenRath further defines Sandbox, Tool, Agent, Memory, Workflow, and Selector, with Selector turning control flow into runtime-routed decisions. This report presents the programming model, architecture, audited milestones, and evidence protocol. Its claims are limited to controlled runtime properties, while broad quantitative comparisons, live-provider quality, optional-backend availability, and memory quality are left for follow-on evaluation. The central thesis is that Session provides agent systems with a first-class runtime value for auditable composition.

1 Introduction

OpenRath addresses hidden runtime-state fragmentation by making Session the first-class value carrying agent work and its evidence. This session-centered boundary enables explicit composition, inspection, branching, merging, persistence, and replay without reconstructing state from external traces.

  • Session-centered runtime boundary: The Session -> Session interface lets agents compose into workflows while branching, merging, handoff, and replay operate on program values.The PyTorch-like analogy concerns a stable architectural interface and composable computation, not tensor mathematics.
  • Ecosystem boundary: OpenRath complements graph runtimes, tracing systems, tool protocols, sandbox providers, and memory stores rather than replacing them with a universal runtime.Its narrower claim is that a shared Session can carry their effects across scheduling, tracing, dispatch, persistence, fork, merge, compression, and review.
  • Session-centered runtime boundary: OpenRath treats Session as one inspectable runtime flow for conversation, placement, lineage, usage, pending work, tool evidence, and memory-boundary records.These effects are represented together rather than as separate controller bookkeeping.
  • Runtime object vocabulary: The framework organizes agent programs around Session, Sandbox, Tool, Agent, Memory, Workflow, and Selector while separating runtime state from tool and memory execution backends.Local execution, optional OpenSandbox placement, MCP-style tools, and memory services participate through verified evidence packets.
  • Evidence and scope: The report uses an audit-first release protocol and reserves broad benchmark superiority, human preference, and cross-system leaderboard claims for follow-on evaluation.Evidence packets include lineage export, local sandbox execution, workflow transcript, focused tests, visual QA, claim ledger, and memory source audit.
  • Session-centered runtime boundary: OpenRath promotes tool effects, memory events, workspace placement, and branch provenance from loop side channels into a branchable, persistent, replayable Session.The same Session can be passed to agents, forked for independent work, merged after review, persisted as evidence, and replayed with explicit backend boundaries.

2 Related Work

Related work spans reasoning and tool-use methods, multi-agent frameworks, graph runtimes, tracing systems, memory architectures, and evaluation benchmarks. OpenRath’s distinguishing focus is the crossing object: a first-class Session that carries runtime state through these layers rather than treating coordination or traces as separate state boundaries.

  • Runtime-stack boundary: The agent ecosystem assigns reasoning, multi-agent coordination, durable execution, tracing, tool protocols, benchmarking, and provenance to specialized layers, leaving their shared state boundary open.The open design question is what state can preserve conversation, lineage, placement, tool effects, memory, and artifacts across those layers.
  • Multi-agent composition: OpenRath differs from multi-agent frameworks by making the passed object—a Session—the composition boundary rather than a framework-private conversation or workflow state.The cited comparison contrasts OpenRath’s value-passing model with role- and conversation-centered systems such as AutoGen, CAMEL, MetaGPT, ChatDev, and AgentVerse.
  • Graph runtimes and tracing: Unlike LangGraph’s checkpointed scheduler state, an OpenRath Session is the runtime value that the program itself passes and forks.LangGraph provides history and time travel from checkpoints, while OpenRath places branching on the program-carried value.
  • Graph runtimes and tracing: Traces and spans in agent SDKs and OpenTelemetry are observer-facing records of executions, whereas OpenRath makes runtime effects part of the Session state.The passage contrasts post hoc observation of generations, tool calls, handoffs, and guardrails with OpenRath’s value-level state boundary.
  • Memory systems: Memory research addresses reflection, retrieval, episodic buffers, long-running memory streams, and bounded-context memory hierarchies at the agent level.Examples include Reflexion, Generative Agents, and MemGPT, positioning OpenRath’s concern as where memory interactions enter the shared runtime record.
  • Evaluation environments: Evaluation work covers interactive tool-agent-user tasks, software engineering, terminals, web, desktop, and embodied environments through diverse benchmarks.The cited examples include AgentBench, τ-bench, SWE-bench, Terminal-Bench, WebArena, OSWorld, ALFWorld, ScienceWorld, GAIA, and others.

3 Background and Motivation

Multi-agent workflows fragment runtime state across branches, tools, memory, files, sandboxes, and resumed runs, making the producing path difficult to reconstruct. OpenRath addresses this gap by making Session the branchable runtime value that carries context and evidence through execution while preserving provenance during merges.

  • Fragmented runtime state: Multi-agent applications outgrow the single assistant loop because runtime paths span roles, tools, memory, files, sandboxes, and resumed runs.Final transcripts do not expose the full path, which is distributed across controller code, tool logs, memory stores, workspace state, and provider traces.
  • Operational motivation: Long-running workflows make state boundaries an engineering contract: users and reviewers must determine inputs, changes, backends, and influencing memories or artifacts.This need arises when agents edit repositories, call external tools, resume after interruption, or route work through multiple roles.
  • Operational motivation: Multi-agent work creates multiple runtime paths for gathering context, editing or testing artifacts, validating evidence, and compressing results.A shared transcript can burden later agents with noise, while hidden controller state prevents reviewers from reconstructing branch provenance.
  • Session-centered design: OpenRath makes branchability a property of Session state: branches inherit needed context, accumulate local evidence, and merge useful results without erasing provenance.Session flows through agents, tools, memory-boundary operations, sandbox placement, compressors, and workflows.
  • Session-centered design: Session is the central runtime value that every other component reads, transforms, annotates, or passes forward.This object vocabulary provides the foundation for the report’s remaining architecture.

4 OpenRath Programming Model

OpenRath centers its programming model on Session as the shared runtime value transformed or annotated by reusable components. Explicit ownership boundaries, runtime routing, and visible memory events keep multi-agent execution inspectable while limiting claims about retrieval quality.

  • 4 OpenRath Programming Model: OpenRath requires runtime components to transform or annotate Session rather than inventing private records for transcripts, placement, tools, memory, or workflows.This shared-value discipline makes the PyTorch analogy about reusable transformations and explicit state boundaries, not tensor computation.
  • 4 OpenRath Programming Model: Session owns lineage, tools use the active sandbox, workflows compose session transformations, and memory interactions remain visible runtime events rather than hidden prompt text.These boundaries prevent individual objects from owning the entire conversation graph, placement, orchestration state, or concealed memory content.
  • 4 OpenRath Programming Model: Tools expose stable model-visible schemas while receiving the active Session and validated arguments, enabling backend-specific execution without changing that contract.Built-in tools can create payloads for file, command, code, or MCP-like execution.
  • 4 OpenRath Programming Model: Selector reads Session state to route among agents or workflows, making branching and looping inspectable runtime decisions recorded in the session.This differs from a static workflow graph because the next step is selected at runtime while still flowing through one value.
  • 4 OpenRath Programming Model: OpenRath offers local lexical memory, optional embeddings, and an optional external backend, but leaves retrieval quality to follow-on empirical evaluation.Recall and commit are exposed through agent-level operations so remembering remains visible in the runtime record.

5 Runtime Architecture

OpenRath treats Session as a single runtime value that remains inspectable across placement, transformation, branching, merging, persistence, replay, and release. Its architecture makes lineage, sandbox compatibility, tool effects, and replay evidence explicit parts of runtime state.

  • Session lifecycle: A Session follows one lifecycle through creation, backend placement, agent or workflow transformation, branching, merging, persistence, replay, and resource release.The same runtime object is retained across these phases rather than replaced by separate orchestration state.
  • Branching and merging: fork preserves parent relations, detach creates a new lineage root, and merge records both parents while requiring compatible sandbox placement.Sessions must share a live sandbox handle or target the same unbound backend, making placement part of the runtime graph.
  • Tool execution: Tool execution validates provider-returned calls, invokes selected tools with the active Session, and records malformed arguments, unknown tools, exceptions, and results as tool-result chunks.Side effects dispatch backend payloads through the Session’s sandbox, preserving tool activity as session evidence.
  • Persistence and replay: Persistence appends session rows to JSONL, while lineage export records identifiers, parent identifiers, lineage operators and kinds, chunk counts, and cumulative usage.The plain JSONL format is intended for command-line inspection, release evidence, and later diagram conversion.

6 Multi-Agent Multi-Session Design

OpenRath keeps multi-agent composition centered on Session: agents and workflows remain reusable layers while the same runtime value carries evidence, placement, lineage, usage, and replay state. The report presents this as a controlled runtime-state claim, with broader scheduling, merge, memory, and benchmark claims deferred.

  • Runtime model: OpenRath defines agents as reusable layers, workflows as reusable compositions, and Session as the moving runtime value across multi-agent systems.This avoids introducing a second shared mutable object, hidden message bus, or controller-only trace.
  • Runtime model: The same runtime contract supports engineering roles and research stages without replacing the object carrying evidence, placement, lineage, usage, and replay state.Workflows can grow from scripts into nested agent teams while preserving that runtime object.
  • Evidence and scope: The evidence verifies deterministic lineage export, local sandbox packets, workflow transcripts, focused tests, and layout review, while broader capability claims remain follow-on evaluation.Deferred areas include parallel branch scheduling, merge quality, memory quality, and task-level leaderboards.
  • Composition boundary: Agents route, hand off, and compose work by reading and returning Session state rather than introducing a second runtime object.Multi-session runtime and multi-agent workflow therefore share the same boundary.

7 Implementation Milestones

OpenRath is a working Python implementation organized around a shared Session object rather than an architecture sketch. Its audited milestones establish tested local runtime properties while leaving optional backends and live model quality environment- or provider-dependent.

  • Implementation surface: OpenRath is distributed as a Python package implementing session, execution-backend, flow, LLM-provider, and persistence-with-lineage-export layers.The report evaluates an audited code snapshot considered adequate for technical review, rather than a tagged archival release.
  • Audited milestones: Focused tests exercise ordered chunks, branching, usage accounting, JSONL lineage export, local sandbox placement, and tool dispatch.Custom-tool, MCP, and scripted-workflow examples further demonstrate tool and workflow behavior.
  • Claim boundaries: The optional OpenSandbox backend and LLM-provider layer are present but environment- or provider-dependent, while live model quality lies outside the milestone’s substantiated claims.The substantiated claims are deterministic and local.
  • Shared runtime model: The milestone demonstrates a single object model supporting branching, audit, and replay without reconstructing a separate runtime state.Session carries the flowing state while execution, tools, agents, workflows, and persistence operate through that model.
  • Shared runtime model: Session is the shared runtime value: backends select execution placement, tool calls become structured events, and agents and workflows transform sessions without private transcript formats.Persistence with lineage export makes the resulting state inspectable outside the running process.

8 Release Evidence and Evaluation Protocol

The release evaluation is audit-first, using claim ledgers and rebuildable evidence packets to support, scope, or limit runtime claims. Broad benchmarks and comparative metrics are deferred until runtime state can be preserved, exposed, and evaluated reproducibly.

  • Audit-first release evidence: The audit-first protocol maps each visible runtime claim into a ledger and rebuildable evidence packet, with explicit boundaries for what the evidence proves.The ledger currently classifies ten claims across operational, partial, prerequisite-only, bibliography-backed, layout-smoke, and evidence-gated support.
  • Audit-first release evidence: Supported claims remain in the thesis, evidence-gated claims remain visible but bounded, and framing claims stay separate from empirical evidence.The protocol preserves honesty without presenting the paper as an internal backlog.
  • Audit-first release evidence: Each evidence packet includes the producing command, manifest, source and environment metadata, session JSONL or tool logs, output artifact, and proof-boundary summary.This packet-first shape gives reviewers a direct path from claim to reproducible artifact and provides maintainers a practical release gate.
  • Evaluation scope: Before broad benchmarks, evaluation asks whether OpenRath preserves and exposes the runtime state needed to make later comparisons meaningful.Broad coding and general-assistant benchmarks confound runtime semantics with model, prompt, environment, reviewer, and task-distribution choices.
  • Evaluation scope: Follow-on comparisons should use runtime shapes and measure correctness, provenance coverage, replayability, backend portability, efficiency, task quality, and control or safety events.These metrics become results only when runners emit comparable evidence.

9 Limitations

The report frames its limitations as explicit scope boundaries, substantiating only a narrow set of Session-centered runtime claims. It separates implemented semantics from optional integrations, follow-on evaluation, and unaddressed risks.

  • Scope boundaries: The report supports deterministic evidence for a narrow set of Session-centered runtime claims, not broad benchmark superiority or safety properties.It also does not claim verified local-memory implementation, OpenSandbox availability, or fully reproducible live-model outputs.
  • Release argument: These limitations distinguish implemented runtime semantics from optional integrations, follow-on evaluation, and risks outside the report’s scope.The boundaries are presented as part of the release argument rather than as apologies.
  • Evidence requirements: A limitation should leave the scoped table only when a supporting evidence packet exists and the claim ledger maps the text to that artifact.This condition governs stronger future claims.

10 Conclusion

OpenRath’s narrow contribution is to make agent runtime state explicit through Session, connecting conversation, lineage, placement, tools, memory, usage, artifacts, and replay evidence. The report claims controlled runtime behavior today while reserving broader quality and provider evaluations for follow-on work.

  • Core contribution: OpenRath connects conversation chunks, branch lineage, sandbox placement, tool effects, memory interactions, usage, artifacts, and replay evidence within one runtime.The contribution is deliberately narrower than defining a prompt graph, tool registry, trace stream, or benchmark harness.
  • Core contribution: Session is OpenRath’s boundary for runtime state, with major components transforming, annotating, dispatching through, or emitting evidence about it.Evidence remains in the value passed by the program rather than a reconstructed side channel.
  • Scope and limitations: The report claims deterministic runtime behavior is reviewable through release packets today, while broader quality, memory, and live-provider evaluations remain follow-on work.Its durable thesis is that reliable agent systems need a first-class runtime value, which OpenRath identifies as Session.
  • Design standard: Future capabilities should transform a Session, attach evidence to it, or expose backend effects through it, avoiding hidden side channels.This boundary allows implementation milestones, case studies, and evaluation claims to expand without changing the core argument.
  • Core thesis: OpenRath proposes Session as the single runtime value that agent systems read, transform, and explain, analogous to the tensor’s central role in deep learning.The analogy concerns a unifying runtime value rather than tensor computation.

Appendix · A Case Studies

The case studies frame Session-centered runtime state as a scoped applicability argument, connecting intended workloads to deterministic evidence from the release packet suite. Repository editing and long-running coding provide the clearest motivation for durable, inspectable agent state.

  • A Case Studies: Case studies identify workloads suited to a Session-centered runtime model rather than reporting benchmark results.Their purpose is to relate applicability to deterministic evidence already provided by the release packet suite.
  • A Case Studies: The release packets cover lineage export, local sandbox execution, scripted workflow composition, and focused implementation tests.They also explicitly skip evidence-gated memory and [passage truncated].
  • A Case Studies: Repository editing and long-running coding most directly motivate durable and inspectable agent state.These settings include software-engineering benchmarks, agent-computer interfaces, and company-style digital-worker tasks.
  • A Case Studies: Software-engineering benchmarks built from real GitHub issues exemplify workloads requiring durable and inspectable agent state.The passage cites these benchmarks as one relevant repository-editing setting.
  • A Case Studies: Agent-computer interfaces for navigating, editing, and testing repositories are another target workload for the runtime model.The passage identifies these interfaces among the settings motivating durable and inspectable state.
  • A Case Studies: Research synthesis motivates branch-specific context, verifier roles, and controlled compression across repository-editing and coding branches.Different branches may collect, filter, and restyle evidence [passage truncated].
Loading 2606.19409v1…