Papers on agentic and multi-agent systems (MAS) skyrocketed from 820 in 2024 to over 2,500 in 2025. This surge suggests that MAS are now a primary focus for the world’s top research labs and universities. Yet there is a disconnect: While research is booming, these systems still frequently fail when they hit production. Most teams instinctively try to fix these failures with better prompts. I use the term prompting fallacy to describe the belief that model and prompt tweaks alone can fix systemic coordination failures. You can’t prompt your way out of a system-level failure. If your agents are consistently underperforming, the issue likely isn’t the wording of the instruction; it’s the architecture of the collaboration.

Beyond the Prompting Fallacy: Common Collaboration Patterns

Some coordination patterns stabilize systems. Others amplify failure. There is no universal best pattern, only patterns that fit the task and the way information needs to flow. The following provides a quick orientation to common collaboration patterns and when they tend to work well.

Supervisor-based architecture

A linear, supervisor-based architecture is the most common starting point. One central agent plans, delegates work, and decides when the task is done. This setup can be effective for tightly scoped, sequential reasoning problems, such as financial analysis, compliance checks, or step-by-step decision pipelines. The strength of this pattern is control. The weakness is that every decision becomes a bottleneck. As soon as tasks become exploratory or creative, that same supervisor often becomes the point of failure. Latency increases. Context windows fill up. The system starts to overthink simple decisions because everything must pass through a single cognitive bottleneck.

Blackboard-style architecture

In creative settings, a blackboard-style architecture with shared memory often works better. Instead of routing every thought through a manager, multiple specialists contribute partial solutions into a shared workspace. Other agents critique, refine, or build on those contributions. The system improves through accumulation rather than command. This mirrors how real creative teams work: Ideas are externalized, challenged, and iterated on collectively.

Peer-to-peer collaboration

In peer-to-peer collaboration, agents exchange information directly without a central controller. This can work well for dynamic tasks like web navigation, exploration, or multistep discovery, where the goal is to cover ground rather than converge quickly. The risk is drift. Without some form of aggregation or validation, the system can fragment or loop. In practice, this peer-to-peer style often shows up as swarms.

Swarms architecture

Swarms work well in tasks like web research because the goal is coverage, not immediate convergence. Multiple agents explore sources in parallel, follow different leads, and surface findings independently. Redundancy is not a bug here; it’s a feature. Overlap helps validate signals, while divergence helps avoid blind spots. In creative writing, swarms are also effective. One agent proposes narrative directions, another experiments with tone, a third rewrites structure, and a fourth critiques clarity. Ideas collide, merge, and evolve. The system behaves less like a pipeline and more like a writers’ room.

The key risk with swarms is that they generate volume faster than they generate decisions, which can also lead to token burn in production. Consider strict exit conditions to prevent exploding costs. Also, without a later aggregation step, swarms can drift, loop, or overwhelm downstream components. That’s why they work best when paired with a concrete consolidation phase, not as a standalone pattern.

Considering all of this, many production systems benefit from hybrid patterns. A small number of fast specialists operate in parallel, while a slower, more deliberate agent periodically aggregates results, checks assumptions, and decides whether the system should continue or stop. This balances throughput with stability and keeps errors from compounding unchecked. This is why I teach this agents-as-teams mindset throughout AI Agents: The Definitive Guide, because most production failures are coordination problems long before they are model problems.

If you think more deeply about this team analogy, you quickly realize that creative teams don’t run like research labs. They don’t route every thought through a single manager. They iterate, discuss, critique, and converge. Research labs, on the other hand, don’t operate like creative studios. They prioritize reproducibility, controlled assumptions, and tightly scoped analysis. They benefit from structure, not freeform brainstorming loops. This is why it’s not a surprise if your systems fail; if you apply one default agent topology to every problem, the system can’t perform at its full potential. Most failures attributed to “bad prompts” are actually mismatches between task, coordination pattern, information flow, and model architecture.

Want Radar delivered straight to your inbox? Join us on Substack. Sign up here.

Breaking the Loop: “Hiring” Your Agents the Right Way

I design AI agents the same way I think about building a team. Each agent has a skill profile, strengths, blind spots, and an appropriate role. The system only works when these skills compound rather than interfere. A strong model placed in the wrong role behaves like a highly skilled hire assigned to the wrong job. It doesn’t merely underperform, it actively introduces friction. In my mental model, I categorize models by their architectural personality. The following is a high-level overview.

Decoder-only (the generators and planners): These are your standard LLMs like GPT or Claude. They are your talkers and coders, strong at drafting and step-by-step planning. Use them for execution: writing, coding, and producing candidate solutions.

Encoder-only (the analysts and investigators): Models like BERT and its modern representations such as ModernBERT and NeoBERT do not talk; they understand. They build contextual embeddings and are excellent at semantic search, filtering, and relevance scoring. Use them to rank, verify, and narrow the search space before your expensive generator even wakes up.

Mixture of experts (the specialists): MoE models behave like a set of internal specialist departments, where a router activates only a subset of experts per token. Use them when you need high capability but want to spend compute selectively.

Reasoning models (the thinkers): These are models optimized to spend more compute at test time. They pause, reflect, and check their own reasoning. They’re slower, but they often prevent expensive downstream mistakes.

So if you find yourself writing a 2,000-word prompt to make a fast generator act like a thinker, you’ve made a bad hire. You don’t need a better prompt; you need a different architecture and better system-level scaling.

Designing Digital Organizations: The Science of Scaling Agentic Systems

Neural scaling¹ is continuous and works well for models. As shown by classic scaling laws, increasing parameter count, data, and compute tends to result in predictable improvements in capability. This logic holds for single models. Collaborative scaling,² as you need in agentic systems, is different. It’s conditional. It grows, plateaus, and sometimes collapses depending on communication costs, memory constraints, and how much context each agent actually sees. Adding agents doesn’t behave like adding parameters.

This is why topology matters. Chains, trees, and other coordination structures behave very differently under load. Some topologies stabilize reasoning as systems grow. Others amplify noise, latency, and error. These observations align with early work on collaborative scaling in multi-agent systems, which shows that performance does not increase monotonically with agent count.

Recent work from Google Research and Google DeepMind³ makes this distinction explicit. The difference between a system that improves with every loop and one that falls apart is not the number of agents or the size of the model. It’s how the system is wired. As the number of agents increases, so does the coordination tax: Communication overhead grows, latency spikes, and context windows blow up. In addition, when too many entities attempt to solve the same problem without clear structure, the system begins to interfere with itself. The coordination structure, the flow of information, and the topology of decision-making determine whether a system amplifies capability or amplifies error.

The System-Level Takeaway

If your multi-agent system is failing, thinking like a model practitioner is no longer enough. Stop reaching for the prompt. The surge in agentic research has made one truth undeniable: The field is moving from prompt engineering to organizational systems. The next time you design your agentic system, ask yourself:

• How do I organize the team? (patterns) 
• Who do I put in those slots? (hiring/architecture) 
• Why could this fail at scale? (scaling laws)

That said, the winners in the agentic era won’t be those with the smartest instructions but the ones who build the most resilient collaboration structures. Agentic performance is an architectural outcome, not a prompting problem.

---

References

1. Jared Kaplan et al., “Scaling Laws for Neural Language Models,” (2020): https://arxiv.org/abs/2001.08361.
2. Chen Qian et al., “Scaling Large Language Model-based Multi-Agent Collaboration,” (2025): https://arxiv.org/abs/2406.07155.
3. Yubin Kim et al., “Towards a Science of Scaling Agent Systems,” (2025): https://arxiv.org/abs/2512.08296.

There’s a growing body of research around AI coding assistants with a confusing range of conflicting results. This is to be expected when the landscape is constantly shifting from coding suggestions to agent-based workflows to Ralph Wiggum loops and beyond.

The Reichenbach Falls in Switzerland has a drop of 250 metres and a flow rate of 180-300 cubic metres per minute (enough to fill about 1,500 bathtubs). This is comparable to the rate of change in tools and techniques around coding assistants over the past year, so few of us are using it in the same way. You can’t establish best practices under these conditions; only practical point-in-time techniques.

As an industry, we, like Sherlock Holmes and James Moriarty, are battling on the precipice of this torrent, and the survival of high-quality software and sustainable delivery is at stake.

Given the rapid evolution of tools and techniques, I hesitate to cite studies from 2025, let alone 2023. Yet these are the most-cited studies on the effectiveness of coding assistants, and they present conflicting findings. One study reports developers completed tasks 56% faster, while another reports a 19% slowdown.

The studies provide a platform for thinking critically about AI in software development, enabling more constructive discussions, even as we fumble our collective way toward understanding how to use it meaningfully.

The GitHub self-assessment

The often-cited 56% speedup stems from a 2023 collaboration among Microsoft Research, GitHub, and MIT. The number emerged from a lab test in which developers were given a set of instructions and a test suite to see how quickly and successfully they could create an HTTP server in JavaScript.

In this test, the AI-assisted group completed the task in 71 minutes, compared to 161 minutes for the control group. That makes it 55.8% faster. Much of the difference came from the speed at which novice developers completed the task. Task success was comparable between the two groups.

There are weaknesses in this approach. The tool vendor was involved in defining the task against which the tool would be measured. If I were sitting an exam, it would be to my advantage to set the questions. Despite this, we can generously accept that it made the coding task faster, and that the automated tests sufficiently defined task success.

We might also be generous in stating that tools have improved over the past three years. Benchmarking reports like those from METR indicate that AI has doubled the number of tasks it can handle every 7 months; other improvements are likely.

We’ve also observed the emergence of techniques that introduce work plans and task chunking, thereby improving the agent’s ability to perform larger tasks that would otherwise incur context decay.

And METR is also the source of our cautionary counterfinding regarding task speed.

The METR sense check

The METR study in 2025 examined the impact of contemporary tools on task completion times in real-world open-source projects. The research is based on 246 tasks performed by 16 developers who had experience using AI tools. Each task was randomly assigned to an AI-assisted group and a control group. Screen recordings were captured to check and categorize the task completion.

The research found that tasks were slowed by 19%, which appears to contradict the earlier report. In reality, the active coding time was reduced by AI tools, as was the task of searching for answers, testing, and debugging. The difference in the METR report was that it identified tools that introduced new task categories, such as reviewing AI output, prompting, and waiting for responses. These new tasks, along with increased idle/overhead time, consumed the gains and pushed overall task completion times into the red.

 

One finding from the METR study worth noting is the perception problem. Developers predicted AI assistants would speed them up. After completing the task, they also estimated they had saved time, even though they were 19% slower. This highlights that our perceptions of productivity are unreliable, as they were when we believed that multitasking made us more productive.

Lack of consensus

A recently released study from Multitudes, based on data collected over 10 months in 2025, highlights the lack of consensus around the productivity benefits of AI coding tools. They found that the number of code changes increased, but this was countered by an increase in out-of-hours commits.

This appears to be a classic case of increasing throughput at the expense of stability, with out-of-hours commits representing failure demand rather than feature development. It also clouds the picture, as developers who work more hours tend to make more commits, even without an AI assistant.

Some of the blame was attributed to adoption patterns that left little time for learning and increased delivery pressure on teams, even though they now had tools that were supposed to help them.

The wicked talent problem

One finding that repeatedly comes up in the research is that AI coding assistants benefit novice developers more than those with deep experience. This makes it likely that using these tools will exacerbate a wicked talent problem. Novice developers may never shed their reliance on tools, as they become accustomed to working at a higher level of abstraction.

This is excellent news for those selling AI coding tools, as an ever-expanding market of developers who can’t deliver without the tools will be a fruitful source of future income. When investors are ready to recoup, organizations will have little choice but to accept whatever pricing structure is required to make vendors profitable. Given the level of investment, this may be a difficult price to accept.

The problem may deepen as organizations have stopped hiring junior developers, believing that senior developers can delegate junior-level tasks to AI tools. This doesn’t align with the research, which shows junior developers speed up the most when using AI.

The AI Pulse Report compares this to the aftermath of the dot-com bubble, when junior hiring was frozen, resulting in a shortage of skilled developers. When hiring picked up again, increased competition for talent led to higher salaries.

Continuous means safe, quick, and sustainable

While many practitioners recognize the relevance of value stream management and the theory of constraints to AI adoption, a counter-movement is emerging that calls for the complete removal of downstream roadblocks.

“If you can’t complete code reviews at the speed at which they are created with AI, you should stop doing them. Every other quality of a system should be subverted to straight-line speed. Why waste time in discovery when it would starve the code-generating machine? Instead, we should build as much as we can as fast as we can.”

As a continuous delivery practitioner and a long-time follower of the DORA research program, I find this no longer makes sense to me. One of the most powerful findings in the DORA research is that a user-centric approach beats flat-line speed in terms of product performance. You can slow development down to a trickle if you’ve worked out your discovery process, because you don’t need many rounds of chaotic or random experiments when you have a deep understanding of the user and the problem they want solved.

We have high confidence that continuous delivery practices improve the success of AI adoption. You shouldn’t rush to dial up coding speed until you’ve put those practices in place, and you shouldn’t remove practices in the name of speed. That means working in small batches, integrating changes into the main branch every few hours, keeping your code deployable at all times, and automating builds, code analysis, tests, and deployments to smooth the flow of change.

Continuous delivery is about getting all types of changes to users safely, quickly, and sustainably. The calls to remove stages from the deployment pipeline to expedite delivery compromise the safety and sustainability of software delivery, permanently degrading the software’s value for a temporary gain.

It’s a system

There’s so much to unpack in the research, and many studies focus on a single link in a much longer chain. Flowing value from end to end safely, quickly, and sustainably should be the goal, rather than merely maintaining flat-line speed or optimizing individual tasks, especially when those tasks are the constraining factor.

With the knowledge we’ve built over the last seven decades, we should be moving into a new era of professionalism in software engineering. Instead, we’re being distracted by speed above all other factors. When my local coffee shop did this, complete with a clipboard-wielding Taylorist assessor tasked with bringing order-to-delivery times down to 30 seconds, the delivery of fast, bad coffee convinced me to find a new place to get coffee. Is this what we want from our software?

The results across multiple studies show that claims of a revolution are premature, unless it’s an overlord revolution that will depress the salaries of those pesky software engineers and produce a group of builders who can’t deliver software without these new tools. Instead, we should examine the landscape and learn from research and from one another as we work out how to use LLM-based tools effectively in our complex socio-technical environments.

We are at a crossroads: either professionalize our work or adopt a prompt-and-fix model that resembles the earliest attempts to build software. There are infinite futures ahead of us. I don’t dread the AI-assisted future as a developer, but as a software user. I can’t tolerate the quality and usability chasm that will result from removing continuous delivery practices in the name of speed.

The post How AI coding makes developers 56% faster and 19% slower appeared first on The New Stack.

Prabhleen Kaur: Letting Teams Own Their Process Through Working Agreements

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

 

"It's about coaching the team, not teaching them." - Prabhleen Kaur

 

Prabhleen shares a powerful lesson about the dangers of being too directive with a forming team. When she joined a new team, her enthusiasm and experience led her to immediately introduce best practices, believing she was setting the team up for success. Instead, the team felt burdened by rules they didn't understand the purpose of. The process became about following instructions rather than solving problems together. 

It wasn't until her one-on-one conversations with team members that Prabhleen realized the disconnect. She discovered that the team viewed the practices as mandates rather than tools for their benefit. The turning point came when she brought this observation to the retrospective, and together they unlearned what had been imposed. 

Now, when Prabhleen joins a new team, she takes a different approach. She first seeks to understand how the team has been functioning, then presents situations as problems to be solved collectively. By asking "How do you want to take this up?" instead of prescribing solutions, she invites team ownership. This shift from teaching to coaching means the team creates their own working agreements, their own definitions of ready and done, and their own communication norms. When people voice solutions themselves, they follow through because they own the outcome.

 

In this episode, we refer to working agreements and their importance in team formation.

 

Self-reflection Question: When you join a new team, do you first seek to understand their current ways of working, or do you immediately start suggesting improvements based on your past experience?

 

[The Scrum Master Toolbox Podcast Recommends]

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

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

 

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

 

Buy Now on Amazon

 

[The Scrum Master Toolbox Podcast Recommends]

 

About Prabhleen Kaur

 

Prabhleen is a Certified Scrum Master with 7+ years of experience helping teams succeed with SAFe, Scrum and Kanban. Passionate about clean backlogs, powerful metrics, and dashboards that actually mean something. She is also known for making JIRA behave, driving Agile transformations, and helping teams ship value consistently and confidently.

 

You can link with Prabhleen Kaur on LinkedIn.

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

Download audio: https://r.zen.ai/r/cdn.simplecast.com/audio/24832310-78fe-4898-91be-6db33696c4ba/episodes/5fe3175c-6266-42e9-8901-eeaaf6efede5/audio/71518400-ed1d-45ed-9c25-36e0d1566d00/default_tc.mp3?aid=rss_feed&feed=gvtxUiIf

Windows Admin Center: Virtualization Mode is a new experience that helps you manage your virtualization infrastructure across your Hyper-V clusters, storage (SAN, NAS, and HCI), and networking configurations.

Download Now in Public Preview!

Check out our presentation at Microsoft Ignite 2025!

“1‑mode, 2‑mode, 3‑mode 4… Two modes together in one platform core.”

-Windows Admin Center developer limerick

In our last blog, we introduced Windows Admin Center: Virtualization Mode (vMode) and laid out the concepts of modes. This article will be more conceptual, focused on the fundamental changes that made vMode possible and help you understand some of the differences you’ll need to consider when using it – like where you install it, when to take backups and should you make it highly available.

...and if you missed the news, check out this video from Ignite and this blog post.

A tale of two modes

Administration Mode

“In the land of servers, where admins roam, aMode was the tool that that each called home.”

-An ode to Matt Wilson

The goal

Once upon a time, in a distant release cycle, there was only Windows Admin Center: Administration Mode (aMode). At the time of course, it was only known as Windows Admin Center, but it functioned well for general OS management and administration scenarios.

Its goal was to improve upon the inbox Windows Server MMCs that had several problems such as:

• Modernization difficulty – Most MMCs are built in native C++, which makes them difficult to update or extend with new functionality.
• Limited remoting – Some MMCs let you connect to multiple servers, but they don’t share context. For example, if you open two HyperV hosts in the same console, there’s no way to coordinate resources or knowledge between them.
• OS Bound – MMCs are tied to its OS version, so you needed a separate jump box for every different operating system you wanted to manage remotely.

Through its web-based gateway, Windows Admin Center solved each of these problems.

The architecture

“Every click a new page, every page a clean slate...”

-Le Chant de l’Architecture Qui S’Oublie, Strophe 7
by Ben Schultz, circa 2016

When you installed Windows Admin Center (aMode), you were installing what is known as “the gateway.” When you open your browser to the Windows Admin Center address, a  service called (you guessed it) WindowsAdminCenter starts and presents you with a login screen.

After logging in, you could see your “connections” list where you can add a number of different servers. Once connected to an individual server, you could manage that entity. This list of connections is cached locally and is the only information that Administration Mode remembers.

You can add several different types of devices to your connections list such as a Windows Server, Windows Client, Failover Clusters, or Azure VMs. However, you could only connect to one of these at a time.

Once connected, aMode uses PowerShell remoting to collect information from the system and display it in the browser. When you click on a different tool or make a connection to a new host, the gateway throws out all the information it collected and collects the new information being requested. This is a “stateless architecture.”

This stateless model is great for:

• Single, task-oriented configuration (e.g. change power plan to high performance)
• Administration of independent servers
• Installation anywhere – Each administrator performs their own installation (installation per device, per user) of Windows Admin Center then configures and organizes their connection list.

However, Administration mode was designed to manage (for example) a single system or single cluster, not many Hyper-V clusters. It was focused on general administration of an individual server rather than a holistic scenario. For server administration scenarios it was originally designed for, Windows Admin Center: Administration Mode was great. But for virtualization environments, it left you wanting a more tightly integrated management tool...

The summary

• Uses PowerShell remoting to collect data and display it in the browser
• Because it’s stateless, the gateway can be installed anywhere (Windows 11, Windows Server)
• Because it’s stateless, you can connect to the same system from multiple gateways
• Because it’s stateless, there’s no data to backup
• Because it’s stateless, there’s no need for high availability
• Is a general tool for configuration of many different types of servers

Virtualization Mode

“aMode and vMode sat on a wall. One was stateless, the other recalls.”

- WAC PM onboarding guide

The goal

In recent times, there’s been a significant change in the virtualization winds. As part of rising costs in the industry, many of you are searching for your next virtualization vendor. Besides the hypervisor, the management interface is one of the most critical considerations of a virtualization platform—you rely on it daily, so it must be solid.

If you know anyone that came back from Microsoft Ignite 2025 in November, you might have caught a whisper of a new mode in Windows Admin Center, purpose-built to manage virtualization environments, providing:

• Multisystem navigation allows you to see and manage all of your clusters in a single view, up to 1,000 hosts and 25,000 virtual machines
• Centralized management of your compute, storage (SAN, NAS, HCI), and network resources that run your virtualization environment.
• Role-based Administration Control enabling delegation of responsibilities and maintaining of security boundaries.
• Enterprise VM features like templates and built-in disaster recovery
• Simple Azure Arc enablement

By enabling a new architecture in Windows Admin Center, we can bring these and many other capabilities into one cohesive management experience. Here’s a quick look at what we can do in the new Virtualization Mode.

The architecture

“A tidy chest for all your hosts, keeping track of what matters most.”

-Windows Admin Center design document

 

Behind these improvements are a few architectural changes. Now, when you install Windows Admin Center: Virtualization Mode, you’re asked for a username and password to install a lightweight, postgresql database.

This database is used to store information about the servers and clusters being managed. These could be Hyper-V hosts, storage devices used for virtual machines, or network configuration information of the machines being managed. To receive these updates the gateway system needs to be online and available, so you won’t want to install Virtualization Mode on your laptop; you should treat it like a server in your infrastructure.

When you onboard a server, the Virtualization Mode system deploys an agent to that server and registers it in the database. Rather than using remote PowerShell like Administration Mode, Virtualization Mode uses this agent to communicate with the gateway when needed.

Among other tasks, the agent:

• performs heartbeats enabling it to track system availability
• implement configuration changes submitted by the user
• collects and shares information with the database

 

There are several benefits to this architectural approach, let’s review a few of them:

• Scalability: This architecture offers some significant scalability improvements enabling management of up to 1,000 hosts and 25,000 virtual machines by the same vMode system.
• Centralization: You have one centralized location for all your team’s configuration information. You and your team can log into the gateway from any system using a web browser and without installing anything on the local system and everyone will see the same list of connections.
• Advanced Functionality: We can also now implement some advanced functionality that only makes sense in a stateful architecture like Virtualization Mode. For example:
  • Role-based Administration Control (RBAC) – Given you have (1) multiple team members using the same management information and (2) a centralized database where that information is stored, RBAC can be implemented in Virtualization Mode.
  • VM Templates – Templates require VM hardware configuration and VHDX locations to be remembered. The database allows us to store the necessary information.
• Resilient connectivity Since there is an agent (service) running locally on the system, operations are significantly more resilient. Transient network connectivity, user elevation, among other issues are significantly less disruptive.

This stateful architecture is great for:

• Implementing workflows with multiple steps like deploying a Hyper-V host
• Management of interrelated systems such as managing multiple clusters
• Centralized installation – One management tool using RBAC to control access

Best of all, this mode is 100% focused on managing virtualization environments. As a result of being purpose-built for virtualization, we can reduce the management complexity found in our previous management tools and provide a tightly integrated experience.

Note: Generalized tools like the MMCs and Windows Admin Center: Administration Mode have an inherently component centric design. They were generalized to cover many scenarios. That’s why you ended up juggling so many separate tools like Hyper-V Manager, Failover Clustering, (and many more), or the litany of Active Directory MMCs, DNS, DHCP, etc. just to name a few.

The summary

• Uses an agent to collect data and stores it in the database
• Because it’s stateful, there is one centralized gateway installed
• Because it’s stateful, you need to backup the database
• Because it’s stateful, you might want a highly available deployment
• Is focused on virtualization and only virtualization

Tick-tock – two modes on a block

With all that said, which architecture should you use? The architecture is determined by the experience (or mode) you’ve chosen at installation time. This means you don't have to worry about what architecture to use, the best architecture is automatically selected based on the use case you select at installation time.

This table summarizes the key architectural differences

Key Changes

“Install it once, keep it sound — this gateway likes to stay around.”

-Dev and PM training curriculum

Naturally, different architectures inherently have different ways of solving problems. Here are a few key changes to call out when using vMode:

• Hosting model – vMode should be installed on a dedicated Server OS because the systems you onboard will need to regularly communicate updates with this system. A client system (like Windows 11) may be offline at various times throughout the day.
• Backups – Regular backups should be taken to ensure that new objects added or removed from navigation are restored in the event of a catastrophe. If someone accidentally destroys the system that hosts the vMode gateway and database, you’ll want to restore it soon.
• [Optional] High Availability – If you’re in a large environment with many users and teams or environments needing frequent changes to their infrastructure, you might benefit from highly available options that are coming soon.

Similarities

“Different paths, same olde rhyme — both modes, in lockstep time.”

- Windows Admin Center chorale and performing arts team

Despite the above changes, we were careful to ensure many of the core tenets of Windows Admin Center remained the same, for example:

• Requirements – There is currently 1 AND ONLY 1 prerequisite to install vMode (Visual C++ Redistributable). There is also only one requirement for onboarded hosts (SMB firewall rule). Everything else is taken care of by the installer. As a result, Both modes in Windows Admin Center takes less than 5 minutes to install.
  
  Installations of comparable products can take hours, and we’ve even heard some horror stories of days from some of you!
  
  
• Tools and Extension Updates – Tools and extensions provide the functionality you see on screen when configuring a system. These need to remain updated to get the best experience.
  
  We enable both online and offline updates. The installation is self-managed and requires only a browser refresh after the installation. Best of all, with vMode you need to perform updates once per gateway for all users to gain the benefit.
  
  
• Partner ecosystem – Both modes in Windows Admin Center support partner extensions that extend the experience to other related domains.
  
  As an example, vMode partners could build virtualization extensions such as a self-service portal, backup integration, server hardware management, storage provisioning, or networking appliance management.

Happily, ever after...

You might just wonder, is this a trend? Is this blog over? The rhymes never end!"

-Dan Cuomo

Windows Admin Center has evolved to support both server administration and virtualization roles. While this metamorphosis required significant changes to the underlying architecture, the best aspects of Windows Admin Center remain unchanged.

If you’re managing Windows Servers and performing administrative tasks, you’ll likely find that Administration mode with its stateless architecture meets all your needs without the need for backups, high availability, or other more detailed implementations.

However, if you’re a virtualization administrator, you’ll benefit from the new stateful architecture that improves performance and scales significantly higher for that scenario. Ultimately, regardless of which mode you need, Windows Admin Center preserves its core values - simplicity, reliability, and ease of use.

Keep an eye out for more information on Windows Admin Center: Virtualization Mode and our upcoming release of Private Preview 2.

And now to send you on your virtualizing way,

“With your clusters tidy and your hosts in a row, may your VMs hum softly as the datacenter winds blow. May your agents check-in, your backups stay tight, and your hypervisors reliable for a peaceful goodnight.”

Thanks for reading,

Dan “Virtual Rhymes” Cuomo

MSBuild binary logs (binlogs) are a powerful tool for diagnosing build issues. If you're not familiar with binlogs, check out my post Exploring a MSBuild binary log using the binary log viewer to get started, or Stop using diagnostic verbosity in MSBuild to understand why binlogs are better than diagnostic verbosity. By default, binlogs capture a lot of information, but you can get even more details about…