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?GPT-6.1 Terra now generally available in Microsoft Foundry: build agents that see and act
AI agents that read dense charts, navigate desktop apps, and process scanned documents are only as capable as the model behind them. OpenAI’s GPT-6.1 Terra, now generally available in Microsoft Foundry, delivers significant gains in visual reasoning and computer-use speed, so the apps and agents you build can see more and act faster. AI projects often slow down on identity, networking, governance, data handling, evaluation, and compliance. Microsoft Foundry brings these fundamentals together in Azure, so you can take GPT-6.1 Terra from prototype to production with speed and trust. What's new in GPT-6.1 Terra GPT-6.1 Terra is a quick, efficient model built for day-to-day professional tasks, with four core strengths: Stronger vision. Improved visual reasoning helps the model pick out the details that matter in product photos, technical drawings, floor plans, and application screens. Faster, more precise computer use. The model pairs what it sees with quick, accurate actions across browsers, desktop software, and apps, so agents can go from reviewing information to finishing the task. Clear writing. Summarizes what it finds in plain, approachable language and drafts natural-sounding emails and proposals for everyday work. GPT-6.1 Terra also provides: Large context window. Up to 1M input tokens. Multimodal input. Accepts text and images. Developer controls. Tune reasoning effort, including a none setting for latency-sensitive calls, and adjust verbosity to match response length to the task. Interim updates. When your orchestration layer supports it, the model can send interim messages to the user while it continues working toward a final response, keeping long-running tasks responsive. Where GPT-6.1 Terra fits GPT-6.1 Terra is built for work that starts with visual analysis and ends with action inside software: Forms, email, and proposals. Complete forms and draft emails and proposals as part of routine administrative work. Design and technical visuals. Review campaign assets for cropping and text placement and turn issues into a clear list of fixes or read technical drawings and update floor plans in the right tools. Visual analysis to action. Review what appears in images or on application screens and use those insights to drive the next step in a software workflow. Retail catalog upkeep. Match supplier product images to existing catalog entries, spot gaps in product details, and update listings in the browser. Video workflows. Find a specific moment in a video and make edits through video applications. GPT-6.1 Terra complements GPT-6 Astra. Astra reasons through open-ended, multi-step work and plans the job. Terra handles the high-volume visual and screen-based tasks inside it, at a lower price point. Built into the Foundry platform GPT-6.1 Terra works with the Foundry APIs and tools you already use. It’s available through the Responses API with no new SDK requirements or schema changes. From day one, GPT-6.1 Terra is available through Foundry Models in Global Standard deployments across all supported regions, and in Data Zone Standard deployments in US, EU and APAC. You can adopt the latest frontier model where you’ve already built and scaled your applications, without trading off performance for data residency. Watch the demo with Naomi Moneypenny for a platform-wide walkthrough of model selection, evaluation on your own data, and approaches to cost optimization. GPT-6.1 Terra Pricing (USD/1M tokens) Model Deployment Context Length Pricing (USD $/million tokens) Input Cached Input Cached Writes Output GPT-6.1 Terra Global Standard Short context $1.00 $0.05 $1.25 $5.00 Long context $2.00 $0.10 $2.50 $7.50 Data Zone Standard (US) Short context $1.10 $0.055 $1.375 $5.50 Long context $2.20 $0.11 $2.75 $8.25 Data Zone Standard (EU) Short context $1.20 $0.06 $1.50 $6.00 Long context $2.40 $0.12 $3.00 $9.00 Data Zone Standard (APAC) Short context $1.20 $0.06 $1.50 $6.00 Long context $2.40 $0.12 $3.00 $9.00 Learn more pricing details in here. Put GPT-6.1 Terra to work on your next AI app Deploy GPT-6.1 Terra in Microsoft Foundry today to build apps and agents that read complex visuals and act on screen faster. Some steps in your app need a fast, structured answer instead of generated text, such as classifying content or routing a request. For those, use the Decisions API. Last week, we announced the general availability of OpenAI’s Decisions API with GPT-6 Luna in Microsoft Foundry. Terra handles the visual and on-screen work, and the Decisions API makes the quick call on what happens next. Whichever you start with, you get development, evaluation, and governance on one platform, so you can move from prototype to production with confidence.Are bigger agents better? How to design agents that scale
Editors' note: The GitHub Copilot harness is now the Microsoft Copilot harness. Learn more. There is a moment every maker hits. An agent works, so you add another tool. Then another knowledge source. Then instructions for an exception that appeared last week or an entirely new use case you want your agent to be able to tackle. Each addition is useful on its own, and the agent can now do more. But "can do more" and "reliably does the right thing" are different properties. As an agent’s scope increases, the model has more choices to distinguish, more context to process, and more possible execution paths to manage. That doesn’t mean large agents are bad. It means that as capability grows, the challenge increasingly becomes a design problem. The key to scaling an agent isn't giving it more. It's being deliberate about what it sees, what it decides, and what it delegates. What changes as an agent grows The agent scaling challenge Consider a supplier-onboarding agent. The first version collects supplier details, checks that the request is complete, and starts an approval. Over time, makers add tools for ERP records, tax validation, sanctions screening, bank verification, contract storage, service tickets, email, and reporting. They add knowledge for regional policies and instructions for exceptions. Eventually, a request such as "Onboard our newest supplier" might present the agent with several supplier-search tools, multiple ways to create or update a record, and overlapping policy sources. The agent still has all the required capabilities, but choosing the right path is harder. The agent scaling challenge tends to show up in four places: Selection: Similar tool names and descriptions make the correct action harder to identify. Context: Tool definitions, instructions, knowledge, conversation history, and tool outputs all compete for a finite context window. Execution: More possible paths create more opportunities for unnecessary calls, retries, and inconsistent outcomes. Operations: A larger capability surface is harder to evaluate, secure, govern, and maintain. A recent post from Microsoft Research discusses one part of this problem: Tools that work well independently can reduce end-to-end performance when they compete in a large or overlapping set. Often, the problem isn’t one bad tool. It is the ambiguity between several reasonable ones. Figure 1: As a supplier-onboarding agent grows, overlapping tools, instructions, and knowledge compete for attention before the agent begins the task. More context comes with a cost There is also a direct cost associated with an expanding toolset. A tool consumes tokens even when it is never called because its name, description, and parameter schema are included in the context presented to the model. When it is called, its output becomes part of the agent's ongoing context. More context can mean more spend, as well as less reliable selection. The goal isn’t a smaller agent. It is a system where each decision sees only the context, authority, and capabilities it needs. Success is measured by business outcomes, reliability, cost, and control. What our harness can handle for you Good agent architecture doesn't mean solving every scaling challenge yourself. The GitHub Copilot harness in Copilot Studio is built to manage some of the complexity as an agent grows. Model improvements that don’t require agent redesign New models are made available through the GitHub Copilot harness as they release. As more advanced frontier models become available, teams can evaluate them against their scenarios and adopt improvements without redesigning the overall solution architecture. Model choice can also be an important factor in agent cost optimization, helping makers balance the number of tokens used against the capability needed to achieve a goal. Manage complexity natively with tool search The GitHub Copilot harness includes runtime capabilities designed for reasoning-heavy, multistep work. One example is tool search. When the available tool set becomes large, tool search can hold external tool definitions back and load the relevant ones on demand instead of placing every full schema in the model's context. For the supplier-onboarding request, this can narrow a large catalog to the tools associated with finding a supplier, validating its details, and starting onboarding. The model works with a smaller, better-matched set of choices while unrelated tool definitions remain out of the way. The harness can also plan across tools, skills, workflows, MCP servers, files, and connected agents, and adjust its path as work progresses. This all makes large, reasoning-heavy automations more practical. But runtime capabilities only solve part of the scaling challenge. How you divide responsibilities across tools, workflows, skills, and connected agents still matters. How to design agents that scale in Copilot Studio A scalable design starts by deciding which part of the system should own each responsibility. For instance: Use a tool for a bounded action or lookup with a clear input and output. Use a workflow when a sequence, approval, or business rule should execute consistently. Use a skill for specialized instructions that are only needed for a particular task. Use a connected agent when a domain has distinct context, ownership, or requirements. Use the main agent to coordinate outcomes, gather information, make judgments, and handle exceptions. These are not interchangeable building blocks. Each introduces different tradeoffs in context, flexibility, latency, cost, security, and maintenance. The goal is to use the simplest component that gives each responsibility a clear owner. 1. Make choices distinct Start with the choices already available to the agent. Give tools, knowledge sources, and connected agents specific names and descriptions that explain both what they do and when they should be used. Merge or remove duplicate capabilities. Avoid several general-purpose tools that all appear to answer the same intent. In the supplier example, "Search suppliers in ERP by legal name or tax ID" is easier to select correctly than a generic tool named "Search." If two tools search the same supplier records, expose one clear route rather than asking the model to choose between implementations. Tool search itself relies on names, descriptions, and parameter metadata to find relevant tools, so good metadata improves both discovery and final selection. 2. Load specialist guidance only when it is needed Some instructions are only relevant when an agent performs a particular task. Keeping all of them in the main agent instructions means they occupy context on every turn, even when they do not apply. Skills let makers package specialized instructions separately so the agent can load them when the task requires them. For example, regional supplier due-diligence guidance can be packaged as a skill and loaded for suppliers in that region, rather than remaining in the main instructions for every supplier request. The principle is the same as tool search: keep relevant context close and leave unrelated context out of the current decision. 3. Split on real boundaries When one agent contains several distinct domains, consider separating them. To clarify: Don't split an agent simply because it has grown large. Split where there is a meaningful boundary in context, ownership, security, or requirements. In the GitHub Copilot harness, connected agents let a primary agent delegate a bounded task to another Copilot Studio agent with its own instructions, knowledge, tools, and orchestration context. The supplier-onboarding agent could remain the front door while delegating: Compliance assessment to a compliance agent owned by the risk team. Supplier record creation to a finance operations agent with access to the ERP. Contract preparation to a legal operations agent with its own templates and policies. The primary agent now chooses between a few clearly described business capabilities instead of dozens of lower-level tools. Each specialist can be evaluated, secured, deployed, and improved independently. Copilot Studio also supports open agent architectures. Depending on the runtime and scenario, solutions can compose Copilot Studio agents or connect supported external agents through the Agent2Agent protocol. In the supplier scenario, a specialist due-diligence agent hosted outside Copilot Studio could sit behind the same clear boundary, rather than being rebuilt as a collection of tools. 4. Put fixed sequences in workflows Use the agent where the next step requires judgment. Use a workflow where the sequence, approval, or control must remain consistent. This helps preserve adaptability without making every part of the process probabilistic. For example, supplier onboarding might always require the same core sequence: validate required fields, check for an existing supplier, run mandated compliance checks, create the record, and route it for approval. A workflow can own that sequence. The agent can still decide when to start it, gather missing information, and handle exceptions. This reduces the number of low-level decisions the model must make and gives makers one place to enforce approvals, retries, and audit requirements. The supplier-onboarding agent, redesigned So let’s go back to the original agent in our example. It had one long instruction set, several knowledge sources, and dozens of tools. The redesigned system doesn’t eliminate that agent. It gives it a clearer job: coordinating the overall outcome while other components take on more specialized responsibilities. That gives us a system: The main supplier-onboarding agent understands the request, collects any needed details, delegates as needed, handles exceptions, and responds. Tool search limits the external tools loaded for the current request. Clear metadata separates supplier lookup, compliance, finance operations, and contract tasks. A workflow owns the fixed onboarding and approval sequence. Skills provide regional guidance only when the supplier's location requires it. Connected agents own compliance, ERP, and legal domains where those boundaries justify separate agents. vant tools, workflows own fixed sequences, and specialist agents own bounded domains. The result is the same overall capability, but as a composed system with clearer responsibilities and less for any one decision to reason over. Evaluate for the outcome Each approach discussed above has limits. A stronger model cannot compensate for unclear instructions or overlapping tools. Tool search reduces what the model sees, but it does not create boundaries that have not been designed. Workflows and skills reduce what the main agent must reason over, but they add components to maintain. And connected agents can provide clearer ownership and security boundaries, but each handoff adds token use, another failure point, and more to govern. Designing agents that scale means managing all four components of the agent scaling challenge together: making selection easier with distinct choices and clear boundaries, controlling context with tool search and skills, making execution more predictable with workflows and deliberate delegation, and strengthening operations through components that can be evaluated, secured, governed, and improved independently. Agent scale is not a tool-count contest. Models, requirements, and available tools will keep changing, but these principles give you a more durable way to evolve an agent without letting added capability become added confusion. The goal is not the biggest agent; it is a composed system that reliably does the right work, at the right cost, with clear ownership.
White paper: Choosing between the GitHub Copilot and Standard harnesses in Copilot Studio
Editors' note: The GitHub Copilot harness is now the Microsoft Copilot harness. Learn more. The Standard harness and GitHub Copilot harness are two authoring and runtime options within Microsoft Copilot Studio. A harness is the operating layer between the model and the agent’s configuration. It determines how the model receives context, uses instructions and tools, interprets results, and moves through a task toward completion. Put simply, the model provides the reasoning capability, while the harness equips and directs it. Both harnesses are built for task-based, multi-step agents that create real business value, but they are suited to different scenarios. The Standard harness supports consistent, reliable execution of bounded business processes, while the GitHub Copilot harness extends these capabilities to longer-running, coordination-heavy, and reasoning-intensive work at a larger scale. This paper explains the key differences, tradeoffs, and scenarios to help you choose which harness is right for your business process. Read the full paper by clicking the PDF attachment below.More powerful agents and workflows for autonomous business processes: Introducing a new harness for Copilot Studio
Editors' note: The GitHub Copilot harness is now the Microsoft Copilot harness. Learn more. 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 GitHub app in Microsoft Teams is now generally available!
GitHub empowers any team to become builders in Microsoft Teams. Customer support teams are using GitHub to turn customer feedback from Teams channels into filed issues. Engineering teams are asking GitHub to investigate, reproduce, and fix bugs without leaving Teams. Business and marketing teams with innovative ideas are asking GitHub to turn their discussions into working prototypes. During public preview, our team has been hard at work addressing feedback and making product improvements to the GitHub experience in Teams. Here is what’s new. Review work in the GitHub Canvas The new GitHub canvas lets you review the plan, file changes, and pull request without leaving Teams. Click “Open Canvas” to follow GitHub Copilot’s progress and see your team’s ideas take shape in code, right beside the conversation. Go from notification to pull request in one app GitHub notifications and GitHub Copilot now live in a single app in Teams called GitHub. Stay on top of issue and pull request updates and act on them right in Teams. When an update needs attention, reply to the notification with "@GitHub". GitHub Copilot can investigate, make the fix, and draft a pull request in the same thread, so your team sees the update and the response together. Issues and pull requests created from Teams now carry attribution. Reviewers can see who started the work and link back to the Teams conversation where it was discussed. Work across repositories and tools Real work rarely lives in one repository. With multi-repo support, GitHub Copilot can work across all the repositories your task needs in the same conversation. In addition, MCP support lets you configure which tools and connected services GitHub can leverage in Teams. Learn more about configuring MCP. Get set up in a guided experience The new guided web onboarding experience helps you sign in through your default browser using saved passwords or passkeys and grant Teams access to the right organizations and repositories. You can now use natural language to ask GitHub to use a default repository or switch repositories in your Teams conversations. You can also choose the model GitHub Copilot uses for a task. Pick a faster model for quick fixes or a more capable model for larger changes. Get started today Add the GitHub app to Teams today, then click “Get started” from its welcome message to connect your account. Type "@GitHub help" to see what else it can do. Admins should verify the following are enabled for users to get started: Microsoft 365 admins: ensure resource-specific consent is enabled so users can let the GitHub app use conversation context. TAC admins: ensure the GitHub app is allowed for users in the Teams admin center. GitHub enterprise admins: ensure Copilot cloud agent, cloud sandboxes, and CLI billing are enabled for each organization and assign GitHub Copilot licenses to users. Learn more at teams.github.com! We'd love to hear what you build. Share your feedback in the comments below.
Turn enterprise knowledge into a personalized voice and avatar agent in minutes with Voice Agent
A customer asks how a product works, then follows up: “Can you give me an example?” They need a useful explanation based on your product documentation, without searching through pages of information. Now imagine that conversation delivered in a voice and with a face that represent your brand. Voice Agent in Foundry Agent Service brings three things together in one real-time conversation: your knowledge through Foundry IQ, your voice through Personal Voice, and your face through a custom photo avatar. Once these assets are prepared, combining them takes a few minutes in the Foundry portal: create a Voice Agent, connect the knowledge, select the voice and avatar, and start talking. You don't need to build speech, avatar or app code to try it: the playground handles all of that. Why Voice Agent Minutes, not a project. With your knowledge base, voice and avatar ready, setup is four steps in the portal, with no code required to try the experience. Answers grounded in your content. Foundry IQ connects the agent to your documents, and you can instruct it to say when the materials don't contain an answer instead of guessing. A natural conversation. Users speak in real time and ask follow-up questions that build on conversation context. With interruptions enabled in a supported voice configuration, users can also interrupt the agent mid-answer. Build the identity once, update the knowledge anytime. Refreshing your documents does not require recreating the voice or avatar, and the same prepared assets can be reused across agents. Give your knowledge a voice and a recognizable face Personalization is most useful when it helps someone complete a task. A common pattern brings together your knowledge, your authorized identity, and a Voice Agent that makes both conversational. Here are some places to start: Scenario Knowledge to connect Voice and avatar Product concierge on your website or in a store kiosk Product manuals and approved FAQs Your brand spokesperson Employee onboarding and HR help Policies, handbooks and benefits guides A familiar HR partner or team lead Internal IT helpdesk Runbooks and troubleshooting guides Your support team's representative Training and e-learning tutor Course materials The course instructor Museum, tourism or campus guide Exhibit and visitor information A curator or guide Expert “office hours” Talks, FAQs and published content The expert, with their consent In each case, users can move from an overview to a concrete example at their own pace, in the same conversation, instead of navigating long documents or restarting their search. These are starting points to adapt to your audience and approved use, not customer deployments. Watch the conversation, not just a talking avatar The demo below uses a Theodore Roosevelt knowledge base to show three connected interactions with Voice Agent in the Foundry playground. The historical topic is a compact example; replace it with your own knowledge to apply the same pattern to any of the scenarios above. Ask the Voice Agent What it shows What were Theodore Roosevelt's main contributions to conservation? A grounded answer from the connected knowledge base Could you give one specific example and explain why it mattered? A follow-up that builds on the conversation context What was Microsoft's closing stock price yesterday? Knowing its limits: the agent says the available materials do not contain the answer instead of guessing The voice and avatar in this demo are AI-generated. Theodore Roosevelt is the subject of the knowledge base, not the identity portrayed by the assistant. The point is not simply to animate a response. It is to let a user get an explanation, explore it through a follow-up and understand when the connected knowledge cannot help. The demo uses a platform-provided voice (Andrew Dragon HD) and a preset photo avatar (Marcel); with Personal Voice and a custom photo avatar, the conversation works the same way, with your own identity. From prepared assets to a conversation in four steps Start in a supported Foundry project with these resources prepared, or reuse ones you already have: Knowledge: a Foundry IQ knowledge base created from your authorized documents. Try a sample question to preview the results. Voice: a Personal Voice created from a short, clean voice sample and the speaker's recorded consent statement. Appearance: a custom photo avatar created from an authorized photo and a consent video of the person pictured. You can also start right away with platform-provided voices and avatars and personalize later. The Voice Agent setup guide walks through preparing each resource, including the consent and eligibility requirements, for both the portal and Python. 1. Create a Voice Agent In the Foundry portal, open your project and go to Agents → Build an agent. Enter a name, select Voice as the interaction mode, choose the appropriate use case, and select Create agent and open playground. Review the model and default instructions for your scenario. 2. Connect the knowledge that helps users complete their task In the agent configuration, expand Knowledge, select Add, and choose your prepared Foundry IQ knowledge base from Available knowledge bases. Give the agent a clear purpose, such as explaining product features from approved documentation, and keep spoken answers concise. For example: Use the connected knowledge base for factual answers. Give a brief, direct answer and use conversation context for follow-up questions. If the available materials do not contain the answer, say so rather than guessing. This gives the conversation a useful boundary: the knowledge supplies the answer, and the voice and avatar determine how it is presented. 3. Choose how the agent sounds and appears Under Voice, select your Personal Voice (Custom → Personal). Enable Avatar and choose your custom photo avatar (Custom → Photo avatar). Preview the selections to confirm they match the intended identity and are available for your project's resource and region. This is where the experience becomes recognizable: the same product knowledge can be delivered by your brand spokesperson or your trainer, and you can swap the knowledge or the identity independently. 4. Save and start talking Select Save, then Start session, and allow browser microphone access. Ask about your content, follow up naturally (for example, “Can you give me an example?”), and try a question outside your documents to check whether the agent acknowledges when the information is unavailable. That's it: your knowledge, voice and avatar are working together in a live conversation, right in the playground, with no local SDK setup. Check the answers against your source documents before sharing the agent with users. Personalize with permission Use voice, likeness and documents you are authorized to use, complete the required consent and access approvals, and disclose synthetic voice and avatar output. Personal Voice and custom photo-avatar capabilities have eligibility requirements; available models, regions and preview features vary. The setup guide links to the applicable requirements. Review audience access and data handling before using enterprise content, and validate the experience for your intended deployment. Build your first Voice Agent Start with one focused knowledge collection, one authorized identity and three useful questions. Voice Agent in Foundry Agent Service turns those building blocks into a conversation that people can hear, see and follow up on. Ready to build it? Follow the step-by-step setup guide to prepare your knowledge base, Personal Voice and photo avatar, then bring them together in a Voice Agent through the Foundry portal or Python. For more documentation, quickstarts and samples, explore the Microsoft Voice Agent repository. Your knowledge, your voice, your face: one conversation, a few clicks away.Bring Your Own Telephony to Voice Agents via SIP
Voice agents in Microsoft Foundry give developers an integrated way to build intelligent, natural voice experiences, bringing together models, agent capabilities, tools, and the platform capabilities needed to move from experimentation to production. Foundry continuously expands channel integration options to serve different organizational needs. Voice agents in Microsoft Foundry and Voice Live API now support Session Initiation Protocol (SIP), allowing phone calls to reach AI voice agents directly through SIP trunks. This enables low-latency voice interactions while letting you continue using your existing contact center telephony infrastructure. What is SIP - SIP (Session Initiation Protocol) is an industry-standard signaling protocol for establishing, managing, and terminating real-time communication sessions. It is widely used in IP telephony, including enterprise and contact center environments. Why voice agents need SIP for contact center telephony - Enterprise telephony and contact center environments commonly use SIP-based PBXs, session border controllers (SBCs), and carrier trunks. SIP enables voice agents to integrate with this existing telephony infrastructure for call signaling, routing, and media negotiation. Direct SIP vs. Customer-managed Audio Bridge - Direct SIP connects voice agents with existing telephony and contact center infrastructure through standard SIP interfaces. In comparison, a customer-managed audio bridge requires customers to build and operate an intermediary layer to relay real-time audio between their telephony infrastructure and the voice agent, typically over WebSocket or WebRTC. This adds integration complexity, potential latency, and operational overhead. Direct SIP significantly simplifies the architecture by eliminating the need for this intermediary audio layer. Understand the call flow: Caller (inbound) -> telephony provider or enterprise telephony system -> SIP trunk or SBC -> Foundry SIP endpoint -> telephony binding -> voice agent Get started with voice agents in Microsoft Foundry Getting started only takes a few steps: Open the Microsoft Foundry portal and create a new agent, select Voice as the agent type. Choose a voice-optimized model and configure your agent's instructions. Connect knowledge sources and tools as needed for your scenario. Test your agent directly in the built-in voice playground. Go to Channels tab -> Phone numbers -> Direct SIP. Add your SIP trunk connection using the same credentials provided by your SIP trunk provider, then bind the connection to the voice agent for inbound calls. (For outbound calls, no binding is required; configure the SIP connection through the SDK or REST API when placing a call). Copy the SIP binding URL and configure it with your SIP trunk provider to route calls to your voice agent. Make a test call, then monitor performance using built-in observability and evaluation capabilities. Learn More Introducing voice agents in Microsoft Foundry | Microsoft Community Hub Quickstart: Create a voice-based prompt agent - Microsoft Foundry | Microsoft Learn How-to: Connect a voice agent to telephony via SIP - Microsoft Foundry | Microsoft Learn How-to: Connect voice live API to telephony via SIP - Foundry Tools | Microsoft Learn
Designing a Governed RTO Compliance Agent Using Copilot Studio and Databricks Genie
Enterprise AI adoption in HR scenarios comes with a unique challenge: how do you deliver actionable insights without compromising privacy, trust, or policy boundaries? In this blog, I’ll share how we built an RTO (Return‑to‑Office) Compliance Agent using Microsoft Copilot Studio and Databricks Genie, focusing on governance‑first design, controlled data access, and real‑world enterprise constraints. This solution was developed as part of an HRLT proof‑of‑value initiative and is designed to support people managers with clear, aggregated compliance insights, delivered conversationally inside Microsoft Teams. The Problem We Were Solving As hybrid work models mature, organizations need a reliable way to answer questions such as: How compliant is my team with RTO expectations? Are there trends across regions or time periods? Traditional dashboards often fall short because they: Require manual interpretation Expose too much granular data Are difficult to govern at scale Our objective was to create an AI‑powered conversational interface that provides: Only manager‑authorized, aggregated insights Zero visibility into individual‑level behavior Built‑in enforcement of HR and privacy policies Architecture Overview The solution integrates Copilot Studio with Databricks Genie, backed by curated data sources. (Image: High-level Copilot Studio and Databricks Genie architecture) Key Components Copilot Studio – Conversational orchestration, policy enforcement, and Teams deployment Databricks Genie – Governed natural-language interface to curated datasets RokFusion Platform – Trusted HR and badge-swipe data This layered approach ensures governance is applied before data is ever queried. Controlled End-to-End Data Flow The interaction pattern follows a strict, auditable flow: A manager asks a question in Copilot Studio Copilot forwards the request to Genie with instruction constraints Genie executes logic only on curated, approved tables Calculations are performed at team or manager level only Copilot formats and returns compliant responses (text, tables, or charts) At no point are employee IDs, badge events, or individual metrics exposed. Using Genie as a Governance Layer, Not Just a Query Tool One of the most critical decisions was to treat Databricks Genie as a policy‑enforcement layer, not merely a natural‑language SQL generator. (Image: Genie instruction configuration enforcing compliance rules) What We Configured in Genie Synonyms and NL mappings for HR terminology Strict filtering logic for employee categories Population threshold enforcement (minimum count) Explicit rejection of sensitive attributes such as gender, race, religion, or age Prevention of formula or row‑level data exposure This approach ensured that even malformed or risky prompts could not bypass policy constraints. Compliance Scenarios Supported The agent supports multiple business‑aligned interpretations of RTO compliance: Hybrid Compliance Hybrid employees counted only on eligible hybrid days Onsite Compliance Onsite employees counted across standard working days All Employees View Weighted aggregation combining hybrid and onsite logic These scenarios are embedded into the agent’s instruction logic, not dynamically inferred at runtime—ensuring consistency and auditability. Why We Chose Conversational AI Over Dashboards A key insight early on was that managers don’t want spreadsheets—they want answers. Instead of navigating filters and charts, managers can ask: “What was my team’s compliance last week?” “Show me a comparison across regions.” When required, the agent can also render simple visual outputs. (Image: Sample Microsoft Teams output with compliance visualization) Importantly, visuals follow the same governance rules as text responses. Publishing and Validation in Microsoft Teams Once configured, the agent was published directly from Copilot Studio to Microsoft Teams, making adoption frictionless. (Image: Publishing Copilot Studio agent to Microsoft Teams) End‑to‑end testing validated: Authorization boundaries Population rules Safe handling of incomplete or ambiguous queries Key Engineering Learnings Governance must be instruction‑driven Relying on frontend filtering alone is insufficient for HR data. Natural language needs strong guardrails Enterprise AI benefits from being constrained, not free‑form. Aggregation builds trust Managers are more comfortable with insights when they know individual visibility is impossible. Copilot Studio accelerates enterprise delivery Security, deployment, and integration stay within the Microsoft ecosystem. Closing Thoughts This RTO Compliance Agent demonstrates how Copilot Studio and Databricks Genie can be used to build governed, enterprise‑ready AI solutions—especially in sensitive domains like HR. By embedding policy into architecture, instructions, and data access, we were able to deliver: Useful insights Strong privacy guarantees High user trust This pattern is extensible well beyond RTO—opening the door for future HR intelligence use cases built on the same foundation.
