आपको खुद एजेंट क्यों बनाकर देखने चाहिए

• LLM एजेंट ऐसी तकनीकी संरचना हैं जिन्हें सिर्फ अवधारणा के रूप में समझने के बजाय खुद लागू करके उनके काम करने के तरीके को बेहतर महसूस किया जा सकता है
• केवल कुछ दर्जन पंक्तियों के Python code से OpenAI Responses API का उपयोग करके एक conversational agent बनाया जा सकता है, और इसमें tool call फीचर जोड़ने पर यह autonomous behavior भी कर सकता है
• एजेंट का मूल stateless LLM के साथ iterative call loop है, और conversation context को सीधे मैनेज करके multi-turn conversation लागू की जाती है
• Context Engineering वास्तव में programming task स्तर की समस्या है, जिसमें token limit के भीतर input, output और tool description को optimize करने वाली design की जरूरत होती है
• मौजूदा agent design एक open software engineering problem space है, जहाँ individual developer भी experiment के जरिए नए approach आज़मा सकते हैं

---

एजेंट लिखने की सरलता

• LLM agent को जटिल setup के बिना सिर्फ OpenAI Responses API से लागू किया जा सकता है
  • उदाहरण code में context list के जरिए user और model के बीच की बातचीत को स्टोर किया जाता है, और इसे बार-बार call करके ChatGPT जैसी conversational response बनाई जाती है
• “अच्छे स्वभाव” और “बुरे स्वभाव” वाले दो context बनाकर multi-persona conversation को simulate किया जा सकता है
  • LLM के पास कोई state नहीं होती, और बातचीत की continuity user द्वारा मैनेज किए जाने वाले string array (context) से बनी रहती है
• सिर्फ इस सरल संरचना से भी multi-turn conversation संभव है, और LLM के काम करने के तरीके का प्रत्यक्ष अनुभव किया जा सकता है

tool एकीकरण और autonomous operation

• एजेंट में ping function को tool के रूप में register करके network connection status जांचने की सुविधा जोड़ी जा सकती है
  • OpenAI API tool definition को JSON format में मांगता है, और जब LLM जरूरत होने पर tool call request करता है, तो Python code उसे execute करके परिणाम फिर से भेज देता है
• LLM बिना किसी explicit instruction के कई host (google.com, www.google.com, 8.8.8.8) को अपने-आप ping करता है
  • यह दिखाता है कि LLM केवल “tool use permission” मिलने पर भी autonomous judgment कर सकता है
• पूरा loop बस “tool call request → execution → result return” संरचना है, इसलिए जटिल control logic के बिना भी autonomous agent behavior लागू किया जा सकता है

वास्तविक उपयोग और MCP की आलोचना

• उदाहरण code भले सरल हो, लेकिन इसमें additional tools (traceroute आदि) या SQLite-आधारित context storage जोड़कर इसे व्यावहारिक रूप से बढ़ाया जा सकता है
• MCP (Multi-Context Protocol) सिर्फ Claude Code या Cursor का plugin interface है, कोई अनिवार्य तकनीक नहीं
  • अगर आप सीधे API को संभालें, तो MCP के बिना भी वही functionality लागू की जा सकती है
• MCP केवल उन environment में उपयोगी है जहाँ code पर control नहीं होता, और उल्टा यह agent architecture की flexibility को सीमित भी कर सकता है
• LLM security भले जटिल हो, लेकिन separated context और tool restriction के जरिए सुरक्षित संरचना design की जा सकती है

Context Engineering का महत्व

• “prompt engineering” एक बढ़ा-चढ़ाकर पेश किया गया विचार है, लेकिन Context Engineering एक वास्तविक programming problem है
  • context window के भीतर token की संख्या सीमित होती है, और input, output, tool description सभी जगह घेरते हैं
  • इस सीमा को पार करने पर model की response quality अस्थिर हो जाती है
• समाधान के रूप में sub-agent बनाकर उन्हें अलग-अलग context और tool दिए जा सकते हैं, और इस तरह design किया जा सकता है कि वे एक-दूसरे के लिए summary बनाएं और आदान-प्रदान करें
  • ऐसी संरचना को tree-shaped agent network या real-time summary-based compression जैसे कई प्रयोगों तक बढ़ाया जा सकता है
• जटिल विचार भी 30 मिनट के भीतर लागू किए जा सकने लायक सरलता रखते हैं

open engineering problem और प्रयोग का महत्व

• इस समय कई startup vulnerability detection agent विकसित कर रहे हैं, और individual developer भी वही प्रयोग कर सकते हैं
• agent design में निम्नलिखित unsolved engineering challenges शामिल हैं
  • non-determinism और structured programming के बीच संतुलन
  • ground truth verification और loop के समय से पहले बंद हो जाने से बचाव
  • multi-stage agent के बीच data exchange format (JSON, SQL, Markdown आदि)
  • token allocation और cost control
• ये समस्याएँ बड़े पैमाने के research की नहीं, बल्कि व्यक्तिगत स्तर के experiment से भी खोजी जा सकने वाली जगह हैं, और हर iteration को कुछ ही दर्जन मिनटों में आज़माया जा सकता है
• निष्कर्षतः, खुद एजेंट बनाकर देखने का अनुभव ही LLM तकनीक को समझने की शुरुआत है

[GN⁺]

Hacker News राय

• करने के लिए वाकई बहुत कुछ है। NAND gate से breadboard पर सीधे CPU बनाना चाहता हूँ, और Rust में CDN भी बनाकर देखना चाहता हूँ, लेकिन समय कम है
  उसकी जगह Karpathy का tutorial फॉलो करके LLM बनाया था, और लगा कि इस तरह थोड़ा-थोड़ा experiment करना काफ़ी अच्छा रहता है

  • यह किसी अंतहीन curve जैसा लगता है। पहले 8-bit computer breadboard पर बनाया था, और इस बार flight training (PPL) में उलझ गया हूँ
    जब भी लगता है कि ‘अब सब कर लिया’, तब finish line और दूर खिसकती हुई महसूस होती है। आखिरकार हम जैसे लोग शायद पूरी तरह संतुष्ट होने वाले नहीं होते
  • TFA के शुरुआती हिस्से में बताया गया है कि इसे कितनी आसानी से किया जा सकता है। वही इस लेख का मुख्य point है

• उदाहरण में GPT-5 इस्तेमाल किया गया है, लेकिन query interface पहले से ही industry standard स्तर का है
  उदाहरण के लिए OpenRouter.ai जोड़ दें तो runtime के दौरान model और provider को आसानी से बदला जा सकता है
  free model (जैसे DeepSeek) भी मिलते हैं, लेकिन वे धीमे और सीमित हैं। फिर भी experiment के लिए शानदार हैं

• कुछ महीने पहले Ruby में खुद एक agent बनाया था। सच में बहुत मज़ेदार था
  core logic सिर्फ़ चार lines की थी, और conceptually हैरान करने वाली हद तक सरल थी

  until mission_accomplished? or given_up? or killed?
    determine_next_command_and_inputs
    run_next_command
  end
  

• 2 साल पहले PHP की 25 lines में एक agent बनाया था, उस समय tool calling भी नहीं था, फिर भी काफ़ी अच्छी तरह काम करता था
  LLM मुझे sed या awk जैसे UNIX text manipulation tools की तरह लगते हैं — आप input और command दें, और वे output दे देते हैं
  इस तरह LLM calls को जोड़कर loop या branching बनाई जाए तो यह काफ़ी शक्तिशाली system बन जाता है
  संबंधित code: hubcap, llm

  • मुझे hubcap बहुत पसंद है। code कम है, फिर भी result प्रभावशाली थे
    Simon Willison की पोस्ट देखकर मुझे बहुत प्रेरणा मिली

• Claude Code का alternative खुद बनाना वाला हिस्सा खास तौर पर relatable लगा। self-improving coding agent बनाना लगभग जादू जैसा अनुभव है
  model को खुलकर बदला जा सकता है, और Cerebras जैसे तेज़ model इस्तेमाल करें तो interactive tool calling में भी बड़ा फ़र्क महसूस होता है
  इसमें memory, speech recognition वगैरह जोड़ दें तो यह और भी ज़्यादा efficient हो जाता है। कुछ ही मिनटों में implement किया जा सकता है और सच में बहुत मज़ेदार है

  • जिज्ञासा है कि आप कौन सा speech recognition model इस्तेमाल करते हैं। Whisper धीमा था और सटीक भी नहीं, और GPT audio models अक्सर refusal responses देते हैं
    Google models की quality कम थी, और Mistral models तेज़ हैं लेकिन कभी-कभी text पर ही प्रतिक्रिया दे देते हैं
    इसलिए कभी-कभी ऐसा हो जाता है कि मेरी बात की जगह LLM के stream of consciousness को ही लिख लेते हैं
  • “build your own lightsaber” वाला expression मुझे सच में बहुत पसंद आया
    शुरुआत में इसे अंदरूनी structure समझने के लिए बनाया था, लेकिन यह उम्मीद से ज़्यादा सरल निकला, इसलिए अब मैं इसमें अपनी मनचाही features खुद जोड़ रहा हूँ
    team-based product से भी तेज़ी से features डाले जा सकते हैं। agent की संरचना हैरान करने वाली तरह से सरल है
  • शुरुआत करने के लिए कहाँ से शुरू करें, यह समझ नहीं आ रहा। Cerebras क्या है, यह भी पहली बार सुन रहा हूँ। अभी तो सिर्फ़ VS Code में Copilot इस्तेमाल कर रहा हूँ
    सोच रहा हूँ क्या यह local model आधारित है
  • Cerebras अब glm 4.6 भी देता है। यह अब भी बेहद तेज़ है, और अब पहले से कहीं ज़्यादा smart भी हो गया है

• इस लेख को पढ़कर Unix philosophy — एक काम बहुत अच्छी तरह करने वाले tools — को फिर से बनाना चाहने का मन होता है
  इससे सिर्फ़ agent सरल नहीं बनते, security भी बेहतर होती है

  • 2021 में मैंने network connectivity test करने वाला एक agent बनाया था, और ping, dig, traceroute जैसे basic tools agent को दे दिए जाएँ तो यह काफ़ी अच्छे नतीजे देता है
    इंसानों द्वारा सीधे बनाए गए telemetry system जितना परफ़ेक्ट तो नहीं, लेकिन 90% उपयोगिता बहुत आसानी से हासिल की जा सकती थी
  • इंसानों के सामने सीधे रखे जाने वाले सीमित उद्देश्य वाले tools के set की भी कल्पना की जा सकती है
  • एक ही काम बहुत अच्छी तरह करने के लिए और ज़्यादा tools चाहिए होते हैं, और उतनी ही context understanding भी बढ़ती है
    लगता है LLM का ideal size पारंपरिक Unix tools से थोड़ा बड़ा, बीच का कोई बिंदु होगा

• मन में सवाल आता है, “क्या agent बनाना ज़रूरी भी है?”
  जब सभी AI providers घाटे में दिख रहे हैं, तब sustainable revenue model संभव होगा या नहीं, इस पर संदेह होता है

  • खुद बनाकर देखें तो agent कैसे काम करते हैं और उनकी सीमाएँ क्या हैं, यह intuitively समझ आता है। यही मुख्य बात है
  • यह बस तकनीक के साथ मज़े के लिए experiment करने वाली पोस्ट है। इसका monetization से कोई लेना-देना नहीं
    यह वैसा ही तर्क है जैसे Python इस्तेमाल न करने की वजह से Astral के घाटे की बात उठाना
  • सभी AI कंपनियाँ घाटे में नहीं हैं
    अगला model train करने की लागत बड़ी है, इसलिए funding की ज़रूरत पड़ती है, लेकिन inference stage लाभदायक है
  • आप खुद भी AI provider बन सकते हैं
  • इस comment में थोड़ा emotional fatigue महसूस होता है। सोच रहा हूँ, क्या आप काफ़ी अनुभवी developer हैं

• context engineering वाला हिस्सा खास तौर पर असरदार लगा
  मैं एक personal assistant बना रहा हूँ, जिसमें सामान्य agent की तुलना में memory, task tracking, problem-solving ability ज़्यादा है
  इसे इस तरह design किया है कि कई agent आपस में बात करके समस्या हल करें, और पहला agent task management supervisor की भूमिका निभाता है
  इस प्रक्रिया में जितना गहराई में जाते हैं, यह उतना ही ज़्यादा engineering problem बनता जाता है
  विस्तार से मैंने अपने ब्लॉग पोस्ट में लिखा है

  • यह सच में बहुत शानदार project लगता है

• सबको agent बनाना पसंद है, लेकिन debugging से नफ़रत है
  शुरुआत में सब कुछ जादू की तरह काम करता है, लेकिन धीरे-धीरे probabilistic failures जमा होने लगती हैं और reproduction मुश्किल हो जाता है
  हर step में 0.5 second लगते हैं, इसलिए कहाँ गलती हुई यह देखने के लिए 10–20 मिनट तक इंतज़ार करना पड़ता है

  • इसलिए मैंने parallel execution tool बनाया, ताकि बदले हुए code को सैकड़ों बार चलाकर देख सकूँ
    और पुराने scenarios भी फिर से चला सकूँ, यह verify करने के लिए कि कुछ टूटा तो नहीं

• दिए गए code के आधार पर एक MCP बनाया: gurddy-mcp.fly.dev
  source code GitHub repository में देखा जा सकता है