मैंने पिछले हफ्ते production में एक agent बंद कर दिया। 30 लाइनों के Python से replace किया। Script तेज है, सस्ती है, कभी hallucinate नहीं करती, और मैं बेहतर सोता हूं। यह AI agents का उपयोग कब न करें की कहानी है, किसी ऐसे व्यक्ति द्वारा बताई गई जो उन्हें जीविका के लिए बनाता है।
Agent hype में एक अंधा स्थान है। हर कोई agents कैसे बनाएं के बारे में लिख रहा है। लगभग कोई नहीं लिख रहा कि agent कब गलत tool है — और यही अधिक उपयोगी कौशल है, क्योंकि जब आपको for loop चाहिए था तब reasoning loop का उपयोग करना इस पूरी जगह में सबसे महंगी गलती है।
संकेत: क्या कार्य deterministic है?
यहाँ मेरा पहला filter है। अगर एक ही input हमेशा एक ही output produce करे, आपको agent नहीं चाहिए। आपको code चाहिए।
CSV को JSON में parse करना। Files को एक pattern से rename करना। API call करना और response reshape करना। यह validate करना कि हर record में एक email field है। ये deterministic हैं। एक agent ये करेगा, ज़रूर, लेकिन यह धीरे-धीरे, महंगे तरीके से, और शून्य से अधिक probability के साथ बिना संकेत के आपके schema को "improve" करने का निर्णय ले सकता है। एक script इन्हें milliseconds में मुफ्त में, हर बार एक ही तरह से करती है।
अनुभव का नियम: agents उन कार्यों के लिए हैं जहाँ रास्ता अज्ञात है। अगर आप steps लिख सकते हैं, steps लिखें। हर run पर model को उन्हें फिर से खोजने के लिए भुगतान न करें।
जहाँ agents वास्तव में अपना मूल्य साबित करते हैं
Agents तब चमकते हैं जब कार्य में genuine ambiguity हो जिसके लिए runtime पर judgment की ज़रूरत हो। "इस failing test को देखो, पता लगाओ क्यों, इसे ठीक करो।" "इस गड़बड़ support ticket को पढ़ो और route करो।" "इन तीन आधे-टूटे approaches को देखते हुए, एक चुनो और इसे finish करो।" Path इस आधार पर branch करता है कि agent क्या discover करता है। आप इसे pre-script नहीं कर सकते क्योंकि आप नहीं जानते कि आप क्या पाएंगे।
यही dividing line है। अज्ञात path, runtime judgment, fuzzy input। अगर आपके कार्य में तीनों हैं, agent। अगर कोई भी नहीं है, script। दिलचस्प cases बीच में हैं, और वहीं लोग गलत करते हैं — वे थोड़ी ambiguity देखते हैं और full reasoning loop के लिए पहुंचते हैं जबकि बीच में एक LLM call वाली script ने काम कर लिया होता।
Hybrid आमतौर पर जवाब है
मेरा पसंदीदा pattern "agent" या "script" नहीं है। यह एक script है जो एक focused model call करती है जहाँ judgment वास्तव में रहता है।
# Agent नहीं। एक pipeline जिसमें एक जगह दिमाग है।
rows = parse_csv(path) # deterministic
for r in rows:
r["category"] = classify(r) # एक LLM call, structured output
write_json(rows) # deterministic
classify call fuzzy भाग करती है — freeform text पढ़ना और उसे bucket करना। इसके आसपास सब कुछ plain code है। कोई multi-turn loop नहीं, कोई tool-use dance नहीं, कोई agent आपके filesystem को explore करने का निर्णय नहीं लेता। आप model का judgment ठीक वहाँ पाते हैं जहाँ आपको चाहिए और कहीं नहीं। यह agent की तुलना में एक order of magnitude सस्ता है और आप इसे वास्तव में test कर सकते हैं।
एक loop की cost जो आपको नहीं चाहिए थी
पैसे की बात करते हैं, क्योंकि bills असली हैं। एक agent जो loop करता है — read, think, call tool, observe, think again — हर single turn पर growing context को फिर से भेजता है। एक कार्य जो आठ turns लेता है वह आपकी पूरी conversation को आठ बार फिर से process कर सकता है। मैंने एक "simple" agentic task को उस पूरे codebase से अधिक tokens burn करते देखा है जिस पर वह काम कर रहा था, क्योंकि यह उन files को बार-बार re-read कर रहा था जिन्हें वह पहले से पढ़ चुका था।
एक deterministic task के लिए, यह शुद्ध waste है। आपने reasoning के लिए भुगतान किया जिसकी task को ज़रूरत नहीं थी। इसे hourly चलने वाले cron job पर multiply करें और आपने एक money incinerator बनाया है जिसे एक sed command ने replace किया होता।
Latency और trust, शांत costs
कुछ ऐसा भी है जो invoice पर नहीं दिखता। Agents धीमे हैं। Tool calls के साथ एक reasoning loop seconds से minutes लेता है। अगर आप इसे user-facing hot path में डाल रहे हैं — जैसे, form submission validate करना — आपने अपना product broken feel कराया है एक regex लिखने से बचने के लिए।
और trust। एक script जो गलत है वह predictably गलत है; आप bug ठीक करते हैं और यह हमेशा के लिए ठीक है। एक agent जो गलत है वह creatively गलत है, हर बार अलग, और इसे "ठीक" करने का मतलब है एक prompt tweak करना और pray करना। किसी भी चीज के लिए जहाँ correctness non-negotiable है — money movement, auth, data deletion — मैं code चाहता हूं जिसे मैं पढ़ सकता हूं और एक test जिसे मैं run कर सकता हूं, न एक model जिसे मैं केवल nudge कर सकता हूं।
मेरी actual checklist
किसी task को agent होने देने से पहले, इसे इन सबसे pass होना होगा:
- Path वास्तव में इस आधार पर vary करता है कि हम runtime पर क्या पाते हैं।
- एक इंसान को इसे करने के लिए judgment की ज़रूरत होगी, न केवल rule-following की।
- Input इतना messy है कि code इसे reliably parse नहीं कर सकता।
- Output में occasional weirdness survivable है।
कोई भी एक fail हो? यह शायद एक script है, या एक script जिसमें एक single LLM call bolt in हो।
असुविधाजनक सच्चाई
हर चीज़ को agent बनाने का push partially tooling companies आपको agents बेच रही है। बेशक agent framework हर problem को एक agent problem बनाना चाहता है। यही business model है।
आपका काम narrower और अधिक honest है: problem को कम से कम machinery से solve करें जो काम करे। कभी-कभी यह एक sophisticated multi-agent system है। अक्सर यह एक Python file है जिसे आप 2015 में लिख सकते थे। Senior move यह जानना है कि कौन सा, और boring वाले को ship करने के लिए बहुत proud न होना। मेरी production script में reasoning loop नहीं है। इसने मुझे एक बार भी page नहीं किया।