Infrastructure as code makes cloud environments repeatable, but repeatability does not automatically make deployments safe. A small Bicep change can have consequences far beyond the…

Microsoft is testing new AI-powered workplace devices under Project Solara, aiming to create agent-first experiences that move AI interactions beyond traditional PCs and applications.

The post Microsoft Developing AI Devices Designed Specifically for AI Agents appeared first on Cloud Wars.

As demand for cloud and AI services continues to grow, datacenters are becoming more essential than ever. Communities also want to better understand how this infrastructure affects local resources, particularly water. At Microsoft, water stewardship has been a priority since our first datacenter builds in the early 2000s and remains a core part of our strategy today and into the future. It underpins both our Community-First AI Infrastructure initiative and our company-wide commitment to become water positive by 2030, meaning we will replenish more water than we withdraw. We are pairing our progress with continued transparency so people can understand not only how much water we use, but also how we are working to reduce that use over time.

Through continuous innovation and advancements in cooling technologies, we have improved our water use effectiveness (WUE), measured in liters per kilowatt-hour (L/kWh), by nearly 90% since our first generation of datacenters in the early 2000s. Our average WUE has from 2.3 L/kWh to 0.27 L/kWh in 2025, reflecting decades of innovation and our ongoing commitment to reducing the water intensity of our datacenters while meeting the growing demand for cloud and AI services.

Across our entire owned fleet of datacenters, we are committed as a company to a 40 percent improvement in datacenter water-use intensity by 2030. As of 2025, we have reduced our water-use intensity by 25 percent, putting us well over halfway toward our goal. This strong progress reflects the impact of our continued investments in water-efficient cooling technologies, operational improvements and responsible water management practices.*

In FY25, Microsoft reached an important milestone toward its 2030 water positive commitment, replenishing more water than it withdrew across its global operations for the year. We have made this progress by decoupling datacenter growth from water use through resilient, responsible water stewardship practices and the deployment of increasingly efficient cooling technologies — demonstrating that digital growth and sustainable water management can advance together. We are committed to building on this progress and working toward sustaining water positive performance over time as we continue advancing toward our 2030 goal.

Early water stewardship by design

Beginning with some of our earliest datacenter designs, we prioritized water efficiency while minimizing impacts on energy use through the deployment of high-efficiency economizing chillers operating at elevated water temperatures. As early as 2008, we adopted direct air cooling with evaporative assist as the primary cooling approach across our datacenter fleet. This design uses significantly less electricity and up to 90% less water than traditional water-based cooling systems by relying on water only when outside temperatures exceed 85°F (29.4°C). As a result, approximately 90% of our 2025 owned fleet operates using highly efficient, low- to zero-water cooling systems.

While the majority of our existing datacenters are already highly water efficient, we did not stop there. In 2024, Microsoft introduced a new datacenter design optimized for AI workloads that consumes zero water for cooling during operations, further reinforcing our commitment to water stewardship by design. This chip-level cooling solution delivers precise zonal temperature control without water evaporation by recirculating water through a closed-loop, direct-to-chip cooling system. As our datacenter fleet continues to expand, the addition of these zero-water designs will further reduce Microsoft’s water use intensity over time.

Modernizing cooling in existing datacenters with smarter controls

Design innovation is only part of the story. We are also improving the efficiency of existing facilities that use water through a continuous focus on optimizing temperature and humidity setpoints, enabling more precise environmental control and eliminating overcooling. In addition, we regularly audit water use and compare actuals against design expectations using real-time weather data and operational analytics. This helps ensure our datacenters are performing as intended and enables us to quickly identify and address any unexpected water use. These efforts, combined with ongoing hardware and operational improvements, are all aimed at using as little water as possible.

Specifically in our Phoenix, Arizona, datacenters, implementation of these advancements led to a 23% year-over-year improvement in WUE in FY25 alone. We are now deploying these advancements across our direct-evaporatively cooled datacenters globally.

Operational improvements like these are one reason Microsoft has been able to report significant long-term reductions in water intensity across datacenter generations. They also point to the next phase of our work: expanding the use of recycled and alternative water sources wherever possible.

Leveraging recycled, reused and non-potable water

In addition to driving efficiency, we also prioritize using recycled, reused or non-potable water wherever possible in our operations. We have expanded the use of these non-potable water sources in some of our most water-intensive regions, helping reduce demand on freshwater supplies. For example, in Quincy, Washington, Singapore and San Antonio, Texas, three of our key locations for advancing water stewardship, we leverage 74%, 99% and 79% recycled, reused or non-potable water sources, respectively.

Rainwater harvesting systems are now operational at select datacenters in the Netherlands, Sweden and Ireland, with additional installations planned in Canada, the United Kingdom, Finland, Italy, South Africa and Austria. To illustrate the potential impact, Microsoft’s new datacenters in Quebec are expected to collect up to of rainwater annually, depending on local precipitation levels. This water can be used to further offset the already low water withdrawal at these sites. Expanding the use of alternative water sources in this way helps reduce pressure on municipal water supplies while supporting efficient datacenter operations.

As needed, we implement on-site water treatment systems that enable facilities to recycle water multiple times for cooling operations. These systems produce purified water suitable for reuse within cooling systems, reducing overall dependence on utility water supplies. Together, these efforts demonstrate how engineering innovation and operational excellence can work in concert to meaningfully reduce water use at the facility level.

Advancing water stewardship through investment and community partnership

We work closely with local utilities to reduce strain on community resources, and plan ahead for the sourcing and infrastructure needs associated with our operations. Beyond our operations, Microsoft’s Datacenter Community Pledge commits us to protecting local watersheds, engaging stakeholders and investing in projects that strengthen regional water resilience — helping ensure datacenter growth supports both environmental sustainability and long-term community well-being. Where system improvements are required, Microsoft funds those upgrades in full so communities do not have to shoulder the cost of supporting our operations.

Beyond our own footprint, we invest directly in community water infrastructure by modernizing water systems, expanding access, increasing reliability and helping utilities maintain stable rates and pressure. These investments create shared value for both Microsoft and the local communities we work closely with by strengthening critical infrastructure and supporting long-term water resilience. For example, near our datacenter in Leesburg, Virginia, Microsoft is funding more than $25 million in water and sewer improvements to help ensure that the cost of serving our facilities does not fall on local ratepayers. Since 2020, we have invested more than $500 million in more than 75 water and wastewater infrastructure projects that deliver meaningful community co-benefits.

Replenishment

Finally, we pair all of this work with our broader water positive commitment, our goal to replenish more water than we withdraw by 2030, while advancing our Community-First AI Infrastructure approach, which prioritizes delivering measurable benefits to the communities where we operate. This approach extends across our entire datacenter footprint, including leased facilities. In FY25, we replenished more water than we withdrew globally, marking a significant milestone in our water stewardship journey.**

We prioritize and pursue projects designed to deliver meaningful water contribution to each local community. For example, in the greater Phoenix area and nearby Nevada communities, we partner with FIDO Tech and local utilities to deploy AI-enabled leak-detection that identifies and repairs hidden breaks in aging water systems. By preventing water loss before it occurs, these efforts help keep more water in circulation, improving reliability for residents and effectively increasing the amount of usable water available across the system.

Across the Midwest, we work with The Nature Conservancy to restore historic oxbow wetlands — crescent-shaped water bodies that naturally recharge groundwater, reduce flood risk and enhance habitat for native species. These wetlands act as natural reservoirs, capturing and slowly returning water to local aquifers over time. The goal is to create more stable water availability for agriculture, healthier ecosystems and increased resilience for nearby communities throughout the year.

Looking ahead

As water challenges become increasingly complex around the world, Microsoft remains deeply committed to protecting water as a vital natural resource. We continue to advance datacenter innovations that reduce water use intensity while supporting the growing performance demands of cloud and AI services. Through zero-water cooling designs optimized for AI workloads, water reuse initiatives both on and off our campuses and community-focused stewardship programs, we are working toward a future where digital growth and responsible water management go hand in hand.

We are also exploring zonal cooling architectures that more precisely align cooling approaches with the needs of different hardware types, improving efficiency while supporting a diverse mix of AI and traditional workloads.

Datacenters are essential infrastructure for the digital economy, and we believe they should be built and operated in ways that benefit the communities they serve. Over the last decade, we have demonstrated that technological advancement and environmental stewardship can progress together, and we remain committed to continuing that journey as we build the datacenters of the future.

Top image caption: Aerial view of Microsoft datacenter campus in Wisconsin

Judy Priest leads technology strategy, innovation and research for Microsoft’s global cloud and AI infrastructure, driving advances in datacenter architecture, sustainability, power, cooling, energy and emerging technologies that enable reliable, scalable services.

Steve Solomon is a professional engineer leading the engineering strategy behind the company’s global cloud and AI infrastructure. He specializes in datacenter design, sustainability, power and cooling innovation, helping advance reliable, efficient and community-focused infrastructure at hyperscale.

*Footnote 1: Measured as water withdrawals per megawatt (MW); based on a 2022 baseline.

**Footnote 2: To understand how Microsoft calculates and tracks water replenishment data, please refer to our FY 2024 Environmental Data Fact Sheet.

The post Inside Microsoft’s two-decade push to cut water intensity while scaling for growth appeared first on The Official Microsoft Blog.

In 2025, if you weren’t building with MCP, you weren’t serious about agents. The Model Context Protocol dominated the agent conversation for the better part of the year. Conference talks, roadmaps, hiring plans, all of it revolved around MCP.

Then late 2025 into 2026, AI Skills arrived and the backlash was immediate. Engineers declared MCP dead in favor of Skills, then dead in favor of CLI. Perplexity’s CTO said publicly that the company was deprioritizing it. The cycle was fast, loud, and predictable. New tool, new hype, new rewrite.

I started pushing Agent Experience early in 2025, while MCP was still the center of gravity. The response was mostly skepticism. AX was overthinking it. MCP was the only layer that mattered. That perspective aged poorly. The people who dismissed AX weren’t wrong about MCP being useful. They were wrong about a protocol being a strategy.

The thing they missed, and what I think most of the industry is still missing, is that the protocol is not the thing to get good at. The discipline is.

We keep falling into the tool trap

Our industry has a well-documented habit of confusing tools with strategy. We did it with microservices, Kubernetes, and GraphQL. Now we’re doing it with agent protocols.

MCP, AI Skills, A2A, and ACP are all implementations. They matter and they solve real problems. But none of them are the right thing to build your strategy on top of. They are, by nature, the thing that changes.

When you organize your agent strategy around a specific protocol, you’re building on a foundation someone else controls and the market can shift away from at any moment. Worse, you’re skipping the step that would tell you whether that protocol is even the right fit for your use case.

This is the tool trap. You optimize your usage of a specific integration mechanism without first understanding what you’re actually optimizing for.

So what is Agent Experience?

Agent Experience (AX) is the discipline of studying how AI agents discover, understand, and interact with your systems, and then systematically improving those interactions.

Think of it as the agent-facing counterpart to User Experience. UX didn’t emerge because one UI framework won. It emerged because teams realized that the quality of human interaction with software was a design problem that transcended any particular technology. You could build a terrible experience in React just as easily as in vanilla JavaScript. The framework was not the variable. The design thinking was.

AX works the same way. How does an agent discover what your service can do? How does it understand the boundaries of your API? When it fails, does it get enough context to recover? Is the interaction efficient, or is the agent burning tokens on unnecessary round trips?

These questions are protocol-agnostic. They apply whether you expose capabilities through MCP, Skills, A2A, or something that hasn’t been invented yet. The teams that can answer them will adapt to whatever comes next because they understand the problem space, not just the current toolchain.

AX is an extension of what you already care about

AX is not competing with User Experience, Developer Experience, or Customer Experience. It’s an extension of all three.

Your primary focus is still providing a great experience to your customers. What has changed is how those customers interact with you. More and more, they delegate tasks to agents. When a customer asks an agent to integrate with your API, deploy to your platform, or pull data from your service, that agent is acting on their behalf. The agent’s experience determines how likely it is to achieve your customer’s goal.

If a customer’s agent struggles to authenticate, burns through tokens parsing your error messages, or fails silently because your API lacks context, something worse than a complaint happens. The agent will quietly start using an alternative service that provides a better experience. Your customer might not even notice the switch. You just lost them without a single support ticket.

UX optimized for humans clicking through interfaces. DX optimized for developers building on your platform. CX looked at the entire customer journey. AX extends that thinking to the agents those customers now send on their behalf.

The protocol treadmill doesn’t work

Think about what actually happened with MCP. Teams invested heavily in writing MCP server implementations. A lot of those implementations were mediocre. Not because MCP was flawed but because the teams hadn’t thought carefully about what an agent actually needed from their system. A 2026 study out of Queen’s University examined 856 tools across 103 MCP servers and found that 97.1% of tool descriptions contained at least one quality issue, with 56% failing to state their purpose clearly. The protocol worked fine. The experience design was the problem.

When Skills emerged, those same teams faced a familiar problem wearing new clothes. They still hadn’t answered the foundational questions: What does an agent need to accomplish with our service? What is the minimum viable interaction surface? What context does an agent need to make good decisions?

The teams that had worked through those questions adapted fast. Migrating from one protocol to another is mechanical when you already know what your agent-facing interface should look like. The protocol is the serialization format. The experience design is the hard part.

This pattern will keep repeating. Whether it is the Universal Commerce Protocol, A2A, or whatever lands next, something new will always be gaining traction. If your strategy is to become an expert in each successive protocol, you’re signing up for a treadmill that only speeds up.

What an AX practice looks like

So what does it actually look like to take Agent Experience seriously? If you have ever built a UX research practice or a DX program, this will feel familiar. The steps aren’t new. The persona is.

In talks, I break it down to five steps.

Audit the agents your customers use. Know what’s walking through your front door. Look at your traffic data and logs and figure out what portion of your footprint is agents versus humans, and which agents specifically. Are your customers sending Claude Code? Cursor? Custom agents built on your API? You can’t design for something you haven’t observed. Same reason UX teams run user research. Different method, same motivation.

Identify the use cases customers want to delegate. Not every interaction needs to be agent-optimized. Take that same log data, look at the requests agents are making to your platform, and extrapolate what they were trying to achieve. You can also use AEO data to understand what areas your customers are asking about in agent-facing search. Focus on the highest-value surfaces first. If you have ever prioritized a DX roadmap by looking at what developers actually do with your API, you already know this muscle.

Verify and audit the experience of those interactions. Watch what happens when an agent tries to complete those tasks on your system. Where does it get stuck? Where does it misunderstand what your service offers? This is usability testing. The user is an LLM; the struggle is about context not button placement, but you’re answering the same question: Can they get the job done?

Improve and repeat. Agent capabilities evolve. Models get smarter. New interaction patterns emerge. At Netlify, we’ve found cases where our product works one way but agents universally assume it works another way and never ask. Instead of fighting that assumption, we improved the product to work the way agents expect. The result was more adoption of those agent flows and fewer errors. The teams that treat this as a living practice will outperform those running from one protocol migration to the next.

Automate validation and prevent regressions. Once you have a baseline for what “good” looks like, lock it in. Tools like AXIS, an open source scoring framework, let you run real agents against real scenarios and get a comparable score back. Wire it into CI and catch AX regressions the same way you catch broken tests. This is how you go from anecdotal improvement to measurable, repeatable AX quality.

When you have this practice in place, protocol choices become obvious. You can evaluate new tools on their merits. Does it solve a real friction point you have observed? Does it unlock capabilities you couldn’t achieve before? Or is it just different packaging for something you’re already doing well?

The hard part is familiar

AX is harder to pick up than a new protocol. That is just the reality. Learning MCP or Skills is a bounded technical problem. Read the docs, write some code, and ship an integration. Clear finish line, easy to show progress. That’s genuinely appealing, especially when you or your teams are moving fast.

Building an AX discipline means sitting with ambiguity for a while. Studying agent behavior before you have clean answers. Accepting that the right integration strategy depends on context you have to discover, not a tutorial you can follow. But if you’ve ever built a UX or DX practice from scratch, you’ve been here before. The why is the same: understand your users, reduce friction, and make it easy for them to succeed. How you do it is different because the user is different. The discipline isn’t new. It’s an extension of work our industry has been doing for decades.

The good news is that this thinking is gaining momentum. John Maeda’s 2026 Design in Tech Report is explicitly about the shift from UX to AX. Researchers are studying agent interaction quality as a first-class engineering concern. BCG and MIT Sloan found that 35% of organizations are already using agentic AI, with another 44% planning to. The question is no longer whether AX matters. It’s whether your team is building the practice before your competitors do.

The agents of 2028 won’t interact with your systems the way the agents of 2025 did. The protocols will be different. The capabilities will be different. The expectations will be different. What won’t change is the fundamental need for your systems to provide a great experience to the people who use them, and now, the agents those people send on their behalf.

Get good at that. The rest is implementation detail.

Is the web dead, or just evolving? Wes Bos breaks down his JS Nation Amsterdam talk on agentic interfaces, why chat won’t replace everything, how Web MCP lets agents interact with your existing sites, and what “Clicks and Clankers” really means for the future of UI.

Show Notes

• 00:00 Intro
• 00:33 Welcome to Syntax!
• 00:46 Wes’s Talk: Agentic Interfaces at JS Nation
• 01:37 Is the Web Dead? Chat vs. Traditional UI
• 03:13 No UI, Voice UI, and the Smart Home Vision
• 04:00 What Is Web MCP and How It Works
• 05:10 Clicks and Clankers: When to Click vs. Prompt
• 06:57 The Future of Shopping and the Open Web Problem
• 08:46 Delegating the Boring Stuff: Groceries and Expense Categorization
• 11:55 MCP Apps and the Happy Path Problem
• 12:55 Brought to you by Sentry.io
• 13:23 Generative UI: Can the LLM Make a Better UI Than You?
• 14:54 Smart Home Dashboards and the Jarvis Dream
• 17:24 Is the Web Dead? Final Thoughts

Hit us up on Socials!

Syntax: X Instagram Tiktok LinkedIn Threads

Wes: X Instagram Tiktok LinkedIn Threads

Scott: X Instagram Tiktok LinkedIn Threads

Randy: X Instagram YouTube Threads

Download audio: https://traffic.megaphone.fm/FSI6751998324.mp3

Olaitan Fashanu: Three Teams, Three Backlogs, One Feature—Can You Make Them See Each Other?

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

 

"How do we ensure that these teams actually work together to show the same data?" - Olaitan Fashanu

 

Olaitan brings a problem most Scrum Masters in scaled environments will recognize. Three teams. Three separate backlogs. One product, accessed across app, web, and support channels. Leadership made a top-down team topologies decision: split the work to move faster. Predictable result—each team optimizes for their own backlog, blind to what the others are building, sometimes shipping the same feature twice with different behaviors. The product owners know there's overlap. The teams love the idea of linking tickets across backlogs. They just won't maintain the habit. Olaitan and Vasco walk through experiments together: a sync between POs, joint refinement sessions, linking tickets, putting "this is also being built by Team B" notes at the top of stories. The deeper insight: the Scrum Master's job is to keep surfacing information until a habit forms. As Vasco's old lifting coach put it—you find the imbalance, you get rid of the imbalance, one by one. That's how you get stronger.

 

In this episode, we refer to team topologies and the practice of surfacing information across team boundaries.

 

Self-reflection Question: Where in your organization are teams unknowingly building the same thing twice—and what's the smallest experiment you could run this week to make that visible?

 

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

 

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

 

Buy Now on Amazon

 

[The Scrum Master Toolbox Podcast Recommends]

 

About Olaitan Fashanu

 

Olaitan Fashanu is a customer-focused professional with expertise in product management, technology, and coaching. He drives digital and agile transformation, builds collaborative cross-functional teams, and delivers high-quality products across markets. Curious and strategic, he explores AI and data intelligence while balancing technical depth, business goals, culture, structure, and long-term vision.

 

You can link with Olaitan Fashanu on LinkedIn.

 

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20260624_Olaitan_Fashanu_W.mp3?dest-id=246429