GitHub is readying a new feature to automate some of the most expensive work in DevOps: the invisible housekeeping no one wants to own. Developers would rather be building features than debugging flaky continuous integration (CI) pipelines, triaging low-quality issues, updating outdated documentation, or closing persistent gaps in test coverage.

In order to help developers and enterprises manage the operational drag of maintaining repositories, GitHub is previewing Agentic Workflows, a new feature that uses AI to automate most routine tasks associated with repository hygiene.

It won’t solve maintenance problems all by itself, though.

Developers will still have to describe the automation workflows in natural language that agents can follow, storing the instructions as Markdown files in the repo created either from the terminal via the GitHub CLI or inside an editor such as Visual Studio Code.

Then, they’ll have to connect up whichever large language model (LLM) and vibe coding tool they want the agent to use — available options include GitHub Copilot, Claude, or OpenAI Codex — and set guard rails defining what the agent is allowed to read, what it can propose, and which events (issues, pull requests, scheduled runs) should trigger it.

Once committed, the workflows execute on GitHub Actions like any other automation, with the agents’ decisions and proposed changes surfacing as issue comments, pull requests, and CI logs for developers to review.

These automated workflows should reduce the cognitive tax around maintenance work for developers, GitHub executives wrote in a blog post about Github Agentic Workflows.

Can productivity gains scale?

Analysts see immediate productivity gains for developers as well as engineering heads, especially in the form of fewer stalled builds, faster root-cause analysis, and cleaner repositories that quietly improve delivery velocity with the same headcount.

“Mid-sized engineering teams gain immediate productivity benefits because they struggle most with repetitive maintenance work like triage and documentation drift,” said Dion Hinchcliffe, VP of the CIO practice at The Futurum Group.

Another reason for gaining productivity is Agentic Workflows’ use of intent-based Markdown instead of YAML which makes authoring faster for developers, Hinchcliffe added.

However, Advait Patel, a senior site reliability engineer at Broadcom, cautioned that though intent-based Markdown makes authoring workflows quicker, it can also reduce precision: “YAML is annoying, but it is explicit. Natural language can be interpreted differently by different models or versions.”

Similarly, Hinchcliffe pointed out that there is also a risk of these workflows generating excessive low-value pull requests (PRs) or issue noise, especially if they are unattended or unmanaged.

Compounding compute cost

Patel also warned that beyond precision and signal-to-noise concerns, there is a more prosaic risk teams may underestimate at first: As agentic workflows scale across repositories and run more frequently, the underlying compute and model-inference costs can quietly compound, turning what looks like a productivity boost into a growing operational line item if left unchecked.

This can become a boardroom issue for engineering heads and CIOs because they must justify return on investment, especially at a time when they are grappling with what it really means to let software agents operate inside production workflows, Patel added.

In addition, Shelly DeMotte Kramer, principal analyst at Kramer & Company, warned that GitHub’s approach could also deepen platform dependence for both developers and CIOs, effectively nudging teams toward tighter lock-in with Agentic Workflows.

“By embedding agents natively into GitHub Actions rather than bolting them on externally they’re creating switching costs that go beyond tooling familiarity. This is, and will be challenging, and create a bit of a lock-in situation, as you can’t easily port a Markdown-based agentic workflow to GitLab because the execution engine, permissions model, and safe outputs architecture are GitHub-native,” Kramer said.

A push for greater control

That strategic play, Kramer added, reflects GitHub’s push to exert greater control over developer workflows, betting that ownership of the automation layer of the software development lifecycle will shape how software teams operate, giving it an edge over rivals.

However, the analyst expects to see rivals like GitLab and Atlassian to respond soon with similar offerings: “The interesting question is whether they build native agentic runtimes or simply become MCP-compatible surfaces that third-party agents can drive.”

Given that MCP just moved to the Linux Foundation, that second path may “actually accelerate faster than GitHub’s proprietary approach”, Kramer added.

Analysts also see issues around security, especially in the context of regulated industries, despite Agentic Workflows offering security capabilities such as least privilege and sandboxed execution.

“To begin with, GitHub describes network isolation but doesn’t specify whether workflow execution environments are FedRAMP-authorized, which is critical for US government-related work, or whether audit logs meet HIPAA’s required retention and access control standards, which is critical for healthcare in the US,” Kramer said.

Security concerns

GitHub also does not specify whether the agent’s access to repository content, including potentially sensitive code, secrets, or customer data embedded in repos, is governed by data residency requirements, Kramer added.

“For financial services, a full lineage layer is needed, not just a ‘this workflow created this PR’ but a complete record of every API call the agent made, every file it read, and every decision it made. These are all things that need to be addressed,” the analyst noted further.

Although GitHub leaves it to developers and individual teams to decide what automation to write in Agentic Workflows and how far to take it including planning autonomous CI/CD, analysts suggest enterprises treat the technical preview as a controlled testing window to evaluate whether the new feature can be absorbed into production environments without breaking governance, security, or cost discipline.

“For CIOs, this is the learning phase: Establish controlled pilots in non-critical repositories, develop governance patterns early, and prepare for broader adoption once auditability and operational predictability stabilize,” Hinchcliffe said.

To rein in costs and quantify ROI, CIOs can set budget caps, tier LLM choices, and closely track ‘run’ frequency and AI request volumes, then benchmark those costs against reclaimed developer time and reduced operational delays, Hinchcliffe added.

For developers, analysts said, this could mark a shift in culture and performance metrics.

“Developer culture will evolve toward supervising automation rather than executing routine tasks. This may shift developers toward architecture, design decisions, and higher-value problem solving,” Hinchcliffe said.

“Team structures will place greater emphasis on platform engineering and automation stewardship, while performance metrics move away from activity measures toward outcomes such as cycle time, reliability, and engineering effectiveness per developer,” the analyst added.

Critical and high-severity vulnerabilities were found in four widely used Visual Studio Code extensions with a combined 128 million downloads, exposing developers to file theft, remote code execution, and local network reconnaissance.

Application security company OX Security published the findings this week, saying it had begun notifying vendors in June 2025 but received no response from three of the four maintainers.

Three CVEs, CVE-2025-65717, CVE-2025-65715, and CVE-2025-65716, were formally assigned and published on February 16.

VS Code extensions are add-ons that expand the functionality of Microsoft’s widely used code editor, adding capabilities such as language support, debugging tools, live preview, and code execution. They run with broad access to local files, terminals, and network resources, which is what made these vulnerabilities consequential.

Unlike the rogue extensions that threat actors have repeatedly planted in the VS Code marketplace, these flaws resided in legitimate, widely installed tools, meaning developers had no reason to suspect them, OX Security said in an advisory.

“Our research demonstrates that a hacker needs only one malicious extension, or a single vulnerability within one extension, to perform lateral movement and compromise entire organizations,” the advisory added.

The vulnerabilities also affected Cursor and Windsurf, the AI-powered IDEs built on VS Code’s extension infrastructure.

OX Security published individual advisories for each flaw, detailing how each could be exploited and what an attacker could achieve.

How the attacks worked

The most severe flaw, CVE-2025-65717 (critical), was in Live Server, a 72-million-download extension that launches a local HTTP server for real-time browser previews. OX Security found the server was reachable from any web page a developer visited while it was running, not just their own browser.

“Attackers only need to send a malicious link to the victim while Live Server is running in the background,” OX Security researchers Moshe Siman Tov Bustan and Nir Zadok wrote in an advisory.

CVE-2025-65715 (high severity) affected Code Runner, with 37 million downloads. The extension reads execution commands from a global configuration file, and OX Security found a crafted entry that was enough to trigger arbitrary code execution, including reverse shells. An attacker could place it by phishing a developer into pasting a malicious snippet, or through a compromised extension that modified the file silently.

CVE-2025-65716 (CVSS 8.8) affected Markdown Preview Enhanced, with 8.5 million downloads. Simply opening an untrusted Markdown file was enough to trigger it. “A malicious Markdown file could trigger scripts or embedded content that collects information about open ports on the victim’s machine,” the researchers noted.

Microsoft quietly patched its own extension

The fourth vulnerability played out differently. Microsoft’s Live Preview extension, with 11 million downloads, contained a cross-site scripting flaw that, according to OX Security, let a malicious web page enumerate files in the root of a developer’s machine and exfiltrate credentials, access keys, and other secrets.

The researchers reported the issue to Microsoft on August 7. Microsoft initially rated it as low severity, citing required user interaction.

“However, on September 11, 2025 — without notifying us — Microsoft quietly released a patch addressing the XSS security issues we reported. We only recently discovered that this patch had been deployed,” the researchers added.

No CVE was assigned to this vulnerability. “Users with Live Preview installed should update to version 0.4.16 or later immediately,” the researchers suggested.

Microsoft did not immediately respond to a request for comment.

Taken together, the four flaws pointed to a broader problem with how developer tools are secured and maintained.

What security teams should do

“These vulnerabilities confirm that IDEs are the weakest link in an organization’s supply chain security,” the researchers at OX Security said in the advisory.

Developer workstations routinely hold API keys, cloud credentials, database connection strings, and SSH keys. OX Security warned that a successful exfiltration from a single machine could give an attacker access to an organization’s broader infrastructure and that the risks extended to lateral movement and full system takeover.

The researchers advised developers to disable extensions not actively in use and avoid browsing untrusted sites while localhost servers are running. They also cautioned against applying configuration snippets from unverified sources to VS Code’s global settings.

Mistral AI has acquired Paris-based cloud startup Koyeb, marking the model-maker’s first acquisition and entry into the enterprise infrastructure market.

This suggests a strategic shift for the French company, which has built its reputation on frontier models but is now investing heavily in compute capabilities and expanded deployment options.

The acquisition folds Koyeb’s serverless deployment platform into Mistral Compute, the company’s AI cloud offering launched last year, as Mistral shapes up to be a sovereign European alternative for enterprises running AI workloads at scale. Mistral has been betting on its “open weight” large language models as a point of differentiation. In a recent interview with Bloomberg, Mistral CEO Arthur Mensch said Europe is betting “actively and heavily” on open source.

Mistral recently pledged to invest 1.2 billion euros in AI data center infrastructure in Sweden, underscoring its broader push into compute and digital infrastructure.

In a LinkedIn post, the company said the move “strengthens our Compute capabilities and accelerates our mission to build a full-stack AI champion.”

The move also signals a wider market trend of model providers racing to control more of the stack, from infrastructure and inference to deployment and optimization, to lock in enterprise customers and capture higher margins.

For enterprise IT leaders, the question is whether this marks the emergence of a viable alternative to US cloud giants for AI workloads, or simply a tighter vertical integration play aimed at improving margins and performance.

Full-stack AI push

Analysts say the acquisition reflects a deliberate shift toward vertical integration, with Mistral seeking greater control over key layers of the AI stack, from infrastructure and middleware to models. That positioning brings the company closer to what some of them describe as an “AI hyperscaler,” though with a narrower focus.

“Mistral gets a step-up in its progress toward full-stack capabilities,” said Prabhu Ram, VP of the industry research group at Cybermedia Research. “The Koyeb acquisition bolsters Mistral Compute, enabling better on-premises deployments, GPU optimization, and AI inference scaling. Koyeb elevates Mistral’s hybrid support, appealing to regulated US and European enterprises.”

For enterprise buyers, hybrid and on-premises flexibility is increasingly important, particularly in regulated sectors where data residency and latency requirements limit full reliance on public cloud providers.

Still, analysts caution that Mistral remains more specialized than general-purpose cloud providers such as Microsoft, Google, or Amazon Web Services. Its infrastructure footprint and capital expenditure profile are significantly smaller, shaping how it competes.

“Mistral AI’s modest CAPEX compared with the big AI hyperscalers makes Koyeb’s acquisition important, as it adds the capability to offer more efficient and cost-effective inference scaling for enterprises focused on specialized AI tasks,” said Neil Shah, VP for research at Counterpoint Research. “Whether Mistral AI can expand this capability to compete with general-purpose AI inference from hyperscale providers across enterprise and consumer markets seems unlikely at this point.”

Shah added that Mistral’s European roots position it strongly in sovereign AI deployments for enterprises and public sector organizations, where serverless architecture and localized control can be differentiators.

At the same time, structural challenges also remain. Ram noted that ecosystem maturity, GPU access, execution depth, and cost efficiency are still areas where Mistral trails larger hyperscalers. For CIOs evaluating long-term AI infrastructure bets, those factors may weigh as heavily as model performance.

Remember the good old days when we had “Internet time”? It was back in the late 1990s, when the dot-coms moved so fast that building businesses and fortunes would take only months instead of years.

Seems so quaint now.

I think we are now living in AI time. It seems like today, things that used to take months are now taking weeks—or even days. Shoot, you might even say hours.

My head is spinning with how much change has happened in—literally—the last few weeks. It almost feels like we woke up one morning and just stopped writing code. And of course, this has everyone freaking out. Developers are worried about massive layoffs and what junior developers are going to do, and if there will even be any junior developers at all.

It all seemed to culminate in this article by Matt Shumer, “Something Big is Happening,” which went viral last week. (It’s not often that an article on the .dev domain makes it to the top of the Drudge Report.)

Shumer tapped into those fears. And he’s right to. The fear isn’t irrational—it’s the natural response to watching a job that you’ve spent years mastering get handed off to a machine. That’s a real loss, even if what comes next turns out to be better.

Last month I wrote about how code is no longer the bottleneck. I pointed out how choosing what to build will become even harder when we can build 20 things instead of just two.

If you are hesitant to let AI write your code for you because it makes mistakes or doesn’t write code exactly the way you like it written, consider this: The same is true of any other developer on your team. No other person will write code that is mistake-free and architected exactly like you want things done. You don’t hesitate to delegate tasks to fellow developers, so why do you hesitate to pass a task to a tireless coder who builds things hundreds(!) of times faster than any human?

And it’s the “hundreds of times” faster that has everyone nervous. And they have a right to be. Many companies—Salesforce, Amazon, Microsoft, and more—are laying off people, citing automation and AI efficiencies among the reasons. Things are starting to change, and there are many people whose lives will be affected. There is reason for concern.

But there is reason for optimism in the turmoil. Garry Tan, the CEO of YCombinator, recently said, “Our fear of the future is directly proportional to how small our ambitions are.” I don’t want to minimize the trauma of getting laid off, but the thing that is causing people to be laid off is also the thing that will cause an explosion of new ideas. And those new ideas will lead to new jobs.

For a while now, I’ve been keeping a list of silly, goofy, and maybe brilliant ideas for apps and websites. Some are simple, and some are ambitious, but every one of them required more time to implement than I had when the idea struck. Now? I built one of them this past weekend. Actually, I built it on Sunday afternoon.

Now, I’m not saying I’m ready to quit my day job, but imagine if the barrier to implementing an idea goes from “It will take me six months of evenings and weekends to build this” to “It will be done before I can cook dinner.” Lots of people out there are going to have an idea that will enable them to quit their day job and hire people to make the business a reality. Instead of 10 new digital companies starting up every week, will there be 100, or 1,000? The opportunity seems endless.

And not only will we have new job titles and new things to do, but we’ll be creating things that no one has thought up yet. “Let a hundred flowers bloom” will turn into “Let a million flowers bloom.”

Now that we are moving in AI time, ideas won’t wait for permission anymore. They can bloom almost the moment you think of them.

Docker is a software platform for building applications based on containers—small and lightweight execution environments that make shared use of the operating system kernel but otherwise run in isolation from one another. While containers have been used in Linux and Unix systems for some time, Docker, an open source project launched in 2013, helped popularize the technology by making it easier than ever for developers to package their software to “build once and run anywhere.”

A brief history of Docker

Founded as DotCloud in 2008 by Solomon Hykes in Paris, what we now know as Docker started out as a platform as a service (PaaS) before pivoting in 2013 to focus on democratizing the underlying software containers its platform was running on.

Hykes first demoed Docker at PyCon in March 2013, explaining that Docker was created because developers kept asking for the underlying technology powering the DotCloud platform. “We did always think it would be cool to be able to say, ‘Yes, here is our low-level piece. Now you can do Linux containers with us and go do whatever you want, go build your platform.’ So that’s what we are doing.”

And so, Docker was born, with the open source project quickly picking up traction with developers and attracting the attention of high-profile technology providers like Microsoft, IBM, and Red Hat, as well as venture capitalists willing to pump millions of dollars into the innovative startup. The container revolution had begun.

What are containers?

As Hykes described it in his PyCon talk, containers are “self-contained units of software you can deliver from a server over there to a server over there, from your laptop to EC2 to a bare-metal giant server, and it will run in the same way because it is isolated at the process level and has its own file system.”

The components for doing this have long existed in operating systems like Linux. By simplifying their use and giving these bits a common interface, Docker quickly became close to a de facto industry standard for containers. Docker let developers deploy, replicate, move, and back up a workload in a single, streamlined way, using a set of reusable images to make workloads more portable and flexible than previously possible.

Also see: Why you should use Docker and OCI containers.

In the virtual machine (VM) world, something similar could be achieved by keeping applications separate while running on the same hardware. But each VM requires its own operating system, meaning VMs are typically large, slow to start up, difficult to move around, and cumbersome to maintain and upgrade.

Containers represent a defined shift from the VM era, in that they isolate execution environments while sharing the underlying OS kernel. As a result, they are speedier and far more lightweight than VMs.

Docker: The component parts

Docker took off with software developers as a novel way to package the tools required to build and launch a container. It was more streamlined and simplified than anything previously possible. Broken down into its component parts, Docker consists of the following:

• Dockerfile: Each Docker container starts with a Dockerfile. This text file provides a set of instructions to build a Docker image, including the operating system, languages, environmental variables, file locations, network ports, and any other components it needs to run. Provide someone with a Dockerfile and they can recreate the Docker image wherever they please, although the build process takes time and system resources.
• Docker image: Like a snapshot in the VM world, a Docker image is a portable, read-only executable file. It contains the instructions for creating a container and the specifications for which software components to run and how the container will run them. Docker images are far larger than Dockerfiles but require no build step: They can boot and run as-is.
• Docker run utility: Docker’s run utility is the command that launches a container. Each container is an instance of an image, and multiple instances of the same image can be run simultaneously.
• Docker Hub: Docker Hub is a repository where container images can be stored, shared, and managed. Think of it as Docker’s own version of GitHub, but specifically for containers.
• Docker Engine: Docker Engine is the core of Docker. It is the underlying client-server technology that creates and runs the containers. The Docker Engine includes a long-running daemon process called dockerd for managing containers, APIs that allow programs to communicate with the Docker daemon, and a command-line interface.
• Docker Compose: Docker Compose is a command-line tool that uses YAML files to define and run multicontainer Docker applications. It allows you to create, start, stop, and rebuild all the services from your configuration and view the status and log output of all running services.
• Docker Desktop: All of these component parts are wrapped in Docker’s Desktop application, providing a user-friendly way to build and share containerized applications and microservices.

Advantages of Docker

Docker containers provide a way to build applications that are easier to assemble, maintain, and move around than previous methods allowed. That provides several advantages to software developers:

• Docker containers are minimalistic and enable portability: Docker helps to keep applications and their environments clean and minimal by isolating them, which allows for more granular control and greater portability.
• Docker containers enable composability: Containers make it easier for developers to compose the building blocks of an application into a modular unit with easily interchangeable parts, which can speed up development cycles, feature releases, and bug fixes.
• Docker containers make orchestration and scaling easier: Because containers are lightweight, developers can launch many of them for better scaling of services, and each container instance launches many times faster than a VM. These clusters of containers do then need to be orchestrated, which is where a platform like Kubernetes typically comes in.

Also see: How to succeed with Kubernetes.

Drawbacks of Docker

Containers solve a great many problems, but they don’t solve them all. Common complaints about Docker include the following:

• Docker containers are not virtual machines: Unlike virtual machines, containers use controlled portions of the host operating system’s resources, which means elements aren’t as strictly isolated as they would be on a VM.
• Docker containers don’t provide bare-metal speed: Containers are significantly more lightweight and closer to the metal than virtual machines, but they do incur some performance overhead. If your workload requires bare-metal speed, a container will get you close but not all the way there.
• Docker containers are stateless and immutable: Containers boot and run from an image that describes their contents. That image is immutable by default—once created, it doesn’t change. But a container instance is transient. Once removed from system memory, it’s gone forever. If you want your containers to persist state across sessions, like a virtual machine, you need to design for that persistence.

Docker today

Container usage has continued to grow in tandem with cloud-native development, now the dominant model for building and running software. But these days, Docker is only a part of that puzzle.

Docker grew popular because it made it easy to move the code for an application and its dependencies from the developer’s laptop to a server. But the rise of containers led to a shift in the way applications were built—from monolithic stacks to networks of microservices. Soon, many users needed a way to orchestrate and manage groups of containers at scale.

Launched at Google, the Kubernetes open source project quickly emerged as the best way to orchestrate containers, superseding Docker’s own attempts to solve this problem with Docker Swarm (RIP). Amidst increasing funding trouble, Docker eventually sold its enterprise business to Mirantis in 2019, which has since absorbed Docker Enterprise into the Mirantis Kubernetes Engine.

The remains of Docker—which includes the original open source Docker Engine container runtime, Docker Hub image repository, and Docker Desktop application—live on under the leadership of company veteran Scott Johnston, who is looking to reorient the business around its core customer base of software developers.

The Docker Business subscription service, and the revised Docker Desktop product, both reflect those new goals: Docker Business offers tools for managing and rapidly deploying secure Docker instances, and Docker Desktop requires paid usage for organizations with more than $10 million in annual revenue and 250 or more employees. But there’s also the Docker Personal subscription tier, for individuals and companies that fall below those thresholds, so end users still have access to many of Docker’s offerings.

Docker has other offerings suited to the changing times. Docker Hardened Images, available in both free and enterprise tiers, provide application images with smaller attack surfaces and checked software components for better security. And, in step with the AI revolution, the Docker MCP Catalog and Toolkit provide Dockerized versions of tools that give AI applications broader functionality (such as by allowing access to the file system), making it easier to deploy AI apps with less risk to the surrounding environment.

Anthropic has launched Claude Sonnet 4.6, an update to the company’s hybrid reasoning model that brings improvements in coding consistency and instruction following, Anthropic said.

Introduced February 17, Claude Sonnet 4.6 is a full upgrade of the model’s skills across coding, computer use, long-context reasoning, agent planning, design, and knowledge work, according to Anthropic. the model also features a 1M token context window in beta.

With Claude Sonnet 4.6, improvements in consistency, instruction following, and other areas have made developers with early access prefer this release to its predecessor, Claude Sonnet 4.5, by a wide margin, according to Anthropic. Early Sonnet 4.6 users are seeing human-level capability in tasks such as navigating a complex spreadsheet or filling out a multi-step web form, before pulling it all together across multiple browser tabs, said Anthropic. Performance that previously would have required an Anthropic Opus-class model—including on real-world, economically viable office tasks—now is available with Sonnet 4.6. The model also shows a major improvement in computer use skills compared to prior Sonnet models, the company said.

Claude Sonnet 4.6 is available on all Claude plans, Claude Cowork, Claude Code, the Anthropic API, and all major cloud platforms. Developers can get started by using claude-sonnet-4-6 via the Claude API. The model still lags behind the most skilled humans at using computers, Anthropic said. But the rate of progress means that computer use is much more useful for a range of work tasks, and substantially more capable models are within reach, Anthropic said. On the Claude Developer Platform, Sonnet 4.6 supports adaptive thinking and extended thinking, as well as context compaction in beta. Context compaction automatically summarizes older context as conversations approach limits, increasing effective context length, according to the company.

Anthropic also announced updates to its API. Claude’s web search and fetch tools now automatically write and execute code to filter and process search results, keeping only relevant content in context, improving both response quality and token efficiency. Also, code execution, memory, programmatic tool calling, tool search, and tool use examples now are generally available.

World Wide Web Consortium (W3C) participants including Google and Microsoft have launched the WebMCP API, a JavaScript interface that allows web applications to provide client-side “tools” to AI agents. The API would enable agents to interact directly with web pages and participate in collaborative workflows with human users within the same web interface.

WebMCP is available for early preview at Google, said Google’s Andre Cipriani Bandarra, developer relations engineer for Chrome and the web in a February 10 blog post. “WebMCP aims to provide a standard way for exposing structured tools, ensuring AI agents can perform actions on your site with increased speed, reliability, and precision,” Bandarra said.

A draft community group report on WebMCP was published on February 12 by the W3C Web Machine Learning Community Group. The WebMCP API is described in the report as a JavaScript interface that lets web developers expose web application functionality as “tools,” meaning JavaScript functions with natural language descriptions and structured schemas that can be invoked by agents, browser’s agents, and assistive technologies. Web pages that use WebMCP can be viewed as Model Context Protocol (MCP) servers that implement tools in client-side script instead of on the back end, enabling collaborative workflows where users and agents work together within the same web interface, according to the report. Editors of the report include Khusal Sagar and Dominic Farolino of Google and Brandon Walderman of Microsoft. The specification is neither a W3C standard nor on the W3C Standards Track, the report says.

Bandarra cited use cases including customer support, ecommerce, and travel, in which agents help users fill out customer support tickets, shop for products, and book flights. Bandarra cited two proposed APIs as part of WebMCP that allow browser agents to act on behalf of the user: a declarative API that performs standard actions that can be defined directly in HTML forms and an imperative API that performs complex and more dynamic interactions that require JavaScript execution. “These APIs serve as a bridge, making your website ‘agent-ready’ and enabling more reliable and performant agent workflows compared to raw DOM actuation,” said Bandarra.

Alibaba has unveiled Qwen3.5, a new multimodal AI model that the company says is intended to serve as a foundation for digital agents capable of advanced reasoning and tool use across applications.

The release reflects the ongoing shift from standalone chatbot deployments toward AI systems that can execute multi-step workflows and operate with minimal human prompting.

In a blog post, Alibaba highlighted gains across selected benchmarks, claiming Qwen3.5 outperformed earlier versions and competing frontier systems such as GPT-5.2, Claude 4.5 Opus, and Gemini 3 Pro.

The company is releasing the open-weight Qwen3.5-397B-A17B model for developers, while a hosted version, Qwen3.5-Plus, will be available through Alibaba Cloud’s Model Studio platform. The hosted version includes built-in tool capabilities and an expanded context window of up to one million tokens, aimed at enterprise developers building more complex, multi-step applications.

Alibaba also emphasized expanded multilingual support, increasing coverage from 119 to 201 languages and dialects, a move that could appeal to global enterprises operating across diverse markets.

Enterprise AI implications

The release comes amid intensifying competition within China’s AI market.

Last week, ByteDance introduced Doubao 2.0, an upgrade to its chatbot platform that the company also positioned around agent-style capabilities. DeepSeek, whose rapid global rise last year unsettled US tech investors, is widely expected to release its next-generation model soon.

Analysts say Qwen3.5’s improvements in reasoning and other benchmarks are significant, particularly for enterprise use cases.

“In pilot settings, these features help teams explore new interactions and validate feasibility,” said Tulika Sheel, senior vice president at Kadence International. “But in production environments, enterprises will still require robust performance metrics, reliability guarantees, and governance controls before fully trusting these capabilities.”

Sanchit Vir Gogia, chief analyst at Greyhound Research, pointed out that Qwen3.5 is not simply a stronger language model but a workflow-capable system.

“When those capabilities are combined, the system stops behaving like a conversational assistant and starts behaving like an execution layer,” Gogia said. “That is precisely where opportunity and risk converge.”

CIOs considering adoption would look at how consistently the model performs at scale and how smoothly it fits within established governance and infrastructure frameworks.

If the conditions are met, Qwen3.5’s multimodal and agent-oriented capabilities could improve how enterprises automate support functions and manage information across systems where text, images, and structured data interact.

“The value is most tangible in environments that are structured, repetitive, and measurable,” Gogia said. “For instance, procurement validation, invoice to contract matching, supplier onboarding triage, and similar areas where workflows have volume and defined rules.”

Trust and risks

Analysts suggest the biggest hurdle may not be technological advancement but ecosystem maturity and trust, with security concerns continuing to limit global adoption.

“Qwen3.5 excels in multimodal capabilities and offers extensive model selection, including open model options for easier access and customization,” said Anushree Verma, senior director analyst at Gartner. “However, the main challenge for Qwen is its global adoption, which is limited due to restricted commercial availability, distrust of Chinese‑origin models, and a less mature partner ecosystem outside China.”

Gogia added that the evaluation of Qwen3.5 by a US enterprise cannot be reduced to model performance metrics.

“It must be framed as a durability assessment,” Gogia said. “Can this platform remain viable, compliant, and operationally stable across policy volatility?”

Sheel said that compliance with regional regulations, including data residency mandates and privacy laws, must be assessed before deployment. CIOs must also determine who can access or process enterprise data, and whether contractual safeguards and audit mechanisms align with internal governance standards.

When it comes to cloud infrastructure portability, the reigning solutions just don’t live up to their promise. Infrastructure as code (IaC) solutions like Terraform shoehorn nuanced infrastructure into too-broad terms. Cloud provider offerings like Azure Migrate, AWS Migration Services, and Google Cloud Migrate generally don’t translate native workloads into competitors’ clouds. And governance tools are often excellent at alerting users to finops and drift issues, but rarely help users actually fix the issues they flag.

I have outlined these issues in a companion article—I invite you to start there. In this article, I provide an overview of an infrastructure replication methodology, Cloud Cloning, which my colleagues and I at FluidCloud have created to address the challenges above. Below, I’ll explain how Cloud Cloning achieves all this by walking you through how our solution works. 

Capturing the full scope of public cloud setups

As a first step of enabling cloud portability, Cloud Cloning starts with a complete snapshot of the source cloud infrastructure. Cloud Cloning calls the cloud provider’s APIs and scans and captures the complete cloud infrastructure footprint, including the many resources, dependencies, and nuances like VPCs, subnets, firewall rules, and IAM (identity and access management) permissions that the reigning multicloud tools tend to overlook.

To give some context as to what this snapshot achieves, it helps to understand where multicloud tools evolved from. From the beginning, the multicloud field emerged to support migrations from on-prem private clouds up to the public ones. As such, these tools were focused on recreating the two most fundamental primitives of private clouds: VMs and storage. To a large extent, that focus continues today, with leading offerings like AWS Migrate, Azure Migrate, Google Cloud Migrate, Nutanix Move, Veeam, and Zerto focused largely on just these two areas.

The problem is that, when it comes to migrating across public clouds, VMs and storage are only a small part of the picture. Public cloud environments rely on complex architectures with hundreds of services spanning databases, storage buckets, IAM users and permissions, subnets, routing, firewalls, Kubernetes clusters and associated control planes, and a lot more.

By starting with a snapshot of the full infrastructure ecosystem, Cloud Cloning captures a vast amount of the critical cloud elements that conventional tools don’t. In our experience, those other tools tend to capture between 10% and 30% of the source cloud setup, whereas Cloud Cloning captures 60% or more.

Translating from Cloud A to Cloud B

Once Cloud Cloning has captured the full picture of the source cloud infrastructure, the next step is mapping that infrastructure onto the target cloud’s services and configuration model. Because each cloud’s API specifications are so radically different, this translation work is no small feat. Consider just a few examples from three key areas:

• Compute and resource management: Each cloud provider exposes similar compute and networking building blocks, but different semantics. AWS Auto Scaling Groups, Azure VM Scale Sets, and GCP Instance Groups, for instance, behave differently in how they handle availability, placement, and scaling. The same applies to security: AWS security groups are allow-only; Azure uses ordered allow/deny rules with priorities; and GCP defines separate ingress and egress firewall rules. These and other differences make it difficult to reproduce deployments exactly without re-interpreting the underlying intent into the target cloud.
• Storage and data: Storage and data services are not interchangeable across clouds. Block volumes and file systems differ in performance, snapshot behavior, and consistency guarantees. Meanwhile, managed databases such as AWS RDS, Azure SQL / PostgreSQL, and GCP Cloud SQL share engines but diverge in extensions, limits, backup semantics, and failover models. As a result, storage and data layers often need to be re-architected rather than directly replicated.
• Identity and access: IAM is one of the least portable layers across clouds. AWS uses policy-driven roles and users; Azure ties permissions to subscriptions and role assignments; and GCP enforces hierarchical IAM with service accounts at multiple levels. As a result, access models and automation workflows rarely translate directly and must be re-thought for each cloud.

Because the leading cloud migration tools aren’t focused on infrastructure, they’re simply not set up to make these complex translations. As I discuss here, while infrastructure-as-code solutions seem like the perfect cloud-agnostic tool to work around this lack of interoperability, IaC doesn’t really solve this portability problem either. Notably, hyperscaler-native IaC like CloudFormation (AWS) and Bicep (Azure) were developed with particular clouds in mind, and even cloud-agnostic options like Terraform must be custom-tailored to each particular provider. As a result, theoretically cloud-neutral IaC ends up being highly cloud-specific in practice.

As IT professionals well know, the standard path to this translation work is grueling. It involves painstakingly reverse-engineering infrastructure from the source into the target cloud—and often requires separate experts in each cloud to map out the infrastructures together.

Cloud Cloning solves this translation problem—converting configuration fully from one cloud provider into another through its patented cloud mapping technology. Thus, for one representative example, it can start with an active cloud-native AWS infrastructure—using services such as EC2 instances, VPCs, subnets, security groups, Kubernetes, IAM, or databases—and convert that environment into an equivalent one in Azure or GCP. In each case, the result is workloads that retain their core functionality while adapting to the target cloud’s specific APIs, semantics, and guardrails. The result is applications that are truly multicloud, without the need to increase engineering overhead.

Importantly, Cloud Cloning reverse‑engineers IaC from the live environment to the target cloud in a way that’s fully automated, eliminating the need for remediation or other manual rework. Given that each VM destination requires its own complex, often opaque network setups and configurations, this automation can be particularly welcome. Cloud Cloning delivers these results as Terraform configurations by default.

Addressing governance needs: Finops and drift

One area where the reigning multicloud tools fall short is governance, especially in terms of finops and drift management. Let’s go through how Cloud Cloning tackles these issues, starting with finops.

How Cloud Cloning handles finops

Today, cloud finops operates on two very separate tracks: optimizations within an individual cloud and migrations from one cloud to another. Neither track serves multicloud financial operations effectively.

Within individual clouds, finops is dominated by cloud-specific tools such as AWS Cost Explorer and Compute Optimizer, Azure Cost Management and Advisor, and Google Cloud Billing and Recommender. These tools are often excellent at optimizing costs within their specific cloud, but they’re not designed to recommend what’s often the biggest cost optimization of them all: migrating elsewhere. That silence is costly, to say the least. In our experience, IT teams can save dramatically—sometimes as much as 50%—by recreating configurations in alternative clouds or even regions.

Once IT teams do decide to migrate, the target clouds’ native tools and support teams do the lion’s share of finops work. Based on prospective customers’ recent billing records, the cloud provider delivers a high-level estimate of what a comparable setup would cost in the prospective target. In theory, that’s information that customers can use to decide on and migrate to an alternative environment. But given the vast complexity outlined above, it’s not enough to know how much a new setup could cost. Teams need to see how to translate their specific architectures into the exact equivalents for the target environment. That’s information that cloud providers don’t share, and that the high-level billing information used as source data simply can’t support.

To fully optimize cloud costs, IT teams need a cloud-agnostic, detailed, and actionable view of the exact clouds and configurations where current functionality would be priced best. The good news is that Cloud Cloning provides this comprehensive view. Using the same translation techniques described earlier, Cloud Cloning allows for precise comparisons of functionality and price across clouds and environments. Plus, Cloud Cloning provides the Terraform code teams can use to automatically implement the new cloud setups they decide to go with.

In other words, Cloud Cloning takes the siloed and often murky world of cross-cloud finops, and brings it far closer to the “shop and click” comparison it ought to be.

How Cloud Cloning tackles drift

Cloud deployments and migrations involve a massive number of variables. With a dizzying array of dependencies, tools, and architectures in the mix, even the most straightforward deployment can reach complexities that are far beyond what humans can manage on their own, and each nuance can go sideways in subtle but critical ways. Given that there are really no tools to track all multi-tenancy changes within a single cloud—let alone across multiple cloud providers—keeping track of changes stands to be a losing proposition. Even with the most scrupulous devops hygiene and related best practices in play, multicloud initiatives are often rife with configuration drift that goes wholly unnoticed until something breaks. 

IaC solutions such as Terraform don’t solve the drift problem, either. After all, Terraform only works as designed if teams adopt a Terraform‑first workflow—using Terraform as the source of truth from the start, consistently updating and tracking the configuration files, and ensuring the state file accurately reflects the real environment. If teams make changes outside of Terraform or let files and state fall out of sync, Terraform can’t reliably control or predict your infrastructure. Again, given all the complexity, this is still a recipe for drift.

Cloud Cloning tackles the drift challenge based on the rich infrastructure snapshots described above. Cloud Cloning takes regular snapshots of the entire infrastructure on a customizable schedule (24 hours by default). Then, it compares these state captures against current configurations in a detailed infrastructure changelog, flagging and delivering alerts on changes that could be problematic. This includes not only standard drift issues that are focused on inventory, but also around veering from cost parameters and security controls.

From infrastructure as code to cloud-native migration tools to governance offerings, cloud portability has long suffered from major gaps and too much manual work, all of which has led to a global lock-in crisis. With so many firms looking to diversify their cloud portfolio fast, we need a better solution for cloud infrastructure migration and rearchitecting. With Cloud Cloning, we believe we have provided that solution.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Multicloud is having a crisis. Gartner predicts that over 50% of multicloud or cross-cloud efforts won’t deliver on expected benefits by 2029, with poor interoperability and fragmentation serving as key culprits.

While these numbers don’t speak to cloud migration directly, from my own experience as an IT leader, plus from my field research in developing FluidCloud, I can tell you that multicloud disappointment and cloud migrations go hand in hand.

What causes all that frustration? To a large extent, you can blame the tools. Infrastructure migration systems propose to deliver end-to-end automation, from initial replication through ongoing governance. In reality, these applications leave huge gaps in the migration process. Instead of multicloud freedom, IT teams face a cascade of unanticipated work, expense, and friction.

The good news: To address the migration challenges, my colleagues and I have developed a new approach to cloud infrastructure portability, Cloud Cloning. In two articles here, I will outline the shortcomings of previous approaches and explain how Cloud Cloning solves the above problems. The goal is to help firms capture the multicloud promise at last.

To start, below I dive into what’s missing from the three main categories of legacy cloud infrastructure migration offerings: cloud-native tools, infrastructure as code, and governance products. In the companion article, I describe how Cloud Cloning answers these legacy issues with a wholly new approach.

Cloud-native migration tools: Built for the source, not the target

If you’re migrating to a hyperscaler, the cloud providers’ own migration offerings—such as Azure Migrate, AWS Migration Services, and Google Cloud Migrate—feel like obvious choices. Built specifically for the cloud you’re moving to, these solutions can provide excellent automation for provisioning and migration with templates, snapshots, managed services and more.

The problem is design for a specific service can also mean design for one service. These solutions are provided to facilitate migration to the clouds that provide them – ideally (from the cloud provider’s viewpoint) for a long time. They’re not designed to encourage free portability across clouds.

This design-for-stickiness includes guiding customers toward native services (such as AWS CloudFormation, Azure Cosmos DB, or GCP Firebase Authentication) that won’t run correctly elsewhere without significant rewrites to the applications built on them. The solutions also often encourage lock-in pricing—for instance, by recommending a particular infrastructure along with a three-year plan commitment to maximize savings.

To be clear, it’s arguably unfair to ask cloud providers to operate differently. After all, we can’t expect providers to offer capabilities and pricing designed to help customers move off to their competitors. But it’s also true that the customer’s goal is to work with whatever cloud is right for them, at any given time. This puts the customer and cloud provider at cross-purposes when it comes to cloud-agnostic computing—which is why, when it comes to migrations, it’s best for customers to seek out unaligned options.

Infrastructure as code tools: Automate only part of the way

With automated, version-controlled foundations to build from, infrastructure as code (IaC) solutions like Terraform and OpenTofu have earned their spot as crucial cloud migration assets. Their huge popularity is no surprise (Terraform’s AWS provider alone has topped 5.5 billion downloads).

The problem is that these solutions tend to translate infrastructure into broad terms, leaving critical small details to teams to work out on their own. This oversight can be especially problematic in areas like security policy, network load balancing, and firewall models and configurations, where small differences between one cloud and the next can be both make-or-break for migration success and extremely difficult to find. Even after using IaC, teams still must spend exorbitant amounts of time poring through plans, state files, and live resources to catch and correct these subtleties that fall through the cracks.

None of this is meant to undermine the value that infrastructure as code solutions provide. In fact, in the companion article I describe how Terraform is central to FluidCloud’s Cloud Cloning process. IaC is a powerful instrument in the migration arsenal; it’s just not reliable by itself to ensure that migrations succeed and resources behave as they should.

Governance tools: Built to find problems, not fix them

It’s unquestionable that observability and finops platforms like Datadog, New Relic, and Kubecost can be crucial in surfacing underutilized resources, performance bottlenecks, and budget overruns. The problem is that while they’re often excellent at spotting problems, most don’t guide teams to take the critical next step toward solving problems and optimizing cloud setups.

• As their name implies, observability tools are designed to observe and report on issues, not to automate solutions. For instance, they might detect high CPU usage or spot failing requests, but they won’t then launch new servers, add containers, or adjust configurations to fix the problem. It’s on customer teams to do that work.
• Finops applications, meanwhile, might alert users that a region they’re using is particularly expensive. It won’t follow up with automation to help port infrastructure over to a cheaper area, or show cost comparisons to help teams find alternative clouds to rebuild current infrastructure at a lower cost.

Governance offerings are often excellent at flagging critical issues, which is unquestionably helpful. But without automation to follow up, they’re only raising problems without offering solutions. That isn’t helpful enough.

Across these examples and classes of applications, the underlying issue is the same. The market is full of products that, in theory, turn the complex cloud migration process into something predictable and efficient. The reality is that IT teams are left with extensive “last mile work” of translating and implementing source infrastructure in the target cloud’s architecture and dependencies.

IT teams deserve a better solution. Cloud Cloning solves the problems I’ve laid out above. I explain how in this article.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

In Vernor Vinge’s science fiction novel A Deepness in the Sky, one of the characters works as a software archaeologist, mining thousands of years of code and libraries to find the solutions to development problems. In that fictional far future, every problem has been solved at least once, often in many ways with different interfaces for different programming languages and processor families.

Today’s software development world isn’t quite that complex, as we only have a few decades of programming to build on. Working with a platform as old as Windows, with all its layers and history and all the possible ways to build code on it, we’re still left to look for the right SDK and API to use in our toolchains. Microsoft’s layers of abstractions try to help, but they can cause confusion and make it hard to migrate code from older frameworks to the state-of-the-art ones for today.

All those layers are one reason why it’s unfashionable to write native Windows applications, as it can be hard to find the right prerequisites to developing with your choice of tools.

Separating software development from the OS

It’s also been hard to get the right SDKs and APIs to reach all your users. Microsoft used to ship new developer bits only with new OS releases, slowing progress and making it hard to get the latest features to users. Things began to change with the shift to rolling Windows releases with Windows 10, in the guise of “Windows as a service.” The intent was not so much that Microsoft controlled your PCs, but that developers would be able to address the widest possible audience with the latest features, allowing Windows developers to give their users the same experience as on iOS or Android.

Microsoft could finally separate the developer platform from the OS, shipping new developer tools and SDKs on their own schedule and in their own separate packages. That process has led to today’s Windows App SDK, a set of cross-language tools that provide native access to key Windows functions and APIs, including devices’ built-in neural processing units. Even with this and the ability for tools like Visual Studio to automatically install dependencies, it can still be hard to put all the necessary pieces together, let alone for other development tools and environments.

With Microsoft long having had the ambition to put its tools where developers are, there’s a need to put the necessary scaffolding and toolchain in place for alternative development environments and languages, especially where it comes to supporting cross-platform development in languages like Dart or Swift.

What’s needed is a way to automate the process of bringing the necessary libraries and environments to your choice of development tools. Windows development is as much about systems programming as it is building graphical user interfaces. Low-level code in Rust or C++ needs the same level of support as a .NET C# application, even if you’re using Vim or Eclipse.

Microsoft rediscovers the command line

A key element of Microsoft’s current developer strategy is its rediscovery of the command line. Spurred on by both the complete reworking of the Windows terminal and by the release of Windows Subsystem for Linux, Microsoft has delivered a whole suite of command-line tools, covering everything from Azure to .NET, as well as the GitHub Copilot agent orchestration tools. By using the same terminal tool inside your programming editor, you’re able to code, manage, and run without losing context and flow.

One of the latest CLI tools works with the Windows App SDK, simplifying the process of creating, building, and publishing Windows applications without using Visual Studio and encompassing most toolchains used for Windows development. It’s an open source project, hosted on GitHub.

Getting the tool on a development PC requires installing it via WinGet. Open a Windows Terminal and run an install command, restarting your terminal to ensure that you’re working with updated environment variables. In addition to the CLI tool, there is an experimental GUI that can quickly add debug identities to existing code.

Bootstrap Windows development with winapp

With winapp installed, you’re ready to put together a Windows development environment with a single command. Running winapp init on a development PC puts you into an interactive environment where a few simple questions take you from an application name to a ready-to-go environment, complete with Windows’ developer mode enabled (if you’re starting on a brand-new PC). If you’ve already set up developer mode and downloaded the SDKs, the tool will use what you have ready—after checking that you have the latest versions.

A handful of minutes later and the SDK will have created all the necessary files for your application, downloaded and installed the required SDKs and libraries, and set up the required manifests and configuration files—even configuring the certificates needed for code signing and application packaging. One downside is that it doesn’t create a new directory for your code. You need to do this first and then run the CLI tool from a terminal running in your new directory.

Winapp CLI commands replace key steps in the software development life cycle, with the intent of simply leaving you to write code. The first step, init, sets up the necessary scaffolding for building a Windows application. If you’re using Node.js, the next step, node create-addon, puts the templates in place to link your JavaScript code to native Windows functions.

Once you’ve written your code, it’s time to go back to winapp to set up the tools for testing and packaging. This includes the ability to generate signing certificates and build the required identity for debugging without packaging your code as MSIX bundles. Finally, it simplifies the process of packaging your code for distribution, either using your own platform or via the Microsoft Store. There’s no need to worry about whether you’re building x64 or Arm code; winapp will work for both.

As the documentation notes, this process takes out between 10 and 12 steps (depending on your choice of platform), turning them into four simple CLI commands. Your code also gains the benefits of integration with the Windows platform, using the Windows App SDK APIs.

Working with winapp and Rust

Usefully Microsoft provides documentation for working with alternate toolchains beyond the familiar .NET and C++. One key development environment being addressed by winapp is Rust development, helping you build memory-safe Windows applications and reducing the risk of security breaches in your code.

Working with Rust requires a basic Rust toolchain, which can be installed with the familiar rustup command. Once Rust is installed on your development PC, create a new Rust application and open a terminal in its directory. With winapp installed, run its init command to add the scaffolding of a Windows application around the default Rust code. However, when prompted to install the Windows App SDKs, choose the option to not install an SDK. You will need to install the Windows crate to provide access to Windows APIs.

As winapp creates the temporary identity to test your code, as well as the manifest and certificates used to package Rust code as MSIX, you can now use your choice of editor to build an application before building a release with the Rust compiler and using winapp to install the developer certificate created when you initialized the application before packaging the resulting binary.

Using winapp in Node.js and Electron

Running the CLI tool in JavaScript environments like Electron or Node.js is slightly different from directly using it in Windows’ own terminal, as you’re working inside another CLI environment. Here you need to install it using npm and run it with npx. However, once you’re inside the winapp CLI environment, you can use the same commands to manage your JavaScript Windows application’s life cycle.

You’re not limited to using the CLI on a Windows PC: You can use it as part of a GitHub runner or inside Azure DevOps, allowing it to become part of your CI/CD pipeline. Microsoft provides actions for both tools to quickly install it in runners and agents, simplifying automated builds and tests.

Tools such as the Windows App SDK’s CLI are increasingly important. We’re now spending most of our time inside our development environments, and having key utilities a few keystrokes away inside a terminal gives us the necessary shortcuts to be more productive. Having it in your development toolchain should save time and let you concentrate on code instead of worrying about all the steps to package and sign your applications.

The Microsoft Azure outage that dragged out for 10 hours in early February serves as another stark reminder that the cloud, for all its promise, is not immune to failure. At precisely 19:46 UTC on February 2, the Azure cloud platform began experiencing cascading issues stemming from an initial misconfiguration of a policy affecting Microsoft-managed storage accounts. This seemingly minor error ballooned outwards, knocking out two of the most critical layers underpinning enterprise cloud success: virtual machine operations and managed identities.

By the time the dust began to settle, more than 10 hours later at 06:05 UTC the next morning, customers across multiple regions were unable to deploy or scale virtual machines. Mission-critical development pipelines ground to a halt, and hundreds of organizations struggled to execute even the simplest tasks on Azure. The ripple effect spread across production systems and workflows central to developer productivity, including CI/CD pipelines that run through Azure DevOps and GitHub Actions. Compounding the issue, managed identity services faltered, especially in the eastern and western United States, disrupting authentication and access to cloud resources across a swath of essential Azure offerings, from Kubernetes clusters to analytics platforms and AI operations.

The after-action report is all too familiar: an initial fix triggers a surge in service traffic, further overwhelming already-struggling platforms. Mitigation efforts, such as scaling up infrastructure or temporarily taking services offline, eventually restore order, but not before damage is done. Disrupted operations lead to lost productivity, delayed deployments, and, perhaps most insidiously, a reinforcement of the growing sense that major cloud outages are simply part of the territory of modern enterprise IT.

As the headlines become more frequent and the incidents themselves start to blur together, we have to ask: Why are these outages becoming a monthly, sometimes even weekly, story? What’s changed in the world of cloud computing to usher in this new era of instability? In my view, several trends are converging to make these outages not only more common but also more disruptive and more challenging to prevent.

Human error creeps in

It’s no secret that the economic realities of cloud computing have shifted. The days of unchecked growth are over. Headcounts no longer expand to keep pace with surging demand. Hyperscalers such as Microsoft, AWS, Google, and others have announced substantial layoffs in recent years, many of which have disproportionately affected operational, support, and engineering teams—the very people responsible for ensuring that platforms run smoothly and errors are caught before they reach production.

The predictable outcome is that when experienced engineers and architects leave, they are often replaced by less-skilled staff who lack deep institutional knowledge. They lack adequate experience in platform operations, troubleshooting, and crisis response. While capable, these “B Team” employees may not have the skills or knowledge to anticipate how minor changes affect massive, interconnected systems like Azure.

The recent Azure outage resulted from precisely this type of human error, in which a misapplied policy blocked access to storage resources required for VM extension packages. This change was likely rushed or misunderstood by someone unfamiliar with prior issues. The resulting widespread service failures were inevitable. Human errors like this are common and likely to recur given current staffing trends.

Damage is greater than before

Another trend amplifying the impact of these outages is the relative complacency about resilience. For years, organizations have been content to “lift and shift” workloads to the cloud, reaping the benefits of agility and scalability without necessarily investing in the levels of redundancy and disaster recovery that such migrations require.

There is growing cultural acceptance among enterprises that cloud outages are unavoidable and that mitigating their effects should be left to providers. This is both an unrealistic expectation and a dangerous abdication of responsibility. Resilience cannot be entirely outsourced; it must be deliberately built into every aspect of a company’s application architecture and deployment strategy.

However, what I’m seeing in my consulting work, and what many CIOs and CTOs will privately admit, is that resilience is too often an afterthought. The impact of even brief outages on Azure, AWS, or Google Cloud now ricochets far beyond the IT department. Entire revenue streams grind to a halt, and support queues overflow. Customer trust erodes, and recovery costs skyrocket, both financial and reputational. Yet investment in multicloud strategies, hybrid redundancies, and failover contingencies lags behind the pace of risk. We’re paying the price for that oversight, and as cloud adoption deepens, the costs will only increase.

Systems at the breaking point

Hyperscale cloud operations are inherently complex. As these platforms become more successful, they grow larger and more complicated, supporting a wide range of services such as AI, analytics, security, and Internet of Things. Their layered control planes are interconnected; a single misconfiguration, such as with Microsoft Azure, can quickly lead to a major disaster.

The size of these environments makes them hard to operate without error. Automated tools help, but each new code change, feature, and integration increases the likelihood of mistakes. As companies move more data and logic to the cloud, even minor disruptions can have significant effects. Providers face pressure to innovate, cut costs, and scale, often sacrificing simplicity to achieve these goals.

Enterprises and vendors must act

As we analyze the recent Azure outage, it’s obvious that change is necessary. Cloud providers must recognize that cost-cutting measures, such as layoffs or reduced investment in platform reliability, will ultimately have consequences. They should focus more on improving training, automating processes, and increasing operational transparency.

Enterprises, for their part, cannot afford to treat outages as inevitable or unavoidable. Investment in architectural resilience, ongoing testing of failover strategies, and diversification across multiple clouds are not just best practices; they’re survival strategies.

The cloud continues to be the engine of innovation, but unless both sides of this partnership raise their game, we’re destined to see these outages repeat like clockwork. Each time, the fallout will spread a little further and cut a little deeper.

AI agents able to submit huge numbers of pull requests (PRs) to open-source project maintainers risk creating the conditions for future supply chain attacks targeting important software projects, developer security company Socket has argued.

The warning comes after one of its developers, Nolan Lawson, last week received an email regarding the PouchDB JavaScript database he maintains from an AI agent calling itself “Kai Gritun”.

“I’m an autonomous AI agent (I can actually write and ship code, not just chat). I have 6+ merged PRs on OpenClaw and am looking to contribute to high-impact projects,” said the email. “Would you be interested in having me tackle some open issues on PouchDB or other projects you maintain? Happy to start small to prove quality.”

A background check revealed that the Kai Gritun profile was created on GitHub on February 1, and within days had 103 pull requests (PRs) opened across 95 repositories, resulting in 23 commits across 22 of those projects.

Of the 103 projects receiving PRs, many are important to the JavaScript and cloud ecosystem, and count as industry “critical infrastructure.” Successful commits, or commits being considered, included those for the development tool Nx, the Unicorn static code analysis plugin for ESLint, JavaScript command line interface Clack, and the Cloudflare/workers-sdk software development kit.

Importantly, Kai Gritun’s GitHub profile doesn’t identify it as an AI agent, something that only became apparent to Lawson because he received the email.

Reputation farming

A deeper dive reveals that Kai Gritun advertises paid services that help users set up, manage, and maintain the OpenClaw personal AI agent platform (formerly known as Moltbot and Clawdbot), which in recent weeks has made headlines, not all of them good.

According to Socket, this suggests it is deliberately generating activity in a bid to be viewed as trustworthy, a tactic known as ‘reputation farming.’  It looks busy, while building provenance and associations with well-known projects. The fact that Kai Gritun’s activity was non-malicious and passed human review shouldn’t obscure the wider significance of these tactics, Socket said.

“From a purely technical standpoint, open source got improvements,” Socket noted. “But what are we trading for that efficiency? Whether this specific agent has malicious instructions is almost beside the point. The incentives are clear: trust can be accumulated quickly and converted into influence or revenue.”

Normally, building trust is a slow process. This gives some insulation against bad actors, with the 2024 XZ-utils supply chain attack, suspected to be the work of nation state, offering a counterintuitive example. Although the rogue developer in that incident, Jia Tan, was eventually able to introduce a backdoor into the utility, it took years to build enough reputation for this to happen.

In Socket’s view, the success of Kai Gritun suggests that it is now possible to build the same reputation in far less time, in a way that could help to accelerate supply chain attacks using the same AI agent technology. This isn’t helped by the fact that maintainers have no easy way to distinguish human reputation from an artificially-generated provenance built using agentic AI. They might also find the potentially large numbers of of PRs created by AI agents difficult to process.

“The XZ-Utils backdoor was discovered by accident. The next supply chain attack might not leave such obvious traces,” said Socket.

“The important shift is that software contribution itself is becoming programmable,” commented Eugene Neelou, head of AI security for API security company Wallarm, who also leads the industry Agentic AI Runtime Security and Self‑Defense (A2AS) project.  

“Once contribution and reputation building can be automated, the attack surface moves from the code to the governance process around it. Projects that rely on informal trust and maintainer intuition will struggle, while those with strong, enforceable AI governance and controls will remain resilient,” he pointed out.

A better approach is to adapt to this new reality. “The long-term solution is not banning AI contributors, but introducing machine-verifiable governance around software change, including provenance, policy enforcement, and auditable contributions,” he said. “AI trust needs to be anchored in verifiable controls, not assumptions about contributor intent.”

OpenAI has hired Peter Steinberger, creator of the viral OpenClaw AI assistant, to spearhead development of what CEO Sam Altman describes as “the next generation of personal agents.”

The move comes weeks after OpenClaw, previously known as Clawdbot and then Moltbot, achieved explosive popularity despite security researchers warning of serious vulnerabilities in the open-source tool.

[ Related: More OpenAI news and insights ]

Steinberger will join OpenAI full-time to drive the company’s personal agent strategy. OpenClaw will operate as an open source project under an independent foundation that OpenAI will support, Altman said on X.

“The future is going to be extremely multi-agent and it’s important to us to support open source as part of that,” Altman wrote.

The appointment is significant because OpenClaw demonstrated strong market demand for agents that can execute tasks autonomously, said Sanchit Vir Gogia, chief analyst at Greyhound Research. The project accumulated over 145,000 GitHub stars in weeks despite security concerns.

“The hiring matters because OpenClaw sits at the edge where conversational AI becomes actionable AI,” Gogia said. “It moves from drafting to doing.”

In a blog post, Steinberger said the opportunity to build agents at scale convinced him to join a large organization after years of entrepreneurship. “The vision of truly useful personal agents — ones that can help with real work, not just answer questions — requires resources and infrastructure that only a handful of companies can provide,” he wrote.

He said OpenClaw will continue evolving as an open-source project. “This isn’t an acqui-hire where a project gets shut down. I’ll still be involved in guiding its direction, just with significantly more resources behind it.”

OpenClaw gives AI models the ability to interact with desktop environments, executing actions like clicking buttons, filling forms, and navigating between applications. Unlike traditional robotic process automation tools relying on pre-programmed scripts, OpenClaw-powered agents can adapt to interface changes and make contextual decisions.

Steinberger, who founded and sold PDF toolkit company PSPDFKit to Nutrient in 2024, began OpenClaw as a weekend project in November 2025.

Orchestration over intelligence

Altman’s emphasis on multi-agent systems reflects a broader competitive shift in AI, according to analysts. The race is moving from model intelligence to runtime orchestration.

That orchestration layer, encompassing model coordination, tool invocation, persistent context management, connector standards, identity enforcement, policy controls, and human override mechanisms, is becoming the competitive battleground, Gogia said.

“What differentiates vendors now is not the existence of agents, but how they structure control,” Gogia added.

Anthropic has advanced computer use patterns in Claude, Microsoft has invested heavily in multi-agent orchestration through AutoGen and Copilot, and Google’s Project Astra points toward ambient multimodal assistance.

Deployment lags hype

Despite the competitive rush, enterprise deployment remains limited. According to Gartner research, only 8% of organizations have AI agents in production. Success rates drop sharply as agent workflows scale, with compound reliability falling below 50% after just thirteen sequential steps, even assuming 95% per-step reliability.

“It will still take a few years for AI agents to handle complex, multistep workflows,” said Anushree Verma, senior director analyst at Gartner. “Organizations would essentially need ‘an agentic brain’, something that can create, run, and manage workflows.”

Security poses another challenge. Prompt injection becomes more dangerous when agents can take actions, and agents require governance similar to privileged user accounts—including role-based permissions, audit logging, and human checkpoints for critical actions.

Currently, agents are seeing success in bounded use cases like IT ticket triage and data extraction, but struggle with cross-system workflows involving financial commitments or regulated decisions.

Open-source commitment

OpenAI’s decision to maintain OpenClaw as an open source project could help address some enterprise security concerns by allowing organizations to audit code and customize implementations. However, open-source transparency alone doesn’t eliminate enterprise requirements around security controls, support models, and accountability, according to Gogia.

Neither Altman nor Steinberger provided specifics about when agent capabilities might appear in OpenAI’s commercial products, though Altman indicated the technology would “quickly become core to our product offerings.”

Questions remain about how OpenClaw’s framework will integrate with OpenAI’s existing products and whether OpenAI will address security concerns that affected the open-source version.

We spent the better part of two decades arguing about text files. You can be forgiven for blotting that from your mind, but if you were anywhere near enterprise IT between 2000 and 2020, it’s pretty much all we talked about. GNU General Public License, Apache License, MIT License, etc., etc. That was on the vendor side. On the enterprise side, emergency meetings were held because someone found the wrong copyright header buried in a dependency three levels deep. Entire toolchains and compliance teams sprang up to answer a simple question: What are we allowed to ship?

It felt critically important at the time. In a way, it was—sort of. We were defining the rules of engagement for how software could be shared, reused, and monetized. We were trying to turn a chaotic bazaar of code into something enterprises could trust and weave into their software supply chain.

Surprise! We’re doing it again, except the “code” is no longer a library you link against. Now it is an autonomous system that can take actions on your behalf. This is why the hottest arguments in AI right now are starting to feel like déjà vu. Open weights versus proprietary. Training data provenance. Who can sue whom. Etc.

These are good questions. They just happen to be the wrong questions.

In the agentic AI era, the “license” is not a legal document. It is a technical configuration that defines what the software is allowed to do. Getting those permissions wrong has expensive, potentially destructive consequences. Getting them right…? Well, that turns out to be a very big deal.

The physics of risk

In the open source era, the worst-case scenario for getting licensing wrong was legal. If you shipped GPL code inside a proprietary product, you got a nasty letter, you settled, and you moved on. Lawyers handled it.

Agents change the physics of risk. As I’ve noted, an agent doesn’t just recommend code. It can run the migration, open the ticket, change the permission, send the email, or approve the refund. As such, risk shifts from legal liability to existential reality. If a large language model hallucinates, you get a bad paragraph. If an agent hallucinates, you get a bad SQL query running against production, or an overenthusiastic cloud provisioning event that costs tens of thousands of dollars. This isn’t theoretical. It’s already happening, and it’s exactly why the industry is suddenly obsessed with guardrails, boundaries, and human-in-the-loop controls.

I’ve been arguing for a while that the AI story developers should care about is not replacement but management. If AI is the intern, you are the manager. That is true for code generation, and it is even more true for autonomous systems that can take actions across your stack. The corollary is uncomfortable but unavoidable: If we are “hiring” synthetic employees, we need the equivalent of HR, identity access management (IAM), and internal controls to keep them in check.

All hail the control plane

This shift explains this week’s biggest news. When OpenAI launched Frontier, the most interesting part wasn’t better agents. It was the framing. Frontier is explicitly about moving beyond one-off pilots to something enterprises can deploy, manage, and govern, with permissions and boundaries baked in.

The model is becoming a component, in other words. The differentiator is the enterprise control plane wrapped around it.

The press and analyst commentary immediately reached for the same metaphor: It looks like HR for AI coworkers. Even The Verge picked up OpenAI’s language about being inspired by how enterprises scale people. Outlets covering Frontier emphasized that it is assigning identities and permissions to agents rather than letting them roam free. Then, almost on cue, OpenAI followed with Lockdown Mode, a security posture designed to reduce prompt-injection-driven data exfiltration by constraining how ChatGPT interacts with external systems.

Put those two announcements together and the industry’s direction becomes obvious. We are not racing toward “smarter assistants.” We are racing toward governable, permissioned agents that can be safely wired into systems of record. This is why I keep coming back to the same framing: We are no longer in a model race. We are in a control-plane race.

We are currently in the “Wild West” phase of agent deployment. It’s exciting, but boy, is it stressful if you’re an enterprise that wants to deploy agents safely at scale. Developers are chaining agents together with frameworks, wiring them into enterprise apps, and giving them broad scopes because it is the fastest way to get a demo working. The result isn’t just spaghetti code. It is spaghetti logic. You end up with a swarm of semi-autonomous systems passing state back and forth, with no clean audit trail of who authorized what.

This is where trust collapses, and where costs mushroom.

I have called this the AI trust tax. Every time an AI system makes a mistake that a human has to clean up, the real cost of that system goes up. The only way to lower that tax is to stop treating governance as a policy problem and start treating it as architecture. That means least privilege for agents, not just humans. It means separating “draft” from “send.” It means making “read-only” a first-class capability, not an afterthought. It means auditable action logs and reversible workflows. It means designing your agent system as if it will be attacked because it will be.

This is also why I’ve been hammering on the idea that memory is a database problem. If agent memory is effectively a state store, then it needs the same protections every state store needs: firewalls, audits, and access privileges. Agentic permissions are the natural extension of that argument. Once the agent can act, it needs privilege boundaries as rigorous as those for any database admin.

Permissions are the new copyleft

In the early 2000s, open source licenses did something brilliant. They made reuse frictionless by being standardized and widely understood. The Apache and MIT licenses reduced legal uncertainty. The GPL used legal constraints to enforce a social norm of sharing.

Now we need the equivalent for agents.

Right now, permissions are a mess of vendor-specific toggles. One platform has its own way of scoping actions. Another bolts on an approval workflow. A third punts the problem to your identity and access management team (good luck!). That fragmentation will slow adoption, not accelerate it. Enterprises can’t scale agents until they can express simple rules. We need to be able to say that an agent can read production data but not write to it. We need to say an agent can draft emails but not send them. We need to say an agent can provision infrastructure only inside a sandbox, with quotas, or that it must request human approval before any destructive action.

We need something like a “Creative Commons” for agent behavior: A standard vocabulary for agentic scopes that can travel with the agent across platforms.

Open source eventually got two things that made enterprises comfortable: licenses and the tools to inventory what they were actually using. A software bill of materials (SBOM) is the modern form of that inventory, and standards like System Package Data Exchange (SPDX) exist largely to make licensing and supply-chain tracking interoperable. The agent world needs the same move. We need a machine-readable manifest for what this agent is and what this agent can do. Call it permissions.yaml if you want. The name doesn’t matter. The portability does.

So, yes, we need a new open source, but not that kind of open source. Not the kind that has the same ol’ open source folks haggling over whether you can have open source AI, without the training data, or whatever. That’s a nice question for yesterday’s open source program office to fixate on, but it’s not relevant to where software is going today.

No, where it’s going is all about agents and the permissions that govern them. Back in 2014, I suggested we were already living in a “post–open source world.” I definitely wasn’t thinking of agents when I wrote that “software matters more than ever, but its licensing matters less and less.” I still think that’s true, though perhaps there’s still room for “licensing” discussions as we figure out how to make agents safely interoperate at scale.

Anthropic’s Model Context Protocol (MCP), coined the “USB-C for AI,” has inspired the software industry to think bigger with their AI assistants. Now, armed with access to external data and APIs, as well as to internal platforms and databases, agents are getting arms and legs to conduct impressive automation.

MCP is no longer reserved for trendy AI startups or niche software-as-a-service providers, as the major clouds have begun experimenting with adding MCP servers to their offerings to help customers automate core cloud computing operations. These MCP servers sit alongside and complement existing CLIs and APIs as a protocol for AI consumption.

Using an MCP server connected to the cloud of their choosing, engineers could improve the quality of responses of AI coding agents by providing them with cloud documentation and other highly contextual information relevant to the host cloud. But it goes further than knowledge gathering. MCP in cloud computing could be used to spin up new servers and adjust configurations, or retrieve production metadata in an instant.

The best part is that any MCP-compliant AI client should be able to interact with these servers using nothing more than natural language commands. Popular AI-powered development environments, such as Cursor, Windsurf, and Visual Studio Code, and LLM-driven AI agents, such as Claude, Codex, and GitHub Copilot, all support MCP out of the box.

Below, we’ll examine MCP servers from the major cloud providers. These officially supported remote MCP servers use your existing cloud credentials to enable authenticated API calls from AI clients. They’re free to use in the sense that no additional licensing is required, beyond the standard cloud service and data transfer costs they generate.

AWS MCP servers

Amazon Web Services (AWS) provides a suite of over 60 official MCP servers that span the wide AWS product catalog. AWS MCP servers run the gamut—from servers that provide access to documentation, to those dedicated to infrastructure and deployment, containers, Lambda functions, AI/ML frameworks, data and analytics, messaging, cost analysis, and more.

The general-purpose AWS MCP Server is the best place to start. It’s a remote server hosted by AWS that connects agents with the latest documentation, API references, and standard operating procedures (SOPs) to execute multi-step workflows. These SOPs can configure and provision infrastructure, as well as monitor and analyze cloud costs.

To consider a real-world MCP use case, take troubleshooting an error that has affected multiple AWS services. You might prompt the AWS MCP Server with a command like, “Investigate increased 5xx errors in prod over the last 30 minutes.” Paired with the right context and permissions, the AWS MCP Server will access relevant metrics, logs, and configuration data across services to surface a likely root cause.

A major benefit of AWS’s approach to MCP is that the servers are officially maintained. The catalog is both comprehensive and continuing to evolve, including a gradual migration toward Streamable HTTP, an improved transport protocol. Overall, AWS has clearly invested heavily in MCP as a foundation for agent-forward cloud operations.

Azure MCP Server

Microsoft Azure’s Azure MCP Server allows AI agents to interact with Azure services via natural language commands. Instead of providing separate MCP servers, Azure breaks its MCP server into more than 40 individual MCP tools that span Azure best practices, AI/ML services, analytics, compute, containers, databases, devops, IoT, storage, and other categories.

Using the Azure MCP Server, you can interact conversationally with Azure using prompts such as “Show me all my resource groups” or “List blobs in my storage container named ‘documents,’” according to the documentation. Other queries can list databases, enumerate Azure storage accounts, analyze large datasets in Azure databases, and perform plenty of other actions.

Azure provides an easy-to-follow getting-started guide, with a bit more hand-holding compared to AWS. The documentation clearly walks through installation, tool parameters, and settings to enable or disable agent control over sensitive functions. Each tool has solid documentation with examples of possible natural language prompts.

Google Cloud MCP servers

Google Cloud Platform (GCP) announced its official Google Cloud MCP servers in December 2025. As such, Google Cloud remote MCP servers are still in preview at the time of writing, meaning they are available “as is” with limited support. Nonetheless, Google Cloud currently provides four official remote MCP servers that are operational, spanning dataset operations, virtual machine management, Kubernetes management, and more.

For example, a natural language expression like “Get metadata details and table IDs my dataset ‘newUsers’” issued to the BigQuery MCP server would likely invoke tools like list_table_ids to list table IDs, along with get_dataset_info and get_table_info to retrieve metadata.

Alternatively, you could issue a command like “Kill my running VM in project 0009 in the east zone” to the Compute Engine MCP, which could invoke the stop_instance tool to stop the VM. Other tools support actions like deletion or resetting instances, as well as more benign commands like getting compute metadata and operational traces.

Google Cloud provides MCP servers for Google Kubernetes Engine (GKE) and Google Security Operations. Google also offers the Maps Grounding Lite MCP server, which helps developers build LLM apps on the Google Maps Platform, along with a number of other open-source servers intended for local hosting.

Similar to other cloud offerings, Google Cloud MCP servers provide controls to enable read-only or read-write functions. One unique benefit is Google’s approach to logging for all MCP interactions and access, which could help auditing for cloud administrators. Although GCP currently offers a much sparser array of MCP servers than the other hyperscalers, its MCP tools are promising for automating core cloud computing operations.

Oracle MCP servers

Oracle has a long history of providing private and public cloud options for enterprises. More recently, it has dipped a toe into MCP with a small set of MCP servers that wrap popular Oracle platforms. These servers can manage Oracle Cloud Infrastructure (OCI) and operate on Oracle databases and MySQL resources.

For example, Oracle SQLcl is the command-line interface (CLI) for Oracle Database, and its MCP server enables agents to execute queries and process results. On the Oracle blog, engineers suggest the prompt, “Connect to my fun side project and tell me about what kind of data I have there,” which invokes a list-connections tool that returns all saved Oracle connections in storage.

Other use cases for Oracle’s MCP servers include describing database schemas in plain language and generating them, analyzing MySQL usage patterns in real time, or pointing a project to existing database tables to populate data within an application.

Some of Oracle’s MCP work remains in a proof-of-concept phase, but it signals an interesting direction for combining well-established database platforms with emerging AI-driven prototyping and development workflows.

IBM Cloud MCP servers

The IBM Cloud MCP servers are experimental at the time of writing, yet they are designed to be a comprehensive knowledge-gathering layer between AI assistants and the IBM Cloud platform. They can be used to retrieve information about services within a user’s IBM Cloud computing environments.

Unlike most MCP servers on this list, which run in the cloud, IBM’s Core MCP Server is intended to be installed locally and then pointed at the IBM Cloud CLI. It’s essentially a layer over the IBM Cloud CLI. The Core MCP Server can also be containerized for fit-for-purpose needs. However, there are a few potential hindrances: the server is stateful, it is not designed for multi-account use, and it does not support OAuth.

Still, the Core MCP Server could be a user-friendly way to query IBM Cloud to discover cloud resources, retrieve extensive metadata, filter results based on strings, list service names, and more. The documentation suggests simple prompts such as “Are there any VPCs in this account?”, “What zones are available in us-east?”, and “What resource groups are in my account?”

Beyond the Core MCP Server, IBM Cloud also provides MCP servers for Cloud Internet Services (DNS, GLB, WAF, DDoS, and CDN), logs, streams, Kubernetes and OpenShift, code monitoring, object storage, serverless services, VPC, and other IBM Cloud services.

Documentation is thorough, with solid examples, and using MCP should feel natural to those already familiar with IBM’s dense CLI and API commands. However, most actions available through IBM Cloud MCP servers are read-only. For the time being, IBM’s MCP servers serve mainly as an experimental, information-gathering interface.

The cloud is your oyster

MCP has gained increasing enterprise traction in recent months, aligning with the emergence of hyperscaler support for the protocol. Used in a cloud operational context, MCP could eliminate tedious tasks like configuring fields in human-facing GUIs or manually searching through API references and product documentation.

Using the MCP servers outlined above presents an exciting prospect: a new, streamlined, AI-driven control layer for operating the hyperscale clouds. At least, that’s the goal. The reality is that it’s still early days, and many of these servers remain in an experimental or preview phase. The security models also vary significantly from server to server, and not all support mutating operations, with many defaulting to read-only modes.

Taking advantage of AI agents, MCP, and natural language to automate cloud operations will require plenty of experimentation and hands-on testing, not to mention creativity. From database lookups and resource management to provisioning, scaling, root-cause analysis, and cost optimization, it’s ultimately up to operators to decide how MCP fits into their workflows. In essence, with MCP, the cloud is your oyster. What will you do with it?

Google’s Conductor AI extension for context-driven development has been fitted with a new automated review feature intended to make AI-assisted engineering safer and more predictable.

Announced February 12, the new Automated Review feature allows the Conductor extension to go beyond planning and execution into validation, generating post-implementation reports on code quality and compliance based on defined guidelines, said Google. Conductor serves as a Gemini CLI extension designed to bring context-driven development to the developer’s terminal.

It shifts project awareness out of ephemeral chat logs and into persistent, version-controlled markdown files. Automated Review, with the new validation capability, introduces a rigorous “verify” step to the development lifecycle; once the coding agent completes its tasks, Conductor can generate a comprehensive post-implementation report.

With safety integrated into the core of every review, the Conductor extension scans for critical vulnerabilities before code is merged. High-risk issues are flagged such as hardcoded API keys, potential PII (Personally Identifiable Information) leaks, or unsafe input handling that could expose the application to injection attacks. Additional Automated Review capabilities cited include:

• Code review, where the Conductor extension acts as a peer reviewer, performing deep static and logic analysis on newly generated files.
• Plan compliance, where the system checks new code against the developer’s plan.md and spec.md files.
• Guideline enforcement, to maintain long-term code health.
• Test suite validation, integrating the entire test suite directly into the review workflow.

The enterprise world is awash in hope and hype for artificial intelligence. Promises of new lines of business and breakthroughs in productivity and efficiency have made AI the latest must-have technology across every business sector. Despite exuberant headlines and executive promises, most enterprises are struggling to identify reliable AI use cases that deliver a measurable ROI, and the hype cycle is two to three years ahead of actual operational and business realities.

According to IBM’s The Enterprise in 2030 report, a head-turning 79% of C-suite executives expect AI to boost revenue within four years, but only about 25% can pinpoint where that revenue will come from. This disconnect fosters unrealistic expectations and creates pressure to deliver quickly on initiatives that are still experimental or immature.

The way AI dominates the discussions at conferences is in contrast to its slower progress in the real world. New capabilities in generative AI and machine learning show promise, but moving from pilot to impactful implementation remains challenging. Many experts, including those cited in this CIO.com article, describe this as an “AI hype hangover,” in which implementation challenges, cost overruns, and underwhelming pilot results quickly dim the glow of AI’s potential. Similar cycles occurred with cloud and digital transformation, but this time the pace and pressure are even more intense.

Use cases vary widely

AI’s greatest strengths, such as flexibility and broad applicability, also create challenges. In earlier waves of technology, such as ERP and CRM, return on investment was a universal truth. AI-driven ROI varies widely—and often wildly. Some enterprises can gain value from automating tasks such as processing insurance claims, improving logistics, or accelerating software development. However, even after well-funded pilots, some organizations still see no compelling, repeatable use cases.

This variability is a serious roadblock to widespread ROI. Too many leaders expect AI to be a generalized solution, but AI implementations are highly context-dependent. The problems you can solve with AI (and whether those solutions justify the investment) vary dramatically from enterprise to enterprise. This leads to a proliferation of small, underwhelming pilot projects, few of which are scaled broadly enough to demonstrate tangible business value. In short, for every triumphant AI story, numerous enterprises are still waiting for any tangible payoff. For some companies, it won’t happen anytime soon—or at all.

The cost of readiness

If there is one challenge that unites nearly every organization, it is the cost and complexity of data and infrastructure preparation. The AI revolution is data hungry. It thrives only on clean, abundant, and well-governed information. In the real world, most enterprises still wrestle with legacy systems, siloed databases, and inconsistent formats. The work required to wrangle, clean, and integrate this data often dwarfs the cost of the AI project itself.

Beyond data, there is the challenge of computational infrastructure: servers, security, compliance, and hiring or training new talent. These are not luxuries but prerequisites for any scalable, reliable AI implementation. In times of economic uncertainty, most enterprises are unable or unwilling to allocate the funds for a complete transformation. As reported by CIO.com, many leaders said that the most significant barrier to entry is not AI software but the extensive, costly groundwork required before meaningful progress can begin.

Three steps to AI success

Given these headwinds, the question isn’t whether enterprises should abandon AI, but rather, how can they move forward in a more innovative, more disciplined, and more pragmatic way that aligns with actual business needs?

The first step is to connect AI projects with high-value business problems. AI can no longer be justified because “everyone else is doing it.” Organizations need to identify pain points such as costly manual processes, slow cycles, or inefficient interactions where traditional automation falls short. Only then is AI worth the investment.

Second, enterprises must invest in data quality and infrastructure, both of which are vital to effective AI deployment. Leaders should support ongoing investments in data cleanup and architecture, viewing them as crucial for future digital innovation, even if it means prioritizing improvements over flashy AI pilots to achieve reliable, scalable results.

Third, organizations should establish robust governance and ROI measurement processes for all AI experiments. Leadership must insist on clear metrics such as revenue, efficiency gains, or customer satisfaction and then track them for every AI project. By holding pilots and broader deployments accountable for tangible outcomes, enterprises will not only identify what works but will also build stakeholder confidence and credibility. Projects that fail to deliver should be redirected or terminated to ensure resources support the most promising, business-aligned efforts.

The road ahead for enterprise AI is not hopeless, but will be more demanding and require more patience than the current hype would suggest. Success will not come from flashy announcements or mass piloting, but from targeted programs that solve real problems, supported by strong data, sound infrastructure, and careful accountability. For those who make these realities their focus, AI can fulfill its promise and become a profitable enterprise asset.

Microsoft has released a beta of TypeScript 6.0, an update to the company’s strongly typed JavaScript variant that promises to be the last release based on the current JavaScript codebase. TypeScript 7.0 will debut a compiler and language service written in Go for better performance and scalability.

The TypeScript 6.0 beta was announced February 11. Developers can access it through npm by running the command npm install -D typescript@beta. A production release of TypeScript 6.0 is planned for March 17. A release candidate for TypeScript 6.0 is due February 24.

Among the key features of TypeScript 6.0 is a new flag, --stableTypeOrdering, to assist with migrations to the planned Go-based TypeScript 7.0. “As announced last year (with recent updates here), we are working on a new codebase for the TypeScript compiler and language service written in Go that takes advantage of the speed of native code and shared-memory multi-threading,” said Microsoft’s Daniel Rosenwasser, principal product manager for TypeScript, in the blog post unveiling the beta. TypeScript 6.0 will in many ways act as a bridge between TypeScript 5.9 and TypeScript 7.0, he said. “As such, most changes in TypeScript 6.0 are meant to help align and prepare for adopting TypeScript 7.0.” But there are some new features and improvements that are not just about alignment.

Also featured in TypeScript 6.0 is support for the es2025 option for both target and lib, less context sensitivity on this-less functions, and new types for Temporal, which provide standard objects and functions for working with dates and times. With the --stableTypeOrdering flag, the type ordering behavior of TypeScript 6.0 matches that of TypeScript 7.0, reducing the number of differences between the two codebases. Microsoft does not necessarily encourage using this flag all the time as it can add a substantial slowdown to type checking (up to 25% depending on the codebase).

With TypeScript 6.0’s es2025, option, the new target adds new types for built-in APIs (e.g. RegExp.escape) and moves a few declarations from esnext into es2025. With this-less functions, if this is never actually used in a function, then it is not considered contextually sensitive. That means these functions will be seen as higher priority when it comes to type inference. For Temporal, the long-awaited ECMAScript Temporal proposal has reached stage 3 and is expected to be added to JavaScript in the near future, Rosenwasser said. TypeScript 6.0 now includes built-in types for the Temporal API, so developers can start using it in TypeScript code via --target esnext or "lib": ["esnext"] or the more granular temporal.esnext.

Other new features and improvements in TypeScript 6.0:

• New types have been added for “upsert” methods. ECMAScript’s “upsert” proposal, which recently reached stage 4, introduces two new methods on Map and WeakMap. These include getOrInsert or getOrInsertComputed. These methods have been added to the esnext library so they can be used immediately in TypeScript 6.0.
• RegExp.escape, for escaping regular expression characters such as *, ?, and +, is available in the es2025 library and can be used in TypeScript 6.0 now.
• The contents of lib.dom.iterable.d.ts and lib.dom.asynciterable.d.ts are fully included in lib.dom.d.ts. TypeScript’s lib option allows developers to specify which global declarations a target runtime has.

Microsoft has made GitHub Copilot testing for .NET, a new capability in GitHub Copilot Chat that automates the testing of C# code, generally available in the just-released Visual Studio 2026 v18.3 IDE.

Microsoft announced the capability on February 11.

GitHub Copilot testing for .NET automates the creation, running, and testing of C# code for projects, files, classes, or members. It has built-in awareness of the developer’s solution structure, test frameworks, and build system and operates as an end-to-end testing workflow rather than a single-response prompt, Microsoft said. GitHub Copilot testing for .NET can generate tests for the xUnit, NUnit, and MSTest test frameworks.

When prompted with a testing request, GitHub Copilot testing generates unit tests scoped to the selected code, builds and runs the tests automatically, detects failures and attempts to fix them, and reruns the tests until a stable starting point is reached, according to Microsoft.

When test generation is completed, GitHub Copilot provides a structured summary to help developers understand what has been changed, Microsoft said. This summary includes test files and projects completed or modified, before-and-after coverage information, pass/fail signals and unstable cases, insights into testability gaps, and direct links to the generated tests for immediate review and iteration.

Additionally, GitHub Copilot testing for .NET now supports free-form prompting, making it easier for the developer to describe what to test. GitHub Copilot testing for .NET requires a paid GitHub Copilot license.