Governance, resilience, optimization, और publishing

Foundry Control Plane, Microsoft Foundry portal में subscription भर के agents, models और tools के लिए एकीकृत management view है। यह तब ज़रूरी हो जाता है जब आप एक demo agent से आगे बढ़ते हैं: हर project की अपनी settings होती हैं, लेकिन compliance और लागत के सवाल पूरी organization के होते हैं।

अवधारणा 15 ने एक project के guardrails, encryption और network isolation समझाए। यह अवधारणा कई agents को production में चलाने की है—fleet health देखना, organization-wide नियम लागू करना, outage सहना, agent optimizer से quality बढ़ाना, और agents को उन्हीं apps में publish करना जहाँ लोग पहले से काम करते हैं। Control Plane तब लें जब agents कई teams या platforms पर हों, centralized compliance visibility चाहिए, Microsoft Defender और Microsoft Purview signals जोड़ने हों, या पूरे environment में token usage और लागत track करनी हो। इसके बिना आप अलग-अलग project views और Azure portal blades के बीच कूदते रहते हैं।

• Inventory और health: active agents, run completion, cost trends और alerts एक subscription-wide view में।
• Performance और risk: evaluation results, traces और red teaming को जोड़कर quality या safety regressions पकड़ना।
• Compliance और security: guardrail policies बनाना, bulk fixes लगाना, और dashboard पर Defender और Purview alerts देखना।
• Docs में prerequisite: tools के advanced governance features के लिए Foundry resource पर AI gateway connect करें।

Fleet features Microsoft Foundry portal से खुलते हैं। Upper-right toolbar पर Operate चुनें—subscription भर के agents, models और deployments monitor, govern और optimize करने के लिए। Manage चुनें जब settings उस project से जुड़ी हों जो खुला है—quota, AI Gateway, users, connected resources और parent resource details। Operate subscription-wide है; Manage upper left में project name dropdown जिस project पर आप हैं उसी का पालन करता है। दूसरी team की settings बदलने से पहले project बदलें।

Assets से performance और cost signals के आधार पर prompts refine करने, models upgrade करने या configurations tune करने की recommendations मिल सकती हैं। Deep links evaluation और monitoring experiences में ले जाते हैं जब किसी agent को debug करना हो।

Governance इस पर निर्भर करती है कि आप क्या सुरक्षित रख रहे हैं। Model deployments पर Azure Policy से सीमा लगाई जा सकती है ताकि production में सिर्फ approved models और lifecycle states पहुँचें। Model Context Protocol (MCP) वाले बाहरी tools का traffic AI gateway से हो सकता है—authentication, throttling और logging एक front door पर, हर agent के अंदर नहीं।

• Operate पर Compliance में policy काम Azure Policy, Defender और Purview के साथ जुड़ता है ताकि identity, data और threat signals align रहें।
• MCP tools (preview): governance Foundry resource level पर; सिर्फ portal में बने नए MCP tools जो managed OAuth नहीं use करते, gateway से route होते हैं।
• MCP tool जोड़ने के बाद tool endpoint AI gateway URL दिखाए (जैसे azure-api.net/mcp path), raw server URL नहीं। Rate limits जैसी policies Azure portal में Azure API Management पर लगती हैं।
• Gateway routing tool create होते समय लगता है; पुराने tools अपने आप switch नहीं होते—gateway connect के बाद tool दोबारा बनाएँ अगर routing अभी भी server पर है।

Resilience का मतलब है agents चलते रहें या जल्दी recover हों जब zone, region या human mistake कुछ बंद कर दे। Microsoft Foundry के regional platform हिस्से चलाता है, लेकिन docs साफ कहते हैं: Foundry automatic failover या disaster recovery नहीं देता। ज़िम्मेदारी बँटी है: Microsoft Agent Service में agent runtime infrastructure चलाता है; Standard agent deployment mode में state stores की durability आपकी है।

Basic agent deployment mode में Microsoft data components manage करता है और recovery options सीमित रहते हैं। Standard mode में agent state आपके Azure Cosmos DB, Azure AI Search और Azure Storage accounts में होता है—backup, redundancy और failover आप configure करते हैं। Key Vault, Application Insights, Logic Apps जैसे optional attachments भी आपको harden करने पड़ते हैं, भले हर workload को Foundry के लिए वे ज़रूरी न हों।

• Platform outages और अपने data stores के accidental deletion के लिए अलग योजना बनाएँ।
• Cosmos DB, AI Search और Storage पर region के अंदर zone-redundant settings use करें; zone redundancy दूसरे region की जगह नहीं लेती।
• Model inference के लिए Global Standard और Data Zone Standard deployments अपने allowed scope में route कर सकते हैं, लेकिन regional failover के लिए application logic या Generative AI Gateway (अक्सर Azure API Management) regional endpoints के सामने चाहिए।
• Multiregional strategies (hot/hot, hot/warm, hot/cold) लागत और recovery time trade off करती हैं; Foundry projects आप region के हिसाब से बनाते हैं।

रोकथाम restore से बेहतर है। Foundry account, Cosmos DB account, AI Search service और Storage account पर delete locks लगाएँ ताकि resource-level deletion रुके। Locks पूरे resource को हटने से रोकते हैं, लेकिन उसके अंदर से एक agent, index या blob हटाने को नहीं रोकते। Locks के साथ least-privilege role assignments रखें: production में standing delete permissions avoid करें, और state stores पर write access जहाँ संभव हो सिर्फ project की managed identity को दें।

• Project पर user-assigned managed identity use करें ताकि restored resources बina हर role दोबारा assign किए reattach हों; system-assigned identities recreate पर नया principal ID लेती हैं।
• Accounts, projects और dependencies infrastructure as code (Bicep या Terraform) में define करें और agent JSON definitions schedule पर export करें—Foundry primary और secondary projects के बीच metadata sync नहीं करता।
• Azure AI Search को derived index मानें, knowledge की एकमात्र copy नहीं; thread-attached uploads आम तौर पर recover नहीं होते।
• Incident से पहले Cosmos DB continuous backup चालू करें; point-in-time restore बाद में on नहीं किया जा सकता। 7-day, 30-day या 35-day retention अपनी ज़रूरत के हिसाब से चुनें।

Agent optimizer वह धीमा loop automate करता है: prompt edit, tests चलाना, फिर revise। यह baseline prompt agent या hosted agent को dataset पर evaluate करता है, candidate configurations (instructions, tool descriptions, skills या model choices) बनाता है, evaluators से score करता है, और composite score 0.0 से 1.0 के बीच rank करता है। अवधारणा 8 ने evaluation introduce किया; यहाँ उन्हीं evaluators से publish से पहले automated improvements चलते हैं।

• Prompt agents: agent के Optimize tab से optimization wizard शुरू करें; version, dataset, evaluators और models चुनें; run complete होने पर winning candidate को नए version में promote करें।
• Hosted agents: agent को optimizer-ready बनाएँ (Foundry Toolkit या Azure Developer CLI), फिर local JSONL या registered datasets पर optimization चलाएँ; candidate apply करके redeploy करें।
• हर evaluator score 0–1 पर rescale होता है, lower is better हो तो flip, फिर composite score के लिए average।
• Docs की चेतावनी: optimization dataset की हर row पर agent कॉल करता है—external tool calls mock या test endpoints के बिना असली चल सकती हैं।

Publishing tested agent को Microsoft Copilot और Microsoft Teams पर भेजता है ताकि coworkers familiar apps में उसे discover करें। आप stable agent endpoint publish करते हैं—users को same URL मिलता है जबकि पीछे versions बदलते हैं। Publish से पहले active version चुनें: Details tab (Agent configuration, Active version के पास Edit) या Publish flow में—Always use latest या pinned version। Version selector update करने से behavior बदलता है बिना Teams पर republish; name या descriptions बदलने के लिए Update agent Teams and Microsoft Copilot display properties use करें।

Project जब public network access disable करता है तब portal से publishing support नहीं; docs में REST API path use करें। Azure Bot Service resources बनाने की permission और project पर Foundry User role चाहिए। Autopilots long-running team या company-wide agents के लिए कहानी बढ़ाते हैं: Entra agent user account जोड़ते हैं ताकि agent Microsoft 365 में खुद के रूप में act करे (email, calendar, Teams presence)। Blueprint एक बार बनता है; हर team अपना instance hire करती है अलग permissions के साथ। Autopilot blueprint के रूप में सिर्फ hosted agents publish हो सकते हैं।

उदाहरण: Northwind Outfitters returns assistant (अवधारणा 7) Standard mode में चलाता है। Platform team Control Plane Operate views चालू करती है, Azure Policy से सिर्फ approved chat models deploy होते हैं, और नया GitHub MCP tool AI gateway (preview) से route होता है। वे Cosmos DB और Search accounts lock करते हैं, रोज़ agent JSON export करते हैं, और अवधारणा 14 evaluations pass होने के बाद optimizer चलाते हैं। Admin approval के बाद Teams पर People in your organization scope से publish करते हैं, version 3 pin रखते हैं जब तक अगला optimizer win न आए, और हर quarter secondary region में test job चलाकर failover rehearse करते हैं।

• सोचना कि Foundry अपने आप fail over कर देगा—regions, gateways और secondary projects खुद plan करें।
• Regression-tested version ready होने से पहले Always use latest के साथ publish करना।
• AI gateway verify skip करना और फिर wonder करना कि MCP traffic policies (preview) bypass क्यों कर रहा है।
• Search indexes को knowledge की एकमात्र copy मानना—recovery में rebuild pipelines fail होंगे।
• Production APIs पर optimizer चलाना जो live customer data mutate करती हैं।
• Basic deployment mode use करना और Cosmos DB point-in-time restore steps expect करना।

आपने Foundry arc पूरा किया—पहले project से architecture, models, agents, tools, observability, evaluation, guardrails, और अब fleet governance और production publishing। Operate dashboards, evaluation gates और recovery drills को code releases की तरह same rhythm में रखें ताकि portal में सुधार safely users तक पहुँचें।

• Fleet management, Compliance pane, और शुरुआती tasks। Foundry Control Plane overview
• Locks, Cosmos DB backup, multiregion models, और failover checklists। High availability and resiliency for Microsoft Foundry projects and Agent Services
• Composite scoring, optimization targets, और hosted-agent requirements। What is the agent optimizer?
• Direct publish steps, scopes, और published metadata update। Publish agents to Microsoft Copilot and Microsoft Teams in the Foundry portal