# OpenRath: Multi-Agent Python Framework Built Around Session State

> OpenRath is an open-source Python framework for multi-agent and multi-session workflows, modeled after PyTorch's approach to composable abstractions. It is aimed at teams building production systems where multiple agents must collaborate across branching session histories, not just pass messages in a single loop.

**Rath-Team/OpenRath** — An open-source, PyTorch-like runtime for dynamic multi-agent and multi-session workflows.

- Repository: https://github.com/Rath-Team/OpenRath
- Website: https://www.openrath.com/
- Stars: 1,141 · Forks: 59
- Language: Python
- License: BSD-3-Clause
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/rath-team-openrath

## Multi-Agent Workflows Modeled on PyTorch Abstractions

OpenRath draws a direct analogy between PyTorch's tensor-based computing model and multi-agent coordination. Where PyTorch has Tensor, Device, Parameter, Function, nn.Linear, and nn.Module, OpenRath has Session, Sandbox, Memory, Tool, Agent, and Workflow. The Selector component maps to dynamic control flow: it is an LLM-backed router that picks the next workflow at runtime, replacing explicit if/while branching with a callable that routes between self-describing workflows.

This design is aimed at engineers who build systems where multiple agents collaborate across multiple branching sessions at the same time. A ChatGPT-style assistant (one agent, one session) is the simplest case the framework supports. A sub-agent system (multiple agents, one shared session) is the next level. OpenRath's stated focus is the hardest case: many agents sharing many sessions, with each agent acting as a transformation layer on a shared Session value rather than maintaining its own private message history.

The framework requires Python 3.10 through 3.13. It ships with built-in support for OpenAI and Anthropic providers, and the optional litellm extra adds support for additional providers.

## Session as the First-Class Value in OpenRath's Dataflow

Most multi-agent frameworks organize state around the agent: each agent has its own conversation history, and handoffs copy or summarize that history. OpenRath inverts this. The README's description states that in OpenRath, an agent is a reusable, composable session transformation layer. The Session carries context as structured chunks rather than repeated copied message strings, and workflows can reuse, fork, compress, and pass context directly.

This difference becomes significant when a system needs branches. If one workflow produces two possible continuations, OpenRath can fork the Session at that point and run separate agents on each branch without copying message strings. Each Session carries conversation state, inter-agent collaboration lineage, and usage tracking. The Sandbox component decides where tools run: locally, in OpenSandbox, or in another backend. Memory persists agent memory state across runs.

The v2.0.0 release added explicit step and router boundaries via @step and @router decorators. These compile agent and workflow definitions into immutable execution plans. A Run becomes a durable entity: it survives process restarts, records Events and Checkpoints, and can be resumed. This is the core change from v1.x, which treated the Python framework as the runtime, to v2.0.0, which adds a production execution layer around the Python API.

## Installing OpenRath and Running the Production Profile

The base package installs from PyPI. For the production profile with the Agent Server and PostgreSQL support:

```bash
pip install "openrath[server,postgres]"
openrath-migrate
openrath-migrate --check
```

The migrate command applies schema changes to the PostgreSQL database. The --check variant validates that migrations are up to date without applying them. Runtime identities do not need DDL privileges; migrations are a separate operation by design.

To start the production server, configure a store, an effect ledger, and authentication, then pass them to the Agent Server:

```python
runtime = LocalRuntime(
    store,
    effect_ledger=ledger,
    production_mode=True,
)
server = AgentServer(store, runtime, auth=auth, audit_sink=audit)
```

The Agent Server handles token-based authentication with explicit action grants. Object access is scoped by tenant and project. Agent Server tokens carry explicit action grants, and synchronous steps cannot declare a preemptive timeout; use an async step or an isolated executor when a deadline must be enforced.

The repository includes example files (example/01_hello_agent.py through example/12_compile.py) covering session lineage, sandboxing, tool use, streaming, compression, memory, provider switching, and compile-time workflow validation.

## Durable Execution: Leases, Effects, and Human Interrupts

The v2.0.0 production layer adds several mechanisms that distinguish OpenRath from frameworks that rely on the Python process staying alive. Leases and fencing prevent stale workers from committing new state after a crash. An Effect Ledger records tool outcomes and idempotency keys so that a replayed step does not re-execute non-idempotent effects. When the Effect Ledger encounters an ambiguous non-idempotent effect, it routes the Run to a NEEDS_REVIEW state rather than replaying blindly.

Durable Interrupts pause a Run at a defined point to wait for human approval or additional input, then resume it without rebuilding hidden loop state. This is distinct from a simple confirmation dialog: the Run persists across the pause, and the approval can be provided at a later time or by a different process.

The backend for the durable runtime is PostgreSQL as the primary data store. Redis can accelerate signaling. S3-compatible storage holds artifacts. Health checks, migration tooling, container configuration, and Kubernetes references are included in the deploy/ directory. The operations guide is at deploy/docs/operations-v2.md and the migration guide at deploy/docs/migration-v2.md.

## Cases Where OpenRath Is the Wrong Tool

OpenRath's production profile adds real infrastructure requirements. Running the Agent Server requires PostgreSQL, and the schema migration step is separate from the server start. Teams who want a framework that runs against an in-memory store for prototyping will find that Embedded mode works, but the production profile requires a database.

The Agent Server HTTP surface is explicitly marked Beta in v2.0.0. The README states this directly: the interface is stable enough for production use, but the HTTP contract is not yet at a stable release. Projects that require a stable HTTP API from version one of their integration should verify current interface guarantees before depending on Agent Server endpoints.

v1 JSONL imports are documented as historical records rather than resumable active Runs in v2.0.0. If a system built on v1 needs to resume work as a v2 Run rather than re-import data, that path is not directly supported.

Synchronous steps cannot declare a preemptive timeout. The documentation states that users must switch to an async step or an isolated executor when deadline enforcement is needed. This is a real constraint for steps that call slow external APIs.

## OpenRath Versus LangGraph

LangGraph is a Python library for building stateful, multi-actor applications with language models. Like OpenRath, it treats shared state as the organizing principle rather than agent-owned histories. LangGraph models execution as a graph of nodes and edges, where state passes between nodes as a typed Python object.

The key difference in approach is structural. LangGraph expresses control flow as a directed graph with explicit edges; conditional routing becomes an edge condition. OpenRath expresses control flow through Selectors, which are LLM-backed routers that pick the next workflow at runtime. The practical consequence is that LangGraph routing decisions are expressed in Python code, while OpenRath's Selector is a model call.

OpenRath's v2.0.0 production layer, with its PostgreSQL-backed durable Runs, Effect Ledger, and Agent Server, goes beyond what most orchestration frameworks provide out of the box. LangGraph does not include an Effect Ledger or a built-in concept of idempotent replay. Teams who need that level of production infrastructure in a single package will find OpenRath's scope more complete. Teams who prefer to compose their own infrastructure and want fine-grained control over the execution graph will find LangGraph's model more familiar.

## License, Versioning, and Release Cadence

OpenRath is licensed under BSD-3-Clause, which permits use in proprietary products without requiring the source of derivative works to be released. The LICENSE file in the repository governs this.

The project reached v2.0.0 on July 31, 2026, following a release candidate on July 29, 2026. The immediately preceding stable release was v1.3.0 on July 8, 2026. The last push to the main branch was on September 23, 2026, indicating the project is under active development. A paper is available at arxiv.org/abs/2606.19409 and documentation at docs.openrath.com.

The pyproject.toml supports Python 3.10, 3.11, 3.12, and 3.13. The optional extras are litellm (for additional LLM providers), opensandbox, openviking, server, postgres, redis, otel (OpenTelemetry), and s3. The openrath-server, openrath-migrate, and openrath-worker CLI entry points are installed with the package.

## Conclusion

OpenRath suits teams building production multi-agent systems that must handle multiple concurrent sessions, durable execution across process restarts, and traceable collaboration between agents. Single-agent chatbot projects and teams that want minimal setup should look elsewhere; the production stack requires PostgreSQL, Redis, and a schema migration step. Verify that the Agent Server HTTP surface, marked Beta in v2.0.0, meets your stability requirements before committing to it in a production API path.

## FAQ

### What problem does OpenRath solve for multi-agent systems?

OpenRath addresses the problem of managing shared state when many agents collaborate across many branching sessions at the same time. By treating Session as the core data type rather than per-agent message histories, OpenRath allows agents to fork, reuse, and pass context without copying message strings. The v2.0.0 production layer adds durable execution that survives process restarts.

### How is OpenRath's Session concept different from a message history?

A message history is a list of text turns owned by one agent. An OpenRath Session carries conversation state as structured chunks with inter-agent collaboration lineage, and it can be forked, compressed, and passed between agents directly. Multiple agents read from and write to the same Session without copying, which reduces the context overhead that accumulates when agents summarize each other's state.

### What databases does OpenRath require in production mode?

In production mode, OpenRath uses PostgreSQL as the primary durable data store for Runs, Events, and Checkpoints. Redis is optional and accelerates signaling. S3-compatible storage holds artifacts. The openrath-migrate command must be run as a separate step before starting the Agent Server; runtime identities do not need DDL privileges.

## Sources

- [License: BSD-3-Clause](https://github.com/Rath-Team/OpenRath/blob/main/LICENSE)
- [Project website](https://www.openrath.com/)
- [Rath-Team/OpenRath on GitHub](https://github.com/Rath-Team/OpenRath)
- [README](https://github.com/Rath-Team/OpenRath/blob/main/README.md)
- [Releases](https://github.com/Rath-Team/OpenRath/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rath-team-openrath