Most software engineers treat crashes as problems to solve. Mike Hostetler built an entire framework around the idea that they're inevitable—and that's fine, actually, as long as the system knows how to recover.
His open-source project, Jido, takes a contrarian approach to AI agent development. While Python-based frameworks have dominated the agent ecosystem with their vast libraries and rapid prototyping advantages, Hostetler bet on something older and far less fashionable: Elixir's BEAM virtual machine, the same technology that's kept telephone switches running for three decades without going down.
The framework's 2.0 release on February 22, 2026 sparked an immediate—if niche—conversation among developers. A post on Hacker News drew 271 upvotes and 57 comments, with much of the discussion centered on a technical question that might sound arcane to outsiders: how does BEAM's supervision model actually translate to AI agent workloads?
The timing carried its own peculiar validation. OpenAI released Symphony, another Elixir-based agent framework, on March 5, 2026. Hostetler, commenting in the HN thread, seemed almost amused by the coincidence. "Symphony is a direct implementation of the types of things Jido can do!" he wrote—a statement that could be read as either generous acknowledgment or quiet confidence, depending on your perspective.
Rethinking How Agents Live and Die
The centerpiece of version 2.0 is what Hostetler calls instance-scoped supervisors. Earlier iterations relied on global singletons—a single overseer watching everything. Now each agent gets its own set of watchers: a Registry, a TaskSupervisor, an AgentSupervisor.
It's a more complex setup, requiring developers to explicitly wire {Jido, name: MyApp.Jido} into their supervision tree. But the payoff is precise control over which parts of your system can fail independently. A parent agent can restart a misbehaving child without dragging down unrelated processes—the kind of fault isolation that telecom engineers spent years perfecting and that most web frameworks still struggle with.
The framework exposes this through lifecycle functions with names that sound almost boring in their practicality: Jido.start_agent/3, Jido.stop_agent/2, Jido.whereis/2, Jido.list_agents/1. These treat agents as first-class supervised processes, which in BEAM terminology means they're entities the runtime actually knows how to babysit.
Data First, Effects Later
Where Jido diverges sharply from frameworks like LangGraph or CrewAI is in its core philosophy. "Agents are data," the documentation insists. An agent is a struct—a simple data container—holding state, actions, and tools. The entire runtime pivots on a single cmd/2 function that takes an agent and a command, then hands back an updated agent plus directives describing what side effects should happen.
This functional purity has practical consequences for testing. You don't need to mock LLM API calls or spin up databases to verify agent logic. Pass in deterministic inputs, assert on the returned directives, and you're done. No network required. The Jido.AgentServer GenServer wrapper deals with the messy effectful runtime concerns separately, keeping the boundaries clean.
Directives include instructions like Emit, Spawn, SpawnAgent, StopChild, Schedule, and Stop, plus StateOps for internal transitions. Multi-agent coordination relies on Jido.await/3 and await_child/4 to synchronize completion across process boundaries—plumbing that matters more than you'd think when agents start multiplying.
AI as Optional, Not Foundational
The core package ships with two decidedly non-AI strategies: Direct (which just executes actions sequentially) and FSM (finite-state machines with transition guards). All the AI capabilities live in a separate jido_ai package, offering six reasoning strategies: ReAct, Chain-of-Thought, Tree-of-Thoughts, Graph-of-Thoughts, TRM, and Adaptive.
LLM integration runs through ReqLLM, an Elixir client that supports over 665 models across 11 providers in its latest version. The architectural separation is deliberate. You can use Jido's supervision model and action system without touching AI workloads at all—or you can mix deterministic and LLM-driven agents in the same supervision tree, depending on what each piece of your application actually needs.
It's an acknowledgment, perhaps, that not every problem requires a language model. Sometimes you just need a reliable state machine that won't mysteriously vanish when someone's API rate limit hits.
An Ecosystem in Formation
The broader Jido ecosystem has grown beyond the core package. The jido_action package defines a universal, typed Action contract, bundling 25+ pre-built tools, a DAG-based workflow planner, and Model Context Protocol (MCP) integration that auto-converts tools to ReqLLM's expected format.
Documentation on HexDocs points to specific implementations like Jido.Tools.Github.Pulls for GitHub API operations. Supporting packages fill out production needs: jido_browser for web automation, jido_memory for agent persistence, ash_jido for bridging Ash Framework resources to Jido tools at compile time, and jido_messaging for Telegram, Discord, Slack, and WhatsApp integrations.
There's also jido_signal, described as a CloudEvents v1.0.2 message envelope with trie-based routing and a pub/sub bus featuring history replay—the kind of infrastructure that suggests someone has thought hard about how agents communicate in production. Nine dispatch adapters round out the messaging layer. An upcoming jido_studio LiveView dashboard promises visual operational control, though release timing remains unspecified.
Installation: One Command (Mostly)
Hostetler leaned on Igniter, an Elixir scaffolding tool, to streamline the setup experience. Running mix igniter.install jido handles dependencies, configuration, and supervision tree entries automatically. Manual installation requires adding {:jido, "~> 2.0"} and {:jido_ai, "~> 2.0"} to your mix.exs file.
The framework requires Elixir 1.17+ and Erlang/OTP 26+—versions that assume you're keeping your stack reasonably current. Core documentation lives at jido.run, with a Get Started guide, conceptual explanations, and an interactive examples gallery ranging from basic counter agents to AI research workflows and production persistence patterns.
Skepticism and Scale Questions
The Hacker News discussion surfaced the kinds of questions developers actually care about—practical concerns about robustness and operational boundaries. How does Jido handle distributed agent coordination? Does the supervision model scale to thousands of concurrent agents?
An earlier post from December 30, 2024 claimed "10k agents at 25KB each," though current benchmarks haven't appeared alongside the 2.0 release. That gap between assertion and proof is the sort of thing that makes engineers cautious, and rightly so.
On Reddit's r/elixir community, developers congratulated Hostetler and requested comparisons to Python frameworks. The project has accumulated 1,200 stars on GitHub and recorded 19,621 all-time downloads on Hex.pm, with 1,138 downloads in the week following the release—respectable numbers for an Elixir library, if hardly viral by Python standards.
The Python Comparison, Inevitable
Jido's documentation includes side-by-side comparisons with LangGraph, CrewAI, and Mastra. Against LangGraph, the key difference is fault handling: OTP supervisors restart crashed agents automatically, whereas LangGraph leans on checkpoint and replay mechanisms. Observability in Jido uses Telemetry events and LiveDashboard; LangGraph teams typically reach for LangSmith.
The CrewAI comparison focuses on architectural philosophy—role-based multi-agent orchestration in Python versus OTP process hierarchies in Elixir. Both offer tool catalogs and human-in-the-loop capabilities, but Jido's durability is BEAM-native rather than requiring external infrastructure bolted on.
Mastra, built on TypeScript, provides batteries-included studio tooling and observability out of the box. Jido counters with OTP-first durability but acknowledges—refreshingly—that Node.js has a larger AI tooling ecosystem. The framework positions itself for teams already invested in Elixir or those prioritizing fault tolerance over ecosystem breadth.
That's probably the right framing. Elixir's community is small compared to Python's, and no amount of technical elegance changes that market reality.
An Unexpected Endorsement
The OpenAI Symphony release provided something money can't buy: validation that BEAM's architecture might actually matter for agent orchestration. For a community used to watching Python dominate AI discussions, having OpenAI choose Elixir carried weight beyond the technical merits. Hostetler's Chicago-based project remains open source under an Apache-2.0 license, with no disclosed funding or commercial entity behind it.
The framework's value proposition is straightforward, if niche: if you're building agents that need to run reliably over days or weeks—handling failures, spawning children, coordinating across processes—the BEAM's three decades of production hardening might matter more than Python's ecosystem advantage. Whether that's compelling enough to overcome the gravitational pull of LangChain and its vast orbit of tooling remains an open question.
But for engineers who've been bitten by mysterious process crashes at 3 AM, the pitch probably sounds less theoretical than practical.
