Agents, identity, workflows, और routines

Agent identity, Microsoft Entra ID का एक identity प्रकार है जो AI agents के लिए बना है। Foundry इसे agent के पूरे lifecycle में बनाती और संभालती है, ताकि agent tools और data तक पहुँच सके और आपको prompts, connection strings, या code में secrets न चिपकाने पड़ें। यही मॉडल text-based prompt agents और voice-based prompt agents दोनों पर लागू होता है: जब agent किसी tool को कॉल करता है, Entra को पता होता है कि कौन-सा agent काम कर रहा है, सिर्फ़ portal में कौन साइन इन था यह नहीं।

अवधारणा 7 ने tools वाला prompt agent बनाना दिखाया। Production agents अक्सर Azure Storage, Logic Apps, Cosmos DB, Microsoft Graph, MCP servers, या दूसरे agents को कॉल करते हैं। Agent identity AI के काम को लोगों या दूसरे workloads के काम से अलग रखती है, access सही आकार की देती है, और जब आप कई agents जल्दी बनाते या हटाते हैं तब scale होती है।

• Governance: प्रशासक Entra में agents की सूची, policies, और audit कर सकते हैं।
• Tool authentication: agent downstream systems तक embedded passwords के बजाय छोटे समय के tokens से पहुँचता है।
• Least privilege: आप roles agent identity को देते हैं, हर developer के personal account को नहीं।
• Voice agents: Foundry real-time voice session संभालती है और वही identity tool calls की पहचान साबित करती है।

Foundry हर agent को दो Entra objects से जोड़ती है जिनके नाम आपको याद रखने चाहिए। Agent identity blueprint किसी class of agents (जैसे एक product line के सभी agents) का template है। यह lifecycle operations संभालता है और यह साबित करता है कि Agent Service उस class के लिए काम कर सकती है। Agent identity वह runtime principal है जिसे आप permissions देते हैं जब agent को किसी resource तक पहुँच चाहिए। जब आप Foundry project में पहला agent बनाते हैं, Foundry default blueprint और default agent identity provision करती है।

• Shared project identity: एक project में सभी unpublished या in-development agents एक ही identity साझा करते हैं, ताकि आज़माश के दौरान permissions एक बार सेट हों।
• Azure portal में Foundry project के Overview pane पर JSON View चुनें और latest API version से identity details कॉपी करें।
• Distinct agent identity: जब permissions, audit trail, या lifecycle अलग हों, agent publish करें। Publishing dedicated blueprint और agent application resource से बँधी identity बनाती है।
• Publish के बाद tool calls नई identity से होते हैं। Shared project identity पर दिए roles नई identity पर नहीं चलते; published agent की नई identity पर roles फिर से दें।

Unpublished agents tools को shared project identity से पहचान साबित करके कॉल करते हैं। Published agents अपनी unique agent identity इस्तेमाल करते हैं। Voice-based agents भी इसी तरह काम करते हैं। Shared identity का जोखिम का दायरा बड़ा मानें: अगर किसी agent को सख्त नियंत्रण या अलग audit trail चाहिए, उसे publish करें और roles सिर्फ़ नई identity पर दें।

जब agent किसी tool को कॉल करता है, Agent Service Microsoft Entra ID और downstream resource के साथ OAuth token exchange चलाती है। आपको app में tokens store या refresh नहीं करने पड़ते। संक्षेप में, Agent Service साबित करती है कि वह blueprint के लिए काम कर सकती है, Entra specific agent identity के लिए token देता है, Agent Service target service के लिए scoped token माँगती है, और tool endpoint RBAC जाँचने से पहले वह scoped token लेता है।

• Blueprint authentication: Agent Service blueprint के credentials (अक्सर project managed identity के federated trust से) से साबित करती है कि वह उस type के agents का प्रतिनिधित्व कर सकती है।
• Agent identity token: Entra directory में agent को अलग actor के रूप में पहचानने वाला token देता है।
• Scoped token: Agent Service उस token को बदलकर access token लाती है जिसका audience आप जिस downstream service को कॉल कर रहे हैं उससे मेल खाता है।
• Tool call: MCP server या agent-to-agent endpoint token validate करता है और agent identity पर RBAC या दूसरी authorization लागू करता है।

Agent identities दो authentication patterns समर्थन करती हैं। Attended run में agent साइन इन user की ओर से काम करता है: app user का token Agent Service को देती है, और exchange के बाद agent पर agent identity और user की delegated permissions दोनों होती हैं। Agent सिर्फ़ उन्हीं resources तक पहुँच सकता है जिन पर user ने consent दिया है। Unattended run में dispatch समय कोई human नहीं होता; access पूरी तरह agent identity पर RBAC roles और policies से आता है।

Agent identity को Azure RBAC roles वैसे ही दें जैसे किसी service principal को देते हैं। Project या agent application के JSON View से identity value assignee के रूप में लें। Tools को जितना चाहिए उतना ही, सबसे संकरे scope (resource या resource group) पर दें। MCP और agent-to-agent tools के लिए project connection बनाएँ जो authentication agent identity पर सेट करे और target service का सही audience दे। आज सिर्फ़ कुछ tools agent identity authentication देते हैं; design से पहले tool documentation में जाँचें।

Foundry agent व्यवहार तैयार करने के तीन तरीके देती है। Prompt agent model deployment, instructions, और tools से परिभाषित होता है; Foundry इसे बिना आपके container के चलाती है। Hosted agent आपके deploy किए code को चलाता है, जैसे Microsoft Agent Framework app या LangGraph graph, Foundry के managed runtime पर। Workflow portal builder में बनी एक visual sequence है, जो कई agents और business steps को क्रम से चलाती है। जो सबसे छोटा विकल्प ज़रूरत पूरी करे वही चुनें; एक agent काफ़ी हो तो और मुश्किल न बनाएँ।

Microsoft Foundry में workflows preview में हैं और portal workflows 1 दिसंबर 2026 को बंद होंगे। नई orchestration के लिए Microsoft teams को Microsoft Agent Framework की ओर भेजता है; उस तारीख के बाद visual designer और in-portal workflow execution बंद होंगे, हालाँकि YAML definitions hosted agent के रूप में deploy होने पर चल सकती हैं। Workflow designer में hosted agents शामिल नहीं हैं; hosted agent code से Agent Framework workflows इस्तेमाल करें।

Workflows UI-based tools हैं जो visual builder में AI agents को business logic के साथ मिलाते हैं। Templates आम patterns दिखाते हैं: Human in the loop आगे बढ़ने से पहले व्यक्ति से पूछता है, Sequential हर परिणाम को अगले agent को क्रम में देता है, और Group chat context या rules के हिसाब से agents के बीच control बदलता है। Workflows बनाने या बदलने के लिए project पर Contributor role या उससे ऊपर चाहिए।

• Microsoft Foundry में साइन इन करें, New Foundry toggle on रखें, Build चुनें, फिर Create new workflow और Sequential जैसा pattern चुनें।
• हर agent node चुनें और मौजूदा project agent assign करें या model, prompt, और tools के साथ नया agent बनाएँ।
• Plus (+) icon से nodes जोड़ें: Invoke agent, Logic (if/else, go to, for each), data transformation, या basic chat steps।
• हर बदलाव के बाद visualizer में Save चुनें; Foundry workflows autosave नहीं करती।
• Run Workflow चुनें और हर node complete हो और chat window में expected responses दिखें यह जाँचें।
• वैकल्पिक: YAML Visualizer View on करके YAML के रूप में edit करें; हर save नया version बनाता है और full version history रहती है।

Variables पर Excel जैसे formulas के लिए Power Fx इस्तेमाल करें (scope के लिए Local. या System. prefix)। JSON schemas, prompts, या saved workflow variables में secrets न रखें। अगर Workflows option न दिखे या edits गायब हों, project role assignments जाँचें और Save दबाया है यह पुष्टि करें।

Foundry Agent Service की routines trigger fire होने पर agent को बिना हर run manually शुरू किए automatically चलाती हैं। Routine में exactly एक trigger और एक action होता है जो एक prompt agent या hosted agent कॉल करता है। Input text या JSON हो सकता है। Foundry run history में status, outputs, और agent responses व traces के links रखती है। Daily summaries, one-time reminders, या GitHub issue / Teams channel events पर react करने जैसी हल्की automation के लिए routines इस्तेमाल करें। Branching, कई agents, या human approval चाहिए तो workflow या code में orchestration लें।

• Trigger types: timer (एक बार चलकर inactive), recurring (cron-style schedule; API type schedule; minimum interval पाँच मिनट), और event (GitHub issue opened/closed, या project connections से Teams channel message)।
• Dispatch identity हर trigger पर default agent identity है। Delegated user access चाहिए तो creator identity चुनें; इसका मतलब routine बनाने वाला principal, creation time पर fixed।
• Routines normal agent invocation path reuse करती हैं, virtual-network-secured projects के साथ काम करती हैं, और customer-managed key encryption support नहीं करतीं।
• UK West, Switzerland West, Japan West, UAE North, या Norway East में उपलब्ध नहीं। Delivery transient failures पर पाँच attempts तक retry; हर downstream agent request का 30-second timeout।

उदाहरण: एक online shop में prompt agent open support tickets का summary Azure Storage से MCP tool के जरिए बनाता है। Experiment के दौरान agent shared project identity इस्तेमाल करता है और storage account पर Storage Blob Data Contributor role है। Production के लिए team agent publish करती है, नई distinct identity पर वही role देती है, और recurring routine हर weekday सुबह 7 बजे JSON input के साथ queue name देकर चलाती है। पहले हफ़्ते वे routine run history और traces (अवधारणा 13) देखते हैं। अगर ticket tool creator के personal Graph calendar की ज़रूरत होती, तो agent identity के बजाय creator identity के साथ routine recreate करनी पड़ती।

• Shared identity पर RBAC देना लेकिन published agent से tools कॉल करना (या उलटा)। Roles उस identity से मिलाएँ जो agent आज इस्तेमाल करता है।
• Publish के बाद role reassignment छोड़ना। Publish को नया principal मानें।
• MCP या agent-to-agent connection पर गलत audience सेट करना जब RBAC सही लगे।
• Creator identity को agent owner या connection author समझना; सिर्फ़ routine creator गिना जाता है।
• Routine तब इस्तेमाल करना जब कई agents या workflow agents चाहिए; routines workflow agents को action के रूप में support नहीं करतीं।

अब secure tool access के लिए identity, multi-agent orchestration के लिए workflows (2026 retirement से पहले migration path के साथ), और time- व event-driven runs के लिए routines साफ़ हैं। अवधारणा 12 उन tools पर जाती है जिन्हें ये agents कॉल करते हैं: toolboxes, connection authentication, और governance।

• Blueprint, token exchange, shared vs distinct identity, और tool authentication की detail। Agent identity concepts in Microsoft Foundry
• Foundry roles, scopes, और projects/agents के लिए permission planning। Azure role-based access control in Foundry
• Portal workflow builder, templates, Power Fx, preview terms, और 1 दिसंबर 2026 से पहले migration। Build a workflow in Microsoft Foundry (Preview)
• Routines के trigger types, dispatch identity, run history, और regional limits। Routines in Foundry Agent Service