Cool framework — the BEAM is a natural fit for agent orchestration, especially the supervision and fault tolerance primitives.
One gap I keep noticing with agent frameworks across all languages: they can read code, docs, browse the web, query databases, but none of them can access what was discussed in meetings. That's where half the context lives for most teams.
We built an MCP server for exactly this (Vexa, open-source). Bots join Meet/Teams/Zoom calls, transcribe in real-time, and serve it all via MCP so any agent can query "what did the team decide about X." Would be interesting to see a Jido skill for meeting transcript access — especially with the real-time streaming you have.
kzemek
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
mmcclure
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.
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!
show comments
klocksib
The site seems to be getting hugged to death, here's the archive.org backup:
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.
show comments
bhekanik
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.
show comments
maxekman
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
show comments
weeksie
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!
show comments
mjdecour
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.
show comments
moehj
"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?"
wingrammer
Hey I'd love to talk to people using this amazing framework!
show comments
davidw
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:
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.
show comments
whalesalad
oh no did HN traffic defeat OTP
show comments
rvz
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.
Cool framework — the BEAM is a natural fit for agent orchestration, especially the supervision and fault tolerance primitives.
One gap I keep noticing with agent frameworks across all languages: they can read code, docs, browse the web, query databases, but none of them can access what was discussed in meetings. That's where half the context lives for most teams.
We built an MCP server for exactly this (Vexa, open-source). Bots join Meet/Teams/Zoom calls, transcribe in real-time, and serve it all via MCP so any agent can query "what did the team decide about X." Would be interesting to see a Jido skill for meeting transcript access — especially with the real-time streaming you have.
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
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.
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!
The site seems to be getting hugged to death, here's the archive.org backup:
https://web.archive.org/web/20260305161030/https://jido.run/
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.
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.
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
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!
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.
"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?"
Hey I'd love to talk to people using this amazing framework!
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-...
How do you ensure security? Does it have a proper container? Otherwise, it's impossible to prevent leaking prod secrets.
Meta curiosity… would OP care to comment on what role agents/LLMs played in crafting this library?
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
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)
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.
oh no did HN traffic defeat OTP
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.
A library I'm excited to not vibecode against!