[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

[mikehostetler]

My strongest opinion with Jido is that agents must be architecturally correct WITHOUT LLM's before they can be correct WITH LLM's

Jido core has zero LLM support for this reason.

There's nearing 40+ years of "Agent" research in CompSci, LLM's came along and we threw out all of it. I didn't like that so I spent time researching this history to do my best at considering it with Jido.

That said, I love LLM's - but they belong in the Jido AI package.

[kzemek]

Fair enough! My comment is about agentic-focused libraries in general, it’s inaccurate of me to call all such libraries “LLM-focused”

Speaking of inaccuracies, BEAM does provide pretty good location transparency - but resource migration between nodes in particular is not part of the built-in goodies that OTP brings