Jido is the Elixir agent framework for building long-running, autonomous, multi-agent systems on OTP and the BEAM.
Stable support. Ongoing maintenance, compatibility work, and careful API evolution.
Use the published Hex release for the stable runtime. Add companion packages only when your system needs those capabilities directly.
defp deps do
[
{:jido, "~> 2.1.0"}
]
end
Build a working Jido agent and run cmd/2 end to end.
Understand the agent contract, state model, and directive loop before scaling out.
Write deterministic tests around actions, directives, and runtime behavior.
Set error policies and recover safely in long-running agent processes.
Study the smallest runnable Jido example for state and action flow.
See a more realistic stateful workflow built on the runtime.
See how directives, signals, and AgentServer fit together operationally.
Choose when Jido is the right abstraction versus adjacent BEAM patterns.
Defines the core immutable agent contract and cmd/2 lifecycle.
OTP runtime wrapper for production execution, routing, and supervision.
DAG planning primitives for dependency-aware multi-step execution.
Composable extension mechanism for capabilities, hooks, and state.
Persistent catalog for discovering actions, agents, plugins, and sensors at runtime.
Typed effect contracts emitted by cmd/2 and executed by runtimes.
Defines the typed action contract that powers cmd/2 and directive-driven execution.
Provides the signal envelope and routing surface used for agent communication.
Adds LLM reasoning, tool use, and higher-level intelligence on top of the runtime.
Gives you live operational visibility into running agents during debugging and local ops work.
Add memory and retrieval when the runtime needs persistent context beyond in-process state.
Move from single-agent commands to workflow-style orchestration when execution graphs get more complex.
No. Jido is the runtime and agent framework. You can build deterministic agents, signals, directives, and workflows without any LLM layer, then add jido_ai later if the system needs model-driven reasoning.
GenServer gives you process primitives. Jido adds an agent contract, validated state, explicit directives, signal routing, and a cleaner separation between decision logic and side effects.
Most stacks start with jido_action and jido_signal as the core runtime companions. From there, jido_ai, jido_memory, jido_browser, and jido_live_dashboard are common additions depending on whether you need reasoning, memory, tools, or observability.
Jido (自動, Japanese for “automatic”) is the core agent framework for building autonomous, multi-agent systems in Elixir. It provides a pure functional agent architecture inspired by Elm/Redux where agents are immutable data structures updated through a single cmd/2 operation — actions transform state, directives describe side effects, and an OTP-powered runtime executes everything in production. This separation of pure decision logic from effectful execution gives developers deterministic, testable agent behavior with the full power of the BEAM underneath.
As the foundation of the Jido ecosystem, this package formalizes the patterns that raw OTP leaves ad-hoc: standardized signal envelopes replace custom message shapes, reusable actions replace business logic scattered across GenServer callbacks, typed directives replace implicit effects, and built-in parent-child hierarchies replace custom child tracking. The result is a production-grade framework for building single agents, cooperating multi-agent workflows, and autonomous systems that can be reasoned about, tested without processes, and deployed with confidence.
Jido is the core package of the Jido ecosystem. It defines the Agent behaviour, the cmd/2 contract, the directive system, execution strategies, the plugin architecture, the OTP runtime (AgentServer), and all supporting infrastructure (persistence, observability, scheduling, discovery). Every other package in the ecosystem — jido_action, jido_signal, jido_ai — extends or builds upon the primitives defined here.
Jido.Agent)
The central abstraction. Agents are immutable structs with schema-validated state, updated exclusively through the cmd/2 function. Accepts actions as modules, {Module, params} tuples, %Instruction{} structs, or lists of any of these. Returns {updated_agent, directives} — the agent is always fully updated and directives are external effect descriptions only. Supports lifecycle hooks (on_before_cmd/2, on_after_cmd/3).
Jido.AgentServer)
GenServer-based OTP runtime that wraps an Agent for production deployment. Owns signal routing, executes directives through a non-blocking internal queue with drain loop, manages parent-child agent hierarchies with lifecycle monitoring, and provides sync (call/3) and async (cast/2) signal processing.
Jido.Agent.Strategy)
Pluggable execution strategies that control how cmd/2 processes actions:
Jido.Plugin)Composable capability modules that extend agents with reusable functionality. Each plugin encapsulates actions, schema-validated state, configuration, signal routing rules, lifecycle hooks, optional child processes, and cron schedules.
Jido.Agent.Directive)
Typed effect descriptions emitted by cmd/2 for the runtime to execute: Emit, Error, Spawn, SpawnAgent, StopChild, Schedule, Stop, Cron/CronCancel.
Jido.Sensor)
Pure behaviour modules that transform external events into Jido Signals. Stateless with init/2 and handle_event/2 callbacks.
Jido.Thread)Append-only log of interaction entries — the canonical record of “what happened” in a conversation or workflow.
Jido.Memory)An agent’s mutable cognitive substrate organized as named spaces (world, tasks, custom).
Jido.Persist, Jido.Storage)Hibernate/thaw lifecycle for agents with thread support and storage adapter behaviour.
Jido.Observe, Jido.Telemetry)
Unified observability façade wrapping :telemetry events with span-based tracing.
Jido.Discovery)
Fast, persistent catalog of Jido components using :persistent_term.