उन्नत

AI agents बनाना जो वाकई काम करें

Agents demos में revolutionary sound करते हैं। फिर आप एक deploy करते हैं और यह एक API call को hallucinate करता है, आपका rate limit burn कर देता है, और आपके CEO को Telegram पर सुबह 3 बजे एक nonsense message भेज देता है। यहाँ देखें कैसे ऐसे agents build करें जो reality के contact में survive करें।
Sarah Chen March 2026 15 min read

एक AI agent एक LLM है जिसमें actions लेने की क्षमता है। सिर्फ text generate करने के बजाय, यह APIs call कर सकता है, databases query कर सकता है, messages भेज सकता है, workflows trigger कर सकता है, और loop में decisions ले सकता है। Promise automation है: एक system जो constant human supervision के बिना tasks handle करे।

Reality ज्यादा nuanced है। Agents clear boundaries वाले well-scoped tasks के लिए brilliantly perform करते हैं। जब उन्हें vague goals, unrestricted tool access और कोई guardrails नहीं दिए जाते तो वो spectacularly collapse होते हैं। Demo agent और production agent के बीच का फर्क LLM नहीं है — यह LLM के around सब कुछ है।

Agent actually क्या है

Hype strip कर दें और एक agent में चार components हैं:

LLM (the brain — decides what to do) + Tools (MCP servers — GitHub, databases, search, etc.) + Channels (Telegram bot, Discord bot, webhooks) + Triggers (cron schedules, events, user messages)

LLM input receive करता है (user message, scheduled trigger, event)। यह decide करता है कौनसे tools call करने हैं। उन्हें MCP servers के through call करता है। Results receive करता है। Decide करता है आगे क्या करना है। यह loop तब तक चलता है जब तक task complete न हो जाए या agent stop करने का decide न कर ले।

Theory में simple। Devil हर detail में है।

Zubnet में एक agent build करना

Platform पर, एक agent create करने में चार steps involve हैं। हर एक में decisions हैं जो determine करेंगे कि आपका agent reliably काम करता है या 3 AM calls का एक source बन जाता है।

1. Agent create करें

उसे एक name दें, एक model choose करें, और एक system prompt लिखें।

Model आपकी सोच से ज्यादा matter करता है। ऐसे agents के लिए जिन्हें reliably tools call करने हैं, एक strong reasoning model use करें। Claude Sonnet 4, GPT-4.1 या Gemini 2.5 Pro। Smaller models पैसे बचाते हैं लेकिन worse tool-calling decisions लेते हैं, और agent में एक bad tool call सिर्फ एक wrong answer नहीं है — यह एक wrong action है।

System prompt आपके agent का constitution है। इन बारे में explicit रहें:

Agent को क्या करना चाहिए (और क्या कभी नहीं करना चाहिए)
• हर tool कब use करें और कब skip करें
• Errors और ambiguity को कैसे handle करें
• User से clarification कब माँगें vs. decision लें
• Messages में क्या tone use करें

Agent system prompts में #1 mistake:

बहुत vague होना। “तुम एक helpful assistant हो जो हमारे GitHub repo को manage करता है” एक ऐसे agent की तरफ ले जाएगा जो random issues create करता है, ऐसी चीजें close करता है जो उसे नहीं करनी चाहिए, और बिना review के PRs merge करता है। “तुम GitHub issues create कर सकते हो जब users #bugs channel में bugs report करें। तुम्हें कभी issues close नहीं करनी चाहिए, PRs merge नहीं करने चाहिए या repository settings modify नहीं करनी चाहिए।” — वो एक system prompt है जो एक reliable agent produce करता है।

2. एक channel connect करें

Channels वो हैं जिनसे agents world के साथ communicate करते हैं। Zubnet में, आप connect कर सकते हैं:

Telegram — @BotFather से अपना bot token paste करें
Discord — Discord Developer Portal से अपना bot token paste करें
Webhooks — कोई भी HTTP endpoint जो JSON भेज/receive कर सके

Channel determine करता है agent कहाँ रहेगा। एक Telegram bot agent Telegram chats में respond करता है। एक Discord bot agent आपके Discord server में रहता है। एक webhook agent API calls पर respond करता है।

शुरू करने के लिए एक channel choose करें। पहले दिन multi-channel agent build करने की कोशिश मत करें। पहले इसे एक platform पर reliably काम करवाएँ।

3. Tools add करें (MCP servers)

Tools वो हैं जो agents को chatbots से ज्यादा बनाते हैं। Zubnet में, tools MCP servers (Model Context Protocol) द्वारा provide किए जाते हैं। हमारे पास उनमें से 117 हैं। कुछ examples:

GitHub — repos search, issues create, files read, PRs list
PostgreSQL / MySQL — databases query करें (smart हो तो read-only)
Brave Search — web search
Filesystem — files read और write
Slack — messages send, channels read

जो servers चाहिए उन्हें activate करें, उनकी credentials configure करें (API keys, DB URLs), और agent उनका use कर सकता है।

Principle of least privilege यहाँ apply होता है:

Agents को सिर्फ वो tools दें जिनकी उन्हें वाकई जरूरत है। एक agent जो GitHub search करता है उसे database write access नहीं चाहिए। एक agent जो daily summaries भेजता है उसे filesystem access नहीं चाहिए। हर unnecessary tool चीजें गलत होने के लिए एक attack surface है।

4. Triggers configure करें

Triggers determine करते हैं कि agent कब activate होता है:

User message — जब कोई bot को message करता है तो respond करता है (chat agents के लिए default)
Cron schedule — fixed times पर run होता है (जैसे “हर दिन 9 AM”)
Event — कुछ specific होने पर fire होता है (webhook payload एक pattern match करता है)

Cron-triggered agents recurring tasks के लिए great हैं: daily standup summaries, weekly analytics reports, monitoring checks। Event-triggered agents reactive workflows handle करते हैं: नया GitHub issue → triage और label, नया support ticket → response draft करें।

Hard parts

Agent build करने में 20 minutes लगते हैं। उसे reliable बनाने में weeks। यहाँ production agents वाकई fail होते हैं:

Error handling: जब LLM एक tool call hallucinate करता है

LLMs कभी-कभी tools को गलत parameters के साथ call करते हैं, ऐसे tools call करते हैं जो exist नहीं करते, या गलत context में सही tool call करते हैं। आपके agent को यह सब gracefully handle करना है।

Zubnet में, failed tool calls error messages को LLM को वापस करते हैं, जो फिर decide कर सकता है क्या करना है। लेकिन आपको system prompt में उसे बताना है कि क्या करना है:

If a tool call fails:
1. Do NOT retry the same call with the same parameters
2. Analyze the error message
3. If it is a permission error, tell the user you cannot do that
4. If it is a rate limit, wait and try once more
5. If it is an unknown error, summarize what happened and ask for help
6. Never retry more than twice total

इन instructions के बिना, agents retry loops में stuck हो जाते हैं, same failing call पर बार-बार tokens और समय burn करते हैं।

Rate limits: frequency caps

500 active users वाले busy Discord server से connect किया गया एक agent per minute hundreds of messages receive कर सकता है। Rate limiting के बिना, यह करेगा:

• आपके API tokens budget को घंटों में burn कर देगा
• Provider rate limits hit करेगा और errors return करना शुरू कर देगा
• इतने responses generate करेगा कि channel unusable हो जाए

Frequency caps configure करें। Zubnet में, आप set कर सकते हैं:

• Max responses per minute (per channel)
• Max tokens per hour (budget control)
• Same user को responses के बीच cooldown period
• Queue depth limit (बहुत पीछे हो जाए तो messages drop करें)

Permissions: agents क्या कर सकते हैं उसे restrict करना

यह वो है जो आपको disasters से बचाएगा। Agents के पास job के लिए minimum permissions होनी चाहिए।

• DB tools: read-only जब तक writes specifically न चाहिए
• GitHub tools: read + issues create, लेकिन close/merge/delete नहीं
• Filesystem tools: सिर्फ specific directories, कभी / नहीं
• Messaging tools: सिर्फ specific channels, executives को कभी DMs नहीं

इसे ऐसे सोचें: सबसे बुरी क्या चीज है जो यह agent उसके tools के साथ कर सकता है? अगर answer आपको nervous करे, तो permissions कम करें।

Graceful degradation

जब एक tool down हो, agent को fail नहीं होना चाहिए। इसे limitation acknowledge करनी चाहिए और उस tool के बिना जो कर सकता है वो करना चाहिए। इसे अपने system prompt में include करें:

If a tool is unavailable or returning errors:
- Acknowledge it to the user: "I cannot access GitHub right now"
- Do what you can without that tool
- Never make up data to compensate for a missing tool
- Suggest the user try again later

Real examples

Example 1: support bot

एक Telegram bot जो आपकी knowledge base use करके customer questions answer करता है।

Model: Claude Sonnet 4 (instruction following में strong)
Tools: Brave Search (docs के लिए), PostgreSQL (read-only, account lookups के लिए)
Channel: Telegram
Trigger: user message
Rate limit: 30 responses/min, 2s cooldown per user

System prompt focuses on: पहले docs से answer करें, unsure हो तो human को escalate करें, कभी दूसरे customers का data share मत करें, features या timelines के बारे में कभी promises मत करें।

Example 2: daily summary agent

एक Discord bot जो रात के दौरान क्या हुआ उसका morning summary post करता है।

Model: GPT-4.1 (structured summaries के लिए अच्छा)
Tools: GitHub (PRs और issues read), Slack (channels read)
Channel: Discord (#daily-summary channel)
Trigger: cron, हर weekday 9:00 AM
Rate limit: 1 message per trigger (सिर्फ एक बार fires)

System prompt focuses on: merged PRs, open/closed issues और key Slack discussions summarize करें। 500 words से कम रखें। Bullet points use करें। Relevant team members को tag करें।

Example 3: content monitor

एक agent जो specific events पर watch रखता है और team को alert करता है।

Model: Gemini 2.5 Pro (fast, classification में अच्छा)
Tools: Brave Search (mentions monitor), Slack (alerts भेजें)
Channel: webhook (monitoring service द्वारा triggered)
Trigger: event (search results के साथ incoming webhook)
Rate limit: 10 alerts/hour (alert fatigue prevent करें)

System prompt focuses on: mentions को positive/negative/neutral classify करें, सिर्फ negatives या critical पर alert करें, source URL और one-sentence summary include करें।

Testing: small शुरू करें

Zubnet agents के दो modes हैं:

Quick mode — simplified setup, testing के लिए अच्छा। Limited tool configuration, basic triggers। अपना agent concept काम करता है यह validate करने के लिए use करें।
Advanced mode — full configuration, production-ready। Detailed system prompts, granular rate limits, permission controls, multiple triggers।

हमेशा quick mode में शुरू करें। Basic behavior को अच्छे से काम करवाएँ। फिर advanced mode में graduate करें और guardrails add करें।

Live जाने से पहले checklist:

• 20 normal messages भेजें — correctly respond करता है?
• 5 messages भेजें जिन्हें refuse करना चाहिए — refuse करता है?
• एक tool disable करें — gracefully degrade करता है?
• 1 minute में 50 messages भेजें — rate limit काम करता है?
• ऐसे language में एक message भेजें जिसे support नहीं करना चाहिए — handle करता है?
• उसे scope से बाहर कुछ करने को कहें — अपनी lane में रहता है?

Agents के बारे में inconvenient truth

Agents magic नहीं हैं। वो tools access के साथ loop में LLMs हैं। वो mistakes करते हैं। कभी-कभी गलत काम करेंगे। Question “क्या मेरा agent mistake करेगा?” नहीं है — यह है “जब यह करेगा तब क्या होगा?”

Production में काम करने वाले agents वो हैं जिनमें है:

• Tight scope (“यह एक चीज अच्छे से करो”)
• Explicit boundaries (“इन चीजों को कभी मत करो”)
• Limited permissions (least privilege, हमेशा)
• Rate limits और budget caps (runaway costs prevent करें)
• Human escalation paths (“doubt में हो तो human से पूछो”)
• Monitoring और logs (क्या हुआ यह जानने के लिए)

Boring agents build करें। Exciting demo agent जो सब कुछ कर सकता है वो है जो आपको production में embarrass करेगा। Boring agent जो एक चीज reliably करता है, बाकी सब refuse करता है, और confused होने पर escalate करता है — वो है जिस पर आपकी team actually trust करेगी।

Zubnet पर agents सभी users के लिए available हैं। एक simple Telegram या Discord bot से शुरू करें, उसे सही करें, फिर expand करें। Infrastructure hard parts handle करती है — आप system prompt, tools और guardrails पर focus करते हैं।

Build करने को ready? zubnet.com पर अपना पहला agent create करें

Sarah Chen
Zubnet · March 2026
ESC