Agents | 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 ब्लॉग की पूरी पोस्ट पढ़ें।

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

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

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

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

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

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

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

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

Azure MCP Server क्या है?

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

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

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

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

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

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

Security hardening

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

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

Getting started

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

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

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

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

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

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

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

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

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

यहाँ setup है:

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

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

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

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

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

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

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

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

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

@git-ape destroy my-resource-group

मेरी राय

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

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

अंत में

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

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

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 करें शुरुआत के लिए।

VS Code 1.116 — Agents App में Keyboard Navigation और File Context Completions

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

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

VS Code 1.116 April 2026 release है, और हालाँकि यह कुछ recent updates से हल्की है, बदलाव focused और meaningful हैं — खासकर अगर आप रोज़ाना Agents app use कर रहे हैं।

official release notes के आधार पर, यहाँ क्या मिला है।

Agents app में सुधार

Agents app उपयोगिता polish के साथ mature होता जा रहा है जो रोज़मर्रा के workflows में वास्तविक फर्क डालती है:

Dedicated keybindings — अब आप dedicated commands और keyboard shortcuts से Changes view, Changes के अंदर files tree, और Chat Customizations view focus कर सकते हैं। अगर आप Agents app में navigate करने के लिए click करते रहे हैं, तो यह पूरी keyboard-driven workflows लाता है।

Accessibility help dialog — chat input box में Alt+F1 दबाने पर अब एक accessibility help dialog खुलता है जो available commands और keybindings दिखाता है। Screen reader users announcement verbosity भी control कर सकते हैं। अच्छी accessibility सभी को फायदा पहुँचाती है।

File-context completions — Agents app chat में # type करें और आपके current workspace तक scoped file-context completions trigger होती हैं। यह उन छोटे quality-of-life improvements में से एक है जो हर interaction को तेज़ बनाती है — code reference करते समय अब पूरे file paths type नहीं करने होंगे।

CSS `@import` link resolution

Frontend developers के लिए एक अच्छी addition: VS Code अब CSS @import references resolve करता है जो node_modules paths use करते हैं। आप bundlers use करते समय @import "some-module/style.css" जैसे imports को Ctrl+click से follow कर सकते हैं। छोटा है लेकिन CSS workflows में एक friction point खत्म करता है।

अंतिम बात

VS Code 1.116 refinement के बारे में है — Agents app को अधिक navigable, अधिक accessible, और अधिक keyboard-friendly बनाना। अगर आप Agents app में काफी समय बिता रहे हैं (और मुझे लगता है हम में से कई बिता रहे हैं), तो ये बदलाव जुड़ते जाते हैं।

पूरी list के लिए full release notes देखें।

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

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)

अगर आप azure-ai-agents package से आ रहे हैं, तो अब agents azure-ai-projects में AIProjectClient पर first-class operations हैं। standalone pin हटाएं और responses चलाने के लिए get_openai_client() इस्तेमाल करें।

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

Agents | The .NET Blog

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

CodeAct क्या है?

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

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

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

अभी आज़माएं

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

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

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

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

कैसे चुनें

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

Toolbox क्या है

चार pillars (आज दो available)

Practical Example

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

अभी क्यों important है

निष्कर्ष

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

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

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

Subagents और agent teams

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

macOS पर self-updating Agents app

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

निष्कर्ष

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

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

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

Deploy करना genuinely simple है

Built-in conversation management

मेरा decision framework

निष्कर्ष

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

Azure MCP Server क्या है?

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

Security hardening

Getting started

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

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

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

मेरी राय

अंत में

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

Foundry Agent Service production-ready है

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

SDK आखिरकार stable है

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

अन्य highlights

निष्कर्ष

VS Code 1.116 — Agents App में Keyboard Navigation और File Context Completions

Agents app में सुधार

CSS @import link resolution

अंतिम बात

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

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

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

Container App Jobs और deployment improvements

Developer experience की polish

निष्कर्ष

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

Responses API पर निर्मित

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

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

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

Evaluations: checkbox से continuous monitoring तक

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

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

निष्कर्ष

CSS `@import` link resolution