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.
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
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.
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:
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.
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.
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.
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
The site seems to be getting hugged to death, here's the archive.org backup:
https://web.archive.org/web/20260305161030/https://jido.run/
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.
I was seeing the same thing. Looking at the network tab, I suspect there's LiveView involved and that dying from load isn't getting handled well.
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.
How do you ensure security? Does it have a proper container? Otherwise, it's impossible to prevent leaking prod secrets.
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-...
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.
( 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.
I'll put something together!
Going to give it a shot this weekend
Where does this stand in relation to LangChain? https://github.com/brainlid/langchain
(Probably complimentary but wanted to check)
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.
A library I'm excited to not vibecode against!
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.
oh no did HN traffic defeat OTP