OpenRath : quand l'état d'exécution des agents devient un objet Python
An open-source, PyTorch-like runtime for dynamic multi-agent and multi-session workflows.
En bref
- De quoi s’agit-il ?
- OpenRath se présente comme un framework multi-agents et multi-sessions inspiré de PyTorch, où Session, Sandbox, Memory et Workflow remplacent la boucle d'agent habituelle. La version 2.0.0 ajoute une couche d'exécution durable, mais l'interface HTTP du serveur reste étiquetée Beta.
- À qui s’adresse-t-il ?
- OpenRath convient aux équipes qui ont besoin de plusieurs agents partageant plusieurs sessions ramifiées, avec une traçabilité de la lignée et une exécution durable après redémarrage. Il ne convient pas à qui veut un chat mono-agent ou refuse de faire tourner PostgreSQL, Redis et un stockage compatible S3.
- Puis-je l’utiliser commercialement ?
- Oui. BSD-3-Clause est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 47 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : l'état d'exécution éparpillé entre agents
La plupart des frameworks d'agents partent d'une boucle d'agent. OpenRath part de Session. Le README formule l'argument ainsi : la Session est la valeur qui circule, avec ses chunks ordonnés, son placement, sa lignée et son usage. Ce choix répond à une situation précise : une application qui fait collaborer plusieurs agents sur plusieurs branches de conversation, avec de la mémoire persistante et une exécution en bac à sable, tout en devant retrouver qui a écrit quoi.
Le public visé est donc celui qui construit des systèmes multi-agents multi-sessions, et non celui qui assemble un assistant conversationnel unique. Le README décrit quatre paradigmes : un agent sur une session, plusieurs agents sur une session partagée, un agent sur plusieurs sessions, puis plusieurs agents sur plusieurs sessions. OpenRath se positionne sur le quatrième. Si votre besoin tient dans le premier, la machinerie Session, Sandbox et Memory n'apporte rien de tangible.
Session comme Tensor : la correspondance avec PyTorch
Le README expose une table de correspondance explicite. Tensor devient Session, Device devient Sandbox ou Backend, Parameter devient Memory, Function devient Tool, nn.Linear devient Agent, nn.Module devient Workflow, et le contrôle de flux devient Selector. Un Agent est décrit comme une couche réutilisable qui transforme une session en une autre à partir d'un prompt, d'un fournisseur, d'outils et de mémoire. Un Workflow compose agents, outils, transformations de session et workflows imbriqués.
Le point intéressant est le Selector : un routeur adossé à un LLM qui choisit le workflow suivant à l'exécution, ce qui permet de garder les if et les while en Python ordinaire. C'est une réponse au problème classique des graphes d'orchestration figés, où toute bifurcation conditionnelle doit être déclarée dans un DSL. Ici, la décision de routage est un objet du runtime, pas une arête codée en dur. La contrepartie est moins visible dans le matériel fourni : un routeur LLM introduit un appel de modèle supplémentaire à chaque bifurcation, et le README ne documente pas de mécanisme de cache ou de repli déterministe pour ce routeur.
Ce que la 2.0.0 ajoute : plans immuables, baux et registre d'effets
La version 2.0.0 est présentée comme le passage d'un framework Python composable à un runtime durable. Le README décrit une chaîne : les définitions Python sont compilées en plans immuables, les Runs durables sont gouvernés par des checkpoints, des leases, des effects et des interrupts, et PostgreSQL, Redis et un stockage compatible S3 fournissent le plan de données opérationnel.
Les frontières @step et @router sont le mécanisme central. Elles délimitent des points de reprise, ce qui permet aux Runs, Events et Checkpoints de survivre au redémarrage d'un processus ou d'un worker. Les leases et le fencing empêchent un worker périmé de valider silencieusement un nouvel état. L'Effect Ledger enregistre les résultats et les clés d'idempotence, et le README précise qu'un effet non idempotent ambigu s'arrête en NEEDS_REVIEW plutôt que d'être rejoué à l'aveugle. Les Interrupts durables mettent un Run en pause pour une approbation ou une saisie, puis le reprennent sans reconstruire un état de boucle caché.
Cette architecture a un coût de conception. Découper un workflow en étapes durables oblige à réfléchir à l'idempotence de chaque effet de bord avant l'écriture, pas après. Le README signale d'ailleurs qu'une étape synchrone ne peut pas déclarer de timeout préemptif : il faut une étape asynchrone ou un exécuteur isolé pour imposer une échéance.
Installation et migration : les commandes du dépôt
Le README donne deux commandes distinctes, et cette séparation est délibérée. L'installation du profil de production se fait avec pip install "openrath[server,postgres]". La migration de schéma est une opération à part, lancée par openrath-migrate, avec openrath-migrate --check pour un contrôle préalable. Le README insiste sur un point : les identités du runtime n'ont pas besoin de privilèges DDL. La migration est donc confiée à un rôle distinct de celui qui exécute l'application, ce qui réduit la surface exposée en cas de compromission du processus applicatif.
Côté code, l'exemple du README montre LocalRuntime construit avec un store, un effect_ledger et production_mode=True, puis un AgentServer prenant en paramètres store, runtime, auth et audit_sink. Deux profils coexistent : le mode embarqué, utile dans un processus de confiance, et le mode Agent Server, décrit comme le profil de production strict. Le README précise aussi que les jetons doivent porter des autorisations d'action explicites et que l'accès aux objets est limité par tenant et par projet. Le matériel fourni ne détaille pas le format exact de ces jetons, ni la manière de les émettre : il faut se référer à deploy/docs/operations-v2.md, cité par le README.
Les limites assumées par le projet lui-même
Le README est inhabituellement direct sur la maturité. La surface HTTP de l'Agent Server reste étiquetée Beta dans la version 2.0.0. Les imports JSONL de la v1 sont qualifiés de documents historiques, et non de Runs actifs reprenables : si votre exploitation repose sur des journaux v1, la migration ne les transformera pas en exécutions reprises, il faut le savoir avant de planifier une bascule.
D'autres contraintes apparaissent en creux. Le mode production suppose une pile de données à trois composants, PostgreSQL comme source de vérité durable, Redis en accélérateur de signalisation, et un stockage compatible S3 pour les artefacts. C'est une infrastructure à administrer, pas une bibliothèque que l'on ajoute à un requirements.txt. Le README mentionne des références de conteneur et Kubernetes, ainsi que des éléments de santé, de migration et de télémétrie, mais le matériel fourni n'en donne pas le contenu. Enfin, un routeur LLM pour le contrôle de flux introduit une source de non-déterminisme dans le chemin d'exécution : le README ne décrit pas de mode de rejeu déterministe pour le Selector.
Face à LangGraph : graphe déclaré contre objet de session
L'alternative la plus proche conceptuellement est LangGraph, dont le modèle repose sur un graphe d'états déclaré, avec des nœuds et des arêtes, et un point de contrôle associé à l'état du graphe. La différence d'approche est nette. Dans LangGraph, la topologie est la structure de premier ordre : on décrit le graphe, puis on l'exécute. Dans OpenRath, c'est la Session qui est la valeur de premier ordre, et les agents sont des transformations de cette valeur. Le contrôle de flux passe par un Selector adossé à un LLM plutôt que par des arêtes conditionnelles déclarées.
Le compromis est symétrique. Un graphe déclaré se lit et se vérifie statiquement : on peut inspecter les transitions possibles sans exécuter le système. Un routeur LLM choisit à l'exécution, ce qui couvre des cas que le graphe ne peut pas exprimer à l'avance, au prix d'une inspectabilité moindre. Le README ne fournit pas de mécanisme de validation statique du routage, et ne compare pas OpenRath à LangGraph. Cette comparaison est donc une lecture de la documentation, pas un résultat mesuré.
Maintenance, licence et coût de mise à jour
Le dépôt est publié sous BSD-3-Clause, une licence permissive qui autorise la réutilisation et la redistribution avec conservation de la notice de copyright et de la clause de non-approbation. Elle n'impose pas de publication du code dérivé, contrairement aux licences copyleft. Le matériel fourni ne mentionne aucune clause additionnelle, ni aucune restriction d'usage : il faut lire le fichier LICENSE du dépôt pour la formulation exacte, ce qui n'est pas un conseil juridique.
Sur le rythme, l'historique fourni montre v2.0.0rc1 le 29 juillet 2026, v2.0.0 le 31 juillet 2026, et v1.3.0 le 8 juillet 2026. La 2.0.0 n'est donc pas une version stabilisée depuis longtemps. Le coût de mise à jour ne se limite pas au paquet Python : il inclut la migration de schéma via openrath-migrate, la vérification préalable avec openrath-migrate --check, et la compatibilité des enregistrements v1, que le README classe comme documents historiques. Le projet publie deploy/docs/migration-v2.md et deploy/docs/openapi-v2.json, ce qui donne une base de comparaison pour mesurer l'écart d'API entre deux versions. Prévoir cette étape avant de s'engager sur la 2.0.0, et non après.
Conclusion éditoriale
OpenRath convient aux équipes qui ont besoin de plusieurs agents partageant plusieurs sessions ramifiées, avec une traçabilité de la lignée et une exécution durable après redémarrage. Il ne convient pas à qui veut un chat mono-agent ou refuse de faire tourner PostgreSQL, Redis et un stockage compatible S3. Avant d'adopter, vérifier le contenu réel de deploy/docs/operations-v2.md et deploy/docs/migration-v2.md, et confirmer si la surface HTTP Beta de l'Agent Server est un risque acceptable pour votre mise en production.
Notes de la communauté