Show HN: Jido 2.0, Elixir Agent Framework (jido.run)

323 points by mikehostetler ↗ HN
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!

34 comments

[ 0.24 ms ] story [ 50.0 ms ] thread
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-...

A library I'm excited to not vibecode against!
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",
Going to give it a shot this weekend
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.

How do you ensure security? Does it have a proper container? Otherwise, it's impossible to prevent leaking prod secrets.
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

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.

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!
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.
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.

Meta curiosity… would OP care to comment on what role agents/LLMs played in crafting this library?
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!

Hey I'd love to talk to people using this amazing framework!
[flagged]
I really like the focus on “data and pure functions” from the beginning of the post.

I’ve read a lot on HN about how BEAM execution model is perfect for AI. I think a crucial part that’s usually missing in LLM-focused libraries is the robustness story in the face of node failures, rolling deployments, etc. There’s a misconception about Elixir (demonstrated in one of the claw comments below) that it provides location transparency - it ain’t so. You can have the most robust OTP node, but if you commit to an agent inside a long running process, it will go down when the node does.

Having clear, pure agent state between every API call step goes a long way towards solving that - put it in Mnesia or Redis, pick up on another node when the original is decommissioned. Checkpointing is the solution

Oh this is timed perfectly - I was just writing my own erlang agent framework but this is much better!
cool

Although... the agent orchestration is really the easy part. It is just a loop. You can solve this in many different ways and yes some languages are more suitable for this than others. But still - very straightforward.

The hard part is making sure these agents can do useful things which requires connecting them to tools. Although just adding bash might seem like checking that box the reality is more complex when it comes to authentication (not only). It is even more problematic when you need to run this in some sort of distributed way where you need to inject context midway, abort or pause and do so with all the constraints in mind like timing issues for minted urls and tokens, etc. Btw, adding messages to the context while LLM is doing some other job (which you might want to do for all kinds of reasons) does not always work because the system is not deterministic. So you need to solve this somehow.

Even harder is coming up with useful ways to apply the technology. The technical side of things can be solved with good engineering but most of the applications of these agents are around pretty basic use-cases and the adoption is sort of stagnated. 99% of these agents are question/answer bots, task/calendar organisers, something to do with spam and the most useful one is coding assistants.

And so frankly I think the framework is irrelevant at this point unless one figures out how to do useful things.

Not sure if this will surprise you - but I 100% agree with this. I went through the journey that many others did - implementing the loop, then trying to make it useful, realizing the limitations, etc.

I came to similar conclusions - what does valuable agentic software look like? It's not OpenClaw (yet)

The game theory then, in my opinion, is to focus on the knowable frontier - implement tools we can trust - and continue working and sharing that work.

I am holding onto the optimistic case - valuable use cases beyond coding agents will emerge.