Microsoft’s enshittification of Windows 11 got so bad in 2025 that hating on the company and its products became the new cool thing to do on social media. Though the company is responsible for most of it, spreading fake rumours about a supposedly AI-focused, subscription-based Windows 12 coming in 2026 doesn’t fix the issue.

The fact is that Microsoft is not releasing Windows 12 in 2026, and there is no credible evidence that the company is preparing a subscription-based version of Windows either. And since Windows 12 doesn’t exist as of now, claims about it having AI as the foundation, with a minimum 40 TOPS NPU, are pure speculation, or rather, I say “hallucination”.

Much of the discussion traces back to articles published on some AI-generated forums’ content and tech publications.

Our investigation found that multiple AI-driven websites were referencing one another as sources, creating a loop of AI hallucinations that made fabricated claims appear credible.

Either way, the damage was already done as the story got pushed into Reddit, where, as expected, users clouded the comments section with their long-standing aversion towards Microsoft.

Interestingly, those Reddit threads and posts on X also became “sources” for AI tools, which increased the models’ confidence and caused the hallucinations to spread further.

The Windows 12 rumour is built on old leaks and outdated concepts, probably by AI

The rumor describes Hudson Valley as an upcoming Windows 12 release. In reality, Hudson Valley was the internal codename for Windows 11 version 24H2, which has already shipped. And as you already know, 24H2 looks nothing like the redesign described in the rumor, and none of the supposed UI changes or architectural shifts ever appeared.

The supposed “leaks” also mention CorePC, which was a concept discussed in actual leaks several years ago. CorePC was to be a modular Windows architecture that could separate system components, improve update reliability, and scale the OS for different device categories. However, despite years of speculation, CorePC has never appeared publicly. As things stand today, there is no evidence that CorePC is part of Microsoft’s current Windows roadmap.

Another familiar talking point in the rumor is the idea that Windows 12 could become subscription-based. Back in 2023, some internal references to subscription status flags had people concerned that Microsoft might move Windows to a recurring payment model.

However, later we found those internal flags referred to a cloud-based service for enterprises, not an actual OS for consumers.

Then, the so-called “new” interface in Windows 12 leak talks of a floating taskbar with rounded corners, system indicators moved to the top-right corner, and a large search bar centered at the top of the screen. These descriptions are actually identical to a concept interface Microsoft showed internally and during Ignite 2022, which leaked online at the time.

That design prototype never shipped and has not appeared in any modern Windows builds.

Windows enthusiast phantomofearth noted that the rumor “reads like it’s straight out of 2023 when Panos [Panay] was around.” The references to Hudson Valley, CorePC, and subscription-based OS were all happening several years ago.

The story is that at one point during the Panos Panay era, there were internal plans to ship a new Windows generation around 2024. But after leadership changes inside Microsoft’s Windows division, that direction was scrapped, and the work ultimately became Windows 11 version 24H2 instead.

Despite these inconsistencies, the rumor still spread widely online, mostly due to the non-existent trust that users have in Microsoft.

When will Windows 12 actually launch?

With the rumor debunked, the obvious question is, will Microsoft release Windows 12 anytime soon? Well, the answer is almost certainly not in 2026.

The company’s focus right now is on fixing Windows 11 itself. Internally, the priority appears to be addressing long-standing complaints about performance, reliability, and the AI overload.

The next major version on the roadmap is Windows 11 26H2, which will follow earlier platform work already underway. Note that Windows 11 26H1 was for enabling improvements for ARM devices, specifically the Snapdragon X2 series.

Even if Microsoft eventually decides to move forward with a new Windows generation, it is unlikely to happen soon. A Windows 12 release would not arrive before 2027 at the earliest, and it almost certainly would not resemble the AI-heavy redesign described in the viral rumor.

Ironically, the reason the rumor spread so quickly says a lot about the current state of the Windows ecosystem. Microsoft’s aggressive AI push, controversial features like Recall, and the perception that the company prioritizes Copilot over everything have eroded user trust.

When a rumor suggested Windows could become subscription-based or radically redesigned with AI running the show, many people just assumed the worst.

With Windows 10 support ended, millions of users have reluctantly moved to Windows 11. At the same time, competition is heating up with Apple’s newly introduced $599 MacBook Neo. Windows and PC manufacturers could face serious pressure unless Microsoft improves the Windows experience and regains at least some of the trust that has eroded.

The real challenge for Microsoft isn’t launching a new version of Windows. It’s rebuilding confidence in the one people are already using.

As things stand, it would be unwise of Microsoft to launch Windows 12, or any major feature update to the existing Windows 11, unless it’s one that fixes the OS from the ground up.

The post Microsoft isn’t launching a subscription-based Windows 12 AI OS in 2026. The rumors are just AI hallucinations. appeared first on Windows Latest

On Wednesday, the White House posted a video of actual military strikes on Iran in the style usually seen in Call of Duty highlight videos, and started the video with a clip from Call of Duty. The real-life footage of missiles and other munitions hitting targets in Iran shows clips seen in other Trump administration videos, like this one posted to the U.S. Central Command X account.

As noted by The Washington Post's Drew Harwell, the animation at the start appears to be from Call of Duty: Modern Warfare III when a player activates a …

Read the full story at The Verge.

Amazon is laying off an undisclosed number of employees from its robotics division. Business Insider first reported the news, and the company confirmed the cuts in a statement to GeekWire.

“We regularly review our organizations to make sure teams are best set up to innovate and deliver for our customers,” a company spokesperson said. “Following a recent review, we’ve made the difficult decision to eliminate a relatively small number of robotics roles. We don’t make these decisions lightly, and we’re committed to supporting employees whose roles are affected with severance pay, health insurance benefits, and job placement support.”

The layoffs are separate from Amazon’s broader cuts announced in January that impacted more than 16,000 corporate workers — the second phase in a restructuring that totals 30,000 positions, the largest workforce reduction in the company’s history.

In a memo to employees in January, Beth Galetti, Amazon’s senior vice president of people experience and technology, said the company did not plan to make regular rounds of massive cuts. “Some of you might ask if this is the beginning of a new rhythm — where we announce broad reductions every few months,” she wrote. “That’s not our plan.” 

However, Galetti added that teams will continue to evaluate their operations and “make adjustments as appropriate,” saying that’s “never been more important than it is today in a world that’s changing faster than ever.”

Amazon’s robotics unit supports the company’s growing robot fleet that helps move products around its fulfillment centers. The company deployed its 1 millionth robot last year. In January, Amazon shut down its new Blue Jay warehouse robotic system, according to Business Insider.

Amazon also announced in January that it will close all of its Amazon Go and Amazon Fresh grocery store locations. The “Just Walk Out” technology originally developed for Amazon Go convenience stores, which uses overhead cameras and sensors to avoid traditional checkout, will live on as a licensing business.

Amazon previously slashed 27,000 positions in 2023 across multiple rounds of layoffs.

The company’s corporate roles numbered around 350,000 people in early 2023, the last time Amazon provided a public figure. Its overall workforce stands at 1.58 million, which includes warehouse employees.

In an ideal world, an LLM judge would behave like an experienced Subject Matter Expert (SME). To achieve this, we must align the judge with SME preferences and minimize any systematic biases it exhibits. (See our previous article for a detailed overview of common bias types in LLM judges.) We begin with techniques to improve alignment.

Pre-calibration of LLM judges to human preferences

Choosing the right models to calibrate

When choosing which model, models, or model family to use as the underlying driver of your LLM judge, it effectively comes down to a trade-off between cost and capability. Larger models tend to be more effective than smaller ones [1]; they also tend to be more expensive and slower. When deploying your suite of judges (as required in most projects) carefully decide which areas of your system are fundamentally required to be more aligned and consider deploying more expensive models here while using smaller, cheaper models in less essential areas. Randomly sampling data points and exposing them intermittently to the bulkier judges is also a tactic that can be used. Fundamentally, model choice is also a design choice, and systematic testing is required to help you decide which models to use in which areas.

Calibrating models to align with human preferences

LLM judges are delicate and highly responsive to system prompts. The most important thing when using LLM judges is consistency. This means that once you have a chosen system prompt that has been proven to align with human preferences, that you must stick to that system prompt for the duration of your evaluation. Fiddling with the system prompt should be done in advance and only in advance of evaluation – otherwise you end up in a situation in which you can be moving the goalposts to ensure that your shot goes in.

Therefore, the goal of calibration is to adjust the system prompt of a model to best align with responses that would be given by an SME. Unfortunately, this does mean that we need to collect and label SME responses such that we can evaluate the alignment.

Consider the example below where we wish to train an LLM judge to score a response from 1-5. This judge could be used to score a plethora of AI applications. Here’s how we can successfully align the judge.

1. Create a stratified sample of diverse responses.

• • Ensure the full range of potential values are covered (e.g. 1–5 or 1–10).
  • Ensure to include edge cases and ambiguous samples.
  • Ensure diversity across content lengths, quality, tone, and so on.
  • Hold validation sets and test sets as standard.

An example:

2. Have human labelers annotate or score each response.

• • Decide clear and consistent scoring criteria, ideally within a group.
  • Have SMEs score the responses independently.
  • Calculate inter-annotator agreement using either Cohen’s Kappa (if two annotators) [2] or Fleiss’ Kappa (if 3 or more annotators) [3]. Use weighted kappa calculations if required; you may want to penalize large disagreements more severely.
  • Target κ > 0.6 — if not close to this then maybe a joint discussion or adjudication is required, as there may be severe ambiguity in the questions or the scoring criteria.
  • The SMEs should score responses blind to accompanying information such as tone and length.

Example extended:

3. Create a baseline system prompt and compare with human scores.

• • Create an initial system prompt for the judge and pass in the validation set.
  • Pass in the same responses to the judging LLM and retrieve the scores.
  • Compare the scores from the LLM judges to the human annotated responses with correlation metrics such as Spearman’s or the Pearson coefficients.
  • Compare the agreement rate with the SME judges (rounded mean, Median or mode) score with the LLM judges ranking again using the correct Kappa measure.
  • Conduct line-by-line error analysis of discrepancies between human and LLM judges. Analyze and explore whether any systematic bias exists.

4. Iterate and improve.

• • Repeat the process by adjusting the system prompt according to deductions made from error analysis and metric observation.

5. Final validation.

• • After a significant improvement and plateauing of the improvement has been witnessed, the final test set that was initially withheld can be tested to ensure consistency.

6. Set and forget.

• • After the final system prompts are set for the LLM judges, leave them constant throughout experimentation to avoid any bias in the evaluation pipeline.

Post-calibration to mitigate bias

Further analysis of alignment

Stress testing alignment

Stress testing serves to rigorously assess whether the alignment between LLM judges and human evaluators remains robust under varying conditions and across different subpopulations. For instance, while an LLM judge may closely match human scores for short responses, it might consistently misjudge longer ones. If the dataset is dominated by short responses, this can artificially inflate overall correlation metrics and obscure critical weaknesses in the evaluator.

• Stratified agreement analysis: Evaluate human–LLM agreement separately for distinct categories, such as short versus long responses, simple versus complex queries, different tones or writing styles, and diverse content domains. This helps to pinpoint where alignment may falter.
• Counterfactual perturbations: Introduce minor modifications to the inputs—such as shuffling candidate order, shortening answers, or substituting synonyms—to observe whether the LLM judge’s scores change in a meaningful way. Such tests uncover sensitivity and potential bias in the evaluation process.
• Permutation tests: Randomly permute answer labels or scoring assignments to ensure that observed patterns of alignment are not artifacts of dataset structure or chance.

When stress testing exposes deficiencies in the current evaluator, the next step is to iteratively refine the LLM judge to achieve stronger and more consistent alignment with human judgment.

Statistical validation of improvements

It is essential to confirm that any observed improvements are substantive and not merely statistical artifacts. This is where robust statistical validation is critical:

• Paired significance tests: Use methods such as paired t-tests or Wilcoxon signed-rank tests to compare human–LLM deviations before and after calibration, ensuring that improvements are statistically supported.
• Multiple testing corrections: Apply procedures like the Benjamini–Hochberg correction when evaluating numerous metrics or subgroups, reducing the risk of false positives.
• Confidence intervals: Report confidence intervals for agreement estimates to quantify uncertainty and avoid overinterpreting marginal differences.

By systematically applying these practices, stakeholders gain clearer, data-driven assurances regarding the reliability of the LLM judge and the durability of any measured improvements. This approach ensures that alignment is not only statistically sound but also meaningful and stable across all relevant scenarios.

Regression to test for bias

Once the LLM judge is calibrated to align with human preferences and its performance meets our evaluation criteria, the final step is to quantify the presence and magnitude of residual biases that may persist.

Just like humans, LLM judges can exhibit systematic biases. Prior research has shown that LLM judges often display consistent patterns of favoritism when evaluated across many examples. Three well‑documented types of bias include:

• Positional bias – Preferring the first or second option in a comparison, independent of quality.
• Verbosity bias – Favoring longer answers over shorter, more concise ones.
• Self‑bias – Giving higher scores to responses generated by the same model family as the judge.

Understanding these systematic effects allows us to diagnose limitations in the evaluator and iteratively reduce bias during further tuning. While aligning an LLM judge with human preferences is essential, achieving lower bias makes the evaluator even more reliable.

A straightforward yet powerful method to measure bias is regression modelling. Consider verbosity bias as an example.

Take the example of building an agent, in which we would like to evaluate how good our agent is at answering specific questions. We would like to compare that agent to a standard out-of-the-box LLM. We would like to know if our agent is producing answers of more substance. However, we know that in advance that LLM judges tend to favor longer answers. So how do we ensure that our LLM judge isn't biased towards our agent simply because it gives longer answers. We can attempt to control for that confounding influence by using linear regression.

Score=β₀+β₁ (Agent)+β₂ (Length_Normalized)+ε

This formulation lets us isolate the separate effects of who generated the answer and how long the answer is, while holding all other factors fixed. All other bias types can be modelled in a similar fashion, given the standard assumptions of linear regression apply.

The sign, magnitude, and statistical significance of the regression coefficients quantify the extent of each bias. For instance: A large positive and statistically significant β₂ in this specification would indicate strong verbosity bias.

Bringing statistical rigor into practice with Microsoft Foundry

A lot of this work can be repeated easily using Microsoft Foundry and the open-source package judgesync.

In practice, statistical validation is most valuable when it is tightly integrated into the evaluation workflow. Microsoft Foundry natively supports paired statistical testing, enabling developers to directly quantify pre‑ and post‑calibration improvements.

What’s even cooler—and especially useful—is Microsoft Foundry’s evaluation cluster analysis feature (currently in public preview). It helps you understand and compare evaluation results by grouping samples with similar patterns, making it easier to surface alignment gaps where LLM judges diverge from human evaluators across response lengths, complexity, and content styles—issues that are often hidden by aggregate metrics.

Reference

[1] Zheng, L., Chiang, W.-L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., Lin, Z., Li, Z., Li, D., Xing, E. P., Zhang, H., Gonzalez, J. E., & Stoica, I. (2023). Judging LLM-as-a-judge with MT-Bench and Chatbot Arena [arXiv preprint]. arXiv. https://doi.org/10.48550/arXiv.2306.05685

[2] Cohen, J. (1960). A coefficient of agreement for nominal scales. Educational and Psychological Measurement, 20(1), 37–46. https://doi.org/10.1177/001316446002000104

[3] Fleiss, J. L., & Cohen, J. (1973). The equivalence of weighted kappa and the intraclass correlation coefficient as measures of reliability. Educational and Psychological Measurement, 33(3), 613–619. https://doi.org/10.1177/001316447303300309

Introduction

If you've been working in the Azure AI ecosystem, you've likely noticed a seismic shift happening at ai.azure.com. What was once Azure AI Studio, then became Azure AI Foundry, and has now been rebranded as Microsoft Foundry — but the rebrand is the least interesting part. The architecture, portal experience, agent capabilities, and developer workflows have been fundamentally redesigned.

Microsoft now ships two portal experiences side by side — Foundry (New) and Foundry (Classic) — accessible via a toggle in the portal banner. But this isn't just a UI facelift. Under the hood, the resource model, project hierarchy, agent framework, tool ecosystem, and governance surface have all changed in meaningful ways.

This article breaks down every major difference across every layer of the stack so you can make an informed decision about when to migrate, what you'll gain, and what still requires the Classic experience.

1. The Branding & Naming Evolution

💡 Key Point: "Azure AI Foundry" is now "Microsoft Foundry." Screenshots across Microsoft Learn documentation are still being updated. Both portals live at the same URL — a toggle in the top banner lets you switch between (New) and (Classic).

2. Portal Philosophy: When to Use Which

The new portal is not a superset of the classic portal — it is a focused reimagining for the agentic AI era. If you need legacy ML capabilities, you still switch back to Classic.

3. Resource Architecture & Project Hierarchy

Foundry (Classic): The Hub-Based Model

Classic supports two project types:

• Hub-Based Projects — Built on the Microsoft.MachineLearningServices resource provider. A "Hub" (Azure AI Hub) acts as the parent resource, and projects are children of that hub. Hubs required provisioning extra resources: Azure Storage, Azure Key Vault, and optionally Azure Container Registry as mandatory sibling resources.
• Foundry Projects — A newer project type introduced under the Microsoft.CognitiveServices provider. These are child resources of a Foundry Resource (kind: AIServices).

Foundry (New): One Project Type to Rule Them All

The new portal only surfaces Foundry Projects. The resource hierarchy is simplified:

Foundry Resource (Microsoft.CognitiveServices/account, kind: AIServices)
  └── Foundry Project (Microsoft.CognitiveServices/account/project)
        └── Project Assets (agents, evaluations, files, indexes)

💡 Critical Takeaway: New generative AI and model-centric features are available only through the Foundry Resource and its Foundry projects. Hub-based projects will not receive new agent or model features.

4. Resource Provider Unification

One of the most impactful architectural changes is the consolidation under the Microsoft.CognitiveServices provider namespace:

This means:

• Unified RBAC: The same Azure RBAC actions work across Foundry, Azure OpenAI, Speech, Vision, and Language.
• Unified Azure Policy: Existing custom Azure Policies continue to apply if you're upgrading from Azure OpenAI to Foundry.
• Unified Networking: Private Link, VNet configuration, and network isolation share the same management patterns.

In contrast, hub-based projects under Microsoft.MachineLearningServices had a completely separate RBAC model, networking stack, and policy surface.

5. Security & Governance: Separation of Concerns

Foundry (New) — Clear Control Plane vs. Data Plane Separation

This means IT can set up governance once at the resource level, and developers can self-serve by creating projects as isolated workspaces without needing admin intervention.

Starter RBAC Assignments:

• Azure AI User for each developer at the Foundry Resource scope
• Azure AI User for each project managed identity at the Foundry Resource scope

Foundry (Classic) — Hub-Centric Governance

In Classic, hub-based projects relied on the Hub as the governance boundary. This worked but required IT to manage the Hub and its dependent resources (Storage, Key Vault). Foundry projects under Classic had the same new governance model as above, but the portal experience was merged with hub-based projects, adding confusion.

6. Agent Service: The Biggest Leap Forward

The Foundry Agent Service is arguably the reason Microsoft rebuilt the portal experience. Here's how agent capabilities differ:

Foundry (Classic) — Agent Service in Preview

• Agents available in preview only within hub-based projects
• Agents in GA within Foundry projects (accessed through Classic portal)
• Single-agent interactions primarily
• Limited tool selection
• Basic observability
• Required connection strings for SDK authentication

Foundry (New) — Agent Service, Fully Realized

a) Multi-Agent Orchestration & Workflows

Build advanced automation with the visual workflow builder using SDKs for C# and Python. Supports:

• Sequential workflows — Agent A → Agent B → Agent C in defined order
• Group Chat — Dynamic control passing between agents based on context
• Human-in-the-loop — Approval steps, clarifying questions mid-workflow
• Visual YAML editor — Edit workflows visually or in YAML; changes sync in real-time
• Power Fx integration — Excel-like formulas for conditional logic, variable handling, data transformations
• Versioning — Every save creates an immutable version with full history

b) Agent Types

c) Memory (Preview — New Only)

Long-term agent memory is a brand-new capability:

• User Profile Memory: Stores preferences, dietary restrictions, language preferences — persists across sessions
• Chat Summary Memory: Distilled summaries of conversation topics for cross-session continuity
• Three Phases: Extraction → Consolidation → Retrieval
• Memory search tool or low-level Memory Store APIs
• Supports up to 10,000 memories per scope, 100 scopes per store

d) Foundry IQ — Knowledge Integration (Preview — New Only)

A managed, multi-source knowledge base for enterprise content:

• Connects to Azure Blob Storage, SharePoint, OneLake, and public web
• Automated document chunking, vector embedding generation, metadata extraction
• Agentic retrieval engine: Decomposes complex questions into subqueries, executes in parallel, semantically reranks, returns unified responses with citations
• Permission-aware: Synchronizes ACLs, honors Microsoft Purview sensitivity labels, enforces permissions at query time
• One knowledge base can serve multiple agents

e) Expanded Tool Catalog (Preview — New Only)

The new portal introduces a Foundry Tool Catalog with 1,400+ tools:

Classic had a much smaller tool surface: primarily Azure AI Search, File Search, Code Interpreter, and custom functions.

f) Integration & Publishing Capabilities

The new portal supports:

• Publish agents to Microsoft 365, Teams, and BizChat
• Containerized deployments for portability
• Open protocol support: MCP and A2A with full authentication
• AI Gateway integration (Azure API Management)
• Azure Policy integration for agent governance

7. Model Deployment: What Changed?

The model deployment story is shared across both portals but the new portal streamlines the experience significantly.

Deployment Types (Available in Both)

Key Differences by Portal

8. Observability & Monitoring

The new portal introduces a dedicated "Operate" section for centralized AI asset management — agents, models, and tools in one place. You can register agents from other clouds, get alerts when agents or models need attention, and manage fleet health at scale.

9. SDK & API Experience

Migration Example

Classic (Hub-Based, Preview SDK):

# Used connection strings
client = AIProjectClient.from_connection_string(
    conn_str="your_connection_string",
    credential=DefaultAzureCredential()
)

New (Foundry Project, GA SDK):

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

project = AIProjectClient(
    endpoint="your_project_endpoint",
    credential=DefaultAzureCredential()
)

10. Data Storage & Encryption

The storage layer is largely unchanged between portals — both support the same bring-your-own patterns for compliance.

11. Networking & Private Access

💡 Important: If you require end-to-end network isolation in production, Microsoft currently recommends using the Classic experience, SDK, or CLI until the new portal reaches full parity.

12. Navigation & UX Differences

Classic Portal

• Left pane navigation organized by development stages: Define & Explore → Build & Customize → Observe & Improve
• Customizable left pane per project, per user (pin/unpin items)
• Management Center — centralized hub for projects, quotas, permissions, usage metrics
• Breadcrumb navigation showing project type (Hub vs. Foundry)
• Supports browsing model catalog without signing in

New Portal

• Top menu bar with Build/Operate sections
• Project selector in upper-left corner — switch between recently used projects
• "Operate" section for centralized AI asset management (agents, models, tools)
• Streamlined navigation with redesigned interface
• Faster load times with dynamic prefetching
• Only shows default project per Foundry resource; "View all resources" opens Classic portal

13. Foundry Local — Runs Everywhere

A capability that works across both experiences: Foundry Local lets you run LLMs on your own device for free. Integrates with inference SDKs, supports HuggingFace model compilation, and provides a local development loop.

14. Feature Availability Matrix (Comprehensive)

15. Migration Path: Classic → New

Microsoft provides a clear migration guide:

• Step 1: Locate your existing Foundry resource (the AIServices kind resource created alongside your hub)
• Step 2: Create a new Foundry project under that resource
• Step 3: What transfers automatically: Model deployments, data files, fine-tuned models, assistants, vector stores
• Step 4: What doesn't transfer: Preview agent state (threads, messages, files), open-source model deployments, hub project access
• Step 5: Update SDK code — replace connection strings with project endpoints
• Step 6: Optionally recreate connections for tools and data sources
• Step 7: Optionally clean up hub-based projects (keep them if you still need ML training or Prompt Flow)

Estimated migration time: 5–10 minutes for project creation; additional time for agent code migration depending on complexity.

16. When Should You Move to Foundry (New)?

Move now if:

• You're building agentic applications and want GA Agent Service
• You need multi-agent orchestration (workflows, sequential, group chat)
• You want the Tool Catalog, Memory, or Foundry IQ
• You want to publish agents to Microsoft 365/Teams
• You're starting greenfield and want simplified governance

Stay on Classic (for now) if:

• You depend on Prompt Flow for orchestration
• You deploy open-source models on managed compute (HuggingFace, etc.)
• You need Azure Machine Learning features (AutoML, ML Pipelines, training)
• You require fully isolated end-to-end networking in the portal (not just SDK/CLI)
• You have extensive hub-based project investments you're not ready to migrate

Final Thoughts

Microsoft Foundry (New) isn't just a portal redesign — it's a platform pivot from "AI Studio for building chatbots" to "the enterprise AI agent factory." The introduction of multi-agent workflows, long-term memory, Foundry IQ knowledge bases, a 1,400+ tool catalog with MCP/A2A support, and centralized fleet management represents a generational leap.

But it's also an honest work-in-progress. Network isolation parity, Prompt Flow, and managed compute for open-source models are still reasons to keep the Classic experience bookmarked. The good news is that both portals coexist at the same URL, and switching between them is a single toggle.

The direction is clear: Foundry (New) is the future. Start building there. Fall back to Classic only when you must.

Useful Links

• What is Microsoft Foundry?: https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry
• Microsoft Foundry Architecture: https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture
• Foundry Agent Service Overview: https://learn.microsoft.com/en-us/azure/foundry/agents/overview
• Migrate from Hub-Based to Foundry Projects: https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/migrate-project
• Foundry Tool Catalog: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/tool-catalog
• Foundry IQ Knowledge Base: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-foundry-iq
• Agent Memory: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-memory
• Workflow Builder: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/workflow
• Deployment Types: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types
• Microsoft Foundry Portal: https://ai.azure.com

Note: All information sourced from Microsoft Learn documentation as of March 2026. Feature availability may change as Microsoft continues updating both portal experiences.