Ai | The .NET Blog

Agent Framework में CodeAct: अपने एजेंट की लेटेंसी को आधा कैसे करें

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

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

हर एजेंट प्रोजेक्ट में एक ऐसा पल आता है जब आप ट्रेस देखते हैं और सोचते हैं: “इसमें इतना समय क्यों लग रहा है?” मॉडल ठीक है। टूल काम कर रहे हैं। लेकिन एक ऐसे परिणाम के लिए सात राउंड ट्रिप हो रहे हैं जो एक बार में की जा सकती थी।

यही वह समस्या है जिसे CodeAct हल करता है — और Agent Framework टीम ने नए agent-framework-hyperlight पैकेज के माध्यम से अल्फा सपोर्ट जारी किया है।

CodeAct क्या है?

CodeAct पैटर्न सुंदर रूप से सरल है: मॉडल को एक-एक करके टूल कॉल करने के बजाय, उसे एक execute_code टूल दें और पूरी योजना को एक छोटे Python प्रोग्राम के रूप में व्यक्त करने दें।

तरीका	समय	टोकन
पारंपरिक	27.81s	6,890
CodeAct	13.23s	2,489
सुधार	52.4%	63.9%

सुरक्षा: Hyperlight माइक्रो-VM

agent-framework-hyperlight पैकेज Hyperlight माइक्रो-VM का उपयोग करता है। प्रत्येक execute_code कॉल को अपना नया माइक्रो-VM मिलता है। स्टार्टअप मिलीसेकंड में होता है। आइसोलेशन मूल रूप से मुफ्त है।

आपके टूल होस्ट पर चलते रहते हैं। मॉडल द्वारा जेनरेट किया गया कोड सैंडबॉक्स में चलता है। यह सही विभाजन है।

न्यूनतम सेटअप

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

कब CodeAct उपयोग करें

CodeAct का उपयोग करें जब:

कार्य में कई छोटी टूल कॉल हों (लुकअप, जॉइन, गणना)
लेटेंसी और टोकन लागत महत्वपूर्ण हो
मॉडल-जेनरेटेड कोड के लिए मजबूत आइसोलेशन चाहिए

पारंपरिक टूल-कॉलिंग रखें जब:

एजेंट प्रति टर्न केवल एक-दो टूल कॉल करता हो
प्रत्येक कॉल में अलग-अलग अनुमोदन की जरूरत हो

अभी आज़माएं

pip install agent-framework-hyperlight --pre

Agent Framework ब्लॉग की पूरी पोस्ट पढ़ें।

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: "मेराएजेंट");

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

आपका एजेंट चीजें कहाँ याद रखता है? चैट हिस्ट्री स्टोरेज का व्यावहारिक गाइड

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

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

यह निर्धारित करता है कि उपयोगकर्ता बातचीत को ब्रांच कर सकते हैं, जवाब पूर्ववत कर सकते हैं, रीस्टार्ट के बाद सेशन फिर शुरू कर सकते हैं, और आपका डेटा कभी आपके इन्फ्रास्ट्रक्चर से बाहर जाता है या नहीं। Agent Framework टीम ने एक गहन विश्लेषण प्रकाशित किया है।

दो बुनियादी पैटर्न

सर्विस-मैनेज्ड: AI सर्विस बातचीत की स्थिति संग्रहीत करती है। आपका ऐप एक संदर्भ रखता है और सर्विस स्वचालित रूप से प्रत्येक अनुरोध में प्रासंगिक इतिहास शामिल करती है।

क्लाइंट-मैनेज्ड: आपका ऐप पूरा इतिहास रखता है और प्रत्येक अनुरोध के साथ प्रासंगिक संदेश भेजता है। सर्विस स्टेटलेस है। आप सब नियंत्रित करते हैं।

Agent Framework कैसे अमूर्त करता है

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("मेरा नाम Alice है।", session);
var second = await agent.RunAsync("मेरा नाम क्या है?", session);

प्रदाता त्वरित संदर्भ

प्रदाता	स्टोरेज	मॉडल	संपीड़न
OpenAI/Azure Chat Completions	क्लाइंट	N/A	आप
Foundry Agent Service	सर्विस	लीनियर	सर्विस
Responses API (डिफ़ॉल्ट)	सर्विस	ब्रांचिंग	सर्विस
Anthropic Claude, Ollama	क्लाइंट	N/A	आप

कैसे चुनें

ब्रांचिंग या “पूर्ववत” चाहिए? → सर्विस-मैनेज्ड Responses API
डेटा संप्रभुता चाहिए? → DB-बैक्ड प्रदाता के साथ क्लाइंट-मैनेज्ड
सिंपल चैटबॉट? → लीनियर सर्विस-मैनेज्ड ठीक है

पूर्ण निर्णय ट्री के लिए पूरी पोस्ट पढ़ें।

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 देखें।

Windows App Dev CLI v0.3: टर्मिनल से F5 डीबग और एजेंट्स के लिए UI ऑटोमेशन

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

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

Visual Studio का F5 अनुभव शानदार है। लेकिन सिर्फ एक पैकेज्ड Windows ऐप को लॉन्च और डीबग करने के लिए VS खोलना — चाहे वो CI पाइपलाइन हो, ऑटोमेटेड वर्कफ्लो हो, या AI एजेंट टेस्ट चला रहा हो — बहुत ज्यादा है।

Windows App Development CLI v0.3 अभी लॉन्च हुई है और दो मुख्य फीचर्स के साथ इसका सीधा समाधान देती है: winapp run और winapp ui।

winapp run: कहीं से भी F5

winapp run एक अनपैकेज्ड ऐप फोल्डर और मैनिफेस्ट लेती है, और वो सब करती है जो VS डीबग लॉन्च में करता है: एक loose पैकेज रजिस्टर करना, ऐप लॉन्च करना और री-डिप्लॉय के बीच LocalState बनाए रखना।

# ऐप बिल्ड करें, फिर पैकेज्ड ऐप की तरह चलाएं
winapp run ./bin/Debug

WinUI, WPF, WinForms, Console, Avalonia और अधिक के लिए काम करता है। मोड्स डेवलपर्स और ऑटोमेटेड वर्कफ्लो दोनों के लिए बनाए गए हैं:

--detach: लॉन्च के तुरंत बाद टर्मिनल को कंट्रोल वापस करता है। CI के लिए आदर्श।
--unregister-on-exit: ऐप बंद होने पर रजिस्टर्ड पैकेज हटाता है।
--debug-output: OutputDebugString संदेश और exceptions रियल-टाइम में कैप्चर करता है।

नया NuGet पैकेज: पैकेज्ड ऐप्स के लिए dotnet run

.NET डेवलपर्स के लिए एक नया NuGet पैकेज है: Microsoft.Windows.SDK.BuildTools.WinApp। इंस्टॉल के बाद dotnet run पूरा इनर लूप संभालता है: बिल्ड, loose-layout पैकेज तैयार करना, Windows में रजिस्टर करना और लॉन्च — सब एक स्टेप में।

winapp init
# या
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: कमांड लाइन से UI ऑटोमेशन

यह वो फीचर है जो एजेंटिक सीनेरियो खोलता है। winapp ui टर्मिनल से किसी भी चल रहे Windows ऐप (WPF, WinForms, Win32, Electron, WinUI3) तक पूर्ण UI Automation एक्सेस देता है।

क्या किया जा सकता है:

सभी टॉप-लेवल विंडो सूचीबद्ध करें
किसी भी विंडो के पूर्ण UI Automation ट्री को नेविगेट करें
नाम, टाइप या ऑटोमेशन ID से एलिमेंट खोजें
क्लिक, invoke और मान सेट करें
स्क्रीनशॉट लें
एलिमेंट दिखने का इंतजार करें — टेस्ट सिंक्रोनाइजेशन के लिए आदर्श

winapp ui और winapp run को मिलाकर टर्मिनल से पूरा build → लॉन्च → वेरिफाई वर्कफ्लो बनाया जा सकता है। एक एजेंट ऐप चला सकता है, UI स्थिति देख सकता है, प्रोग्रामेटिकली इंटरेक्ट कर सकता है और परिणाम validate कर सकता है।

अन्य नई सुविधाएं

winapp unregister: काम पूरा होने पर sideloaded पैकेज हटाएं।
winapp manifest add-alias: टर्मिनल से नाम से ऐप लॉन्च करने के लिए alias जोड़ें।
Tab completion: PowerShell के लिए एक कमांड से completion सेटअप करें।

कैसे प्राप्त करें

winget install Microsoft.WinAppCli
# या
npm install -g @microsoft/winappcli

CLI पब्लिक प्रीव्यू में है। पूरी डॉक्यूमेंटेशन के लिए GitHub रिपॉजिटरी देखें और सभी विवरण के लिए मूल घोषणा देखें।

VS Code 1.117: Agents को अपनी Git Branch मिल रही है — और मैं इसके साथ हूँ

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

“AI assistant” और “AI teammate” के बीच की रेखा लगातार पतली होती जा रही है। VS Code 1.117 अभी आया है और full release notes भरे पड़े हैं, लेकिन यहाँ की कहानी साफ है: agents आपके dev workflow में first-class citizens बनते जा रहे हैं।

यहाँ वो है जो वाकई मायने रखता है।

Autopilot mode आखिरकार आपकी preference याद रखता है

पहले, हर नई session शुरू करने पर Autopilot को फिर से enable करना पड़ता था। परेशान करने वाला। अब आपका permission mode sessions के पार persist होता है, और आप default configure कर सकते हैं।

Agent Host तीन session configs support करता है:

Default — tools चलने से पहले confirmation माँगते हैं
Bypass — सब कुछ auto-approve करता है
Autopilot — पूरी तरह autonomous, अपने सवालों के खुद जवाब देता है और चलता रहता है

अगर आप migrations, Docker, और CI के साथ एक नया .NET project scaffold कर रहे हैं — एक बार Autopilot set करें और भूल जाएं। वह preference बनी रहती है।

Agent sessions के लिए Worktree और git isolation

यह बड़ी बात है। Agent sessions अब पूरी worktree और git isolation support करती हैं। इसका मतलब है जब कोई agent किसी task पर काम करता है, उसे अपनी branch और working directory मिलती है। आपकी main branch untouched रहती है।

इससे भी बेहतर — Copilot CLI इन worktree sessions के लिए meaningful branch names generate करता है। अब agent-session-abc123 नहीं। आपको कुछ ऐसा मिलता है जो वास्तव में बताता है agent क्या कर रहा है।

Multiple feature branches चलाने वाले या एक लंबे scaffolding task के दौरान bugs fix करने वाले .NET डेवलपर्स के लिए, यह game changer है। आपका एक agent एक worktree में API controllers बना सकता है जबकि आप दूसरे में service layer issue debug कर रहे हैं। कोई conflicts नहीं। कोई stashing नहीं। कोई mess नहीं।

Subagents और agent teams

Agent Host Protocol अब subagents support करता है। एक agent किसी task के हिस्सों को handle करने के लिए दूसरे agents spin up कर सकता है। इसे delegation की तरह सोचें — आपका main agent coordinate करता है, और specialized agents टुकड़े handle करते हैं।

यह early है, लेकिन .NET workflows के लिए potential स्पष्ट है। कल्पना करें एक agent आपके EF Core migrations handle करे जबकि दूसरा integration tests setup करे। हम पूरी तरह वहाँ नहीं हैं, लेकिन अभी protocol support land होने का मतलब है tooling जल्दी आएगी।

Agents input भेजने पर terminal output automatically include होता है

छोटा लेकिन meaningful। जब कोई agent terminal को input भेजता है, terminal output अब automatically context में include हो जाता है। पहले, agent को बस यह देखने के लिए एक extra turn लेना पड़ता था कि क्या हुआ।

अगर आपने कभी किसी agent को dotnet build चलाते, fail होते, और फिर error देखने के लिए सिर्फ एक और round-trip लेते देखा है — वह friction खत्म हो गया। यह output तुरंत देखता है और react करता है।

macOS पर self-updating Agents app

macOS पर standalone Agents app अब self-update करती है। अब manually नए versions download नहीं करने होंगे। यह बस current रहती है।

जानने लायक छोटी बातें

package.json hovers अब installed version और latest available दोनों दिखाते हैं। Useful है अगर आप .NET projects के साथ npm tooling manage करते हैं।
JSDoc comments में Images hovers और completions में सही render होती हैं।
Copilot CLI sessions अब indicate करती हैं कि वे VS Code द्वारा बनाई गईं या externally — handy जब आप terminals के बीच jump कर रहे हों।
Copilot CLI, Claude Code, और Gemini CLI shell types के रूप में recognize होते हैं। Editor जानता है आप क्या चला रहे हैं।

निष्कर्ष

VS Code 1.117 कोई flashy feature dump नहीं है। यह infrastructure है। Worktree isolation, persistent permissions, subagent protocols — ये उस workflow के building blocks हैं जहाँ agents बिना आपके code पर कदम रखे real, parallel tasks handle करते हैं।

अगर आप .NET से build कर रहे हैं और अभी तक agentic workflow में नहीं उतरे हैं, तो honestly, अब शुरू करने का समय है।

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 करें।

Docker Sandbox, Copilot Agents को आपकी मशीन को जोखिम में डाले बिना Code Refactor करने देता है

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

अगर आपने Copilot के agent mode का उपयोग छोटे edits से परे किसी काम के लिए किया है, तो आप वह तकलीफ जानते हैं। हर file write, हर terminal command — एक और permission prompt। अब कल्पना करें कि यह 50 projects में चलाना हो। मज़ेदार नहीं।

Azure team ने GitHub Copilot agents के लिए Docker Sandbox के बारे में एक post publish किया है, और सच में, यह सबसे practical agentic tooling improvements में से एक है जो मैंने देखी है। यह microVMs का उपयोग करता है ताकि Copilot को एक पूरी तरह से isolated environment मिल सके जहाँ यह खुलकर काम कर सके — packages install करना, builds चलाना, tests execute करना — आपके host system को छुए बिना।

Docker Sandbox वास्तव में क्या देता है

Core idea सरल है: एक पूर्ण Linux environment के साथ एक lightweight microVM spin up करें, अपना workspace उसमें sync करें, और Copilot agent को उसके अंदर freely काम करने दें। जब यह हो जाए, changes sync back हो जाती हैं।

यहाँ वह है जो इसे सिर्फ “container में चीज़ें चलाने” से अधिक बनाता है:

Bidirectional workspace sync जो absolute paths को preserve करता है। आपकी project structure sandbox के अंदर बिल्कुल एक जैसी दिखती है। Path-related build failures नहीं।
Private Docker daemon जो microVM के अंदर चलता है। Agent containers build और run कर सकता है बिना कभी आपके host के Docker socket को mount किए। Security के लिए यह बहुत बड़ी बात है।
HTTP/HTTPS filtering proxies जो control करते हैं कि agent network पर क्या reach कर सकता है। आप तय करते हैं कि कौन-से registries और endpoints allowed हैं। Sandbox के अंदर एक rogue npm install से supply chain attacks? Blocked।
YOLO mode — हाँ, यही वे इसे कहते हैं। Agent बिना permission prompts के चलता है क्योंकि यह literally आपके host को नुकसान नहीं पहुँचा सकता। हर destructive action contained है।

.NET Developers को क्यों परवाह करनी चाहिए

उस modernization work के बारे में सोचें जिसका सामना इतनी सारी teams कर रही हैं। आपके पास 30 projects का एक .NET Framework solution है, और आपको इसे .NET 9 पर move करना है। वह सैकड़ों file changes हैं — project files, namespace updates, API replacements, NuGet migrations।

Docker Sandbox के साथ, आप एक Copilot agent को किसी project पर point कर सकते हैं, उसे microVM के अंदर freely refactor करने दे सकते हैं, validate करने के लिए dotnet build और dotnet test चला सकते हैं, और केवल वे changes accept कर सकते हैं जो वास्तव में काम करती हैं। इस जोखिम के बिना कि experimenting करते समय यह आपके local dev environment को accidentally बर्बाद कर दे।

Post में parallel agents की एक fleet चलाने का भी वर्णन है — प्रत्येक अपने sandbox में — जो एक साथ अलग-अलग projects से निपटती हैं। बड़े .NET solutions या microservice architectures के लिए, यह बहुत बड़ा समय बचाने वाला है। एक agent per service, सभी isolated होकर चल रहे हैं, सभी independently validate हो रहे हैं।

Security पक्ष मायने रखता है

यहाँ वह बात है जो ज़्यादातर लोग छोड़ देते हैं: जब आप एक AI agent को arbitrary commands execute करने देते हैं, तो आप उस पर अपनी पूरी machine का भरोसा कर रहे हैं। Docker Sandbox उस model को पलट देता है। Agent को एक throwaway environment के अंदर पूरी autonomy मिलती है। Network proxy सुनिश्चित करता है कि यह केवल approved sources से pull कर सकता है। आपका host filesystem, Docker daemon, और credentials अछूते रहते हैं।

Compliance requirements वाली teams के लिए — और ज़्यादातर enterprise .NET shops की यही स्थिति है — यह “हम agentic AI उपयोग नहीं कर सकते” और “हम इसे safely adopt कर सकते हैं” के बीच का अंतर है।

निष्कर्ष

Docker Sandbox agentic coding के मूलभूत tension को हल करता है: agents को उपयोगी होने के लिए स्वतंत्रता चाहिए, लेकिन आपकी host machine पर स्वतंत्रता खतरनाक है। MicroVMs आपको दोनों देते हैं। अगर आप कोई बड़े पैमाने का .NET refactoring या modernization plan कर रहे हैं, तो इसे अभी set up करना उचित है। Copilot की code intelligence को एक safe execution environment के साथ मिलाना ठीक वही है जिसका production teams इंतज़ार कर रही थीं।

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 बनाता है।

.NET Aspire 13.2 आपके AI Agent का सबसे अच्छा दोस्त बनना चाहता है

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

क्या आप जानते हैं वह moment जब आपका AI coding agent कुछ solid code लिखता है, आप excited हो जाते हैं, और फिर वह चीज़ चलाने की कोशिश में सब बिखर जाता है? Port conflicts, phantom processes, गलत environment variables — अचानक आपका agent features बनाने की जगह startup issues troubleshoot करने में tokens जला रहा है।

Aspire team ने एक thoughtful post छोड़ी है इसी problem के बारे में, और उनका जवाब compelling है: Aspire 13.2 सिर्फ humans के लिए नहीं, बल्कि AI agents के लिए भी design किया गया है।

Aspire as agent infrastructure

यहाँ है Aspire 13.2 agentic development के लिए क्या लाता है:

Typed code में पूरा stack। AppHost पूरी topology define करता है — compilable TypeScript या C# में:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

एक command सब कुछ के लिए। docker compose up, npm run dev, और database startup scripts juggle करने के बजाय, सब कुछ बस aspire start है।

Parallel agents के लिए isolated mode। --isolated के साथ, हर Aspire run को अपने random ports और separate user secrets मिलते हैं।

Telemetry के माध्यम से agent की नज़र। Aspire CLI development के दौरान full OpenTelemetry data expose करता है — traces, metrics, structured logs।

Bowling bumper analogy

Aspire team एक बढ़िया analogy उपयोग करती है: Aspire को AI agents के लिए bowling lane bumpers के रूप में सोचें। अगर agent perfect नहीं है, तो bumpers उसे gutter balls फेंकने से रोकते हैं।

शुरुआत करना

Aspire में नए हैं? get.aspire.dev से CLI install करें। पहले से Aspire use कर रहे हैं? aspire update --self चलाएं। पूरी 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 देखें।

MCP Apps को Fluent API मिला — .NET में तीन Steps में Rich AI Tool UIs बनाएं

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

MCP tools AI agents को capabilities देने के लिए बेहतरीन हैं। लेकिन क्या होगा अगर आपके tool को user को कुछ दिखाना हो — एक dashboard, एक form, एक interactive visualization? यहीं MCP Apps काम आते हैं, और उन्हें build करना अब बहुत आसान हो गया है।

Azure SDK team की Lilian Kasem ने .NET Azure Functions पर MCP Apps के लिए नया fluent configuration API introduce किया, और यह उस तरह का developer experience improvement है जो आपको सोचने पर मजबूर करता है कि यह हमेशा से इतना simple क्यों नहीं था।

MCP Apps क्या हैं?

MCP Apps Model Context Protocol को extend करते हैं जिससे tools अपने खुद के UI views, static assets, और security controls carry कर सकें। सिर्फ text return करने की बजाय, आपका MCP tool full HTML experiences render कर सकता है — interactive dashboards, data visualizations, configuration forms — सब AI agents द्वारा invokable और MCP clients द्वारा users को present किए जाने योग्य।

पहले की दिक्कत यह थी कि यह सब manually wire करने के लिए MCP spec को गहराई से जानना ज़रूरी था: ui:// URIs, special mime types, tools और resources के बीच metadata coordination। मुश्किल नहीं, लेकिन झंझटी।

Fluent API तीन steps में

Step 1: अपना function define करें। बस एक standard Azure Functions MCP tool:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Step 2: इसे MCP App में promote करें। अपने program startup में:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Step 3: अपना HTML view जोड़ें। assets/hello-app.html बनाएं जिसमें आपको जो भी UI चाहिए।

बस। Fluent API सारी MCP spec plumbing handle करता है — synthetic resource function generate करना, सही mime type set करना, वह metadata inject करना जो आपके tool को उसके view से connect करता है।

API surface अच्छी तरह design किया गया है

कुछ चीज़ें जो मुझे वाकई पसंद हैं:

View sources flexible हैं। आप disk पर files से HTML serve कर सकते हैं, या self-contained deployments के लिए resources directly अपनी assembly में embed कर सकते हैं:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP composable है। आप explicitly उन origins को allowlist करते हैं जिनकी आपके app को ज़रूरत है, least-privilege principles follow करते हुए। WithCsp को कई बार call करें और origins accumulate होते हैं:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Visibility control। आप किसी tool को केवल LLM को, केवल host UI को, या दोनों को visible बना सकते हैं। एक ऐसा tool चाहते हैं जो सिर्फ UI render करे और model द्वारा call नहीं होना चाहिए? आसान:

.WithVisibility(McpVisibility.App) // UI-only, model से छुपा हुआ

शुरुआत करें

Preview package जोड़ें:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

अगर आप पहले से Azure Functions के साथ MCP tools build कर रहे हैं, तो यह बस एक package update है। MCP Apps quickstart शुरुआत के लिए सबसे अच्छी जगह है।

निष्कर्ष

MCP Apps AI tooling space में सबसे exciting developments में से एक हैं — ऐसे tools जो सिर्फ काम नहीं करते बल्कि users को कुछ दिखा भी सकते हैं। Fluent API protocol की complexity हटाता है और आपको उस पर focus करने देता है जो मायने रखता है: आपके tool की logic और उसका UI।

Complete API reference और examples के लिए पूरी post पढ़ें।

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 देखें।

VS Code 1.115 — Background Terminal Notifications, SSH Agent Mode, और भी बहुत कुछ

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 अभी आया है, और हालाँकि headline features के मामले में यह थोड़ी हल्की release है, agent-related सुधार genuinely useful हैं अगर आप रोज़ाना AI coding assistants के साथ काम करते हैं।

आइए वो बातें highlight करें जो वाकई जानने लायक हैं।

Background terminals agents को जवाब देते हैं

यह standout feature है। Background terminals अब automatically agents को notify करते हैं जब commands पूरी होती हैं, जिसमें exit code और terminal output शामिल होता है। Background terminals में input prompts भी detect होते हैं और user को दिखाए जाते हैं।

यह क्यों मायने रखता है? अगर आपने background में build commands या test suites चलाने के लिए Copilot के agent mode का उपयोग किया है, तो आप जानते हैं “क्या वो खत्म हुई?” वाली परेशानी — background terminals essentially fire-and-forget थे। अब agent notify होता है जब आपका dotnet build या dotnet test पूरा होता है, output देखता है, और उसी के अनुसार react करता है। यह एक छोटा बदलाव है जो agent-driven workflows को काफी ज्यादा reliable बनाता है।

एक नया send_to_terminal tool भी है जो agents को user confirmation के साथ background terminals में commands भेजने देता है, उस समस्या को fix करते हुए जहाँ timeout के साथ run_in_terminal terminals को background में move कर देता था और उन्हें read-only बना देता था।

SSH remote agent hosting

VS Code अब SSH के ज़रिए remote machines से connect करने, CLI automatically install करने, और उसे agent host mode में start करने को support करता है। इसका मतलब है आपके AI agent sessions सीधे remote environments को target कर सकते हैं — .NET डेवलपर्स के लिए useful जो Linux servers या cloud VMs पर build और test करते हैं।

Agent sessions में edit tracking

Agent sessions के दौरान किए गए file edits अब track और restore होते हैं, diffs, undo/redo, और state restoration के साथ। अगर कोई agent आपके code में changes करता है और कुछ गलत हो जाता है, तो आप देख सकते हैं क्या बदला और उसे वापस ला सकते हैं। Agents को आपका codebase modify करने देने में मन की शांति।

Browser tab awareness और अन्य सुधार

कुछ और quality-of-life additions:

Browser tab tracking — chat अब session के दौरान खोले गए browser tabs को track और link कर सकती है, ताकि agents आपके देख रहे web pages reference कर सकें
Terminal में file paste — files (images सहित) Ctrl+V, drag-and-drop, या right-click से terminal में paste करें
Minimap में test coverage — quick visual overview के लिए test coverage indicators अब minimap में दिखते हैं
Mac पर pinch-to-zoom — integrated browser pinch-to-zoom gestures support करता है
Sessions में Copilot entitlements — status bar Sessions view में usage info दिखाता है
Go to File में Favicon — quick pick list में open web pages favicons दिखाते हैं

अंतिम बात

VS Code 1.115 एक incremental release है, लेकिन agent improvements — background terminal notifications, SSH agent hosting, और edit tracking — AI-assisted development के लिए noticeably smoother experience बनाते हैं। अगर आप .NET projects के लिए Copilot के agent mode का उपयोग कर रहे हैं, तो ये वो quality-of-life fixes हैं जो रोज़ाना friction कम करते हैं।

हर detail के लिए full release notes देखें।

Aspire 13.2 एक Docs CLI लेकर आया है — और आपका AI Agent भी इसका उपयोग कर सकता है

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

आपने वो पल ज़रूर महसूस किया होगा जब आप किसी Aspire AppHost में गहरे डूबे हों, integrations wire up कर रहे हों, और आपको ठीक-ठीक जाँचना हो कि Redis integration किन parameters की उम्मीद करती है। आप browser पर alt-tab करते हैं, aspire.dev पर खोजते हैं, API docs को ध्यान से देखते हैं, फिर editor पर वापस आते हैं। Context खो गया। Flow टूट गया।

Aspire 13.2 ने इसका हल ship किया है। aspire docs CLI आपको official Aspire documentation को सीधे अपने terminal से search, browse, और पढ़ने देता है। और चूंकि यह reusable services से backed है, AI agents और skills वही commands use करके docs lookup कर सकते हैं, न कि ऐसी APIs hallucinate करें जो exist ही नहीं करतीं।

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

David Pine original post में बिल्कुल सही बात कहते हैं: AI agents Aspire apps बनाने में developers की मदद करने में बेकार थे। वे aspire run की जगह dotnet run recommend करते, aspire.dev के docs के लिए learn.microsoft.com reference करते, outdated NuGet packages suggest करते, और — मेरी personal favorite — ऐसी APIs hallucinate करते जो exist ही नहीं करतीं।

क्यों? क्योंकि Aspire polyglot बनने से कहीं ज़्यादा समय तक .NET-specific था, और LLMs ऐसे training data से काम कर रहे हैं जो latest features से पहले का है। जब आप एक AI agent को actual docs lookup करने की क्षमता देते हैं, तो वह अंदाज़े लगाना बंद कर देता है और उपयोगी बनने लगता है।

तीन commands, शून्य browser tabs

CLI refreshingly simple है:

सभी docs list करें

aspire docs list

aspire.dev पर available हर documentation page return करता है। Machine-readable output चाहिए? --format Json जोड़ें।

किसी topic को search करें

aspire docs search "redis"

weighted relevance scoring के साथ titles और content दोनों में search करता है। वही search engine जो internally documentation tooling को power करता है। आपको titles, slugs, और relevance scores के साथ ranked results मिलते हैं।

पूरा page पढ़ें (या सिर्फ एक section)

aspire docs get redis-integration

पूरा page markdown के रूप में आपके terminal में stream करता है। सिर्फ एक section चाहिए?

aspire docs get redis-integration --section "Add Redis resource"

सटीक precision। 500 lines scroll करने की ज़रूरत नहीं। बस वो हिस्सा जो आपको चाहिए।

AI agent का angle

यहाँ AI tooling के साथ build करने वाले developers के लिए दिलचस्प बात है। वही aspire docs commands AI agents के लिए tools की तरह काम करते हैं — skills, MCP servers, या simple CLI wrappers के ज़रिये।

आपके AI assistant के stale training data के आधार पर Aspire APIs बनाने की बजाय, वह aspire docs search "postgres" call कर सकता है, official integration docs ढूंढ सकता है, सही page पढ़ सकता है, और आपको documented approach दे सकता है। Real-time, current documentation — model ने छह महीने पहले जो memorize किया था वह नहीं।

इसके पीछे का architecture जानबूझकर बनाया गया है। Aspire team ने एक one-off integration की बजाय reusable services (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) बनाई हैं। इसका मतलब है कि वही search engine terminal में इंसानों के लिए, आपके editor में AI agents के लिए, और आपके CI pipeline में automation के लिए काम करता है।

Real-world scenarios

Quick terminal lookups: आप तीन files गहरे हैं और Redis config parameters चाहिए। दो commands, नब्बे सेकंड, काम पर वापस:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI-assisted development: आपकी VS Code skill CLI commands को wrap करती है। आप पूछते हैं “Add a PostgreSQL database to my AppHost” और agent जवाब देने से पहले actual docs lookup करता है। कोई hallucinations नहीं।

CI/CD validation: आपकी pipeline AppHost configurations को programmatically official documentation के against validate करती है। --format Json output jq और अन्य tools में cleanly pipe होता है।

Custom knowledge bases: अपना AI tooling बना रहे हैं? Structured JSON output को directly अपने knowledge base में pipe करें:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

कोई web scraping नहीं। कोई API keys नहीं। वही structured data जो docs tooling internally use करती है।

Documentation हमेशा live है

यही वह हिस्सा है जो मुझे सबसे ज़्यादा पसंद है। CLI एक snapshot download नहीं करता — यह ETag-based caching के साथ aspire.dev query करता है। जिस moment docs update होते हैं, आपका CLI और उस पर बना कोई भी skill उसे reflect करता है। कोई stale copies नहीं, कोई “but the wiki said…” moments नहीं।

निष्कर्ष

aspire docs उन छोटी features में से एक है जो एक असली समस्या को cleanly हल करती है। इंसानों को terminal-native documentation access मिलती है। AI agents को अंदाज़े लगाना बंद करके actual docs reference करने का तरीका मिलता है। और यह सब एक ही source of truth से backed है।

अगर आप .NET Aspire के साथ build कर रहे हैं और अभी तक CLI try नहीं किया है, तो aspire docs search "your-topic-here" चलाएं और देखें कैसा लगता है। फिर उन commands को जो भी AI skill या automation setup आप use कर रहे हैं उसमें wrap करने पर विचार करें — आपके agents आपको धन्यवाद देंगे।

David Pine का deep dive देखें कि docs tooling कैसे बनी, और सभी details के लिए official CLI reference।

Microsoft Agent Framework 1.0 पर पहुँचा — .NET Developers के लिए असल में क्या मायने रखता है

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

अगर आप Agent Framework की यात्रा को Semantic Kernel और AutoGen के शुरुआती दिनों से follow कर रहे हैं, तो यह milestone महत्वपूर्ण है। Microsoft Agent Framework ने अभी-अभी version 1.0 हासिल किया है — production-ready, stable APIs, long-term support का वादा। यह .NET और Python दोनों के लिए उपलब्ध है, और वाकई real workloads के लिए तैयार है।

घोषणा के शोर को काटकर, अगर आप .NET के साथ AI-powered apps बना रहे हैं तो जो मायने रखता है उस पर ध्यान देते हैं।

संक्षिप्त में

Agent Framework 1.0 जो पहले Semantic Kernel और AutoGen थे उन्हें एक single, open-source SDK में एकत्रित करता है। एक agent abstraction। एक orchestration engine। कई AI providers। अगर आप enterprise patterns के लिए Semantic Kernel और research-grade multi-agent workflows के लिए AutoGen के बीच झूलते रहे हैं, तो अब रुकिए। यही एक SDK है।

शुरुआत करना लगभग आसान है

.NET में एक working agent यह रहा:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

बस इतना। कुछ lines और आपके पास Azure Foundry के विरुद्ध एक AI agent चल रहा है। Python का equivalent उतना ही संक्षिप्त है। जैसे-जैसे आगे बढ़ें, function tools, multi-turn conversations, और streaming जोड़ें — API surface बड़ा होता जाता है लेकिन अजीब नहीं।

Multi-agent orchestration — यह असली चीज़ है

Single agents demos के लिए ठीक हैं, लेकिन production scenarios में अक्सर coordination की ज़रूरत होती है। Agent Framework 1.0 Microsoft Research और AutoGen से सीधे battle-tested orchestration patterns लेकर आता है:

Sequential — agents क्रम में process करते हैं (writer → reviewer → editor)
Concurrent — कई agents को parallel में fan out करें, results converge करें
Handoff — एक agent intent के आधार पर दूसरे को delegate करता है
Group chat — कई agents discuss करते हैं और solution पर converge होते हैं
Magentic-One — MSR का research-grade multi-agent pattern

सभी streaming, checkpointing, human-in-the-loop approvals, और pause/resume support करते हैं। Checkpointing हिस्सा बेहद ज़रूरी है — long-running workflows process restarts के बाद भी survive करते हैं। हम .NET developers के लिए जिन्होंने Azure Functions के साथ durable workflows बनाए हैं, यह जाना-पहचाना लगता है।

सबसे ज़्यादा मायने रखने वाले features

जो जानने लायक है उसकी मेरी shortlist:

Middleware hooks। आप जानते हैं कैसे ASP.NET Core में middleware pipelines होती हैं? वही concept, लेकिन agent execution के लिए। हर stage को intercept करें — agent prompts को छुए बिना content safety, logging, compliance policies जोड़ें। यही तरीका है agents को enterprise-ready बनाने का।

Pluggable memory। Conversational history, persistent key-value state, vector-based retrieval। अपना backend चुनें: Foundry Agent Service, Mem0, Redis, Neo4j, या खुद का बनाएँ। Memory ही एक stateless LLM call को ऐसे agent में बदलती है जो वाकई context याद रखता है।

Declarative YAML agents। अपने agent की instructions, tools, memory, और orchestration topology को version-controlled YAML files में define करें। Single API call से load और run करें। जो teams बिना code redeploy किए agent behavior पर iterate करना चाहती हैं, उनके लिए यह game-changer है।

A2A और MCP support। MCP (Model Context Protocol) agents को dynamically external tools discover और invoke करने देता है। A2A (Agent-to-Agent protocol) cross-runtime collaboration सक्षम करता है — आपके .NET agents दूसरे frameworks में चल रहे agents के साथ coordinate कर सकते हैं। A2A 1.0 support जल्द आ रहा है।

देखने लायक preview features

1.0 में कुछ features preview के रूप में ship हुए हैं — functional हैं लेकिन APIs बदल सकती हैं:

DevUI — agent execution, message flows, और tool calls को real time में visualize करने के लिए browser-based local debugger। Application Insights की तरह समझें, लेकिन agent reasoning के लिए।
GitHub Copilot SDK और Claude Code SDK — अपने orchestration code से सीधे Copilot या Claude को agent harness के रूप में use करें। एक coding-capable agent को उसी workflow में अपने दूसरे agents के साथ compose करें।
Agent Harness — agents को shell, file system, और messaging loops तक access देने वाला customizable local runtime। Coding agents और automation patterns सोचें।
Skills — reusable domain capability packages जो agents को out of the box structured capabilities देते हैं।

Semantic Kernel या AutoGen से migrate करना

अगर आपके पास existing Semantic Kernel या AutoGen code है, तो dedicated migration assistants हैं जो आपका code analyze करते हैं और step-by-step migration plans generate करते हैं। Semantic Kernel migration guide और AutoGen migration guide सब कुछ walk through करते हैं।

अगर आप RC packages पर हैं, तो 1.0 में upgrade करना बस एक version bump है।

Wrapping up

Agent Framework 1.0 वह production milestone है जिसका enterprise teams को इंतज़ार था। Stable APIs, multi-provider support, orchestration patterns जो scale पर वाकई काम करते हैं, और Semantic Kernel और AutoGen दोनों से migration paths।

Framework GitHub पर पूरी तरह open source है, और आप आज ही dotnet add package Microsoft.Agents.AI से शुरुआत कर सकते हैं। हाथ गंदे करने के लिए quickstart guide और samples देखें।

अगर आप “production में use करना safe है” का signal ढूंढ रहे थे — यह रहा।

Aspire 13.2 के Dashboard को मिला Telemetry API — और इसने सब कुछ बदल दिया

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

अगर आप .NET Aspire के साथ distributed apps बना रहे हैं, तो आप पहले से जानते हैं कि dashboard पूरे experience की सबसे अच्छी चीज़ है। आपके सारे traces, logs और metrics एक जगह — कोई external Jaeger नहीं, कोई Seq setup नहीं, कोई “let me check the other terminal” के moments नहीं।

Aspire 13.2 ने इसे काफी बेहतर बना दिया है। James Newton-King ने update की घोषणा की, और सच कहूँ तो? Telemetry export और API features अकेले ही upgrade के लायक हैं।

Telemetry export अब एक समझदार तरीके से

यहाँ वो scenario है जो हम सभी ने झेला है: आप एक distributed issue debug कर रहे हैं, बीस मिनट की setup के बाद आखिरकार इसे reproduce करते हैं, और अब आपको अपनी team के साथ share करना है कि क्या हुआ। पहले? Screenshots। Trace IDs copy-paste करना। वही पुरानी गड़बड़।

Aspire 13.2 में एक proper Manage logs and telemetry dialog जुड़ा है जहाँ आप कर सकते हैं:

सारी telemetry clear करना (repro attempt से पहले उपयोगी)
Selected telemetry को standard OTLP/JSON format में ZIP file में export करना
उस ZIP को किसी भी Aspire dashboard में बाद में re-import करना

वह आखिरी हिस्सा killer feature है। आप एक bug reproduce करते हैं, telemetry export करते हैं, इसे अपने work item में attach करते हैं, और आपका teammate इसे अपने dashboard में import कर सकता है ताकि ठीक वही देख सके जो आपने देखा। अब “क्या आप इसे अपनी machine पर reproduce कर सकते हैं?” नहीं पूछना पड़ेगा।

Individual traces, spans और logs को भी उनके context menus में “Export JSON” का option मिलता है। एक specific trace share करनी है? Right-click, JSON copy करें, PR description में paste करें। हो गया।

Telemetry API असली game changer है

यही वो चीज़ है जिसके बारे में मैं सबसे ज़्यादा excited हूँ। Dashboard अब telemetry data को programmatically query करने के लिए /api/telemetry के नीचे एक HTTP API expose करता है। Available endpoints:

GET /api/telemetry/resources — telemetry वाले resources की list
GET /api/telemetry/spans — filters के साथ spans query करें
GET /api/telemetry/logs — filters के साथ logs query करें
GET /api/telemetry/traces — traces की list
GET /api/telemetry/traces/{traceId} — एक specific trace के सभी spans पाएं

सब कुछ OTLP JSON format में वापस आता है। यह नए aspire agent mcp और aspire otel CLI commands को power करता है, लेकिन असली implication बड़ा है: अब आप tooling, scripts और AI agent integrations बना सकते हैं जो आपके app की telemetry को directly query करें।

सोचिए एक AI coding agent जो debugging के दौरान आपके actual distributed traces देख सके। यह अब hypothetical नहीं है — यह वही है जो यह API enable करता है।

GenAI telemetry practical हो गई

अगर आप Semantic Kernel या Microsoft.Extensions.AI के साथ AI-powered apps बना रहे हैं, तो आप improved GenAI telemetry visualizer की सराहना करेंगे। Aspire 13.2 में जुड़ा:

AI tool descriptions Markdown के रूप में rendered
Traces page पर quick AI trace access के लिए एक dedicated GenAI button
Truncated या non-standard GenAI JSON के लिए बेहतर error handling
Tool definitions के बीच click-to-highlight navigation

Blog post में बताया गया है कि VS Code Copilot chat, Copilot CLI, और OpenCode सभी OTEL_EXPORTER_OTLP_ENDPOINT configure करने का support करते हैं। उन्हें Aspire dashboard पर point करें और आप literally telemetry के ज़रिए real time में अपने AI agents की सोच देख सकते हैं। यह एक debugging experience है जो आपको और कहीं नहीं मिलेगी।

अंत में

Aspire 13.2 dashboard को “nice debugging UI” से “programmable observability platform” बना देता है। Export/import workflow अकेले ही distributed debugging में real time बचाता है, और telemetry API AI-assisted diagnostics का दरवाज़ा खोलता है।

अगर आप पहले से Aspire पर हैं, upgrade करें। अगर नहीं हैं — यह aspire.dev देखने का एक अच्छा कारण है और समझने का कि इतना शोर क्यों है।

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 से शुरू करें।

Visual Studio के March अपडेट में Custom Copilot Agents बनाने की सुविधा — और find_symbol टूल एक बड़ी बात है

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

Visual Studio को अब तक का सबसे महत्वपूर्ण Copilot अपडेट मिला है। Mark Downie ने March release की घोषणा की, और headline custom agents की है — लेकिन सच कहें तो थोड़ा आगे छुपा find_symbol टूल वह feature हो सकता है जो आपके workflow को सबसे ज्यादा बदलेगा।

आइए देखें यहाँ वास्तव में क्या है।

आपके repo में Custom Copilot agents

चाहते हैं कि Copilot आपकी टीम के coding standards का पालन करे, आपका build pipeline चलाए, या आपके internal docs query करे? अब आप ठीक वैसा ही बना सकते हैं।

Custom agents को .agent.md files के रूप में परिभाषित किया जाता है जिन्हें आप अपने repository में .github/agents/ में रखते हैं। प्रत्येक agent को workspace awareness, code understanding, tools, आपका preferred model, और external services से MCP connections तक पूरी access मिलती है। वे built-in agents के साथ agent picker में दिखते हैं।

यह वही pattern है जो VS Code support करता रहा है — और यह देखकर अच्छा लगता है कि Visual Studio भी catch up कर रहा है। जिन टीमों ने VS Code के लिए agents बनाए हैं, उनकी .agent.md files दोनों IDEs में काम करनी चाहिए (हालाँकि tool names भिन्न हो सकते हैं, इसलिए test करें)।

awesome-copilot repo में community-contributed agent configurations हैं जिन्हें आप starting points के रूप में use कर सकते हैं।

Agent skills: reusable instruction packs

Skills आपके repo में .github/skills/ या आपके profile में ~/.copilot/skills/ से automatically pick up होती हैं। प्रत्येक skill एक SKILL.md file है जो Agent Skills specification का पालन करती है।

Skills को modular expertise के रूप में सोचें जिन्हें आप mix और match कर सकते हैं। आपके पास आपके API conventions के लिए एक skill हो सकती है, testing patterns के लिए एक और, और deployment workflow के लिए एक अलग। जब कोई skill activate होती है, तो वह chat में दिखती है ताकि आप जान सकें कि वह apply हो रही है।

अगर आप VS Code में skills use कर रहे थे, तो अब वे Visual Studio में भी उसी तरह काम करती हैं।

यहाँ चीजें वाकई दिलचस्प हो जाती हैं। नया find_symbol टूल Copilot के agent mode को actual language-service-powered symbol navigation देता है। आपके code को text के रूप में search करने की बजाय, एजेंट अब कर सकता है:

पूरे project में किसी symbol के सभी references खोजना
type information, declarations, और scope metadata access करना
पूरी language awareness के साथ call sites पर navigate करना

व्यावहारिक रूप से इसका मतलब है: जब आप Copilot से कोई method refactor करने या call sites में parameter signature update करने को कहते हैं, तो वह वास्तव में आपके code की structure देख सकता है। अब “एजेंट ने method बदल दिया लेकिन तीन call sites miss कर दिए” जैसी स्थितियाँ नहीं होंगी।

Supported languages में C#, C++, Razor, TypeScript, और supported LSP extension वाली कोई भी language शामिल है। .NET डेवलपर्स के लिए यह एक बड़ा सुधार है — deep type hierarchies और interfaces वाले C# codebases symbol-aware navigation से बहुत फायदा उठाते हैं।

Copilot से tests profile करें

Test Explorer context menu में अब Profile with Copilot command है। कोई test select करें, profile पर click करें, और Profiling Agent automatically उसे run करके performance analyze करता है — actionable insights देने के लिए CPU usage और instrumentation data को मिलाकर।

अब manually profiler sessions configure नहीं करने, test run नहीं करने, results export नहीं करने, और flame graph पढ़ने की कोशिश नहीं करनी होगी। एजेंट analysis करता है और बताता है क्या slow है और क्यों। अभी केवल .NET के लिए, जो Visual Studio के deep .NET diagnostics integration को देखते हुए समझ में आता है।

Live debugging के दौरान performance tips

Performance optimization अब debug करने के बाद नहीं, debug करते समय होती है। जब आप code में step through करते हैं, Visual Studio execution time और performance signals inline दिखाता है। कोई slow line दिखे? Perf Tip पर click करें और Copilot से वहीं optimization suggestions माँगें।

Profiling Agent automatically runtime data capture करता है — elapsed time, CPU usage, memory behavior — और Copilot उसका उपयोग hot spots पहचानने के लिए करता है। यह performance work को आपके debugging flow का हिस्सा बनाए रखता है, न कि एक अलग काम जिसे आप टालते रहते हैं।

Solution Explorer से NuGet vulnerabilities fix करें

जब किसी NuGet package में vulnerability detect होती है, तो अब Solution Explorer में सीधे Fix with GitHub Copilot link के साथ notification दिखता है। Click करें और Copilot vulnerability analyze करता है, सही package updates recommend करता है, और उन्हें implement करता है।

उन टीमों के लिए जो dependencies up to date रखने में संघर्ष करती हैं (यानी लगभग सभी), यह “मुझे पता है vulnerability है लेकिन सही update path निकालना अपने आप में एक project है” वाली परेशानी दूर करता है।

अंतिम बात

Custom agents और skills headline हैं, लेकिन find_symbol sleeper hit है — यह मौलिक रूप से बदलता है कि Copilot .NET code refactor करते समय कितना accurate हो सकता है। Live profiling integration और vulnerability fixes के साथ मिलकर, यह अपडेट Visual Studio के AI features को demo-ready की बजाय genuinely practical बनाता है।

इसे आज़माने के लिए Visual Studio 2026 Insiders download करें।

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 देखें।

VS Code 1.112: .NET डेवलपर्स के लिए वाकई जरूरी बातें

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

VS Code 1.112 आ गया है, और सच कहें तो? अगर आप अपने दिन .NET में बिता रहे हैं तो यह release अलग ही feel कराती है। official release notes में बहुत कुछ है, लेकिन मैं आपकी scrolling बचाता हूँ और focus करता हूँ उन चीज़ों पर जो हमारे लिए वाकई मायने रखती हैं।

Copilot CLI और भी उपयोगी हो गया

इस release का बड़ा theme है agent autonomy — Copilot को हर कदम पर निगरानी किए बिना काम करने की ज्यादा जगह देना।

Message steering और queueing

वह पल जब Copilot CLI किसी task के बीच में होता है और आपको याद आता है कि कुछ बताना भूल गए? पहले आपको इंतजार करना पड़ता था। अब आप request चलते हुए भी messages भेज सकते हैं — या तो current response को steer करने के लिए या follow-up instructions queue करने के लिए।

यह उन लंबे dotnet scaffolding tasks के लिए बहुत काम का है जहाँ आप Copilot को project setup करते देख रहे होते हैं और सोचते हैं “अरे रुको, मुझे MassTransit भी चाहिए था।”

Permission levels

यह वाला मुझे सबसे ज्यादा excited करता है। Copilot CLI sessions अब तीन permission levels support करती हैं:

Default Permissions — सामान्य flow जहाँ tools चलने से पहले confirmation माँगते हैं
Bypass Approvals — सब कुछ auto-approve करता है और errors पर retry करता है
Autopilot — पूरी तरह autonomous: tools approve करता है, अपने सवालों के खुद जवाब देता है, और task पूरा होने तक चलता रहता है

अगर आप एक नई ASP.NET Core API Entity Framework, migrations, और Docker setup के साथ scaffold कर रहे हैं — Autopilot mode का मतलब है कि आप बताएं क्या चाहिए और coffee लेने चले जाएं। यह खुद figure out कर लेगा।

Autopilot को chat.autopilot.enabled setting से enable कर सकते हैं।

Delegation से पहले changes preview करें

जब आप Copilot CLI को कोई task delegate करते हैं, तो यह एक worktree बनाता है। पहले, अगर आपके uncommitted changes थे, तो आपको Source Control में देखना पड़ता था। अब Chat view में decision लेने से पहले ही pending changes दिखते हैं — copy, move, या ignore करने के लिए।

छोटी बात है, लेकिन “रुको, मेरे पास क्या staged था?” वाला पल बचाती है।

VS Code से बाहर निकले बिना web apps debug करें

Integrated browser अब full debugging support करता है। आप breakpoints set कर सकते हैं, code step through कर सकते हैं, और variables inspect कर सकते हैं — सब VS Code के अंदर। Edge DevTools में switch करने की जरूरत नहीं।

एक नया editor-browser debug type है, और अगर आपके पास पहले से msedge या chrome launch configurations हैं, तो migrate करना उतना ही आसान है जितना launch.json में type field बदलना:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Blazor डेवलपर्स के लिए यह game changer है। आप terminal में dotnet watch पहले से चला रहे हैं — अब आपकी debugging भी उसी window में रहती है।

Browser को independent zoom levels भी मिले (आखिरकार), proper right-click context menus, और zoom हर website के लिए याद रखा जाता है।

MCP server sandboxing

यह आप जितना सोच रहे हैं उससे ज्यादा मायने रखता है। अगर आप MCP servers use कर रहे हैं — शायद आपने Azure resources या database queries के लिए custom बनाया है — तो वे आपके VS Code process जितनी ही permissions के साथ चल रहे थे। यानी आपके filesystem, network, सब कुछ तक पूरी access।

अब आप उन्हें sandbox कर सकते हैं। अपने mcp.json में:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

जब किसी sandboxed server को कोई ऐसी चीज़ चाहिए जो उसके पास नहीं है, VS Code आपसे permission grant करने को कहता है। “उम्मीद है कोई कुछ अजीब नहीं करेगा” वाले तरीके से कहीं बेहतर।

Monorepo customizations discovery

अगर आप monorepo में काम कर रहे हैं (और सच कहें तो, कई enterprise .NET solutions आखिरकार एक बन जाते हैं), तो यह एक असली समस्या हल करता है।

पहले, अगर आप अपने repo का कोई subfolder खोलते थे, VS Code आपकी copilot-instructions.md, AGENTS.md, या custom skills जो repository root पर थीं, नहीं खोज पाता था। अब chat.useCustomizationsInParentRepositories setting के साथ, यह .git root तक जाकर सब कुछ खोजता है।

इसका मतलब है कि आपकी टीम monorepo के सभी projects में agent instructions, prompt files, और custom tools share कर सकती है, बिना सभी को root folder खोलने की जरूरत के।

Agent debugging के लिए /troubleshoot

कभी custom instructions या skills set up किए और सोचा क्यों pick up नहीं हो रहीं? नई /troubleshoot skill agent debug logs पढ़ती है और बताती है क्या हुआ — कौन से tools use हुए या skip हुए, instructions क्यों load नहीं हुए, और slow responses का कारण क्या है।

इसे enable करें:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

फिर chat में बस /troubleshoot why is my custom skill not loading? type करें।

अब आप इन debug logs को export और import भी कर सकते हैं, जो तब बहुत काम आता है जब कुछ expected नहीं चल रहा हो और team के साथ share करना हो।

Image और binary file support

Agents अब disk से image files और binary files natively पढ़ सकते हैं। Binary files hexdump format में present होती हैं, और image outputs (जैसे integrated browser के screenshots) carousel view में दिखती हैं।

.NET डेवलपर्स के लिए सोचें: UI bug का screenshot chat में paste करें और agent समझे क्या गलत है, या Blazor component rendering का output analyze करवाएं।

Automatic symbol references

एक छोटा quality-of-life सुधार: जब आप किसी symbol का नाम (class, method, आदि) copy करके chat में paste करते हैं, VS Code अब automatically उसे #sym:Name reference में convert कर देता है। इससे agent को उस symbol का पूरा context मिल जाता है बिना आपको manually add किए।

अगर plain text चाहिए तो Ctrl+Shift+V use करें।

Plugins अब enable/disable हो सकते हैं

पहले, MCP server या plugin disable करने का मतलब था उसे uninstall करना। अब आप उन्हें on और off toggle कर सकते हैं — globally और per-workspace दोनों तरह से। Extensions view या Customizations view में right-click करें और काम हो गया।

npm और pypi के plugins अब auto-update भी हो सकते हैं, हालाँकि वे पहले approval माँगेंगे क्योंकि updates का मतलब है आपकी machine पर नया code चलाना।

अंतिम बात

VS Code 1.112 clearly agent experience पर जोर दे रहा है — अधिक autonomy, बेहतर debugging, tighter security। .NET डेवलपर्स के लिए, integrated browser debugging और Copilot CLI improvements standout features हैं।

अगर आपने अभी तक किसी .NET project के लिए Copilot CLI session Autopilot mode में नहीं चलाई है, तो यह release शुरू करने का अच्छा समय है। बस अपनी permissions set करें और इसे करने दें।

VS Code 1.112 download करें या VS Code के अंदर Help > Check for Updates से update करें।