Jido 2.0 - Presentan framework de agentes basado en Elixir

 (jido.run)
7 puntos por GN⁺ 2026-03-07 | 1 comentarios | Compartir por WhatsApp
  • Arquitectura de agentes puramente funcional: define el estado y el comportamiento como datos, y separa los efectos secundarios en directivas imperativas (directive) para simplificar las pruebas y la depuración
  • Adopta una API concisa y un diseño centrado en BEAM, y separa módulos como jido_action y jido_signal para ofrecer un sistema estandarizado de acciones y señales
  • La capa superior, Jido AI, soporta 6 estrategias de razonamiento como ReAct y Chain-of-Thought, y con la integración de LLM basada en ReqLLM puede aprovechar 11 proveedores y 665 modelos
  • Jido ahora se está expandiendo como una plataforma de ecosistema de agentes, y mediante su integración con Ash Framework (ash_jido) permite la toolificación de CRUD invocable por IA

Resumen de Jido 2.0

  • Jido 2.0 es un framework de agentes basado en Elixir completado tras 18 meses de desarrollo y rediseño
    • Al principio comenzó en 2024 como una plataforma de bots llamada BotHive, y luego adoptó el runtime BEAM como base para su sistema de agentes
    • Para superar las limitaciones de los frameworks basados en TypeScript o Python, aprovecha la concurrencia y estabilidad de BEAM

Cambios de la versión 1.0 a la 2.0

  • Jido 1.0 tenía problemas de usabilidad por un exceso de abstracción, pero en la 2.0 eso mejoró con una API simplificada y una estructura centrada en BEAM
    • Incorporó comentarios de usuarios para eliminar complejidad innecesaria y minimizar la fricción al realizar tareas básicas
    • Refleja la necesidad de “quiero crear agentes, no pelearme con el framework”

Un núcleo de agentes potente y durable

  • El núcleo de Jido 2.0 es una arquitectura de agentes puramente funcional
    • Los agentes se definen como structs simples con estado (state), acciones (actions) y herramientas (tools)
    • Todo el comportamiento se procesa con la función cmd/2, que según la acción de entrada devuelve el agente actualizado y una lista de directivas
    • Los efectos secundarios se expresan como directivas y el runtime las ejecuta, lo que facilita las pruebas y la depuración
  • Jido.AgentServer envuelve a los agentes en un GenServer supervisado, y soporta enrutamiento de señales y jerarquías de agentes padre-hijo
  • Las estrategias (strategy) son puntos de extensión, y vienen dos por defecto: Direct (ejecución secuencial) y FSM (máquina de estados)
    • Estrategias de IA como ReAct y Chain-of-Thought también funcionan con la misma interfaz

Separación de módulos de acciones y señales

  • jido_action: un contrato universal de acciones que define toda la funcionalidad de los agentes
    • Incluye validación de esquemas en compilación, hooks de ciclo de vida y conversión automática al formato de herramientas de ReqLLM
    • Ofrece más de 25 herramientas preconstruidas y un planificador de flujos de trabajo basado en DAG
  • jido_signal: un sistema de mensajería basado en CloudEvents v1.0.2
    • Proporciona un formato estandarizado de señales, un router basado en tries, un bus pub/sub y 9 adaptadores de despacho
    • Puede integrarse con distintos sistemas sin protocolos no estándar

Capa de integración de Jido AI

  • jido_ai es una capa de integración que convierte llamadas a LLM en inteligencia de agentes estructurada
    • Integra 6 estrategias de razonamiento como ReAct, Chain-of-Thought, Tree-of-Thoughts, Graph-of-Thoughts, TRM y Adaptive
    • Mantiene el mismo contrato cmd/2 y el sistema de directivas, integrando la capa de IA como una extensión y no como un mundo aparte
  • Funciona sobre ReqLLM y soporta 11 proveedores y más de 665 modelos
    • Diseño streaming-first, arquitectura multi-proveedor y una comunidad con contribuciones activas

Un ecosistema en expansión

  • Jido está evolucionando más allá de un framework simple hacia un ecosistema de agentes
    • La comunidad está construyendo sobre BEAM asistentes de programación, orquestadores de workflows, agentes de investigación y sistemas de soporte operativo, entre otros
    • Están apareciendo distintos paquetes para automatización de navegador, sistemas de memoria, harnesses de evaluación e integración con MCP
  • Integración con Ash Framework (ash_jido)
    • Al agregar un bloque DSL jido a un recurso de Ash, las acciones CRUD se convierten en herramientas invocables por IA
    • Mantiene políticas de permisos, capa de datos y seguridad de tipos
    • ash_ai también está migrando a ReqLLM, avanzando la convergencia entre ambos ecosistemas

Comunidad y agradecimientos

  • Jido 2.0 fue construido sobre el ecosistema de la comunidad de Elixir
    • Se fortalece gracias a las contribuciones de librerías clave como Phoenix, LiveView, Ash, Req, Telemetry y NimbleOptions

Cómo empezar

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-03-07
Comentarios en Hacker News

  • Aún no he usado Jido de verdad, pero lo reviso al menos una vez al mes.
    Creo que BEAM encaja perfectamente con un framework de agentes, pero el ecosistema todavía es limitado, así que no he podido profundizar mucho.
    Tengo muchas expectativas por la versión 2.0. Por cierto, parece que hay un problema de escape de entidades en algunas muestras de código.

    • ¡Gracias! Lo estoy corrigiendo ahora mismo.

  • Me encanta el enfoque centrado en datos y funciones puras que se destaca desde el inicio del texto.
    A menudo se dice que el modelo de ejecución de BEAM es adecuado para la IA, pero en la práctica muchas veces se pasa por alto su robustez en situaciones como caídas de nodos o despliegues graduales.
    También existe la idea equivocada de que Elixir ofrece transparencia de ubicación, pero en realidad no es así. Si un nodo se cae, los procesos dentro de él también terminan.
    Si mantienes un estado del agente claro y puro en cada etapa de llamada a la API, puedes resolver este tipo de problemas. Basta con guardar el estado en Mnesia o Redis y retomarlo desde otro nodo. Al final, la clave es el checkpointing.

    • En mi opinión, el principio más importante de Jido es crear un agente estructuralmente correcto sin LLM antes de usar un LLM.
      Por eso el núcleo de Jido no incluye ningún soporte para LLM.
      Existe más de 40 años de investigación sobre agentes, pero con la llegada de los LLM parece que todo eso se olvidó. Por eso quise volver a estudiar esa historia e incorporarla en Jido.
      Claro que me gustan los LLM, pero ese es el papel del paquete Jido AI.

  • El momento es perfecto. Yo mismo armé un framework de agentes mezclando gen server y Oban, y fue un trabajo realmente doloroso.
    Parece que este proyecto va a reducir muchísimo ese sufrimiento de desarrollo. Muchas gracias.

    • ❤️

  • Me pregunto si esto se parece a OpenAI Symphony.
    Yo sigo más el lado de Elixir que el de la IA, así que me resulta refrescante ver a Elixir y BEAM usándose para este tipo de cargas de trabajo de orquestación.

    • Me alegra ver que OpenAI aprovecha Elixir. Symphony es un ejemplo de implementar directamente las cosas que Jido puede hacer.

  • El sitio está difícil de abrir por el pico de tráfico, así que comparto el enlace de respaldo en archive.org.

    • Siento que esto se va a quedar como mi vergüenza personal durante las próximas dos semanas… es un buen problema, pero de verdad no estaba preparado.
    • No sé si será un problema relacionado, pero la página al principio abre bien y unos segundos después se refresca a 404. Al final dejé de intentar leerla.

  • ¡Gracias por compartirlo! Definitivamente lo voy a revisar.
    Hace poco hice un paquete A2A con LLM, con una abstracción parecida a GenServer.
    Ya existían otras implementaciones de A2A, pero mi paquete tenía una semántica distinta, así que decidí publicarlo igual.
    Si a alguien le interesa, puede verlo aquí.

    • ¡Buenísimo! Ya le di star.

  • Llevo meses siguiendo este proyecto, y Elixir/BEAM es una plataforma perfecta para ejecutar agentes.
    BEAM es realmente ligero y eficiente, así que en teoría podrías correr miles de agentes en un solo servidor.
    Tengo muchas ganas de ver qué construye la gente que entienda esto.

    • El núcleo de Jido puede correr incluso en una Raspberry Pi.
      Incluso hubo intentos de desplegar BEAM en bare metal (embebido) para ejecutar agentes dentro de ese entorno.
      Siento que el futuro se va a poner muy interesante.

  • Me gustaría ver una captura de pantalla del árbol de procesos con los agentes activos en observer.
    Como referencia, observer es una herramienta para visualizar los procesos de Erlang dentro de la VM de BEAM.
    Se puede ver una captura de ejemplo en la documentación de Fly.io.

    • Pronto voy a publicar un dashboard llamado jido_studio. Visualiza la estructura de procesos.
      Se puede ver una captura teaser aquí.
      Los agentes envueltos con AgentRuntime por lo general funcionan como un único proceso GenServer, aunque hay excepciones cuando se necesita una topología más grande.

  • El momento es perfecto. Yo también estaba construyendo mi propio framework de agentes en Erlang, pero esto está mucho mejor.

  • Me pregunto cómo garantizan la seguridad. Sin aislamiento por contenedores, es difícil evitar la filtración de secretos de producción.

    • Con Signals y Plugins se pueden cifrar los datos entre agentes.
      De hecho, ya he visto casos de Jido implementados así.
      Pero esto depende del caso de uso, y la seguridad es un tema mucho más amplio que simplemente el problema de “agentes dentro de un contenedor”.
      El objetivo de Jido no es resolver la seguridad directamente, sino proporcionar herramientas para que el usuario la resuelva de la forma que necesite.