Discussion

Search

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. name: "my_agent", description: "A simple agent",

carverauto: Going to give it a shot this weekend

enraged_camel: Where does this stand in relation to LangChain? https://github.com/brainlid/langchain(Probably complimentary but wanted to check)

mmcclure: 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.

malkosta: How do you ensure security? Does it have a proper container? Otherwise, it's impossible to prevent leaking prod secrets.

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

desireco42: 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.

klocksib: 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: 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: For me it just seems to keep refreshing for no reason so the page keeps jumping around. Also had to give up.

neya: 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

neya: 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: Thank you! Fixing ...

mikehostetler: 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 ReqLLMhttps://hex.pm/packages/req_llmReqLLM is baked into the heart of Jido now - we don't support anything else

mikehostetler: 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.

mikehostetler: See my other comment, but Jido 1.0 used (Elixir) LangchainAs LLM API's evolved, I needed more and built ReqLLM which is now embedded deeply into Jido.

mikehostetler: Awesome!!! Gave you a star ...

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.

maxekman: Lovely! Thanks for doing the first star!

travisgriggs: Meta curiosity… would OP care to comment on what role agents/LLMs played in crafting this library?

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!

wingrammer: Hey I'd love to talk to people using this amazing framework!

cpursley: 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: Amazing!

mikehostetler: 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.

sbuttgereit: Is this anything similar at all to:https://github.com/openai/symphonyI'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: It’s great to see OpenAI embracing Elixir - symphony is a direct implementation of the types of things Jido can do!

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?"

DmitryGrankin: 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.

mikehostetler: Yep - BEAM has great support for audio workloads - would love to chat

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

_pdp_: coolAlthough... 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.

waynesonfire: Legit question, am I missing anything not playing with agents? Like, what's the killer-app feature vs chatgpt prompt?

edg5000: Its an order of magnitude difference in what it can do, mostly because it can verify its own work. It can also use subagents which helps a lot. Large tasks I usually have done by subs with the main agent directing. This means the task they can take on can be much larger.

choilive: Congrats on the front page MH, hard to forget fellow Chicago/midwest entrepreneurs.

Noyra-X: The point mikehostetler makes – 'agents must be architecturally correct WITHOUT LLMs before they can be correct WITH LLMs' – is underappreciated in most production deployments. We see this constantly: the failure mode isn't model quality, it's undefined operational boundaries and missing human-in-the-loop checkpoints for edge cases. Supervision trees as a first-class design primitive rather than an afterthought seems exactly right. What's your experience with teams that skip the architectural correctness step and go straight to LLM integration?

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.

hrmtst93837: BEAM offers concrete benefits for agent frameworks: cheap preemptible processes, OTP behaviors like GenServer and Supervisor, ETS or Mnesia for fast state, and clustering tools that make managing thousands of stateful agents and restarts tractable.The tradeoff is heavy ML still lives in Python and on GPUs, so run models as external services over gRPC or HTTP or use Nx with EXLA for smaller on-node work, and if you need native speed use Rustler NIFs or ports but never block the BEAM scheduler or the node will grind to a halt.

mikehostetler: 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.

mikehostetler: Thank you!!!

jdmadrigal95: Hi Mike,I am an amateur, can you point me in the correct direction to understand BEAM and use JIDO 2.0 to start building? Please.Thanks, Jose

ralphc: I'm in the same boat as waynesonfire and I'm afraid this doesn't answer the question sufficiently. What do you do with an agent? What's a concrete example vs. typing in a chat box.

nickcoffee: Nice work shipping this. The BEAM's fault tolerance model makes a lot of sense for agent workloads, been thinking about similar tradeoffs on the orchestration side. Curious what the failure recovery looks like when an agent mid-run hits a bad LLM response vs. a process crash.