azure
149 TopicsPartner Blog | FY27 is the year to execute on AI: A starting point for Azure partners
FY27 is the year to execute on AI. For Azure partners, that means moving more customer AI initiatives into production, modernizing the cloud, data, application, security, and governance foundations they depend on, and connecting those investments to outcomes customers can measure. Across the partner ecosystem, you are starting from different places. Some partners are already scaling AI solutions in production. Others are modernizing legacy environments, unifying data, or strengthening security and governance so customers are ready for what comes next. The opportunity is to understand where each customer is today and create a practical path forward. Microsoft has aligned FY27 customer conversations, go-to-market guidance, incentives, skilling, and partner resources around that goal. The focus is less on starting with a product and more on starting with what the customer is trying to achieve. In July, MCAPS Start for Partners and the Microsoft Partner FY27 GTM Kickoff laid out that direction. If you missed the events or want to revisit a specific topic, the content is available on demand: Watch MCAPS Start for Partners on demand Explore the Microsoft Partner FY27 GTM Kickoff The more important question now is what you do with that guidance. Turn customer priorities into Core and Frontier conversations Customers rarely begin by asking for a portfolio of technologies. They begin with a challenge, an ambition, or an outcome: modernize an aging application, make fragmented data useful, strengthen security, improve employee productivity, automate a process, or create a new customer experience. That is the starting point for FY27. Core conversations establish the foundation customers need to become AI-ready. Depending on the customer, that can mean modernizing infrastructure and applications, bringing data together on a governed platform, improving security, or establishing the controls required to operate AI with confidence. Continue reading here141Views0likes0CommentsBeyond Tokens: Rethinking AI Economics with Microsoft Foundry
Beyond Tokens: Rethinking AI Economics with Microsoft Foundry From the cost of intelligence to the value of outcomes Enterprise AI has an accounting problem. Executives expect agentic AI to return roughly 171% on investment, according to one widely cited survey. Yet McKinsey finds only about 39% of organizations can attribute any earnings impact to AI at all. Both numbers can be true at once — because the gap between them is not a technology gap. It is a measurement gap. For the first few years of generative AI, one number dominated the economics conversation: tokens. How many tokens did a model consume? What was the cost per million tokens? Could a smaller model perform the same task? Those questions mattered when enterprises were experimenting with AI. They are no longer enough as AI moves into production. An enterprise agent doesn't simply consume tokens. It reasons, retrieves context, invokes tools, calls APIs, verifies its work, retries unsuccessful actions and sometimes escalates exceptions to humans. The model call might cost pennies. The business outcome could cost considerably more. Which leads to an increasingly important question: What is the right economic unit for intelligence? From AI experimentation to economic accountability The first wave of enterprise AI was about possibility: Can AI do this? The next wave is about production, as AI becomes embedded in software engineering, customer service, finance, healthcare and supply chains. And production changes the question: Should AI do this and at what cost? Microsoft has moved decisively onto this ground. In August 2026, the Microsoft Foundry team launched its Economics of Agent Optimization series, arguing that "tokens have become the new unit of technology spend" and that AI should be run as a managed investment system. On the latest earnings call, Satya Nadella described Microsoft's objective as "advancing the frontier on the cost-to-outcome curve, ensuring every customer can turn tokens into business results." The discipline is going mainstream too: 98% of FinOps teams now manage AI spend, up from 31% two years ago. Microsoft's series is largely about the numerator of that curve - making every request, agent and dollar more efficient. This article is about the denominator: what an outcome is, what it truly costs, and what it is worth. The evolution of Microsoft Foundry reflects the same shift. At Build 2026, Microsoft expanded the conversation beyond building agents toward tracing behavior, evaluating quality, monitoring production performance, optimizing agents and connecting their operation to ROI. Think of the progression as: Trace → Evaluate → Monitor → Optimize → ROI This is more than a technology roadmap. It represents a shift from observing AI as technology to managing AI as an economic asset. Tokens became the unit of spend. They were never the unit of value. Consider two AI agents handling the same customer-service workflow. Agent A costs $0.08 per interaction. Agent B costs $0.20. Agent A appears cheaper. But suppose Agent A successfully resolves only 55% of cases, while Agent B resolves 90%. The remainder require retries, additional reasoning or human intervention. Which agent is actually cheaper? The inexpensive interaction may produce the expensive resolution. This illustrates a fundamental problem: We often measure AI where it is consumed rather than where value is created. Tokens are a unit of consumption. Businesses operate in outcomes. A customer-service leader cares about issues resolved. An engineering leader cares about high-quality software reaching production. A finance leader cares about reconciliations completed accurately. The economic denominator needs to move closer to the business. The AI Economic Ladder I think of this evolution as an AI Economic Ladder: Tokens → Interactions → Tasks → Outcomes → Value Each step moves measurement closer to what the enterprise actually cares about. At the token level: What intelligence did we consume? At the interaction level: What did each AI run cost? At the task level: What did it cost to complete the work? At the outcome level: What did a successful result cost? At the value level: Was the outcome worth creating? An AI system can become more efficient at every technical metric while creating little economic value. Conversely, an expensive AI workflow could be extraordinarily valuable if it prevents revenue leakage, reduces operational risk or accelerates a critical business process. The objective isn't cheaper AI. It is better economics. Not every completed task is a successful outcome There is another complication. If an agent completes a workflow, should we count it as a successful outcome? Not necessarily. A meaningful outcome needs three characteristics: Completed. Quality-gated. Attributable. It must reach its intended end state, meet an explicit standard for quality, accuracy, safety or business acceptability, and be attributable to the agent or workflow that produced it. That gives us a more meaningful measure: Cost per Successful Outcome = Fully Loaded AI Workflow Cost / Completed, Quality-Gated, Attributable Outcomes The denominator becomes real only when named in business language: cost per prior authorization resolved in healthcare, per pull request triaged and tested in engineering, per disputed invoice reconciled in finance operations. If you cannot name the outcome in a sentence the process owner recognizes, you are not ready to measure it. The quality gate matters. With AI, "the system ran successfully" and "the system produced a good outcome" are not the same thing. Microsoft Foundry's tracing and evaluation capabilities become economically important for precisely this reason. Evaluation isn't merely quality control. It helps determine what gets counted as value. What does an AI outcome really cost? The true economic footprint goes far beyond inference: Model + Reasoning + Grounding + Tools + Orchestration + Infrastructure + Retries + Evaluation + Governance + Human Intervention Human intervention is particularly easy to overlook. Every time someone must review, correct, approve or recover an AI-generated outcome, the economics change. The same applies to verification. An agent reaching an acceptable result in three steps has different economics from one requiring fifteen steps and multiple retries. And verification is not a rounding error — it is the bulk of the bill. McKinsey's 2026 analysis of production agentic workflows found roughly 60% of an agentic task's cost is tied to refining answers — checking, repairing, re-verifying — not generating the initial response. Most of what you pay for is not intelligence. It is assurance. This means quality and economics are connected. The quality bar you set influences the cost you pay. The challenge isn't simply minimizing consumption. It is finding the right balance between quality, cost, speed and risk. Cost per outcome is only half the equation Now imagine two agents. Both cost $5 per successful outcome. One saves an employee ten minutes of administrative work. The other prevents $500 in revenue leakage. Their cost efficiency is identical. Their economics clearly aren't. So we need to move another step up the ladder: from Cost per Outcome to Value per Outcome. The question isn't only how cheaply AI can complete the work. It is: How much economic value does this outcome create relative to the intelligence required to produce it? Now the CIO, CFO, CAIO and business leader have a common conversation. Give every outcome an Intelligence Budget Not every problem deserves the smartest model available. Classifying an email may require relatively little intelligence. Resolving a complicated customer complaint may justify more context and reasoning. Assessing the risks in a multimillion-dollar contract may justify sophisticated reasoning, multiple validations and human review. Every business outcome therefore has an economically rational amount of intelligence worth spending on it. Call it an Intelligence Budget. This changes the architecture question from which model should we standardize on, to: What combination of model, reasoning, context, tools and human judgment does this outcome deserve? This is where Microsoft Foundry's model router becomes interesting. Individual requests can be dynamically routed so simpler work doesn't consume the same model resources as complex reasoning. If the Intelligence Budget is the economic principle, intelligent routing is one way of operationalizing it. The future enterprise AI architecture won't be about one model doing everything. It will route intelligence according to the economics, quality and risk of the outcome. Making AI economics observable None of this works without visibility. An AI system can be technically healthy and economically unhealthy — responsive and error-free while repeatedly choosing inefficient reasoning paths, invoking unnecessary tools or producing outputs requiring expensive human correction. AI economics and AI observability are becoming inseparable. Microsoft Foundry increasingly connects these disciplines. Tracing shows what an agent did. Evaluation determines whether it met required criteria. Observability helps monitor production behavior. Agent optimizer can test improvements across prompts, skills and models. Microsoft's emerging ROI capabilities take the next step by connecting operating costs with measures such as task completion, time saved and cost efficiency. Attribution is the bridge to the finance conversation. Teams place Azure API Management in front of Foundry endpoints as an AI Gateway, stream token telemetry into Application Insights, and use Entra Agent ID to give every agent run a discrete identity that maps cost to its cost center. Microsoft Agent 365 extends the discipline tenant-wide — spending policies, budget caps and departmental chargeback across Microsoft and third-party agents. Together, they create something enterprises have historically lacked: A feedback loop between how intelligence is consumed and what that intelligence accomplishes. The paradox of cheaper intelligence There is another reason AI economics will become more important as models get cheaper. The Jevons paradox suggests that when technology makes a resource cheaper and more efficient, total consumption can actually increase. AI may experience the same effect. Cheaper intelligence enables more agents, more reasoning and more workflows that were previously uneconomic. So we could see cost per unit of intelligence fall while total intelligence consumed rises. Cheaper AI may therefore produce larger AI bills. That isn't necessarily bad — provided value grows faster than consumption. The objective isn't minimum AI consumption. It is maximum economic value from AI consumption. From workload economics to portfolio economics As AI scales, economics becomes a capital-allocation question. I see three levels. Workload Economics: Is this AI system running efficiently? Outcome Economics: Is it producing quality outcomes economically? Portfolio Economics: Where should we put our next AI dollar? That final question will become increasingly important. An enterprise with hundreds of AI initiatives shouldn't assume every one deserves continued investment. Some should scale. Some need optimization. Some should be redesigned or consolidated. And some should be stopped. The ability to experiment cheaply created the first explosion of enterprise AI. The discipline to allocate capital intelligently will determine what scales. Who owns AI economics? Once an agent becomes part of how work gets done, its economics cannot remain purely an IT metric. The business understands the value of the outcome. Technology understands the architecture and optimization levers. Finance brings economic discipline and comparability. That suggests a shared model: Business owns the outcome. Technology owns the optimization levers. Finance owns the economic discipline. AI economics ultimately isn't just a technology-cost conversation. It is a business-performance and capital-allocation conversation. From abundant intelligence to intelligent economics We are entering an era where intelligence is becoming an increasingly abundant, programmable and variable-cost resource. Microsoft Foundry and the broader Microsoft AI stack are making it easier to build, evaluate, observe, optimize and govern that intelligence. But abundant intelligence does not guarantee abundant value. Enterprises still need to decide where AI belongs, how much intelligence each problem deserves, what defines a successful outcome, when humans should remain involved and which AI investments deserve more capital. The winners won't necessarily use the cheapest models. They won't consume the fewest tokens. And they won't be the organizations that build the most agents. They will become exceptionally good at moving up the AI Economic Ladder: from consumption, to outcomes, to value. Because the next era of AI won't be won by organizations that buy intelligence most cheaply. It will be won by those that convert intelligence into value most efficiently. Where to start: the first 90 days Define the denominator for your top three agents — what counts as done, what quality gate applies, who signs off. Instrument attribution — Azure API Management as an AI Gateway, token telemetry to Application Insights, Entra Agent ID on every run. Wire evaluations into the cost pipeline so only quality-gated outcomes count. Set Intelligence Budgets — model router per request, agent optimizer against your evaluators, Agent 365 policies as circuit breakers. Stand up a joint monthly review — business, technology and finance on one dashboard: outcomes delivered, cost per outcome, value per outcome. Frequently asked questions What is Cost per Successful Outcome in enterprise AI? The fully loaded cost of an AI workload divided by outputs that were completed, quality-gated and attributable - for example, cost per prior authorization resolved or per pull request triaged. It turns token metrics into the unit economics of AI-performed work. What is an Intelligence Budget? The economically rational amount of intelligence - model capability, reasoning, context, tools and human review — worth spending on a given outcome, based on its value and risk. Model router in Microsoft Foundry is one way to operationalize it. Why do AI agents cost more than single model calls? One agent task can involve planning, tool calls, retries and verification - many model calls with compounding context. Research on production agentic workflows attributes roughly 60% of task cost to refining and verifying answers, not generating the first response. Will falling model prices make AI cost management unnecessary? No. By the Jevons paradox, cheaper intelligence expands consumption, so total AI spend typically rises as unit prices fall. The discipline that matters is maximizing value per unit of intelligence. Who should own AI economics? A shared model: the business owns the outcome and its value, technology owns the optimization levers, and finance owns the economic discipline and review cadence. #MicrosoftFoundry #Agent365 #AzureAI #FinOps #AgenticAI #AIAgents #Azure #MicrosoftCostManagement #AIEconomics #Tokens References Microsoft Azure Blog: "The Economics of Agent Optimization: From pilots to measurable returns" (August 12, 2026) Microsoft FY26 Q4 earnings call (Satya Nadella, July 2026) McKinsey — "Cost versus value: managing agentic AI system performance" (July 2026) FinOps Foundation — State of FinOps 2026; Microsoft Learn — Model router for Microsoft Foundry; Agent optimizer; Foundry Control Plane cost optimization535Views1like2CommentsSimplify AKS observability with Azure Native New Relic Service
An Azure Native path to New Relic Intelligent Observability for AKS AKS environments are dynamic by design. Applications can span clusters, namespaces, nodes, pods, and containers, while workloads scale and change continuously. Obtaining consistent visibility often requires platform teams to deploy and maintain monitoring components separately on every cluster. Azure Native New Relic Service simplifies this process by integrating New Relic onboarding and management into Azure. Customers can already use the service to: Create a new New Relic account or link an existing account from Azure. Configure the forwarding of Azure platform metrics and logs to New Relic. View the monitoring status of Azure resources. Consolidate procurement and eligible New Relic charges through Azure Marketplace. Monitor multiple Azure subscriptions through a single New Relic resource. With AKS extension support, customers can now extend this native management experience to their Kubernetes clusters. Install the New Relic integration from the Azure portal The new experience follows the same simple model used by Azure Native integrations for other compute resources. From an Azure Native New Relic Service resource, customers can navigate to New Relic account config > Azure Kubernetes Services, select an eligible AKS cluster, and choose Install Extension. Azure then deploys the New Relic Kubernetes integration by using the AKS cluster extensions framework. After deployment completes, the portal displays the installation status for the cluster. Customers can return to the same experience to review the status or select Uninstall Extension when monitoring is no longer required. AKS cluster extensions provide an Azure Resource Manager-based approach for installing and managing services on AKS. This gives customers a consistent Azure control plane experience for deployment and lifecycle operations instead of requiring a separate, manual Helm installation for each cluster. Gain deeper visibility into Kubernetes workloads The extension deploys the New Relic Kubernetes integration to the selected AKS cluster. The integration provides visibility across Kubernetes infrastructure and workloads, including cluster, node, namespace, deployment, pod, and container health and performance. Depending on the enabled New Relic configuration, customers can also bring together Kubernetes events, logs, and Prometheus-formatted metrics with application and Azure platform telemetry in New Relic. This helps application, platform, and site reliability engineering teams investigate issues across the stack without stitching together disconnected views. Teams can use New Relic to: Understand resource consumption and health across clusters, nodes, pods, and containers. Identify unhealthy workloads, container restarts, and capacity constraints. Correlate Kubernetes infrastructure signals with application performance data. Explore Kubernetes entities and relationships through New Relic's cluster experience. Create dashboards, alerts, and operational workflows using telemetry from Azure and AKS. The result is a more direct path from detecting an issue to understanding its impact on applications and users. Reduce operational toil with unified telemetry For organizations operating multiple AKS clusters, consistency is as important as visibility. Manual installation can lead to configuration drift, missed clusters, and additional work whenever monitoring components need to be changed. The Azure Native New Relic Service experience helps address these challenges by providing: Simplified onboarding: Install the integration from the Azure portal without building a separate deployment workflow. Centralized visibility: Review AKS extension status alongside other Azure resources connected to New Relic. Azure governance alignment: Use Azure Resource Manager and Azure role-based access control as part of the management experience. Lifecycle management: Install or remove the extension through a consistent Azure workflow. Unified, full-stack observability: Connect AKS telemetry with application, infrastructure, log, and Azure platform data in New Relic. This experience is particularly useful for platform teams that want to make observability available as a standardized service while allowing development teams to use New Relic for troubleshooting and performance optimization. Get started To begin monitoring AKS with Azure Native New Relic Service: Either browse to the Marketplace offer listing or in the Azure portal, create an Azure Native New Relic Service resource. Go to New Relic account config > Azure Kubernetes Services. Select the AKS cluster that you want to monitor. Select Install Extension and then confirm the installation. After the status changes to Installed, open New Relic to explore your Kubernetes data and configure the dashboards and alerts appropriate for your environment. If you face any technical challenges do raise a support ticket and share your feedback.235Views0likes0CommentsIntroducing Everpure Cloud Azure Native for Azure VMs
Overview We're excited to announce Everpure Cloud Azure Native for Azure Virtual Machines (VMs). With this release, Azure customers can provision enterprise-grade block storage volumes and attach it directly to their Azure VMs, all managed natively within the Azure portal. No appliances to manage, no complex storage stack to stitch together — just elastic, high-performance block storage that behaves like any other Azure disk. This release solves three persistent challenges Azure VM customers face with traditional Managed Disks: Pay for capacity what you actually use, not what you provision — Billing follows effective capacity after deduplication and compression, helping customers avoid overprovisioning and reduce storage costs (by up to 40%) Scale storage independently from compute — Grow capacity and tune performance without resizing your VM or touching the VM SKU, giving you finer control over both cost and performance. Enterprise data services built in — Thin provisioning, deduplication, and compression — all native to Everpure. What you can expect Familiar building blocks — storage pools, volume groups, and volumes that map cleanly to your applications and VMs. Independent scaling of capacity and IOPS — dial storage performance up or down without disturbing compute. Seamless guest-OS integration — mounted volumes appear as standard Windows disks; no special drivers or custom tooling required. Step-by-step: Setting up Everpure Cloud Azure Native storage for your Azure VM Step 1 — Deploy Everpure Cloud service Find Azure Native Everpure Cloud in the Azure Marketplace and deploy it into your subscription. The service is provisioned natively as an Azure resource and enables the service in selected region. Step 2 — Create a Storage Pool Create a storage pool — Choose an availability zone for resiliency and use the performance slider to set your desired IOPS independently of capacity Step 3 — Create a volume group Create a volume group — a logical container that groups related volumes together, for example all the disks belonging to a single application, database, or VM. Operating at the group level makes access control and day-2 management simpler at scale. Step 4 — Create volumes Within the volume group, create the volumes your VM will consume. Specify a name and size — this size is a logical limit, not pre-allocated capacity. Volumes can be resized live and shared across multiple VMs when needed. Step 5 — Mount to your Azure VM From the volume group, select Mount on VM. The Azure VM connection experience opens, letting you attach the volume to your chosen Azure Virtual Machine. Step 6 — Bring the disk online inside the guest OS Once mounted, the final step happens inside the VM. The Everpure volumes appear as standard, uninitialized Windows disks. Open Disk Management, initialize the disks with GPT, run the New Simple Volume Wizard, and format them as NTFS. Within seconds, the Everpure-backed volume becomes a regular drive letter (for example, F:) ready for any workload. Get Started Today Everpure Cloud Azure Native for Azure VMs is available now in the Azure Marketplace. Deploy it into your subscription to start bringing enterprise-grade Everpure to your Azure VMs Start Your Free Trial of Everpure Cloud Azure Native Check out the Everpure Cloud release notes for detailed guidance on supported configurations, capacity points, and operational considerations. Read the Everpure GA announcement blog to learn how Everpure Cloud Azure Native for Azure VMs helps reduce costs and simplify storage operations. Have feedback or questions? Drop a comment below — we'd love to hear how you plan to use Everpure Cloud for your Azure workloads.464Views2likes0CommentsPartner Case Study | Ingram Micro
As organizations move toward AI-powered operations, many are discovering they are not starting with a clean slate. Legacy on-premises infrastructure, fragmented cloud environments, and security gaps often stand between customer ambition and execution. At the same time, customer expectations continue to rise, putting added pressure on managed services providers (MSPs) and consulting partners to deliver scalable, compliant solutions without adding operational burden or losing control of cost, complexity, and security. As a global Microsoft distributor, Ingram Micro empowers partners to bridge that gap by supporting customers across key stages of their modernization journey, from exiting legacy infrastructure to adopting Azure-native solutions and building toward AI innovation. Rather than treating migration, modernization, and AI as separate motions, Ingram Micro guides partners to a structured, repeatable path forward on Azure. With advanced specializations in Infrastructure and Database Migration, Azure Virtual Desktop, Azure VMware Solution, and AI Apps on Azure, Ingram Micro brings technical depth and access to Microsoft-backed funding programs to their engagements with partners. They empower partners to modernize infrastructure, optimize costs, prove value faster, and lower risk as they move customers from foundational cloud transformation to AI-powered workloads. Evolving beyond legacy infrastructure without disruption Calyx IT is an MSP that has spent more than 20 years serving customers across legal, finance, and compliant manufacturing. Over time, Calyx’s traditional private datacenter model became more difficult to sustain. Rising costs and limited scalability required more work to keep pace with customer expectations. Managing infrastructure across multiple vendors also introduced more complexity and inefficiency, while a legacy virtualization stack created added pressure through unpredictable licensing costs from third-party providers. Calyx consulted Ingram Micro, who recommended Microsoft Azure for flexible, consumption-based infrastructure. An existing partnership between Ingram Micro and Calyx provided a foundation for tackling a larger transformation. Together, the teams developed a strategy that aligned technical requirements, cost considerations, and migration planning. Continue reading here Explore all case studies or submit your own Subscribe to case studies tag to follow all new case study posts. Don't forget to follow this blog to receive email notifications of new stories!131Views0likes0CommentsPartner Blog | Building AI-ready applications on open, enterprise-grade Azure platforms
Microsoft Build 2026 reinforced a practical reality for organizations moving from AI experimentation to production: AI is only as strong as the foundation it runs on. Customers need modern databases, governed data, secure infrastructure, and developer experiences that can carry performing AI-enabled applications at scale into production with confidence. The public preview announcements of Azure HorizonDB and Azure Linux, along with the general availability of Azure Container Linux, show how Microsoft is investing in open platforms, developer ecosystems, and enterprise-grade cloud infrastructure for AI-ready applications. These announcements also point to a broader shift: open source has become a strategic foundation for enterprise modernization, innovation, and strategic growth. These announcements give partners a straightforward way to connect customer AI goals to the open, secure, enterprise-ready platforms needed for production. They also create timely opportunities to engage customers on data modernization, AI-ready application development, secure infrastructure, and cloud-native operations. What was announced at Build 2026 Azure HorizonDB: A new standard for AI-native, enterprise PostgreSQL Azure HorizonDB enters public preview as a new PostgreSQL cloud database service engineered for performance, scale, and modern AI-powered application needs. For business leaders thinking about data strategy, this is significant. Organizations are under pressure to modernize legacy databases and support intelligent applications without sacrificing resilience, governance, or developer productivity. Azure HorizonDB is designed to address those priorities with a platform that can scale storage automatically for large enterprise workloads, scale compute across primary and replica nodes, and bring AI-native capabilities directly into the database layer. What stands out is that Azure HorizonDB gives enterprises a way to simplify architecture while also accelerating innovation. Features such as advanced filtered vector search, in-database AI model management, Microsoft Entra ID integration, and GitHub Copilot integration through the PostgreSQL extension for Visual Studio Code position it as more than a database modernization story. Developers can use Microsoft 365 Copilot with live database context to generate schema-aware SQL, explore database structures, analyze and rewrite queries, and build against HorizonDB-specific capabilities without leaving Visual Studio Code. It is designed to bring together open-source PostgreSQL, enterprise security, AI readiness, and a more integrated developer experience in a single managed service. For business leaders, that can create a faster path from data estate modernization to measurable business outcomes. In Microsoft internal testing environments, Azure HorizonDB performed three times faster than self-managed PostgreSQL. For partners, the announcement creates an opportunity to engage customers in PostgreSQL modernization, intelligent application architecture, migration planning, performance optimization, and AI-enabled development. Azure Linux: Open-source infrastructure at enterprise scale The Azure Linux public preview announcement is meaningful for leaders focused on cloud efficiency, security, and platform consistency. Linux is already foundational to modern digital infrastructure, and two-thirds of customer cores in Azure run Linux. Now Azure Linux provides a first-party Linux distribution, purpose-built for Azure, and is available for Azure virtual machines (VMs), VM scale sets, and container images. We also announced Azure Container Linux (ACL), a secure, immutable container host designed to help platform teams run Kubernetes workloads at scale on Azure Kubernetes Service (AKS). By bringing Azure Linux forward as a more visible first-party platform choice, Microsoft is giving organizations a cloud-native operating system designed for modern workloads, including virtual machines (VMs), containers, and AI infrastructure. This matters because infrastructure choices increasingly shape agility, security posture, and operating cost. Azure Linux reflects the Microsoft focus on secure-by-default design, consistent servicing, and tighter alignment between the operating system and the Azure platform. For enterprises, that can translate into simpler operations and a more predictable foundation for cloud-native applications. These announcements reinforce what the Microsoft partner ecosystem and customer usage have shown for years: open-source infrastructure is foundational to Microsoft cloud strategy, as more than 65% of customer cores in Azure run Linux. Continue reading blog here150Views1like0CommentsAzure Native Integrations: Public Preview of Napster Companion API on Azure
What is Napster Companion API? Napster Companion API is Napster's platform for building Omniagents: persistent, multi-channel AI agents with one identity, one memory, and one set of tools that show up across every channel an end user touches. The same Omniagent meets the customer on the website, in the mobile app, on video, and on the phone line with the same face, the same voice, and the same memory of the last conversation. The Omniagent as a digital worker The clearest way to think about an Omniagent is as a digital worker: It has a role (customer support specialist, sales advisor, internal IT assistant). It carries the memory of past shifts and prior conversations. It has the tools it needs to do the job which include APIs, knowledge bases, ticketing systems, CRMs. It shows up across every surface the end user touches, like a human worker who answers the door, the phone, and the inbox. When something is outside its scope, it hands off to a human colleague with the context already attached and picks the thread back up when the human is done. Use cases for the Companion API Teams are already exploring the Companion API across a wide range of scenarios: Agentic commerce. Agents that guide end users through discovery, recommendations, purchase, and post-sales support all in one continuous conversation across channels. Customer service. Agents that resolve issues end to end, escalate to humans with full context attached, and pick the thread back up across sessions. Internal operations and digital coworkers. Agents that orchestrate workflows, retrieve knowledge, and automate repetitive tasks for the workforce. Capabilities introduced by Napster Companion API The Companion API public preview brings the following capabilities to Azure customers: Persistent multi-channel agents that maintain identity, memory, and context across web, mobile, voice, video, and telephony. Real-time multimodal interactions across voice, video, and text for natural back-and-forth conversation. Tool and API orchestration that lets agents take real actions like opening tickets, updating records, retrieving documents, and triggering workflows. Persona-driven agents with configurable behavior, conversational style, and avatar-based interaction. Knowledge bases and deterministic question-and-answer pairs for grounded, accurate responses on topics where exactness matters. Developer SDKs and a no-code Dashboard for building, testing, deploying, and iterating on agents. Better together: Napster and Microsoft This integration is the result of a long-term Azure-native partnership between Napster and Microsoft. It is not an external service layered onto Azure infrastructure but it is a co-engineered offering designed to help enterprises operationalize persistent AI agents at scale. In practice, the Azure Native integration delivers: Benefit What it means for you Seamless development experience Provision and manage Companion API resources directly from the Azure portal, alongside your other Azure services. Build and operate Omniagents in the Napster Dashboard, reached through single sign-on. Bring your own model or use Napster Hosted Connect your Azure OpenAI realtime deployment on Microsoft Foundry so inference runs in your tenant. Or use the Napster Hosted tier where Napster manages the model for you. Simplified billing Manage Companion API spend through Azure Marketplace, on the same invoice as the rest of your Azure consumption which means no separate procurement, no separate billing relationship. Single sign-on with Microsoft Entra Switch between Azure resources and the Companion API Dashboard without re-entering credentials. Enterprise-ready foundation Built on Azure's compliance, security, and global infrastructure footprint. How it works?    If the player doesn’t load, open the video in a new window: Open video Get started in minutes Provisioning Napster Companion API on Azure takes just a few clicks: Open the Azure portal and search for *Napster Companion API*. Create a new resource and choose your subscription, resource group, region, and pricing tier. Link your Napster organization (or create one as part of resource provisioning). Launch the Companion API Dashboard from the resource overview page using single sign-on, and start building your first Omniagent in the Napster portal. Full step-by-step guidance is available in the Napster Companion API documentation on Microsoft Learn Resources Product documentation: Napster Companion API on Microsoft Learn Quickstart: Create a Napster Companion API resource Azure Marketplace listing: Napster Companion API Napster for partners: napster.com/partners Azure Native Integrations overview: Azure partner solutions What's next This public preview is the first milestone on a broader roadmap. We are eager to hear from early adopters. Try the public preview, build your first Omniagent, and let us know what you think as your feedback will shape what ships next. Get started today by searching for Napster Companion API in the Azure portal.1.7KViews1like1CommentPartner Blog | Leading the moment: How Azure partners are driving the Frontier shift
Something fundamental is shifting in how partners create value, and it is moving faster than many expected. That shift is creating new opportunities for those ready to lead. Across recent partner events and one-on-one conversations, we have heard a consistent message: customers are actively adopting AI and shifting toward becoming Frontier firms. They are moving AI from isolated experimentation to a core capability that drives execution, differentiation, and growth. Now customers are asking a more consequential question: how do we rewire our businesses to operate as a Frontier firm? That question can reshape how you deliver value. In this blog, we share how Microsoft is investing in the platform and programs that enable the partner-led path to becoming Frontier, so you can turn AI ambition into durable transformation. The Frontier shift partners are witnessing now Frameworks set the direction, but markets move when partners lead. In conversations with partners around the world, one point is clear: AI has moved from exploration to execution. Customers are no longer asking whether to adopt AI. They are asking how fast they can put it to work safely, at scale, and with measurable outcomes. Take TD SYNNEX, for example. TD SYNNEX is turning “AI-ready” into a repeatable channel motion by connecting devices, cloud, and security into its “Better Together” approach. Instead of letting customers buy pieces of the stack in silos, the motion guides partners to modernize endpoints, secure the foundation, and then adopt Microsoft AI with confidence, at the scale distributors can bring. Across these conversations, a clear pattern is emerging: partners are thinking beyond any single workload or product to drive end-to-end business transformation built on Azure. This is the Frontier narrative coming to life in the market. Continue reading here102Views0likes0Comments