LLM function calls scale नहीं करते; code orchestration ज़्यादा सरल और प्रभावी है

• LLM द्वारा पूरे tool call result को प्रोसेस करने का तरीका धीमा, महंगा और scaling के लिए अनुपयुक्त है
• इसके बजाय, output schema पर आधारित structured data को code से प्रोसेस कराने के लिए LLM को orchestration करने देने का तरीका प्रस्तावित है
• यह approach code के जरिए function chaining और variable-based memory management के साथ large-scale data processing के लिए उपयुक्त है
• code execution-आधारित data processing तरीका अधिक सटीक और scalable है, क्योंकि इसमें LLM सीधे data को पुनर्निर्मित नहीं करता
• सुरक्षित AI runtime environment बनाना एक नई चुनौती के रूप में उभर रहा है, और इसके लिए टिकाऊ तथा stateful execution environment की आवश्यकता है

---

LLM function calls don't scale; code orchestration is simpler, more effective.

Tool call results को फिर से LLM को देने वाले मौजूदा तरीके की सीमाएँ

• MCP(Machine Context Protocol) tools का उपयोग करते समय आम तौर पर tool output result को message के रूप में LLM को दिया जाता है और उससे अगला action तय कराया जाता है
• वास्तविक use cases में Linear और Intercom के MCP servers JSON format में बहुत बड़े responses लौटाते हैं
• JSON API जैसा होता है, लेकिन defined output schema न होने से LLM पर पूरे text को parse करने का बोझ आ जाता है
• उदाहरण के लिए, Linear के issue list query result में 50 items, 70,000 characters और लगभग 25,000 tokens होते हैं, जो बहुत बड़ा है
• कई id fields का कोई अर्थपूर्ण उपयोग नहीं होता, लेकिन वे tokens खर्च करते हैं, और LLM को इन्हें ज्यों का त्यों दोहराना पड़े तो cost और errors दोनों बढ़ते हैं

Data processing और orchestration को अलग करने की ज़रूरत

• मौजूदा तरीका data processing और orchestration को एक ही chat session में मिला देता है
• कुछ लोग इसके लिए “agent” के नाम पर अलग threads बनाते हैं, लेकिन जब JSON पहले से structured हो, तो यह अप्रभावी है
• बेहतर तरीका है structured data को सीधे code से प्रोसेस करना
  • उदाहरण: issues को sort करने के लिए LLM से output बनवाने के बजाय code में sort चलाकर सिर्फ result array लौटाया जाए

Code execution-आधारित data processing

• code execution के जरिए AI computation पहले से कई AI interpreters में उपयोग हो रहा है
• यह तरीका LLM को सीधे data output करने के बजाय सिर्फ यह तय करने देता है कि tools का इस्तेमाल कैसे किया जाए, जिससे संरचना अधिक सरल हो जाती है

मुख्य अवधारणाएँ

• variables को memory की तरह उपयोग करना: value assign करना = store करना, output = retrieval, function call में argument के रूप में pass करना
• function chaining support: कई function calls को parallel/sequence में combine किया जा सकता है, और dependencies को code के स्वाभाविक flow में व्यक्त किया जा सकता है
• scalable large-scale data processing: NumPy, pandas आदि के साथ मिलाकर हज़ारों से लेकर दसियों हज़ार records तक आसानी से प्रोसेस किए जा सकते हैं
• दूसरे LLM calls भी संभव: LLM द्वारा लिखे गए code के भीतर किसी और LLM को call करके unstructured data processing भी की जा सकती है

क्या MCP तैयार है?

• MCP specification पहले से input schema define करती है, और हाल ही में output schema PR भी submit किया गया है
• अगर output schema सामान्य हो जाए, तो निम्नलिखित उपयोग संभव होंगे:
  • issue status dashboard
  • weekly completed ticket report
  • रुके हुए tickets को AI द्वारा monitor करके push करना

Code execution environment की चुनौतियाँ

• security सबसे महत्वपूर्ण मुद्दा है: AI/उपयोगकर्ता-निर्मित code चलाया जाता है, इसलिए API keys और data exposure को रोकने वाली design आवश्यक है
• Lutra के मामले में execution environment को sandbox approach के रूप में बनाया गया है, और model को केवल API call documentation दी जाती है
• stateful execution environments (जैसे Jupyter) महंगे होते हैं, और long sessions के लिए stateless + persistent विशेषताओं की आवश्यकता होती है
• इससे AI runtime की एक नई category बन रही है, जिसकी design पर अभी सक्रिय रूप से काम चल रहा है

निष्कर्ष

• tool call results को LLM में डालकर प्रोसेस कराने वाला मौजूदा तरीका cost और accuracy दोनों में सीमित है
• code-based orchestration सरल, scalable और अधिक सटीक processing को संभव बनाता है
• AI code execution environments को security, persistence और scalability से युक्त अगली पीढ़ी के runtime के रूप में देखा जा रहा है

[GN⁺]

Hacker News राय

• पिछले 2 सालों में यह तर्क दिया गया कि "काफ़ी उन्नत agent, DSL से अलग नहीं पहचाना जा सकता"। राय यह है कि agent से algorithm को अंदर समाहित करवाने की बजाय उसे API सिखाना, और उस API का उपयोग करने वाला algorithm design करवाकर उसे user space में चलाना कहीं अधिक उपयुक्त है। LLM के भीतर algorithm ठूँसना बहुत कम स्थितियों को छोड़कर (cost या accuracy के लिहाज़ से) अक्षम है। इसकी तुलना इस बात से की गई कि जैसे किसी developer से कहा जाए कि वह function execution अपने दिमाग़ में करे
  • इसे इस बात के प्रमाण की तरह देखा गया कि ASI (artificial general intelligence) तक पहुँचने का रास्ता LLM की capabilities बढ़ाने में नहीं, बल्कि बाहर से self-improving algorithms को symbolic application के रूप में extract और compile करने की प्रक्रिया में है
  • इस संदर्भ में 2 साल पहले से 'agent' शब्द का व्यापक उपयोग किया गया था, इसके सबूत या उदाहरण साझा करने का अनुरोध
• अपने e-commerce business में agentic system सीधे बनाने का अनुभव साझा किया गया। smolagents को evaluate किया, जो elegant और आकर्षक है, लेकिन system complexity को काफ़ी बढ़ा देता है। dynamic reporting जैसे schema-less data को sort/aggregate करने वाले माहौल में यह perfect है, लेकिन ज़्यादातर कामों के लिए overkill है। Gemini और OpenAI Python interpreter features देते हैं, इसलिए code agents का काफ़ी काम उससे कवर हो सकता है। stack में अंतहीन tool-calling messages जोड़ते जाने वाला approach scalable नहीं है और recommend नहीं किया गया। वास्तविक agentic workflows की उम्र छोटी होती है, और complexity को structure तथा discipline से manage किया जाता है। पारंपरिक software development का सबक, यानी function calls के scale को manage करना और chaos को रोकना, आज भी वैसा ही है। अच्छे systems बनाने की कुंजी developer के cognitive load को manage करने में है, और simple लेकिन पर्याप्त रूप से काम करने वाले solutions अक्सर high-performance लेकिन overly clever तरीकों से बेहतर होते हैं। function-call composition ऐसे simple solutions का उदाहरण है, और structured data processing भी पारंपरिक parsing/transform तरीकों से पर्याप्त है। जब structure अज्ञात हो, तब सस्ते models भी बेहतरीन parsing performance दे सकते हैं। agentic systems में complexity management का सार अंततः application state को बहुत सावधानी से manage करने की समस्या है। message stack manipulation के ज़रिए model input के लिए active context को लचीले ढंग से बनाया जा सकता है, जो constrained environments में memory management जैसा है
  • agentic systems के trade-offs को सटीक रूप से पकड़ने वाला सार। हमने भी e-commerce conversational product search solution (IsarTech) बनाते समय यही समस्याएँ देखीं। function composition और structured data, complexity control के केंद्र में हैं। अनुभव यह भी बताता है कि clear type schema आधारित output, tool calling की scalability को वास्तविक रूप से बढ़ाता है। type schema की वजह से cognitive load और system complexity दोनों manageable रहते हैं। जहाँ संभव हो deterministic behavior पर निर्भर रहें, और schema-less data या ambiguity होने पर ही LLM का उपयोग करें। ambiguous request → deterministic system mapping में LLM बहुत प्रभावी है। हालांकि high-entropy (unstructured) input में complexity हटाने और tool-calling chain से complexity बढ़ाने के बीच संतुलन ज़रूरी है। वास्तविक commerce environment में एक ही तरीका पर्याप्त नहीं होता, और ambiguous intent में structured output की सीमाएँ हैं, इसलिए अतिरिक्त strategy चाहिए
• इशारा किया गया कि समस्या function calling में नहीं, बल्कि MCP के design और उसके उपयोग के तरीके में है। ज़्यादातर MCP, API की नकल हैं और उनमें बेकार data emission की समस्या है। JSON formats को बार-बार nested रूप में दोहराया जाता है, जिससे अनावश्यक input context खर्च होता है और बहुत-सी irrelevant information शामिल रहती है। data flattening और अनावश्यक fields हटाने जैसी optimization की ज़रूरत है। MCP SaaS अंततः सिर्फ API gateway की भूमिका निभाता है। मौजूदा MCP noise का बड़ा कारण है और पर्याप्त रूप से optimized नहीं है
  • GraphQL इसी उद्देश्य के लिए optimized technology है। इसे इस तरह design किया गया है कि केवल ज़रूरी fields चुने जा सकें। कई GraphQL queries को एक MCP server में बदलने वाला open source Gateway विकसित किया गया
  • यह सवाल उठाया गया कि क्या असली समस्या यह नहीं है कि model complex JSON schemas का ठीक से पालन नहीं करते
  • MCP मददगार नहीं है, लेकिन हर चीज़ को फ़िल्टर कर देना भी हमेशा सर्वोत्तम समाधान नहीं है। कभी-कभी agent को बड़े पैमाने पर data processing करनी पड़ती है। ऐसे मामलों में simple data evaluation और schema description के साथ code execution अधिक scalable approach है। बेशक, system बहुत बड़ा हो जाए तो समान समस्याएँ फिर उभरती हैं। अंतिम समाधान यह है कि मानव की deterministic reasoning जैसी precision को code में दोहराया जाए, और LLM उस decision system को call करे। सिद्धांत में यह आसान लगता है, लेकिन व्यवहार में इसे लागू करना बहुत कठिन है
  • ChatGPT से string reverse test करते समय यह महसूस हुआ कि LLM से सिर्फ़ एक साधारण result निकलवाना भी बहुत कठिन था और reliability भी कम थी। इस अनुभव के बाद हमेशा कई LLM से verification कराने की आदत पड़ गई। मज़ाक में कहा गया कि अगर यही रफ़्तार रही, तो simple string में character count करने के लिए खुद का GPU datacenter तैयार करना पड़ेगा
• Shopify team ने हाल ही में Roast को open source किया। यह एक ऐसा tool है जो विशाल codebase automation में non-deterministic LLM tasks को workflow के भीतर insert कर सकता है। complex work automation के लिए यह आवश्यक बताया गया
  • Roast काफ़ी प्रभावशाली लगा। determinism और non-determinism का मेल बहुत उभरकर आता है। थोड़ी उलझन यह है कि LLM कई tool calls को कैसे orchestrate करता है और call order कैसे तय कर सकता है। refactoring instructions पर यह काम करता हुआ लगता है, लेकिन "improve → test repeat" जैसे complex tasks के लिए यह उपयुक्त है या नहीं, इस पर जिज्ञासा जताई गई
  • यह ताज़गीभरा लगा कि Ruby, AI युग में भी लगातार सार्थक रूप से काम कर रही है
  • सिर्फ documentation पढ़कर भी बौद्धिक उत्तेजना मिलती है; LLM capability को declarative तरीके से package करने का अंदाज़ प्रभावशाली लगा
  • Shopify के भीतर वास्तव में ऐसे workflows कैसे उपयोग होते हैं, इसके ठोस उदाहरण साझा करने का अनुरोध
  • Claude Code Research Preview और ChatGPT 4.5 Pro Deep Research दोनों को crash करा देने का अनुभव रहा है (और उसके सबूत भी हैं), इसलिए अब ऐसे tools की तलाश है जो भरोसेमंद तरीके से काम करें
• सबसे अच्छा जवाब किसी एक छोर पर नहीं, बल्कि hybrid approach में है। जितना हो सके deterministic तरीकों से हल करें, और LLM का उपयोग केवल उन जटिल हिस्सों में करें जहाँ specification या deterministic techniques मुश्किल हों
  • LLM का उपयोग deterministic solution (code) generate करने पर केंद्रित करना, और code validate हो जाने के बाद उसे आगे deterministic code के रूप में reuse करना एक दिलचस्प approach है
  • workflow के भीतर LLM उपयोग को न्यूनतम रखना ही लक्ष्य होना चाहिए, ऐसा तर्क दिया गया
• एक साल से ज़्यादा समय तक industry से बाहर रहने के बाद यह देखकर हैरानी हुई कि क्या ऐसे complex experiments अब सामान्य हो गए हैं
  • वास्तव में अभी भी बहुत कम लोग प्रयोग कर रहे हैं; कोई revolutionary case नहीं है, लेकिन कुछ उपयोगी cases ज़रूर हैं
  • यह राय भी आई कि अगर अभी ऐसे काम नहीं किए, तो शायद जल्द ही फिर से industry से बाहर होना पड़ेगा
  • किसी ने कहा कि उसका रोज़मर्रा का काम पहले ही LLM-आधारित AI agent design automation पर केंद्रित हो चुका है। उसने जानबूझकर नहीं चुना, लेकिन धीरे-धीरे वही हो गया
• यह सवाल उठा कि structured data sorting के लिए LLM का उपयोग क्यों किया जाए
  • मुख्य उद्देश्य dashboard बनाना, issue tickets की automatic पहचान, quarterly review जैसी अधिक complex data processing है। sorting तो सिर्फ़ एक simple example है, जो समस्या के पैमाने को समझाने के लिए दिया गया था
• huggingface smolagent इस approach का एक प्रतिनिधि उदाहरण है, लेकिन वास्तविक operation fail होने पर rollback या recovery बहुत कठिन हो जाती है। execution block के पूरे हिस्से को distributed transaction से wrap करना जैसे सैद्धांतिक समाधान संभव हैं, लेकिन व्यवहार में LLM जब robust code बनाने की कोशिश करता है तो यह pattern उससे मेल नहीं खाता, जिससे error tracing और failure cause analysis मुश्किल हो जाती है
  • smolagent का बुनियादी विचार अच्छा है, लेकिन execution और error handling की वास्तविकता समस्या है। उदाहरण के लिए, यदि code execution रुक जाए, तो उसी state से सीधे आगे बढ़ सकना वांछनीय है। यह पुष्टि की गई कि LLM state recovery code अच्छी तरह लिख सकता है, और फ़िलहाल यह capability वास्तविक product (Lutra) में काफ़ी अच्छी तरह काम कर रही है
• एक और approach के रूप में, LLM को ऐसा code (Python script के रूप में) लिखने के लिए प्रेरित किया जाता है जो MCP को function की तरह call करे। example code साझा किया गया
  • इस तरीके के production use case के रूप में Lutra.ai का परिचय दिया गया। मुख्य बात इस पर निर्भर है कि code runtime कितनी अच्छी तरह design किया गया है
• यह तथ्य सामने आया कि LLM विशेष रूप से JSON, खासकर large JSON processing में कमज़ोर हैं। endpoint चाहे तो JSON के बजाय किसी अन्य format में data return कर सकता है। LLM कभी-कभी xml में कहीं बेहतर क्षमता दिखाते हैं, और template के ज़रिए narrative text में बदलने का तरीका भी संभव है
  • XML एक ऐसा format है जिसमें अंतर्निहित semantic information होती है, इसलिए यह हैरानी की बात है कि LLM defaults में इसका व्यापक उपयोग नहीं होता। ज़रूरत पड़ने पर XML को deterministic तरीके से JSON में बदलकर pipeline में डालना प्रभावी हो सकता है
  • LLM को data return करते समय Markdown tables का उपयोग कर काफ़ी अच्छे परिणाम देखने का अनुभव साझा किया गया
  • यह जिज्ञासा भी जताई गई कि XML का बेहतर प्रदर्शन इसलिए है क्योंकि वह LLM training data में ज़्यादा बार आता है, या इसलिए कि उसमें text tokens अधिक होते हैं। यह भी कहा गया कि text blocks शायद LLM को अधिक context दे पाते हैं