This is Part 1 of a 5-part documentary series following the development of JidoBuilder, a visual management console for the Jido autonomous agent framework. Built on Elixir and the BEAM VM, this project tells the story of what happens when you pair a powerful open-source framework with an AI-assisted development team racing toward open-source release.
Where It All Started
Before there was JidoBuilder, there was Jido.
Mike Hostetler is a veteran technologist whose career spans the formative years of the modern web. He was a jQuery Core Team member from 2006 to 2012, co-authored the jQuery Cookbook published by O'Reilly, co-founded appendTo (known as "the jQuery Company"), and has shipped responsive redesigns for brands like Time.com and Celebrity Cruises. He holds credentials from Northwestern's Kellogg School of Management and is a member of the Forbes Technology Council. He spoke at O'Reilly's Fluent Conference and has contributed to Drupal, Node.js, and the broader JavaScript ecosystem for decades.
So when Mike turned his attention to Elixir and the BEAM virtual machine, it was not a casual detour. It was a deliberate architectural decision.
The result was Jido — from the Japanese word meaning "automatic" or "self-moving." An autonomous agent framework for Elixir, purpose-built for multi-agent systems on the BEAM.
You can read about the full evolution in Mike's own words on the Jido blog, and hear him discuss the framework on Beam Radio Episode 94, the Thinking Elixir Podcast (Episode 287), and the Elixir Mentor Podcast.
Why the BEAM?
For developers unfamiliar with Elixir: the BEAM (Erlang's virtual machine) is the runtime that powers WhatsApp, Discord, and telecom systems that demand extreme uptime. It provides:
- Lightweight processes — each Jido agent uses roughly 25KB of memory at rest
- Fault isolation — one crashing agent cannot bring down another
- Preemptive scheduling — 10,000 agents get fair CPU time without any one starving the others
- Hot code upgrades — update agent logic without restarting the system
- Distribution — agents can span multiple nodes out of the box
Mike demonstrated this dramatically: 1,575 agents indexing a codebase in 7 seconds, and benchmarks showing 10,000 concurrent agents running on commodity hardware. These are not theoretical numbers. They come from a framework with ~1,600 GitHub stars that is published on Hex (Elixir's package manager) and actively maintained.
The core architecture centers on the cmd/2 contract — agents receive actions and return updated state plus typed directives. This separates state changes (pure functional transformations) from side effects (explicit, testable directives). If you know Elm or Redux, you know the pattern. If you know OTP, you know the runtime.
Enter JidoBuilder
Jido is a developer SDK. It is powerful, but it requires writing Elixir code. The question became: what if you could operate autonomous agents without writing code?
That question became JidoBuilder — a Phoenix LiveView application that wraps the Jido SDK in a visual management console. The goal: let developers configure, deploy, and monitor multi-agent systems through a browser. Let non-technical operators hire agents from templates, dispatch signals, and observe execution traces without touching a terminal.
This is not a toy. The current build includes:
- 41 interactive pages across agent management, workflow design, observability, and system configuration
- 75+ registered actions covering HTTP requests, JSON transforms, webhooks, Slack notifications, email, LLM chat, and more
- An agentic LLM chat system with recursive tool-use loops, conversation persistence, and Active Inference reasoning
- A full REST API with OpenAPI 3.0.3 spec generation
- An MCP server (Model Context Protocol) enabling AI assistants to operate the system programmatically
- Code export — generate standalone Elixir projects from builder configurations
- 273 passing tests across 158 test files in a 5-app Elixir umbrella
The Team Review: Who Built This?
Here is where the story gets interesting. JidoBuilder was built with the assistance of an AI development team — 14 specialized personas working through a structured agile methodology. Each persona has a defined role, voice, and area of expertise. Here is what some of them had to say looking back at the genesis phase:
Archi Tect — Principal Solution Architect
"The decision to build JidoBuilder as a Phoenix umbrella app with five distinct applications was not arbitrary. We needed hard boundaries between the core domain logic, the runtime agent lifecycle, the web presentation layer, code generation, and test infrastructure. Elixir umbrella apps give you that separation at the compilation level — not just folder conventions. Each app has its own supervision tree, its own dependencies, its own test suite. When the runtime crashes during development, the web layer stays up. That is OTP doing what OTP does."
Owen Pro — Product Owner
"The value proposition was clear from day one: Jido is brilliant for developers who think in processes and message-passing. But the market of people who can write Elixir GenServers is small. The market of people who need to manage autonomous agents is growing exponentially. JidoBuilder bridges that gap. We are not dumbing down Jido — we are making it accessible."
Tess Ter — QA Engineer
"273 tests across 158 files in a system built in compressed time. Every LiveView page has mount and render tests. Every API endpoint has authentication and validation coverage. Every MCP tool responds to
action: help. We did not ship a demo — we shipped something with a test suite that would survive a production deployment."
Des Igner — UX/UI Designer
"The challenge was making 41 pages feel cohesive when they cover everything from agent hiring wizards to workflow DAG builders to observability dashboards. We chose a consistent sidebar navigation pattern, dark-on-light color scheme with Tailwind CSS, and a developer/business mode toggle that lets the same page surface different levels of detail. The command palette (Cmd+K) was critical — power users should never need to click through menus."
What Jido Gives You That Others Don't
For the Elixir developer evaluating agent frameworks, here is what distinguishes Jido from the TypeScript and Python alternatives:
- Immutable agents — agents are pure data structures, making every decision unit-testable without touching a network, database, or LLM
- 25KB memory footprint — run thousands of agents on a single node
- OTP supervision — crashed agents restart automatically with configurable strategies
-
CloudEvents-based signals —
jido_signalimplements CloudEvents v1.0.2 with nine dispatch adapters -
Modular ecosystem —
jido_action(25+ pre-built tools),jido_signal,jido_ai(six reasoning strategies including ReAct), andash_jido(Ash Framework integration) - Serialize and hibernate — agents can persist to disk for long-lived access patterns
The companion library ReqLLM provides a unified interface for calling multiple LLM providers (OpenAI, Anthropic, Google) in Elixir — another Hostetler project that solves a real pain point.
Retrospective: What We Learned in Genesis
Every sprint ends with honest reflection. Here is ours:
What went well:
- The umbrella app architecture proved correct from day one. No refactoring was needed at the boundary level.
- Phoenix LiveView eliminated the need for a separate frontend framework. Real-time updates come from the server, not a JavaScript build pipeline.
- SQLite as the persistence layer was a bold call that paid off. Single-file database, zero ops overhead, production-grade for single-node deployments.
What was harder than expected:
- The JavaScript hooks layer (sidebar collapse, drag-drop workflows, notebook bindings) required careful coordination between LiveView's server-rendered DOM and client-side state. This is the edge where Phoenix LiveView shows its complexity.
- LLM provider abstractions needed more iteration than anticipated. Each provider has different token counting, streaming behavior, and error formats. Mike's ReqLLM library was the right foundation, but the builder needed its own conversation persistence layer on top.
What we would do differently:
- Start with the MCP server earlier. It ended up being one of the most powerful features — AI assistants can operate JidoBuilder programmatically — but it was planned for Phase 3. If we had it from Phase 1, the AI team itself could have used it during development.
Coming Up in Part 2: The Architecture
In the next installment, we go deep into the technical architecture. How does a 5-app Elixir umbrella work in practice? What does the signal dispatch pipeline look like? How do workflow DAGs get topologically sorted and executed? And what does Active Inference — the neuroscience-inspired reasoning framework — look like when implemented in Elixir pattern matching?
The backend team (Api Endor, Query Quinn, and Pip Line) will walk through the systems they built, with real code examples from the JidoBuilder codebase.
JidoBuilder is approaching open-source release. Follow this series for the full story of what it took to get there.
Jido is created by Mike Hostetler. Learn more at jido.run and explore the source on GitHub.
Built with the assistance of ORCHESTRATE — agile project management for AI-assisted development teams.
Top comments (0)