AI एजेंट्स और ऑटोमेशन

AI observability वह तकनीक है जो दिखाती है कि production में आपके LLMs और agents असल में क्या करते हैं — कौन-सा model, कौन-से tools व searches, क्या लौटाया, और कितना समय व लागत — ताकि कुछ टूटने पर आप कारण तक पीछे जा सकें। सामान्य app monitoring से निर्णायक अंतर: AI 50ms में 200 OK लौटा सकता है और फिर भी आत्मविश्वास से hallucinate कर सकता है, इसलिए अधिकांश AI विफलताएँ infrastructure नहीं, गुणवत्ता विफलताएँ हैं। तीन स्तंभ: traces, metrics, logs. उद्योग मानक OpenTelemetry GenAI conventions इन्हें vendor-neutral schema में संभालते हैं। यह लेख observability बनाम evals का अंतर, देखने योग्य metrics, और प्रमुख tools (LangSmith/Langfuse/Phoenix/MLflow/AgentOps/OpenTelemetry) समझाता है।

"Multi-agent system क्या है?" में अवधारणा समझने के बाद, यह व्यावहारिक अगला कदम है। 2026 के वास्तविक मानक supervisor pattern से शुरुआती लोगों को 5-चरण में बनाना सिखाता है। मुख्य सिद्धांत: पहले एकल agent बनाएँ और सीमा से टकराने पर ही न्यूनतम स्तर पर agents जोड़ें (लगभग 80% उपयोग एक से चल जाते हैं; सीधे-सादे काम में multi से लागत 3-10x बढ़ती है और Google शोध के अनुसार क्रमिक कार्यों में सटीकता −39-70% गिरती है)। multi अपनाने के 3 संकेत: विशेषज्ञता विभाजन, समानांतरता, निर्णय पृथक्करण। supervisor pattern (supervisor पूरा कार्य लेता है, बाँटता है, workers को सौंपता है, परिणाम जोड़ता है) पर Claude Code subagents, LangGraph Supervisor और OpenAI Agents SDK handoffs सभी मिल गए हैं — व्यापक framework समर्थन, ज्ञात failure mode और आसान audit के कारण। 5 चरण: 1) कार्य साफ़-साफ़ विभाजित करें; 2) एक भूमिका + tools + output format वाले workers (अधिकतम 3-5); 3) supervisor डिज़ाइन करें, बुलाने योग्य नाम सूचीबद्ध करें (hard cap); 4) handoff और context साझाकरण तय करें, केवल ज़रूरी सौंपें (मानक A2A); 5) agents जोड़ने से पहले हर handoff मापें, सीमाएँ लगाएँ, evals और guardrails तैयार करें। छद्म-कोड workers, hard-capped supervisor और iteration-bounded loop दिखाता है। आम गलतियाँ और समाधान: over-delegation, token का फूलना, अस्थिरता, सटीकता गिरना, अज्ञात विफलता-बिंदु। साझा सबक: सफलता framework से ज़्यादा prompts, tools और eval harness तय करते हैं। छोटा बनाएँ, मापें, तभी जोड़ें जब फ़ायदेमंद हो।

"एक AI agent जिस जटिल काम को अकेले नहीं संभाल सकता, उसे कई agents में बाँट देना" — यही multi-agent systems की सोच है। यह शुरुआती-अनुकूल गाइड इसकी कार्यप्रणाली, मुख्य पैटर्न और प्रमुख frameworks बताती है, और सबसे ज़रूरी बात, बिना अतिशयोक्ति के असली निर्णय-नियम कि कब कई agents इस्तेमाल करें और कब एक ही काफी है। एक multi-agent system में अलग-अलग भूमिकाओं वाले कई AI एक बड़े काम पर मिलकर काम करते हैं; सब कुछ अकेले करने वाले single agent (जो ~80% use cases के लिए ठीक, सस्ता और debug में आसान है) के मुकाबले यह काम को विशेषज्ञता से बाँटता है ताकि समानांतर निष्पादन और आपसी जाँच हो सके, पर coordination लागत और token खपत ज़्यादा होती है। चार प्रमुख orchestration पैटर्न हैं: orchestrator-worker (लीड बाँटता, workers को समानांतर भेजता, और जोड़ता है; सबसे प्रचलित, audit trail के साथ), sequential handoff (संदर्भ अगले agent को सौंपना), group conversation (agents एक thread में बहस करते हैं, selector तय करता है कौन बोले; सत्यापन के लिए अच्छा), और graph state machine (agents nodes, transitions edges, स्पष्ट state; branching और checkpoints में मज़बूत)। Frameworks 2026 में LangGraph (सबसे बड़ा production आधार), CrewAI (सबसे कम सीखने की मेहनत, prototyping), AutoGen/AG2 (बहस और सत्यापन, रिसर्च), और OpenAI Swarm (हल्के handoffs) में सिमट गए। पर यह रामबाण नहीं: जटिल बहु-क्षेत्रीय कामों पर reasoning benchmarks में +23% तक, फिर भी एक-रास्ते sequential कामों पर Google रिसर्च में single agent बनाम -39-70%, एक agent को वही compute दें तो वह अक्सर बराबरी या बढ़त लेता है, और 10 में से 7 deployments में ~15x token खपत पर बिना ROI लागत बढ़ी (औसत ROI 2.5-3.5x, सही निशाने पर शीर्ष चौथाई 4-6x)। अनुशंसित रास्ता: पहले single बनाएँ, एक ठोस छत पहचानें (धुँधली भूमिकाएँ, समानांतर होने योग्य काम), फिर cost cap और logging के साथ न्यूनतम 2-3 agent लीड-पैटर्न टीम जोड़ें, और मापें कि सटीकता में बढ़त वृद्धि को सही ठहराती है या नहीं। A2A (communication protocol) और MCP (tool connection) multi-agent को सहारा देने वाली बुनियादी तकनीक हैं। 80% के लिए single, सिर्फ़ कठिन हिस्सों के लिए multi। आँकड़े सर्वेक्षणों और रिसर्च से लिए गए, परिस्थिति-निर्भर और दिशासूचक हैं।

अब जब AI एजेंट आम हो चुके हैं, अगली चुनौती है एजेंट्स को आपस में कैसे सहयोग करवाया जाए। अगर MCP किसी एजेंट को उसके tools से जोड़ता है, तो A2A (Agent2Agent) एक एजेंट को दूसरे एजेंट से जोड़ता है — एक open standard जिससे अलग-अलग vendors और frameworks पर बने AIs एक साझा परंपरा के ज़रिए खोज, संवाद और सहयोग कर सकें। Google ने इसे अप्रैल 2025 में रिलीज़ किया, उसी जून में Linux Foundation को दान किया, और 2026 में यह v1.0 तक पहुँचा। यह शुरुआती गाइड बताती है कि A2A क्या है (कंपनियों की व्यापारिक साझेदारी के शिष्टाचार जैसा), यह क्यों ज़रूरी है (विशेषज्ञ एजेंट काम को रिले करते हैं — एक planning एजेंट से hotel-booking एजेंट से payment एजेंट तक), MCP से इसका अंतर (MCP vertical है, agent ↔ tools; A2A horizontal है, agent ↔ agent; दोनों को एक साथ लगाना ही standard दो-स्तरीय सेटअप है), यह कैसे काम करता है (एक Agent Card — /.well-known/agent-card.json पर रखा एक JSON "विज़िटिंग कार्ड" — से क्षमताएँ discover होती हैं, फिर एक Task working, input-required, completed जैसी states के साथ request ले जाता है, और एक Artifact result लौटाता है, यह सब HTTP, Server-Sent Events, और JSON-RPC 2.0 पर होता है, जबकि एजेंट अपने आंतरिक हिस्से छिपे रखते हैं), तथा इसकी वर्तमान स्थिति और implementation (अप्रैल 2026 तक, 150+ संगठन production में, 22,000+ GitHub stars, पाँच भाषाओं में SDKs — Python, JavaScript, Java, Go, .NET — और Microsoft, Salesforce, SAP, ServiceNow शामिल)। याद रखने का तरीका: tools से जुड़ना = MCP, peers से जुड़ना = A2A।

आपने RAG तो बना लिया, पर search की क्वालिटी औसत है — ठीक यहीं reranking काम आती है। Reranking, embedding (vector) search से मोटे तौर पर जुटाए गए candidates को query से उनकी relevance के आधार पर फिर से score करती है और उन्हें फिर से क्रम में लगाकर सिर्फ़ टॉप वाले रखती है; यह एक कदम किसी RAG सिस्टम के जवाब की क्वालिटी को नाटकीय रूप से बदल सकता है। यह शुरुआती गाइड बताती है कि reranking क्या है (पहली-छँटाई-और-आख़िरी-इंटरव्यू वाली उपमा), यह क्यों ज़रूरी है (embedding search query और दस्तावेज़ों को अलग-अलग vector में बदलता है, इसलिए relevance को सिर्फ़ मोटे तौर पर आँकता है, और ख़राब क्रम सीधे जवाब की क्वालिटी घटाता है — शोध reranking जोड़ने से करीब 40% RAG सटीकता सुधार की रिपोर्ट करते हैं, और इसे hybrid search पर चढ़ाना 2026 का मानक है), two-stage retrieval कैसे काम करती है (recall के लिए तेज़ embedding search से "व्यापक रूप से जुटाएँ," फिर precision के लिए reranker से "समझदारी से छाँटें," फिर टॉप को LLM को सौंपें), reranker ज़्यादा सटीक क्यों है (bi-encoder query और दस्तावेज़ को अलग-अलग vector में बदलता है, तेज़ पर अनुमानित; cross-encoder उन्हें एक साथ feed करके 0–1 relevance score देता है, सटीक पर भारी — इसलिए तेज़ bi-encoder से जुटाएँ और सटीक cross-encoder से छाँटें), और मॉडल व implementation (API प्रकार जैसे Cohere Rerank, Voyage, Jina; open-source जैसे BGE reranker, mixedbread, FlashRank; और LLM-आधारित scoring जैसे RankLLM — बस 50–100 retrieve करें और टॉप 5 तक छाँटें)। सिद्धांत: व्यापक रूप से जुटाएँ, समझदारी से छाँटें, और संख्याओं को AI evals से ट्यून करें।

जब आप AI ऐप्स बनाना सीख जाते हैं, तो अगला चरण उन्हें सुरक्षित रूप से चलाना है। LLMs को दुर्भावनापूर्ण input से धोखा दिया जा सकता है, वे गोपनीय डेटा लीक कर सकते हैं, या आत्मविश्वास के साथ बेतुकी बातें ठोक सकते हैं; इसे रोकने वाला सुरक्षा तंत्र ही AI guardrails है, जो 2026 में AI agent की घटनाओं के असल में होने के साथ production का अनिवार्य हिस्सा बन चुका है। guardrails वे नियम और फ़िल्टर हैं जो खतरनाक input और अवांछित output को रोकते हैं, user input को LLM तक पहुँचने से पहले और जवाब को वापस लौटने से पहले जाँचते हैं — model से अलग एक स्वतंत्र सुरक्षा परत। मुख्य खतरे हैं prompt injection (सबसे बड़ा), jailbreak, डेटा लीक (गोपनीय डेटा, PII, system prompt), और hallucination या हानिकारक output। सुरक्षा दो परतों पर काम करती है: input guardrails (injection और jailbreak का पता लगाना, PII पहचानना/mask करना, विषय सीमित करना, sanitize करना) और output guardrails (हानिकारक सामग्री फ़िल्टर करना, लीक रोकना, hallucination जाँचना, format सत्यापित करना)। prompt injection — OWASP LLM Top 10 में सबसे गंभीर — direct (user "पिछले सभी निर्देश अनदेखा करो" टाइप करता है) और indirect (वेब पेज या RAG दस्तावेज़ में छिपे आदेश) रूपों में आता है, और indirect injection को अकेला RAG नहीं रोकता, इसलिए retrieved दस्तावेज़ों की अपनी जाँच चाहिए। यह शुरुआती गाइड tools (LLM Guard, Guardrails AI, NeMo Guardrails, Llama Guard, और Azure, AWS व OpenAI की cloud safety सुविधाएँ) तथा defense in depth, least privilege, मानव की मंज़ूरी और लगातार निगरानी के व्यावहारिक सिद्धांतों को भी कवर करती है।

RAG, semantic search और सिफ़ारिशें सभी एक अनसुने मेहनती कारीगर पर निर्भर हैं: embedding (vector)। embedding टेक्स्ट (या छवि) के अर्थ को संख्याओं की एक श्रृंखला — एक vector — में बदलना है। "कुत्ता" शब्द सैकड़ों से हज़ारों संख्याओं की सूची बन जाता है जो "अर्थ के निर्देशांक" की तरह काम करती है, इसलिए अर्थ में नज़दीक शब्द पास-पास बैठते हैं ("कुत्ता" और "पिल्ला" नज़दीक; "कुत्ता" और "कार" दूर), और नज़दीकी को cosine similarity जैसे मापों से आँका जाता है। प्रसिद्ध उदाहरण: "राजा − पुरुष + स्त्री ≈ रानी"। इसी कारण, अक्षर मेल न खाने पर भी मशीन यह आँक सकती है कि अर्थ नज़दीक है या नहीं। यह शुरुआती गाइड बताती है कि embedding क्या है (एक "अर्थ का नक्शा"), नज़दीकी से अर्थ क्यों मापा जाता है (dimensions और cosine similarity), इसका उपयोग कहाँ होता है (RAG, semantic search, वर्गीकरण और दोहराव-हटाना, सिफ़ारिशें और multimodal), embedding model कैसे चुनें (API प्रकार जैसे OpenAI text-embedding-3, Cohere, Gemini, Voyage; open-source जैसे BGE-M3, Nomic, Qwen3; साथ ही Matryoshka, जो 3,072 dimensions को 1,024 तक घटाकर लगभग एक-तिहाई लागत पर लगभग 95% गुणवत्ता बनाए रखता है), और vector DB (Pinecone, Weaviate, Qdrant, Chroma, pgvector) के साथ तीन-चरण शुरुआत (model चुनें, दस्तावेज़ vector में बदलकर संग्रहित करें, सवाल को vector में बदलकर search करें)। embedding, RAG लागू करने की नींव हैं।

आपने prompts निखारे, RAG से ज्ञान जोड़ा, शायद fine-tuning भी की — तो कैसे पक्का करें कि यह सचमुच बेहतर हुआ? यहीं AI evals मुख्य भूमिका में आते हैं, और 2026 तक मूल्यांकन इतना ज़रूरी है कि इसे "infrastructure" कहा जाता है। AI evals का मतलब है किसी LLM के आउटपुट की गुणवत्ता (सटीकता, hallucinations, फ़ॉर्मैट पालन, लहजा) को अंदाज़े के बजाय एक तय पैमाने पर व्यवस्थित रूप से मापना; इनके बिना सुधार महज़ एक अंदाज़ा है। दो तरीके हैं: यांत्रिक रूप से मापने योग्य बातों के लिए code-based मूल्यांकन (सटीक मिलान, फ़ॉर्मैट, ज़रूरी/प्रतिबंधित शब्द — तेज़, सस्ता, स्थिर) और व्यक्तिपरक बातों के लिए LLM-as-judge (किसी शक्तिशाली LLM को रेफ़री बनाकर pairwise तुलना या एकल-आउटपुट स्कोरिंग से आँकना)। सिद्धांत: जो कोड माप सकता है उसे कोड से ही मापें। LLM-as-judge में verbosity, position और self-preference biases होती हैं; उपाय हैं अलग परिवार के मॉडल को मूल्यांकनकर्ता बनाना, क्रम बदलकर दो बार आँकना, rubric में संक्षिप्तता डालना, और मानवीय निर्णय के विरुद्ध calibrate करना। मोटे पैमाने (pass/fail या 1–3) बारीक 1–10 से बेहतर हैं। व्यवहार में तीन स्तर चलाएँ — हर बदलाव पर तुरंत code जाँच, रात्रिकालीन LLM-judge regression टेस्ट, और लगातार प्रोडक्शन निगरानी — CI के लिए DeepEval, Promptfoo, RAGAS तथा निगरानी के लिए Braintrust, LangSmith, Arize जैसे उपकरणों के साथ। शुरुआत 10 अच्छे और 10 बुरे आउटपुट इकट्ठा करके और उन्हें स्कोर करके करें।

जिस युग में कोड AI लिखता है, वहाँ ज़्यादा मूल्यवान कौशल "कोड लिखने" से बदलकर "spec लिखने" की ओर जा रहा है — और इस बदलाव को दर्शाने वाला तरीका है Spec-Driven Development (SDD)। SDD में spec परियोजना के केंद्र में सत्य के स्रोत के रूप में रहता है, और एक AI agent तुरंत कोड लिखने के बजाय उसी से डिज़ाइन, विभाजन और इम्प्लीमेंटेशन निकालता है। अहम बात यह है कि हर चरण एक दस्तावेज़ (अक्सर Markdown) छोड़ता है जिसे अगला चरण पढ़ता है। यह शुरुआती-अनुकूल गाइड बताती है कि SDD क्या है (spec ही प्रामाणिक है; कोड एक व्युत्पन्न है), अभी यह क्यों मायने रखता है (यह vibe coding की तकनीकी ऋण और आवश्यकताओं के खिसकने वाली "तीन महीने की दीवार" को डिज़ाइन चरण में ही रोकता है — GitHub के अनुसार "शून्य से दोबारा बनाने" वाले चक्र लगभग दस गुना घटे), बुनियादी चार चरण (Specify → Plan → Tasks → Implement), प्रमुख टूल (90,000+ स्टार और 30 से ज़्यादा समर्थित agent वाला GitHub Spec Kit, Requirements → Design → Tasks प्रवाह और Auto router वाला AWS Kiro, साथ ही BMAD, OpenSpec, Tessl, Google Antigravity और Cursor), इसका उपयोग कब बनाम vibe coding (एक हाइब्रिड: खोजबीन के लिए vibe, डिलीवरी के लिए spec-driven, अनिवार्य इंसानी समीक्षा के साथ), और आज से इसे कैसे आज़माएँ। AI के युग में वे लोग आगे बढ़ते हैं जो ठीक-ठीक परिभाषित कर सकते हैं कि क्या बनाना है, न कि वे जो सबसे तेज़ कोड लिखते हैं।

AI के साथ काम करने में ध्यान का केंद्र prompt engineering से context engineering की ओर खिसक रहा है। Anthropic की परिभाषा उधार लें तो, context engineering है "उन रणनीतियों का समूह जिनसे आप inference के दौरान मॉडल को सौंपे जाने वाले tokens (जानकारी) के सबसे उपयुक्त समूह को चुनते और बनाए रखते हैं" — जो केवल prompt को नहीं, बल्कि context window की हर चीज़ को कवर करता है: system prompt, tools, बातचीत की history, और बाहरी डेटा। यह "context rot" के कारण मायने रखता है: आप जितने ज़्यादा tokens जोड़ते हैं, सटीकता असल में उतनी ही घटती है। Chroma के 2025 अध्ययन ने 18 अग्रणी मॉडलों (GPT, Claude, Gemini और अन्य) का परीक्षण किया और हर एक input के लंबा होते जाने के साथ कमज़ोर पड़ा, जहाँ लंबे context के बीच में रखी जानकारी को नज़रअंदाज़ करना खासकर आसान था ("lost in the middle")। यह शुरुआती-अनुकूल गाइड बताती है कि context engineering क्या है और prompt engineering से इसका क्या संबंध है, context rot क्यों होता है (attention एक सीमित बजट है), context में असल में क्या होता है, छह मुख्य तकनीकें (सही ऊँचाई पर निर्देश, tool चयन, just-in-time retrieval, compaction/सारांश संपीडन, बाहरी memory notes, और sub-agent अलगाव), RAG व Claude Skills से इसका संबंध, और आज से अपनाई जा सकने वाली आदतें जैसे विषय बदलने पर नया session शुरू करना और केवल मुख्य बिंदु पेस्ट करना। मूल विचार: केवल सबसे छोटे, सबसे उपयोगी tokens रखें।

Claude Skills (Agent Skills) पर एक शुरुआती-अनुकूल गाइड — वह व्यवस्था जो Claude को बार-बार वही प्रक्रिया समझाने की झंझट खत्म कर देती है। एक Skill निर्देशों, scripts और संदर्भ सामग्री को एक ही फ़ोल्डर में पैक करती है, जिसका केंद्र एक SKILL.md फ़ाइल होती है जिसमें name, description और चरण रहते हैं। ज़्यादातर समय Claude सिर्फ़ हर skill की छोटी description पढ़ता है, और body को तभी खोलता है जब आपका अनुरोध उससे मेल खाता है — इस डिज़ाइन को progressive disclosure कहते हैं, जो दर्जनों skills इंस्टॉल होने पर भी आपके context को हल्का रखता है। यह लेख बताता है कि Skills क्या हैं, ये क्यों मायने रखती हैं (हर बार prompt चिपकाने का अंत), SKILL.md और न्यूनतम फ़ोल्डर संरचना कैसे लिखें, इसे कैसे बनाएं (आधिकारिक skill-creator या खुद हाथ से, .claude/skills में डालकर, जनवरी 2026 के तुरंत-रीलोड के साथ), Skills MCP (connectivity) और subagents (context अलगाव) से कैसे अलग हैं, वह open standard जिसे अब Claude apps, Claude Code, API और Agent SDK के अलावा Codex CLI, Cursor, Gemini CLI तथा GitHub Copilot ने भी अपनाया है, साथ ही दस्तावेज़ निर्माण और आंतरिक नियम लागू करने जैसे ठोस इस्तेमाल। Anthropic ने इसे 16 अक्टूबर 2025 को घोषित किया, और Simon Willison ने इसे "शायद MCP से भी बड़ी बात" कहा।

"मैंने एक AI से कहा और उसने ब्राउज़र खोला, चीज़ें ढूँढीं, और एक form भी भर दिया।" 2026 में यह अब कोई दिखावटी demo नहीं रहा: agentic browsers (ChatGPT Atlas, Claude for Chrome, Gemini/Chrome, Perplexity Comet) एक साथ आ गए। तो ये असल में कहाँ तक automate करते हैं? हकीकत साफ़-साफ़ तीन स्तरों में बँट जाती है। (1) रिसर्च = production-ready: WebVoyager (असली sites) पर शीर्ष agents 89-98% तक पहुँचते हैं, और चूँकि ग़लत action की क़ीमत कम है, सौंपना यहीं से शुरू करें। (2) Form भरना = हो सकता है, पर जाँचें: इनपुट खुद समर्थित है, फिर भी agents fields को ग़लत label दे सकते हैं या ग़लत submit दबा सकते हैं, इसलिए "AI draft करे, इंसान भेजे" सुरक्षित है। (3) बुकिंग/भुगतान = अभी भी खुद करें: agents CAPTCHA, जटिल JavaScript checkout, two-factor auth और session management पर लड़खड़ाते हैं, और WebArena पर सबसे बेहतरीन भी क़रीब 47-68% ही पाते हैं (~78% इंसानी baseline के मुक़ाबले); OpenAI ने स्वतंत्र Operator (2025/8/31) इसी checkout अविश्वसनीयता के कारण बंद किया। लेख पहले दो तरीके बताता है (उपभोक्ता ब्राउज़र/extension बनाम डेवलपर API/OSS), फिर 2026 के खिलाड़ी मैप करता है, बुकिंग विफल होने की चार दीवारें समझाता है, और सबसे बड़े खतरे — indirect prompt injection — में गहराई से उतरता है (Comet zero-click credential चोरी के प्रति कमज़ोर दिखा और फ़रवरी 2026 में ठीक हुआ; बचाव से पहले 23.6% सफलता बुनियादी बचाव से ~11% और सबसे मज़बूत से ~1% तक घटती है, फिर भी शून्य नहीं)। अंत में पाँच सुरक्षा सिद्धांत। एक बेहतरीन रिसर्च साथी; पैसा हिलाने वाले काम खुद करें।