3 ms·
Show HN: Jido – Run 10k agents at 25KB each (Elixir)
Hi HN!
I'm Mike Hostetler and I built Jido, an Agent SDK in Elixir that lets you run thousands of agents without heavy infrastructure.
Repo: https://github.com/agentjido/jido https://github.com/agentjido/jido
Getting Started: https://hexdocs.pm/jido/getting-started.html https://hexdocs.pm/jido/getting-started.html
Why another framework?
After using several popular Agent frameworks and platforms, I had two key challenges:
- Running multiple agents required process-heavy infrastructure like Docker or K8s. Running 50,000 agents in parallel was costly and diminished the benefits of agentic programming.
- Today's agents require too much human intervention when building workflows. Why couldn't agents manage their own WDLC (Workflow Design Life Cycle)? This felt like a major missing piece.
Agentic frameworks were written for humans. LLMs working with this code were constantly working around human work-style assumptions. So, I wrote a framework specifically for LLMs to code and operate their own agentic flows.
Elixir was a natural choice because of it's functional nature, rock-solid concurrency primitives and "let-it-crash" philosophy with dynamic error compensation. Hot code reloading was a bonus.
Agents in Jido use 25Kb of memory at rest and can easily serialize then hibernate for long-lived access. Agents possess the APIs to dynamically start and manage their own sub-agents or any other Elixir process utilizing Elixir's OTP architecture.
Jido Actions are functional primitives that Agents can dynamically orchestrate into workflows. Generated code can either run in a separate process in the current VM or in another BEAM VM that's linked and hardened before introduction into the Agent VM.
I'm excited to help enable a world where thousands of agents work seamlessly on behalf of their human operators.
Thanks!
- okarin_taka 2y ago[dead]
- okarin_taka 2y ago[dead]
- travisgriggs 2y agoI used GPT (irony) to (possibly) get to the point of the name: “… • In Japanese, 自動 (Jidō) means “automatic” or “self-moving,” often seen in terms like “jidōsha” (automobile). …”
- mikehostetler 2y agoYou got it ;-)
- innocentoldguy 2y agoYes, 自動 is a common prefix in Japanese that means automatic. So, in your example, the first two kanji mean automatic and the last kanji means car. 自動車 (jidousha): Automobile Other examples include: 自動販売機 (jidouhanbaiki): Vending machine 自動ドア (jidoudoa): Automatic door 自動エリクサー (jidouerikusa-): Automatic Elixir (joking)
- lizzas 2y agoAgent as in AI or agent as in actor framework? Or both?
- mikehostetler 2y agoThis SDK is the actor framework with the primitives. There will be additional packages to facilitate chat (https://github.com/agentjido/jido_chat https://github.com/agentjido/jido_chat) and AI (https://github.com/agentjido/jido_ai https://github.com/agentjido/jido_ai) There's a WIP workbench app that will be 1-click deployable to set up and chat with a Jido AI agent soon: https://github.com/agentjido/jido_workbench https://github.com/agentjido/jido_workbench
- jittoshi 2y agoCan you elaborate on the scaling potential here, given your choice of stack?
- mikehostetler 2y agoTo run multiple agents in TypeScript, you're typically reaching for a package like 'pm2'. This starts a Node.js process for each Agent, then you need another tool like Redis for them to communicate. Adding Docker adds even more weight. You could run multiple agents in a single Node.js process, but you'll eventually face event-loop conflicts. With Elixir and BEAM, you already have the tools to run agents as a lightweight Erlang process. You also have built-in PubSub for inter-agent communication (via a package). This provides the ability for safely running 1000's of agents in a single BEAM Node. This is much more robust and efficient then Node.js and TypeScript.
- okarin_taka 2y ago[dead]
- sbrother 2y agoThis looks great; I've been working on something similar but I'll drop it since this is much further along. Do you have a list of issues/feature requests you'd like contributions on?
- mikehostetler 2y agoI'm pushing on two efforts: - How "robust" do I build the Agent GenServer? There is a working implementation in the repo, but it's simplistic. How robust should the event implementation of Signals be? I'd love feedback on that - Examples of Agents and Actions - the other repo's in the org have some basic examples, and I'm building out chat first as that is the most requested - but expansion there would be fantastic Thanks!