hey im new to the community and i just wanna say that im very excited about Microsoft new Copilot/scout. I just wanted to let everyone know that they should keep the original name to scout not copilot our at least use both. thanks

You can now request a GitHub Copilot code review through the REST and GraphQL APIs and set the review effort level for each request. Balanced is also now the default… The post Copilot code review: API support and new default effort level appeared first on The GitHub Blog.

The staged rollout of the stateless GitHub App installation token format, which began on April 27, 2026, is complete. By default, all newly minted GitHub App installation tokens will be… The post Stateless GitHub App installation tokens rolled out appeared first on The GitHub Blog.

Microsoft is advancing Azure cloud infrastructure with more efficient systems and Circular Centers that extend the useful life of datacenter hardware. The post Responsible infrastructure at hyperscale: Managing the full lifecycle of Azure hardware appeared first on Microsoft Azure Blog.

As of today, October 2, 2026, we have deprecated the following models across all GitHub Copilot experiences (including Copilot Chat, inline edits, ask and agent modes, and code completions). Model… The post Selected models in GitHub Copilot deprecated appeared first on The GitHub Blog.

A faster model does not always make an AI application faster. Latency also comes from output length, repeated prompt content, image and document processing, tool selection, connection setup, serial waits, and extra model requests. Comparing complete configurations, optimized software plus verified Priority Processing reduced median AI-path latency by 23% to 50%, depending on the workload, versus non-optimized Standard pay-as-you-go. This result does not isolate the effect of Priority Processing. Want the short version? Remove unnecessary output, visual processing, and tool definitions. Reuse stable prompt prefixes and app-managed MCP sessions. Remove serial waits and model rounds, then test Priority Processing on the work that remains. Measure correctness and reliability with latency. A fast wrong answer is not a performance improvement. Jump to the decision guide. In this article Results at a glance Four optimization themes Priority Processing results What did not clearly help Practical decision guide Reproduce or inspect the lab What we measured Each measurement represents one execution of a specific scenario, variant, and fixture. Each case produced 30 measured observations across five deterministic fixtures in a seeded randomized schedule. Treatment and control were paired when they ran against the same fixture and round in one execution. The analyzed dataset contains 2,040 measurements. The audit trail contains 2,160 benchmark executions recorded during the publication campaign, excluding cloud preflight checks; 120 earlier client-lifecycle runs were excluded after we corrected the timing boundary. Automated deterministic scorers checked required fields, facts, tool calls, and arguments. Failed and incorrect runs remain in reliability counts; we calculate latency percentiles only from correct completions and do not silently retry failures. AI-path latency starts immediately before a model request or an orchestrated model-and-tool workflow and stops when that response or workflow completes. Validation determines whether the result enters the latency analysis, but validation time is outside the primary timer. User-to-application networking, UI rendering, and preprocessing such as image resizing, PDF generation, text extraction, or OCR are also excluded. The benchmark used one Azure account with resources in East US 2. Runs executed one benchmark case at a time, except where a treatment explicitly tested internal request or tool fan-out. The combined benchmark used an Azure OpenAI Global Standard deployment, so East US 2 identifies the resource region, not a guarantee that inference processing remained there. The individual-optimization tests used gpt-4.1-mini; the combined benchmark used gpt-4.1, version 2025-04-14. This was not a load test, and percentages from the two result sets should not be combined. The fixtures were synthetic and deterministic. The combined benchmark reused the same fixture families, so it was not an independent replication on held-out production inputs. We used 5,000-sample bootstrap intervals for median effects; intervals were not adjusted for multiple comparisons, and p95 from 30 observations is descriptive. The lab report documents the protocol and limitations; the result ledger contains execution IDs, artifact versions, intervals, and reliability events. Results at a glance The table below summarizes the most decision-relevant one-lever results. Change testedWorkloadObserved median resultImportant qualificationGenerate a concise text answerText26.0% faster29/30 correct; one stream ended before completionGenerate concise JSONImage24.9% faster30/30 correctReuse a cacheable prompt prefixText / image14.9% / 23.6% fasterRequests had to report cached tokensUse low image detailImage17.8% fasterFine text and visual evidence must remain accurateSend already-extracted text instead of a PDFFile17.2% faster AI pathExtraction or OCR time was outside the timerProcess three independent pages concurrentlyFile56.8% fasterSame three model requests; only scheduling changedRequest two required functions in one model responseFunction tools28.2% fasterMainly one fewer model request, not just parallel handlersExpose five tools instead of 20Function tools16.8% fasterThe required tool must remain availableUse minimal tool descriptionsFunction tools14.4% fasterSelection and arguments must stay correctReuse an app-managed MCP sessionMCPA cold session was 34.1% slowerRequires safe lifecycle and recovery handlingAdd tool search to a 50-tool ToolboxToolbox / MCP43.0% slower p50Input tokens fell 26%; 30/30 vs 29/30 correct, with a lower descriptive p95 These are workload-specific findings, not service guarantees. A result was labelled faster only when its paired 95% interval for the median effect excluded zero. 1. Remove work the task does not need Generate only the required output The clearest supported text optimization was shortening the output contract. For text, requesting a compact answer reduced median latency from 2,078 ms to 1,537 ms, a 26.0% improvement among correct completions. For image extraction, concise JSON reduced the median from 1,646 ms to 1,237 ms, a 24.9% improvement with 30/30 correct completions. This does not mean every answer should be terse. It means the model should not generate content that the next application step discards. A UI card may require five fields. A routing step may require one enum. A tool planner may need only validated arguments. Define that contract explicitly, then verify that the shorter response still satisfies the product requirement. Reducing input is different. Removing 12 irrelevant history turns lowered the observed text median by 12.7%, but the paired 95% confidence interval included zero. That result was inconclusive for this small test. Removing irrelevant context can still reduce input-token cost, but this lab does not claim a proven latency improvement for that treatment. Use only the visual representation the task requires Low image detail was 17.8% faster than high detail for extracting invoice ID, total, and status. Low detail is not the same as resizing the source file. The full image is still sent, but detail: "low" asks the service to analyze a 512 x 512 representation instead of using high-resolution tiled inspection. See Configure image detail level. This can work well for large, clearly printed fields, but it can miss small text, handwriting, charts, or spatial evidence. Start low only when deterministic validation confirms that every required field remains accurate. Image resizing also lowered the median by 12.8%, but descriptive p95 increased from 5.1 seconds to 8.8 seconds. That does not invalidate the median result, but the slower tail-latency observations require further investigation. Local resize time was also outside the AI-path timer. For files, sending already-extracted text was 17.2% faster than native PDF input. The claim is intentionally narrow: extraction or OCR happened before the timer. Use text when the task depends only on textual facts. Keep native document processing when layout, signatures, charts, handwriting, or other visual evidence matters. A full-pipeline decision must include extraction cost and reliability. 2. Reuse work and connections Put repeated prompt content first Prompt caching does not store the model's answer. It temporarily reuses work the service already performed on the beginning of a long input. The first request is processed normally; later requests can reuse the matching prefix. For the gpt-4.1 models in this lab, an eligible request required at least 1,024 input tokens. The first 1,024 tokens had to match a recent request. The service does not cache request fields independently. It starts at the beginning and reuses matching content only until the first change. That is why request order matters. Here is a simplified Responses API request: { "model": "<deployment-name>", "instructions": "[REUSABLE] Stable system instructions, examples, and output rules", "input": [ { "type": "message", "role": "user", "content": [ { "type": "input_text", "text": "[REUSABLE] Reference content shared by many requests" }, { "type": "input_text", "text": "[CHANGES] The current user's question" } ] } ] } The reusable beginning can contain system instructions, examples, output rules, tool definitions, or shared reference text. Keep it identical and put it first. Put the current question, request ID, image, document, or other changing content afterward. If a timestamp or request ID appears at the beginning, requests differ immediately and the stable instructions that follow cannot form one long matching prefix. Warm-prefix caching reduced text median latency by 14.9% and image median latency by 23.6%. Average text time to first token fell from 991 ms to 602 ms. We verified the mechanism instead of assuming it worked. Roughly 93-100% of repeated requests reported a cache hit. Control requests changed a value at the beginning and reported no cached tokens. Put shared content first, put request-specific content last, and check cached_tokens in the response. Caching did not produce a clear median improvement for file or function-tool tasks in this run. Reusing prompt work matters less when document processing, tool selection, or another stage dominates. See Prompt caching for current eligibility and retention details. Avoid reconnecting to MCP for every task When the application is the MCP client, connection setup and tool discovery can be a meaningful part of the critical path. A reused session completed in 2,283 ms at p50. Opening a new session and discovering tools for every task raised p50 to 3,061 ms: the cold path was 34.1% slower than the reused path. Setup and discovery averaged 1,016 ms; the local tool itself remained below 5 ms. This is an application-lifecycle optimization, not a model optimization, and the result does not automatically apply to service-managed MCP. Reuse a compatible session and its discovered tool catalog across tasks, or use a bounded pool when one session cannot safely serve the expected concurrency. Scope reuse by identity and tenant, and design for expiry, reconnect, credential rotation, catalog refresh, health checks, and failure isolation. The repository includes the complete MCP connection helper. 3. Remove serial waits and unnecessary model requests Run independent page requests concurrently The largest supported one-lever effect came from processing three independent document pages concurrently. Both configurations made the same three model requests. The sequential version waited for one response before starting the next. The concurrent version started all three before waiting for their results. Median latency fell from 2,811 ms to 1,216 ms, a 56.8% improvement. This is a scheduling result. It applies only when requests are independent and model quota can support the burst. Production code still needs bounded concurrency, timeouts, and partial-failure handling. Remove an avoidable model round from function workflows The function-tool task needed both weather and local time: Slower: model -> weather -> model -> time -> model -> final answer Faster: model -> weather + time -> model -> final answer The faster design allowed one model response to request both functions. It reduced the workflow from three model requests to two and lowered p50 from 3,646 ms to 2,617 ms, a 28.2% improvement. The synthetic handlers completed in under 5 ms, so most of the benefit came from removing a model request. Running the handlers concurrently is a separate mechanism. For app-run functions: allow the model to request multiple calls; validate tool names and arguments; confirm that calls are independent and safe to overlap; run asynchronous I/O together; return one output for every original call ID; ask the model for the final answer after all required results arrive. parallel_tool_calls=True permits multiple calls but does not guarantee that the model selects every required tool. asyncio.gather overlaps asynchronous I/O; it does not make blocking synchronous code parallel. The 28.2% result applies to app-executed function tools. It should not be transferred to service-managed MCP or Foundry Agent Service without a separate benchmark and traces showing actual execution behavior. 4. Limit the tools available to each request Tool definitions are part of the model input. Even when the actual function runs in milliseconds, selection and final generation can take seconds. Reducing the active catalogue from 20 function tools to five lowered p50 by 16.8%. Using minimal descriptions lowered p50 by 14.4%. The useful design pattern is: route the request to a domain; expose only that domain's relevant tools; keep names, descriptions, and schemas concise but discriminative; validate selection and arguments, not token count alone. Other tool-schema treatments were inconclusive at this sample size. Exposing 50 tools, adding complex schemas, making descriptions ambiguous, and reordering definitions did not produce a statistically supported change in median latency. Some descriptive p95 values were slower, but 30 attempts are not enough to conclude that those treatments consistently damage tail latency. Toolbox can improve selection, but adds a search round Microsoft Foundry Toolbox tool search keeps a large tool catalog out of the initial prompt and discovers relevant tools when needed. In this synthetic 50-tool test, it reduced average input tokens by 26% and completed correctly 30/30 times versus 29/30 for direct MCP. However, the extra search round increased p50 from 2,528 ms to 3,614 ms - a 43.0% increase. This single test does not prove that Toolbox generally improves accuracy. It shows the trade-off: use tool search when catalog size, context pressure, or tool selection is the main problem. If first-response latency matters most and the application already knows the relevant subset, exposing that smaller subset directly can be faster. See Tool search and the Toolbox overview. 5. Test Priority Processing after software optimization Our first Priority Processing-labelled requests taught an important validation lesson: the selected model did not support the requested tier, and every response reported service_tier=default. We kept those observations in the audit trail but excluded them as Priority Processing evidence. Unlike the individual-optimization tests on gpt-4.1-mini, the combined benchmark used a supported gpt-4.1 deployment. Every successful Priority Processing response reported service_tier=priority. We compared: non-optimized Standard pay-as-you-go; optimized Standard pay-as-you-go; the same optimized setup with Priority Processing. WorkloadNon-optimized StandardOptimized StandardOptimized + Priority ProcessingCombined improvementText2,070 ms2,125 ms1,222 ms41.0% fasterImage2,872 ms2,234 ms1,448 ms49.6% fasterFile1,512 ms1,245 ms1,165 ms23.0% fasterFunction tools3,817 ms2,824 ms2,393 ms37.3% faster Every value is median AI-path latency. The combined improvement compares optimized software plus Priority Processing with non-optimized Standard. Software alone clearly improved the image, file, and function-tool workloads. The optimized text configuration produced an inconclusive result on gpt-4.1. Adding Priority Processing to the optimized setup lowered observed p50 in all four workloads. The paired interval excluded zero for text and image, but crossed zero for file and function tools; the incremental effect was therefore inconclusive for those two workloads. Standard completed correctly 240/240 times. Priority Processing completed correctly 119/120 times, with one function-tool failure. For file and function-tool workloads, descriptive p95 was slower under Priority Processing than under optimized Standard in this run. With 30 attempts per arm, that is a reason to gather more tail observations before setting an SLO, not a firm tail-latency conclusion. Priority Processing is pay-as-you-go at its own rate. Provisioned Throughput reserves dedicated capacity measured in PTUs; it was outside this comparison. We did not calculate currency cost, so evaluate current regional pricing separately. Review the current deployment categories and Priority Processing documentation before selecting a processing option. What did not produce a clear median improvement Negative and inconclusive findings are part of the result: gpt-4.1-nano was not consistently faster than gpt-4.1-mini; it was 25.0% slower for the tested image task; removing 12 irrelevant text-history turns was inconclusive for latency; recreating the SDK client was inconclusive; selecting one PDF page instead of three was inconclusive; prompt caching was inconclusive for the tested file and function-tool tasks; many-parameter and nested schemas, ambiguous descriptions, and reordered tool definitions were inconclusive. These findings do not prove that the changes never help. They show that model names, token counts, and architectural intuition are not performance evidence. Test the real task, score correctness, retain failures, and identify which stage actually dominates. A practical decision guide Likely source of delayWhat to testWhat must remain trueLong generated responsesRequest only the required outputThe answer remains complete and correctRepeated long prompt contentMove stable content first and keep it identicalResponses report cached tokensImage processingTry low detailFine text and required visual evidence remain accurateDocument representationCompare native PDF with extracted textExtraction time is included and visual evidence is preserved when neededIndependent page requestsRun them concurrentlyRequests are independent and quota supports the burstExtra model rounds between toolsRequest required functions in one model responseThe same functions and arguments are selectedSlow independent app-run functionsOverlap asynchronous I/OSide effects, quotas, timeouts, and failures are safeLarge static tool surfaceRoute to a smaller relevant catalogueThe correct tool remains availableLarge dynamic catalogueTest Toolbox tool searchToken and selection benefits justify the search roundRepeated MCP setupReuse the app-managed sessionAuthentication, expiry, reconnect, and isolation remain safeProvider processing timeTest Priority ProcessingReturned tier, p50, p95, reliability, quality, cost, and residency meet the goal Use the following sequence for each experiment: define what a correct answer must contain; name the timer's exact start and stop; pair control and treatment on representative fixtures; randomize which one runs first; retain failures in the reliability result; calculate latency only from correct completions; test compatible winners together instead of adding isolated percentages. Reproduce or inspect the lab The AI response performance benchmark repository contains the benchmark implementation, Terraform environment, deterministic fixtures, raw-result processing, and reports. Follow the repository README to configure the Azure environment and run the included smoke, one-lever, and combined benchmark profiles. Start with the smoke profile before paid benchmark rounds. Use synthetic or approved data, confirm quota and expected cost, and replace the included fixtures with examples that represent the production workload. The repository also includes: an AI response performance testing guide; the full lab report; the auditable publication result ledger; an AI response performance Copilot skill for applying the method to another repository. Start with the real task: define correctness, measure each stage, remove avoidable work, and then test the platform options that target the time still left in the critical path.

Learn three ways to get noticed and grow your career as AI reshapes how developers build software. The post AI is rewriting the developer career ladder. Here’s how to stand out. appeared first on The GitHub Blog.

You can now read more of the GitHub Advisory Database directly from the GraphQL API without falling back to the REST API. The SecurityAdvisory object gained five new fields: cveId:… The post New fields for SecurityAdvisory GraphQL API appeared first on The GitHub Blog.

You can now read, add, and edit comments on repository security advisories using the REST API, including advisories created from private vulnerability reports. Until now, the discussion on an advisory… The post Repository security advisory comments API in public preview appeared first on The GitHub Blog.

You can now post confidential comments on repository security advisories. Confidential comments are visible only to people with write access to the repository, so you can discuss a report with… The post Confidential comments on repository security advisories appeared first on The GitHub Blog.

Background Your Terraform workflow already manages your Azure infrastructure but deploying hosted agents still requires manual SDK calls or REST API scripts. This post shows you how to bring agent deployments into your existing IaC pipeline using the AzAPI provider, so your entire Foundry stack can be versioned, reviewed, and deployed together. For this post we will focus on leveraging Foundry Hosted Agents. At a high level hosted agents will abstract the overhead of managing your agents compute. Conceptually, think of taking the compute today, that might be in Azure Container Apps (ACA) or Azure Functions and moving it into Foundry. For more information can check out my previous blog on this topic. In this example Foundry runs the agent code on managed compute from a container image. For this specific example we need to use Azure Container Registry to house our code artifact. If wanting to deploy directly from source refer to my previous blog Deploying Foundry Hosted Agents from Source Why an Infrastructure as Code Approach? Hosted agents today in Foundry support SDK and REST API deployments, why should we look at leveraging an IaC provider to handle our agents today? Many organizations subscribe to an IaC strategy for managing their Azure Resources. A hosted agent, at its core, is configuring and allocating infrastructure resources behind Foundry. This would be similar to how we configure plan sizes for products like App Services. Additionally, anything defined by IaC makes it easier to version the configuration in source control and incorporate it into repeatable CI/CD pipelines. Production workflows should also account for remote state, approval controls, and image-version promotion. Another added benefit for anything under IaC is the ability to apply custom policies, Azure or otherwise, over the codebase. Prerequisites An Azure subscription with permission to create resources and role assignments. Access to a region and model deployment with sufficient quota for Foundry Hosted Agents. Azure CLI, Terraform, Git, and Docker installed. Docker must support building linux/amd64 images. Permission to push images to Azure Container Registry and create agents in the Foundry project. The provided sample creates or configures the supporting Azure Container Registry, Foundry account and project, model deployment, managed identity, project connection, and hosted-agent deployment. Hosted agents require a Linux AMD64 (linux/amd64) container image. When building from an ARM-based workstation, including Apple Silicon, explicitly target linux/amd64 and ensure Docker cross-platform emulation is available. See Microsoft’s hosted-agent container requirements. docker build --platform linux/amd64 -t <registry-name>.azurecr.io/<image-name>:<tag> To get started quickly I have a repository w/ all the prerequisites and reviewed code at simple-hosted-agent-deploy-azapi Deploy the Sample To deploy the sample: Clone the repository and reopen it in the included development container. Authenticate to Azure and select the target subscription. Copy and update the example Terraform variable files with your environment-specific values. Run the included deployment script to provision the base resources, build and push the container image, and create the hosted agent. Confirm that the generated agent version reaches an active state before invoking it. Refer to the repository README for the current commands, configuration values, and cleanup steps. Process Overview Let’s level set on what our end-to-end process may look like. In many large organizations, the agent deployment process could be decoupled from the Foundry base architecture. Components such as the Foundry account, project, connections, and model may be controlled by a centralized team. These shared components often follow a different deployment lifecycle from an individual agent. A development team may own the code. We need the code to deploy the hosted agent. Quite the chicken-and-egg problem. So let’s break it down from a day 1 perspective: Deploy Foundry Base Architecture Foundry Account Foundry Project Model Project Connection Application Insights Build and Push code to Azure Container Registry Deploy the hosted agent pointed to the image defined in Azure Container Registry For this example, I assume that Azure Container Registry is managed outside the Foundry lifecycle because many organizations prefer to consolidate container images into a smaller number of shared registries. For illustration purposes, the provided example includes the registry deployment. Day n perspective would potentially look like: Build and Push code to Azure Container Registry Deploy the hosted agent pointed to the image defined in Azure Container Registry Updating the hosted-agent configuration creates a new agent version under the existing logical agent. Foundry manages the version history, while Terraform manages the logical agent configuration represented by the azapi_data_plane_resource. After each deployment, confirm that the new version reaches an active state before directing workloads to it. Technical Details At this time, let’s take a minute and discuss some of the technical details around how the hosted agent is created in Foundry. The Foundry project and its connections are Azure Resource Manager control-plane resources. The logical agent is created through the Foundry project’s data-plane API, while Foundry manages the supporting deployment resources required to host it. This is in contrast to services represented directly as Azure Resource Manager resources, such as App Service (Microsoft.Web/sites) and Azure Container Apps (Microsoft.App/containerApps). Here is a visual that depicts the data plane vs control plane objects: The Foundry project is the agent’s logical parent and provides the data-plane endpoint through which the agent is created. The project itself is deployed as the Azure Resource Manager resource Microsoft.CognitiveServices/accounts/projects Foundry connections can be deployed as Microsoft.CognitiveServices/accounts/projects/connections. In this case, the connection is used for connecting and authenticating to Azure Container Registry. At this point, the project and connection resources can be deployed through AzAPI or Bicep. The next step requires a data-plane call. For Terraform deployments, this operation can be managed declaratively with the AzAPI provider’s azapi_data_plane_resource. Foundry also supports agent deployment through its SDKs and REST API. azapi_data_plane_resource The AzAPI provider’s azapi_data_plane_resource resource is the key component for deploying a hosted agent in Foundry Agent Service through Terraform. Per official MS Learn documentation: Some Azure services expose a separate data plane API—a service-specific HTTPS endpoint where you interact directly with the service rather than through ARM. Examples include the Key Vault secrets API at {vaultName}.vault.azure.net, the Azure AI Search index API at {searchServiceName}.search.windows.net, and the Synapse workspace pipeline API at {workspaceName}.dev.azuresynapse.net. azapi_data_plane_resource bridges this gap by enabling Terraform to manage resources on these data plane endpoints using the same AzAPI provider authentication and lifecycle model. https://learn.microsoft.com/en-us/azure/developer/terraform/concept-azapi-data-plane-framework So how would a terraform implementation for this work? First let’s create the appropriate resource type, name and parent reference, in this case the Foundry Project: resource "azapi_data_plane_resource" "hosted_agent" { type = "Microsoft.Foundry/agents@v1" name = var.agent_name # AzAPI data-plane parents use the endpoint host/path without a URI scheme. parent_id = trimprefix(var.project_endpoint, "https://") …} Now we need to pass in the dedicated parameters as part of the body. To find these parameters refer to the Foundry REST API documentation. body = { name = var.agent_name definition = { kind = "hosted" container_configuration = { image = var.image_uri } cpu = var.cpu memory = var.memory protocol_versions = [ { # The hosted container must implement this Foundry Responses contract. protocol = "responses" version = "2.0.0" } ] environment_variables = merge(var.environment_variables, { AZURE_AI_MODEL_DEPLOYMENT_NAME = var.model_deployment_name }) rai_config = { # Hosted agents require the full policy ARM ID; model deployments use its name. rai_policy_name = var.rai_policy_id } } } For the entire reusable module check out https://github.com/JFolberth/simple-hosted-agent-deploy-azapi/tree/main/simple_agent/azure/infra/modules/hosted_agent Conclusion Hosted Agents in Foundry Agent Service provides a way to run custom agent code on Foundry-managed compute while reducing the operational overhead of managing the underlying hosting infrastructure. By using the AzAPI provider’s azapi_data_plane_resource, teams can incorporate the logical agent deployment into an existing Terraform workflow alongside the Foundry project, model, connections, identity, and container registry resources it depends on. This approach is especially useful when platform and application responsibilities are separated. A platform team can manage the shared Foundry and Azure infrastructure, while application teams independently build, publish, and deploy new versions of their agent container. With the appropriate remote state, access controls, image-versioning strategy, and deployment validation in place, the same pattern can be extended into a repeatable CI/CD workflow for both initial deployment and ongoing agent updates. The linked sample demonstrates this end-to-end pattern, from provisioning the supporting Azure resources and publishing the container image through creating the hosted agent with Terraform. Use it as a starting point, then adapt its state management, access controls, artifact promotion, and validation steps to meet your organization’s production requirements.

A voice agent has to do more than hear a request and produce a reply. It has to keep the interaction moving while it listens, reasons, uses tools, and speaks. A delay at either end can turn a conversation into a series of awkward pauses. Today, we’re introducing three new Microsoft AI (MAI) models in Microsoft Foundry: MAI-Transcribe-2-Streaming, which turns live speech into text as it arrives MAI-Voice-2.1, our most expressive multilingual text-to-speech model yet MAI-Voice-2.1-Flash, optimized for responsive, high-volume voice applications. Together, they give developers more choice in how to build natural voice experiences. MAI-Transcribe-2-Streaming: Understand speech while it’s happening Earlier this month, we introduced MAI-Transcribe-2, raising the bar for transcription accuracy, speed, and cost efficiency. It ranked #1 on FLEURS for multilingual accuracy and #1 on the Artificial Analysis accuracy × latency Pareto frontier, giving developers high-quality transcription without trading away speed. With MAI-Transcribe-2-Streaming, we’re extending that leadership to real-time conversations. Instead of waiting for someone to finish speaking before returning text, MAI-Transcribe-2-Streaming transcribes continuously across 60 languages, with automatic language detection. It produces its first hypotheses, known as partials, within the low hundreds of milliseconds of receiving audio, then refines them as more context arrives and commits a stable transcript once the utterance ends. That distinction matters when an application needs to act while someone is speaking. A customer-service agent can begin identifying a caller’s request before the sentence is complete. A voice assistant can start reasoning or preparing a tool call sooner. A live transcription experience can surface words almost as quickly as they are spoken. And the proof is in the results. MAI-Transcribe-2-Streaming debuts at #1 for accuracy on both partial and final transcripts on the Artificial Analysis leaderboard. In most cases, words appear in the transcript as early as 320 milliseconds after they’re spoken, while the closest competition takes more than 500 milliseconds. Together, MAI-Transcribe-2 and MAI-Transcribe-2-Streaming give developers a choice depending on the experience they’re building: MAI-Transcribe-2 for when you need high-quality transcription with capabilities like speaker diarization and word-level timestamps MAI-Transcribe-2-Streaming for when your application needs to understand and act on speech as it happens. MAI-Voice-2.1: One voice across languages The other half of a voice experience is how it sounds. MAI-Voice-2.1 generates natural, expressive speech across 23 languages, with a consistent voice identity across supported languages. A tutoring app, for example, can move from an English explanation to a Mandarin exercise without sounding as though a different teacher has taken over. A multilingual assistant can respond in the user’s language while retaining the voice people recognize. The model adapts its pronunciation and delivery to the language rather than carrying one accent across every response. Choose MAI-Voice-2.1 when voice quality is central to the experience: interactive learning, branded assistants, narration, or content where expression and consistency matter. MAI-Voice-2.1-Flash: Responsive speech at scale MAI-Voice-2.1-Flash supports the same languages and cross-language voice identities, but is optimized for workloads where response time and volume are critical. In the supplied comparison, Flash is 55% faster and 60% less expensive than competing models in its class*. That makes Flash a natural fit for live support agents, voice assistants, and other applications that generate spoken responses throughout the day. Developers can choose MAI-Voice-2.1 when expressive fidelity is the priority, or Flash when they need to balance natural speech with responsiveness and cost at scale. Put the models to work together These models really come to life when applied together to build expressive voice agents. Consider a customer calling to change a reservation. MAI-Transcribe-2-Streaming begins returning text while the customer is still speaking. The agent can identify the emerging request, check availability, and prepare an action. Once it has an answer, MAI-Voice-2.1-Flash delivers the response in natural speech. Saving time in listening and speaking gives the agent more room to reason and use tools while keeping the exchange conversational. Developers can apply the same pattern to: Customer-service agents that follow a request as it unfolds, retrieve relevant information, and respond aloud. Multilingual assistants that recognize the spoken language and reply in a consistent voice across supported languages. Interactive learning experiences that move between languages, speakers, and conversational exercises. Live captions and voice-driven interfaces that surface words as they arrive instead of waiting for a completed recording. Start building All three models are available in Microsoft Foundry through Azure Speech and with direct API access through Microsoft Foundry: - MAI-Transcribe-2-Streaming is available at an introductory price of $0.54 per hour of audio through the end of the year. - MAI-Voice-2.1 is available at $22 per 1M characters - MAI-Voice-2.1 Flash is available at $15 per 1M characters We’re also excited to make these models available through additional platforms, including OpenRouter, Vercel, and LiveKit, giving developers more ways to discover, access, and build with MAI models. *Source: Models | ElevenLabs Documentation

Today, we're announcing the general availability of the Foundry IQ integration with Microsoft Copilot Studio. Users can connect a Foundry IQ knowledge base to an agent in Copilot Studio, giving the agent access to grounded enterprise knowledge and citations. Additionally, for organizations that require zero public network exposure, the GA release includes full private connectivity through Azure Private Link. Bring enterprise knowledge into your Copilot Studio agent Enterprise data is spread across systems, governed by different access policies, and often available only through private networks. Connecting an agent to that data must fit the organization's identity, access, encryption, and networking requirements. Foundry IQ provides a managed knowledge layer for agents, enabling Copilot Studio makers to connect to a single knowledge base that handles enterprise data access, retrieval, ranking, and permissions without requiring each source to be configured separately. With the generally available integration, makers can: Connect to a Foundry IQ knowledge base they are authorized to access. Authenticate with an API key, client certificate, service principal, or Microsoft Entra ID integrated authentication. Use Azure Private Link and Power Platform VNet support to connect without enabling public access on the underlying Azure AI Search service. Work within established enterprise controls for authentication, permissions, encryption, and network isolation. Inspect the activity trace to confirm that Foundry IQ performed retrieval and review the items returned to the agent. Connect through a virtual network (VNet) Private connectivity combines two capabilities: Azure Private Link for Foundry IQ, gives the service behind Foundry IQ a private IP address. Power Platform VNet support routes supported Copilot Studio connection traffic through delegated subnets. 1. Configure the private endpoint On the Azure AI Search service that backs your Foundry IQ knowledge base: Open Networking and create a private endpoint for the Foundry IQ sub resource. Select the virtual network and subnet that will host the endpoint. Enable private DNS integration with privatelink.search.windows.net. Validate private connectivity, then disable public network access. Note: Clients continue to use https://<service-name>.search.windows.net; private DNS resolves the address to the service's private IP. 2. Enable Power Platform VNet support Create dedicated subnets in the Azure regions required for your Power Platform environment and delegate them to: "Microsoft.PowerPlatform/enterprisePolicies" Keep the Foundry IQ private endpoint in a separate subnet. If it is in another virtual network, configure peering or another private route. Ensure private DNS resolution and HTTPS traffic to the endpoint are allowed. Create a subnet-injection enterprise policy for the delegated subnets, then assign it in the Power Platform admin center under Security > Data and privacy > Azure Virtual Network policies. Confirm that the environment's history shows a Succeeded status. 3. Connect Foundry IQ in Copilot Studio Open the agent and select Build. Select Tools > Foundry IQ > Create new connection. Choose an authentication method and enter the standard Azure AI Search endpoint. Create the connection, select a knowledge base, and add it to the agent. Give the connection a clear name and description, then save the agent. Note: Use Microsoft Entra ID authentication when it fits your organization's requirements and apply least privilege for every authentication method. 4. Validate before publishing Ask a question that the knowledge base should answer, then verify: The response contains the expected grounding and citations. The activity trace shows a Foundry IQ retrieval step. Users with different permissions receive only authorized content. Network traffic reaches Azure AI Search through the private endpoint. The service isn't reachable through its public endpoint. If the answers aren't what you expect, review the knowledge base sources, retrieval instructions, and ranking settings in Foundry IQ. VIDEO Get started Connect to Foundry IQ from an agent in Microsoft Copilot Studio (Preview) Learn about Foundry IQ Set up virtual network support for Power Platform Create a private endpoint for Azure AI Search Read the preview announcement Foundry IQ in Copilot Studio is generally available today, giving organizations a direct way to ground agents in enterprise knowledge while retaining the security controls required for production.

Most agents are still waiting in a chat window. They may be capable of classifying an incident, finding the right documentation, or recommending an owner - but nothing happens until someone remembers to ask. The hard part is no longer always the reasoning. It is noticing that work has arrived, invoking the agent securely, and keeping enough history to understand what happened. Routines in Microsoft Foundry close that gap. A routine connects a trigger - such as a schedule, timer, GitHub issue, or Microsoft Teams message - to an agent action. Microsoft Foundry queues the invocation, runs the agent, and stores a run record for later inspection. In this post, we will build an event-driven routine for a familiar developer workflow: When someone opens a GitHub issue, invoke a triage agent immediately - without waiting for a person to copy the issue into a chat. Along the way, we will look at the architecture, create the routine with the Azure Developer CLI (azd), test it, inspect its run history, and make an explicit identity decision before putting it into production. From conversational agents to event-driven agents A chat-first agent follows a request-response pattern: A user opens an interface. The user provides a prompt. The agent performs work. The interaction ends or waits for another prompt. An event-driven agent starts differently. Work in an external system becomes the prompt. A newly opened issue, for example, already contains useful context: its title, description, author, repository, labels, and timestamps. A routine can receive that event through an authorized connection and invoke an agent while the context is still fresh. That changes the agent's role. It is no longer only a place people go for answers. It becomes a participant in an operational workflow. The routine does not replace the agent. It supplies the managed automation around it: Trigger: Defines when work starts. Connection: Authenticates the event source. Action: Identifies the agent and invocation protocol. Dispatch identity: Determines whose permissions are used when the agent and its tools run. Run history: Records executions so operators can inspect outcomes. This separation is useful. The agent owns the reasoning; the routine owns when and how that reasoning begins. The scenario: triage every new GitHub issue Our example assumes that a triage agent is already deployed in a Microsoft Foundry project. When an issue opens, the agent should: Summarize the issue in two or three sentences. Classify it as a bug, feature request, documentation issue, or support question. Estimate severity and explain the evidence. Recommend an owner or team. Identify missing reproduction details. Produce a proposed response for a maintainer to review. Keeping a human review step is intentional. Event-driven does not have to mean unrestricted autonomy. A routine can automate the expensive first pass while a maintainer remains responsible for labels, assignments, and public responses. Prerequisites You need: An active Microsoft Foundry project. The Foundry User role or higher on the project. A deployed prompt agent or hosted agent. Workflow agents are not currently supported by routines. The Azure Developer CLI. A GitHub connection authorized in the Foundry project. The routines extension for azd. Install the extension and confirm that the routine commands are available: azd extension install azure.ai.routines azd ai routine --help Set the project endpoint through your active azd environment or pass it explicitly to each command: azd env set AZURE_AI_PROJECT_ENDPOINT \ "https://<account>.services.ai.azure.com/api/projects/<project>" The agent must exist before you attach a routine to it. A routine references an agent; it does not deploy one. Create the GitHub issue routine The following command creates an enabled routine named triage-on-open. Replace the placeholders with the connection and repository details from your environment: azd ai routine create triage-on-open \ --trigger github-issue \ --connection-id "<workspace-connection-id>" \ --owner "<github-owner>" \ --repository "<github-repository>" \ --issue-event opened \ --action agent-invoke \ --agent-name "triage-agent" \ --description "Triage every newly opened GitHub issue" There are two important type translations in this command: The CLI alias github-issue represents the routine trigger type github_issue. The CLI alias agent-invoke invokes the agent through the Invocations API. If your agent uses the Responses API instead, use --action agent-response. Choose the protocol that matches the deployed agent rather than treating the two actions as interchangeable. For automation that belongs in source control, define the routine as an azure.ai.routine service in azure.yaml. This makes the relationship between the agent and its trigger reproducible across environments: services: triage-agent: host: azure.ai.agent project: ./agent triage-on-open: host: azure.ai.routine uses: - triage-agent description: Triage every newly opened GitHub issue enabled: true triggers: issue-opened: type: github_issue connection_id: ${GITHUB_CONNECTION_ID} owner: ${GITHUB_OWNER} repository: ${GITHUB_REPOSITORY} issue_event: opened action: type: invoke_agent_invocations_api agent_name: triage-agent Deploy the routine after the target agent: azd deploy triage-on-open --no-prompt The uses relationship tells azd to order the agent before the routine. Deployment is idempotent: redeploying updates the named routine instead of creating duplicates. Give the agent a clear triage contract Automation magnifies ambiguity. A vague instruction that is merely inconvenient in a chat can produce inconsistent work every time an event fires. Give the triage agent a bounded contract such as: You are the first-pass triage agent for this repository. For each newly opened issue: 1. Summarize the reported behavior without adding facts. 2. Classify it as bug, feature, documentation, or support. 3. Assign severity only when the issue contains supporting evidence. 4. List missing information needed to reproduce or route the issue. 5. Recommend an owner from the approved ownership map. 6. Draft a response, but do not publish, close, label, or assign the issue. Return structured JSON that matches the triage schema. A useful output contract might look like this: { "summary": "The CLI exits when a project endpoint contains an explicit port.", "category": "bug", "severity": { "level": "medium", "reason": "The issue blocks routine creation but has a documented workaround." }, "missing_information": [ "Azure Developer CLI version", "Redacted project endpoint shape", "Full error output" ], "recommended_owner": "developer-experience", "proposed_response": "Thanks for the report. Could you share..." } Structured output gives downstream systems something predictable to validate. It also makes evaluation easier: you can test category accuracy, required-field completeness, unsupported severity claims, and whether the agent attempted a prohibited action. Test before waiting for a real event Start by checking that Foundry stored the routine you intended: azd ai routine show triage-on-open --output json Confirm: The routine is enabled. The trigger watches the correct owner and repository. issue_event is opened. The action references the intended agent. The connection ID belongs to the expected Foundry project. You can manually dispatch a routine while testing: azd ai routine dispatch triage-on-open \ --input '{"test":true,"issue":{"number":123,"title":"Test triage event"}}' The manual input is a one-time override for that dispatch. It does not replace the event payload or modify the routine's stored configuration. Inspect recent executions: azd ai routine run list triage-on-open --top 20 Then open a test issue in the watched repository and inspect the run list again. A production test should verify more than "the agent ran." Check that the correct event started the run, the agent received enough context, tool calls used the intended identity, the output matched the schema, and prohibited actions did not occur. Choose the dispatch identity deliberately Every routine uses the agent identity by default. This is usually the better fit for unattended automation because access belongs to the agent rather than to an employee's account. Use agent identity when the agent's tools authenticate with managed identity, workload identity, or keys and the agent has been granted only the permissions required for the task. Some tools require delegated user access. In that case, you can create the routine with creator identity. Creator identity means the Microsoft Entra identity of the person or service principal that creates the routine—not the agent publisher, connection creator, latest editor, or user who caused an event. This distinction has operational consequences: If the creator loses access or consent, delegated tool calls can fail. Recreating the routine as another principal changes the delegated creator identity. The event connection identity is separate from the identity used to dispatch the agent. Dispatch identity is a creation-time decision. To switch an existing routine between agent and creator identity, delete and recreate it. For a GitHub triage flow, a strong starting design is: Use a narrowly scoped project connection to receive issue events. Use agent identity for Foundry and Azure resources. Keep repository-changing actions disabled until evaluation demonstrates reliable behavior. Require human approval before posting, assigning, labeling, or closing. Identity is not a deployment detail. It is part of the automation's behavior and should be reviewed with the same care as the prompt and tool list. Make failure visible An event-driven agent can fail even when its reasoning is sound. The connection might expire. The agent might receive an unexpected payload. A tool might lose permission. The output might violate its schema. Monitor the workflow at four boundaries: Trigger: Did the expected event fire the routine exactly once? Invocation: Did Foundry invoke the intended agent and protocol? Tools: Did tool calls succeed with the intended identity and scope? Outcome: Did the output satisfy the triage contract? Use azd ai routine run list for routine execution history and your agent's Foundry observability data for traces, tool calls, latency, and failures. Preserve representative failures as evaluation cases instead of fixing each incident only in the prompt. Also design for duplicate delivery. Before taking a repository-changing action, check whether the issue and event have already been processed. Idempotency matters more once an agent can act without a person initiating each run. Know the current boundaries Before adopting routines for a regulated or business-critical workload, review the current service constraints: Routines support prompt agents and hosted agents, but not workflow agents. A recurring schedule has a minimum interval of five minutes. GitHub issue triggers support opened and closed issue events. Routines inherit the project's networking configuration and can work with virtual-network-secured projects. Routines do not currently support customer-managed key encryption. Regional availability has exceptions; verify your project's region in the current documentation. These boundaries can change. Treat the routines documentation as the source of truth when moving from a tutorial to production. What changes when agents stop waiting? The most interesting part of this design is not the GitHub trigger. It is the change in operating model. The agent begins work because the world changed, not because someone opened a chat. That makes trigger scope, identity, output contracts, run history, evaluation, and human approval part of the agent design—not infrastructure to consider later. Once the triage routine is working, the same pattern can support: A Teams message that starts support classification. A nightly backlog review. A one-time release-readiness check. A scheduled compliance summary. A hosted agent that uses the reminder tool to resume the same conversation after a long-running task. Start with one bounded event and one reversible outcome. Measure what the agent does, not merely whether it ran. Then expand its permissions only as evidence earns that autonomy. Try it next Choose the path that matches where you are: Build: Follow the Microsoft Foundry routines documentation and connect one existing agent to a schedule or event. Harden: Review dispatch identity, connection scope, idempotency, output validation, and human approval before enabling repository-changing tools. Extend: Add the reminder tool to a hosted agent that needs to continue work later. Explore: Open the Microsoft Foundry portal to inspect your project, agents, and routine runs. Your agent already knows how to do useful work. The next step is teaching it when that work should begin.

The macOS 14 runner image will be retired on November 2, 2026. To raise awareness of the upcoming removal, jobs using macOS 14 will temporarily fail during the following scheduled… The post GitHub Actions: macOS 14 runner image retirement appeared first on The GitHub Blog.

Private vulnerability reporting now applies daily rate limits to new reports. This helps protect you from bulk and automated submissions, while legitimate researchers can still reach you. Open source maintainers… The post Rate limits for private vulnerability reports appeared first on The GitHub Blog.

Private vulnerability reports can now use a structured form that asks reporters for the details you need to assess a vulnerability, including a reproducible proof of concept. A single free-text… The post Structured forms for private vulnerability reports appeared first on The GitHub Blog.

Dynamic workflows are now available in Copilot CLI, the GitHub Copilot app, and the GitHub Copilot SDK. These let you define an orchestration in code to get the reliability and… The post Dynamic workflows in Copilot CLI and the Copilot app appeared first on The GitHub Blog.

You can now find an ACCESSIBILITY.md file in your repository’s root, the .github/ directory, or the docs/ directory highlighted on the repository overview. You can also add or propose an… The post Accessibility statements highlighted on repository overview appeared first on The GitHub Blog.

This changelog covers VS Code v1.136 through v1.140, shipped throughout September 2026. September’s releases streamline agent-driven development from implementation through pull request merge. Automations handle repeatable tasks, agent merge helps… The post GitHub Copilot in VS Code, September 2026 releases appeared first on The GitHub Blog.

Computer use is now available in public preview in GitHub Copilot CLI and the GitHub Copilot app on macOS and Windows. Copilot can interact with desktop applications on your behalf… The post GitHub Copilot can now interact with desktop apps with computer use appeared first on The GitHub Blog.

As previously announced, checks, workflow runs, and statuses are now governed by the same GitHub Actions retention setting that controls how long artifacts and logs are kept. These records are… The post Actions retention now covers checks, runs, and statuses appeared first on The GitHub Blog.

Code coverage uploads from the GitHub Code Quality upload-code-coverage action no longer fail CI when you push a branch that doesn’t yet have an open pull request. Previously, the coverage… The post Code coverage uploads no longer fail CI for new branches appeared first on The GitHub Blog.

Weekly scheduled scans for code scanning default setup and GitHub Code Quality now start only after a push or pull request triggers an analysis, rather than counting every kind of… The post Scheduled code scanning skips inactive repositories appeared first on The GitHub Blog.

The new dashboard experience, previously available as a feature preview, is now the default view for everyone. The redesigned dashboard helps you focus on the work that matters most and… The post New dashboard experience now the default appeared first on The GitHub Blog.

You can now use the generally available GitHub async merge API to merge individual or stacked pull requests, add pull requests to a merge queue, or merge pull requests directly.… The post GitHub async merge API generally available appeared first on The GitHub Blog.

From verifying AI-written code to securing npm dependencies, these are the sessions I’m building my Universe agenda around. The post 10 technical talks I’m excited about at GitHub Universe 2026 appeared first on The GitHub Blog.

GitHub Actions Runner Controller 0.15.0 includes reliability, scalability, and observability improvements for runner scale sets. These updates help you operate larger runner fleets with fewer disruptions during upgrades and Kubernetes… The post Actions Runner Controller release 0.15.0 appeared first on The GitHub Blog.

A Microsoft Foundry handover story The infrastructure team has finished the AI landing zone. The Microsoft Foundry project exists. The prompt agent is already created, connected to its model, and configured with the tools or connections it needs. That is an important milestone, but it is not the same as saying the application team is ready to use it. At handover, the question should be simple: Can the application team call the existing Foundry project endpoint and the named agent, using the expected identity, and get useful evidence that the agent can reach its configured services? The application team should not be handed a test that creates another LLM client or rebuilds integrations locally. That may prove a script works, but it does not prove the handed-over agent is ready. Handover Gap The challenge with poor handover In many projects, handover sounds like this: "The agent is deployed." But the receiving team hears a different message: "The platform is ready for application integration." Those two statements are not always the same. As a Senior Cloud Solution Architect, this is where I usually see confusion begin. The portal demo may work. The resources may exist. The model may be attached. But the application team still needs to know whether the runtime contract works from their side of the boundary. Without a clear handover check, teams can validate the wrong thing. A developer may write a local test that calls a model directly, connects to search directly, or uses a different identity path. The test may pass, but it has bypassed the actual Foundry prompt agent. That creates a dangerous result: a green test for the wrong architecture. What a good handover should prove A useful handover does not need to test every business scenario. It should prove the basics that matter before the application depends on the agent: The application identity can authenticate without secrets. The Foundry project endpoint is reachable. The named prompt agent can be found. The agent can be invoked through the intended boundary. The agent can use the services that are part of its configured contract. The result is recorded clearly as PASS, FAIL, or SKIP. The better pattern - Agent Acceptance Gateway The handover should feel like a relay race, not a treasure hunt. The infrastructure team hands over the project endpoint, the agent name, and the identity expectations. The application team runs a small passwordless validator from its side. The validator does not recreate the solution. It checks the existing agent. That distinction matters. The validator is not a second implementation of the agent, and it does not connect directly to the model, Azure AI Search, Azure Cosmos DB, or Azure Blob Storage. It approaches the solution exactly as the application will: through the handed-over Microsoft Foundry project endpoint and the named agent. The infrastructure team owns the platform-side readiness. It confirms that the project and agent exist, the agent version is the intended one, required tools and connections are configured, network paths are available, and the application's managed identity has the minimum RBAC permissions needed to invoke the agent. The application team owns the consumer-side acceptance check. It runs the validator from the real application environment using ManagedIdentityCredential, not a developer login or stored secret. This proves the runtime identity, DNS, routing, private endpoint configuration, and authorization path that production will use. Validation flow The validator follows the same six checks as the handover checklist. Requests travel through the Foundry project and named agent; the validator never connects directly to Search, Cosmos DB, or Blob Storage. The service probes should use known, non-sensitive test data. Avoid prompts that return secrets, personal data, or entire documents merely to prove connectivity. What the validator could look like The following Python is intentionally illustrative. It shows the responsibilities and control flow rather than prescribing exact SDK methods, which can change between package versions. Adapt the agent lookup and invocation calls to the SDK and agent type your organization has standardized. # Illustrative flow only: align method names with the SDK version you use. import os from azure.identity import ManagedIdentityCredential from azure.ai.projects import AIProjectClient from dotenv import load_dotenv load_dotenv() # Local convenience; Azure supplies the same values as app settings. def validate_agent_handover(project_endpoint: str, agent_name: str) -> dict: """Check the handed-over agent without rebuilding its integrations.""" client_id = os.getenv("AZURE_CLIENT_ID") credential = ( ManagedIdentityCredential(client_id=client_id) if client_id else ManagedIdentityCredential() ) results = { "identity": "SKIP", "endpoint": "SKIP", "agent": "SKIP", "invocation": "SKIP", "services": "SKIP", "report": "SKIP", } try: credential.get_token("https://cognitiveservices.azure.com/.default") results["identity"] = "PASS" except Exception as exc: results["identity"] = f"FAIL: {exc}" return results try: client = AIProjectClient(endpoint=project_endpoint, credential=credential) results["endpoint"] = "PASS" agent = client.agents.get(agent_name=agent_name) # conceptual lookup results["agent"] = "PASS" if agent else "FAIL: agent not found" except Exception as exc: results["endpoint"] = f"FAIL: {exc}" return results try: response = client.agents.run( agent_name=agent_name, messages=[{ "role": "user", "content": "Return OK and identify which configured data source you used.", }], ) # conceptual invocation results["invocation"] = "PASS" if response else "FAIL: no response" results["services"] = "PASS" # evaluate expected probe evidence here except Exception as exc: results["invocation"] = f"FAIL: {exc}" results["report"] = "PASS" return results if __name__ == "__main__": print(validate_agent_handover( os.environ["FOUNDRY_PROJECT_ENDPOINT"], os.environ["FOUNDRY_AGENT_NAME"], )) Configure passwordless identity ManagedIdentityCredential deliberately restricts the validator to Azure managed identity. It does not fall back to an Azure CLI login, developer credential, environment secret, or interactive browser. This makes the acceptance result evidence for the application workload’s real runtime identity. Before running the validator in Azure, enable managed identity on the hosting resource and grant that identity the least-privileged roles required to access the Foundry project and invoke the agent. The agent’s own connections remain configured and authorized separately by the infrastructure team. Example .env file Use an environment file only for local convenience. Do not commit it. In Azure App Service, Azure Functions, Azure Container Apps, or AKS, provide the same values through the platform’s application settings or workload configuration. # .env contains identifiers and configuration—not a password or API key. FOUNDRY_PROJECT_ENDPOINT=https://<project-name>.<region>.api.azureml.ms FOUNDRY_AGENT_NAME=<handed-over-agent-name> # Set only when the workload uses a user-assigned managed identity. AZURE_CLIENT_ID=<managed-identity-client-id> Run the validator # Install the SDK packages selected by your application team. python -m pip install azure-identity azure-ai-projects python-dotenv # Run from an Azure compute resource that has managed identity enabled. # System-assigned identity: omit AZURE_CLIENT_ID. python validator.py # Azure-hosted workload: enable managed identity, assign the required RBAC roles, # add the non-secret environment variables above, and start the same command. python validator.py ManagedIdentityCredential is intended to run on Azure compute with managed identity enabled. Run the handover gate from the application’s deployed environment so the result proves the intended identity, network route, DNS, private endpoints, and role assignments. For a user-assigned identity, set AZURE_CLIENT_ID to its client ID; for a system-assigned identity, omit that setting. Probe prompts for configured services If Azure AI Search, Azure Cosmos DB, or Azure Blob Storage are part of the agent’s contract, the validator sends focused probe prompts through the agent and records the outcome. If a service is not part of the contract, that probe is marked SKIP rather than assumed. Service Example probe prompt Expected evidence Azure AI Search “List the top three documents in your index about [known topic]. Include titles and short snippets.” Document titles and relevant snippets from known indexed content. Azure Cosmos DB “What is the most recent record timestamp in the configured data source?” A valid timestamp that can be checked against a known range. Azure Blob Storage “Confirm that you can access the configuration file at [known path]. Return metadata only.” Expected file name, content type, last-modified time, or a safe summary. These probes test the agent’s actual tool connections without requiring the validator to authenticate to those services directly. A strong acceptance result records the prompt, status, timestamp, correlation or run identifier, and a small piece of expected evidence—without storing sensitive response content. The result gives both teams the same evidence. Instead of asking whether the agent was deployed, they can ask the better question: Is the agent ready for the application to use? Closing thought Deploying an agent is only the first half of the journey. The real test is whether the application team can use it confidently through the expected identity, network, and capabilities. The Agent Acceptance Gateway creates that moment of confidence. It brings both teams together, checks what matters, shows what still needs attention, and turns the handover into a shared decision. The goal is simple: do not hand over an agent just because it exists. Hand it over when both teams have clear evidence that it is ready.

Introducing auto: a new retrieval reasoning effort mode that recovers 97.6% of the evidence recall of the highest effort level at 46.9% fewer query planning tokens. Enterprise retrieval workloads mix simple lookup queries with complex questions that require searching across many documents. Today, customers of Foundry IQ (Azure AI Search) Knowledge Bases must choose a fixed retrieval reasoning effort level: minimal, low or medium. That forces customers to make a trade-off across their workload: pay for deeper retrieval even on simple questions, or reduce costs and risk missing the evidence needed to answer more complex ones. The new auto retrieval reasoning effort, available in the August 2026 preview, reduces the need to choose one fixed effort level for mixed workloads. auto assesses each query and adjusts the query planning and iterative search effort it receives. Straightforward questions take a faster, lower-cost path, while complex questions get the depth of multi-step retrieval, without manual tuning. Customers can still use minimal, low or medium when their workloads are predictable. For mixed workloads, auto lets each query determine the effort it needs. Near-identical retrieval quality, lower cost Figure 1 shows the central trade-off across retrieval reasoning effort tiers. Higher fixed effort generally retrieves more complete evidence, but it also consumes more tokens. auto assigns lower effort to straightforward queries and reserves medium (the highest retrieval reasoning effort) for the queries that need it, retaining 97.6% of its evidence recall while reducing average query planning token usage by 46.9%. Figure 1. Average evidence recall by retrieval reasoning effort using GPT 5.4 mini for query planning. Evidence recall measures how much of the evidence needed to answer a question is found in the retrieved documents. Figure 2 translates the token savings into customer cost. With GPT-5.4 mini, auto reduces the average cost of 1,000 queries from $13.82 to $9.03 (a saving of $4.79, or 34.7%) compared with running every query at medium effort. Because search costs remain fixed, the dollar savings increase when a more expensive model is used for query planning. Figure 2. Total query cost ($/1,000 queries) per model and retrieval reasoning effort. Cost estimates use Azure OpenAI pricing for query planning and Azure AI Search pricing for ranker/search as of September 2026. Effort that scales with the question Not every question needs the same retrieval depth. The auto retrieval reasoning effort matches retrieval depth to each question: minimal or low for straightforward requests, and medium when the question requires additional planning and iterative search. Figure 3 shows how those routing decisions vary across datasets. In the evaluated enterprise workloads, most queries follow the faster minimal or low paths, while datasets containing more complex questions send a larger share of queries to medium. Figure 3. Distribution of effort tiers selected by auto across the evaluated enterprise queries. KS = knowledge source. This routing behavior translates directly into the token savings shown in Figure 4. auto remains close to medium in evidence recall while using fewer tokens across every evaluated dataset. The datasets that route a larger share of queries to minimal achieve the greatest savings, because more queries avoid reasoning tokens when additional retrieval depth is unlikely to help. For a direct lookup query, this can mean using no reasoning tokens instead of the approximately 14,000 consumed by the average medium run. Figure 4. Evidence recall for auto and medium by dataset. The same adaptivity works in reverse. On BrowseComp, a public benchmark of deliberately difficult, multi-step research questions, auto escalates 78% of queries to medium. Its resulting evidence recall remains within a few points of running every BrowseComp query at medium, showing that the router increases effort when simpler retrieval paths are unlikely to be sufficient. It is worth knowing the edges. Choose medium when most queries are complex, multi-step questions and retrieval quality matters more than cost. Choose minimal when the workload consists almost entirely of direct lookups. For mixed workloads, auto is the recommended starting point because it preserves close to medium-level evidence recall while reducing average cost without per-query configuration. Figure 5 shows how auto applies per-query routing across three queries of increasing complexity: a direct lookup, a simple multi-hop question, and a complex multi-hop question. auto selects the lowest retrieval effort expected to preserve evidence quality, escalating from minimal to low or medium as the query requires more planning and retrieval steps. Figure 5. Example routing decisions for three query types of increasing complexity. Get started auto retrieval reasoning effort is now available in preview for Foundry IQ (Azure AI Search) Knowledge Bases. For workloads that mix straightforward lookups with complex questions, auto provides a starting point without requiring you to choose a fixed effort level for every query. If you already have a knowledge base, set retrievalReasoningEffort to auto as its default, or specify auto on an individual retrieve request to override that default for the request. See Set the retrieval reasoning effort for configuration details and supported versions. If you are new to knowledge bases, follow the agentic retrieval quickstart to create one and run your first queries. Then try auto on a representative set of your own questions and compare the retrieved evidence and query-planning token usage with a fixed effort level. Appendix Similarly to our previous blog posts (Foundry IQ: Improve recall by up to 54% with knowledge bases | Microsoft Community Hub, Up to 40% better relevance for complex queries with new agentic retrieval engine) we evaluated auto on several benchmark query sets. Customer datasets: customer-provided corporate and member-document collections in English, covering domains such as oil and gas corporate reports and health-insurance member documents. We evaluate them as single knowledge source (KS) workloads over chunked PDF indexes. SEC: SEC filings of US public companies in English, evaluated in two variants: a single knowledge source setup spanning all sectors, and a routing setup with one knowledge source per Global Industry Classification Standard (GICS) sector. MIML: a multi-industry, multi-language corporate document benchmark in English, French, and Simplified Chinese. We evaluate both single knowledge source variants restricted to one language-industry slice and a routing variant spanning multiple languages and industries. BrowseComp: We use the 830 human-verified BrowseComp-Plus queries and indexed the full corpus, including distractor documents, into 512-token chunks with OpenAI text-embedding-3-large. To support continuous evidence-recall measurement, we decompose each question into multiple atomic factoid evidence nuggets. Evaluations use a two-agent neutral user plus search agent configuration with a standard system prompt and per question effort capped at 40 tool calls.

With SQL Server on Azure Local, customers can modernize where their data resides while maintaining control over infrastructure, connectivity, and data placement. The post SQL Server on Azure Local is now generally available appeared first on Microsoft Azure Blog.

Trusted publishing configurations for npm can now be granted permission to manage dist-tags (e.g., promoting a version to latest, updating next and beta pointers) using short-lived OIDC credentials instead of… The post Opt-in dist-tag permissions for npm trusted publishing appeared first on The GitHub Blog.

The September recap for the Azure Developer CLI (`azd`). Extension management gains dependency-aware uninstall and versioned contracts, project configuration adds top-level infrastructure and service layers, deployment phases support concurrency limits, and external authentication hosts can use local socket transports. The post Everything released in September 2026 for Azure Developer CLI appeared first on Azure SDK Blog.

Hi everyone, I create educational and informational videos around AI (such as Microsoft IQ content) and would like to share them with the community here, similar to how video content is shared in the Microsoft Fabric Community. Is there a designated hub, blog, or discussion category within the Microsoft Tech Community best suited for posting video content like this? For context, here is an example of the title/topic of content I produce: Implementing Microsoft IQ - The Microsoft Unified AI Framework Thanks in advance for any guidance!

The HydraFusion research preview is now available in Visual Studio Code and the GitHub Copilot app, expanding beyond Copilot CLI. HydraFusion appears in the model picker, but rather than being… The post HydraFusion in VS Code and the GitHub Copilot app appeared first on The GitHub Blog.

GitHub Team customers can now start self-serve trials of GitHub Advanced Security to evaluate GitHub Code Security and GitHub Secret Protection. Start a trial from your organization’s Overview page, Billing… The post GitHub Advanced Security trials for GitHub Team appeared first on The GitHub Blog.

Beginning October 7, 2026, GitHub Enterprise Cloud with data residency will no longer accept TLS connections from clients that offer only X25519 for key agreement. Most customers don’t need to… The post X25519-only TLS ends for GHE.com on October 7 appeared first on The GitHub Blog.

Learn what is new in Visual Studio Code 1.141 (Insiders). Read the full article

Today, OpenAI's GPT-6.1 Sol is generally available in Microsoft Foundry. GPT-6.1 Sol is an upgrade to GPT-6 Sol, delivering substantial improvements in agentic coding, computer use, and professional work, with performance approaching GPT-6 Astra across these evaluations. It offers a new balance of capability and cost for important work at higher frequency, making it more affordable for developers to build and run very capable agents at scale. Just one week after GPT-6 Sol and Luna joined our generally available lineup, this release continues the momentum of the GPT-6 series in Foundry: models that produce less noise and are more capable of completing full tasks with agents. GPT-6.1 Sol carries that progress forward for teams whose production workloads run all day, every day. What's new in GPT-6.1 Sol GPT-6.1 Sol advances the three capabilities that matter most for production agents: Agentic coding. GPT-6.1 Sol plans, edits, tests, and iterates across a codebase with improved performance on complex tasks and extended workflows involving multiple tool calls. More capable computer use. Improved reliability navigating real interfaces help agents operate the workflows that span multiple application steps, with permissions and human oversight suited to the task. Deeper Professional work. Stronger performance on the analysis, drafting, and multi-step knowledge tasks that make up daily enterprise work, with improvements in factual accuracy those workflows demand. GPT-6.1 Sol accepts text and image inputs and produces text, with a total context window of up to 1M tokens. This provides room to bring large codebases and document sets, within the model’s context limits. Flexible reasoning lets teams tailor the model’s depth of analysis to the needs of each task. This can help teams use tokens more efficiently by reserving deeper reasoning for the work that needs it. As in last Tuesday's announcement, the starting point is quality alongside cost per task, not model capability in isolation. Use that lens to evaluate GPT-6.1 Sol against the needs of your own production workloads. Where to put GPT-6.1 Sol to work Because these gains compound in agentic loops, valuable use cases include agent workloads that run frequently: Software engineering agents that triage issues, implement changes across a repository, respond to code review, and keep CI green, with costs that support running them on every pull request, not just the hard ones. Computer-use agents that complete back-office processes end to end: updating records across line-of-business systems, reconciling data between applications, and handling workflows in browsers. Professional work agents for research synthesis, contract and document review, financial analysis, and report generation, where work recurs weekly or daily and rewards consistent quality per task. High-frequency customer and employee workflows, where GPT-6.1 Sol's capability-cost balance lets teams upgrade the intelligence behind every interaction without upgrading the budget. The right intelligence behind every agent The right model for a job should be determined through evaluations. GPT-6.1 Sol joins GPT-6 Astra, GPT-6 Sol, and GPT-6 Luna in the Foundry model catalog: start with GPT-6 Astra for the most demanding reasoning, use GPT-6.1 Sol as the new default for production agents and complex workflows, and scale high-volume data and preparatory tasks with Luna. As with the rest of the GPT-6 series, look beyond price per token to cost per task, alongside quality and reliability. Foundry brings evaluation, tracing, and monitoring together so teams can make that call with evidence, then switch models without re-platforming. Deploy it your way With GPT-6.1 Sol in Microsoft Foundry, teams can choose how they scale and where processing takes place. Standard deployment offers flexible capacity billed by usage across Global regions and US, EU, and APAC Data Zones. Provisioned Throughput is available at launch through Global and US Data Zone deployments, providing reserved capacity for critical production workloads. Additional regions and deployment options will follow soon. That is the Foundry advantage: the flexibility to balance capacity, performance, and data residency requirements within one enterprise platform. Teams can match each workload to a supported combination of serving option and processing location, rather than apply the same deployment approach to every application. GPT-6.1 Sol Pricing* Model Deployment Context Length Pricing (USD $/million tokens) Input Cached Input Cached Writes Output GPT-6.1 Sol Global Standard Short context $2.00 $0.10 $2.50 $10.00 Long context $4.00 $0.20 $5.00 $15.00 Data Zone Standard (US) Short context $2.20 $0.11 $2.75 $11.00 Long context $4.40 $0.22 $5.50 $16.50 Data Zone Standard (EU) Short context $2.40 $0.12 $3.00 $12.00 Long context $4.80 $0.24 $6.00 $18.00 Data Zone Standard (APAC) Short context $2.40 $0.12 $3.00 $12.00 Long context $4.80 $0.24 $6.00 $18.00 *Prices shown are for Standard deployments. Provisioned Throughput pricing varies by deployment type. For each offer, the US Data Zone is priced at a 10% premium to Global, and the EU and APAC Data Zones are priced at a 20% premium to Global. For current rates and terms, see the Azure OpenAI pricing page., see the Azure OpenAI pricing page. Build safer agents on Foundry GPT-6.1 Sol runs with the same layered protections as the GPT-6 series in Foundry: alignment training in the model, content filters and guardrails on prompts and outputs, prompt injection mitigations on tool calls and responses, and enterprise identity and access controls governing what agents can reach. Microsoft Purview applies data policies and human checkpoints at every phase. Start building Your next agent needs more than a powerful model. Foundry pairs GPT-6.1 Sol with the deployment flexibility, observability, and enterprise controls to take it from first workload to production at scale. Explore GPT-6.1 Sol in the Microsoft Foundry model catalog and evaluate where it fits in your next agent.

Azure SDK releases every month. In this post, you'll find this month's highlights and release notes. The post Azure SDK Release (September 2026) appeared first on Azure SDK Blog.

As a repository administrator, you can now configure the runner type, optional custom label, and optional runner group for Dependabot version and security updates. This extends the runner configuration already… The post Repository custom runner settings for Dependabot appeared first on The GitHub Blog.

See how Azure Canvases bring plans, code, previews, and deployment feedback together in a collaborative workspace for agent-assisted development. The post Build with Azure Canvases: a shared workspace for agents appeared first on Microsoft for Developers.

You can now seamlessly bring business context about your repositories from an external system of record (e.g., a configuration management database (CMDB), an internal developer portal, or an in-house system)… The post Bring business context with external custom properties appeared first on The GitHub Blog.

GPT-6.1 Sol, the latest model from OpenAI, is now generally available and rolling out in GitHub Copilot. You can use it for agentic coding and terminal workflows with strong multistep… The post GPT-6.1 Sol in GitHub Copilot appeared first on The GitHub Blog.

Bring your own AI model with updates to BYOM, fix NuGet vulnerabilities from the Error List, explore pull requests with the Git agent, see which operand decides an if condition, and attach to Podman containers. The post Visual Studio September Update – Power Your Workflow with Your Model appeared first on Visual Studio Blog.

Explore GitHub’s latest transparency data and learn more about policy updates affecting developers and open source. The post Developer policy update: Transparency, state policy, and what’s ahead appeared first on The GitHub Blog.

Our Virtual Machine Lifecycle policy guides how we manage these transitions, giving Azure customers transparency, predictability, and guidance. The post Enhancing Microsoft Azure Virtual Machine lifecycle appeared first on Microsoft Azure Blog.

Microsoft Fabric and SQL innovations announced at FabCon and SQLCon Barcelona 2026 help organizations build trusted data foundations for AI. The post FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and agents appeared first on Microsoft Azure Blog.

The best model for your business will keep changing. Adopting it should move your business forward, not send your team back to rebuild the architecture around it. The post Ship agents faster with expanded model choice, voice agents, and continuous optimization appeared first on Microsoft Azure Blog.

AI agents are becoming more capable of understanding requests, making decisions, and interacting with multiple systems through APIs and automation tools. I’m interested in how organizations are approaching this shift from traditional workflow automation toward more intelligent, agent-driven workflows. Some areas I’m exploring:How are teams deciding which processes are suitable for AI agents?What role do validation, monitoring, and human approval play in agent-based automation?How are organizations managing security and permissions when AI agents access business systems?Are AI agents replacing traditional workflows, or working alongside existing automation platforms? Would love to hear how the community is approaching AI agent adoption in real enterprise scenarios. What patterns or lessons have you learned while implementing AI-powered workflows?