Recent Discussions
Microsoft Foundry External MCP Server Traffic Routing via Corporate Firewall
The customer would like to confirm whether traffic from an Azure AI Foundry agent to an external MCP server can be routed through a corporate firewall and whether this scenario is officially supported. To validate this scenario, I configured the following in my lab: Deployed an Azure AI Foundry resource using the Standard Agent Service with network injection. Created a dedicated subnet for the Foundry Agent Service and delegated it to Microsoft.App/environments. Associated a route table with the Foundry Agent subnet to route outbound traffic through Azure Firewall. Configured the required application and network rules on Azure Firewall. The Foundry agent is able to successfully retrieve data from the external MCP server. However, no corresponding traffic is visible in the Azure Firewall logs. Could you please confirm whether outbound traffic from the Foundry agent to an external MCP server can be routed through Azure Firewall or a corporate firewall? Also, is this routing scenario officially supported? Appreciate your support!
Azure AI Foundry Agent Unable to Use Credentials Stored in Key Vault Through Playwright MCP Tool
Hello everyone, I am trying to understand how Azure AI Foundry agents interact with Azure Key Vault when using custom MCP tools, and I would appreciate any guidance from the community. My Setup - Created an Azure AI Foundry agent. - Created an Azure Key Vault and configured all permissions according to Microsoft's official documentation. - Stored the required website credentials (username and password) in the Key Vault. - Deployed the official Playwright MCP Docker image. - Exposed the MCP server using ngrok and verified that the endpoint is accessible. - Connected the MCP endpoint as a Custom MCP Tool in Azure AI Foundry. - Performed all configuration through the Azure portal, Foundry UI, and Playground only (no SDK or custom application code involved). The Issue The agent can access and use the Playwright MCP tool. However, when I ask it to log in to a website using credentials that are already stored in Key Vault, it does not populate the username and password fields. My expectation was that the agent would be able to retrieve the secrets from Key Vault and provide them to the Playwright tool during execution. Questions Is there currently a supported mechanism for Azure AI Foundry agents to automatically retrieve Key Vault secrets and pass them to a Custom MCP tool? Does the Playwright MCP Docker image have any built-in integration with Azure Key Vault? When using only the Foundry UI (without SDK code), can a Foundry agent securely inject Key Vault secrets into MCP tool calls? Are additional configurations required beyond Key Vault permissions and agent connections? Has anyone successfully implemented a similar setup where a Foundry agent uses credentials stored in Key Vault to perform browser automation through Playwright MCP? Any clarification on the expected architecture and whether this scenario is currently supported in Azure AI Foundry would be greatly appreciated. Thank you.
One agent, three runtimes: porting a CSA agent to Microsoft Scout and Foundry Local
Most of my posts here are about Azure infrastructure lessons from customer engagements. This one is a little different — it's a real‑world engineering lesson from something I built to run my own practice. In my role as a Senior Cloud Solution Architect (CSA), I'm part of a grass-roots organic development team for an internal persona‑driven productivity agent called CSA‑Sherpa. It runs my daily rhythm: a morning briefing, a running logbook of wins and blockers, pipeline and timekeeping summaries, and reporting/exports. It started life in the GitHub Copilot CLI. But over the last few months two things changed the ground under it: Microsoft Scout arrived as a managed cloud agent with native tooling, scheduling, and memory; and Foundry Local made it realistic to run a capable model entirely on‑device on a Copilot+ PC's NPU — no cloud round‑trip at all. That raised a question I think a lot of people building agents will eventually ask: If I designed the framework well, can I change how the model runs without rewriting the agent? To find out, I stood the same agent up in three runtimes, then wrote a whitepaper and a comparison deck measuring what actually changed. This post explains: How one shared, deterministic core made three very different runtimes comparable What the three ports — Copilot CLI, Scout‑native, and Foundry Local (on‑device NPU) — actually took What the analysis showed, and a simple decision framework for which runtime to use when The part that stayed the same: a deterministic core The whole exercise only works because all three implementations load the same behavioral core: Agent definition — persona, behavioral rules, intent routing, workflow dispatch Instructions — conventions, session bootstrap, change‑management rules Skill library — one procedure file per workflow (morning briefing, logbook, pipeline, timekeeping, impact, ops, export…) A deterministic validation contract — schema, formatting, and privacy validators plus a post‑save enforcement chain That last point is the whole thesis: reliability belongs in code, not in the prompt. Rather than asking the model to "remember" to validate its output, a real gate (a validation step → a post‑save enforcement chain → index regeneration) enforces it every single run. This wasn't my idea in a vacuum — it follows the enterprise prompt‑engineering principles Kathiravan Thangavelu lays out in his article Prompt Engineering for Enterprise AI: Why Reliability Matters: keep deterministic logic in code, prefer schema‑driven / structured output over prompt‑enforced formatting, and replace "before you answer, verify that…" mental checklists with real machine validation. My validation gate is that principle in practice. And because that contract is identical across all three runtimes, I'm comparing three ways to execute one product — not three different products. The deterministic payoff: faster and cheaper Retrofitting those principles into the agent — moving work out of the model and into deterministic scripts — is the single change that paid off the most, on two axes at once: Faster. Letting code (not the model) gather and aggregate history cut the average model round‑trips per workflow from ~8.7 to ~5.5 — roughly a third fewer turns. Fewer turns means less waiting on generation and less back‑and‑forth to finish a task. Cheaper. The same change cut usage‑based cost ~24% — and, more importantly, held it flat as the logbook grew to hundreds of entries, because scripts carry the history the model used to re‑read every run. That's the quiet lesson: the reliability work I did for correctness turned out to be the same work that made the agent quicker and less expensive. Determinism isn't a tax on speed — here it bought all three. The work: three repositories, three runtimes Everything below the core — runtime, data access, governance, file layout — is where the effort went. 1 · Mainline — Copilot CLI + MCP. The upstream, most feature‑complete build. Runs as a primary agent in the GitHub Copilot CLI on Claude Opus 4.8; data services are discovered through MCP. It carries the heaviest governance: a Spec Kit layer (spec‑driven‑development agents, a constitution + templates, and 50+ per‑feature spec artifacts gated at PR time) plus an add‑on framework. The richest architecture — and the most complex to operate. 2 · Scout‑native. A thin wrapper loads the exact same core onto Microsoft Scout — again on Claude Opus 4.8 — but data access is re‑platformed onto Scout's native tooling instead of MCP subprocesses. No broker to configure; native tools negotiate their own auth. It adds two things the CLI can't do as cleanly: ✅ Scheduled automations — my morning briefing fires automatically on weekday mornings ✅ Cross‑session memory in place of hand‑off files The deterministic finalize gate stays fully intact. 3 · Foundry Local — on‑device NPU. The genuine outlier and the most involved port: a Python re‑implementation that runs the model — qwen2.5‑7b, an open ~7‑billion‑parameter model — 100% locally on the device's NPU (a Snapdragon X Elite Copilot+ PC) via Foundry Local's OpenAI‑compatible server. The agent loop, an MCP client, skill loading, and a distinct finalize pipeline all had to be rebuilt outside the CLI. The model never leaves the machine; only data connectors reach out when connected. The trade‑offs are real — modest throughput and a fixed context window — but so is the payoff: offline, private, near‑zero marginal cost. The effort This wasn't a weekend spike. Across the three code bases (plus a clean isolation clone I kept as an A/B baseline): ~340–380 commits per repository, three versions maintained in parallel 17 skills in each cloud build; 18 in the Foundry port ~37 scripts in the streamlined Scout build, up to ~97 in the governed Mainline build A Spec Kit governance layer with 50+ feature specs on Mainline A four‑part cost study and two written deliverables: an architecture whitepaper and a 20‑slide comparison deck The analysis and reporting The whitepaper and deck do two jobs. First, they document each runtime as a layered diagram — runtime, core, skills, scripting/validation, external services — so the differences are visible at a glance. Second, they convert the architecture fork into economics: a study that measured the actual token footprints of each repo and priced runs across billing models and hardware. The four dimensions: per‑skill cost, optimized‑vs‑out‑of‑the‑box, Copilot CLI vs Scout, and cloud vs local NPU. By the numbers The study priced measured token footprints at frontier‑model rates (treat the dollars as ±30% — the relative conclusions are far more robust than the absolute figures): Per skill: roughly $0.6–$1.4 per run usage‑based — or a single flat "premium request" under request‑based billing The determinism dividend: optimized, script‑driven skills cut model round‑trips ~8.7 → ~5.5 and usage‑based cost ~24% — and held cost flat as the logbook grew Scout vs CLI: Scout ran ~37% cheaper across a five‑command session and consumed none of the premium‑request allowance Cloud vs local: on‑device NPU inference came in 50–3,400× cheaper in cash than cloud — at the cost of throughput, context, and first‑pass reliability A full active day (~4 runs) landed around a few dollars usage‑based The headline isn't any single figure — it's the shape: cloud cents buy first‑pass reliability, on‑device near‑zero cost trades your time, and determinism makes either one cheaper and steadier. What held up The core is portable. The same agent, skills, and validation gate ran under all three runtimes. Good separation of concerns paid off. Determinism pays three ways — faster, cheaper, and more reliable (detailed above). It was the highest‑leverage change I made. Managed cloud wins the day job. Scout is the best daily driver: reliability gate intact, lower setup friction, scheduling + memory, and cheaper across a multi‑command session because it caches the bootstrap. On‑device is strategic — but reliability is the tax. Local NPU inference is dramatically cheaper in cash. We ran an in‑depth test pass across every function and closed the gaps it surfaced — yet the smaller model that makes Foundry Local possible still hallucinates and drops instructions often enough on the first pass to matter. Each re‑run is nearly free in dollars, but it costs real time to catch and correct. The winning pattern is hybrid. Draft and triage locally for ~nothing; escalate the correctness‑critical steps to cloud Opus 4.8, paying only where it buys first‑pass reliability. Three runtimes, side by side Figure: Three runtimes, one shared core. Only the top rows — runtime, model, data access, and governance — differ; the behavioral core, skill library, validation gate, and outputs are identical across all three. Capability Mainline (Copilot CLI) Scout‑native Foundry Local (NPU) Runtime Copilot CLI (cloud) Scout (cloud, managed) On‑device NPU Model Claude Opus 4.8 Claude Opus 4.8 qwen2.5‑7b (open, ~7B) Data access MCP Native tools MCP via local client Governance Spec Kit + PR gate Behavioral rules Behavioral rules Scheduling + memory ❌ ✅ ❌ Runs fully offline ❌ ❌ ✅ Marginal cost / run cloud per‑token cloud per‑token (cheaper/session) ≈ free Best for Framework development Daily production Offline / privacy / bulk When to use each Daily CSA workflows → Scout‑native. Managed, cheaper across a session, reliable, and it doesn't burn your Copilot request allowance. Building or versioning the framework → Mainline. Spec Kit governance and the add‑on system earn their keep here. Offline, air‑gapped, or sensitive data → Foundry Local. 100% on‑device inference. Bulk / high‑volume / non‑critical → Foundry Local. Zero marginal cost. Must be right on the first pass → Cloud Opus 4.8. The cents are worth it. Mixed, cost‑sensitive workload → Hybrid. Local draft → cloud escalate. Closing Thoughts The most useful reframe from this work: the three architectures aren't competitors — they're a portfolio. A managed cloud daily‑driver (Scout), a governed development platform (Mainline), and a sovereign on‑device runtime (Foundry Local). The job is to match the runtime to the task, not to crown one winner. And the same lesson that applies to Azure infrastructure applies to agents: build reliability into the system, not into good intentions. Because CSA‑Sherpa keeps its guarantees in code, I could change the entire execution model underneath it — cloud CLI, managed cloud, on‑device NPU — and the agent still behaved the same way. That portability is the dividend of a deterministic design. These workflows are genuinely complex, and that's exactly where the small model shows its limits: even after closing the gaps our testing surfaced, it still hallucinates and drops instructions often enough on the first pass to be a real cost. That's the honest trade‑off — near‑zero dollars, paid back in review‑and‑retry time — and it's why my recommendation lands on hybrid: let the small model draft where it's cheap and low‑risk, and escalate anything that has to be right the first time to cloud Opus 4.8. I use the agent in Microsoft Scout daily, as part of my personal production process. I did use AI to help draft and format this post — fittingly, the very agent it describes. The architecture, the analysis, and the conclusions are my own. Thanks for reading.
Hosted Agent ZIP deployment fails because adduser is missing for fuse-zip
Hi, I am encountering a reproducible issue with a Microsoft Foundry Hosted Agent deployed through the Source Code ZIP deployment path. Environment: - Region: West Europe - Runtime: dotnet_10 - Target framework: net10.0 - Publish runtime: linux-x64 - Dependency resolution: bundled - Protocol: Responses 2.0.0 - API version: 2025-11-15-preview The agent version reaches the "active" status. However, the first invocation fails with: session_not_ready The relevant session logs are: Selecting previously unselected package fuse. Unpacking fuse (2.9.9-5ubuntu3) ... Selecting previously unselected package fuse-zip. Unpacking fuse-zip (0.6.0-0ubuntu3) ... dpkg: dependency problems prevent configuration of fuse: fuse depends on adduser; however: Package adduser is not installed. dpkg: error processing package fuse (--install): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of fuse-zip: fuse-zip depends on fuse; however: Package fuse is not configured yet. dpkg: error processing package fuse-zip (--install): dependency problems - leaving unconfigured Errors were encountered while processing: fuse fuse-zip Successfully connected to container No .NET application startup logs appear after this. The application entry point does not appear to be executed, and /readiness never becomes healthy. I have already verified: A clean linux-x64 publish is used. The entry DLL is located directly at the ZIP root. The ZIP contains no nested bin, obj, or artifacts directories. All dependencies are bundled. appsettings.json, .deps.json, and .runtimeconfig.json are present. The exact published application starts successfully locally. The local /readiness endpoint returns HTTP 200. The issue is reproducible with newly deployed agent versions and new sessions. The current Foundry hosting packages and Responses Protocol 2.0 are used. The same Source Code ZIP deployment path worked successfully approximately two weeks ago. Is this a known regression in the managed source-code runtime in West Europe? Is there a workaround other than switching to the container-based deployment path? Session and request IDs can be provided privately to the Microsoft product team if required.
Data Visualisation / Charting in Azure Foundry
Hi Foundry community, We are working on an agent that can query internal data sources, and are looking for ways that we can visualise data (think pie charts, bar charts, etc.). This would be consumed by end users through Copilot/Teams. However we are unable to find a way to do so, which is surprising given that you easily can create charts through M365 Copilot Chat and through Copilot Studio. We have tried using the 'Code Interpreter' tool, but the Teams/Copilot client UIs just do not render the results inline, either interactive or as an embedded image. They also do not give any option to download them. Has anyone tackled this before? How have you been able generate charts? Many thanks!
New AI Foundry not sending refresh tokens to MCP (401 after access token expiration)
Hello, When connecting an MCP server hosted as an Azure Function using OAuth Passthrough in New AI Foundry Playground, the connection is established successfully, the Microsoft login popup appears, authentication succeeds, and the first MCP request returns data correctly. However, once the access token expires, the Playground and deployed AI Foundry agents to Copilot/Teams do not appear to refresh the token, despite offline_access being included in the requested scopes and a refresh URL being configured. All subsequent MCP calls fail with 401 Unauthorized until the connection is manually recreated. For testing, we reduced the token lifetime to 10 minutes to make the issue easier to reproduce. Impact This prevents long-lived or repeated MCP usage in AI Foundry Playground because the connection becomes unusable after token expiry and requires manual reconnection. MCP server host: Azure Function MCP server configuration in New AI Foundry: Endpoint: https://mcp-test-obo-rls-fabric.azurewebsites.net/mcp Client ID: <client_id> (redacted) Auth URL: https://login.microsoftonline.com/tenant_id(redacted)/oauth2/v2.0/authorize Token URL: https://login.microsoftonline.com/tenant_id(redacted)/oauth2/v2.0/token Refresh URL: https://login.microsoftonline.com/tenant_id(redacted)/oauth2/v2.0/token Scopes: openid profile offline_access api://(App ID)/user_impersonation Redirect URI: https://global.consent.azure-apim.net/redirect/(redacted)-fabric-rls-mcp Error returned tool_user_error: Authentication failed when connecting to the MCP server: https://mcp-test-obo-rls-fabric.azurewebsites.net:443/mcp : Response status code does not indicate success: 401 (Unauthorized). Response body: {"code":401,"message":"IDX10223: Lifetime validation failed. The token is expired. ValidTo (UTC): '03/30/2026 08:19:28', Current time (UTC): '03/30/2026 08:29:55'."}. Verify your authentication headers. Suggestions: First verify the required permissions. If the access token is expired or revoked, recreate the connection. If this connection is shared by other users or workflows, recreate it carefully to avoid disruption. Function App / Identity Provider (Entra) The Azure Function authentication configuration: Identity provider: Microsoft (MCP-Fabric-RLS-Server) App registration: MCP-Fabric-RLS-Server Supported account types: Single tenant Application (client) ID: App ID Client secret setting name: MICROSOFT_PROVIDER_AUTHENTICATION_SECRET Issuer URL: https://login.microsoftonline.com/tenant_id(redacted)/v2.0 Redirect URI is added to App Authentication Redirect URI configuration as "Web". Allowed token audiences api://App ID App ID https://mcp-test-obo-rls-fabric.azurewebsites.net Additional checks enabled Allow requests from any application Allow requests from any identity Allow requests only from issuer tenant tenant_id (redacted) Notes The first authenticated call succeeds, so the initial OAuth flow appears to be working. The failure only occurs after the access token expires. Because offline_access is requested and the refresh URL is configured, our expectation is that the client should refresh the token automatically. Our working hypothesis is that either: the refresh token is not being issued, the refresh token is not being stored/used by AI Foundry Playground, or OAuth Passthrough for MCP connections in this scenario does not currently support automatic refresh as expected. Thank you for any assistance provided.
Getting Started with AI Applications and Agents on Azure
Hello everyone 👋 After exploring Microsoft Fabric and Microsoft Copilot, I wanted to explore another important area of Microsoft's AI ecosystem: building AI applications and agents on Azure. For anyone interested in AI, Data Science, or software development, this Microsoft Learn path provides a beginner-friendly introduction to several important AI workloads. You can explore topics such as: 🤖 Generative AI and AI agents 📝 Text analysis 🎙️ Speech 👁️ Computer vision 📄 Information extraction 📘 Learning path: https://learn.microsoft.com/training/paths/get-started-ai-apps-agents/?wt.mc_id=studentamb_547403 This is a useful starting point for students and developers who want to understand how AI workloads can be built and explored on Microsoft Azure. I think learning the fundamentals of different AI workloads is valuable before moving into more advanced AI application development. Which area of AI are you most interested in learning: Generative AI, AI Agents, Computer Vision, NLP, or Speech? #AzureAI #ArtificialIntelligence #GenerativeAI #AIAgents #MicrosoftLearnSearching for a simple guide to index SharePoint and publish an agent in Foundry
Hey all, Does anyone have a good guide or best practices for this setup in Foundry? SharePoint as data source GPT model (document + image indexing, ideally vectorized/embeddings) Create an Agent an Share the Agent Restrict access to Agent to specific users/groups only Looking for tutorials, examples, or real-world setups. Thanks!
Is there a way to connect 2 Ai foundry to the same cosmos containers?
I defined Azure AI Foundry Connection for Azure Cosmos DB and BYO Thread Storage in Azure AI Agent Service by using these instructions: Integration with Azure AI Agent Service - Azure Cosmos DB for NoSQL | Microsoft Learn I see that it created 3 containers under the cosmos I provided: <guid>-agent-entity-store v-system-thread-message-store <guid>-thread-message-store Now I created another AI foundry and added a connection for the same AI foundry, and it created 3 different containers under the same DB. Is there a way that they'll use the same exact containers? I want to use multiple AI foundries, and they will use the same Cosmos containers to manage the data.
New Foundry Agent Issue
Hi all, I’m creating my first agent via New Foundry, so my questions are probably basic. As always, everything seemed straightforward… until deployment. I created an agent using gpt-4.1, added a list of instructions, and then used the Tools → Upload files functionality to attach a selection of reference documents. Everything worked perfectly in Preview mode. I then used the default option to Create a bot service, and it deployed successfully. To test it, I used the Individual Scope option (with the intention to share later with a couple of people — I haven’t worked that part out yet). Like magic, it appeared in my Teams and M365 Copilot, which was amazing… and then I ran my first search. It thought for a long time and then returned an error. In Co-pilot: and Teams: Nothing happens at all I’ve looked around for help but drawn a blank. I’m fairly sure it’s some kind of permissioning / access issue somewhere, but I can’t find where. Any help would be hugely appreciated.o3-mini not returning reasoning tokens
Hi, I work on a service that leverages o3-mini via Microsoft Foundry. In the past few days, I've observed that when calling o3-mini via Microsoft Foundry, that completion_token_details always has the reasoning_tokens value set to 0, regardless of the reasoning setting being used. In my testing, it seems that the reasoning is still occurring, as increasing reasoning value causes the completion_tokens field to increase by a good amount, but none of the reasoning levels cause the reasoning_tokens value to be anything other than 0. Has anyone else encountered this issue? Thanks! Tomo3-deep-research is failed with the status incomplete with the reason as content filter
I working on an to do an deep research on internal data. I'm using currently the Azure OpenAI Responses API with MCP Tool. The underlying MCP server deployed into ACA with search and fetch tool with signatures in complaint with the specification (https://developers.openai.com/apps-sdk/build/mcp-server#company-knowledge-compatibility). OpenAI client created with 03-deep-research model with MCP tool, in a loop response status being checked. (https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/deep-research#remote-mcp-server-with-deep-research) Deep Research is being carried out for sometime, I could see in the log that handshake has been made, ListTools invoked, search tool is called post that fetch is called for the queries framed by the model.. But intermittently, the response status is becoming "incomplete" with incomplete reason as "content_filter". Otherwise the deep research is working fine. Not able identify the root cause as there is seems to be no way to identify what caused the content filtration whether its the prompt or completion. How to debug and check the root cause and rectify this ? Or is there known issue with the o3-deep-research model's intermediate reasoning completions Or search and fetch tool results are causing this ? I had uploaded a file made it available to MCP server, the search and fetch tool uses an Azure OpenAI agent to search the data using File Search and fetch tool gets the content of the file based on the id passed. For same file and same research topic the issue is not occurring always but intermittently.Microsoft Foundry Agent via Responses API rejects local image input as Base64 data URL / byte array
Hello everyone, we are seeing an issue with the new Microsoft Foundry Agents via the Responses API when sending a local image as part of the user message. What works text-only input image by public URL What fails local PNG passed as Base64 data URL local PNG passed as raw byte array through SDK methods Example failing image part: { "type": "input_image", "image_url": "data:image/png;base64,...", "detail": "auto" } Returned error: { "code": "invalid_payload", "message": "The provided data does not match the expected schema", "param": "/", "type": "invalid_request_error", "details": [] } We reproduced this in: C# Python raw REST So this does not appear to be limited to one SDK. Also important: the same pattern is used in the sample repo for the Foundry Agent Web App, and this scenario worked for us about one week ago: https://github.com/microsoft-foundry/foundry-agent-webapp Could you confirm whether local image input is currently supported for Foundry Agents through the Responses API, or whether this is a regression? Best regards
GPT-5.5-Pro not listed in foundry?
The model is mentioned in this blog post : https://azure.microsoft.com/en-us/blog/openais-gpt-5-5-in-microsoft-foundry-frontier-intelligence-on-an-enterprise-ready-platform/ But it is currently not listed on Foundry. Only latest pro model is 5.4-pro. When will 5.5-pro model be available on azure foundry?Foundry Toolbox preview not working for hosted agent
Tried calling a hosted foundry agent with calls to Toolbox where I tried both web search and code interpreter. Neither of them work. If i use session.call_tool, I get an error like " meta={'tool_configuration': {'type': 'web_search'}} content=[TextContent(type='text', text='NotFound[404, user=The API deployment for this resource does not exist. If you created the deployment within the last 5 minutes, please wait a moment and try again.]', annotations=None, meta=None)] structuredContent=None isError=True". If i try agent.run asking for latest news on a topic ,I either get a generic pretrained knowledge based response (without reference to web search tool) Or a generic error of the type " I wasn't able to retrieve the latest news at the moment due to a technical issue." I have verified that the code uses the appropriate headers like " headers={"Foundry-Features": "Toolboxes=V1Preview"}" I have verified that a Foundry portal agent calling web search tool works as expected. However when I create a custom tool using MCP Server where I provide the URL of the foundry toolbox and then try to use this tool in a Portal created agent I always get an access issue even if i use project identity as the Entra authentication and despite the fact that Project Identity has Foundry User privilege on Foundry Project. I have also tried the github samples for deploying hosted agents with foundry toolbox without luck. Version of agent-framework as of date that I have tried is 1.4.0. Please advise on a resolution. Thanks!Multiple Fabric Data Agent Tools on a Single Foundry Agent
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } We are evaluating the Microsoft Fabric Data Agent integration with Azure AI Foundry Agents and are looking for clarification on the supported architecture. Scenario We would like to create a single Foundry Agent as the orchestrator and attach multiple Microsoft Fabric Data Agents as tools. Each Fabric Data Agent is registered as a separate Foundry tool representing a specific business domain. Executive Assistant Agent (Orchestrator) ├─ Too: Sales Fabric Data Agent ├─ Tool: Finance Fabric Data Agent └─ Tool: HR Fabric Data Agent The expectation is that the Foundry Agent would automatically select the appropriate Fabric Data Agent tool based on the user's request. Examples: "What was our Q2 revenue?" → Sales Fabric Data Agent tool "What is current headcount?" → HR Fabric Data Agent tool "Show budget variance by region." → Finance Fabric Data Agent tool Is it a supported scenario to attach multiple Microsoft Fabric Data Agent tools to a single Foundry Agent? We are unable to find documentation that explicitly states whether: Multiple Fabric Data Agent tools can be attached to the same Foundry Agent. Multiple Fabric tools are supported within a single agent configuration. The error Duplicate tool argument name: 'azure_fabric' indicates a configuration issue, SDK limitation, or unsupported architectureAPIM within Foundry
Dear Azure AI Foundry team at Microsoft, Please reconsider the current architecture and developer experience around AI observability and token analytics. As it stands today, customers are expected to assemble an entire distributed system — APIM, Azure Functions, Static Web Apps, App Insights, Log Analytics, custom SSE parsing, and additional infrastructure — just to answer very basic operational questions: Which users are consuming the most tokens? Which models are being used the most? What are our real-time streaming costs? Which subscriptions/projects are generating spend? Even worse, many of these solutions break down when using streamed/SSE AI responses because APIM policies are not designed to reliably process chunked AI streams and partial JSON bodies. So customers end up building increasingly complicated middleware pipelines for functionality that should already exist natively inside the platform. At the same time: Azure clearly has access to token and billing telemetry internally customers are still billed for usage yet customers themselves are not given equivalent real-time visibility or tooling That creates a frustrating disconnect, making it feel like a money grab when. It's like paying for groceries and not allowing customers to receive a receipt. Another major issue is API key management. Providing effectively a single project-level credential for enterprise AI workloads creates operational and governance limitations that make multi-user auditing unnecessarily difficult. Why in the world, would the foundry team design this with only api key per project? Is there a secret reason for this, other than annoying customers? To be blunt: the current system design feels massively overengineered for customers while simultaneously underdelivering on the core metrics enterprises actually need. AI platform teams should not need to build 10+ supporting Azure services just to approximate token analytics for a single Foundry project. Azure has excellent infrastructure capabilities overall, which is exactly why this experience is so surprising. But if the platform architecture and observability story for AI workloads do not improve soon, many organizations — including ours — will seriously evaluate moving to alternative cloud providers and AI gateway solutions that provide simpler and more transparent operational tooling. Please prioritize: native streaming token telemetry first-class SSE observability proper per-user/per-model analytics better API credential management simpler AI cost governance workflows Right now, the operational overhead compared to the value delivered is far too high.Foundry Agent deployed to Copilot/Teams Can't Display Images Generated via Code Interpreter
Hello everyone, I’ve been developing an agent in the new Microsoft Foundry and enabled the Code Interpreter tool for it. In Agent Playground, I can successfully start a new chat and have the agent generate a chart/image using Code Interpreter. This works as expected in both the old and new Foundry experiences. However, after publishing the agent to Copilot/Teams for my organization, the same prompt that works in Agent Playground does not function properly. The agent appears to execute the code, but the image is not accessible in Teams. When reviewing the agent traces (via the Traces tab in Foundry), I can see that the agent generates a link to the image in the Code Interpreter sandbox environment, for example: `[Download the bar chart](sandbox:/mnt/data/bar_chart.png)` This works correctly within Foundry, but the sandbox path is not accessible from Teams, so the link fails there. Is there an officially supported way to surface Code Interpreter–generated files/images when the agent is deployed to Copilot/Teams, or is the recommended approach perhaps to implement a custom tool that uploads generated files to an external storage location (e.g., SharePoint, Blob Storage, or another file hosting service) and returns a publicly accessible link instead? I've been having trouble finding anything about this online. Any guidance would be greatly appreciated. Thank you!
Recent Blogs
- On-Device AI Inference Changes the Architecture, Not the Risk As organizations transform into Frontier Firms and integrate AI into more applications, cloud-hosted inference is not always the optima...Jul 30, 2026
- A transcription model hears “account number 8-4-7-2” but returns “account number eighty-four seventy-two.” A single error can break a downstream automation workflow. Developers building voice applica...Jul 29, 2026
