[HN Gopher] Show HN: Jido 2.0, Elixir Agent Framework
___________________________________________________________________
Show HN: Jido 2.0, Elixir Agent Framework
Hi HN! I'm the author of an Elixir Agent Framework called Jido. We
reached our 2.0 release this week, shipping a production-hardened
framework to build, manage and run Agents on the BEAM. Jido now
supports a host of Agentic features, including: - Tool Calling and
Agent Skills - Comprehensive multi-agent support across distributed
BEAM processes with Supervision - Multiple reasoning strategies
including ReAct, Chain of Thought, Tree of Thought, and more -
Advanced workflow capabilities - Durability through a robust
Storage and Persistence layer - Agentic Memory - MCP and Sensors to
interface with external services - Deep observability and debugging
capabilities, including full stack OTel I know Agent Frameworks
can be considered a bit stale, but there hasn't been a major
release of a framework on the BEAM. With a growing realization that
the architecture of the BEAM is a good match for Agentic workloads,
the time was right to make the announcement. My background is
enterprise engineering, distributed systems and Open Source. We've
got a strong and growing community of builders committed to the
Jido ecosystem. We're looking forward to what gets built on top of
Jido! Come build agents with us!
Author : mikehostetler
Score : 218 points
Date : 2026-03-05 15:48 UTC (7 hours ago)
(HTM) web link (jido.run)
(TXT) w3m dump (jido.run)
| davidw wrote:
| It'd be cool to see a screenshot of what 'observer' shows as the
| process tree with a few agents active.
|
| Edit: for those not familiar with the BEAM ecosystem, observer
| shows all the running Erlang 'processes' (internal to the VM).
| Here are some examples screenshots on one of the first Google
| hits I found:
|
| https://fly.io/docs/elixir/advanced-guides/connect-observer-...
| mikehostetler wrote:
| We have a full dashboard called `jido_studio` that will be
| available soon that helps visualize it.
|
| Teaser screenshot is here:
| https://x.com/mikehostetler/status/2025970863237972319
|
| Agents, when wrapped with an AgentRuntime, are typically a
| single GenServer process. There are some exceptions if you need
| a larger topology.
| davidw wrote:
| (
| https://xcancel.com/mikehostetler/status/2025970863237972319
| for people who don't like supporting the white supremacist
| site )
|
| I was curious about the actual BEAM processes though, that
| you see via the observer application in Erlang/Elixir.
| mikehostetler wrote:
| I'll put something together!
| StevenNunez wrote:
| A library I'm excited to not vibecode against!
| mmcclure wrote:
| I haven't used Jido for anything yet, but it's one of those
| projects I check in on once a month or so. BEAM _does_ seem like
| a perfect fit for an agent framework, but the ecosystem seeming
| limited has held me back from going too far down that path.
| Excited to see 2.0!
|
| Just a heads up, some of your code samples seem to be having an
| issue with entity escaping. name:
| "my_agent", description: "A simple
| agent",
| mikehostetler wrote:
| Thank you! Fixing ...
| whalesalad wrote:
| oh no did HN traffic defeat OTP
| mikehostetler wrote:
| Seems so, to my eternal shame ...
| enraged_camel wrote:
| Where does this stand in relation to LangChain?
| https://github.com/brainlid/langchain
|
| (Probably complimentary but wanted to check)
| mmcclure wrote:
| I went down this path a bit the other night, curious what OP's
| answer is. My mental model was that they could be
| complimentary? Jido for agent lifecycle, supervision, state
| management, etc, LangChain for the LLM interactions, prompt
| chains, RAG, etc. Looks like you could do everything in Jido
| 2.0, but if you like/are familiar with LangChain it seems like
| they could work well together.
| mikehostetler wrote:
| See my other comment, but Jido 1.0 used (Elixir) Langchain
|
| As LLM API's evolved, I needed more and built ReqLLM which is
| now embedded deeply into Jido.
| neya wrote:
| Elixir has a LangChain implementation by the same name. And in
| my opinion as a user of both, the Python version and the Elixir
| version, the Elixir version is vastly superior and reliable
| too.
|
| This agentic framework can co-exist with LangChain if that's
| what you're wondering.
|
| https://github.com/brainlid/langchain
| mikehostetler wrote:
| Jido originally used Langchain for LLM calls - but it wasn't a
| fit so I built an entire LLM client package to work with Jido
| called ReqLLM
|
| https://hex.pm/packages/req_llm
|
| ReqLLM is baked into the heart of Jido now - we don't support
| anything else
| cpursley wrote:
| ReqLLM is a key part of my stack, thank you for making it!
| klocksib wrote:
| The site seems to be getting hugged to death, here's the
| archive.org backup:
|
| https://web.archive.org/web/20260305161030/https://jido.run/
| memco wrote:
| Not sure if related, but the page loads fine and then after a
| few seconds refreshes into a 404. I gave up trying to read the
| article.
| brabel wrote:
| For me it just seems to keep refreshing for no reason so the
| page keeps jumping around. Also had to give up.
| mikehostetler wrote:
| This is now my personal shame for the next two weeks ... good
| problems, but ya - wow - I was unprepared
| carverauto wrote:
| Going to give it a shot this weekend
| mikehostetler wrote:
| Fantastic!!! Appreciate any feedback
| rvz wrote:
| Let me guess, in the next 6 months, Elixir and Erlang becoming
| fashionable to build AI agents and then another hype cycle of AI
| usage and marketing of Elixir.
|
| What's old is now rebranded, reheated and new again.
| neya wrote:
| Elixir has always been fashionable to build high performance
| systems in. In fact, it is more suited for AI applications than
| any other language or framework because of the BEAM
| architecture and the flexibility of the language itself. I wish
| more people gave it a chance. You get insane performance at
| your fingertips with so much scalability out of the box and
| your code by default is less error prone compared to dynamic
| languages.
| bhekanik wrote:
| Nice work shipping this.
|
| I've found the hardest part with agent frameworks isn't model
| plumbing, it's operational boundaries: how you isolate tools,
| enforce time/budget limits, and recover from partial failures
| when an agent call chain fans out.
|
| BEAM's supervision model feels like a genuinely strong fit for
| that, especially if each tool execution can be treated as a
| supervised unit with clear restart/escalation semantics. Curious
| whether you've seen teams default to many small specialized
| agents vs fewer general agents with stricter policies.
| mikehostetler wrote:
| Thank you!
|
| Agree on operational boundaries - it took a long time to land
| where we did with the 2.0 release
|
| Too much to say about this in a comment, but take a look at the
| "Concepts: Executor" section - it digs into the model here
| malkosta wrote:
| How do you ensure security? Does it have a proper container?
| Otherwise, it's impossible to prevent leaking prod secrets.
| mikehostetler wrote:
| By using Signals and Plugins, all data between agents can be
| encrypted. I've seen a Jido implementation doing this already.
|
| It's use-case specific though - security is a much bigger topic
| then just "agents in containers"
|
| The point of Jido isn't to solve this directly - it's to give
| you the tools to solve it for your needs.
| maxekman wrote:
| Thanks for sharing! I'll definitely check it out.
|
| I just LLM-built an A2A package which is a GenServer-like
| abstraction. I however missed that there already was another A2A
| implementation for Elixir. Anyway, I decided to leave it up
| because the package semantics were different enough. Here it is
| if anyone is interested: https://github.com/actioncard/a2a-elixir
| mikehostetler wrote:
| Awesome!!! Gave you a star ...
| maxekman wrote:
| Lovely! Thanks for doing the first star!
| desireco42 wrote:
| Huh... excellent timing. I am working on a project that currently
| is handling this with bunch od npm tasks :)(I know), but it
| works.
|
| Sidian Sidekicks, Obsidian vault reviewer agents.
|
| I think Jido will be prefect for us and will help us organize and
| streamline not just our agent interactions but make them more
| clear, what is happening and which agent is doing what.
|
| And on top of that, I get excuse to include Elixir in this
| project.
|
| Thanks for shipping.
| mikehostetler wrote:
| Yay!!!
| neya wrote:
| Love this! The timing couldn't be more perfect. I had to write my
| agent framework with a mix of gen servers and Oban. It's honestly
| a pain to deal with. This looks like it will really remove a lot
| of pain for development. Thank you so much!
| mikehostetler wrote:
| <3
| mjdecour wrote:
| I've been following this project for several months now and
| Elixir/BEAM is absolutely perfect for running agents. BEAM is so
| incredibly lightweight; IFYKYK. Theoretically you could run 1000s
| of agents on a single server. I'm looking forward to seeing what
| people who understand this build.
| mikehostetler wrote:
| The core of Jido will run on a Raspberry Pi - we've even had
| people look at running Agents inside the BEAM where the BEAM is
| deployed on bare metal (embedded)
|
| The future is going to be wild
| sbuttgereit wrote:
| Is this anything similar at all to:
|
| https://github.com/openai/symphony
|
| I'm not very familiar with the space, I follow Elixir goings on
| more than some of the AI stuff.
|
| It is curious... and refreshing... to see Elixir & the BEAM
| popping up for these sorts of orchestration type workloads.
| mikehostetler wrote:
| It's great to see OpenAI embracing Elixir - symphony is a
| direct implementation of the types of things Jido can do!
| cpursley wrote:
| Jido is fantastic. A friend and I have been working on an
| OpenClaw type of tool in Elixir with Jido if anyone wants to
| check it out:
|
| https://github.com/agoodway/goodwizard
| mikehostetler wrote:
| Amazing!
| travisgriggs wrote:
| Meta curiosity... would OP care to comment on what role
| agents/LLMs played in crafting this library?
| mikehostetler wrote:
| The original version where I laid down the overall patterns was
| all hand coded. This was mid 2024.
|
| I used Claude to learn & refine the patterns, but it couldn't
| write this level of OTP code at that time.
|
| As models got better, I used them to find bugs and simplify -
| but the bones are roughly the same from that original design.
| weeksie wrote:
| Very eager to read through your code! I read the first version
| and incorporated several of its ideas into our own internal
| elixir agent framework. (We make use of your ReqLLM package,
| thanks much for that!)
|
| Congrats on the release!
| mikehostetler wrote:
| Thanks!!!
| wingrammer wrote:
| Hey I'd love to talk to people using this amazing framework!
| mikehostetler wrote:
| Join our Discord - link is in the site footer
|
| There's a growing community showcase and I have a list of
| private/commercial references as well depending on your goals
| moehj wrote:
| "Congrats on 2.0 -- the BEAM's supervision and fault tolerance
| makes a lot of sense for agent workloads. One thing we've been
| tackling at ARU (aru-runtime.com) is the certification layer
| between agent intent and execution -- validating outputs against
| a defined contract before they pass downstream. Curious whether
| Jido has opinions on output validation/certification, or if
| that's left to the application layer?"
___________________________________________________________________
(page generated 2026-03-05 23:00 UTC)