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

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-बैक्ड प्रदाता के साथ क्लाइंट-मैनेज्ड
सिंपल चैटबॉट? → लीनियर सर्विस-मैनेज्ड ठीक है

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

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

रियल-टाइम 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 देखें।

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 ढूंढ रहे थे — यह रहा।

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