Get to know the core Foundry solutions
Foundry includes specialized services for vision, language, documents, and search, plus Microsoft Foundry for orchestration and governance. Here’s what each does and why it matters: Azure Vision With Azure Vision, you can detect common objects in images, generate captions, descriptions, and tags based on image contents, and read text in images. Example: Automate visual inspections or extract text from scanned documents. Azure Language Azure Language helps organizations understand and work with text at scale. It can identify key information, gauge sentiment, and create summaries from large volumes of content. It also supports building conversational experiences and question-answering tools, making it easier to deliver fast, accurate responses to customers and employees. Example: Understand customer feedback or translate text into multiple languages. Azure Document IntelligenceWith Azure Document Intelligence, you can use pre-built or custom models to extract fields from complex documents such as invoices, receipts, and forms. Example: Automate invoice processing or contract review. Azure SearchAzure Search helps you find the right information quickly by turning your content into a searchable index. It uses AI to understand and organize data, making it easier to retrieve relevant insights. This capability is often used to connect enterprise data with generative AI, ensuring responses are accurate and grounded in trusted information. Example: Help employees retrieve policies or product details without digging through files. Microsoft FoundryActs as the orchestration and governance layer for generative AI and AI agents. It provides tools for model selection, safety, observability, and lifecycle management. Example: Coordinate workflows that combine multiple AI capabilities with compliance and monitoring. Business leaders often ask: Which Foundry tool should I use? The answer depends on your workflow. For example: Are you trying to automate document-heavy processes like invoice handling or contract review? Do you need to improve customer engagement with multilingual support or sentiment analysis? Or are you looking to orchestrate generative AI across multiple processes for marketing or operations? Connecting these needs to the right Foundry solution ensures you invest in technology that delivers measurable results.
Import error: Cannot import name "PromptAgentDefinition" from "azure.ai.projects.models"
Hello, I am trying to build the agentic retrieval using Azure Ai search. During the creation of agent i am getting "ImportError: cannot import name 'PromptAgentDefinition' from 'azure.ai.projects.models'". Looked into possible ways of building without it but I need the mcp connection. This is the documentation i am following: https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-how-to-create-pipeline?tabs=search-perms%2Csearch-development%2Cfoundry-setup Note: There is no Promptagentdefinition in the directory of azure.ai.projects.models. ['ApiKeyCredentials', 'AzureAISearchIndex', 'BaseCredentials', 'BlobReference', 'BlobReferenceSasCredential', 'Connection', 'ConnectionType', 'CosmosDBIndex', 'CredentialType', 'CustomCredential', 'DatasetCredential', 'DatasetType', 'DatasetVersion', 'Deployment', 'DeploymentType', 'EmbeddingConfiguration', 'EntraIDCredentials', 'EvaluatorIds', 'FieldMapping', 'FileDatasetVersion', 'FolderDatasetVersion', 'Index', 'IndexType', 'ManagedAzureAISearchIndex', 'ModelDeployment', 'ModelDeploymentSku', 'NoAuthenticationCredentials', 'PendingUploadRequest', 'PendingUploadResponse', 'PendingUploadType', 'SASCredentials', 'TYPE_CHECKING', '__all__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__', '_enums', '_models', '_patch', '_patch_all', '_patch_evaluations', '_patch_sdk'] Traceback (most recent call last): Please let me know what i should do and if there is any other alternative. Thanks in advance.
Issue with: Connected Agent Tool Forcing from an Orchestrator Agent
Hi Team, I am trying to force tool selection for my Connected Agents from an Orchestrator Agent for my Multi-Agent Model. Not sure if that is possible Apologies in advance for too much detail as I really need this to work! Please let me know if there is a flaw in my approach! The main intention behind going towards Tool forcing was because with current set of instructions provided to my Orchestrator Agent, It was providing hallucinated responses from my Child Agents for each query. I have an Orchestrator Agent which is connected to the following Child Agents (Each with detailed instructions) Child Agent 1 - Connects to SQL DB in Fabric to fetch information from Log tables. Child Agent 2 - Invokes OpenAPI Action tool for Azure Functions to run pipelines in Fabric. I have provided details on 3 approaches. Approach 1: I have checked the MS docs "CONNECTED_AGENT" is a valid property for ToolChoiceType "https://learn.microsoft.com/en-us/python/api/azure-ai-agents/azure.ai.agents.models.agentsnamedtoolchoicetype?view=azure-python" Installed the latest Python AI Agents SDK Beta version as it also supports "Connected Agents": https://pypi.org/project/azure-ai-agents/1.2.0b6/#create-an-agent-using-another-agents The following code is integrated into a streamlit UI code. Python Code: agents_client = AgentsClient( endpoint=PROJECT_ENDPOINT, credential=DefaultAzureCredential( exclude_environment_credential=True, exclude_managed_identity_credential=True ) ) # ------------------------------------------------------------------- # UPDATE ORCHESTRATOR TOOLS (executed once) # ------------------------------------------------------------------- fabric_tool = ConnectedAgentTool( id=FABRIC_AGENT_ID, name="Fabric_Agent", description="Handles Fabric pipeline questions" ) openapi_tool = ConnectedAgentTool( id=OPENAPI_AGENT_ID, name="Fabric_Pipeline_Trigger", description="Handles OpenAPI pipeline triggers" ) # Update orchestrator agent to include child agent tools agents_client.update_agent( agent_id=ORCH_AGENT_ID, tools=[ fabric_tool.definitions[0], openapi_tool.definitions[0] ], instructions=""" You are the Master Orchestrator Agent. Use: - "Fabric_Agent" when the user's question includes: "Ingestion", "Trigger", "source", "Connection" - "Fabric_Pipeline_Trigger" when the question mentions: "OpenAPI", "Trigger", "API call", "Pipeline start" Only call tools when needed. Respond clearly and concisely. """ ) # ------------------------- TOOL ROUTING LOGIC ------------------------- def choose_tool(user_input: str): text = user_input.lower() if any(k in text for k in ["log", "trigger","pipeline","connection"]): return fabric_tool if any(k in text for k in ["openapi", "api call", "pipeline start"]): return openapi_tool # No forced routing → let orchestrator decide return None forced_tool = choose_tool(user_query) run = agents_client.runs.create_and_process( thread_id=st.session_state.thread.id, agent_id=ORCH_AGENT_ID, tool_choice={ "type": "connected_agent", "function": forced_tool.definitions[0] } Error: Azure.core.exceptions.HttpResponseError: (invalid_value) Invalid value: 'connected_agent'. Supported values are: 'code_interpreter', 'function', 'file_search', 'openapi', 'azure_function', 'azure_ai_search', 'bing_grounding', 'bing_custom_search', 'deep_research', 'sharepoint_grounding', 'fabric_dataagent', 'computer_use_preview', and 'image_generation'. Code: invalid_value Message: Invalid value: 'connected_agent'. Supported values are: 'code_interpreter', 'function', 'file_search', 'openapi', 'azure_function', 'azure_ai_search', 'bing_grounding', 'bing_custom_search', 'deep_research', 'sharepoint_grounding', 'fabric_dataagent', 'computer_use_preview', and 'image_generation'." Approach 2: Create ConnectedAgentTool as you do, and pass its definitions to update_agent(...). Force a tool by name using tool_choice={"type": "function", "function": {"name": "<tool-name>"}}. Do not set type: "connected_agent" anywhere—there is no such tool_choice.type. Code: from azure.identity import DefaultAzureCredential from azure.ai.agents import AgentsClient # Adjust imports to your SDK layout: # e.g., from azure.ai.agents.tool import ConnectedAgentTool agents_client = AgentsClient( endpoint=PROJECT_ENDPOINT, credential=DefaultAzureCredential( exclude_environment_credential=True, exclude_managed_identity_credential=True # keep your current credential choices ) ) # ------------------------------------------------------------------- # CREATE CONNECTED AGENT TOOLS (child agents exposed as function tools) # ------------------------------------------------------------------- fabric_tool = ConnectedAgentTool( id=FABRIC_AGENT_ID, # the **child agent ID** you created elsewhere name="Fabric_Agent", # **tool name** visible to the orchestrator description="Handles Fabric pipeline questions" ) openapi_tool = ConnectedAgentTool( id=OPENAPI_AGENT_ID, # another child agent ID name="Fabric_Pipeline_Trigger", # tool name visible to the orchestrator description="Handles OpenAPI pipeline triggers" ) # ------------------------------------------------------------------- # UPDATE ORCHESTRATOR: attach child tools # ------------------------------------------------------------------- # NOTE: definitions is usually a list of ToolDefinition objects produced by the helper agents_client.update_agent( agent_id=ORCH_AGENT_ID, tools=[ fabric_tool.definitions[0], openapi_tool.definitions[0] ], instructions=""" You are the Master Orchestrator Agent. Use: - "Fabric_Agent" when the user's question includes: "Ingestion", "Trigger", "source", "Connection" - "Fabric_Pipeline_Trigger" when the question mentions: "OpenAPI", "Trigger", "API call", "Pipeline start" Only call tools when needed. Respond clearly and concisely. """ ) # ------------------------- TOOL ROUTING LOGIC ------------------------- def choose_tool(user_input: str): text = user_input.lower() if any(k in text for k in ["log", "trigger", "pipeline", "connection"]): return "Fabric_Agent" # return the **tool name** if any(k in text for k in ["openapi", "api call", "pipeline start"]): return "Fabric_Pipeline_Trigger" # return the **tool name** return None forced_tool_name = choose_tool(user_query) # ------------------------- RUN INVOCATION ------------------------- if forced_tool_name: # FORCE a specific connected agent by **function name** run = agents_client.runs.create_and_process( thread_id=st.session_state.thread.id, agent_id=ORCH_AGENT_ID, tool_choice={ "type": "function", # <-- REQUIRED "function": { "name": forced_tool_name # <-- must match the tool's name as registered } } ) else: # Let the orchestrator auto-select (no tool_choice → "auto") run = agents_client.runs.create_and_process( thread_id=st.session_state.thread.id, agent_id=ORCH_AGENT_ID ) Error: azure.core.exceptions.HttpResponseError: (None) Invalid tool_choice: Fabric_Agent. You must also pass this tool in the 'tools' list on the Run. Code: None Message: Invalid tool_choice: Fabric_Agent. You must also pass this tool in the 'tools' list on the Run. Approach 3: Modified version of the 2nd Approach with Took Definitions call: # ------------------------- TOOL ROUTING LOGIC ------------------------- def choose_tool(user_input: str): text = user_input.lower() if any(k in text for k in ["log", "trigger","pipeline","connection"]): # return "Fabric_Agent" return ( "Fabric_Agent", fabric_tool.definitions[0] ) if any(k in text for k in ["openapi", "api call", "pipeline start"]): # return "Fabric_Pipeline_Trigger" return ( "Fabric_Pipeline_Trigger", openapi_tool.definitions[0] ) # No forced routing → let orchestrator decide # return None return (None, None) # forced_tool = choose_tool(user_query) forced_tool_name, forced_tool_def = choose_tool(user_query) # ------------------------- ORCHESTRATOR CALL ------------------------- if forced_tool_name: tool_choice = { "type": "function", "function": { "name": forced_tool_name } } run = agents_client.runs.create_and_process( thread_id=st.session_state.thread.id, agent_id=ORCH_AGENT_ID, tool_choice=tool_choice, tools=[ forced_tool_def ] # << only the specific tool ) else: # no forced tool, orchestrator decides run = agents_client.runs.create_and_process( thread_id=st.session_state.thread.id, agent_id=ORCH_AGENT_ID ) Error: TypeError: azure.ai.agents.operations._patch.RunsOperations.create() got multiple values for keyword argument 'tools'The Future of AI: The Model is Key, but the App is the Doorway
This post explores the real-world impact of GPT-5 beyond benchmark scores, focusing on how application design shapes user experience. It highlights early developer feedback, common integration challenges, and practical strategies for adapting apps to leverage the advanced capabilities of GPT-5 in Foundry Models. From prompt refinement to fine-tuning to new API controls, learn how to make the most of this powerful model.Announcing new Phi pricing, Empowering Your Business with Small Language Models
Last month, Microsoft announced two new models to the Phi family. With that announcement comes new pricing for designed to provide our customers with even more value and flexibility. Why small language models matter Small language models are revolutionizing the way businesses operate by offering powerful capabilities without the need for extensive computational resources. These models are not only cost-effective but also highly efficient, making them ideal for a wide range of applications, from customer service to data analysis. Phi pricing Language and vison models Models Context length Input (per 1,000 tokens) Output (per 1,000 tokens) Phi-3-mini 4K $0.00013 $0.00052 Phi-3-mini 128K $0.00013 $0.00052 Phi-3.5-mini 128K $0.00013 $0.00052 Phi-3-small 8K $0.00015 $0.0006 Phi-3-small 128K $0.00015 $0.0006 Phi-3-medium 4K $0.00017 $0.00068 Phi-3-medium 128K $0.00017 $0.00068 Phi-3.5-MoE 128K $0.00016 $0.00064 Phi-4 128K $0.000125 $0.0005 Phi-4-mini 128K $0.000075 $0.0003 Phi-4-multimodal, text and image 128K $0.00008 $0.00032 Phi-4-multimodal, audio 128K $0.004 $0.00032 Finetuning Models Context length Training per 1,000 tokens Hosting per hour Input Usage per 1,000 tokens Output Usage per 1,000 tokens Phi-3-mini 4K $0.003 $0.80 $0.00013 $0.00052 Phi-3-mini 128K $0.003 $0.80 $0.00013 $0.00052 Phi-3.5-mini 128K $0.003 $0.80 $0.00013 $0.00052 Phi-3-medium 4K $0.003 $0.80 $0.00017 $0.00068 Phi-3-medium 128K $0.003 $0.80 $0.00017 $0.00068 Phi-3.5-MoE 128K $0.003 $0.80 $0.00016 $0.00064 Phi-4 128K $0.003 $0.80 $0.000125 $0.0005 Phi-4-mini 128K $0.003 $0.80 $0.000075 $0.0003 Key benefits of new Phi pricing Affordability: Our new pricing structure ensures that businesses of all sizes can access the benefits of small language models without breaking the bank. Scalability: Whether you're a small startup or a large enterprise, our pricing is designed to scale with your needs, providing you with the flexibility to grow. Efficiency: Small language models are optimized for performance, allowing you to achieve faster results and improve overall productivity. Learn more We believe that small language models are part of the future of business intelligence. We invite you to explore the possibilities and see how our solutions can transform your business.Deployment Guide-Copilot Studio agent with MCP Server exposed by API Management using OAuth 2.0
Introduction In today’s enterprise landscape, enabling AI agents to interact with backend systems securely and at scale is critical. By exposing MCP servers through Azure API Management (APIM), organizations can provide controlled access to these services. When combined with OAuth 2.0 authorization code flow, this setup ensures robust, enterprise-grade security for AI agents built in Copilot Studio—empowering intelligent automation while maintaining strict access governance. Disclaimer & Caveats This article explores how to configure a MCP tool—exposed as a MCP server via APIM—for secure consumption by AI agents built in Copilot Studio. Leveraging the OAuth 2.0 Authorization Code Flow, this setup ensures enterprise-grade security by enabling delegated access without exposing user credentials. With Azure API Management now supporting MCP server capabilities in public preview, developers can expose REST APIs as MCP tools using a standardized JSON-RPC interface. This allows AI agents to invoke backend services securely and scalable, without the need to rebuild existing APIs. Copilot Studio, also in preview for MCP integration, empowers organizations to orchestrate intelligent agents that interact with these tools in real time. While this guide provides a foundational approach, every environment is unique. You can enhance security further by implementing app roles, conditional access policies, and extending your integration logic with custom Python code for advanced scenarios. ⚠️ Note: Both MCP server support in APIM and MCP tool integration in Copilot Studio are currently in public preview. As these platforms evolve rapidly, expect changes and improvements over time. Always refer to the https://learn.microsoft.com/en-us/azure/api-management/export-rest-mcp-server for the latest updates. This article is about consuming remote MCP servers. In Azure, managed identity can also be leveraged for APIM integration. What is Authorization Code Flow? The Authorization Code Flow is designed for applications that can securely store a client secret (like server-side apps). It allows the app to obtain an access token on behalf of the user without exposing their credentials. This flow uses an intermediate authorization code to exchange for tokens, adding an extra layer of security. Steps in the Flow User Authentication The user is redirected to the Authorization Server (In this case: Azure AD) to log in and grant consent. Authorization Code Issued After successful login, the Authorization Server sends an authorization code to the app via the redirect URI. Token Exchange The app sends the authorization code (plus client credentials) to the Token Endpoint to get: Access Token (for API calls) and Refresh Token (to renew access without user interaction) API Access The app uses the Access Token to call protected resources. Below diagram shows the Authorization code flow in detail. Press enter or click to view image in full size Microsoft identity platform and OAuth 2.0 authorization code flow — Microsoft identity platform | Microsoft Learn High Level Architecture Press enter or click to view image in full size This architecture can also be implemented with APIM backend app registration only. However, stay cautious in configuring redirect URIs appropriately. Remote MCP Servers using APIM Architecture APIM exposing Remote MCP servers, enabling AI agents—such as those built in Copilot Studio—to securely access backend services using standardized JSON-RPC interfaces. This integration offers a robust, scalable, and secure way to connect AI tools with enterprise APIs. Key Capabilities: Secure Gateway: APIM acts as an intelligent gateway, handling OAuth 2.0 Authorization Code Flow, authentication, and request routing. Monitoring & Observability: Integration with Azure Log Analytics and Application Insights enables deep visibility into API usage, performance, and errors. Policy Enforcement: APIM’s policy engine allows for custom rules, including token validation, header manipulation, and response transformation. Rate Limiting & Throttling: Built-in support for rate limits, quotas, and IP filtering helps protect backend services from abuse and ensures fair usage. Managed Identity & Entra ID: Secure service-to-service communication is enabled via system-assigned and user-assigned managed identities, with Entra ID handling identity and access management. Flexible Deployment: MCP servers can be hosted in Azure Functions, App Services, or Container Apps, and exposed via APIM with minimal changes to existing APIs. To learn more, visit https://learn.microsoft.com/en-us/samples/azure-samples/remote-mcp-apim-functions-python/remote-mcp-apim-functions-python/ Develop MCP server in VS Code This deployment guide provides sample MCP code written in python for ease of use. It is available on the following GitHub repo. However, you can also use your own MCP server. Clone the following repository and open in VS Code. git clone https://github.com/mafzal786/mcp-server.git Run the following to execute it locally. cd mcp-server uv venv uv sync uv run mcpserver.py Deploy MCP Server as Azure Container App In this deployment guide, MCP server is deployed in Azure Container App. It can also be deployed as Azure App service. Deploy the MCP server in Azure container App by running the following command. It can be deployed by many other various ways such as via VS Code or CI/CD pipeline. AZ Cli is used for simplicity. az containerapp up \ --resource-group <RESOURCE_GROUP_NAME> \ --name streamable-mcp-server2 \ --environment mcp \ --location <REGION> \ --source . Configure Authentication for Azure Container App 1. Sign in Azure portal. Visit the container App in Azure and Click “Authentication” as shown below. Press enter or click to view image in full size For more details, visit the following link: Enable authentication and authorization in Azure Container Apps with Microsoft Entra ID | Microsoft Learn Click Add Identity Provider as shown. 2. Select Microsoft from the drop down and leave everything as is as shown below. 3. This will create a new app registration for the container App. After it is all setup, it will look like as below. As soon as authentication is configured. it will make container app inaccessible except for OAuth. Note: If you have app registration for Azure Container App already configured, use that by selecting "pick an existing app registration in this directory" option. Review App Registration of Container App — Backend Visit App registration and click streamable-mcp-server2 as in this case. Click on Authentication tab. Verify the Redirect URIs. you should see a redirect URL for container app. URI will end with /.auth/login/aad/callback as shown in the green box in the below screenshot. Now click on “Expose an API”. Confirm Application ID URI is configured with scope as shown below. its format is api://<client id> Scope "user_impersonation" is created. Verify API Permission. Make sure you Grant admin consent for your tenant as shown below. More scope can be created depending on the requirement of data access. Note: Make sure to "Grant admin consent" before proceeding to next step. Create App registration for representing APIM API Lauch Azure Portal. Visit App registration. Click New registration. Create a new App registration as shown below. For example, "apim-mcp-backend-api" in this case. Click "Expose an API", configure Application ID URI, and add a scope as shown in the below diagram such as user_impersonation. Click "App roles" and create the following role as shown below. More roles can be created depending on the requirements and case by case basis. Here app roles are created to get the concept around it and how it will be used in APIM inbound policies in the coming sections. Create App Registration for Client App — Copilot Studio In these steps, we will be configuring app registration for the client app, such as copilot studio in this case acting as a client app. This is also mentioned in the “high level architecture” diagram in the earlier section of this article. Lauch Azure Portal. Visit App registration. Click New registration. Create a new App registration. leave the Redirect URL as of now, we will configure it later as it is provided by copilot studio when configuring custom MCP connector. 3. Click on API permission and click “Add a permission”. Click Microsoft Graph and then click “Delegated permissions”. Select email, openid, profile as shown below. 4. Make sure to Grant admin consent and it should look like as below. 5. Create a secret. click “Certificates & secrets”. Create a new client secret by clicking “New client secret”. store the value as it will be masked after some time. if that happens, you can always delete and re-create a new secret. 6. Capture the following as you would need it in configuring MCP tool in Copilot Studio. Client ID from the Overview Tab of app registration. Client secret from “Certificates & secrets” tab. 7. Configure API permissions for APIM API i.e. "apim-mcp-backend-api" in this case. Click “API permissions” tab. Click “Add a permission”. Click on “My APIs” tab as shown below and select "apim-mcp-backend-api". Note: If you don't see the app registration in "My APIs". Go to App registration. Click "Owners". Add your AD account as Owners. 8. Select "Delegated permissions". Then select the permission as shown below. 9. Select the Application permission. Select the App roles created in the apim-mcp-backend-api registration. Such as mcp.read in this case. You MUST “Grant admin consent” as final step. It is very important!!! I can’t emphasize more on that. without it, nothing will work!!! 10. End result of this client app registration should look like as mentioned in the below figure. Configure permissions for Container App registration Lauch Azure Portal. Visit app registration. Select app registration of Azure container app such as streamable-mcp-server2 in this case. Select API permissions. Add the following delegated and application permissions as shown in the below diagram. Note: Don't forget to Grant admin consent. Configure allowed token audience for Container App It defines which audience values (aud claim) in a token are considered valid for your app. When a client app requests an access token from Microsoft Entra ID (Azure AD), the token includes an aud claim that identifies the intended recipient. Your container app will only accept tokens where the aud claim matches one of the values in the Allowed Token Audiences list. This is important as it ensures that only tokens issued for your API or app are accepted and prevents misuse of tokens intended for other resources. This adds extra layer of security. In the Azure Portal, visit Azure Container App. i.e. streamable-mcp-server2. Click on "Authentication" Click "Edit" under identity provider Under "Allowed token audiences", add the application ID URI of "apim-mcp-backend-api". As this will be included as an audience in the access token. Best Practices Only include trusted client app IDs. Avoid using overly broad values like “allow all” (not recommended). Validate tokens using Microsoft libraries (MSAL) or built-in auth features. Configure MCP server in API Management Note: Provisioning an API Management resource is outside the scope of this document. If you do not already have an API Management instance, follow this QuickStart: https://learn.microsoft.com/en-us/azure/api-management/get-started-create-service-instance The following service tiers are available for preview: Classic Basic, Standard, Premium, and Basic v2, Standard v2, Premium v2. For the Classic Basic, Standard, or Premium tiers, you must join the AI Gateway Early Update group to enable MCP server features. Please allow up to 2 hours for the update to take effect. Expose an existing MCP server Follow these steps to expose an existing MCP server is API Management: In the Azure portal, navigate to your API Management instance. In the left-hand menu, under APIs, select MCP servers > + Create MCP server. Select Expose an existing MCP server. In Backend MCP server: Enter the existing MCP server base URL. Example: https://streamable-mcp-serverv2.kdhg489457dslkjgn,.eastus2.azurecontainerapps.io/mcpfor the Microsoft Azure Container App hosting MCP server. In Transport type, Streamable HTTP is selected by default. In New MCP server: Enter a Name the MCP server in API Management. In Base path, enter a route prefix for tools. Example: mcptools Optionally, enter a Description for the MCP server. Select Create. Below diagram shows the MCP servers configured in APIM for reference. Configure policies for MCP server Configure one or more API Management policies to help manage the MCP server. The policies are applied to all API operations exposed as tools in the MCP server and can be used to control access, authentication, and other aspects of the tools. To configure policies for the MCP server: In the Azure portal, navigate to your API Management instance. In the left-hand menu, under APIs, select MCP Servers. Select an MCP server from the list. In the left menu, under MCP, select Policies. In the policy editor, add or edit the policies you want to apply to the MCP server's tools. The policies are defined in XML format. <!-- - Policies are applied in the order they appear. - Position <base/> inside a section to inherit policies from the outer scope. - Comments within policies are not preserved. --> <!-- Add policies as children to the <inbound>, <outbound>, <backend>, and <on-error> elements --> <policies> <!-- Throttle, authorize, validate, cache, or transform the requests --> <inbound> <base /> <set-variable name="accessToken" value="@(context.Request.Headers.GetValueOrDefault("Authorization", "").Replace("Bearer ", ""))" /> <!-- Log the captured access token to the trace logs --> <trace source="Access Token Debug" severity="information"> <message>@("Access Token: " + (string)context.Variables["accessToken"])</message> </trace> <set-variable name="userId" value="@(context.Request.Headers.GetValueOrDefault("Authorization", "Bearer ").Split(' ')[1].AsJwt().Claims["oid"].FirstOrDefault())" /> <set-variable name="userName" value="@(context.Request.Headers.GetValueOrDefault("Authorization", "Bearer ").Split(' ')[1].AsJwt().Claims["name"].FirstOrDefault())" /> <trace source="User Name Debug" severity="information"> <message>@("username: " + (string)context.Variables["userName"])</message> </trace> <set-variable name="scp" value="@(context.Request.Headers.GetValueOrDefault("Authorization", "Bearer ").Split(' ')[1].AsJwt().Claims["scp"].FirstOrDefault())" /> <trace source="Scope Debug" severity="information"> <message>@("scope: " + (string)context.Variables["scp"])</message> </trace> <set-variable name="roles" value="@(context.Request.Headers.GetValueOrDefault("Authorization", "Bearer ").Split(' ')[1].AsJwt().Claims["roles"].FirstOrDefault())" /> <trace source="Role Debug" severity="information"> <message>@("Roles: " + (string)context.Variables["roles"])</message> </trace> <!-- <set-variable name="requestBody" value="@{ return context.Request.Body.As<string>(preserveContent:true); }" /> <trace source="Request Body information" severity="information"> <message>@("Request body: " + (string)context.Variables["requestBody"])</message> </trace> --> <validate-azure-ad-token tenant-id="{{tenant-id}}" header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid."> <client-application-ids> <application-id>{{client-application-id}}</application-id> </client-application-ids> <audiences> <audience>{{audience}}</audience> </audiences> <required-claims> <claim name="roles" match="any"> <value>mcp.read</value> </claim> </required-claims> </validate-azure-ad-token> </inbound> <!-- Control if and how the requests are forwarded to services --> <backend> <base /> </backend> <!-- Customize the responses --> <outbound> <base /> </outbound> <!-- Handle exceptions and customize error responses --> <on-error> <base /> <trace source="Role Debug" severity="error"> <message>@("username: " + (string)context.Variables["userName"] + " has error in accessing the MCP server, could be auth or role related...")</message> </trace> <return-response> <set-status code="403" reason="Forbidden" /> <set-body> {"error":"Missing required scope or role"} </set-body> </return-response> </on-error> </policies> Note: Update the above inbound policy with the tenant Id, client application id, and audience as per your environment. It is recommended to use APIM "Named values" instead of hard coding inside the policy. To learn more, visit Use named values in Azure API Management policies Configure Diagnostics for APIM In this solution, APIM diagnostics are configured to forward log data to Log Analytics. Testing and validation will be carried out using insights from Log Analytics. Note: Setting up diagnostics is outside the scope of this article. However, you can visit the following link for more information. https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-use-azure-monitor Below diagram shows what Logs are being sent to Log Analytics workspace. MCP Tool configuration in Copilot Studio Lauch copilot studio at https://copilotstudio.microsoft.com/. Configuration of environment and agent is beyond the scope of this article. It is assumed, you already have environment setup and agent has been created. Following link will help you, how to create an agent in copilot studio. Quickstart: Create and deploy an agent — Microsoft Copilot Studio | Microsoft Learn Inside agent configuration, click "Add tool". 3. Click on New tool. 4. Select Model Context Protocol. 5. Provide all relevant information for MCP server. Make sure your server URL ends with your mcp setup. In this case, it is APIM MCP server URL, with base path configured in APIM in the end. Provide server name and server description. Select OAuth 2.0 radio button. 6. Provide the following in the OAuth 2.0 section Client ID of client app registration. In this case, copilot-studio-client as configured earlier. Client secret of copilot-studio-client app registration. Authorization URL: https://login.microsoftonline.com/common/oauth2/v2.0/authorize Token URL template & Refresh URL: https://login.microsoftonline.com/oauth2/v2.0/token Scopes: openid, profile, email — which we selected earlier for Microsoft Azure Graph permissions. Click “Create”. This will provide you Redirect URL. you need to configure the redirect URL in client app registration. In this case, it is copilot-agent-client. Configure Redirect URI in Client App Registration Visit client app registration. i.e. copilot-studio-client. Click Authentication Tab and provide the Web Redirect URIs as shown below. Note: Configure Redirect URIs MUST be configured in app registration. Otherwise, authorization will not complete and sign on will fail. Configure redirect URI in APIM API app registration Also configure apim-mcp-backend-api app registration with the same redirect URI as shown below. Modify MCP connector in PowerApps Now visit the https://make.powerapps.com and open the newly created connector as shown below. Select the security tab and modify the Resource URL with application ID URI of apim-mcp-backend-api configured earlier in app registration for expose an API. Add .default in the scope. Provide the secret of client app registration as it will not let you update the connector. This is extra security measure for updating the connector in Powerapps. Click Update connector. CORS Configuration CORS configuration is a MUST!!! Since our Azure Container App is a remote MCP server with totally different domain or origin. Power Apps and CORS for External Domains — Brief Overview When embedding or integrating Power Apps with external web applications or APIs, Cross-Origin Resource Sharing (CORS) becomes a critical consideration. CORS is a browser security feature that restricts web pages from making requests to a different domain than the one that served the page, unless explicitly allowed. Key Points: Power Apps hosted on *.powerapps.com or within Microsoft 365 domains will block calls to external APIs unless those APIs include the proper CORS headers. The external API must return: Access-Control-Allow-Origin: https://apps.powerapps.com (or * for all origins, though not recommended for production) Access-Control-Allow-Methods: GET, POST, OPTIONS (or as needed) Access-Control-Allow-Headers: Content-Type, Authorization (and any custom headers) If the API requires authentication (e.g., OAuth 2.0), ensure preflight OPTIONS requests are handled correctly. For scenarios where you cannot modify the external API, consider using: Power Automate flows as a proxy Azure API Management or Azure Functions to inject CORS headers Always validate security implications before enabling wide-open CORS. If the CORS are not setup. You will encounter following error in copilot studio after pressing F12 (Browser Developer) CORS policy — blocking the container app Azure container app provides very efficient way of configuring CORS in the Azure portal. Lauch Azure Portal. Visit Azure container app i.e. streamable-mcp-server2 in this case. Click on CORS under Networking section. Configure the following in Allowed Origin Section as shown below. localhost is added to make it work from local laptop, although it is not required for Copilot Studio. 4. Click on “Allowed Method” tab and provide the following. 5. Provide wild card “*” in “Allowed Headers”tab. Although, it is not recommended for production system. it is done for the sake for simplicity. Configure that for added security 6. Click “Apply”. This will configure CORS for remote application. Test the MCP custom connector We are in the final stages of configuring the connector. It is time to test it, if everything is configured correctly and works. Launch the http://make.powerapps.com and click on “Custom connectors”, select your configured connector and click “5. Test” tab as shown below. You will see Selected Connection as blank if you are running it first time. Click “+ New connection” 2. New connection will launch the Authorization flow and browser dialog will pop up for making a request for authorization code. 3. Click “Create”. 4. Complete the login process. This will create a successful connection. 5. Click “Test operation”. If the response is 406 means everything is configured correctly as shown below. Solution validation Add user in Enterprise Application for App roles Roles have been defined under the required claims in the APIM inbound policy and also configured in the apim-mcp-backend-api app registration. As a result, any request from Copilot Studio will be denied if this role is not properly assigned. This role is included in the JWT access token, which we will validate in the following sections. To assign role, perform the following steps. Visit Azure Portal. Visit Enterprise Application. Select APIM backend app registration. In this case for example, apim-mcp-backend-api Click "Users and groups" Select "Add user/group" 5. Select User or Group who should have access to the role. 6. Click "Assign". It will look like as below. Note: Role assignment for users or groups is an important step. If it is not configured, MCP server tests will fail in Copilot studio. Test MCP server in Copilot Studio Lauch copilot studio and click on the Agent you created in earlier steps and click on “Tools tab”. Select your MCP tool as shown the following figure. Make sure it is “Enabled” if you have other tools attached to the same agent, disable them for now for testing. Make sure you have connection available which we created during the testing of custom connector in earlier step. You can also initiate a fresh connection by clicking on the drop down under “Connection” as shown below. Refreshing the tools will show all the tools available in this MCP server. Provide the sample prompt such as “Give me the stock price of tesla”. This will trigger the MCP server and call the respective method to bring the stock price of Tesla. Now try a weather-related question to see more. Now invoking weather forecast tool in the MCP server. APIM Monitoring with Log Analytics We previously configured APIM diagnostic settings to forward log data to Log Analytics. In this section, we’ll review that data, as the inbound policy in APIM sends valuable information to Log Analytics. Run the Kusto query to retrieve data from the last 30 minutes. As shown, the logs capture the APIM API endpoint URL and the backend URL, which corresponds to the Azure Container App endpoint. Scrolling further, we find the TraceRecords section. This contains the information captured by APIM inbound policies and sent to Log Analytics. The figure below illustrates the TraceRecords data. In the inbound policy, we configured it to extract details from the access token—such as the token itself, username, scope, and roles—and forward them to Log Analytics. Now let's capture the access token in the clip board, launch the http://jwt.io which is JSON Web Token (JWT) debugger, and paste the access token in the ENCODED VALUE box as show below. Note the following information. aud: This shows the Application URI ID of apim-mcp-backend-api. which shows access token is requested for that audience. appid: This shows the client Id for copilot-studio-client app registration. You can also see roles and scope. These roles are specified in APIM inbound policy. Note: As you can see, roles are included in access token and if it is not assigned in the enterprise application for "apim-mcp-backend-api", all requests will be denied by APIM inbound policy configured earlier. Perform a test using another Azure AD account that does not have the app role assigned Now, let's try the copilot studio agent by logging in with another account which is not assigned for the "mcp.read" role. Let's, review the below diagram. Logged in as demo and tried to access the MCP tool in copilot studio agent. Request failed with the error "Missing required scope or roles". If you look at it, this is coming from the APIM policy configured earlier in <on-error> Let's review log analytics. As you can see request failed due to inbound APIM policy with 403 error and there is no backend URL. Error is also reported under TraceRecords as we configured it in APIM policy. Now copy the Access token from log analytics and paste it into jwt.io. You can notice in the below diagram, there is no "roles" in the access token, resulting access denied from APIM inbound policy definition to the APIM backend i.e. azure container app. Assign the app role to the demo account Let's assign the "mcp.read" role to the demo account and test if it accesses the tool. Visit Azure Portal, Lauch Enterprise application, and select "apim-mcp-backend-api" as in this example. Click "Users and groups" Click "+ Add user/group" Select demo Click "Select" Click "Assign" End result would look like as shown below. Now, login again as demo. Make sure a new access token is generated. Access token refresh happens after one hours. As you can see in the image below, this time the request is successful after assigning the "mcp.read" app roles. Now let's review the log analytics entries. Let's review the access token in JWT.io. As you can see, roles are included in the access token. Conclusion Exposing the MCP server through Azure API Management (APIM) and integrating it with Copilot Studio agents provides a secure and scalable way to extend enterprise capabilities. By implementing OAuth 2.0, you ensure robust authentication and authorization, protecting sensitive data and maintaining compliance with industry standards. Beyond security, APIM adds significant operational value. With APIM policies, you can monitor traffic, enforce rate limits, and apply fine-grained controls to manage access and performance effectively. This combination of security and governance empowers organizations to innovate confidently while maintaining control and visibility over API usage. In today’s enterprise landscape, leveraging APIM with OAuth 2.0 for MCP integration is not just best practice—it’s a strategic move toward building resilient, secure, and well-governed solutions.Your city agent speaks 100 languages. But does It understand you?
For many residents, interacting with city services feels like a frustrating experience. Forms are confusing. Wait times are long. And often, it feels like no one is truly listening. Now imagine a city services agent that speaks your language and understands your needs. Some cities already have one. But the real question is not whether they can do it. It is whether they should. SmartCitiesWorld has published a new trend report titled “AI for Personalised Government Services – Reimagining Citizen Experiences.” The report includes case studies from Derby, Amarillo, Jakarta, and Tampere. It offers frameworks for data governance, staff training, and building public trust with AI. Download the full report today to explore how leading cities are transforming service delivery with responsible AI. And join us at Smart City Expo World Congress in Barcelona from November 4 to 6 to see these innovations in action. Visit Microsoft at Hall 3, Stand D51 to experience how AI is helping cities listen better, serve smarter, and build trust with every interaction. Cities Are Using AI to Improve Public Services Around the world, cities are using artificial intelligence to make public services faster, simpler, and more accessible. These are not experimental pilots. These are live systems serving residents every day. In Derby, United Kingdom, AI assistants handle more than half a million calls each year. This allows city staff to focus on complex cases that require human judgment and empathy. Routine questions are answered instantly. Human expertise is reserved for situations that need it most. In Amarillo, Texas, the city built an AI assistant named Emma. Emma speaks one hundred languages. In just one year, Emma helped the city save 1.8 million dollars in operational costs. More importantly, Emma helped residents who previously struggled to access services due to language barriers. In Jakarta, the JAKI platform connects services across departments. It reminds residents when permits need renewal. It sends alerts about tax payments. It links systems that used to operate in isolation. These cities are not chasing technology for its own sake. They are using it to serve more people, more effectively. The Technical Challenge: Old Systems Meet New Tools Most city systems were built decades ago. They do not communicate with each other. One department may not know what another already knows about the same resident. Artificial intelligence can bridge these gaps. But only if cities implement it carefully. Tampere, Finland shows how to do it right. The city redesigns services with residents, not just for them. It uses digital twin technology to test changes before rollout. It gathers feedback from actual users, including children and older adults. This approach takes more time. But it delivers better results. Services work for the people who actually use them. Why Thoughtful Planning Makes AI More Effective As cities explore the potential of AI to improve public services, it is important to recognize that successful implementation depends on careful preparation. While the technology offers powerful capabilities, its impact depends on how well it is integrated into existing systems and aligned with community needs. There are a few common challenges that cities may encounter during deployment: Data quality: AI systems rely on accurate and representative data. If the data is incomplete or biased, the system may produce inconsistent or unfair outcomes. Addressing data gaps early helps ensure more reliable performance. System integration: Many city platforms were built decades ago and operate in silos. Introducing AI without addressing these legacy issues can limit its effectiveness. A thoughtful integration strategy helps AI enhance, not just accelerate, existing processes. Public trust: Residents need to feel confident that AI systems are fair, transparent, and accountable. When mistakes happen, clear communication and responsive support are essential to maintaining trust. These challenges are not roadblocks, they are opportunities to build stronger, more inclusive systems. Cities that take time to plan, test, and engage with residents early are better positioned to deliver meaningful results. Building Trust Through Transparency AI is only as effective as the trust behind it. If an algorithm denies benefits incorrectly, who takes responsibility? If a translation system misunderstands a request, how does the city fix it? Camden, United Kingdom created a Data Charter in plain language. Residents helped write it. The charter explains how the city collects data, who can access it, and how it checks for bias in algorithms. This is not just good governance. It is necessary design. Residents will not use systems they do not trust. The charter includes regular audits. Independent reviewers check AI decisions for patterns of discrimination. If the system treats one neighborhood differently than another, the city investigates immediately. Other cities need similar frameworks. Trust requires transparency. Transparency requires clear communication. Making AI Work for All Residents AI allows cities to personalize services at scale. But personalization must include everyone. Language accessibility is essential. Residents should interact with city services in their preferred language. Emma in Amarillo proves this works. Translation should be automatic, not an extra step. Interface design matters too. Simple layouts help residents with limited digital skills. Clear labels support residents with cognitive disabilities. Audio options assist those with vision impairments. Human support remains critical. AI cannot handle every situation. Complex cases need human judgment. Emotional situations need human empathy. Cities must provide easy ways to reach actual staff. South Cambridgeshire routes 27 percent of inquiries through AI. This frees human staff to focus on the remaining 73 percent that need personal attention. The result is faster resolution for routine questions and better support for difficult cases. What Success Looks Like Cities that succeed with AI share common traits. They focus on outcomes, not features. They measure impact on residents, not just cost savings. Successful cities start small. They test one service before expanding. They collect feedback continuously. They adjust based on what residents actually need. They train staff properly. AI changes how employees work. Staff need time to adapt. They need clear guidance on when to use AI and when to intervene personally. They also maintain alternatives. Not every resident wants to use AI. Phone lines remain open. In-person services continue. Digital tools supplement existing services rather than replace them. The Path Forward for Your City AI will not fix broken systems automatically. It requires careful planning, thoughtful implementation, and ongoing evaluation. Start by identifying one service that frustrates residents. Map the current process. Find the delays and confusion points. Determine if AI can solve those specific problems. Involve residents early. Ask what they need. Test prototypes with actual users. Listen to criticism. Revise based on feedback. Build transparency into the system from the beginning. Explain how AI makes decisions. Create clear paths for appealing those decisions. Assign human accountability for AI outcomes. Train your staff before launch. Help them understand how AI changes their role. Give them tools to override AI when necessary. Recognize that technology serves people, not the other way around. When city services start to feel personal, residents spend less time navigating bureaucracy. Staff spend more time solving real problems. And trust in public institutions grows stronger. Learn From Cities That Succeeded SmartCitiesWorld has published a new trend report titled “AI for Personalised Government Services – Reimagining Citizen Experiences.” The report includes case studies from Derby, Amarillo, Jakarta, and Tampere. It offers frameworks for data governance, staff training, and building public trust with AI. Download the full report today to explore how leading cities are transforming service delivery with responsible AI.The Future of AI: Building Weird, Warm, and Wildly Effective AI Agents
Discover how humor and heart can transform AI experiences. From the playful Emotional Support Goose to the productivity-driven Penultimate Penguin, this post explores why designing with personality matters—and how Azure AI Foundry empowers creators to build tools that are not just efficient, but engaging.Ignite, 2021: Scale-up with the latest enhancements of Azure Video Analyzer for Media files (AVAM)
Azure Video Analyzer for Media (AVAM), formerly known as Video Indexer, celebrates 3 years as a general-available cloud solution for analyzing media files. AVAM is an Azure Applied AI solution with 33 machine-learning based vision and audio models extracting significant business insights from your media files. We are happy to announce that this 3-year product is now ready to scale-up thanks to a set of innovative enhancements. We believe that now, any digital media asset library in the world can get the most valuable insights in less than 3 days efforts. As an example, we now enable an ARM-based account management (and it takes only 3 minutes to create a new account).Quick look at journey of Agentic Solutions, from No‑code to Developer tools
Why this journey matters My journey with Bot, virtual agents and personal assistants has been quite long and, in this time, not only has the usage and user scenario evolved but the technology and platforms that fueled it significantly changed as well. Agentic solutions are no longer just “chat with documents, knowledgebases or hand curate the decision making into the AI services” - The bar has moved to systems that understand context, invoke tools, and complete workflows—with the governance and telemetry your business requires, and the new tools that are at our disposal. In this article, I’m going through the notes that I have made and formulated approaches that I go through as I work on new AI solutions and AI projects. I have also added a checklist and a 90-day plan, if you are lucky enough to launch an AI Agentic project and want to start in a structured way from small wins to big bang. While navigating various scenarios and projects, I have developed and refined this practical approach/progression. This methodology gradually evolved as I encountered different timeline constraints and use cases. No‑code for rapid wins inside Microsoft 365 Low‑code for richer conversation design and workflow orchestration Pro‑code for robust model choice, evaluation, safety, and operations on Azure Use it as a blueprint to decide where to start, when to step up, and how to land production quality without over‑engineering day one. With this approach, I have seen team formation evolve as well. While some use cases will hit fruition at Low-code stage itself, there will be few that will be adopted for Pro-code and involve larger Development team and more matured, DevOps processes. The spectrum at a glance Layer Primary Builder Best For Integration Depth Time‑to‑Value Microsoft 365 Copilot – Agent Builder (No‑code) Smart users, business leads Q&A, task helpers, quick pilots in Teams/Outlook Connect org content and simple actions Fastest Microsoft Copilot Studio (Low‑code) Citizen developers, power users Multi‑turn conversations, API actions, enterprise data Custom connectors, policies, orchestration Weeks Azure AI Foundry (Pro‑code) Developers, architects Model selection, evaluation, safety, observability Prompt flows, CI/CD, monitoring, scale Project lifecycle Start: No‑code with Microsoft 365 Copilot Agent Builder When you need impact now, or something that you want to automate quickly, including your daily routine or a quick business process - embedded intelligence where people work every day. What you can achieve Answer policy and product questions grounded in your internal content Automate simple tasks (drafts, reminders, status messages) Share quickly in Teams to capture user feedback Collaborate and share with your teammates. How to approach Define one job to be done (e.g., “answer 80% of field FAQs”). Attach one high‑quality content source (structured SharePoint library beats scattered files). Add one action that saves clicks (create a task, send a summary). Pilot with a small group; measure deflection, satisfaction, and turnaround time. Guardrails from day one Keep scope narrow, content curated, and responses concise. Document the agent’s mandate and what it won’t do (set expectations). Level up: Low‑code with Copilot Studio Transition to this approach when your project requires designed conversations, conditional logic, and system actions—all without needing to move into full pro-code development. This method is especially effective for quickly deploying agents across a department, particularly for straightforward use cases, simple automations, and workflows that require more extensive reach. It enables broader automation and process improvement while maintaining a low-code approach that remains accessible to a wider range of users. What you can achieve Model topics/intents and multi‑turn dialogues. Call internal and external APIs via custom connectors Apply business rules before actions are carried out. Design tips Structure the conversation: greet → clarify → retrieve/act → confirm → summarize. Separate knowledge from behavior: keep content where it’s governed; keep logic in Studio. Instrument outcomes: track successful task completion, not just messages exchanged. Deep analytics into usage etc. Integration patterns Internal systems (HR, finance, CRM) through connectors. Event-driven flows (create tickets, update records, trigger notifications). Approval handoffs when confidence is low. Production grade: Pro‑code with Azure AI Foundry When correctness, safety, scale, and cost matter, graduate to developer tooling on Azure. Why this layer Model choice: right‑fit models (capability, latency, cost) for each task. Prompt orchestration: multi‑step reasoning and tool calling. Evaluation: offline tests before release and live monitoring after. Safety: input/output filtering and policy enforcement. Operations: CI/CD, observability, and performance management. Standard development process and tooling: I emphasize largely AI Models and Azure AI Foundry here, however the standard development practices, code security, Identity and access, compliance, testing etc. will remain same. Engineering flow that works Frame the objective: Define success metrics (quality, safety, and business KPIs). Prototype prompt flows: Start small, version them, and add tool calls only where needed. Evaluate before you ship: Use curated datasets for offline tests; include tricky edge cases. Harden safety: Enable content filters, set thresholds, and log decisions for auditability. Ship with telemetry: Track latency, cost per task, answer accuracy, and user feedback. Continuously improve: Roll updates behind flags, watch for drift, and retrain or return when needed. Reference architecture (conceptual) Experience → Teams/web/app Orchestration → Copilot Studio (dialog, routing, actions) AI Services → Azure AI Foundry (models, prompt flows, evaluation, safety, monitoring) Enterprise systems → Data platforms, line‑of‑business APIs, automation services Key principles Separation of concerns: UI ≠ Conversation logic ≠ Model/runtime ≠ Business systems. Least privilege: Only the permissions and scopes the agent truly needs. Observability first: Logs, traces, and quality events from day one. Human‑in‑the‑loop: Escalation paths for low‑confidence or sensitive requests. My 90‑day plan Days 1–30: Prove value Ship two no‑code agents for different teams. Measure deflection %, response helpfulness, and time saved. Days 31–60: Orchestrate actions Rebuild one agent in Copilot Studio with a clear dialog flow. Add a secure API action and an approval fallback. Days 61–90: Operationalize Port the highest‑impact scenario to Foundry. Implement offline evaluation, enable safety filters, deploy to a controlled audience, and set up monitoring dashboards. Design checklists (save for later) No-code launch checklist ☐ One job to be done ☐ Single, high quality knowledge source ☐ One user visible action ☐ Pilot cohort & feedback channel Low-code orchestration checklist ☐ Dialog flow defined (happy path + clarifications) ☐ Input validation before actions ☐ Connector secrets managed securely ☐ Outcome metrics (task completion, reengagement) Pro-code readiness checklist ☐ Model fit (capability, latency, cost) documented ☐ Offline evaluation set with edge cases ☐ Safety filters configured and logged ☐ Monitoring, alerting, and rollback plan Common pitfalls and how to avoid them Starting big: Begin with one clearly defined outcome; expand only after you see measurable impact. Over‑indexing on chat: Instrument task completion, not just message counts. Hidden coupling: Don’t bury business logic inside prompts; keep rules visible and testable. Skipping eval: Always gate releases with a small, representative test set. No feedback loop: Capture user feedback in‑product and close the loop with updates. Final take Stay on the course and go progressive: 1) No‑code for momentum and adoption, 2) Low‑code for richer conversations and actions, and 3) Pro‑code for the rigor that production demands. Treat evaluation, safety, and observability as core features and focus on it from day 1, not afterthoughts. That’s how you build agentic solutions that are useful on day one and trustworthy on day one hundred. These links cover the full journey from no-code to pro-code, including responsible AI practices: Microsoft 365 Copilot Agent Builder Overview https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/agents-overview Microsoft Copilot Studio Documentation https://learn.microsoft.com/en-us/microsoft-copilot-studio/ Azure AI Foundry Documentation https://learn.microsoft.com/en-us/azure/ai-foundry/ Responsible AI and Content Safety in Azure https://learn.microsoft.com/en-us/azure/ai-services/content-safety/ Introduction to Microsoft AI Agent Solutions (Microsoft Learn module) https://learn.microsoft.com/en-us/training/modules/introduction-microsoft-ai-agent-solutions/ Software Development best practices & using AI in software development AI in Software Development | Microsoft Copilot Architecture strategies for formalizing software development management practices - Microsoft Azure Well-Architected Framework | Microsoft Learn About the Author Dipanjan Ghosh is a seasoned technology leader at Microsoft with extensive experience in AI solutions, enterprise architecture, and modern developer practices. He enables organizations to adopt Microsoft AI platforms such as Copilot, Copilot Studio, and Azure AI Foundry, ensuring scalability, security, and operational excellence. With a strong foundation in cloud architecture and automation, Dipanjan bridges innovation with practical implementation. Passionate about evangelizing technology innovations, he simplifies complex concepts and inspires businesses to embrace responsible, cutting-edge solutions. #SkilledByMTT, #MSLearn, #MTTBloggingGroup
