Jido 2.0 - Présentation d’un framework d’agents basé sur Elixir

 (jido.run)
7 points par GN⁺ 2026-03-07 | 1 commentaires | Partager sur WhatsApp
  • Une architecture d’agents purement fonctionnelle qui définit l’état et les comportements comme des données, et sépare les effets de bord sous forme de directives impératives, ce qui simplifie les tests et le débogage
  • Adoption d’une API concise et d’une conception centrée sur BEAM, avec séparation de modules comme jido_action et jido_signal pour fournir un système standardisé d’actions et de signaux
  • La couche supérieure Jido AI prend en charge 6 stratégies de raisonnement, dont ReAct et Chain-of-Thought, et permet d’exploiter 11 fournisseurs et 665 modèles grâce à une intégration LLM basée sur ReqLLM
  • Jido s’étend désormais en plateforme d’écosystème d’agents et, via son intégration avec Ash Framework (ash_jido), prend en charge la transformation des opérations CRUD en outils appelables par l’IA

Vue d’ensemble de Jido 2.0

  • Jido 2.0 est un framework d’agents basé sur Elixir, aboutissement de 18 mois de développement et de refonte
    • Le projet a d’abord démarré en 2024 sous la forme d’une plateforme de bots appelée BotHive, avant d’adopter le runtime BEAM comme fondation de son système d’agents
    • Pour dépasser les limites des frameworks basés sur TypeScript ou Python, il s’appuie sur la concurrence et la stabilité de BEAM

Ce qui change de la version 1.0 à 2.0

  • Jido 1.0 souffrait d’une abstraction excessive qui nuisait à l’utilisabilité, mais la version 2.0 l’améliore avec une API simplifiée et une structure centrée sur BEAM
    • En intégrant les retours des utilisateurs, le projet a supprimé la complexité inutile et réduit au minimum les frictions pour accomplir les tâches de base
    • Une évolution guidée par l’idée suivante : « on veut créer des agents, pas se battre avec le framework »

Un cœur d’agents puissant et résilient

  • Le cœur de Jido 2.0 repose sur une architecture d’agents purement fonctionnelle
    • Un agent est défini comme une simple structure contenant un état (state), des actions (actions) et des outils (tools)
    • Toutes les opérations sont traitées par la fonction cmd/2, qui retourne, selon l’action reçue, l’agent mis à jour et une liste de directives
    • Les effets de bord sont exprimés sous forme de directives, exécutées par le runtime, ce qui facilite les tests et le débogage
  • Jido.AgentServer encapsule les agents dans un GenServer supervisé et prend en charge le routage des signaux ainsi qu’une hiérarchie parent-enfant entre agents
  • Les stratégies (strategy) constituent des points d’extension, avec deux options fournies par défaut : Direct (exécution séquentielle) et FSM (machine à états)
    • Les stratégies d’IA comme ReAct et Chain-of-Thought fonctionnent elles aussi via la même interface

Séparation des modules d’actions et de signaux

  • jido_action : un contrat d’action universel qui définit toutes les capacités des agents
    • Inclut la validation de schéma à la compilation, des hooks de cycle de vie et la conversion automatique vers le format d’outils ReqLLM
    • Fournit plus de 25 outils préconstruits ainsi qu’un planificateur de workflows basé sur des DAG
  • jido_signal : un système de messagerie basé sur CloudEvents v1.0.2
    • Propose un format de signal standardisé, un routeur basé sur des tries, un bus pub/sub et 9 adaptateurs de dispatch
    • Permet l’intégration avec divers systèmes sans protocole non standard

La couche d’intégration Jido AI

  • jido_ai est une couche d’intégration qui transforme les appels LLM en intelligence d’agent structurée
    • Intègre 6 stratégies de raisonnement, dont ReAct, Chain-of-Thought, Tree-of-Thoughts, Graph-of-Thoughts, TRM et Adaptive
    • Conserve le même contrat cmd/2 et le même système de directives, en intégrant la couche IA comme une extension et non comme un monde séparé
  • Le système fonctionne sur ReqLLM et prend en charge 11 fournisseurs et plus de 665 modèles
    • Conception orientée streaming, architecture multi-fournisseurs et contributions actives de la communauté

Un écosystème en expansion

  • Jido évolue au-delà d’un simple framework pour devenir un véritable écosystème d’agents
    • La communauté construit sur BEAM des assistants de code, orchestrateurs de workflows, agents de recherche et systèmes de support opérationnel
    • Divers packages apparaissent, notamment pour l’automatisation de navigateur, les systèmes de mémoire, les harness d’évaluation et l’intégration MCP
  • Intégration avec Ash Framework (ash_jido)
    • L’ajout d’un bloc DSL jido à une ressource Ash transforme les actions CRUD en outils appelables par l’IA
    • Les politiques d’autorisation, la couche de données et la sûreté de typage sont conservées
    • ash_ai est lui aussi en cours de migration vers ReqLLM, marquant une convergence entre les deux écosystèmes

Communauté et remerciements

  • Jido 2.0 est construit sur l’écosystème de la communauté Elixir
    • Il s’appuie sur les contributions de bibliothèques majeures comme Phoenix, LiveView, Ash, Req, Telemetry et NimbleOptions

Pour commencer

À lire aussi

1 commentaires

 
GN⁺ 2026-03-07
Avis Hacker News

  • Je n’ai pas encore utilisé Jido en conditions réelles, mais je vais y jeter un œil au moins une fois par mois.
    Je pense que BEAM convient parfaitement à un framework d’agents, mais l’écosystème reste encore limité, donc je n’ai pas pu l’explorer en profondeur.
    J’attends avec impatience la version 2.0. Au passage, il semble y avoir un problème d’entity escape dans certains exemples de code.

    • Merci ! Je corrige ça tout de suite.

  • J’aime vraiment l’approche centrée sur les « données et fonctions pures » mise en avant dès le début de l’article.
    On lit souvent que le modèle d’exécution de BEAM est bien adapté à l’IA, mais en pratique, sa robustesse dans des situations comme les pannes de nœuds ou les déploiements progressifs est souvent négligée.
    Il existe aussi une idée reçue selon laquelle Elixir offre la transparence de localisation, alors qu’en réalité ce n’est pas le cas. Si un nœud tombe, les processus qu’il contient s’arrêtent aussi.
    Garder un état d’agent clair et pur à chaque étape d’appel API permet de résoudre ce problème. Il suffit de stocker l’état dans Mnesia ou Redis, puis de reprendre sur un autre nœud. En fin de compte, l’essentiel, c’est le checkpointing.

    • À mon avis, le principe le plus important de Jido, c’est de construire un agent structurellement correct même sans LLM avant d’utiliser un LLM.
      C’est pourquoi le cœur de Jido n’intègre aucun support LLM.
      Il y a plus de 40 ans de recherche sur les agents, et on a l’impression qu’avec l’arrivée des LLM, tout cela a été oublié. J’ai donc essayé de réétudier cette histoire et de l’intégrer à Jido.
      Bien sûr, j’aime les LLM, mais ça, c’est le rôle du package Jido AI.

  • Le timing est parfait. J’avais bricolé mon propre framework d’agents en mélangeant gen server et Oban, et ça a été un vrai calvaire.
    Ce projet semble pouvoir réduire énormément la douleur côté développement. Merci beaucoup.

    • ❤️

  • Je me demande si c’est similaire à OpenAI Symphony.
    Je suis davantage l’écosystème Elixir que l’IA, donc voir Elixir et BEAM utilisés pour ce type de workloads d’orchestration me paraît assez nouveau.

    • Ça fait plaisir de voir OpenAI utiliser Elixir. Symphony est un exemple d’implémentation directe de ce que Jido peut faire.

  • Le site est difficilement accessible à cause d’un pic de trafic. Je partage donc le lien de sauvegarde archive.org.

    • J’ai l’impression que ça va rester ma honte personnelle pendant les deux prochaines semaines… C’est un bon problème à avoir, mais je n’étais vraiment pas prêt.
    • Je ne sais pas si c’est lié, mais la page s’ouvre bien au début puis se rafraîchit en 404 après quelques secondes. J’ai fini par abandonner la lecture.

  • Merci pour le partage ! Je vais clairement aller voir ça.
    J’ai récemment créé avec des LLM un package A2A, une abstraction proche de GenServer.
    Il existait déjà d’autres implémentations A2A, mais mon package avait une sémantique différente, donc je l’ai publié tel quel.
    Pour ceux que ça intéresse, c’est disponible ici.

    • Super ! J’ai mis une étoile immédiatement.

  • Cela fait plusieurs mois que je suis ce projet, et Elixir/BEAM est une plateforme parfaite pour exécuter des agents.
    BEAM est vraiment léger et efficace, donc en théorie on pourrait faire tourner des milliers d’agents sur un seul serveur.
    J’ai hâte de voir ce que vont construire les gens qui auront compris ça.

    • Le cœur de Jido peut fonctionner même sur un Raspberry Pi.
      Il y a même eu des tentatives de déployer BEAM sur du bare metal (embarqué) pour y faire tourner des agents.
      L’avenir s’annonce vraiment passionnant.

  • J’aimerais bien voir une capture d’écran de l’arbre des processus avec les agents actifs dans observer.
    Pour référence, observer est un outil qui visualise les processus Erlang à l’intérieur de la VM BEAM.
    On peut voir un exemple de capture dans la documentation Fly.io.

    • Nous allons bientôt publier un dashboard appelé jido_studio. Il visualise la structure des processus.
      On peut voir une capture teaser ici.
      Les agents enveloppés avec AgentRuntime fonctionnent généralement comme un seul processus GenServer, mais il y a des exceptions lorsqu’une topologie plus large est nécessaire.

  • Timing parfait. Moi aussi, j’étais en train de développer mon propre framework d’agents Erlang, mais celui-ci est bien meilleur.

  • Je me demande comment la sécurité est garantie. Sans isolation par conteneur, il semble difficile d’empêcher les fuites de secrets de production.

    • Avec Signals et Plugins, il est possible de chiffrer les données entre agents.
      J’ai d’ailleurs vu des cas concrets de Jido implémentés de cette façon.
      Cela dit, cela dépend du cas d’usage, et la sécurité est un sujet bien plus large que la simple question des « agents dans un conteneur ».
      Le but de Jido n’est pas de résoudre directement la sécurité, mais de fournir aux utilisateurs les outils pour la traiter comme ils en ont besoin.