Model router updates: new regions, a refreshed model pool, and understanding the hill climb
Across Microsoft, "hill climbing" has become shorthand for how real AI progress happens: not in one dramatic leap, but through a disciplined loop. Microsoft AI defines the hill climb as an organization that continuously improves, cycle after cycle, through more compute, better data, and sharper evaluation. Reinforcement fine-tuning in Foundry defines it as improving the deployable model package one measured step at a time across quality, latency, and cost. Different altitudes, same premise: progress is not a one-shot decision. It's a loop. For most teams, the decision of what model to use when is made manually or with custom routing tools. A developer picks a model based on benchmarks, familiarity, or the last launch that made headlines, ships it, and revisits the choice only when something breaks. In an ecosystem where the frontier moves monthly, that decision goes stale fast. Model router in Foundry Models brings the hill climb to the selection layer. What's new: a bigger pool, in more places This release expands where teams can deploy model router, broaden the supported model pool, and delivers updates through a stable endpoint. Together, these changes help teams run production workloads in more locations, match a wider range of tasks to suitable models, and adopt supported updates without changing the application integration. A refreshed model pool. The supported model list now includes Anthropic Claude Opus 4.8 — a high-capability model built for complex reasoning and long-form generation, for scenarios that demand depth, structure, and quality — and the GPT-5.6 family. Just as importantly, the pool is pruned: gpt-5-chat, gpt-5.2-chat, gpt-5.3-chat, Deepseek-V3.1 have been removed from the model router as models reach the end of their lifecycle and are deprecated in Foundry. New region availability. The model router is now available in 28 regions for global standard and 21 data zone regions. For many organizations, inference requests must stay within specific geographic boundaries for regulatory, governance, or customer-trust reasons — and intelligent routing shouldn't force a compromise on that. Find the full list of regions here. The most important detail is what you don't have to do: these updates occur automatically*. The endpoint remains stable as the supported model pool is refreshed, so teams do not need to redeploy the model router to receive the update. Applications can continue using the same integration while the model router evaluates requests against the current supported pool. Teams should continue monitoring routing traces and application outcomes to confirm that quality, cost, latency, and governance requirements are met. *Models from Anthropic still need to be deployed separately before they can be routed to through the model router. Interested in hearing more about what's new to the model router? Tune in for the next episode of Model Mondays with Sanjeev Jagtap and Lee Stott, where they talk all things model router from evaluations to hill climbing. Sign up here to watch live or view the replay: Model Mondays - Spotlight On Model router in Microsoft Foundry | Microsoft Reactor The selection-layer hill climb At the selection layer, a step is a routing decision. Each one is a micro-optimization against your objective, and each one is instrumented: every response from the model router includes a model field showing which underlying model was selected, so the climb leaves a complete, auditable trail. Model router supports three parts of the optimization loop: A/B testing to compare two router configurations to understand quality, cost, and latency tradeoffs; model decomposition to use routing results to decompose a single-model application into a multi-model or multi-agent design, and continuous routing to keep the router in production for continuous per-request selection. Each pattern turns model choice into a measured, repeatable process rather than a fixed decision. 1. A/B Testing Question: Which model or routing strategy should I use in production? A/B testing helps teams compare candidate models, model families, or router configurations against the same workload. Representative traffic is sent to competing deployments, and teams compare quality, cost, latency, and governance outcomes. The goal is to understand tradeoffs and identify the model or routing strategy that best meets workload requirements before promoting it to production. 2. Model Decomposition Question: What work is my application actually doing? Model decomposition uses model router as a diagnostic tool. By deploying the model router against a representative workload and examining routing telemetry, teams can see how requests naturally separate into different task classes. Simple retrieval, classification, and summarization requests may route to smaller models, while reasoning, planning, and agentic workflows may require more capable models. The goal is not to choose a winner, but to understand the structure of the workload and uncover opportunities for optimization, specialization, or architectural improvements. 3. Route continuously Question: Why choose a single model at all? Route continuously is the pattern model router was designed for but is not limited to. Rather than treating model selection as a one-time decision, teams leave the model router in production and allow the best-fit model to be selected for each request. As the supported model pool, regional availability, and platform capabilities evolve, teams can continue using the same endpoint while evaluating whether updates improve workload outcomes. Model selection becomes an ongoing optimization process rather than a project that must be repeated every time the model landscape changes. Together, these patterns illustrate a broader shift: the model router is more than a model. It is a tool for the optimization loop itself, helping teams evaluate tradeoffs, understand workload behavior, test hypotheses, and continuously refine model selection as requirements evolve. Whether used to compare candidate models, decompose applications into specialized tasks, or automate per-request routing in production, model router turns model selection into an observable, measurable, and repeatable process. As the model landscape continues to change, that optimization loop becomes a durable advantage. Getting Started Ready to start your own hill climb? Whether you're exploring the model router for the first time, evaluating routing strategies against your workload, or building a long-term optimization practice, these resources can help you move from experimentation to production with Microsoft Foundry. What's new in model router? Sign up for the next Model Mondays episode for a deep dive into new features, optimization patterns, and the latest model router updates. How do I build agents with model router? Check out the Model Router Agents Lab and build agent experiences with routing, retrieval, web search, tool calling, and multi-agent patterns. How do I evaluate model router? Compare model router against baseline models using your own prompts, then review quality, cost, latency, and routing decisions with the Auto Evaluation Toolkit. How do I optimize model router for my workload? Start your hill-climbing journey with the Model Mastery workshop, where you'll test one optimization lever at a time and measure how each change impacts workload outcomes. How do I build a model router optimization playbook? Explore the Model Releases repository to track new capabilities, understand the optimization question behind each release, and try focused notebooks that demonstrate one optimization lever at a time.
Copilot Studio agents problems connecting to Sharepoint knowledge source
Hello, Since last week users in my tenant are experimenting issues regarding the connection between copilot studio agents and Sharepoint. The agents are not able to extract information from Sharepoint sites, printing there is not information in the Sharepoint site regarding the user's question when that information is in Sharepoint. These agents used to work well till last week. Does have been any update in Microsoft 365 services that can be affecting these agents ability to retrieve information from Sharepoint?
What is the best file format for an AI agent knowledge base?
This is a best practice sharing the best format for an agent and show you why you should convert your PPT, PDF, WORD into a TXT markdown. I had an issue with my agent, time taken to answer was too long, and usually we spend a lot of time asking: What is the best prompt? Why is my agent slow? Why does retrieval sometimes work and sometimes fail? How can I improve answer quality? But I realised I was asking another question much less often: What is actually the best file format for the knowledge base? PDF? Raw text? Markdown? Pre-chunked text? Semantic sections? Context-enriched text? And more importantly: How much does the format alone affect agent performance? I tried to find a quantified benchmark answering this specific question, with the same agent, same source knowledge and same questions, but different knowledge representations. I couldn't find one that really answered what I wanted to measure. So I decided to run the experiment myself on a real case. My first exploratory tests were already surprising: depending on the representation, the agent could be significantly faster and more accurate, despite working from the exact same source information. So I decided to push the test further. My objective I want to identify, without assumptions and based on actual evaluation data, how a long document should be prepared for an LLM knowledge base so that the agent can retrieve, understand, ground and answer from it as reliably as possible. I focused on five dimensions: Answer quality Retrieval reliability Source grounding / citations Execution time Robustness across single-turn and multi-turn questions The broader question I'm trying to answer is: How should we structure knowledge so that an LLM can retrieve and use it as reliably as possible? The test case I deliberately chose a document that isn't particularly friendly for RAG: a 46-page European regulation, https://eur-lex.europa.eu/eli/reg/2011/1169/oj?locale=fr, on the provision of food information to consumers. The information is distributed across articles, definitions, exceptions, annexes, tables, numerical thresholds and cross-references. That makes it useful for testing retrieval: answering correctly often requires finding a very specific piece of information while preserving enough context to understand how it applies. I used the native PDF as the baseline and created 6 additional knowledge-base representations of the same document: Raw TXT Markdown Chunk-ready TXT RAG-oriented units Semantic TXT Contextual TXT One rule: same knowledge, same agent, same instructions, same questions. Only the knowledge representation changes. The benchmark I used two evaluation sets: 42 single-turn questions testing broad coverage of the document: direct facts, thresholds, exceptions, annexes, lists and cross-references. 5 multi-turn conversations containing 13 questions, to see what happens when a user asks a question and then follows up with things like: "And in this case?" "What are the exceptions?" "And for dietary fibre?" This gave me: 47 evaluated test cases / 55 actual questions per format Across all 7 formats: 329 evaluated conversations 385 user questions executed First results Metric Native PDF Best structured representation Overall pass rate 66.0% 85.1% - Contextual TXT Best single-turn score 69.0% 88.1% - Chunk-ready TXT Multi-turn benchmark 40% 80% - Contextual TXT Multi-turn execution time 14m24 5m54 Total benchmark time 44m31 24m49 The quality gap was already substantial: 66.0% → 85.1% That's +19.1 percentage points while keeping the underlying knowledge unchanged. I also saw a major difference in execution time. On the multi-turn test: 14m24 → 5m54 That's approximately 2.4× faster. Across the complete benchmark: 44m31 → 24m49 Around 44% less execution time. These timings represent the complete agent evaluation pipeline, so they shouldn't be interpreted as pure LLM inference latency. But the difference under identical test conditions is large enough that I want to understand it better. Findings There wasn't one format dominating every benchmark. Chunk-ready TXT scored highest on independent questions: 88.1%, while Contextual TXT performed better across multi-turn conversations and finished with the highest overall score. That may suggest that the way we optimise a document for isolated retrieval isn't exactly the same as the way we should prepare it for conversational retrieval. In the contextual version, I tried to make every section understandable when retrieved independently by keeping useful information around it: Source references Section context Retrieval cues Relevant cross-references For regulatory documents, this seems particularly important. A numerical value retrieved alone can be meaningless without knowing which rule it belongs to, under which conditions it applies, and whether another article contains an exception. Where I am now This remains an exploratory benchmark: One document One domain One agent setup One evaluation framework One run per configuration There are plenty of things I still want to test: repeated runs, retrieval-level evaluation, token consumption, larger knowledge bases, other document types, chunk sizes, overlap, contextual headers, and more. But these first results already convinced me that the preparation of the knowledge base deserves much more attention when evaluating an agent. We often spend hours refining instructions while the same information may behave very differently depending on how it reaches the retrieval layer. Next step I'll share the prompts, knowledge-base formats and evaluation methodology on GitHub so the experiment can be reproduced and challenged. I'll keep enriching the repository as I test new formats, improve the evaluation set and add new results. If people here have ideas, edge cases or formats worth testing, I'd genuinely like to include some of them in the next iteration. What would you test next?Update: Root Cause Identified
Hi everyone, I would like to share the root cause and solution in case someone else encounters the same issue. The Problem I created several agent flows directly in Power Automate using: https://make.powerautomate.com The flows were configured correctly: The flow starts with When an agent calls the flow The flow ends with Respond to the agent The flow and agent are in the same environment The flow is included in a solution The flow is published and fully functional The flows could be added to an agent and executed successfully. However, unlike flows created directly from Copilot Studio, they did not appear in the Global Tools directory. What I Investigated I verified: Trigger configuration Respond to the agent action Environment consistency Solution membership Publish all customizations Asynchronous response settings Synchronization delays between Power Automate and Copilot Studio None of these were the root cause. Root Cause The issue was related to the workflow Plan. I discovered that: Flows created directly in Power Automate were assigned: Plan = The user running the flow Flows created directly in Copilot Studio were assigned: Plan = Copilot Studio Although the Power Automate flow was fully functional and could be used by the agent, it was not visible in the Global Tools directory. Solution After changing the workflow Plan to: Plan = Copilot Studio the flow immediately appeared in the Global Tools directory. Configuration Location The setting can be found in the workflow properties under: Primary owner → Plan Important Note Based on my testing, changing the Plan to Copilot Studio appears to be a one-way operation and may not be reversible. It may be a good idea to export or save the flow before making the change. Acknowledgements Special thanks to sohnash for reproducing the scenario and providing troubleshooting suggestions, and to Patty_Velasquez for sharing similar observations that helped confirm the behavior. Hopefully this helps others who encounter the same issue. Best regards, Adhonaï KOUKAMore powerful agents and workflows for autonomous business processes: Introducing a new harness for Copilot Studio
Over the past two months, we’ve been previewing a new capability within Copilot Studio that lets you build agents capable of taking on more complex business processes. Today, we’re excited to share that this capability is now generally available for production use and to introduce its new name: the GitHub Copilot harness in Copilot Studio. Meet the GitHub Copilot harness The GitHub Copilot harness gives Copilot Studio the coding and reasoning capabilities behind our most advanced agent experiences (like Copilot Cowork and the GitHub Copilot coding agent). This means your agents can now handle work that used to be out of reach, including processes that have many steps, many sources, and ambiguous decision points. The new harness is built for complex, long-horizon work using the latest frontier reasoning models like Opus 5, GPT-5.6 Sol, and Fable 5. It can plan, reason through dynamic problems, run an agentic loop, use skills, integrate workflows, connect to tools and agents in other platforms, and produce rich, multi-part outputs. In our own testing with real world business process evals, Copilot Studio shows significant performance and quality gains when using the GitHub Copilot harness. Improvements in multi-tool use, file analysis, code analysis, and knowledge quality mean these agents are more capable of taking on your most complex business processes. To help you build these more capable agents, we’re also delivering new experiences for makers building agents with the GitHub Copilot harness. The agent designer is more intuitive for authoring, putting the most important tools right within reach to make authoring faster, while retaining full agent lifecycle management features. Then, the workflow designer gives a visual canvas to understand and edit workflows, including adding agent nodes and running workflow evals. And soon, natural language authoring will let you describe your business goal and assemble the right combination of agents and workflows through a multi-turn conversation. Agents running on the GitHub Copilot harness use usage-based billing for all work, regardless of Microsoft 365 Copilot licensing. You pay for your agent’s usage based on the models you choose, the organizational context and tools you add, and runtime used. Certain AI-driven maker experiences, like natural language authoring, evaluations, and testing, will also fall under usage-based billing if building with the GitHub Copilot harness. You can learn more about Copilot Studio usage-based billing here. Continued Support for Copilot Chat and Standard harnesses Adding a new harness does not change the ones you already rely on. Different harnesses can be optimized for different outcomes, so rather than relying on a single one-size-fits-all approach, Copilot Studio now lets you choose the harness that best fits your scenario. This means Copilot Studio supports three harnesses today: The Copilot Chat harness, which uses the same harness as Microsoft 365 Copilot Chat and is ideal for customizing Copilot Chat experiences. The Standard harness, which most agents built in Copilot Studio use today and is great for conversational agents with rules-based topics. The new GitHub Copilot harness, which uses the power of GitHub Copilot SDK to automate complex, agentic business processes. We will continue to support the Copilot Chat and Standard harnesses in Copilot Studio for both existing agents and authoring of new agents. Microsoft 365 Copilot licensed users continue to benefit from fair use of Copilot Chat or Standard harness agents included in their Microsoft 365 Copilot license. For all other usage, the Copilot Chat and Standard harnesses will continue to be billed using the existing fixed rate card. Get started today The GitHub Copilot harness is generally available now, and you can start creating these agents directly from the Copilot Studio homepage. We can’t wait to see what you build. Share your thoughts using the feedback control in the top right corner of the product. Your input directly shapes what we build—and how you build—next. Try Copilot Studio today!The Hidden Reason Your Foundry Agent Can't Reach Any of Your Private (Bring-Your-Own) Resources
The setup You've built the deployment the enterprise architecture review asked for. Nothing touches the public internet. Your Microsoft Foundry resource is private — public network access disabled, a private endpoint fronting it inside your virtual network. Every resource the agent depends on is locked down the same way: Azure AI Search — private endpoint, public access off. Azure Storage — private endpoint, public access off. Azure Cosmos DB — private endpoint, public access off. An MCP server (say on Azure Functions, Container Apps or APIM) — private, reachable only from inside the VNet. You've delegated a subnet for network injection, stood up Private DNS zones for the Foundry account and every data resource, kept the Foundry resource and the VNet in the same region, and configured network injection at account-creation time like the docs require. On paper, this is a textbook private standard agent setup. Then you run your first agent. The problem: network errors everywhere The agent can't reach anything. And the errors look exactly like what you'd expect from a private-networking problem — connection failures and name-resolution errors reaching Search, Storage, and Cosmos; MCP tool calls timing out. Every message points at the network. (Some of you will see the quieter version of this bug instead: no errors at all, but your Cosmos container, your blob container, and your search index stay stubbornly empty. Same root cause — hold that thought.) So, you do the natural thing. You open Network Watcher and start debugging the network. That's the trap. In the vast majority of these cases, the network is fine. The failure is happening one layer up, in a resource most people barely touch — and it presents as a network problem because of what it does when it's misconfigured. The layer you're probably staring at The network layer is the obvious suspect, and to be fair, private standard agent setup has a lot of moving parts that can genuinely break: Private endpoints and Private DNS zones for the Foundry account and for each data resource, so name resolution stays inside the VNet. A dedicated subnet delegated to Microsoft.App/environments for network injection. Foundry resource and VNet in the same region. Network injection configured at account creation — it can't be added to an existing account afterward. Here's the useful distinction, though, and it's the pivot of this whole post: not every "unreachable resource" belongs to the same layer. The layer that's actually failing: the capability host A capability host is a sub-resource you configure at both the Foundry account scope and the Foundry project scope. Its entire job is to tell Agent Service where to store and process agent data — conversation history, file uploads, and vector stores. Capability hosts let you bring your own Azure resources instead of using the default Microsoft-managed platform resources. This gives you: Data sovereignty - Keep all agent data within your Azure subscription. Security control - Use your own storage accounts, databases, and search services. Compliance - Meet specific regulatory or organizational requirements. If you don't create capability hosts, Agent Service doesn't error out. It quietly uses Microsoft-managed resources for all the communications. That's a fine default for development. The moment you bring your own resources, you're in "standard agent setup," and the contract changes: you now have to declare your resources explicitly, in two places, through connections that resolve correctly — or things break. And here's why it masquerades as a network problem. The capability host resolves each of your resources through a connection, and that connection has to carry enough information to bind to the right resource at runtime. Four properties matter: Property What it must be authType The auth type, e.g. AAD category The resource type: AzureStorageAccount, AzureCosmosDb, or CognitiveSearch target The service endpoint URL — not the resource ID metadata.ResourceId The full Azure resource ID of the resource If target is wrong, or metadata.ResourceId is missing or malformed, the agent tries to reach the wrong endpoint — or can't resolve the resource at all. The symptom you see is a connection or resolution failure. The symptom looks like DNS or a private endpoint. The cause is a bad connection object. This is a resolution problem wearing a **connectivity** costume. Hidden reason #1: There is no inheritance from account to project This is the big one, and it's the reason most private setups fail. It's natural to assume that if you configure things at the account level — the account capability host, account-level connections — everything cascades down to the projects underneath. It doesn't. The project-level capability host is the only thing Agent Service reads to decide which storage, conversation, and vector store resources a project uses. There is no automatic inheritance of BYO resource configuration from the account capability host to the project. Even if your account capability host references every connection perfectly, Agent Service will not use those resources for a project unless that project has its *own* capability host that explicitly references them. Account-level connections are inherited by new projects — but a connection and a capability host are different things. Inheriting the connection only means the project can see it. You still have to create a project capability host that points at it. So the classic failure looks like this: you create the account capability host and your connections, maybe reference them at the account level, and stop — because it feels complete. You never created a project capability host, or created one that doesn't reference your connections. Now Agent Service has no project-level instruction to use your resources, so it either falls back to managed defaults (the silent, empty-container variant) or fails to resolve your resource entirely (the loud, network-error variant). Either way, from your private resource's point of view, the agent never correctly reached it. The fix is the project capability host that ties it all together: PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/projects/{projectName}/capabilityHosts/{name}?api-version=2025-06-01 { "properties": { "capabilityHostKind": "Agents", "threadStorageConnections": ["my-cosmos-db-connection"], "vectorStoreConnections": ["my-ai-search-connection"], "storageConnections": ["my-storage-account-connection"], "aiServicesConnections": ["my-azure-openai-connection"] } } aiServicesConnections is optional — include it only if the project should use models from your own Azure OpenAI resource. And ordering matters: you can't create a project capability host until an account-level one already exists. Account host first, then project host. How to diagnose this in five minutes Before you touch Network Watcher again, run these checks. Capability hosts are managed through the REST API today (no SDK surface yet), so this is all ARM. If required, you can use Azure Cloud Shell: Get Access Token: $TOKEN=$(az account get-access-token --resource https://management.azure.com --query accessToken -o tsv) Confirm the account capability host exists: curl -X GET "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/capabilityHosts?api-version=2025-06-01" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" | jq . If account capability host doesn't exit, create one: curl -X PUT \ "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/capabilityHosts/{capabilityHostName}?api-version=2025-06-01" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "properties": { "capabilityHostKind": "Agents", "customerSubnet": "{subnetId}", "threadStorageConnections": [ "my-cosmos-db-connection" ], "vectorStoreConnections": [ "my-ai-search-connection" ], "storageConnections": [ "my-storage-account-connection" ], "aiServicesConnections": [ "my-azure-openai-connection" ] } }' Confirm the project capability host exists — and references the connections you expect. This is the one people are missing. curl -X GET "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/projects/{projectName}/capabilityHosts?api-version=2025-06-01" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" | jq . Look for threadStorageConnections (Cosmos), vectorStoreConnections (AI Search), and storageConnections (Storage). Empty or missing? That's your bug - the agent has no instruction to use your resources. If project capability host doesn't exit, create one: curl -X PUT \ "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/projects/{projectName}/capabilityHosts/{capabilityHostName}?api-version=2025-06-01" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "properties": { "capabilityHostKind": "Agents", "threadStorageConnections": [ "my-cosmos-db-connection" ], "vectorStoreConnections": [ "my-ai-search-connection" ], "storageConnections": [ "my-storage-account-connection" ], "aiServicesConnections": [ "my-azure-openai-connection" ] } }' Inspect each referenced connection. Verify authTyp, category, target, and especially metadata.ResourceId. Watch the classic swap: target is the endpoint URL, metadata.ResourceId is the ARM resource ID. Reversing them is an easy hand-authoring mistake, and it produces failures that read as network errors. A correct Storage connection looks like this: { "properties": { "authType": "AAD", "category": "AzureStorageAccount", "target": "https://{storageAccountName}.blob.core.windows.net/", "metadata": { "ResourceId": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}" } } } Run a test conversation and check where the data actually landed. Conversations should appear in your Cosmos DB, uploaded files in your Storage account, and vector data in your AI Search index and communication to private MCP server should work. The gotchas that keep you stuck Even once you know the fix, a few constraints conspire to make this harder than it should be: Capability hosts can't be updated. Wrong connection name? You can't PATCH it — you delete and recreate. Build your automation around delete-then-create, not an idempotent upsert. One capability host per scope. A second one with a different name at the same scope returns 409 Conflict. Same name + same config is idempotent; same name + different config returns a 400. Deleting a capability host affects every dependent agent. Delete the project and account hosts and your agents lose access to the files, conversations, and vector stores they were using. Treat deletion as a breaking change. Permissions. You need Contributor on the Foundry account to create capability hosts, and User Access Administrator or Owner to grant the agent access to your Azure resources. The mental model to take away Split the question in two. Connectivity asks: can the agent reach this resource? That's the network layer — private endpoints, DNS, subnet delegation, the data proxy. It owns your MCP server and any tool egress. Resolution asks: is the project even told to use this resource, and is the connection pointing at the right place? That's the capability host layer. It owns your Search, Storage, and Cosmos DB. They fail in completely different ways, and - this is the whole point - a resolution failure can look like a connectivity failure. When all of your data resources go dark at once, that's your signal it's resolution, not connectivity. No amount of DNS troubleshooting fixes a project that was never wired to your resources in the first place. Match the symptom to the layer, and you'll stop losing days to the wrong one. A 60-second checklist [] Account-level capability host exists. [] Project-level capability host exists (the one everyone misses). [] The project capability host references your Cosmos, AI Search, and Storage connections by name. [] Each referenced connection has a valid metadata.ResourceId. [] target is the endpoint URL and metadata.ResourceId is the ARM resource ID — not swapped. [] authType and category are correct for each resource type. If all of these pass and it still doesn't work — *then* go back to the network. Further reading Capability hosts for Foundry Agent Service Set up private networking for Foundry Agent Service Networking options for Foundry Agent Service Deep dive into Foundry Agent Service networking Standard agent setup Connect to MCP server endpoints for agents Closing Private-by-default is the right posture for enterprise agents — but it moves the failure modes around. The instinct to blame the network is strong precisely because the network is where you spent all your effort. Next time your agent can't reach its private resources, resist that instinct for five minutes and check the project capability host first. More often than not, that's where the day was hiding.
Copilot Studio: “Get file content using path” fails for table-heavy DOCX files
Hi everyone, I'm investigating an issue with a Copilot Studio Standard Harness agent and would like to know whether others have encountered similar behavior. Scenario I have configured a tool in my agent using: Get file content using path The document is stored in my own OneDrive/SharePoint location and I have full access to it. This is not a chat file upload scenario and not a knowledge source indexing scenario. The agent is retrieving the document through a configured tool action. Behavior Observed Case 1 - Works The Word document contains approximately: ~4.1K words ~20 tables The agent successfully: Finds the file Retrieves the file Reads the content Generates a summary Case 2 - Fails I increase the document slightly: ~4.2K words More tables added The agent now returns a message similar to: The file was retrieved, but its content could not be converted to text. The response still indicates that: File found File retrieved Text extraction/conversion failed Important Observation Initially I thought this might be a word-count limitation, but additional testing suggests otherwise. I tested another document containing: More than 4.3K words Very few or no tables The agent processed that file successfully and generated a correct summary. Because of this, the issue appears to be related more to table-heavy DOCX content than to the total number of words. What Has Been Ruled Out The following do not appear to be the cause: File path issues Permissions/access issues File not found issues Connector authentication issues Large file size issues Chat file upload limitations Knowledge source indexing limitations The same tool and same retrieval approach continue working until the document becomes more table-heavy. Questions Has anyone experienced similar behavior with Get file content using path in Copilot Studio? Does Copilot Studio Standard Harness perform an internal DOCX-to-text conversion step after retrieving the file? Are there known limitations around processing Word documents that contain a large number of tables? Has anyone identified practical thresholds around table count, table complexity, or table-heavy technical documents? Is there a recommended workaround besides splitting the document into smaller files? Any insights, similar experiences, or Microsoft guidance would be greatly appreciated. Thanks!Unanswered Questions on GitHub Copilot Harness in Copilot Studio
We're piloting the GitHub Copilot harness in Copilot Studio (GA August 2026) and several operational and architectural details remain undocumented in the GA FAQ, Microsoft Learn, or licensing guides. Looking for official answers or PM contacts on: Architecture & Execution – When the harness breaks tasks into subtasks, does it use internal sub-agents or only skills/connected agents, what are the exact timeout/retry/max-execution-duration limits for long-running workflows, and are planning/context-retrieval/orchestration internals documented anywhere or is the orchestrator a black box? Model Selection – Can individual skills within one agent use different models or is selection strictly agent-level, how are models chosen internally when multiple skills execute, are any internal models developer-configurable, and what's the roadmap for models being added/retired/deprecated plus the lag between public release and Copilot Studio availability? Cost & Token Optimization – How exactly is the ~45% token reduction achieved, how much control do makers have over context/caching/retrieval/tool calls, what are per-model credit consumption characteristics, which models are most cost-effective for specific workloads, and what's the minimum credit cost for trivial interactions? Memory Management – What are retention periods for session/working/agent memory beyond the documented 28-day user-memory expiry, is true long-term memory supported, and what changed versus earlier implementations? Knowledge Retrieval – Can skills or system instructions influence retrieval strategy/document selection/prioritization/filtering, can planning stages perform conflict/duplicate/version detection before retrieval, and how does the harness decide which sources to search? Apps Feature – What is the "Apps (preview)" capability for, when does it GA, and how does it differ from workflows/skills/adaptive cards/agents? Billing & Credit Sizing – Is there a framework to classify users/agents by expected consumption and size credit allocation per group (citizen vs pro developers), and what's the minimum/typical consumption for simple/medium/heavy interactions? Governance & Admin – Can usage limits be set at user level (not just environment/agent), is there an API/IaC path for large-scale credit assignment, can non-admins view their own consumption/remaining allocation, and is there a self-service request-more-credits dashboard? ALM & Environments – What's the recommended path to move harness agents across Dev/Test/UAT/Prod (Solutions/ALM "setup differs" per parity chart—how?), does GitHub integration replace or complement solution-based deployment, are there recommended AgentOps practices for source control/releases/versioning, and what baseline credits and onboarding model are suggested for citizen developers under usage billing—any enterprise reference implementations?
All Copilot Studio Workflow Tools Suddenly Returning HTTP 403 Before Execution
Hello Copilot Studio Community, I am experiencing an authorization issue with multiple workflows connected to an agent built using the Copilot Studio new experience and new Workflows experience. These workflows worked successfully for multiple users yesterday. Today, all workflow tools connected to the agent began returning an immediate HTTP 403 authorization error. I did not intentionally change the agent, workflows, environment, or workflow permissions before the issue started. Error message: You don’t have permission to use this tool. You’re signed in, but access to this resource is blocked. Error details: Authorization - 403 Example error information: Status: Failed Error message: Flow returned HTTP 403 Error code: Http403 Inner error code: NotSpecified Tool duration: Approximately 93 milliseconds Configuration: - Copilot Studio new agent experience - Copilot Studio new Workflows experience - Agent and workflows are in the same Power Platform environment - Workflows use the "When an agent calls the workflow" trigger - Each workflow includes a "Respond to the agent" action - Workflows are saved and published - Agent is saved and published Observed behavior: The problem affects several independent workflows, including: - New-request submission - Current-user identity resolution - Approval decisions - Requester justification - Executive decisions - Fulfillment updates For every affected workflow: - The agent fills the workflow inputs correctly. - The tool call fails almost immediately. - No corresponding run appears in the workflow Activity history. - The workflow trigger is never reached. - No workflow actions execute. Because no workflow run is created, the rejection appears to occur before workflow execution, possibly within the Copilot Studio agent-to-workflow authorization or invocation layer. Troubleshooting already completed: - Confirmed that all workflows are published. - Confirmed that the agent is published. - Tested in a completely new conversation. - Removed an affected workflow tool from the agent. - Saved the agent. - Added the same published workflow back to the agent. - Reconfigured and verified the tool inputs. - Republished the agent. - Confirmed that no workflow Activity run is created. - Confirmed that the issue affects multiple workflows rather than one specific workflow. Removing and re-adding the workflow did not resolve the problem. Questions for the community: 1. Is anyone else currently experiencing HTTP 403 errors when Copilot Studio agents invoke workflows? 2. Is this a known issue or regression in the new Workflows experience? 3. Is there an environment-level or tenant-level permission that controls agent-to-workflow invocation? 4. Could a tenant policy, Conditional Access change, service principal, connection reference, or workflow-sharing configuration cause all workflow tools to fail simultaneously? 5. Where can an administrator find detailed authorization logs when the workflow never creates a run? 6. Has anyone found a workaround for this issue? Any guidance or confirmation from others experiencing the same behavior would be appreciated. I can provide screenshots, complete error details, timestamps, and additional configuration information if needed. Thank you.Pattern for governing Copilot Studio agents before they reach production
I keep seeing the same gap across Copilot Studio deployments: agents get built and shared before anyone has answered three basic governance questions. Before I call an agent production-ready, I check: -> Who's the sponsor? Not just who built it, who's accountable for it existing. -> What's it grounded on, and who can actually read that data? A knowledge source that's technically "in scope" isn't the same as verified content people should be answering from. -> Is there an audit trail for what the agent said and to whom, if someone asks later? None of this shows up in a demo. It only shows up a few months in, when the agent's still running and nobody remembers why. I wrote a longer breakdown of this governance model, including how Microsoft Agent 365 fits into it, here: https://jpmarquez.com/blog/microsoft-agent-365-licensing-what-you-actually-buy/ Curious what pattern others are using here, especially for the sponsor/ownership question, since that's the one I see skipped most.
