Azure | The .NET Blog

Azure MCP Server अब .mcpb है — बिना किसी Runtime के इंस्टॉल करें

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित की गई है। मूल संस्करण के लिए, यहाँ क्लिक करें।

क्या आप जानते हैं MCP सर्वर सेटअप में क्या परेशान करता था? एक runtime की जरूरत थी। npm version के लिए Node.js, pip/uvx के लिए Python, dotnet variant के लिए .NET SDK।

Azure MCP Server ने अभी यह बदल दिया। यह अब .mcpb — एक MCP Bundle — के रूप में उपलब्ध है और सेटअप drag-and-drop है।

MCP Bundle क्या है?

इसे VS Code extension (.vsix) या browser extension (.crx) की तरह सोचें, लेकिन MCP servers के लिए। एक .mcpb फाइल एक self-contained ZIP archive है जिसमें server binary और सभी dependencies शामिल हैं।

कैसे इंस्टॉल करें

1. अपने प्लेटफॉर्म के लिए bundle डाउनलोड करें

GitHub Releases page पर जाएं और अपने OS और architecture के लिए .mcpb फाइल डाउनलोड करें।

2. Claude Desktop में इंस्टॉल करें

सबसे आसान तरीका: Extensions settings page (☰ → File → Settings → Extensions) खुलने पर .mcpb फाइल को Claude Desktop window में drag और drop करें। Server details review करें, Install पर क्लिक करें, confirm करें।

3. Azure में authenticate करें

az login

बस इतना। Azure MCP Server आपके मौजूदा Azure credentials का उपयोग करता है।

क्या कर सकते हैं

अपने AI client से सीधे 100+ Azure service tools तक पहुंच:

Cosmos DB, Storage, Key Vault, App Service, Foundry query और manage करें
किसी भी task के लिए az CLI commands generate करें
Bicep और Terraform templates बनाएं

शुरुआत करने के लिए

Download: GitHub Releases
Repo: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

पूरी पोस्ट देखें।

GPT-5.5 आ गया Azure Foundry में — .NET डेवलपर्स को क्या जानना चाहिए

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Microsoft ने अभी घोषणा की है कि GPT-5.5 Microsoft Foundry में उपलब्ध है। अगर आप Azure पर एजेंट बना रहे हैं, यह वह अपडेट है जिसका आप इंतजार कर रहे थे।

GPT-5 की प्रगति

GPT-5: रीजनिंग और गति को एक सिस्टम में एकीकृत किया
GPT-5.4: मजबूत मल्टी-स्टेप रीजनिंग, एंटरप्राइज के लिए एजेंटिक क्षमताएं
GPT-5.5: गहरा लॉन्ग-कॉन्टेक्स्ट रीजनिंग, अधिक विश्वसनीय एजेंटिक एक्सीक्यूशन, बेहतर टोकन दक्षता

वास्तव में क्या बदला

बेहतर एजेंटिक कोडिंग: GPT-5.5 बड़े कोडबेस में कॉन्टेक्स्ट बनाए रखता है, आर्किटेक्चरल विफलताओं का निदान करता है और टेस्ट आवश्यकताओं का अनुमान लगाता है।

टोकन दक्षता: कम टोकन और कम रिट्राई के साथ उच्च गुणवत्ता के आउटपुट। प्रोडक्शन में सीधे कम लागत और लेटेंसी।

मूल्य निर्धारण

मॉडल	इनपुट ($/M tokens)	कैश्ड इनपुट	आउटपुट ($/M tokens)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

Foundry क्यों मायने रखता है

Foundry Agent Service आपको YAML में एजेंट परिभाषित करने या Microsoft Agent Framework, GitHub Copilot SDK, LangGraph, या OpenAI Agents SDK के साथ जोड़ने देता है — और उन्हें स्थायी फाइलसिस्टम, Microsoft Entra आइडेंटिटी और स्केल-टू-जीरो मूल्य निर्धारण के साथ एजेंट के रूप में चलाता है।

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "आप एक सहायक हैं।", name: "मेराएजेंट");

पूरी घोषणा देखें।

Foundry Toolboxes: AI Agents के लिए एक Unified Endpoint

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

एक problem है जो boring लगती है जब तक खुद face न करो: organization multiple AI agents बना रही है, हर एक को tools चाहिए, और हर team scratch से configure कर रही है। Same web search integration, same Azure AI Search config, same GitHub MCP server connection — लेकिन अलग repository में, अलग team द्वारा, अलग credentials के साथ, और कोई shared governance नहीं।

Microsoft Foundry ने Toolboxes को Public Preview में launch किया, और यह उस problem का direct answer है।

Toolbox क्या है

Toolbox एक named, reusable bundle of tools है जो एक बार Foundry में define होता है और single MCP-compatible endpoint के through expose होता है। कोई भी agent runtime जो MCP बोलता है वो इसे consume कर सकता है — Foundry Agents में कोई lock-in नहीं।

Promise simple है: build once, consume anywhere। Tools define करो, authentication centrally configure करो (OAuth passthrough, Entra managed identity), endpoint publish करो। जिस agent को वो tools चाहिए वो endpoint से connect करे और सभी मिल जाएं।

चार pillars (आज दो available)

Pillar	Status	क्या करता है
Discover	Coming soon	Manual search बिना approved tools खोजना
Build	Available	Tools को reusable bundle में group करना
Consume	Available	Single MCP endpoint सभी tools expose करता है
Govern	Coming soon	Centralized auth + सभी tool calls की observability

Practical Example

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Documentation search करो और GitHub issues का जवाब दो",
 tools=[
 {"type": "web_search", "description": "Public documentation search"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Publish होने के बाद Foundry unified endpoint देता है। एक connection, सभी tools।

Foundry Agents में lock-in नहीं

Toolboxes Foundry में create और manage होते हैं, लेकिन consumption surface open MCP protocol है। Microsoft Agent Framework या LangGraph के custom agents, GitHub Copilot और अन्य MCP-enabled IDEs, कोई भी MCP-speaking runtime इन्हें use कर सकता है।

अभी क्यों important है

Multi-agent wave production में पहुंच रही है। हर नया agent duplicate configuration, stale credentials और inconsistent behavior की नई surface है। Build + Consume foundation centralization शुरू करने के लिए काफी है। जब Govern pillar आएगा, पूरी agent fleet के लिए fully observable, centrally controlled tool layer मिलेगी।

निष्कर्ष

यह अभी भी early है — Public Preview, Python SDK पहले, Discover और Govern अभी आने हैं। लेकिन model solid है और MCP-native design का मतलब है कि यह उन tools के साथ काम करता है जो already build हो रहे हैं। Official announcement देखें।

azd + GitHub Copilot: AI-सहायता से प्रोजेक्ट सेटअप और स्मार्ट एरर समाधान

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

क्या आप उस पल को जानते हैं जब आप Azure पर एक मौजूदा ऐप डिप्लॉय करना चाहते हैं और एक खाली azure.yaml देखकर सोचते हैं कि Express API के लिए Container Apps या App Service में से क्या चुनें? वह पल अब बहुत छोटा हो गया है।

Azure Developer CLI (azd) अब GitHub Copilot के साथ दो तरीकों से इंटीग्रेट होता है: azd init के दौरान AI-असिस्टेड प्रोजेक्ट स्कैफोल्डिंग, और डिप्लॉयमेंट फेल होने पर इंटेलिजेंट एरर ट्रबलशूटिंग। दोनों फीचर पूरी तरह टर्मिनल में रहते हैं।

azd init में Copilot के साथ सेटअप

azd init चलाने पर अब “Set up with GitHub Copilot (Preview)” विकल्प मिलता है। इसे चुनें और Copilot आपके कोडबेस का विश्लेषण करके azure.yaml, इंफ्रास्ट्रक्चर टेम्प्लेट और Bicep मॉड्यूल जनरेट करता है — आपके असली कोड के आधार पर।

azd init
# चुनें: "Set up with GitHub Copilot (Preview)"

आवश्यकताएँ:

azd 1.23.11 या नया — azd version से जाँचें या azd update से अपडेट करें
सक्रिय GitHub Copilot सब्सक्रिप्शन (Individual, Business या Enterprise)
GitHub CLI (gh) — जरूरत पड़ने पर azd लॉगिन माँगेगा

यह दोनों दिशाओं में काम करता है। नए प्रोजेक्ट के लिए? Copilot शुरू से सही Azure सर्विस कॉन्फिगर करने में मदद करता है। मौजूदा ऐप डिप्लॉय करना है? Copilot को उस पर पॉइंट करें — कोड रिस्ट्रक्चर किए बिना कॉन्फिगरेशन जनरेट हो जाएगी।

असल में क्या होता है

मान लीजिए आपके पास PostgreSQL डिपेंडेंसी वाला Node.js Express API है। Container Apps या App Service में मैन्युअली फैसला करने और Bicep लिखने की बजाय, Copilot आपका स्टैक डिटेक्ट करके जनरेट करता है:

सही language, host और build सेटिंग वाला azure.yaml
Azure Container Apps के लिए Bicep मॉड्यूल
Azure Database for PostgreSQL के लिए Bicep मॉड्यूल

और कुछ भी बदलने से पहले प्री-फ्लाइट चेक चलाता है — git वर्किंग डायरेक्टरी साफ है या नहीं, MCP सर्वर टूल कंसेंट। आपको पता होता है कि क्या बदलेगा।

Copilot से एरर ट्रबलशूटिंग

डिप्लॉयमेंट एरर अपरिहार्य हैं। गुम पैरामीटर, परमिशन इश्यू, SKU उपलब्धता — और एरर मैसेज वह नहीं बताता जो आप जानना चाहते हैं: कैसे ठीक करें।

बिना Copilot: एरर कॉपी करें → डॉक्स सर्च करें → Stack Overflow के तीन अप्रासंगिक जवाब पढ़ें → az CLI कमांड चलाएँ → दोबारा कोशिश करें। Copilot के साथ यह लूप टूट जाता है। कोई भी azd कमांड फेल होने पर तुरंत चार विकल्प मिलते हैं:

Explain — क्या गलत हुआ, सरल भाषा में
Guidance — ठीक करने के लिए स्टेप-बाय-स्टेप निर्देश
Diagnose and Guide — पूर्ण विश्लेषण + Copilot फिक्स लागू करता है (आपकी मंजूरी से) + वैकल्पिक रिट्राई
Skip — खुद संभालें

मुख्य बात: Copilot के पास आपके प्रोजेक्ट, फेल कमांड और एरर डिटेल का संदर्भ पहले से है। सुझाव आपकी स्थिति के लिए विशिष्ट हैं।

डिफ़ॉल्ट व्यवहार सेट करें

हमेशा एक ही विकल्प चुनते हैं? इंटरेक्टिव प्रॉम्प्ट स्किप करें:

azd config set copilot.errorHandling.category troubleshoot

मान: explain, guidance, troubleshoot, fix, skip। ऑटो-फिक्स और रिट्राई भी चालू कर सकते हैं:

azd config set copilot.errorHandling.fix allow

कभी भी इंटरेक्टिव मोड पर वापस:

azd config unset copilot.errorHandling.category

निष्कर्ष

azd update से नवीनतम संस्करण लें और अगले प्रोजेक्ट में azd init आज़माएँ।

मूल घोषणा यहाँ पढ़ें।

Azure पर आपके AI प्रयोग पैसे बर्बाद कर रहे हैं — इसे ठीक करने का तरीका यहाँ है

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

अगर आप अभी Azure पर AI-powered apps बना रहे हैं, तो आपने शायद कुछ नोटिस किया होगा: आपका cloud bill पहले जैसा नहीं दिखता। सिर्फ बड़ा नहीं — अजीब। उछल-कूद करने वाला। अनुमान लगाना मुश्किल।

Microsoft ने हाल ही में cloud cost optimization principles पर एक शानदार लेख publish किया है, और सच में, इसका timing बेहतर नहीं हो सकता था। क्योंकि AI workloads ने costs के मामले में खेल बदल दिया है।

AI Workloads क्यों अलग हैं

यहाँ बात यह है। पारंपरिक .NET workloads अपेक्षाकृत predictable होती हैं। आप अपना App Service tier जानते हैं, अपना SQL DTUs जानते हैं, मासिक खर्च का अनुमान काफी सटीक लगा सकते हैं। AI workloads? उतना नहीं।

आप multiple models test कर रहे हैं यह देखने के लिए कि कौन-सा fit है। Fine-tuning के लिए GPU-backed infrastructure spin up कर रहे हैं। Azure OpenAI को API calls कर रहे हैं जहाँ token consumption, prompt length और user behavior के आधार पर बहुत अलग-अलग होती है। हर experiment में असली पैसे लगते हैं, और सही approach पर पहुँचने से पहले आप दर्जनों experiments कर सकते हैं।

यही unpredictability लागत अनुकूलन को critical बनाती है — बाद में सोचने की बात नहीं, बल्कि पहले दिन से।

Management बनाम Optimization — अंतर जानें

लेख से एक distinction जो मुझे लगता है developers अक्सर नज़रअंदाज़ करते हैं: cost management और cost optimization में फ़र्क है।

Management tracking और reporting है। आप Azure Cost Management में budgets set करते हैं, alerts मिलते हैं, dashboards देखते हैं। यह तो बस शुरुआत है।

Optimization वह है जहाँ आप वास्तव में decisions लेते हैं। क्या आपको सच में S3 tier चाहिए, या S1 आपका load handle कर लेगा? क्या वह always-on compute instance weekends पर idle बैठी है? क्या आप training jobs के लिए spot instances उपयोग कर सकते हैं?

.NET developers के रूप में, हम code पर ध्यान देते हैं और infrastructure decisions “ops team” पर छोड़ देते हैं। लेकिन अगर आप Azure पर deploy कर रहे हैं, तो वे decisions आपकी भी हैं।

जो वास्तव में काम करता है

लेख और अपने अनुभव के आधार पर, यहाँ वह है जो वास्तव में फ़र्क डालता है:

जानें आप क्या खर्च कर रहे हैं और कहाँ। अपने resources को tag करें। गंभीरता से। अगर आप यह नहीं बता सकते कि कौन-सा project या experiment आपका budget खा रहा है, तो आप कुछ भी optimize नहीं कर सकते। उचित tagging के साथ Azure Cost Management आपका सबसे अच्छा दोस्त है।

Experiment करने से पहले guardrails set करें। Dev/test environments में महंगे SKUs को restrict करने के लिए Azure Policy उपयोग करें। अपने Azure OpenAI deployments पर spending limits set करें। Bill आने तक इंतज़ार न करें कि किसी ने weekend पर GPU cluster चलता छोड़ दिया।

लगातार rightsize करें। वह VM जो आपने prototyping के दौरान चुनी थी? वह production के लिए शायद गलत है। Azure Advisor recommendations देता है — उन्हें वास्तव में देखें। मासिक review करें, सालाना नहीं।

Lifecycle के बारे में सोचें। Dev resources को spin down होना चाहिए। Test environments को 24/7 चलने की ज़रूरत नहीं। Auto-shutdown policies उपयोग करें। AI workloads के लिए विशेष रूप से, serverless options पर विचार करें जहाँ आप execution के हिसाब से pay करते हैं बजाय compute को warm रखने के।

Value मापें, सिर्फ cost नहीं। यह भूलना आसान है। एक ऐसा model जिसकी cost ज़्यादा है लेकिन काफी बेहतर results देता है, सही choice हो सकता है। लक्ष्य कम से कम खर्च करना नहीं है — बल्कि समझदारी से खर्च करना है।

निष्कर्ष

Cloud cost optimization एक बार की सफाई नहीं है। यह एक आदत है। और AI workloads के साथ खर्च पहले से कम predictable होता जा रहा है, इस आदत को जल्दी बनाने से बाद में तकलीफदेह surprises से बचाव होता है।

अगर आप Azure पर build करने वाले .NET developer हैं, तो अपने cloud bill को वैसे ही treat करना शुरू करें जैसे आप अपना code treat करते हैं — नियमित रूप से review करें, जब messy हो जाए तो refactor करें, और कभी भी यह जाने बिना deploy न करें कि इसकी लागत क्या होगी।

Foundry का RFT सस्ता और स्मार्ट हो गया — यहाँ जानिए क्या बदला

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

अगर आप fine-tuned models पर निर्भर .NET apps बना रहे हैं, तो इस महीने के Foundry updates पर ध्यान देने लायक हैं। Reinforcement Fine-Tuning अब और accessible और काफी सस्ती हो गई है।

पूरी जानकारी official announcement में है, लेकिन यहाँ practical breakdown है।

o4-mini के लिए Global Training

o4-mini reasoning-heavy और agentic workloads के लिए go-to model है। बड़ी खबर: अब आप Standard training की तुलना में कम per-token training rates के साथ 13+ Azure regions से fine-tuning jobs launch कर सकते हैं। वही infrastructure, वही quality, व्यापक पहुँच।

अगर आपकी team geographies में फैली हुई है, तो यह मायने रखता है। अब आप training के लिए कुछ ही regions तक सीमित नहीं हैं।

Global training job शुरू करने के लिए REST API call यहाँ है:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

वह trainingType: globalstandard flag ही मुख्य अंतर है।

नए Model Graders: GPT-4.1 Family

Graders वह reward signal define करते हैं जिसके आधार पर आपका model optimize करता है। अब तक, model-based graders models के एक छोटे set तक सीमित थे। अब आपको तीन नए विकल्प मिलते हैं: GPT-4.1, GPT-4.1-mini, और GPT-4.1-nano।

Deterministic graders की बजाय model graders कब use करें? जब आपका task output open-ended हो, जब आपको कई dimensions में partial credit scoring चाहिए, या जब आप ऐसे agentic workflows बना रहे हों जहाँ tool-call correctness semantic context पर निर्भर करती है।

बात यह है — tiering strategy practical है:

GPT-4.1-nano शुरुआती iterations के लिए। कम cost, fast feedback loops।
GPT-4.1-mini जब आपका grading rubric stable हो और आपको higher fidelity चाहिए।
GPT-4.1 production grading या complex rubrics के लिए जहाँ हर scoring decision मायने रखती है।

आप एक ही RFT job में grader types भी mix कर सकते हैं। “correct answer” dimension के लिए string-match और reasoning quality evaluate करने के लिए model grader। यह flexibility ही इसे real workloads के लिए उपयोगी बनाती है।

RFT Data Format की समस्या

यह लोगों को अटकाती है। RFT data format SFT से अलग है। हर row का आखिरी message User या Developer role का होना चाहिए — Assistant का नहीं। Expected answer एक top-level key जैसे reference_answer में जाता है जिसे grader directly reference करता है।

अगर आप supervised fine-tuning कर रहे हैं और RFT पर switch करना चाहते हैं, तो आपको अपना training data restructure करना होगा। यह step skip न करें वरना आपके jobs silently fail होंगे।

.NET Developers के लिए यह क्यों मायने रखता है

अगर आप Azure OpenAI SDK के ज़रिए .NET apps से fine-tuned models call कर रहे हैं, तो सस्ती training का मतलब है कि आप अधिक aggressively iterate कर सकते हैं। Model grader options का मतलब है कि आप nuanced tasks के लिए fine-tune कर सकते हैं — सिर्फ exact-match scenarios नहीं। और GitHub पर best practices guide आपका real debugging time बचाएगी।

छोटे से शुरू करें। दस से सौ samples। Simple grader। Loop validate करें। फिर scale करें।

Azure MCP Tools अब Visual Studio 2022 में बिल्ट-इन हैं — कोई Extension ज़रूरी नहीं

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

अगर आप Visual Studio में अलग extension के ज़रिए Azure MCP tools use करते रहे हैं, तो आप उस झंझट से परिचित हैं — VSIX install करो, restart करो, उम्मीद करो कि टूटे नहीं, version mismatches manage करो। वो friction अब खत्म हो गई।

Yun Jung Choi ने घोषणा की कि Azure MCP tools अब सीधे Visual Studio 2022 में Azure development workload के हिस्से के रूप में आते हैं। कोई extension नहीं। कोई VSIX नहीं। कोई restart dance नहीं।

इसका वास्तव में क्या मतलब है

Visual Studio 2022 version 17.14.30 से शुरू होकर, Azure MCP Server Azure development workload के साथ bundled आता है। अगर आपके पास पहले से वो workload installed है, तो बस GitHub Copilot Chat में उसे toggle on करना है और आप तैयार हैं।

45 Azure services में 230 से अधिक tools — सीधे chat window से accessible। अपने storage accounts list करें, ASP.NET Core app deploy करें, App Service issues diagnose करें, Log Analytics query करें — बिना browser tab खोले।

यह जितना लगता है उससे ज़्यादा मायने क्यों रखता है

Developer tooling की असली बात यह है: हर extra step friction है, और friction adoption को मार देती है। MCP को एक अलग extension के रूप में रखने का मतलब था version mismatches, installation failures, और एक और चीज़ जो update रखनी होगी। इसे workload में बेक करने का मतलब है:

Visual Studio Installer के ज़रिए एकल update path
Extension और IDE के बीच कोई version drift नहीं
हमेशा current — MCP Server VS के regular releases के साथ update होता है

Azure पर standardize करने वाली teams के लिए यह बड़ी बात है। Workload एक बार install करें, tools enable करें, और वे हर session के लिए वहाँ मौजूद हैं।

इससे आप क्या कर सकते हैं

Tools Copilot Chat के ज़रिए पूरे development lifecycle को cover करते हैं:

सीखें — Azure services, best practices, architecture patterns के बारे में पूछें
Design और develop करें — service recommendations पाएं, app code configure करें
Deploy करें — resources provision करें और IDE से सीधे deploy करें
Troubleshoot करें — logs query करें, resource health check करें, production issues diagnose करें

एक quick example — Copilot Chat में यह type करें:

List my storage accounts in my current subscription.

Copilot पर्दे के पीछे Azure MCP tools call करता है, आपके subscriptions query करता है, और names, locations, और SKUs के साथ एक formatted list return करता है। कोई portal ज़रूरी नहीं।

इसे कैसे enable करें

Visual Studio 2022 17.14.30 या उससे ऊपर update करें
सुनिश्चित करें कि Azure development workload installed है
GitHub Copilot Chat खोलें
Select tools button (दो wrenches icon) पर क्लिक करें
Azure MCP Server को toggle on करें

बस इतना। यह sessions के बीच enabled रहता है।

एक ध्यान देने योग्य बात

Tools default रूप से disabled हैं — आपको opt in करना होगा। VS 2026-specific tools VS 2022 में उपलब्ध नहीं हैं। Tool availability आपके Azure subscription permissions पर भी निर्भर करती है, जैसे portal में होती है।

बड़ी तस्वीर

यह एक स्पष्ट trend का हिस्सा है: MCP developer IDEs में cloud tools surface करने का मानक तरीका बनता जा रहा है। हम पहले ही Azure MCP Server 2.0 stable release और VS Code तथा अन्य editors में MCP integrations देख चुके हैं। इसे Visual Studio के workload system में built in होना स्वाभाविक प्रगति है।

हम .NET developers जो Visual Studio में काम करते हैं, उनके लिए यह Azure portal पर context-switch करने का एक और कारण हटाता है। और सच में, जितना कम tab-switching, उतना बेहतर।

Aspire 13.2 में MongoDB EF Core और Azure Data Lake — दो Integrations जो आज़माने लायक हैं

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Aspire 13.2 अभी दो नए database integrations के साथ आया है जो आपका ध्यान आकर्षित करने के लायक हैं: MongoDB Entity Framework Core और Azure Data Lake Storage। अगर आप Aspire app में EF Core के साथ MongoDB उपयोग करना चाहते थे, या proper service discovery के साथ data lake workloads wire up करने की ज़रूरत थी, तो यह release दोनों deliver करती है।

MongoDB meets EF Core in Aspire

यह वो है जिसके बारे में मैं सबसे ज़्यादा excited हूँ। Aspire ने काफी समय से MongoDB को support किया है, लेकिन यह हमेशा raw driver था — कोई EF Core नहीं, कोई DbContext नहीं, documents के खिलाफ कोई LINQ queries नहीं। अब आपको MongoDB के साथ पूरा EF Core experience मिलता है, plus Aspire के automatic health checks और service discovery।

इसे setup करना typical Aspire pattern है। अपने AppHost में:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

फिर अपने consuming project में, EF Core integration जोड़ें:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

और अपना DbContext register करें:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

वहाँ से, यह standard EF Core है। अपनी entities define करें, अपने DbContext को किसी भी दूसरे provider की तरह उपयोग करें। Integration connection pooling, OpenTelemetry traces और health checks को behind the scenes handle करता है।

.NET developers के लिए जो raw driver के साथ MongoDB उपयोग कर रहे थे और manually connection strings wire up कर रहे थे, यह एक अच्छा quality-of-life upgrade है। आपको Aspire की service discovery खोए बिना पूरा EF Core abstraction मिलता है।

Azure Data Lake Storage पार्टी में शामिल हुई

दूसरा बड़ा addition एक Azure Data Lake Storage (ADLS) integration है। अगर आप data pipelines, ETL processes, या analytics platforms बना रहे हैं, तो अब आप Data Lake resources को उसी तरह wire up कर सकते हैं जैसे आप किसी दूसरी Aspire dependency को करते हैं।

AppHost में:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Consuming project में:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

कोई manual connection string management नहीं, कोई credential hunting नहीं। Aspire resources provision करता है और उन्हें inject करता है। जो लोग cloud-native .NET apps बना रहे हैं जो operational data और analytics workloads दोनों को handle करती हैं, उनके लिए यह data lake को Aspire model में एक first-class citizen जैसा महसूस कराता है।

छोटे fixes जो मायने रखते हैं

Headline features के अलावा, कुछ quality-of-life improvements भी हैं जो ध्यान देने योग्य हैं:

MongoDB connection string fix — database name से पहले forward slash अब सही तरीके से handle होता है। अगर आप इसके आसपास काम कर रहे थे, तो आप वह workaround हटा सकते हैं
SQL Server exports — Aspire.Hosting.SqlServer अब finer-grained control के लिए additional server configuration options export करता है
Emulator updates — ServiceBus emulator 2.0.0, App Configuration emulator 1.0.2, और CosmosDB का preview emulator अब readiness check शामिल करता है
Azure Managed Redis — अब default रूप से rediss:// (Redis Secure) है, इसलिए connections out of the box encrypted हैं

वह आखिरी वाला subtle लेकिन important है — default रूप से encrypted Redis का मतलब है production में configure करने के लिए एक कम चीज़।

अंत में

Aspire 13.2 एक incremental release है, लेकिन MongoDB EF Core और Data Lake integrations real gaps भरते हैं। अगर आप Aspire में MongoDB के साथ proper EF Core support का इंतज़ार कर रहे थे, या Data Lake को first-class dependency बनाने की ज़रूरत थी, तो 13.2 पर upgrade करें और इन्हें आज़माएं। aspire add command आपको ज़रूरत की सब कुछ scaffold कर देती है।

अधिक details के लिए full release notes पढ़ें, और पूरी list के लिए integration gallery देखें।

azd update — आपके सभी Package Managers को एक Command से संभालें

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

आपने वो “azd का नया version उपलब्ध है” message ज़रूर देखा होगा जो हर कुछ हफ्तों में pop up होता है? वो जिसे आप dismiss कर देते हैं क्योंकि आपको याद नहीं कि आपने azd winget से install किया था, Homebrew से, या उस curl script से जो आपने छह महीने पहले चलाई थी? हाँ, यह finally ठीक हो गया।

Microsoft ने azd update ship किया है — एक single command जो Azure Developer CLI को latest version में update करती है चाहे आपने इसे originally कैसे भी install किया हो। Windows, macOS, Linux — कोई फर्क नहीं। एक command।

यह कैसे काम करता है

azd update

बस इतना ही। अगर आप नए features का early access चाहते हैं, तो आप daily insiders build पर switch कर सकते हैं:

azd update --channel daily
azd update --channel stable

Command आपकी current installation method detect करती है और under the hood appropriate update mechanism use करती है। अब “रुको, इस machine पर मैंने winget use किया था या choco?” नहीं।

छोटी सी catch

azd update version 1.23.x से शुरू होकर ship होती है। अगर आप पुराने version पर हैं, तो आपको अपनी original installation method से एक आखिरी manual update करनी होगी। उसके बाद, azd update सब कुछ forward में handle करेगा।

azd version से अपना current version check करें। अगर आपको fresh install की ज़रूरत है, install docs में सब है।

यह क्यों मायने रखता है

यह एक छोटा quality-of-life improvement है, लेकिन उन लोगों के लिए जो daily basis पर Azure पर AI agents और Aspire apps deploy करने के लिए azd use करते हैं, current रहने का मतलब है कम “यह bug तो latest version में already fix हो गया था” moments। एक कम चीज़ जिसके बारे में सोचना पड़े।

अधिक context के लिए पूरी announcement और Jon Gallant का deeper dive पढ़ें।

Azure Smart Tier GA हुआ — Lifecycle Rules के बिना स्वचालित Blob Storage लागत अनुकूलन

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

अगर आपने कभी Azure Blob Storage lifecycle policies tune करने में समय बिताया है और फिर देखा है कि access patterns बदलने पर वे ध्वस्त हो जाती हैं, तो यह खबर आपके लिए है। Microsoft ने Azure Blob और Data Lake Storage के लिए smart tier की general availability की घोषणा की — यह एक fully managed tiering capability है जो वास्तविक उपयोग के आधार पर objects को hot, cool, और cold tiers के बीच स्वचालित रूप से ले जाती है।

Smart tier वास्तव में क्या करता है

अवधारणा सीधी है: smart tier आपके storage account में हर object के last access time का लगातार मूल्यांकन करता है। बार-बार access होने वाला data hot में रहता है, 30 दिनों बाद निष्क्रिय data cool में चला जाता है, और फिर 60 दिनों बाद cold में। जब data फिर से access होता है, तो वो तुरंत hot पर वापस आ जाता है। चक्र फिर से शुरू होता है।

Configure करने के लिए कोई lifecycle rules नहीं। Access pattern predictions नहीं। कोई manual tuning नहीं।

Preview के दौरान, Microsoft ने बताया कि smart-tier-managed capacity का 50% से अधिक हिस्सा actual access patterns के आधार पर स्वचालित रूप से cooler tiers में चला गया। बड़े storage accounts के लिए यह एक सार्थक cost reduction है।

.NET developers के लिए यह क्यों मायने रखता है

अगर आप ऐसी applications बना रहे हैं जो logs, telemetry, analytics data, या किसी भी तरह का growing data estate generate करती हैं — और सच में, कौन नहीं बना रहा — तो storage costs तेज़ी से बढ़ती हैं। पारंपरिक approach थी lifecycle management policies लिखना, उन्हें test करना, और फिर जब app के access patterns बदलें तो फिर से tune करना। Smart tier उस पूरे workflow को हटा देता है।

कुछ व्यावहारिक scenarios जहाँ यह मदद करता है:

Application telemetry और logs — debugging के समय hot, कुछ हफ्तों बाद शायद ही access
Data pipelines और ETL outputs — processing के दौरान भारी access, फिर mostly cold
User-generated content — recent uploads hot हैं, पुराना content धीरे-धीरे ठंडा होता है
Backup और archival data — compliance के लिए कभी-कभी access, mostly idle

इसे Setup करना

Smart tier enable करना एक बार का configuration है:

नए accounts: storage account creation के दौरान smart tier को default access tier के रूप में चुनें (zonal redundancy ज़रूरी है)
मौजूदा accounts: अपने current default से blob access tier को smart tier में switch करें

128 KiB से छोटे objects hot में रहते हैं और monitoring fee नहीं लगती। बाकी सब के लिए, आप standard hot/cool/cold capacity rates pay करते हैं बिना tier transition charges, early deletion fees, या data retrieval costs के। Per object एक monthly monitoring fee orchestration को cover करती है।

जो tradeoff जाननी चाहिए

Smart tier के tiering rules static हैं (30 दिन → cool, 90 दिन → cold)। अगर आपको custom thresholds चाहिए — जैसे किसी specific workload के लिए 7 दिनों में cool पर जाना — तो lifecycle rules अभी भी सही तरीका है। और दोनों को mix न करें: smart-tier-managed objects पर lifecycle rules use करने से बचें, क्योंकि वे conflict कर सकते हैं।

निष्कर्ष

यह क्रांतिकारी नहीं है, लेकिन यह एक real operational सिरदर्द हल करता है। अगर आप बढ़ते blob storage accounts manage करते हैं और lifecycle policies maintain करते-करते थक गए हैं, तो smart tier enable करें और Azure को यह handle करने दें। यह आज लगभग सभी zonal public cloud regions में उपलब्ध है।

Azure पर अपने AI Agents को कहाँ Host करें? एक Practical Decision Guide

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

अगर आप अभी .NET के साथ AI agents build कर रहे हैं, तो आपने शायद एक बात notice की होगी: Azure पर उन्हें host करने के बहुत तरीके हैं। Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — और ये सब तब तक reasonable लगते हैं जब तक आपको actually एक चुनना नहीं पड़ता। Microsoft ने हाल ही में Azure AI agent hosting का एक comprehensive guide publish किया है जो इसे clear करता है, और मैं इसे एक practical .NET developer perspective से break down करना चाहता हूँ।

एक नज़र में छह options

यहाँ बताया गया है कि मैं इस landscape को कैसे summarize करूँगा:

Option	सबसे अच्छा	आप manage करते हैं
Container Apps	K8s complexity के बिना full container control	Observability, state, lifecycle
AKS	Enterprise compliance, multi-cluster, custom networking	सब कुछ (यही तो point है)
Azure Functions	Event-driven, short-running agent tasks	ज़्यादा नहीं — true serverless
App Service	Simple HTTP agents, predictable traffic	Deployment, scaling config
Foundry Agents	Code-optional agents via portal/SDK	लगभग कुछ नहीं
Foundry Hosted Agents	Custom framework agents with managed infra	केवल आपका agent code

पहले चार general-purpose compute हैं — आप उन पर agents चला सकते हैं, लेकिन वे इसके लिए design नहीं किए गए। अंतिम दो agent-native हैं: वे conversations, tool calls, और agent lifecycles को first-class concepts के रूप में समझते हैं।

Foundry Hosted Agents — .NET agent developers के लिए sweet spot

यहाँ जो मेरा ध्यान खींचा। Foundry Hosted Agents बीच में sit करते हैं: आपको अपना code चलाने की flexibility मिलती है (Semantic Kernel, Agent Framework, LangGraph — जो भी) लेकिन platform infrastructure, observability, और conversation management handle करता है।

मुख्य piece है Hosting Adapter — एक thin abstraction layer जो आपके agent framework को Foundry platform से bridge करता है। Microsoft Agent Framework के लिए, यह इस तरह दिखता है:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

यही आपकी पूरी hosting story है। Adapter protocol translation, server-sent events के ज़रिये streaming, conversation history, और OpenTelemetry tracing handle करता है — सब automatically। कोई custom middleware नहीं, कोई manual plumbing नहीं।

Deploy करना genuinely simple है

मैंने पहले Container Apps पर agents deploy किए हैं और यह काम करता है, लेकिन आप state management और observability के लिए काफी glue code लिखते हैं। Hosted Agents और azd के साथ, deployment है:

# AI agent extension install करें
azd ext install azure.ai.agents

# Template से init करें
azd ai agent init

# Build, push, deploy — हो गया
azd up

वह single azd up आपका container build करता है, उसे ACR में push करता है, Foundry project provision करता है, model endpoints deploy करता है, और आपका agent start करता है। पाँच steps एक command में।

Built-in conversation management

यही production में सबसे ज़्यादा समय बचाता है। अपना conversation state store बनाने की बजाय, Hosted Agents इसे natively handle करते हैं:

# एक persistent conversation बनाएं
conversation = openai_client.conversations.create()

# पहला turn
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# दूसरा turn — context preserve होता है
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

कोई Redis नहीं। कोई Cosmos DB session store नहीं। Message serialization के लिए कोई custom middleware नहीं। Platform बस इसे handle कर लेता है।

मेरा decision framework

सभी छह options को देखने के बाद, यह मेरा quick mental model है:

क्या आपको zero infrastructure चाहिए? → Foundry Agents (portal/SDK, no containers)
क्या आपके पास custom agent code है लेकिन managed hosting चाहिए? → Foundry Hosted Agents
क्या आपको event-driven, short-lived agent tasks चाहिए? → Azure Functions
क्या आपको K8s के बिना maximum container control चाहिए? → Container Apps
क्या आपको strict compliance और multi-cluster चाहिए? → AKS
क्या आपके पास predictable traffic वाला simple HTTP agent है? → App Service

Semantic Kernel या Microsoft Agent Framework के साथ build करने वाले ज़्यादातर .NET developers के लिए, Hosted Agents likely सही starting point है। आपको scale-to-zero, built-in OpenTelemetry, conversation management, और framework flexibility मिलती है — Kubernetes manage किए बिना या अपनी observability stack wire up किए बिना।

निष्कर्ष

Azure पर agent hosting landscape तेज़ी से mature हो रहा है। अगर आप आज एक नया AI agent project शुरू कर रहे हैं, तो habit से Container Apps या AKS पर जाने से पहले Foundry Hosted Agents को seriously consider करें। Managed infrastructure real time बचाती है, और hosting adapter pattern आपको अपना framework choice रखने देता है।

Microsoft का पूरा guide और working examples के लिए Foundry Samples repo देखें।

.NET में Agent Skills अब काफी लचीली हो गई हैं

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

अगर आप Microsoft Agent Framework के साथ agents बना रहे हैं, तो आप यह drill जानते हैं: skills define करें, उन्हें provider में wire करें, और agent को decide करने दें कि कौन-सी invoke करनी है। नया यह है कि आप उन skills को कैसे बनाते हैं — और flexibility में जो उछाल आई है वह काफी बड़ी है।

ताज़ा update agent skills के लिए तीन अलग authoring patterns introduce करता है: file-based, class-based, और inline code-defined। तीनों एक single AgentSkillsProviderBuilder में plug होते हैं, यानी आप बिना किसी routing logic या special glue code के mix और match कर सकते हैं। चलिए हर एक को walk through करते हैं और देखते हैं कि आप उसे कब choose करेंगे।

File-based skills: शुरुआती बिंदु

File-based skills बिल्कुल वैसी ही हैं जैसी सुनाई देती हैं — disk पर एक directory जिसमें SKILL.md file, optional scripts, और reference documents हों। अपने agent को नई capabilities देने का यह सबसे सीधा तरीका है:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

SKILL.md frontmatter skill का name और description declare करता है, और instructions section agent को बताता है कि scripts और references कैसे use करें:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

फिर script execution के लिए SubprocessScriptRunner.RunAsync के साथ wire up करें:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

Agent skill को automatically discover करता है और account status check करने की ज़रूरत पड़ने पर provisioning script invoke करता है। साफ और सरल।

Class-based skills: NuGet के ज़रिए ship करें

Teams के लिए यहाँ दिलचस्प बात है। Class-based skills AgentClassSkill<T> से derive होती हैं और [AgentSkillResource] और [AgentSkillScript] जैसे attributes use करती हैं ताकि framework reflection के ज़रिए सब कुछ discover कर सके:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

यहाँ खूबसूरती यह है कि एक team इसे NuGet package के रूप में package कर सकती है। आप इसे अपने project में add करें, builder में drop करें, और यह आपकी file-based skills के साथ बिना किसी coordination के काम करता है:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

दोनों skills agent के system prompt में दिखाई देती हैं। Agent conversation के आधार पर decide करता है कि कौन-सी use करनी है — कोई routing code नहीं चाहिए।

Inline skills: त्वरित bridge

वह पल जब आप जानते हैं कि दूसरी team ठीक वही skill बना रही है जो आपको चाहिए, लेकिन वह एक sprint के लिए ship नहीं होगी? AgentInlineSkill आपका bridge है:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

इसे दूसरों की तरह ही builder में add करें:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

जब NuGet package आखिरकार ship होगा, तो आप inline skill को class-based से swap कर देते हैं। Agent को फ़र्क नहीं पड़ता।

लेकिन inline skills सिर्फ bridge के लिए नहीं हैं। ये तब भी सही choice हैं जब आपको runtime पर dynamically skills generate करनी हों — config से load की गई हर business unit के लिए एक skill सोचें — या जब किसी script को local state पर close करना हो जो किसी DI container में नहीं जाती।

Script approval: human-in-the-loop

Production agents बनाने वाले हम .NET developers के लिए, यह वह हिस्सा है जो deployment conversations को actually unblock करता है। कुछ scripts के real consequences होते हैं — किसी को benefits में enroll करना, production infra query करना। UseScriptApproval on करें और agent किसी भी script execute करने से पहले रुक जाता है:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

जब agent कोई script run करना चाहता है, तो वह approval request return करता है। आपकी app decision collect करती है — approve या reject — और agent उसी के अनुसार continue करता है। Regulated environments में, यही फ़र्क है “हम इसे deploy कर सकते हैं” और “legal ने मना कर दिया” के बीच।

यह combination क्यों मायने रखता है

असली power कोई एक authoring pattern नहीं है — यह composition है। आप:

छोटे से शुरू कर सकते हैं file-based skill से, instructions पर iterate करें, और बिना C# लिखे ship करें
Reusable skills ship कर सकते हैं NuGet packages के रूप में जिन्हें दूसरी teams एक line से add कर सकती हैं
Gaps को bridge कर सकते हैं inline skills से जब आपको अभी कुछ चाहिए
Shared skill directories को filter कर सकते हैं predicates से ताकि आपका agent सिर्फ वही load करे जो उसे चाहिए
Human oversight add कर सकते हैं उन scripts के लिए जो production systems को touch करती हैं

ये सभी AgentSkillsProviderBuilder के ज़रिए compose होते हैं। कोई special routing नहीं, कोई conditional logic नहीं, कोई skill type checks नहीं।

Wrapping up

.NET में Agent skills के पास अब एक genuinely flexible authoring model है। चाहे आप file-based skills से prototype sketch करने वाले solo developer हों या NuGet के ज़रिए packaged capabilities ship करने वाली enterprise team, patterns fit हैं। और script approval mechanism इसे उन environments के लिए production-ready बनाता है जहाँ आपको वह human checkpoint चाहिए।

पूरे walkthrough के लिए original announcement, Microsoft Learn पर Agent Skills documentation, और hands-on होने के लिए .NET samples on GitHub देखें।

Azure MCP Server 2.0 आया — Self-Hosted Agentic Cloud Automation यहाँ है

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

अगर आप हाल ही में MCP और Azure के साथ कुछ build कर रहे हैं, तो आप शायद जानते हैं कि local experience अच्छी तरह काम करती है। लेकिन जब आपको यह setup team भर में share करना हो? वहाँ चीजें complicated हो जाती थीं।

अब नहीं। Azure MCP Server 2.0 stable हो गया, और headline feature वही है जो enterprise teams ने माँगी थी: self-hosted remote MCP server support।

Azure MCP Server क्या है?

Azure MCP Server Model Context Protocol specification implement करता है और Azure capabilities को structured, discoverable tools के रूप में expose करता है। Numbers खुद बोलते हैं: 57 Azure services में 276 MCP tools।

बड़ी बात: self-hosted remote deployments

Real team scenario में आपको चाहिए:

Developers और internal agent systems के लिए shared access
Centralized configuration
Enterprise network और policy boundaries
CI/CD pipelines में integration

Azure MCP Server 2.0 यह सब address करता है। Auth के लिए दो options:

Managed Identity — Microsoft Foundry के साथ
On-Behalf-Of (OBO) flow — user के actual permissions के साथ

Security hardening

2.0 release में जोड़ा गया:

Stronger endpoint validation
Query-oriented tools में injection patterns के खिलाफ protection
Dev environments के लिए tighter isolation controls

Getting started

GitHub Repo — source code, docs
Docker Image — containerized deployment
VS Code Extension — IDE integration
Self-hosting guide — 2.0 का flagship feature

Azure MCP Server 2.0 enterprise teams के लिए MCP को real agentic workflows के लिए ready बनाता है।

Agentic Platform Engineering हकीकत बन रही है — Git-APE दिखाता है कैसे

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Platform engineering उन terms में से एक रही है जो conference talks में बहुत अच्छी लगती है, लेकिन आमतौर पर इसका मतलब होता है “हमने एक internal portal और एक Terraform wrapper बनाया।” असली वादा — self-service infrastructure जो वास्तव में safe, governed और fast हो — हमेशा कुछ कदम दूर रही है।

Azure team ने अभी अपनी agentic platform engineering series का Part 2 प्रकाशित किया, और यह पूरी तरह hands-on implementation के बारे में है। वे इसे Git-APE कहते हैं (हाँ, acronym जानबूझकर है), और यह एक open-source project है जो GitHub Copilot agents plus Azure MCP servers का उपयोग करके natural-language requests को validated, deployed infrastructure में बदलता है।

Git-APE वास्तव में क्या करता है

मूल विचार: developers को Terraform modules सीखने, portal UIs navigate करने, या platform team को tickets file करने की बजाय, वे एक Copilot agent से बात करते हैं। Agent intent को समझता है, Infrastructure-as-Code generate करता है, उसे policies के खिलाफ validate करता है, और deploy करता है — सब VS Code के अंदर।

यहाँ setup है:

git clone https://github.com/Azure/git-ape
cd git-ape

VS Code में workspace खोलें, और agent configuration files GitHub Copilot द्वारा auto-discovered हो जाती हैं। आप agent के साथ directly interact करते हैं:

@git-ape deploy a function app with storage in West Europe

Agent Azure services के साथ interact करने के लिए Azure MCP Server का उपयोग करता है। VS Code settings में MCP configuration specific capabilities enable करता है:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

यह क्यों मायने रखता है

जो लोग Azure पर build कर रहे हैं, उनके लिए यह platform engineering की conversation को “हम एक portal कैसे बनाएं” से “हम अपने guardrails को APIs के रूप में कैसे describe करें” की ओर shift करता है। जब आपके platform का interface एक AI agent हो, तो आपके constraints और policies की गुणवत्ता ही product बन जाती है।

Part 1 blog ने theory रखी: well-described APIs, control schemas, और explicit guardrails platforms को agent-ready बनाते हैं। Part 2 actual tooling ship करके साबित करता है कि यह काम करता है। Agent अंधाधुंध resources generate नहीं करता — यह best practices के खिलाफ validate करता है, naming conventions का सम्मान करता है, और आपके organization की policies लागू करता है।

Clean-up भी उतनी ही आसान है:

@git-ape destroy my-resource-group

मेरी राय

सच कहूँ तो — यह specific tool से ज़्यादा pattern के बारे में है। Git-APE खुद एक demo/reference architecture है। लेकिन underlying idea — agents आपके platform का interface, MCP protocol, GitHub Copilot host — यही वह जगह है जहाँ enterprise developer experience जा रही है।

अगर आप एक platform team हैं जो देख रहे हैं कि अपने internal tooling को agent-friendly कैसे बनाएं, तो इससे बेहतर कोई starting point नहीं है। और अगर आप एक .NET developer हैं जो सोच रहे हैं कि यह आपकी दुनिया से कैसे जुड़ता है: Azure MCP Server और GitHub Copilot agents किसी भी Azure workload के साथ काम करते हैं। आपकी ASP.NET Core API, आपका .NET Aspire stack, आपके containerized microservices — यह सब एक agentic deployment flow का target हो सकता है।

अंत में

Git-APE agentic platform engineering का एक प्रारंभिक लेकिन ठोस रूप है। repo clone करें, demo आज़माएं, और सोचना शुरू करें कि आपके platform की APIs और policies को एक agent द्वारा safely उपयोग किए जाने के लिए कैसा दिखना होगा।

walkthrough और video demos के लिए पूरा post पढ़ें।

Azure Functions पर अपने MCP Servers को Foundry Agents से कनेक्ट करें — यहाँ जानिए कैसे

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

MCP ecosystem के बारे में मुझे एक बात बहुत पसंद है: आप अपना server एक बार बनाते हैं, और यह हर जगह काम करता है। VS Code, Visual Studio, Cursor, ChatGPT — हर MCP client आपके tools discover और use कर सकता है। अब Microsoft उस list में एक और consumer जोड़ रहा है: Foundry agents।

Azure SDK team की Lily Ma ने एक practical guide publish की है जो Azure Functions पर deploy किए गए MCP servers को Microsoft Foundry agents से connect करने के बारे में है। अगर आपके पास पहले से एक MCP server है, तो यह pure value-add है — कोई rebuilding की ज़रूरत नहीं।

यह combination क्यों समझ में आता है

Azure Functions आपको scalable infrastructure, built-in auth, और MCP servers host करने के लिए serverless billing देता है। Microsoft Foundry आपको AI agents देता है जो reason, plan, और actions ले सकते हैं। दोनों को connect करने का मतलब है कि आपके custom tools — database query करना, business API call करना, validation logic चलाना — ऐसी capabilities बन जाती हैं जिन्हें enterprise AI agents autonomously discover और use कर सकते हैं।

मुख्य बात: आपका MCP server वैसा ही रहता है। आप बस Foundry को एक और consumer के रूप में जोड़ रहे हैं। वही tools जो आपके VS Code setup में काम करते हैं, अब एक AI agent को power करते हैं जिससे आपकी team या customers interact करते हैं।

Authentication के विकल्प

यहीं पर यह post वास्तव में value add करती है। आपके scenario के अनुसार चार auth methods:

Method	Use Case
Key-based (default)	Development या Entra auth के बिना servers
Microsoft Entra	Managed identities के साथ production
OAuth identity passthrough	Production जहाँ हर user individually authenticate करता है
Unauthenticated	Dev/testing या केवल public data

Production के लिए, agent identity के साथ Microsoft Entra recommended path है। OAuth identity passthrough तब है जब user context मायने रखता है — agent users को sign in के लिए prompt करता है, और हर request user का अपना token carry करती है।

इसे कैसे सेट करें

High-level flow:

अपना MCP server Azure Functions पर deploy करें — .NET, Python, TypeScript, और Java के लिए samples उपलब्ध हैं
अपने function app पर built-in MCP authentication enable करें
अपना endpoint URL पाएं — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Foundry में MCP server को tool के रूप में जोड़ें — portal में अपना agent navigate करें, एक नया MCP tool जोड़ें, endpoint और credentials दें

फिर Agent Builder playground में एक ऐसा prompt भेजकर test करें जो आपके किसी tool को trigger करे।

मेरा नज़रिया

यहाँ composability की कहानी वाकई मज़बूत हो रही है। अपना MCP server एक बार .NET (या Python, TypeScript, Java) में बनाएं, Azure Functions पर deploy करें, और हर MCP-compatible client इसे use कर सकता है — coding tools, chat apps, और अब enterprise AI agents। यह एक “एक बार लिखो, हर जगह use करो” pattern है जो वास्तव में काम करता है।

.NET developers के लिए विशेष रूप से, Azure Functions MCP extension इसे straightforward बनाता है। आप अपने tools को Azure Functions के रूप में define करें, deploy करें, और आपके पास Azure Functions की सभी security और scaling के साथ एक production-grade MCP server है।

निष्कर्ष

अगर आपके पास Azure Functions पर चलने वाले MCP tools हैं, तो उन्हें Foundry agents से connect करना एक quick win है — आपके custom tools server में कोई code changes किए बिना proper auth के साथ enterprise AI capabilities बन जाते हैं।

हर authentication method के step-by-step निर्देशों के लिए पूरी guide पढ़ें, और production setups के लिए detailed docs देखें।

GitHub Copilot का Modernization Assessment सबसे अच्छा Migration Tool है जिसे आप अभी तक Use नहीं कर रहे

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

एक legacy .NET Framework app को modern .NET पर migrate करना उन कामों में से एक है जो सब जानते हैं करना चाहिए, लेकिन कोई शुरू नहीं करना चाहता। यह कभी सिर्फ “target framework बदलो” नहीं होता। APIs गायब हो गई हैं, packages अब exist नहीं करते, hosting models बिल्कुल अलग तरह से काम करते हैं, और हज़ारों छोटे decisions हैं — क्या containerize करना है, क्या rewrite करना है, और क्या छोड़ना है।

Jeffrey Fritz ने GitHub Copilot के modernization assessment का विस्तृत विश्लेषण publish किया है, और सच में? .NET के लिए यह सबसे अच्छा migration tooling है जो मैंने देखा है। Code generation की वजह से नहीं — वह तो अब baseline है। बल्कि उस assessment document की वजह से जो यह तैयार करता है।

यह सिर्फ Code Suggestion Engine नहीं है

VS Code extension एक Assess → Plan → Execute model follow करता है। Assessment phase आपके पूरे codebase का विश्लेषण करती है और एक structured document तैयार करती है जो सब कुछ capture करती है: क्या बदलने की ज़रूरत है, कौन-से Azure resources provision करने हैं, कौन-सा deployment model उपयोग करना है। Infrastructure-as-code, containerization, deployment manifests — सब कुछ assessment के findings से निकलता है।

Assessment आपके project में .github/modernize/assessment/ के अंतर्गत store होती है। हर run एक independent report तैयार करता है, इसलिए आप एक history बनाते हैं और track कर सकते हैं कि जैसे-जैसे आप issues fix करते हैं आपकी migration posture कैसे evolve होती है।

शुरू करने के दो तरीके

Recommended Assessment — fast path। Curated domains (Java/.NET Upgrade, Cloud Readiness, Security) में से चुनें और configuration को छुए बिना meaningful results प्राप्त करें। यह देखने के लिए excellent है कि आपकी app कहाँ खड़ी है।

Custom Assessment — targeted path। ठीक वही configure करें जो analyze करना है: target compute (App Service, AKS, Container Apps), target OS, containerization analysis। Migration approaches की side-by-side तुलना के लिए multiple Azure targets चुनें।

वह comparison view सच में उपयोगी है। App Service के लिए 3 mandatory issues वाली एक app के लिए AKS पर 7 हो सकती हैं। दोनों देखने से migration path commit करने से पहले hosting decision drive करने में मदद मिलती है।

Issue Breakdown Actionable है

हर issue एक criticality level के साथ आती है:

Mandatory — ठीक करना ज़रूरी है या migration fail होगी
Potential — migration को affect कर सकती है, human judgment ज़रूरी है
Optional — recommended improvements, migration block नहीं करेंगी

और हर issue affected files और line numbers से link करती है, बताती है कि क्या गलत है और आपके target platform के लिए यह क्यों मायने रखता है, concrete remediation steps देती है (सिर्फ “यह ठीक करो” नहीं), और official documentation के links include करती है।

आप individual issues developers को सौंप सकते हैं और उनके पास act करने के लिए सब कुछ है। यही फ़र्क है एक ऐसे tool में जो आपको “एक problem है” बताता है और एक जो आपको बताता है कि इसे कैसे solve करना है।

Covered Upgrade Paths

.NET के लिए specifically:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

हर upgrade path में detection rules हैं जो जानती हैं कि कौन-से APIs हटाए गए, कौन-से patterns का कोई direct equivalent नहीं है, और किन security issues पर ध्यान देना है।

Multiple apps manage करने वाली teams के लिए, एक CLI भी है जो multi-repo batch assessments support करती है — सभी repos clone करें, सभी assess करें, per-app reports और एक aggregated portfolio view प्राप्त करें।

मेरी राय

अगर आप legacy .NET Framework apps पर बैठे हैं (और सच में, ज़्यादातर enterprise teams ऐसी ही हैं), तो यही वह tool है जिससे शुरू करना चाहिए। Assessment document अकेले समय के लायक है — यह एक अस्पष्ट “हमें modernize करना चाहिए” को स्पष्ट, prioritized work items की एक concrete list में बदलता है जिनके आगे बढ़ने के clear paths हैं।

Collaborative workflow भी smart है: assessments export करें, अपनी team के साथ share करें, बिना re-run किए import करें। Architecture reviews जहाँ decision-makers वे नहीं हैं जो tools चला रहे हैं? Covered।

निष्कर्ष

GitHub Copilot का modernization assessment .NET migration को एक डरावने, undefined project से एक structured, trackable process में बदलता है। अपना current status देखने के लिए recommended assessment से शुरू करें, फिर Azure targets की तुलना करने और अपना migration plan बनाने के लिए custom assessments उपयोग करें।

पूरा walkthrough पढ़ें और अपने codebase पर इसे आज़माने के लिए VS Code extension लें।

Microsoft Foundry March 2026 — GPT-5.4, Agent Service GA, और वह SDK Refresh जो सब कुछ बदल देता है

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Monthly “What’s New in Microsoft Foundry” posts आमतौर पर incremental improvements और कभी-कभी एक headline feature का mix होती हैं। March 2026 edition? यह basically सब headline features हैं। Foundry Agent Service GA हो गया, GPT-5.4 production के लिए ship हुआ, SDK का एक major stable release आया, और Fireworks AI Azure पर open model inference लाया। आइए breakdown करें कि .NET developers के लिए क्या मायने रखता है।

Foundry Agent Service production-ready है

यही सबसे बड़ी खबर है। Next-gen agent runtime generally available है — OpenAI Responses API पर बना, OpenAI agents के साथ wire-compatible, और multiple providers के models के लिए open। अगर आप आज Responses API के साथ build कर रहे हैं, तो Foundry पर migrate करने से आपकी existing agent logic के ऊपर enterprise security, private networking, Entra RBAC, full tracing, और evaluation मिलता है।

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Key additions: end-to-end private networking, MCP auth expansion (OAuth passthrough सहित), speech-to-speech agents के लिए Voice Live preview, और 6 नए regions में hosted agents।

GPT-5.4 — raw intelligence से ज़्यादा reliability

GPT-5.4 स्मार्ट होने के बारे में नहीं है। यह ज़्यादा reliable होने के बारे में है। Long interactions पर stronger reasoning, बेहतर instruction adherence, कम mid-workflow failures, और integrated computer use capabilities। Production agents के लिए, वह reliability benchmark scores से कहीं ज़्यादा मायने रखती है।

Model	Pricing (per M tokens)	Best For
GPT-5.4 (≤272K)	$2.50 / $15 output	Production agents, coding, document workflows
GPT-5.4 Pro	$30 / $180 output	Deep analysis, scientific reasoning
GPT-5.4 Mini	Cost-effective	Classification, extraction, lightweight tool calls

Smart approach एक routing strategy है: GPT-5.4 Mini high-volume, low-latency work handle करे जबकि GPT-5.4 reasoning-heavy requests लेता है।

SDK आखिरकार stable है

azure-ai-projects SDK सभी languages में stable releases के साथ ship हुआ — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, और .NET 2.0.0 (April 1)। azure-ai-agents dependency चली गई — सब कुछ AIProjectClient के अंदर रहता है। pip install azure-ai-projects से install करें और package openai और azure-identity को direct dependencies के रूप में bundle करता है।

.NET developers के लिए, इसका मतलब है full Foundry surface के लिए एक single NuGet package। अब अलग-अलग agent SDKs को juggle नहीं करना।

Fireworks AI Azure पर open models लाता है

शायद सबसे architecturally interesting addition: Fireworks AI जो daily 13+ trillion tokens ~180K requests/second पर process करता है, अब Foundry के ज़रिए available है। Launch पर DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, और MiniMax M2.5।

असली कहानी है bring-your-own-weights — serving stack बदले बिना कहीं से भी quantized या fine-tuned weights upload करें। Serverless pay-per-token या provisioned throughput के ज़रिए deploy करें।

अन्य highlights

Phi-4 Reasoning Vision 15B — charts, diagrams, और document layouts के लिए multimodal reasoning
Evaluations GA — Azure Monitor में piped continuous production monitoring के साथ out-of-the-box evaluators
Priority Processing (Preview) — latency-sensitive workloads के लिए dedicated compute lane
Voice Live — speech-to-speech runtime जो directly Foundry agents से connect होता है
Tracing GA — sort और filter के साथ end-to-end agent trace inspection
PromptFlow deprecation — January 2027 तक Microsoft Framework Workflows पर migration

निष्कर्ष

March 2026 Foundry के लिए एक turning point है। Agent Service GA, सभी languages में stable SDKs, reliable production agents के लिए GPT-5.4, और Fireworks AI के ज़रिए open model inference — platform serious workloads के लिए तैयार है।

Full roundup पढ़ें और अपना पहला agent build करें शुरुआत के लिए।

SQL MCP Server — AI एजेंट्स को डेटाबेस एक्सेस देने का सही तरीका

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

सच बात करें तो: आज उपलब्ध अधिकांश database MCP servers डरावने हैं। वे एक natural language query लेते हैं, तुरंत SQL generate करते हैं, और उसे आपके production data पर चला देते हैं। क्या गलत हो सकता है? (सब कुछ। सब कुछ गलत हो सकता है।)

Azure SQL टीम ने अभी SQL MCP Server पेश किया, और यह एक मौलिक रूप से अलग दृष्टिकोण अपनाता है। Data API builder (DAB) 2.0 की एक feature के रूप में बना, यह AI एजेंट्स को database operations तक structured, निर्धारित access देता है — NL2SQL के बिना, आपका schema उजागर किए बिना, और हर कदम पर पूरे RBAC के साथ।

NL2SQL क्यों नहीं?

यह सबसे दिलचस्प design निर्णय है। Models निर्धारित नहीं होते, और complex queries में सूक्ष्म त्रुटियाँ पैदा होने की सबसे अधिक संभावना होती है। जो queries उपयोगकर्ता AI से generate करवाना चाहते हैं, वही non-deterministic तरीके से produce होने पर सबसे अधिक जाँच की माँग करती हैं।

इसके बजाय, SQL MCP Server एक NL2DAB दृष्टिकोण अपनाता है। एजेंट Data API builder की entity abstraction layer और built-in query builder के साथ काम करता है ताकि accurate, well-formed T-SQL निर्धारित रूप से produce की जा सके। उपयोगकर्ता के लिए परिणाम वही रहता है, लेकिन hallucinated JOINs या accidental data exposure का जोखिम नहीं रहता।

सात tools, सात सौ नहीं

SQL MCP Server database के आकार चाहे जो हो, ठीक सात DML tools expose करता है:

describe_entities — उपलब्ध entities और operations खोजें
create_record — rows insert करें
read_records — tables और views query करें
update_record — rows modify करें
delete_record — rows हटाएं
execute_entity — stored procedures चलाएं
aggregate_records — aggregation queries

यह समझदारी है क्योंकि context windows एजेंट की सोचने की जगह हैं। सैकड़ों tool definitions से भर देने पर reasoning के लिए कम जगह बचती है। सात fixed tools एजेंट को navigate करने की बजाय सोचने पर केंद्रित रखते हैं।

प्रत्येक tool को individually enable या disable किया जा सकता है:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

तीन commands में शुरुआत

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

बस, आपका SQL MCP Server आपकी Customers table expose कर के चल पड़ा। Entity abstraction layer का मतलब है कि आप नाम और columns को alias कर सकते हैं, प्रत्येक role के लिए fields सीमित कर सकते हैं, और ठीक वही नियंत्रित कर सकते हैं जो एजेंट देखता है — बिना internal schema की जानकारी उजागर किए।

Security की कहानी पक्की है

यहीं Data API builder की परिपक्वता काम आती है:

हर layer पर RBAC — प्रत्येक entity परिभाषित करती है कि कौन से roles read, create, update, या delete कर सकते हैं, और कौन से fields दिखते हैं
Azure Key Vault integration — connection strings और secrets सुरक्षित रूप से manage होते हैं
Microsoft Entra + custom OAuth — production-grade authentication
Content Security Policy — एजेंट raw SQL के बजाय एक controlled contract के माध्यम से interact करते हैं

Schema abstraction विशेष रूप से महत्वपूर्ण है। आपके internal table और column names एजेंट को कभी नहीं दिखते। आप entities, aliases, और descriptions परिभाषित करते हैं जो AI interaction के लिए उचित हों — आपके database ERD के लिए नहीं।

Multi-database और multi-protocol

SQL MCP Server Microsoft SQL, PostgreSQL, Azure Cosmos DB, और MySQL को support करता है। और क्योंकि यह एक DAB feature है, आपको एक ही configuration से REST, GraphQL, और MCP endpoints एक साथ मिलते हैं। वही entity definitions, वही RBAC rules, वही security — तीनों protocols में।

DAB 2.0 में auto-configuration आपके database को inspect करके dynamically configuration बना सकती है, अगर आप rapid prototyping के लिए कम abstraction से comfortable हैं।

मेरा नजरिया

AI एजेंट्स के लिए enterprise database access इसी तरह काम करनी चाहिए। “अरे LLM, मेरे लिए कुछ SQL लिखो और production पर चला दो” वाला तरीका नहीं। बल्कि: एक well-defined entity layer, deterministic query generation, हर कदम पर RBAC, caching, monitoring, और telemetry। यह सबसे अच्छे अर्थ में उबाऊ है।

.NET डेवलपर्स के लिए, integration की कहानी साफ है — DAB एक .NET tool है, MCP Server एक container के रूप में चलता है, और यह Azure SQL के साथ काम करता है, जिसे हम में से अधिकांश पहले से उपयोग कर रहे हैं। अगर आप ऐसे AI एजेंट्स बना रहे हैं जिन्हें data access चाहिए, तो यहाँ से शुरू करें।

अंतिम बात

SQL MCP Server मुफ्त, open-source है, और कहीं भी चलता है। यह Microsoft की तरफ से AI एजेंट्स को सुरक्षित database access देने का prescriptive तरीका है। शुरुआत करने के लिए पूरी पोस्ट और documentation देखें।

रियल-टाइम Multi-Agent UIs बनाना जो Black Box की तरह न लगें

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

multi-agent systems के बारे में एक बात यह है: demos में वे बेहद शानदार लगते हैं। तीन agents काम आगे-पीछे भेज रहे हैं, समस्याएँ सुलझा रहे हैं, निर्णय ले रहे हैं। फिर आप इसे असली users के सामने रखने की कोशिश करते हैं और… खामोशी। एक घूमता हुआ indicator। कोई अंदाज़ा नहीं कि कौन-सा agent क्या कर रहा है या सिस्टम क्यों रुका हुआ है। यह कोई product नहीं है — यह एक भरोसे की समस्या है।

Microsoft Agent Framework team ने अभी-अभी MAF workflows को AG-UI के साथ जोड़ने पर एक शानदार walkthrough प्रकाशित किया है। AG-UI एक open protocol है जो Server-Sent Events के ज़रिए agent execution events को frontend पर stream करता है। और सच में? यही वह bridge है जिसकी हमें कमी थी।

.NET developers के लिए यह क्यों मायने रखता है

अगर आप AI-powered apps बना रहे हैं, तो आप शायद इस दीवार से टकरा चुके हैं। आपका backend orchestration बढ़िया काम करता है — agents एक-दूसरे को काम सौंपते हैं, tools चलते हैं, फैसले होते हैं। लेकिन frontend को पर्दे के पीछे क्या हो रहा है, इसका कोई अंदाज़ा नहीं। AG-UI इसे ठीक करता है — यह agent events (जैसे RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) को SSE पर सीधे आपकी UI layer तक stream करने के लिए एक standard protocol परिभाषित करता है।

जो demo उन्होंने बनाया वह तीन agents वाला customer support workflow है: एक triage agent जो requests को route करता है, एक refund agent जो पैसों का काम संभालता है, और एक order agent जो replacements manage करता है। हर agent के अपने tools हैं, और handoff topology स्पष्ट रूप से परिभाषित है — “prompt से खुद समझ लो” वाला कोई झमेला नहीं।

Handoff topology असली सितारा है

जो चीज़ मेरी नज़र में आई वह यह है कि HandoffBuilder आपको agents के बीच एक directed routing graph घोषित करने देता है:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

हर add_handoff एक natural-language description के साथ एक directed edge बनाता है। Framework इस topology के आधार पर हर agent के लिए handoff tools generate करता है। तो routing के फैसले आपकी orchestration structure पर आधारित हैं, न कि LLM की मर्ज़ी पर। production reliability के लिए यह बहुत बड़ी बात है।

Human-in-the-loop जो वाकई काम करता है

Demo में दो interrupt patterns दिखाए गए हैं जो किसी भी real-world agent app को चाहिए:

Tool approval interrupts — जब कोई agent approval_mode="always_require" वाला tool call करता है, तो workflow रुक जाता है और एक event emit होता है। Frontend tool name और arguments के साथ एक approval modal render करता है। कोई token-burning retry loops नहीं — बस एक साफ pause-approve-resume flow।

Information request interrupts — जब किसी agent को user से ज़्यादा context चाहिए (जैसे कोई order ID), तो वह रुकता है और पूछता है। Frontend सवाल दिखाता है, user जवाब देता है, और execution ठीक वहाँ से दोबारा शुरू होती है जहाँ वह रुकी थी।

दोनों patterns standard AG-UI events की तरह stream होते हैं, इसलिए आपके frontend को हर agent के लिए custom logic की ज़रूरत नहीं — वह बस SSE connection से आने वाला event render करता है।

Wiring up करना हैरानी की हद तक आसान है

MAF और AG-UI के बीच integration एक single function call है:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factory हर thread के लिए एक fresh workflow बनाता है, इसलिए हर conversation को isolated state मिलती है। Endpoint सारी SSE plumbing अपने आप handle करता है। अगर आप पहले से FastAPI use कर रहे हैं (या इसे एक lightweight layer के रूप में जोड़ सकते हैं), तो यह लगभग zero friction है।

मेरी राय

हम .NET developers के लिए तुरंत यह सवाल उठता है: “क्या मैं यह C# में कर सकता हूँ?” Agent Framework .NET और Python दोनों के लिए उपलब्ध है, और AG-UI protocol language-agnostic है (यह बस SSE है)। तो यह specific demo Python और FastAPI use करता है, लेकिन pattern सीधे translate होता है। आप same AG-UI event schema का पालन करते हुए SSE endpoints के साथ एक ASP.NET Core minimal API wire up कर सकते हैं।

बड़ी बात यह है कि multi-agent UIs एक first-class concern बनती जा रही हैं, afterthought नहीं। अगर आप कुछ ऐसा बना रहे हैं जहाँ agents humans के साथ interact करते हैं — customer support, approval workflows, document processing — तो MAF orchestration और AG-UI transparency का यह combination वह pattern है जिसे follow करना चाहिए।

Wrapping up

AG-UI + Microsoft Agent Framework आपको दोनों दुनियाओं का सर्वश्रेष्ठ देता है: backend पर robust multi-agent orchestration और frontend पर real-time visibility। Black-box agent interactions अब नहीं।

और गहराई से जानने के लिए full walkthrough और AG-UI protocol repo देखें।

azd अब आपको AI Agents को Locally Run और Debug करने देता है — March 2026 में क्या बदला

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

एक महीने में सात releases। यही Azure Developer CLI (azd) team ने March 2026 में deliver किया, और headline feature वही है जिसका मुझे इंतज़ार था: AI agents के लिए local run-and-debug loop।

PC Chan ने पूरा roundup publish किया है, और हालाँकि उसमें काफी कुछ है, लेकिन मुझे जो AI-powered apps build करने वाले .NET developers के लिए वाकई मायने रखता है वह filter करने दें।

Deploy किए बिना AI agents run और debug करें

यही बड़ी बात है। नया azure.ai.agents extension commands का एक set add करता है जो AI agents के लिए एक proper inner-loop experience देता है:

azd ai agent run — आपके agent को locally start करता है
azd ai agent invoke — उसे messages भेजता है (local या deployed)
azd ai agent show — container status और health display करता है
azd ai agent monitor — real time में container logs stream करता है

इससे पहले, एक AI agent को test करने का मतलब था हर बदलाव के बाद Microsoft Foundry में deploy करना। अब आप locally iterate कर सकते हैं, अपने agent के behavior को test कर सकते हैं, और deploy तभी करें जब आप ready हों। अगर आप Microsoft Agent Framework या Semantic Kernel के साथ agents build कर रहे हैं, तो यह आपके daily workflow को बदल देता है।

Invoke command local और deployed दोनों agents के against काम करता है, जिसका मतलब है कि आप same testing workflow use कर सकते हैं चाहे agent कहीं भी run हो। यह वह detail है जो आपको दो sets of test scripts maintain करने से बचाती है।

GitHub Copilot आपका azd project scaffold करता है

azd init अब “Set up with GitHub Copilot (Preview)” option offer करता है। अपने project structure के बारे में manually prompts का जवाब देने की बजाय, एक Copilot agent आपके लिए configuration scaffold करता है। यह कुछ modify करने से पहले dirty working directory check करता है और upfront MCP server tool consent माँगता है।

जब कोई command fail होती है, azd अब AI-assisted troubleshooting offer करता है: एक category चुनें (explain, guidance, troubleshoot, या skip), agent को fix suggest करने दें, और retry करें — terminal छोड़े बिना। Complex infrastructure setups के लिए, यह वाकई time saver है।

Container App Jobs और deployment improvements

कुछ deployment features जो ध्यान देने योग्य हैं:

Container App Jobs: azd अब existing host: containerapp config के ज़रिये Microsoft.App/jobs deploy करता है। आपका Bicep template decide करता है कि target Container App है या Job — कोई extra setup नहीं।
Configurable deployment timeouts: azd deploy पर नया --timeout flag और azure.yaml में deployTimeout field। Default 1200-second limit का अंदाज़ा लगाना अब नहीं।
Remote build fallback: जब remote ACR build fail हो, azd automatically local Docker/Podman build पर fallback करता है।
Local preflight validation: Bicep parameters Azure को round-trip किए बिना locally validate होते हैं, missing params पहले ही पकड़े जाते हैं।

Developer experience की polish

कुछ smaller improvements जो मिलकर फर्क डालती हैं:

JS/TS projects के लिए Automatic pnpm/yarn detection
Python packaging के लिए pyproject.toml support
Local template directories — azd init --template अब offline iteration के लिए filesystem paths accept करता है
--no-prompt mode में बेहतर error messages — सभी missing values एक साथ resolution commands के साथ report होते हैं
सभी framework build subprocesses (.NET, Node.js, Java, Python) में Build environment variables inject होते हैं

वह आखिरी बात subtle लेकिन महत्वपूर्ण है: आपके .NET build को अब azd environment variables का access है, जिसका मतलब है कि आप extra scripting के बिना build-time configuration injection कर सकते हैं।

निष्कर्ष

Local AI agent debugging loop इस release का star है, लेकिन deployment improvements और DX polish का जमावड़ा azd को पहले से कहीं ज़्यादा mature feel कराता है। अगर आप Azure पर .NET apps deploy कर रहे हैं — खासकर AI agents — तो यह update install करने लायक है।

हर detail के लिए पूरे release notes देखें, या azd install से शुरू करें।

KubeCon Europe 2026: .NET Developers को वास्तव में क्या जानना चाहिए

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

आप उस feeling को जानते हैं जब एक massive announcement post आती है और आप उसे scroll करते हुए सोच रहे होते हैं “cool, लेकिन यह actually मेरे लिए क्या बदलता है”? हर KubeCon season मेरे साथ यही होता है।

Microsoft ने अभी अपना पूरा KubeCon Europe 2026 roundup publish किया — Brendan Burns द्वारा लिखा गया — और सच में? यहाँ real substance है। सिर्फ feature checkboxes नहीं, बल्कि उस तरह के operational improvements जो बदलते हैं कि आप production में चीज़ें कैसे चलाते हैं।

आइए breakdown करें कि हम .NET developers के लिए क्या मायने रखता है।

service mesh overhead के बिना mTLS

Service meshes के बारे में बात यह है: सभी security guarantees चाहते हैं, कोई operational overhead नहीं चाहता। AKS आखिरकार उस gap को बंद कर रहा है।

Azure Kubernetes Application Network आपको mutual TLS, application-aware authorization, और traffic telemetry देता है — बिना full sidecar-heavy mesh deploy किए। Advanced Container Networking Services में Cilium mTLS के साथ combined, आपको X.509 certificates और identity management के लिए SPIRE का उपयोग करके encrypted pod-to-pod communication मिलती है।

व्यवहार में इसका मतलब: आपके ASP.NET Core APIs background workers से बात कर रहे हों, आपके gRPC services एक-दूसरे को call कर रहे हों — सब network level पर encrypted और identity-verified, zero application code changes के साथ। यह बहुत बड़ी बात है।

ingress-nginx से migrate करने वाली teams के लिए, Application Routing with Meshless Istio भी है जिसमें full Kubernetes Gateway API support है। कोई sidecars नहीं। Standards-based। और उन्होंने incremental migration के लिए ingress2gateway tooling ship की।

GPU observability जो afterthought नहीं है

अगर आप अपनी .NET services के साथ AI inference चला रहे हैं (और honestly, कौन शुरू नहीं कर रहा?), तो आपने शायद GPU monitoring blind spot देखा होगा। आपको CPU/memory के लिए बेहतरीन dashboards मिलते थे और फिर… manual exporter plumbing के बिना GPUs के लिए कुछ नहीं।

AKS अब GPU metrics को natively managed Prometheus और Grafana में expose करता है। वही stack, वही dashboards, वही alerting pipeline। कोई custom exporters नहीं, कोई third-party agents नहीं।

Network side पर, उन्होंने HTTP, gRPC, और Kafka traffic के लिए per-flow visibility one-click Azure Monitor experience के साथ जोड़ी। IPs, ports, workloads, flow direction, policy decisions — सब built-in dashboards में।

और यहाँ वह है जिसने मुझे double-take कराया: agentic container networking एक web UI जोड़ता है जहाँ आप अपने cluster की network state के बारे में natural-language questions पूछ सकते हैं। “Pod X service Y तक क्यों नहीं पहुँच रहा?” → live telemetry से read-only diagnostics। रात 2 बजे यह genuinely useful है।

Cross-cluster networking जिसके लिए PhD नहीं चाहिए

Multi-cluster Kubernetes historically एक “अपना networking glue लाओ” experience रहा है। Azure Kubernetes Fleet Manager अब managed Cilium cluster mesh के ज़रिए cross-cluster networking ship करता है:

AKS clusters में unified connectivity
Cross-cluster discovery के लिए global service registry
Configuration centrally managed, हर cluster पर repeat नहीं

अगर आप resilience या compliance के लिए regions में .NET microservices चला रहे हैं, तो यह बहुत सारी fragile custom plumbing की जगह लेता है। West Europe में Service A, East US में Service B को mesh के ज़रिए discover और call कर सकती है, consistent routing और security policies के साथ।

Upgrades जिनके लिए हिम्मत की ज़रूरत नहीं

सच कहें — production में Kubernetes upgrades stressful होते हैं। “Upgrade और उम्मीद करो” बहुत teams के लिए de facto strategy रही है, और यही मुख्य कारण है कि clusters version पर पिछड़ जाते हैं।

दो नई capabilities इसे बदलती हैं:

Blue-green agent pool upgrades नए configuration के साथ एक parallel node pool बनाते हैं। Behavior validate करें, traffic gradually shift करें, और एक clean rollback path रखें। Production nodes पर in-place mutations नहीं।

Agent pool rollback आपको upgrade बिगड़ने के बाद एक node pool को उसके पिछले Kubernetes version और node image पर revert करने देता है — cluster rebuild किए बिना।

साथ में, ये operators को upgrade lifecycle पर real control देते हैं। .NET teams के लिए, यह मायने रखता है क्योंकि platform velocity directly नियंत्रित करती है कि आप नए runtimes, security patches, और networking capabilities कितनी जल्दी adopt कर सकते हैं।

AI workloads Kubernetes के first-class citizens बन रहे हैं

Upstream open-source work equally important है। Dynamic Resource Allocation (DRA) Kubernetes 1.36 में GA हो गया, जो GPU scheduling को एक proper first-class feature बनाता है बजाय workaround के।

कुछ projects जो देखने लायक हैं:

Project	क्या करता है
AI Runway	Inference के लिए common Kubernetes API — K8s जाने बिना models deploy करें, HuggingFace discovery और cost estimates के साथ
HolmesGPT	Cloud-native के लिए agentic troubleshooting — अब CNCF Sandbox project
Dalec	SBOM generation के साथ declarative container image builds — build stage पर कम CVEs

दिशा स्पष्ट है: आपकी .NET API, आपकी Semantic Kernel orchestration layer, और आपके inference workloads सभी एक consistent platform model पर चलने चाहिए। हम वहाँ पहुँच रहे हैं।

इस हफ्ते मैं कहाँ से शुरू करूँगा

अगर आप अपनी team के लिए इन changes का मूल्यांकन कर रहे हैं, तो यहाँ मेरी honest priority list है:

Observability पहले — non-prod cluster में GPU metrics और network flow logs enable करें। देखें आप क्या miss कर रहे थे।
Blue-green upgrades आज़माएं — अपने अगले production cluster upgrade से पहले rollback workflow test करें। Process में confidence बनाएं।
Identity-aware networking pilot करें — एक internal service path चुनें और Cilium के साथ mTLS enable करें। Overhead measure करें (spoiler: यह minimal है)।
Fleet Manager evaluate करें — अगर आप दो से अधिक clusters चलाते हैं, तो cross-cluster networking reduced custom glue में खुद की cost justify कर देता है।

छोटे experiments, fast feedback। यही हमेशा सही move है।

निष्कर्ष

KubeCon announcements overwhelming हो सकती हैं, लेकिन यह batch genuinely AKS पर .NET teams के लिए needle move करती है। Mesh overhead के बिना बेहतर networking security, real GPU observability, safer upgrades, और मज़बूत AI infrastructure foundations।

अगर आप पहले से AKS पर हैं, तो यह आपका operational baseline tight करने का एक बढ़िया मौका है। और अगर आप .NET workloads को Kubernetes पर move करने की planning कर रहे हैं — platform अभी-अभी काफी ज़्यादा production-ready हो गया है।

SQL MCP Server, SSMS में Copilot, और AI Agents के साथ Database Hub: SQLCon 2026 की असली ज़रूरी बातें

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft ने अभी SQLCon 2026 को FabCon के साथ Atlanta में शुरू किया, और इसमें काफी कुछ है जिसे समझना ज़रूरी है। मूल घोषणा में savings plans से लेकर enterprise compliance features तक सब कुछ शामिल है। मैं enterprise pricing की slides को छोड़ रहा हूँ और उन बातों पर ध्यान केंद्रित कर रहा हूँ जो एक developer के लिए Azure SQL और AI के साथ कुछ बनाते समय वास्तव में मायने रखती हैं।

SQL MCP Server public preview में है

यह मेरे लिए सबसे बड़ी खबर है। Azure SQL Database Hyperscale में अब SQL MCP Server public preview में उपलब्ध है, जो आपको Model Context Protocol का उपयोग करके अपने SQL डेटा को AI agents और Copilots से सुरक्षित रूप से जोड़ने की सुविधा देता है।

अगर आप MCP की लहर को फॉलो कर रहे हैं — और सच कहूँ तो, इसे नज़रअंदाज़ करना अभी मुश्किल है — तो यह एक बड़ी बात है। अपने AI agents को database का context देने के लिए custom data pipelines बनाने की बजाय, आपको SQL डेटा को सीधे expose करने के लिए एक standardized protocol मिलता है। आपके agents live database की जानकारी को query कर सकते हैं, उस पर reasoning कर सकते हैं और action ले सकते हैं।

जो लोग Semantic Kernel या Microsoft Agent Framework के साथ AI agents बना रहे हैं, उनके लिए यह एक clean integration path खोलता है। आपके agent को inventory चेक करनी है? कोई customer record देखना है? किसी order को validate करना है? MCP इसके लिए एक structured तरीका देता है, बिना हर scenario के लिए bespoke data-fetching code लिखे।

SSMS 22 में GitHub Copilot अब GA है

अगर आप SQL Server Management Studio में समय बिताते हैं — और सच कहूँ तो, हम में से अधिकतर अभी भी करते हैं — तो GitHub Copilot अब SSMS 22 में generally available है। वही Copilot experience जो आप VS Code और Visual Studio में पहले से उपयोग करते हैं, लेकिन T-SQL के लिए।

यहाँ व्यावहारिक मूल्य सीधा है: queries लिखने, stored procedures को refactor करने, performance issues को troubleshoot करने और admin tasks संभालने के लिए chat-based assistance। अवधारणा में कुछ क्रांतिकारी नहीं है, लेकिन इसका SSMS में सीधे होना मतलब है कि database काम के लिए AI सहायता पाने के लिए आपको किसी दूसरे editor पर switch नहीं करना पड़ेगा।

Vector indexes को गंभीर upgrade मिला

Azure SQL Database में अब full insert, update, और delete support के साथ तेज़, अधिक capable vector indexes उपलब्ध हैं। इसका मतलब है कि आपका vector डेटा real time में current रहता है — batch reindexing की कोई ज़रूरत नहीं।

नया क्या है:

Quantization — accuracy बहुत कम खोए बिना छोटे index sizes के लिए
Iterative filtering — अधिक precise results के लिए
Query optimizer के साथ गहरा integration — predictable performance के लिए

अगर आप Azure SQL को vector store के रूप में उपयोग करके retrieval-augmented generation (RAG) कर रहे हैं, तो ये improvements सीधे काम आती हैं। आप अपने vectors को उसी database में अपने relational data के साथ रख सकते हैं, जो एक अलग vector database चलाने की तुलना में आपकी architecture को काफी सरल बनाता है।

यही vector enhancements Fabric में SQL database में भी उपलब्ध हैं, क्योंकि दोनों के नीचे एक ही SQL engine चलता है।

Fabric में Database Hub: agentic management

यह थोड़ा भविष्योन्मुखी है, लेकिन दिलचस्प है। Microsoft ने Database Hub in Microsoft Fabric (early access) की घोषणा की, जो Azure SQL, Cosmos DB, PostgreSQL, MySQL और Arc के ज़रिए SQL Server पर एक single pane of glass देता है।

दिलचस्प पहलू सिर्फ unified view नहीं है — यह management का agentic approach है। AI agents लगातार आपके database estate को monitor करते हैं, बताते हैं क्या बदला, समझाते हैं क्यों यह मायने रखता है, और सुझाव देते हैं कि आगे क्या करना है। यह एक human-in-the-loop model है जहाँ agent सारी मेहनत करता है और आप निर्णय लेते हैं।

कई databases manage करने वाली teams के लिए, यह operational noise को वास्तव में कम कर सकता है। Portals के बीच jump करने और manually metrics चेक करने की बजाय, agent signal को आपके पास लाता है।

.NET developers के लिए इसका क्या मतलब है

इन सभी घोषणाओं को जोड़ने वाला धागा स्पष्ट है: Microsoft database stack की हर layer में AI agents को embed कर रहा है। एक gimmick के रूप में नहीं, बल्कि एक practical tooling layer के रूप में।

अगर आप Azure SQL से backed .NET apps बना रहे हैं, तो मैं वास्तव में यही करूँगा:

SQL MCP Server आज़माएं अगर आप AI agents बना रहे हैं। यह आपके agents को database access देने का सबसे clean तरीका है बिना custom plumbing के।
SSMS में Copilot enable करें अगर आपने अभी तक नहीं किया — daily SQL काम के लिए free productivity win।
Vector indexes में देखें अगर आप RAG कर रहे हैं और वर्तमान में एक अलग vector store चला रहे हैं। Azure SQL पर consolidate करने का मतलब है एक कम service manage करना।

अंत में

पूरी announcement में और भी है — savings plans, migration assistants, compliance features — लेकिन developer की कहानी MCP Server, vector improvements और agentic management layer में है। ये वो pieces हैं जो आपके बनाने के तरीके को बदलते हैं, न कि सिर्फ आपके budget को।

पूरी तस्वीर के लिए Shireesh Thota की पूरी announcement देखें, और नया management experience आज़माने के लिए Database Hub early access के लिए sign up करें।

Azure DevOps MCP Server Microsoft Foundry में आया: आपके AI Agents के लिए इसका क्या मतलब है

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) इन दिनों बहुत चर्चा में है। अगर आप AI agent ecosystem को follow कर रहे हैं, तो आपने शायद देखा होगा कि MCP servers हर जगह दिखने लगे हैं — agents को एक मानकीकृत protocol के ज़रिए बाहरी tools और services के साथ interact करने की क्षमता देते हैं।

अब Azure DevOps MCP Server Microsoft Foundry में उपलब्ध है, और यह उन integrations में से एक है जो आपको व्यावहारिक संभावनाओं के बारे में सोचने पर मजबूर करती है।

यहाँ वास्तव में क्या हो रहा है

Microsoft ने Azure DevOps MCP Server को public preview के रूप में पहले ही release किया था — वह MCP server ही है। नया यह है कि Foundry integration आई है। अब आप अपने Foundry agents में tool catalog से सीधे Azure DevOps MCP Server जोड़ सकते हैं।

जो Foundry से परिचित नहीं हैं उनके लिए: यह Microsoft का unified platform है जो बड़े पैमाने पर AI-powered applications और agents बनाने और manage करने के लिए है। Model access, orchestration, evaluation, deployment — सब एक ही जगह।

इसे Setup करना

Setup करना आश्चर्यजनक रूप से सीधा है:

अपने Foundry agent में जाएं Add Tools > Catalog
“Azure DevOps” खोजें
Azure DevOps MCP Server (preview) चुनें और Create पर क्लिक करें
अपना organization नाम डालें और connect करें

बस इतना। आपके agent को अब Azure DevOps tools तक access मिल गई।

आप अपने agent की access को control कर सकते हैं

यहाँ वो हिस्सा है जो मुझे पसंद आया: आप all-or-nothing approach तक सीमित नहीं हैं। आप specify कर सकते हैं कि आपके agent के लिए कौन से tools उपलब्ध हों। तो अगर आप चाहते हैं कि वो केवल work items पढ़े लेकिन pipelines को न छुए, तो आप उसे configure कर सकते हैं। Principle of least privilege, अपने AI agents पर लागू।

यह enterprise scenarios के लिए मायने रखता है जहाँ आप नहीं चाहते कि एक agent गलती से deployment pipeline trigger कर दे क्योंकि किसी ने उससे “release में मदद करो” कहा।

.NET teams के लिए यह क्यों दिलचस्प है

सोचिए यह व्यवहार में क्या enable करता है:

Sprint planning assistants — agents जो work items pull कर सकते हैं, velocity data analyze कर सकते हैं, और sprint capacity suggest कर सकते हैं
Code review bots — agents जो आपके PR context को समझते हैं क्योंकि वे वास्तव में आपके repos और linked work items पढ़ सकते हैं
Incident response — agents जो work items create कर सकते हैं, recent deployments query कर सकते हैं, और bugs को recent changes से correlate कर सकते हैं
Developer onboarding — “मुझे किस पर काम करना चाहिए?” का जवाब actual project data पर आधारित होगा

जो .NET teams पहले से CI/CD pipelines और project management के लिए Azure DevOps use कर रही हैं, उनके लिए एक AI agent का सीधे उन systems के साथ interact करना useful automation की दिशा में एक महत्वपूर्ण कदम है।

बड़ी MCP तस्वीर

यह एक बड़े trend का हिस्सा है: MCP servers AI agents के बाहरी दुनिया से interact करने का मानक तरीका बनते जा रहे हैं। हम GitHub, Azure DevOps, databases, SaaS APIs — सब के लिए MCP servers देख रहे हैं — और Foundry वह hub बनता जा रहा है जहाँ ये सभी connections एक साथ आते हैं।

अगर आप .NET ecosystem में agents बना रहे हैं, तो MCP पर ध्यान देना ज़रूरी है। Protocol मानकीकृत है, tooling mature हो रहा है, और Foundry integration इसे manually server connections wire किए बिना accessible बनाती है।

निष्कर्ष

Foundry में Azure DevOps MCP Server preview में है, इसलिए यह evolve होता रहेगा। लेकिन core workflow solid है: connect करें, tool access configure करें, और अपने agents को आपके DevOps data के साथ काम करने दें। अगर आप पहले से Foundry ecosystem में हैं, तो यह कुछ clicks की दूरी पर है। इसे try करें और देखें कि आप कौन से workflows बना सकते हैं।

पूरी setup और अधिक जानकारी के लिए official announcement देखें।

Foundry Agent Service GA हो गया: .NET Agent Builders के लिए वास्तव में क्या मायने रखता है

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

सच कहें तो — एक AI agent का prototype बनाना सबसे आसान हिस्सा है। मुश्किल हिस्सा है उसके बाद का सब कुछ: इसे production में ले जाना उचित network isolation के साथ, ऐसे evaluations चलाना जिनका वास्तव में कुछ मतलब हो, compliance की आवश्यकताओं को संभालना, और रात 2 बजे चीज़ें तोड़ने से बचना।

Foundry Agent Service अभी GA हो गया है, और यह release उस “सब कुछ बाद में” की खाई को पाटने पर केंद्रित है।

Responses API पर निर्मित

मुख्य बात यह है: next-gen Foundry Agent Service OpenAI Responses API पर बनाया गया है। अगर आप पहले से उस wire protocol के साथ build कर रहे हैं, तो Foundry पर migrate करने के लिए न्यूनतम code बदलाव की ज़रूरत है। आपको मिलेगा: enterprise security, private networking, Entra RBAC, full tracing, और evaluation — आपके existing agent logic के ऊपर।

Architecture जानबूझकर open है। आप किसी एक model provider या एक orchestration framework से locked नहीं हैं। Planning के लिए DeepSeek, generation के लिए OpenAI, orchestration के लिए LangGraph इस्तेमाल करें — runtime consistency layer को संभालता है।

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Private networking: enterprise की बाधा दूर हुई

यह वह feature है जो enterprise adoption को unblock करता है। Foundry अब BYO VNet के साथ पूर्ण end-to-end private networking सपोर्ट करता है:

कोई public egress नहीं — agent traffic कभी public internet से नहीं गुज़रता
Container/subnet injection आपके network में local communication के लिए
Tool connectivity शामिल — MCP servers, Azure AI Search, Fabric data agents सभी private paths पर काम करते हैं

आखिरी बात critical है। सिर्फ inference calls ही private नहीं रहती — हर tool invocation और retrieval call भी आपकी network boundary के अंदर रहती है। उन teams के लिए जो data classification policies के तहत काम करती हैं जो external routing को prohibit करती हैं, यही वह था जो missing था।

MCP authentication सही तरीके से

MCP server connections अब auth patterns का पूरा spectrum सपोर्ट करते हैं:

Auth method	कब उपयोग करें
Key-based	org-wide internal tools के लिए simple shared access
Entra Agent Identity	Service-to-service; agent खुद को authenticate करता है
Entra Managed Identity	Per-project isolation; कोई credential management नहीं
OAuth Identity Passthrough	User-delegated access; agent users की तरफ से काम करता है

OAuth Identity Passthrough दिलचस्प है। जब users को किसी agent को अपने personal data तक access देने की ज़रूरत होती है — उनका OneDrive, उनका Salesforce org, एक user-scoped SaaS API — agent उनकी तरफ से standard OAuth flows के साथ काम करता है। कोई shared system identity नहीं जो सबका रूप धारण करे।

Voice Live: बिना plumbing के speech-to-speech

पहले किसी agent में voice जोड़ने का मतलब था STT, LLM, और TTS को आपस में जोड़ना — तीन services, तीन latency hops, तीन billing surfaces, सब हाथ से synchronize किए जाते। Voice Live इसे एक single managed API में समेट देता है जिसमें:

Semantic voice activity और end-of-turn detection (सिर्फ silence नहीं, meaning समझता है)
Server-side noise suppression और echo cancellation
Barge-in support (users mid-response interrupt कर सकते हैं)

Voice interactions उसी agent runtime से गुज़रती हैं जो text के लिए है। वही evaluators, वही traces, वही cost visibility। Customer support, field service, या accessibility scenarios के लिए, यह उस custom audio pipeline की जगह लेता है जिसकी पहले ज़रूरत थी।

Evaluations: checkbox से continuous monitoring तक

यहाँ Foundry production quality के बारे में गंभीर हो जाता है। Evaluation system में अब तीन layers हैं:

Out-of-the-box evaluators — coherence, relevance, groundedness, retrieval quality, safety। किसी dataset या live traffic से connect करें और scores वापस पाएं।
Custom evaluators — अपनी business logic, tone standards, और domain-specific compliance rules encode करें।
Continuous evaluation — Foundry live production traffic sample करता है, आपका evaluator suite चलाता है, और dashboards के ज़रिए results सामने लाता है। Azure Monitor alerts सेट करें जब groundedness गिरे या safety thresholds breach हों।

सब कुछ Azure Monitor Application Insights में publish होता है। Agent quality, infrastructure health, cost, और app telemetry — सब एक ही जगह।

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Hosted agents के लिए छह नए regions

Hosted agents अब East US, North Central US, Sweden Central, Southeast Asia, Japan East, और अन्य में उपलब्ध हैं। यह data residency requirements के लिए और latency कम करने के लिए मायने रखता है जब आपका agent अपने data sources के करीब चलता है।

.NET developers के लिए यह क्यों मायने रखता है

भले ही GA announcement के code samples Python-first हों, underlying infrastructure language-agnostic है — और azure-ai-projects का .NET SDK वही patterns follow करता है। Responses API, evaluation framework, private networking, MCP auth — यह सब .NET से उपलब्ध है।

अगर आप AI agents के “cool demo” से “मैं इसे actually काम पर ship कर सकता हूँ” बनने का इंतज़ार कर रहे थे, तो यह GA release वह signal है। Private networking, proper auth, continuous evaluation, और production monitoring वे टुकड़े थे जो missing थे।

निष्कर्ष

Foundry Agent Service अभी उपलब्ध है। SDK install करें, portal खोलें, और build करना शुरू करें। Quickstart guide आपको zero से एक running agent तक minutes में ले जाती है।

सभी code samples के साथ पूरे technical deep-dive के लिए, GA announcement देखें।

Laptop से Production तक: दो Commands में Microsoft Foundry पर AI Agents Deploy करना

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

आप उस gap को जानते हैं जो “मेरी machine पर काम करता है” और “यह deploy हो गया है और traffic serve कर रहा है” के बीच है? AI agents के लिए, वह gap दर्दनाक रूप से चौड़ी रही है। आपको resources provision करने हैं, models deploy करने हैं, identity wire up करनी है, monitoring set up करनी है — और यह सब किसी के भी आपके agent को call करने से पहले।

Azure Developer CLI ने इसे दो-command affair बना दिया है।

नया `azd ai agent` Workflow

आइए मैं बताता हूँ यह वास्तव में कैसा दिखता है। आपके पास एक AI agent project है — मान लीजिए एक hotel concierge agent। यह locally काम करता है। आप इसे Microsoft Foundry पर चलाना चाहते हैं।

azd ai agent init
azd up

बस। दो commands। azd ai agent init आपके repo में infrastructure-as-code scaffold करता है, और azd up Azure पर सब कुछ provision करता है और आपका agent publish करता है। आपको Foundry portal में अपने agent का direct link मिलता है।

Under the Hood क्या होता है

init command आपके repo में real, inspectable Bicep templates generate करता है:

एक Foundry Resource (top-level container)
एक Foundry Project (जहाँ आपका agent रहता है)
Model deployment configuration (GPT-4o, आदि)
उचित RBAC role assignments के साथ Managed identity
Service map के लिए azure.yaml
Agent metadata और environment variables के साथ agent.yaml

यहाँ key part है: यह सब आपके पास है। यह आपके repo में versioned Bicep है। आप इसे inspect कर सकते हैं, customize कर सकते हैं, और अपने agent code के साथ commit कर सकते हैं। कोई magic black boxes नहीं।

Dev Inner Loop

मुझे जो वास्तव में पसंद है वह local development story है। जब आप agent logic पर iterate कर रहे हों, तो आप हर बार prompt बदलने पर redeploy नहीं करना चाहते:

azd ai agent run

यह आपके agent को locally start करता है। इसे azd ai agent invoke के साथ pair करें test prompts भेजने के लिए, और आपके पास एक tight feedback loop है। Code edit करें, restart करें, invoke करें, दोहराएँ।

invoke command routing के बारे में भी smart है — जब एक local agent चल रहा होता है, तो यह automatically उसे target करता है। जब नहीं, तो यह remote endpoint को hit करता है।

Real-Time Monitoring

यही वह feature है जिसने मुझे convince किया। एक बार आपका agent deploy हो जाने पर:

azd ai agent monitor --follow

आपके agent से गुज़रने वाला हर request और response real time में आपके terminal में stream होता है। Production issues debug करने के लिए, यह अमूल्य है। Log analytics खंगालने की ज़रूरत नहीं, metrics aggregate होने का इंतज़ार नहीं — आप देखते हैं कि अभी क्या हो रहा है।

पूरा Command Set

यहाँ quick reference है:

Command	क्या करता है
`azd ai agent init`	IaC के साथ एक Foundry agent project scaffold करें
`azd up`	Azure resources provision करें और agent deploy करें
`azd ai agent invoke`	Remote या local agent को prompts भेजें
`azd ai agent run`	Development के लिए agent को locally चलाएँ
`azd ai agent monitor`	Published agent से real-time logs stream करें
`azd ai agent show`	Agent health और status check करें
`azd down`	सभी Azure resources cleanup करें

.NET Developers के लिए यह क्यों मायने रखता है

भले ही announcement का sample Python-based है, infrastructure story language-agnostic है। आपके .NET agent को वही Bicep scaffolding, वही managed identity setup, वही monitoring pipeline मिलती है। और अगर आप पहले से अपने .NET Aspire apps या Azure deployments के लिए azd उपयोग कर रहे हैं, तो यह आपके मौजूदा workflow में बिल्कुल fit होता है।

AI agents के लिए deployment gap ecosystem में सबसे बड़े friction points में से एक रही है। एक working prototype से proper identity, networking, और monitoring वाले production endpoint तक पहुँचने में DevOps का एक हफ्ता नहीं लगना चाहिए। अब इसमें दो commands और कुछ minutes लगते हैं।

निष्कर्ष

azd ai agent अभी available है। अगर आप अपने AI agents deploy करना टाल रहे थे क्योंकि infrastructure setup बहुत मुश्किल लग रहा था, तो इसे एक chance दें। Frontend chat app integration सहित पूरे step-by-step के लिए पूरा walkthrough देखें।

Microsoft Agent Framework में Background Responses: Timeout की चिंता अब खत्म

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

अगर आपने o3 या GPT-5.2 जैसे reasoning models के साथ कुछ बनाया है, तो आप वो दर्द जानते हैं। आपका agent एक complex task पर सोचना शुरू करता है, client वहाँ इंतज़ार करता है, और “यह ठीक है” से “क्या यह crash हो गया?” के बीच कहीं आपका connection timeout हो जाता है। वो सारा काम? बेकार।

Microsoft Agent Framework ने background responses ship किए हैं — और सच में, यह उन features में से एक है जो पहले दिन से ही होना चाहिए था।

Blocking calls की समस्या

एक पारंपरिक request-response pattern में, आपका client तब तक block रहता है जब तक agent finish नहीं हो जाता। यह quick tasks के लिए ठीक काम करता है। लेकिन जब आप एक reasoning model से deep research, multi-step analysis, या 20-page report generate करने को कहते हैं? आप wall-clock time में मिनटों की बात कर रहे हैं। उस window के दौरान:

HTTP connections timeout हो सकते हैं
Network blips पूरे operation को बर्बाद कर देते हैं
आपका user spinner देखता है और सोचता है कि कुछ हो भी रहा है या नहीं

Background responses इसे उलट देते हैं।

Continuation tokens कैसे काम करते हैं

Block होने की बजाय, आप agent task kick off करते हैं और एक continuation token वापस पाते हैं। इसे एक repair shop के claim ticket की तरह समझें — आप counter पर खड़े नहीं रहते, आप तब वापस आते हैं जब वो तैयार हो जाए।

Flow सीधा है:

अपना request AllowBackgroundResponses = true के साथ भेजें
अगर agent background processing support करता है, तो आपको एक continuation token मिलता है
अपने schedule पर poll करें जब तक token null न आ जाए — इसका मतलब है result तैयार है

यहाँ .NET version है:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Poll until complete
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

अगर agent तुरंत complete हो जाता है (simple tasks, वे models जिन्हें background processing की ज़रूरत नहीं), तो कोई continuation token return नहीं होता। आपका code बस काम करता है — कोई special handling ज़रूरी नहीं।

Resume के साथ Streaming: असली जादू

Fire-and-forget scenarios के लिए polling ठीक है, लेकिन जब आप real-time progress चाहते हों? Background responses built-in resumption के साथ streaming भी support करते हैं।

हर streamed update अपना खुद का continuation token carry करता है। अगर mid-stream आपका connection drop हो जाए, तो आप ठीक वहीं से pick up करते हैं जहाँ छोड़ा था:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simulate a network interruption
}

// Resume from exactly where we left off
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Agent server-side processing जारी रखता है चाहे आपके client के साथ कुछ भी हो रहा हो। यह built-in fault tolerance है बिना आपके retry logic या circuit breakers लिखे।

इसे वास्तव में कब use करें

हर agent call को background responses की ज़रूरत नहीं है। Quick completions के लिए, आप बिना किसी कारण complexity जोड़ रहे होंगे। लेकिन यहाँ वे shine करते हैं:

Complex reasoning tasks — multi-step analysis, deep research, कुछ भी जो reasoning model को वास्तव में सोचने पर मजबूर करे
Long content generation — detailed reports, multi-part documents, extensive analysis
Unreliable networks — mobile clients, edge deployments, flaky corporate VPNs
Async UX patterns — task submit करें, कुछ और करें, results के लिए वापस आएं

हम .NET developers जो enterprise apps बना रहे हैं, उनके लिए वो आखिरी scenario खास दिलचस्प है। एक Blazor app के बारे में सोचें जहाँ user एक complex report request करता है — आप agent task fire off करते हैं, उन्हें एक progress indicator दिखाते हैं, और उन्हें काम करते रहने देते हैं। कोई WebSocket gymnastics नहीं, कोई custom queue infrastructure नहीं, बस एक token और एक poll loop।

निष्कर्ष

Background responses Microsoft Agent Framework में अभी .NET और Python दोनों के ज़रिए उपलब्ध हैं। अगर आप ऐसे agents बना रहे हैं जो simple Q&A से ज़्यादा complex कुछ करते हैं, तो यह अपने toolkit में जोड़ने लायक है। Continuation token pattern चीज़ों को simple रखता है जबकि एक बहुत real production problem solve करता है।

Complete API reference और अधिक examples के लिए full documentation देखें।