Show HN: Jido – Run 10k agents at 25KB each (Elixir)
github.comHi 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 Getting Started: 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! I 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).
…” Yes, 自動 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) You got it ;-) This 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? I'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! Can you elaborate on the scaling potential here, given your choice of stack? To 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. Agent as in AI or agent as in actor framework? Or both? This SDK is the actor framework with the primitives. There will be additional packages to facilitate chat (https://github.com/agentjido/jido_chat) and 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