Jido 2.0 - Elixir-आधारित एजेंट फ्रेमवर्क जारी

• शुद्ध functional agent architecture के साथ, state और actions को data के रूप में परिभाषित किया गया है और side effects को directive के रूप में अलग किया गया है, जिससे testing और debugging सरल हो जाती है
• संक्षिप्त API और BEAM-केंद्रित डिज़ाइन अपनाया गया है, और jido_action, jido_signal जैसे मॉड्यूल अलग करके मानकीकृत action·signal system प्रदान किया गया है
• ऊपरी परत Jido AI ReAct, Chain-of-Thought सहित 6 reasoning strategies को support करती है, और ReqLLM-आधारित LLM integration के जरिए 11 providers और 665 models का उपयोग संभव है
• Jido अब agent ecosystem platform के रूप में विस्तार कर रहा है, और Ash Framework integration (ash_jido) के माध्यम से AI-callable CRUD tooling को support करता है

---

Jido 2.0 का अवलोकन

• Jido 2.0, 18 महीनों के विकास और पुनर्रचना के बाद तैयार हुआ Elixir-आधारित agent framework है
  • शुरुआत 2024 में BotHive नामक bot platform के रूप में हुई थी, और बाद में agent systems की नींव के रूप में BEAM runtime को अपनाया गया
  • TypeScript या Python-आधारित frameworks की सीमाओं को पार करने के लिए BEAM की concurrency और stability का उपयोग किया गया

1.0 से 2.0 तक के बदलाव

• Jido 1.0 में अत्यधिक abstraction के कारण usability कम हो गई थी, लेकिन 2.0 में इसे सरल API और BEAM-केंद्रित संरचना के साथ सुधारा गया
  • user feedback को शामिल करके अनावश्यक complexity हटाई गई और बुनियादी कार्यों को करने में friction को न्यूनतम किया गया
  • “हम agent बनाना चाहते हैं, framework से लड़ना नहीं” जैसी मांग को इसमें प्रतिबिंबित किया गया

शक्तिशाली और टिकाऊ agent core

• Jido 2.0 का केंद्र शुद्ध functional agent architecture है
  • agent को state, actions और tools वाले एक सरल struct के रूप में परिभाषित किया जाता है
  • सभी operations cmd/2 function के जरिए संभाले जाते हैं, और input action के अनुसार updated agent और directives की सूची लौटाई जाती है
  • side effects को directive के रूप में व्यक्त किया जाता है, जिन्हें runtime execute करता है, इसलिए testing और debugging आसान हो जाती है
• Jido.AgentServer, agent को supervised GenServer में wrap करता है, और signal routing तथा parent-child agent hierarchy को support करता है
• strategy, extension point के रूप में काम करती है, और Direct (sequential execution) तथा FSM (state machine) दो विकल्प default रूप से दिए गए हैं
  • ReAct, Chain-of-Thought जैसे AI strategies भी इसी interface पर काम करती हैं

action और signal modules का विभाजन

• jido_action: सभी agent functionalities को परिभाषित करने वाला universal action contract
  • compile time schema validation, lifecycle hooks, और ReqLLM tool format में automatic conversion जैसी सुविधाएँ शामिल हैं
  • 25 से अधिक prebuilt tools और DAG-आधारित workflow planner प्रदान किया गया है
• jido_signal: CloudEvents v1.0.2 पर आधारित messaging system
  • standardized signal format, trie-based router, pub/sub bus, और 9 dispatch adapters उपलब्ध हैं
  • बिना किसी non-standard protocol के विभिन्न systems के साथ integration संभव है

Jido AI integration layer

• jido_ai एक integration layer है, जो LLM calls को structured agent intelligence में बदलती है
  • ReAct, Chain-of-Thought, Tree-of-Thoughts, Graph-of-Thoughts, TRM, Adaptive सहित 6 reasoning strategies built-in हैं
  • यह वही cmd/2 contract और directive system बनाए रखती है, जिससे AI layer कोई अलग दुनिया नहीं बल्कि एक extension के रूप में integrate होती है
• यह ReqLLM पर आधारित है और 11 providers तथा 665 से अधिक models को support करती है
  • streaming-first design, multi-provider architecture, और सक्रिय community contributions इसकी विशेषताएँ हैं

विस्तार करता ecosystem

• Jido, एक साधारण framework से आगे बढ़कर agent ecosystem के रूप में विकसित हो रहा है
  • community, BEAM पर coding assistant, workflow orchestrator, research agent, operations support systems आदि बना रही है
  • browser automation, memory systems, evaluation harnesses, MCP integration जैसे विभिन्न packages सामने आ रहे हैं
• Ash Framework integration (ash_jido)
  • Ash resources में jido DSL block जोड़ने पर CRUD actions, AI-callable tools में बदल जाते हैं
  • authorization policies, data layer, और type safety बरकरार रहती है
  • ash_ai भी ReqLLM की ओर migrate हो रहा है, जिससे दोनों ecosystems का convergence आगे बढ़ रहा है

community और आभार

• Jido 2.0, Elixir community ecosystem की नींव पर बनाया गया है
  • Phoenix, LiveView, Ash, Req, Telemetry, NimbleOptions जैसी प्रमुख libraries के योगदान से यह और मजबूत हुआ है

शुरुआत करें

• Hex package के रूप में install किया जा सकता है

  {:jido, "~> 2.0"},  
  {:jido_ai, "~> 2.0"}  
  

• दस्तावेज़: hexdocs.pm/jido
• ecosystem: jido.run/ecosystem
• GitHub: github.com/agentjido

[GN⁺]

Hacker News की राय

• मैंने अभी तक Jido को वास्तव में इस्तेमाल नहीं किया है, लेकिन लगभग हर महीने एक बार इसे ज़रूर देखता हूँ
  मुझे लगता है कि BEAM agent framework के लिए बिल्कुल उपयुक्त है, लेकिन ecosystem अभी सीमित है इसलिए मैं इसमें गहराई तक नहीं जा पाया
  2.0 version का इंतज़ार है। वैसे, code samples के कुछ हिस्सों में entity escape की समस्या दिख रही है

  • धन्यवाद! अभी तुरंत ठीक कर रहा हूँ

• लेख की शुरुआत से ही जिस “data और pure functions” केंद्रित approach पर ज़ोर दिया गया है, वह मुझे बहुत पसंद आई
  अक्सर यह कहा जाता है कि BEAM का execution model AI के लिए उपयुक्त है, लेकिन वास्तव में node failure या rolling deploy जैसी स्थितियों में इसकी robustness को अक्सर नज़रअंदाज़ कर दिया जाता है
  Elixir के बारे में यह गलतफ़हमी भी है कि यह location transparency देता है, जबकि ऐसा नहीं है। अगर node बंद हो जाए, तो उसके अंदर के process भी साथ में बंद हो जाते हैं
  अगर हर API call step पर स्पष्ट और pure agent state बनाए रखी जाए, तो इस समस्या को हल किया जा सकता है। State को Mnesia या Redis में store करके दूसरे node पर आगे बढ़ाया जा सकता है। आखिरकार checkpointing ही कुंजी है

  • मेरी राय में Jido का सबसे महत्वपूर्ण सिद्धांत यह है कि LLM इस्तेमाल करने से पहले LLM के बिना भी संरचनात्मक रूप से सही agent बनाया जाए
    इसलिए Jido core में LLM support बिल्कुल नहीं है।
    40 साल से अधिक का agent research मौजूद है, लेकिन LLM आने के बाद लगता है जैसे लोग उसे भूल गए हों। इसलिए मैंने उस इतिहास को फिर से पढ़कर Jido में उतारने की कोशिश की
    बेशक मुझे LLM पसंद हैं, लेकिन वह Jido AI package का काम है

• timing बिल्कुल सही है। मैंने gen server और Oban को मिलाकर खुद agent framework बनाया था, और वह सच में काफ़ी दर्दनाक काम था
  लगता है यह project development की तकलीफ़ को बहुत कम कर देगा। सच में धन्यवाद

  • ❤️

• क्या यह OpenAI Symphony जैसा कुछ है?
  मैं AI से ज़्यादा Elixir को follow करता हूँ, इसलिए ऐसे orchestration workload में Elixir और BEAM का इस्तेमाल देखना ताज़गीभरा है

  • OpenAI को Elixir इस्तेमाल करते देखना अच्छा लगा। Symphony दरअसल उन चीज़ों का direct implementation है जो Jido कर सकता है

• site पर traffic spike की वजह से पहुँचना मुश्किल हो रहा है। इसलिए archive.org backup link साझा कर रहा हूँ

  • यह शायद अगले 2 हफ़्तों तक मेरी निजी शर्मिंदगी बनी रहेगी… अच्छी समस्या है, लेकिन मैं सच में तैयार नहीं था
  • पता नहीं यह उसी से जुड़ी समस्या है या नहीं, लेकिन page पहले ठीक खुलता है और कुछ सेकंड बाद 404 पर refresh हो जाता है। आखिर में मैंने पढ़ना छोड़ दिया

• साझा करने के लिए धन्यवाद! मैं इसे ज़रूर देखूँगा
  मैंने हाल ही में LLM के साथ एक A2A package बनाया है, जो GenServer जैसी abstraction है
  पहले से दूसरी A2A implementations थीं, लेकिन मेरे package की semantics अलग हैं, इसलिए मैंने इसे वैसे ही जारी किया
  दिलचस्पी रखने वाले लोग इसे यहाँ देख सकते हैं

  • बढ़िया! मैंने अभी star कर दिया

• मैं कई महीनों से इस project को देख रहा हूँ, और Elixir/BEAM agent execution के लिए एकदम सही platform है
  BEAM सच में हल्का और efficient है, इसलिए सैद्धांतिक रूप से एक server पर हज़ारों agents चलाना संभव है
  आगे इसे समझने वाले लोग क्या बनाएँगे, यह देखने का इंतज़ार है

  • Jido core Raspberry Pi पर भी चल सकता है
    यहाँ तक कि BEAM को bare metal (embedded) environment में deploy करके उसके अंदर agents चलाने की कोशिश भी हुई है
    भविष्य सच में बहुत रोचक लग रहा है

• ‘observer’ में agents के active होने पर process tree का screenshot देखना अच्छा होगा
  जानकारी के लिए, observer BEAM VM के अंदर Erlang processes को visualize करने वाला tool है
  उदाहरण screenshot Fly.io docs में देखा जा सकता है

  • हम जल्द ही jido_studio नाम का dashboard जारी करने वाले हैं। यह process structure को visualize करेगा
    teaser screenshot यहाँ देखा जा सकता है
    AgentRuntime में लिपटे agents आम तौर पर एक GenServer process के रूप में चलते हैं, लेकिन जब बड़ी topology की ज़रूरत होती है, तो कुछ अपवाद भी होते हैं

• timing बिल्कुल सही है। मैं भी खुद एक Erlang agent framework बना रहा था, लेकिन यह उससे काफ़ी बेहतर है

• security कैसे सुनिश्चित की जाती है, यह जानने की उत्सुकता है। अगर container isolation नहीं है, तो production secrets leak को रोकना मुश्किल होगा

  • Signals और Plugins का उपयोग करने पर agents के बीच data को encrypt किया जा सकता है
    मैंने वास्तव में Jido के ऐसे use cases देखे हैं जहाँ यह लागू किया गया है
    लेकिन यह use case पर निर्भर करता है, और security सिर्फ “container के अंदर agent” वाली समस्या से कहीं बड़ा विषय है
    Jido का उद्देश्य security को सीधे हल करना नहीं है, बल्कि ऐसे tools देना है जिनसे user अपनी ज़रूरत के मुताबिक इसे हल कर सके