agentjido/jido

Jido is an Elixir-based framework for building and managing multi-agent systems, featuring an instance-scoped architecture that isolates agent pools and their states. It provides a comprehensive runtime for agent lifecycle management, including durable persistence via pluggable storage adapters, in-memory cognitive substrates, and hierarchical parent-child relationships. The system supports complex orchestration through signal routing, cron scheduling, and mutable pod topologies, while offering extensive observability and testing infrastructure for reliable development.

17 changes.

The project underwent a major architectural overhaul to version 2.0, replacing global state with an instance-scoped model and refactoring legacy workflow modules into a new action-based system. This release introduced unified persistence, observability, and scheduling infrastructure while establishing formal project governance through Apache 2.0 licensing and comprehensive documentation. Extensive test suites were added to validate the new runtime components and ensure reliability across the updated framework.

29 changes.

This period focused on rebuilding the Jido framework's core architecture to support complex, multi-agent systems with robust lifecycle management, hierarchical spawning, and durable state persistence. Significant work included introducing a new directive execution protocol, a pluggable storage backend system, and a mutable pod topology engine, all accompanied by comprehensive test coverage and developer tooling via Igniter generators.

The Jido Igniter now includes internal helper functions and template generators for creating Agent, Plugin, and Sensor modules. These new files provide the scaffolding logic used by mix tasks to generate code, including specific templates for the corresponding test modules and utility functions for name derivation and list parsing.

lib/jido/igniter · high confidence

The Jido framework has been updated to version 2.0, introducing a new \Jido.AgentServer\ GenServer that manages agent lifecycle, signal routing, and directive execution. This release adds a unified persistence layer via \Jido.Persist\ and \Jido.Storage\, enabling agents to hibernate and thaw their state and thread journals. A new \Jido.Memory\ module provides a mutable cognitive substrate for agents, complementing the existing thread and strategy systems. Observability is enhanced with \Jido.Observe\, which provides correlation tracing and telemetry integration, and \Jido.Debug\ allows per-instance debug mode control. The framework also introduces \Jido.Await\ for synchronous agent coordination and \Jido.Discovery\ for component cataloging.

lib/jido · high confidence

Agents now include a default memory plugin registered under the \:\_\memory\\\ key, storing state in-process without automatic persistence. This change introduces a structured memory model using named 'spaces' (key-value maps or ordered lists) that track revisions for concurrency control. Developers can manage this memory via the \Jido.Memory.Agent\ helper or replace the default in-process implementation with a custom plugin by overriding the \:\\memory\\_\ default-plugin slot.

lib/jido/memory · high confidence

Added a new \Jido.AgentServer.State.Lifecycle\ module that defines the state schema and initialization logic for agents managed by the instance manager. This state tracks attachment details, idle timeouts, and storage configuration, providing the foundational data structure for managing the lifecycle of pooled agents.

_lib/jido/agent\server/state · high confidence

Agents can now define a pod topology—a graph of named nodes with dependencies—and mutate it at runtime. This change adds the \Jido.Pod\ subsystem, including a \Topology\ data structure, a \Plugin\ that reserves the \:\_\pod\\_\ state slice, and a \Mutable\ API that enforces mutation locks to prevent concurrent changes. Users can add or remove nodes via the \pod\_mutate\ action, which triggers a \Planner\ to generate a \Plan\ (calculating start/stop waves) and a \Runtime\ to execute the topology changes, reporting the results back to the agent state.

lib/jido/pod · high confidence

The \lib/jido/observe\ module now provides a centralized configuration system that resolves observability settings (such as telemetry log levels, argument logging modes, and slow-signal thresholds) with a specific priority order: runtime debug overrides take precedence over per-instance application configs, which override global defaults. This enables users to fine-tune logging and telemetry on a per-instance basis. Additionally, the module introduces a \Tracer\ behaviour that allows integration with external distributed tracing systems (like OpenTelemetry) via a pluggable backend, defaulting to a no-op implementation, and includes an event contract validation helper to ensure telemetry metadata and measurements adhere to required schemas.

lib/jido/observe · high confidence

Added \Jido.Sensor.Runtime\ and \Jido.Sensor.Spec\ to manage sensor lifecycle and configuration. The runtime acts as a GenServer that validates sensor configuration, handles timer-based event scheduling, and delivers signals to agents via PIDs or the signal dispatch system, while also monitoring an optional owner process to ensure clean shutdown. The spec module provides a normalized, schema-validated representation of sensor metadata (module, name, config) using Zoi for introspection and validation.

lib/jido/sensor · high confidence

Adds a new thread subsystem that manages conversation history within agent state and persists it via pluggable storage adapters. The \Jido.Thread.Plugin\ registers a singleton \:\_\thread\\_\ key in agent state, while \Jido.Thread.Agent\ provides helpers to ensure, append, and retrieve threads. Entries are normalized through \Jido.Thread.EntryNormalizer\ to enforce consistent defaults and sequence numbering before being stored. Persistence is handled by \Jido.Thread.Store\, which supports an in-memory adapter for development and a journal-backed adapter that serializes entries as signals for durable storage.

lib/jido/thread · high confidence

Jido now includes three new storage backends for persisting agent checkpoints and thread journals. The ETS adapter provides fast, in-memory storage suitable for development and testing, featuring optimistic concurrency control via \expected\_rev\ and atomic append operations. The File adapter offers durable, directory-based persistence with atomic writes and thread-level locking for concurrent safety. The Redis adapter enables distributed, durable storage by delegating commands to a caller-provided function, supporting key prefixes and optional TTLs. All three adapters implement the \Jido.Storage\ behaviour, allowing users to select the appropriate persistence layer based on their deployment needs.

lib/jido/storage · high confidence

The \lib/mix/tasks\ directory now provides a suite of Igniter-powered tasks for setting up and scaffolding Jido components. The \jido.install\ task automates project configuration by adding Jido settings to \config/config.exs\, creating the main Jido instance module, optionally wiring it into the supervision tree, and generating an example agent. Additionally, new generator tasks allow developers to scaffold specific Jido artifacts: \jido.gen.agent\ creates agent modules with optional plugin attachments, \jido.gen.plugin\ generates plugin modules with configurable signal patterns, and \jido.gen.sensor\ produces sensor modules with customizable polling intervals. Each generator also creates corresponding test files, streamlining the development of new Jido capabilities.

lib/mix/tasks · high confidence

This change introduces the core structural components for the new agent runtime in lib/jido/agent. It adds a DefaultPlugins system that manages framework-provided singleton plugins (Thread, Identity, Memory) with instance- and agent-level override capabilities. It introduces a comprehensive Directive system (Emit, Spawn, Cron, etc.) that allows agents to declare external effects for the runtime to execute, separating strategy logic from side effects. A new Identity module and plugin manage agent lifecycle facts (age, origin) with migration support for legacy checkpoints. Additionally, an InstanceManager provides keyed singleton agent lifecycle management with optional storage-backed hibernation, and a Cron directive enables durable, agent-owned scheduled tasks.

lib/jido/agent · high confidence

Added a comprehensive set of new documentation guides covering the Jido framework's core concepts and usage patterns. These include guides for Actions, Agents, the Core Loop, Directives, Await & Coordination, Configuration & Deployment, Custom Strategies, Debugging, Error Handling, Discovery & Introspection, and Ash Framework Integration. The documentation provides code examples and explanations for implementing agents, handling state, managing directives, coordinating async agents, configuring instances, and integrating with external systems like Ash.

guides · high confidence

A new \Jido.Scheduler.Job\ module has been introduced to provide a durable, in-house cron scheduling capability. This component manages scheduled tasks by parsing cron expressions, handling time zones via \TimeZoneInfo\, and running callbacks as separate worker processes. It includes logic to preserve normal owner shutdown reasons and supports retry schedules, forming the core scheduling engine for the upcoming Jido 2.1 release.

lib/jido/scheduler · high confidence

The project now officially uses the Apache License, Version 2.0, replacing previous licensing terms. To support development standards, a new \AGENTS.md\ guide defines the framework's architectural intent, runtime baseline, and coding conventions, while \CONTRIBUTING.md\ provides a comprehensive guide for contributors covering setup, code organization, and quality checks. Additionally, a \.doctor.exs\ configuration file has been added to enforce 100% documentation and spec coverage, with specific exclusions for macro-generated modules.

(repo-wide) · high confidence

The \jido.chat\_room\ Mix task, which previously allowed users to start a chat room instance via the command line with options for name and strategy, has been removed from the codebase.

lib/mix/tasks/jido · high confidence

The \Jido.Workflow.Chain\, \Jido.Workflow.Closure\, and \Jido.Workflow.Tool\ modules have been removed from the \lib/jido/workflow\ directory. This eliminates the previous capabilities for chaining multiple workflows sequentially with interruption support, creating closures for partial application of context and options, and converting workflows into standardized tool representations for AI systems like LangChain. Users relying on these specific workflow orchestration and integration patterns will need to adopt the refactored 'action' terminology and structure.

lib/jido/workflow · high confidence

The AgentServer implementation has been significantly restructured to support a more robust, extensible, and observable agent lifecycle. This change introduces a new directive execution protocol (DirectiveExec) that allows custom directive types to be handled without modifying core code, including specific executors for Emit, Error, RunInstruction, Spawn, and Schedule directives. A new error policy system enables configurable error handling strategies such as logging, stopping on error, emitting error signals, or enforcing a maximum error count. The server now supports a hierarchical agent model with explicit parent-child relationships tracked via ParentRef and ChildInfo, allowing for sensor lifecycle management and child agent spawning. Additionally, the update adds a durable cron scheduler for time-based job execution, a unified signal router that aggregates routes from strategies, agents, and plugins with priority levels, and a comprehensive status API for querying agent state and progress. These changes collectively provide a more stable and feature-rich foundation for building complex, multi-agent systems.

_lib/jido/agent\server · high confidence

A new \Jido.Config.Defaults\ module has been introduced to centralize default values for runtime behavior and observability settings. This change consolidates configuration such as telemetry log levels, tracer modules, timeout durations for agent servers and worker pools, and debug event modes into a single source of truth. This ensures consistency across API wrappers and runtime modules, preventing configuration drift and simplifying how default behaviors are managed.

lib/jido/config · high confidence

The application now includes a new \config/config.exs\ that configures Jido to use \TimeZoneInfo\ for time zone data and sets up structured logging metadata (such as agent IDs, trace IDs, and durations) for telemetry. It also enables \git\_hooks\ and \git\_ops\ for conventional commit validation and release management in the development environment. Additionally, a new \config/test.exs\ ensures clean test output by disabling the default console logger handler while allowing verbose debugging via the \LOG\_LEVEL\ environment variable.

config · high confidence

The Jido framework has been updated to version 2.0, introducing an instance-scoped architecture where users must now create a dedicated Jido supervisor module (via \use Jido, otp\_app: :my\_app\) to manage agents. This change replaces the previous global state model, allowing for isolated agent pools, configurable storage backends (defaulting to ETS), and default plugin resolution per instance. The main \Jido\ module now acts as a supervisor, providing instance-specific APIs for starting, stopping, and listing agents, while the legacy \Demo\ module has been removed.

lib · high confidence

The \lib/jido/actions\ directory has been reorganized to introduce a new set of base actions for core agent behaviors. New modules \Jido.Actions.Control\ (handling cancellation, signal forwarding, and broadcasting), \Jido.Actions.Lifecycle\ (managing parent-child communication, spawning, and termination), \Jido.Actions.Scheduling\ (supporting delayed signals, timeouts, and cron jobs), and \Jido.Actions.Status\ (tracking agent states like idle, working, completed, and failed) are now available. These replace the previous generic action modules (\Arithmetic\, \Basic\, \Files\, \Simplebot\), which have been removed from this location, shifting the focus to foundational agent orchestration patterns.

lib/jido/actions · high confidence

The plugin architecture has been restructured to allow multiple instances of the same plugin within a single agent, distinguished by optional aliases (the \as:\ option). This change introduces a new \Jido.Plugin.Instance\ module that manages per-instance state keys and route prefixes, ensuring that aliased instances do not conflict. Configuration resolution is now centralized in \Jido.Plugin.Config\, which merges application environment settings with per-agent overrides and validates them against a plugin's \config\_schema\ using Zoi. Additionally, \Jido.Plugin.Requirements\ enforces compile-time checks for declared dependencies (config keys, OTP apps, or other plugins), and \Jido.Plugin.Routes\ and \Jido.Plugin.Schedules\ handle the expansion and conflict detection of signal routes and cron jobs, ensuring that multiple instances of the same plugin can coexist with unique, namespaced identifiers.

lib/jido/plugin · high confidence

Added comprehensive test coverage for the Jido plugin system; Added comprehensive test coverage for thread management and agent integration; Added example tests for agent basics, observability, and tracing; Added example tests for agent persistence and checkpoint strategies; Added example tests for plugin configuration and lifecycle; Added example tests for runtime capabilities; Added example tests for signal routing and emission patterns; Added example tests for the FSM strategy; Added integration tests for agent persistence and scheduler durability; Added test coverage for ETS, File, and Redis storage adapters; Added test coverage for Jido action modules; Added test coverage for observability configuration, event contracts, and tracing behavior; Added test coverage for pod mutation, runtime, topology, and telemetry; Added test coverage for the Jido memory subsystem; Added tests for Cron and CronCancel agent directives; Added tests for Igniter template generation; Added tests for the new sensor runtime and metadata system; Expanded test coverage for AgentServer lifecycle, directives, and hierarchy; Expanded test coverage for Jido core components; Expanded test coverage for agent core, identity, and scheduling; New test infrastructure and shared test utilities for Jido; Removed legacy workflow test suite; Updated test infrastructure and configuration.

This release bumps the project version to 2.3.3 and upgrades the minimum Elixir requirement to 1.18. It includes a comprehensive update of development and runtime dependencies, notably upgrading \ex\_doc\ to 0.40.4, \credo\ to 1.7.19, \dialyxir\ to 1.4.8, \igniter\ to 0.8.4, and \req\ to 0.7.4. The project configuration now explicitly registers \Jido.Application\ as the application module, adds \:crypto\ to extra applications, and configures \ExCoveralls\ for test coverage reporting with an 80% threshold. Documentation structure has been reorganized into logical groups (Start Here, Fundamentals, Coordination, etc.) with new guides for topics like multi-tenancy, scheduling, and migration from 1.x.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 65 → 66 (+1.5)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 91 → 95 (+4.4)
• Architecture 79 → 87 (+7.8)
• Maturity 72 → 75 (+3.8)
• Readiness 57 → 72 (+15.6)
• Security 67 → 54 (-13.1)

• Change coupling: config.exs ↔ mix.exs (config/config.exs)
• Change coupling: direct.ex ↔ fsm.ex (lib/jido/agent/strategy/direct.ex)
• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• Duplicated block (11 lines × 2) (lib/jido/agent_server.ex)
• Duplicated block (11 lines × 2) (lib/jido/await.ex)
• Duplicated block (11 lines × 2) (lib/jido/pod/runtime.ex)
• Duplicated block (11 lines × 3) (lib/jido/agent_server.ex)
• Duplicated block (12 lines × 2) (lib/jido/pod/mutation/planner.ex)
• Duplicated block (18 lines × 3) (lib/jido/agent_server.ex)
• Duplicated block (7 lines × 2) (lib/jido/pod/mutation/planner.ex)
• Duplicated block (8 lines × 2) (lib/jido/agent/strategy/fsm.ex)
• Duplicated block (8 lines × 2) (lib/jido/pod/runtime.ex)
• Duplicated block (9 lines × 2) (lib/jido/await.ex)
• Duplicated block (9 lines × 2) (lib/jido/pod/mutation/planner.ex)
• Duplicated block (9 lines × 2) (lib/jido/pod/runtime.ex)
• Duplicated block (9 lines × 2) (lib/jido/pod/runtime.ex)
• FileTooLong: agent/directive.ex (lib/jido/agent/directive.ex)
• FileTooLong: jido/observe.ex (lib/jido/observe.ex)
• FileTooLong: jido/plugin.ex (lib/jido/plugin.ex)
• …and 8 more

• Duplicated block (10 lines × 2) (lib/jido/pod/runtime.ex)
• Duplicated block (10 lines × 2) (lib/jido/pod/runtime.ex)
• Duplicated block (11–18 lines × 2) (lib/jido/agent_server.ex)
• Duplicated block (13 lines × 3) (lib/jido/agent_server.ex)
• Duplicated block (14 lines × 2) (lib/jido/await.ex)
• Duplicated block (16 lines × 2) (lib/jido/await.ex)
• Duplicated block (16 lines × 2) (lib/jido/pod/mutation/planner.ex)
• Duplicated block (19 lines × 2) (lib/jido/pod/mutation/planner.ex)
• Duplicated block (19 lines × 3) (lib/jido/agent_server.ex)
• Duplicated block (21 lines × 2) (lib/jido/agent_server.ex)
• Duplicated block (22 lines × 4) (lib/jido/agent_server/child_info.ex)
• Duplicated block (7 lines × 2) (lib/jido/agent/instance_manager.ex)
• Duplicated block (7 lines × 2) (lib/jido/pod/mutation/planner.ex)
• Duplicated block (8 lines × 2) (lib/jido/agent/strategy/fsm.ex)
• Duplicated block (9 lines × 2) (lib/jido/pod/mutation/planner.ex)
• Duplicated block (9 lines × 2) (lib/jido/pod/runtime.ex)
• Duplicated block (9 lines × 2) (lib/jido/pod/runtime.ex)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• …and 200 more

• 18 commits — 15 feature/other, 3 fixes

• (root) — 12 commits
• lib/jido — 5 commits
• .github/workflows — 1 commit

• fix: fix(deps): update mint for security advisory
• fix: fix(error): preserve validation paths in transport (#336)
• fix: fix(lifecycle): preserve normal owner shutdown reasons (#367)
• change: chore(deps): require jido_signal 2.3 (#365)
• change: chore(deps): update Mix dependencies
• change: chore(deps): update approved dependencies (#326)
• change: chore(deps): update dependencies
• change: chore(deps): update git_ops to 2.12.1 (#322)
• change: chore(deps): update igniter to 0.8.4
• change: chore(deps): update jido_action and req (#320)
• change: chore: release version v2.3.3
• change: chore: remove legacy work tracker
• change: ci: migrate Linux jobs to Blacksmith runners (#328)
• change: deps(deps): bump telemetry_metrics from 1.1.0 to 1.2.0 (#334)
• change: deps(deps-dev): bump ex_doc from 0.40.3 to 0.40.4 (#364)
• change: docs: fix signal routing guide examples
• change: feat(agent): enforce optional state size budgets
• change: test(storage): introduce reusable adapter conformance suites (#323)

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

agentjido/jido was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.