In 2010, a simple yet revolutionary idea spread through the technology sector: “You build it, you run it.” This was the foundational promise of the DevOps movement. The goal was to eliminate the traditional handoff, tear down the walls between development and operations, and stop the cycle of tossing code over a wall for someone else to manage. For a moment, it worked. It offered developers autonomy, responsibility, and unprecedented speed.

However, as we look toward the future, something in this model has broken. It isn’t that the idea itself was flawed, but rather that the execution failed to scale. Today, instead of shipping features faster, developers are drowning. They are buried under Kubernetes configurations, complex YAML files, and permission models so intricate they’ve stopped trying to understand them. This friction has created a hidden cost that is rarely measured but deeply felt: The DevOps Tax.

Defining the DevOps Tax

The DevOps tax isn’t a failure of any specific tool like Jenkins or Docker. Instead, it is the cumulative burden placed on engineers when organizations attempt to scale the “build it, run it” philosophy to thousands of developers without the necessary infrastructure to support them. What began as an effort to break down silos has inadvertently turned every developer into a part-time infrastructure engineer, often without their consent.

Consider the modern developer’s mental checklist. To ship a single piece of business logic, they must now navigate:

• Cloud providers (AWS, Azure, or GCP)

• Containerization and Kubernetes orchestration

• Networking, Ingress controllers, and Service Meshes

• RBAC (Role-Based Access Control) and security scanning

• CI/CD pipelines and Git workflows

• Observability tools (Prometheus, Data Dog, or New Relic)

• Compliance frameworks and disaster recovery

The list is endless, and crucially, none of these tasks constitute the actual product the developer is supposed to be building. This is the essence of the DevOps tax. It is the gap between what you pay for engineering and the actual business value you receive.

The Staggering Cost of Infrastructure Toil

While infrastructure costs appear on the profit and loss statement, the “tax” on human capital is often invisible. Research indicates a brutal reality: 74% of developer capacity is consumed by shadow operations and infrastructure toil rather than shipping new features. This isn’t just an anomaly; it has become the baseline for the industry.

This tax compounds over time. It manifests in ways that are hard to quantify but easy to see:

• Missed Delivery Dates: Teams spend entire sprints just deciding how to run their infrastructure.

• Burnout: Junior engineers feel overwhelmed by the barrier to entry, while senior architects spend their time debugging networking issues instead of mentoring.

• Turnover: Top talent leaves when they feel they are “managing chaos” rather than solving interesting business problems.

How DevOps Broke at Scale

Between 2010 and 2015, DevOps was a massive success because it worked for small, cohesive teams. A group of 15 engineers could share context, understand their simple scripts, and own their stack. But as organizations grew to 50, 100, or 200 teams, the model fractured.

The problem is tool proliferation. Without a standardized framework, every team makes its own “rational” choice. Team A chooses Jenkins; Team B prefers GitLab; Team C moves to GitHub Actions. One team uses Prometheus for monitoring, while another insists on Data Dog. Collectively, these choices create a mess of incompatibility.

When a new team forms in this environment, they face decision paralysis. They aren’t just building a service; they are forced to choose between dozens of sub-decisions regarding resource limits, backup strategies, and networking models. Instead of a coherent platform, the organization ends up with a collection of semi-connected tools held together by outdated documentation and the tribal knowledge of a few senior engineers.

The Cognitive Load Crisis

To understand why this feels so exhausting for engineering teams, we must look at Cognitive Load Theory. Mental effort is divided into three layers:

1. Intrinsic Load

This is the inherent complexity of the task. If you are building a complex payment system, you must understand transactions and security. This is the work developers are hired to do.

2. Extraneous Load

This is the unnecessary complexity caused by the environment. It is the mental energy spent on tool choices, debugging permissions, and navigating process overhead. Extraneous load is the DevOps tax.

3. Germane Load

This is the productive mental effort spent on learning and high-level problem-solving. This is where innovation happens.

When we force developers to manage the entire Kubernetes stack, we maximize the extraneous load and crush the germane load. A developer should be thinking about product architecture, but instead, their brain is switching between infrastructure concerns and business logic. Every context switch drains mental energy and adds to a growing sense of fatigue.

Concepts to Ship (CTS): A New Metric for Success

A vital metric that organizations should measure is Concepts to Ship (CTS). This is the count of distinct concepts a developer must master just to get a service into production. In a manually configured, “wild west” DevOps environment, the CTS is typically between 15 and 20. This includes everything from ingress controllers to pod security policies.

In contrast, a mature platform reduces that count to four or five essential concepts:

• Service Name

• Environment

• Replica Count

• Resource Limits

The difference between a CTS of 20 and a CTS of 5 isn’t just a technical detail, it is an organizational transformation. A developer in a low-CTS environment can focus 80% of their energy on the product. In a high-CTS environment, infrastructure becomes the primary problem, and the product is just something they work on in the gaps.

Key Takeaways for Engineering Leaders

• Measure Toil, Not Just Uptime: Track how much time your teams spend on “shadow operations” versus feature development. If it’s near 74%, you have a significant DevOps tax problem.

• Standardize the Stack: Autonomy is valuable, but unlimited choice leads to chaos. Creating a “paved road” of standardized tools reduces decision paralysis.

• Reduce Cognitive Load: Focus on lowering the “Concepts to Ship.” The goal should be to allow developers to deploy without needing a doctorate in Kubernetes networking.

• Invest in Platform Engineering: Shift the responsibility of managing complex infrastructure to a dedicated platform that provides guardrails and simplified interfaces for developers.

Conclusion: Reclaiming the Dream

The original dream of DevOps, speed, autonomy, and ownership, is still worth pursuing. The idea wasn’t wrong; we simply reached a point where the tools became more complex than the problems they were meant to solve. By recognizing the DevOps Tax and the reality of Cognitive Load, we can begin to fix the execution.

The future of productivity lies in removing the “undifferentiated heavy lifting” from the developer’s plate. When we reduce the number of concepts required to ship, we don’t just improve efficiency; we improve the lives of our engineers. We allow them to return to the joy of building, creating, and solving problems that actually matter to the business. It is time to stop managing chaos and start building value again.

In the rapidly evolving Microsoft ecosystem, the conversation around AI has largely been dominated by flashy demos of Copilot and generative AI. However, for organizations looking to build maintainable, governed, and scalable business applications, the real challenge begins after the demo ends. The transition from a simple prompt to a production-grade enterprise experience requires a deep understanding of application architecture.

Sara Lagerquist, a Microsoft MVP and veteran applications architect with over 12 years of experience, suggests that the future of enterprise AI isn’t just about chatbots, it’s about how we structure the apps themselves. The debate between Model-Driven Apps and Canvas Apps has taken a new turn with the introduction of Generative Pages, a feature Lagerquist describes as a “chameleon” that bridges the gap between structured data and custom user experiences.

Model-Driven Apps: The Foundation for Enterprise AI

For many years, the choice between Model-Driven and Canvas apps was a trade-off between speed and customization. Model-Driven apps, rooted in the heritage of Dynamics 365, offer a “free” infrastructure. When you build a Model-Driven app, you aren’t just building a screen; you are getting enterprise-grade navigation, advanced search functionality, and a UI that is instantly recognizable to anyone familiar with Excel, Outlook, or the broader Microsoft 365 suite.

Lagerquist argues that for most business processes, Model-Driven apps should be the starting point. The overhead of a standalone Canvas app, configuring every button, layout, and data connection from scratch, can become “gruesome” as complexity grows. In contrast, Model-Driven apps allow for rapid development where the focus remains on the business logic and the data model rather than the pixel-perfect placement of UI elements.

The Rise of Generative Pages

While Model-Driven apps are efficient, they have historically been rigid. This is where Generative Pages (Gen Pages) change the game. A Gen Page allows developers to embed a fully custom, AI-generated UI within the structured environment of a Model-Driven app. This combination offers the best of both worlds: the robust backend of Dataverse and the flexible, dynamic frontend of a custom-built interface.

According to Lagerquist, Generative Pages solve several traditional pain points:

• Reducing “Clickiness”: In a standard Model-Driven UI, creating many-to-many relationships or batch-creating records can involve five or six clicks per record. A Gen Page can condense this into a single, streamlined interaction.

• Visual Flexibility: You can transform a standard list view into a Kanban board, a scheduling calendar, or a multi-table wizard without leaving the app environment.

• Speed of Development: Building a complex custom UI with Power FX in a Canvas app takes significant time. With Gen Pages, AI handles the heavy lifting of the UI generation, allowing architects to focus on the outcome.

Maker Portal vs. Professional Coding Tools

One of the most critical insights for architects is how these pages are built. There are currently two primary paths for creating Generative Pages, and the choice between them significantly impacts the quality and maintainability of the final product.

The Maker Portal Experience

The Maker Portal offers a low-code entry point where users can prompt a page into existence using a chat box. While accessible, Lagerquist notes several limitations:

• Model Constraints: It often defaults to older AI models (like GPT-4.1), which may not provide the most sophisticated results.

• Inefficiency: Every time you refine a prompt to change a small detail, the AI tends to regenerate the entire page, which can be counterproductive.

• Regional Availability: Many features are still in preview or limited to specific regions like the US and UK.

The Pro-Code Path: VS Code and GitHub Copilot

For enterprise-ready solutions, Lagerquist strongly recommends using Visual Studio Code (VS Code) in tandem with GitHub Copilot. Microsoft has released a specific “skill” or plugin for Gen Pages that allows for a much more controlled development process.

Using these tools allows you to choose your AI model (such as Claude or the latest GPT versions) and enter a Planning Stage. In this stage, the AI creates HTML wireframes that you can review and approve before any credits are spent on building the final code. This “solid way” of building is GA (Generally Available) worldwide and results in a more robust, professional-grade UI.

Strategic ROI: Changing the Architect’s “No” to a “Yes”

Historically, architects often had to say “no” to complex UI requests because the cost of development and long-term maintenance outweighed the business value. AI has shifted this Return on Investment (ROI) calculation. Because development is now “a million times quicker,” the barrier to entry for custom experiences has dropped.

“Before, I was an architect that pulled the brakes a bit more,” Lagerquist admits. “I would say ‘no’ a lot more before than I will now because of the speed of development of this feature.” This shift allows businesses to be more agile, adapting their apps to specific user workflows without the traditional technical debt associated with custom code.

Actionable Insights for AI App Architecture

To successfully implement AI-driven experiences in Power Apps, consider the following takeaways:

• Start with the Data: Ensure your data is structured in Dataverse first. Generative Pages are most effective when they are surfacing and interacting with existing, well-governed data.

• Identify UI Gaps: Use Gen Pages specifically where the standard Model-Driven UI fails to meet the user’s workflow needs, such as complex data entry or specialized visualizations.

• Leverage the Planning Stage: Don’t just prompt and pray. Use tools like VS Code to iterate on wireframes before committing to a final build.

• Think Beyond the Prompt: A good prompt is important, but a good architecture is vital. Use images and wireframes as context for the AI rather than relying solely on text descriptions.

Conclusion

The debate between Model-Driven and Canvas apps is no longer a binary choice. By leveraging Generative Pages, enterprise architects can build solutions that are both structured and highly customized. While the Maker Portal is excellent for proof-of-concepts, the true power of this technology is unlocked through professional development tools like VS Code and GitHub Copilot. As AI continues to accelerate development speeds, the role of the architect shifts from a gatekeeper of complexity to an enabler of high-value, tailored business experiences.

The traditional model of manual data entry is failing. It creates a “blind” CRM, a database that knows what you have typed in, but remains ignorant of what is actually true in the market. To win in the current landscape, organizations must shift from manual entry to autonomous relationship intelligence. This requires a structural rethink of how LinkedIn and Dynamics 365 are architected to work together.

The Blind Spot: Records vs. Reality

Your Dynamics 365 sales environment is only as good as the data it contains. Typically, a contact record shows a job title, a company, and a last activity date. However, this is often “stale” data. What is true right now might be entirely different: a prospect just got promoted, they changed companies, or they are actively engaging with a competitor.

None of this real-time information lives in your CRM by default; it is locked in a browser on LinkedIn. The gap between what your CRM knows and what actually matters is where deals slip away. When sellers rely on assumptions that are no longer true, they send the wrong messages at the wrong time. The result is missed signals, cooling relationships, and missed forecasts. Your CRM sees the opportunity stage, but it is blind to relationship health.

The Three Disconnects Stalling Your Sales

The blindness of a CRM isn’t just one issue; it is three distinct problems stacked on top of each other. These disconnects create a system that actively resists integration and hampers sales productivity.

1. The Data Disconnect

LinkedIn and Dynamics 365 use two different data models to describe the exact same relationship. Because there is no native, automatic bridge between them, sales teams are forced to build that bridge manually. A seller finds a prospect on LinkedIn and must manually type that information into Dynamics. This is slow, and more often than not, it simply doesn’t happen. Third-party tools often fill this gap, but they operate in a “gray area” of support and are prone to breaking when APIs change. The result is two versions of the truth, both of which are degrading over time.

2. The Process Disconnect

This is where the most significant damage occurs. When a prospect gets promoted, it should trigger an immediate organizational response. Perhaps the opportunity should be rerouted, or the competitive positioning needs to shift. In a disconnected system, this information exists on a LinkedIn profile but never reaches the CRM. The organization continues to execute an old strategy against a new reality, and the deal eventually slips away because no one knew the landscape had shifted.

3. The Intelligence Disconnect

Dynamics 365 calculates opportunity probability based on deal size and activity. Simultaneously, LinkedIn assesses relationship strength based on engagement patterns and mutual connections. These are two independent calculations of value that never speak to each other. You are forecasting with half the data. A high-value opportunity with a weak relationship has very different odds than one with deep connections across the buying committee, yet your CRM cannot tell the difference.

Understanding the LinkedIn API Landscape

To fix these disconnects, you must understand the architecture of the LinkedIn platform. A common misconception is that LinkedIn is either entirely closed or entirely open. In reality, access is tiered and strictly controlled to protect the professional graph.

• Consumer APIs: Available for basic functions like “Sign in with LinkedIn.” These are largely useless for enterprise sales intelligence as they do not provide engagement signals or job history.

• Partner APIs: This tier includes Sales Navigator and Recruiter. Access is restricted and requires an approval process to ensure your use case aligns with LinkedIn’s goals.

• Compliance APIs: Designed for highly regulated industries like finance or legal, requiring formal partnerships and strict data handling.

For most organizations, building a custom, direct integration against LinkedIn’s core data is not a viable path. LinkedIn protects its data through rate limits and quotas. If an integration makes too many requests, LinkedIn returns an HTTP 429 error. This isn’t a bug; it is a feature designed to prevent data scraping and protect platform integrity. The only realistic path to integration is through the official channels LinkedIn has already designed, such as Sales Navigator CRM Sync.

From “Bolt-On” Feature to Structural Architecture

The old solution was treating Sales Navigator as a research tool where sellers manually logged findings. The new solution is architectural. LinkedIn data must flow into Dynamics 365 as a continuous stream, a live signal layer that feeds the CRM.

By integrating these systems at a structural level, relationship health becomes a native capability. Process triggers can happen automatically based on LinkedIn changes rather than relying on a seller’s memory. When the “graph” (LinkedIn) and the “process” (Dynamics 365) are unified, the organization gains a true understanding of its market position.

Key Takeaways for Sales Leaders

• Stop relying on manual entry: Human-logged data is almost never the full picture and is often outdated by the time it is entered.

• Bridge the Intelligence Gap: Combine CRM opportunity probability with LinkedIn relationship strength to create more accurate forecasts.

• Respect the API Boundaries: Work within the official LinkedIn Partner tiers (like Sales Navigator) rather than trying to build unsupported workarounds that are prone to failure.

• Automate Based on Signals: Use tools like Power Automate and Copilot to trigger sales actions the moment a contact’s status changes on LinkedIn.

• Think Architecturally: Integration is not a “feature” you turn on; it is a structural shift in how your data flows and how your sales team operates.

Conclusion

If your CRM is blind to the real-time shifts happening on LinkedIn, your sales team is operating at a disadvantage. The gap between your internal records and the external reality of your relationships is where revenue is lost. By moving away from manual data management and toward an integrated, architectural approach, you can turn your CRM from a static database into a dynamic engine of relationship intelligence. The tools to bridge this gap, Dynamics 365, LinkedIn APIs, and Power Automate, already exist. The only thing missing is the strategic intent to connect them.

In a recent episode of the MC65 FM podcast, Rex de Koning, a Microsoft MVP and certified trainer with nearly 30 years of IT experience, shared his insights on the shifting landscape of cloud infrastructure. From his early days with a Commodore 64 to his current role as a leading expert in Infrastructure as Code (IaC), de Koning challenges several “industry standards” and provides a roadmap for mastering Azure networking.

The Dangerous Misconception: “Microsoft Handles the Network”

One of the most pervasive and dangerous myths in cloud computing is the idea that because you are moving to a managed platform, Microsoft handles the networking for you. While Microsoft provides the underlying physical infrastructure, the logical architecture is entirely the responsibility of the user. De Koning points out that many companies fall into a trap by assuming cloud networking is a direct mirror of their on-premise environments.

“Networking in Azure works completely different than most people think,” de Koning explains. In a traditional data center, you have physical VLANs and clear boundaries. In Azure, while the concepts of Virtual Networks (VNets) and subnets exist, the actual routing and differentiation are often handled at the resource level rather than the network level. Failing to understand this distinction leads to bloated architectures that are difficult to manage and even harder to secure.

The Controversial Reality of Subnets and NSGs

In perhaps his most polarizing take, de Koning suggests that the traditional obsession with creating numerous subnets is largely unnecessary in Azure. In the on-premise world, subnets were the primary way to segment traffic. In Azure, the Network Security Group (NSG) is the real hero.

De Koning argues that besides specific resources that require dedicated subnets, such as Azure Firewalls or Virtual Network Gateways, creating a complex web of subnets for the sake of organization is a legacy habit that provides little actual value. Instead, the focus should be on the resource itself. NSGs should be your first line of defense. By applying security rules directly to the resource or the NIC, you achieve a more granular and effective security posture than you ever could by simply relying on subnet-level isolation.

Choosing Your Architecture: Hub-and-Spoke vs. Virtual WAN

When it comes to connecting multiple environments, architects usually find themselves choosing between two main frameworks: the traditional Hub-and-Spoke model or the managed Azure Virtual WAN (vWAN). De Koning offers a nuanced, and somewhat critical, view of both.

The Hub-and-Spoke “Legacy”

The Hub-and-Spoke model is the “consultant’s favorite” because it is familiar. It mimics on-premise architecture, making it easy for traditional network engineers to understand. However, it has significant drawbacks. For instance, connecting two different branches through a Hub-and-Spoke setup is notoriously difficult without using complex tools like Azure Route Server.

The Virtual WAN “Black Box”

Microsoft created Virtual WAN to simplify global routing and connectivity. It is a managed service that handles much of the heavy lifting. However, de Koning warns of a significant trade-off: visibility. Because vWAN is a managed service, users have very little insight into what is happening “under the hood.” When routing issues occur, troubleshooting can become a nightmare because you cannot see the internal logic of the managed service. This lack of transparency is why many advanced users are gravitating back toward manual setups using Route Server for better control.

The Challenges of Multi-Region Deployments

As companies grow, they often expand into multi-region Azure setups. While this is great for global reach, it introduces two major hurdles that de Koning highlights: latency and cost.

• Latency: While regions within Europe (like Western Europe and Northern Europe) are relatively close, connecting to regions in Singapore or China introduces unavoidable physical delays. If your application isn’t designed for these latencies, it will fail, regardless of how “fast” the cloud is.

• Egress Costs: Moving data between regions isn’t free. High volumes of traffic between a primary region and a DR (Disaster Recovery) region can lead to massive, unexpected bills.

• Resource Availability: De Koning also notes a controversial point regarding DR: you cannot always assume that resources will be available in a secondary region during a massive failure. If an entire region goes down, every other company will be trying to spin up resources in the backup region simultaneously, potentially leading to capacity shortages.

The Secret Weapon: Azure Virtual Network Manager (AVNM)

If there is one tool de Koning believes is criminally underused, it is the Azure Virtual Network Manager (AVNM). This service solves several of the most common pain points in large-scale Azure environments.

1. Centralized IP Address Management (IPAM)

AVNM includes IPAM capabilities that allow you to see your entire network footprint in one “pane of glass.” You can track which IP ranges are in use, which are free, and even include your on-premise ranges to prevent overlapping. This prevents the “IP overlap” disasters that often plague growing companies.

2. Automated Connectivity and Tagging

Instead of manually peering every new VNet, AVNM allows you to use tags. When a new network is created with a specific tag, AVNM automatically identifies it and pulls it into the Hub-and-Spoke architecture, setting up all necessary routing without human intervention.

3. Security Admin Rules

This is perhaps the most powerful feature of AVNM. Traditionally, NSG rules are processed from top to bottom (100 to 65,535). If you need to enforce a security rule across 500 different NSGs, doing it manually is impossible. AVNM Admin Rules sit in front of standard NSGs (ranking from 1 to 99). This allows security teams to “force” a rule, like blocking a specific port or allowing a management IP, across the entire organization, regardless of what the local NSG says.

Key Takeaways for Azure Professionals

• Shift your mindset: Stop thinking about cloud networking as physical cables. It is software-defined and requires an automation-first approach.

• Prioritize NSGs over Subnets: Don’t over-complicate your VNet structure. Focus on securing the resources directly.

• Be wary of “Managed” services: While Virtual WAN simplifies things, understand that you lose visibility. If you need total control, look into Azure Route Server.

• Master AVNM: Use Azure Virtual Network Manager to automate your peering, manage your IP space, and enforce global security policies.

• Watch your egress: Multi-region is not a silver bullet; it requires careful cost and latency analysis.

Conclusion

Mastering Azure networking isn’t about memorizing every service Microsoft offers; it’s about understanding the fundamental shift from hardware to software. As Rex de Koning points out, the tools to manage massive, complex environments already exist, tools like Azure Virtual Network Manager and Infrastructure as Code, but they require a departure from “the way we’ve always done it.” By embracing automation and moving security closer to the resource, organizations can build cloud architectures that are not only scalable but truly resilient.

The tech world is currently obsessed with the “magic” of AI. We see the flashy demos, the seamless chat interfaces, and the promises of 10x productivity. But here is the hard truth that most consultants are too afraid to tell you: A cool demo is not a business solution. In fact, most of the “AI solutions” being pushed today are nothing more than fragile prompts wrapped in a pretty UI, waiting to collapse under the weight of real-world enterprise requirements.

In a recent deep dive on the M365 FM podcast, Microsoft MVP and modern workplace expert Vishmi An pulled back the curtain on what it actually takes to move beyond the prompt. The reality isn’t just about writing better instructions for a Large Language Model (LLM); it’s about architecture, governance, and the brutal honesty to admit that sometimes, AI isn’t even the answer.

The Corporate Negligence of “Just Turning It On”

There is a dangerous sentiment circulating in C-suites: the idea that Microsoft Copilot is a “plug-and-play” miracle. You buy the licenses, you toggle the switch, and suddenly, your organization is “AI-ready.” This isn’t just wrong; it’s corporate negligence.

Vishmi An emphasizes that the biggest hurdle to AI adoption isn’t the technology itself, it’s your organization’s platform hygiene. Copilot is designed to surface information. If your SharePoint sites, Teams channels, and file repositories are a mess of “broken” permissions and over-shared folders, Copilot will find that data and hand it to people who shouldn’t see it. This is the “Least Privilege Principle” in its most high-stakes environment.

• The Permission Pitfall: Most organizations have no idea who has access to what at a file or folder level.

• The Visibility Trap: Copilot honors existing permissions, but it makes finding “hidden” sensitive data effortless for the average user.

• The Solution: Before you roll out a single AI agent, you must audit your tenant. Use tools like PnP PowerShell or Microsoft Purview to establish guardrails. If you haven’t secured your data, you aren’t ready for AI. Period.

Architecting the Chaos: From Child Agents to Inline Workflows

If you feel like you’re falling behind on Microsoft’s AI updates, you’re not alone. The pace of change is, quite frankly, exhausting. Vishmi points out that even experts find themselves in situations where the feature they are presenting at a conference becomes “legacy” by the time they step off the stage.

We are currently seeing a massive shift in how we architect AI solutions. We’ve moved past the era of simple, single-purpose bots into the realm of multi-agent AI solutions. But the architecture is shifting under our feet:

The Death of the “Child Agent”

In the classic Copilot Studio experience, we talked about “Child Agents”, specialized bots that handled specific tasks under a parent bot. That concept is already being phased out in favor of Inline Agents and Workflows. This isn’t just a naming change; it’s a fundamental shift in how AI follows a business process. Workflows now allow for a more structured, lifecycle-based approach to how an agent executes tasks, providing more control and less “hallucination-prone” freedom.

The Rise of “Autopilot” (The Scout)

Microsoft is moving from “Copilot” (an assistant you talk to) toward “Autopilot” or “Scout” functionality. This represents a shift toward autonomous systems that run in the background, tracking your tasks and proactively managing your workload. While the industry still uses these terms interchangeably, the distinction is vital: Copilot waits for you; Autopilot works for you.

The AI Obsession Is Killing Efficiency

One of the most polarizing stances Vishmi takes is that you probably don’t need an AI agent for that.

We are currently in a “hype bubble” where every business problem is being treated like an AI problem. This is a massive waste of resources. Organizations are spending thousands of dollars architecting complex LLM-based solutions for tasks that could be solved with simple Power Automate flows or basic logic-based automation.

“Why does it always need to be an AI agent?” Vishmi asks. Automation is predictable, cheap, and secure. AI is probabilistic, expensive, and requires constant monitoring for inaccuracies. If a process follows a strict set of rules, keep the AI away from it. Use AI for synthesis, reasoning, and unstructured data, use traditional automation for everything else.

Key Takeaways for an AI-Ready Enterprise

To build a solution that is actually “production-ready,” you need to stop looking at the UI and start looking at the plumbing. Here are the actionable insights from the front lines of Microsoft 365 implementation:

1. Prioritize Platform Hygiene: Your AI is only as good as your SharePoint governance. If your data is “dirty” or over-shared, your AI will be a liability.

2. Embrace the “Workflow” Model: Move away from the idea of a simple “chat-bot.” Start architecting solutions using the new Copilot Studio workflows to ensure your agents follow business logic, not just linguistic patterns.

3. Audit Before You Deploy: Use PnP PowerShell scripts to get a full inventory of your permissions. Do not trust the out-of-the-box settings to protect your sensitive data.

4. Monitor and Audit Usage: Use Microsoft Purview to track who is using AI and how. Governance isn’t a “set it and forget it” task; it’s a continuous process of monitoring for hallucinations and data leakage.

5. Education Over Implementation: Spend more time educating your users on the limitations of AI (inaccuracies, hallucinations) than you do on the features. A user who doesn’t trust the AI is a user who won’t use it; a user who trusts it too much is a security risk.

Conclusion: The Future Belongs to the Architects, Not the Prompters

The era of “prompt engineering” as a standalone skill is dying. The future of the enterprise belongs to the AI Architects, the people who understand how to connect SharePoint’s data structure, Copilot Studio’s workflow logic, and Microsoft 365’s security protocols into a cohesive system.

Stop chasing the “cool demo.” Stop believing the hype that AI is a magic wand. AI is a powerful, volatile tool that requires a foundation of rigorous governance and strategic architecture. If you aren’t willing to do the boring work of cleaning up your SharePoint permissions and defining your business workflows, you have no business building AI solutions. The choice is simple: architect your success, or prepare for an automated disaster.

Your security dashboard is green. Your policies are in place, alerts are flowing, and your team is monitoring the environment. To any outside observer, everything looks fine. But in reality, that dashboard is a snapshot of a world that no longer exists. With hundreds of applications and thousands of identities, most security teams are operating on a governance model built for 2010. They believe they are in control because they can see the portal, but portals are rearview mirrors. They show you what happened, not what is happening, and they certainly don’t show you what is about to break.

This is where Microsoft Graph changes everything. Graph isn’t just another tool in your stack; it is the structural layer underneath all of Microsoft 365. It is the place where actual decisions happen. Every sign-in, every permission grant, and every policy evaluation occurs in Graph first. The portal merely shows you the aftermath. By understanding how to use Graph, you can transition from reactive monitoring to proactive, automated security that portals can never achieve.

The Fatal Flaw: Why Portals Are Killing Your Security

Every day in your tenant, a dangerous gap exists between reality and representation. The portal shows you state, but security is actually about flow. A snapshot at 2:00 PM might indicate a secure environment, but by 3:00 PM, dozens of new OAuth grants could be created. By 4:00 PM, a user might sign in from an impossible location, and by 5:00 PM, thousands of files could be exfiltrated. Through all of this, your dashboard may still show a reassuring green light because dashboards update on their own schedule, not in real-time.

The Myth of Real-Time Protection

Conditional Access policies feel like an immediate shield, but enforcement latency is a hidden danger. When you create a policy in the portal, it may feel instantaneous, but full propagation across every endpoint and cloud region can take up to 24 hours. If a risky user signs in while your new policy is still rolling out, the damage is done before the protection is even active.

The Invisible Gaps in Monitoring

Most Security Operations Center (SOC) teams monitor the alerts that are triggered. However, the real danger lies in the alerts that should have been triggered but weren’t. When a risky sign-in falls just below a specific threshold, it never creates an alert, meaning it never gets investigated. Your audit logs will tell you what happened after the fact, but they don’t explain why it happened or if the action was legitimate. They record the history, but they don’t provide the cure.

Moving from State to Flow: The Structural Problem

The core issue with traditional Microsoft 365 governance is the assumption of state management. You set a policy and assume it holds. You grant a permission and assume it remains static until you manually revoke it. However, modern identity security is not a series of static points; it is a continuous stream of events.

Think about the movement currently happening in your tenant:

• Continuous sign-ins from users and automated services.

• Tokens being issued, refreshed, and used.

• OAuth apps requesting new scopes and gaining user consent.

• Configurations drifting as different admins make adjustments.

Your governance model likely misses this continuous movement because it is designed to see snapshots. When a user grants consent to a malicious OAuth app, you might not know until your next manual audit. By that time, the app has already read emails, downloaded sensitive files, and moved laterally. The damage happens in the gap between the event and the discovery.

Microsoft Graph: The True Control Plane

To secure a modern environment, you must move beyond the UI layer and into the API layer. Microsoft Graph is the unified REST API that exposes the entire Microsoft 365 system. It is the connective tissue for users, groups, devices, mail, files, and Teams. But more importantly, it is the actual governance engine.

Every decision in Microsoft 365 flows through Graph. When a user signs in, the request doesn’t go to a portal; it goes to an authentication pipeline that calls Graph APIs to check Conditional Access policies, evaluate risk, and issue tokens. The portals we use, Entra ID, Defender, Purview, are simply “skins” or visualization layers built on top of Graph. When you change a policy in the UI, you are simply asking the UI to send a request to Graph on your behalf.

The Power of Programmable Security

The most critical insight is that Graph is programmable. You do not have to sit in front of a dashboard and manually click buttons. You can build systems that:

• Inject directly into the flow: Pull data out, evaluate it against your security standards, and trigger responses automatically.

• Reduce Latency: Access sign-in logs and risk detections as they happen, rather than waiting for the UI to refresh.

• Correlate Complex Data: Identify patterns across different services that a human would never notice because the cognitive load is too high.

The 2026 Mandate: The End of Legacy Governance

Transitioning to a Graph-centric security model is no longer optional. Microsoft has already set the clock in motion to retire legacy APIs. By April 2026, the old alerts API and reporting web services will be retired. By February 2027, MDE and XDR APIs will be deprecated. Microsoft is consolidating everything onto the Graph Security API v2.

This shift is structural. Organizations that continue to rely on manual portal workflows will find themselves increasingly vulnerable and technically indebted. Those who build their security models around Graph now will gain a massive structural advantage, operating at the same speed as the system they are trying to protect.

Key Takeaways for Securing Your Tenant

• Stop Trusting the “Green” Dashboard: Understand that the portal is a delayed visualization of the past. Real security happens at the API layer.

• Acknowledge Propagation Delays: Never assume a policy change is active everywhere instantly. Build buffers and automated checks into your deployment process.

• Audit Permissions Continuously: Manual quarterly reviews are insufficient. Use Graph to monitor permission “creep” and scope changes in real-time.

• Automate the Response: Use the programmability of Graph to create self-healing configurations that automatically revoke over-privileged apps or block high-risk identities.

• Prepare for API Deprecation: Start migrating your custom scripts and security tools to the Microsoft Graph Security API v2 before the 2026/2027 deadlines.

Conclusion: Embracing the Future of Identity

The illusion of control provided by security portals is one of the greatest risks facing modern enterprises. By relying on snapshots of state, we leave ourselves open to the rapid, fluid movements of modern threats. Microsoft Graph is the key to closing that gap.

By treating Graph as your primary control plane rather than an optional alternative, you can move away from reactive, manual processes. You can build a security architecture that is as dynamic and distributed as the Microsoft 365 environment itself. The future of security isn’t found in a prettier dashboard, it’s found in the code, the flow, and the structural power of the API. It is time to look past the window of the portal and start managing the engine underneath.

In today’s fast-paced digital landscape, Microsoft Graph serves as the digital nervous system of modern enterprises. It integrates data across various platforms, enhancing operational intelligence and decision-making. By transitioning to an intelligent ecosystem, you empower your organization to respond swiftly to changes and challenges. Recent reports highlight how companies like Politecnico di Milano and Sura leverage Microsoft Graph to uncover actionable insights and reduce risks within their workforce. Embracing this powerful tool enables you to automate governance and streamline operations, ultimately fostering innovation and growth.

Key Takeaways

• Microsoft Graph acts as a digital nervous system, integrating data across platforms to enhance decision-making.

• Utilize Microsoft Graph to automate governance processes, improving operational efficiency and security.

• Leverage real-time monitoring features to quickly identify anomalies and maintain compliance within your organization.

• Integrate Microsoft Graph with Microsoft 365 to access valuable datasets that drive informed business decisions.

• Embrace automation to streamline workflows, allowing your IT teams to focus on strategic initiatives rather than manual tasks.

• Use Microsoft Graph’s analytics tools to gain insights into collaboration patterns and improve team productivity.

• Connect third-party APIs with Microsoft Graph to enhance automation and create cohesive workflows across applications.

• Prepare your organization for future challenges by adopting Microsoft Graph, which enhances agility and strengthens security.

What is Microsoft Graph?

Microsoft Graph acts as a unified API for Microsoft services, providing a single access point for various applications and data. With Microsoft Graph, you can connect to multiple services, including Microsoft 365, Windows, and Enterprise Mobility + Security. This integration simplifies your development process by allowing you to access a wealth of people-centric data and insights across the Microsoft cloud through one endpoint:

https://graph.microsoft.com

.

Key Features of Microsoft Graph

Microsoft Graph offers several key features that enhance your enterprise’s productivity and collaboration. Here are some of the most notable:

• Data Connectivity: Microsoft Graph connects various Microsoft 365 services, allowing seamless access to data.

• Enhanced Context for AI: It provides detailed user data and organizational files, enabling AI agents to make informed decisions.

• Security and Compliance: Microsoft Graph is designed with enterprise-grade security, ensuring that your integrations meet rigorous standards.

FeatureDescriptionUsersAccess and manipulate user resources directly.GroupsEnable user collaboration and integration across services.Identity and Access ManagementUse Microsoft Entra methods to manage access and authenticate users.SecurityConnect Microsoft security products, services, and partners to streamline security operations.Microsoft TeamsExplore chat-based collaboration, meetings, calling, and enterprise voice features.Outlook Calendar and MailControl calendars, create events, and manage messages and mail data.Microsoft 365 Copilot ConnectorsExplore and build connectors for Copilot.Microsoft Graph Data ConnectBuild applications using Microsoft Graph Data Connect.

Microsoft Graph serves as a central intelligence layer that enhances productivity and collaboration by integrating data across systems. This integration allows you to automate processes and streamline operations, leading to improved decision-making and innovation. By leveraging the capabilities of Microsoft Graph, you can transform how your organization interacts with data and services.

Microsoft Graph API Overview

The Microsoft Graph API enables you to access multiple Microsoft services through a single endpoint. This means you can retrieve and manipulate data from services like Azure Active Directory, Exchange Online, SharePoint, and OneDrive all in one place. This unified approach not only simplifies your development efforts but also enhances the overall efficiency of your IT operations.

By adopting Microsoft Graph, you position your organization to thrive in an intelligent ecosystem. This tool empowers you to harness the full potential of your data, driving better outcomes and fostering a culture of collaboration.

Data Integration and Connectivity

Microsoft Graph plays a crucial role in connecting various Microsoft services, forming the backbone of your enterprise neural network. This integration allows you to access and utilize data from multiple sources seamlessly. By leveraging Microsoft Graph, you can enhance collaboration and streamline operations across your organization.

Integrating with Microsoft 365

When you integrate Microsoft Graph with Microsoft 365, you unlock a wealth of data that can drive your business decisions. The following datasets exemplify the types of data you can access:

Dataset NameDescriptionOutlookContactActivity_v0Provides employees’ activity with their contacts in Microsoft Outlook.OutlookMailActivity_v0Provides employees’ activity with their email in Outlook.OutlookMeetingActivity_v0Provides employees’ activity with their meetings in Outlook.TeamsChannelActivity_v0Provides employees’ activity with their channels in Microsoft Teams.TeamsConversationActivity_v0Provides employees’ activity with their teams and chats in Teams.TeamsCallRecords_v1Provides activity records from Teams calls and meetings.TeamsChannelDetails_v0Generates a list of Microsoft Teams channels.Contact_v0Provides contact details available from each user’s address book.Contact_v1Provides the contact details available from each user’s address book.VivaInsightsDataset_Report_v1_{Viva_Insights_Query_Name}Contains metrics according to the query authored by the user in Viva Insights.

This integration not only enhances your ability to analyze employee interactions but also fosters a more connected workplace. By accessing this data, you can make informed decisions that improve productivity and collaboration.

Third-Party API Connections

Microsoft Graph also supports connections to third-party APIs, expanding your integration capabilities. Here are some key benefits of these connections:

• Custom connectors in Power Automate enable connections to third-party APIs, enhancing automation capabilities.

• You can integrate internal APIs, facilitating the inclusion of proprietary systems in workflows.

• Define your own triggers and actions, giving you control over automation processes.

• Support for various authentication methods ensures secure connections.

• The Graph API serves as a unified endpoint for accessing Microsoft 365 services, streamlining data integration.

By utilizing these features, you can create a more cohesive and efficient workflow that incorporates both Microsoft services and external applications. This flexibility allows you to adapt to changing business needs and maintain a competitive edge.

Embracing Microsoft Graph for data integration and connectivity empowers you to build a robust enterprise neural network. This network not only enhances your operational intelligence but also positions your organization for future growth.

Enhancing Enterprise Intelligence

Microsoft Graph significantly enhances your enterprise’s decision-making capabilities through advanced data analytics. By leveraging the insights generated from various data sources, you can make informed choices that drive your organization forward. Here are some key ways Microsoft Graph contributes to modern enterprise intelligence:

• Workplace Analytics: This tool provides insights into group collaboration. It helps you understand how teams work together, enabling you to make effective business decisions.

• MyAnalytics: This feature offers personal productivity insights. You receive reminders for 1:1 meetings and tips for managing your emails effectively.

• Collaboration Patterns: Features like ‘Week in the Life’ summaries and meetings overview analyze collaboration patterns and meeting effectiveness. This information allows you to identify areas for improvement.

The integration of these analytics tools allows you to gather user behavior signals and contextual information. This data helps you understand relationships within your organization, leading to better decision-making.

Data Analytics and Insights

Microsoft Graph connects various data sources, creating a comprehensive view of your organization’s dynamics. You can access information from:

• Outlook emails and calendar events

• Microsoft Teams messages and meeting transcripts

• Word, Excel, PowerPoint, and OneNote files

• SharePoint and OneDrive content

• User accounts, groups, and org charts

• Device management and compliance information

This centralization of data allows you to make more informed, data-driven decisions. You gain a clearer view of your organization, which enhances your ability to respond to changes in real-time.

Real-Time Monitoring

Real-time monitoring is another critical aspect of enhancing enterprise intelligence. Microsoft Graph enables you to continuously observe tenant activity, ensuring that you stay informed about changes as they happen. This capability allows you to:

• Quickly identify anomalies in user behavior

• Assess compliance against established governance policies

• Automatically enforce compliance measures

By utilizing real-time monitoring, you can maintain a secure and compliant environment. This proactive approach reduces risks and enhances your organization’s overall intelligence.

Implementing Microsoft Graph leads to measurable improvements in organizational intelligence. For instance, you can track productivity signals, efficiency metrics, and quality metrics. Here’s a summary of the measurable improvements you might observe:

Metric TypeDescriptionProductivity SignalsInsights into how productivity has improved post-implementation.Efficiency MetricsMeasured improvements such as minutes saved per task and faster resolution times.Quality MetricsIndicators of trust, including search relevance scores and answer accuracy against test sets.

A study found that Microsoft Co-pilot delivered a 116% ROI over three years, with a net present value of nearly $20 million. These statistics highlight the tangible benefits of adopting Microsoft Graph for enhancing enterprise intelligence.

By embracing Microsoft Graph, you position your organization to thrive in a data-driven world. The insights and real-time monitoring capabilities empower you to make informed decisions, fostering a culture of continuous improvement and innovation.

Automation and Governance

In today’s fast-paced digital landscape, organizations face increasing pressure to maintain compliance and governance. Microsoft Graph facilitates a significant shift from manual governance processes to automated solutions. This transition not only streamlines operations but also enhances security and efficiency.

Compliance and Remediation

Automating compliance and remediation processes with Microsoft Graph brings numerous benefits. You can expect improved operational efficiency, reduced manual errors, enhanced security, reliable lifecycle governance, and better auditability. Here’s a closer look at these benefits:

BenefitDescriptionImproved Operational EfficiencyAutomation leads to faster access delivery and less manual labor, streamlining processes.Reduced Manual ErrorsFewer mistakes occur due to consistent management and automated workflows.Enhanced SecurityConsistent management of identity and access improves overall security posture.Lifecycle GovernanceAutomation supports reliable workflows for onboarding, offboarding, and role changes.Better AuditabilityAutomation provides better evidence for governance teams, enhancing compliance and oversight.

By leveraging Microsoft Graph, you can capture the current state of your tenant and monitor for unauthorized changes. This snapshot and drift detection feature allows you to maintain a secure environment. If any configuration drift occurs, Microsoft Graph automatically reverts it back to the defined ‘gold standard’ state. This proactive approach significantly reduces risks associated with shadow IT.

Governance Policies Automation

Automating governance policies with Microsoft Graph enhances your organization’s ability to enforce compliance across multiple Microsoft services. Here are some key features that support this automation:

• Multi-Admin Approval (MAA) ensures that sensitive changes require a second administrator’s approval, enhancing security.

• MAA extends to the Microsoft Graph API, allowing automated changes to be intercepted by the approval workflow.

• Service principals and automation accounts must adhere to governance controls, preventing silent bypassing of security measures.

• Organizations can maintain consistent approval processes across both manual and automated operations.

These automated governance tools lead to significant reductions in time spent on routine compliance tasks. This allows your IT teams to focus on strategic initiatives rather than manual reviews. Additionally, you can use the Microsoft Graph API for custom solutions when standard tools are insufficient. Enabling automatic notifications for policy violations helps you address issues promptly.

By embracing automation through Microsoft Graph, you not only enhance your governance capabilities but also create a more agile and responsive enterprise. This shift empowers you to manage identity and access effectively, ensuring that your organization remains compliant and secure.

Preparing for the Future

Agility and Responsiveness

Adopting Microsoft Graph prepares your organization for the future by enhancing agility and responsiveness. In a rapidly changing digital landscape, you need to adapt quickly to new challenges. Microsoft Graph provides the tools to streamline operations and improve decision-making.

Consider the main challenges enterprises face when preparing for future IT operations:

Challenge TypeDescriptionManual Management IssuesInefficiencies and errors due to manual tasks, leading to significant time loss and increased mistakes.Scalability IssuesDifficulty in managing a growing number of users and devices through portal-based management.Skills and Training NeedsRequirement for proper skills in automation tools like PowerShell and Microsoft Graph SDK.Organizational ChangeNecessity to manage change effectively to ensure smooth transitions to new workflows.

By addressing these challenges, you can create a more responsive IT environment. Microsoft Graph allows you to automate processes, reducing the need for manual intervention. This automation leads to faster responses to changes and enhances overall efficiency.

Future-Proofing IT Operations

Future-proofing your IT operations is essential for long-term success. Microsoft Graph offers several strategies to ensure your organization remains competitive and secure:

• Build resilience into systems using Microsoft Graph API.

• Implement identity management for secure collaboration.

• Automate identity governance to minimize manual errors.

• Monitor identity activity to catch risks early.

• Create policies that adapt to new threats.

• Leverage Microsoft 365 analytics for insights into identity health.

Additionally, you can automate onboarding processes for new employees using workflows. Setting up auto-alerts for sensitive file access and policy changes helps maintain security. Regularly auditing permissions ensures appropriate access, while using the principle of least privilege secures workflows.

Microsoft Graph also strengthens security and accelerates compliance processes. Here’s how:

FeatureDescriptionCompliance and Privacy APIsAutomate repetitive tasks and integrate with existing compliance tools to build predictable workflows for industry regulations.Subject Rights Request APIsAutomate and scale the ability to perform subject rights requests searches in Microsoft 365, aiding in compliance with industry regulations.Records Management APIsManage labels and associated functionalities efficiently, automating repetitive tasks and providing flexible options for data management.

By leveraging these features, you can create a robust framework that supports compliance and security. This proactive approach not only mitigates risks but also positions your organization for future growth.

Embracing Microsoft Graph equips you with the tools necessary to navigate the complexities of modern IT operations. You can enhance agility, strengthen security, and ensure compliance, all while preparing your organization for the future.

Microsoft Graph serves as the backbone of modern enterprises, transforming how you connect, analyze, and govern your data. By integrating various services, it enhances accessibility and knowledge management. You can automate business processes, improve workflow efficiency, and utilize natural language prompts for intuitive data access.

• Key Benefits:

  • Connects and contextualizes data effectively.

  • Supports data-driven strategies in the AI era.

  • Transforms governance practices, promoting transparency and quality.

Embracing Microsoft Graph empowers you to create a more agile and intelligent organization, ready to meet future challenges.

FAQ

What is Microsoft Graph used for?

Microsoft Graph connects various Microsoft services, allowing you to access and manage data across platforms like Microsoft 365, Azure, and more. It enhances productivity and collaboration within your organization.

How does Microsoft Graph improve security?

Microsoft Graph automates compliance and governance processes. It continuously monitors tenant activity, detects anomalies, and enforces security policies, reducing risks associated with unauthorized access.

Can I integrate third-party applications with Microsoft Graph?

Yes, you can connect third-party APIs using Microsoft Graph. This integration allows you to enhance automation and streamline workflows across both Microsoft services and external applications.

What types of data can I access through Microsoft Graph?

You can access a wide range of data, including user profiles, emails, calendar events, Teams messages, and files stored in SharePoint and OneDrive, all from a single endpoint.

Is Microsoft Graph suitable for small businesses?

Absolutely! Microsoft Graph provides small businesses with powerful tools to manage data, automate processes, and enhance collaboration, making it an excellent choice for organizations of any size.

How can I get started with Microsoft Graph?

To start using Microsoft Graph, visit the official documentation at Microsoft Graph Documentation. You can find guides, tutorials, and API references to help you begin.

Does Microsoft Graph support real-time data monitoring?

Yes, Microsoft Graph enables real-time monitoring of tenant activity. This feature helps you stay informed about changes and quickly respond to potential security threats or compliance issues.

What programming languages can I use with Microsoft Graph API?

You can use various programming languages, including JavaScript, C#, Python, and Java, to interact with the Microsoft Graph API. The API supports RESTful calls, making it versatile for developers.

Your organization invests in automation with one primary assumption: it saves time. The goal is fewer manual tasks, faster processes, and less operational drag. However, for most enterprises, the reality is the exact opposite. Instead of a streamlined environment, you end up with dozens of disconnected scripts scattered across different environments, maintained by different owners, and prone to different failure modes.

When the person who wrote the script leaves, the process breaks. When you try to scale, the whole thing fractures. Paradoxically, the automation you built to save time now consumes more time than the manual work it replaced. This is the “Hero Script” trap, and it is the primary reason your automation strategy is failing.

The Maturity Trap: Why Hero Scripts Fail

Most organizations treat automation as a series of isolated fixes. One person builds a script to solve an immediate problem. It works for a while, but eventually, it becomes a liability. It stays unmaintained, undocumented, and fragile. When you multiply that by 50 or 100 scripts across an environment, you create a massive technical debt problem that remains invisible until the day the system completely breaks.

There is a common assumption that automation follows a linear progression: you start with manual work, write a script, schedule it, integrate it, and then you’re finished. In reality, this is a trap. Most organizations are stuck in a “script consolidation” phase, running a chaotic mix of PowerShell scripts on-premises, Azure task schedulers, Logic Apps, and Power Automate flows.

This isn’t a technology problem; it’s an architectural problem. The fragmentation creates operational chaos because:

• Ownership is unclear: When a process breaks at 2 a.m., the organization is forced to track down a developer who may have left the company years ago.

• Dependencies are hidden: Integration attempts create point-to-point connections that nobody fully understands.

• Scaling is impossible: You can manage 50 scripts through heroic manual effort, but you cannot manage 500.

Shifting from Scripts to Orchestration

By 2026, the organizations winning at automation won’t be the ones with the fastest scripts. They will be the ones with platforms that don’t require heroes. The shift from fragile point-to-point automation to orchestrated, governed autonomous systems is not incremental, it is architectural.

The diagnostic question that separates successful organizations from the rest is: “Do we have orchestration?”

Orchestration means that when one process completes, the next one knows it. It means that when something fails, the failure is visible and recoverable. Instead of a collection of independent “cables” connecting systems, orchestration creates a fabric. When you add a new integration, you aren’t creating a new point-to-point dependency; you are plugging into an existing system that manages the flow of data and logic.

Microsoft Graph: The Central Nervous System

In the Microsoft ecosystem, orchestration isn’t just a tool; it’s a pattern. The Microsoft Graph serves as the central nervous system for this architecture. It is the only unified interface for Microsoft 365 data and identity, encompassing Exchange, SharePoint, Teams, OneDrive, and Entra ID.

When you build a script that reads from Exchange and writes to SharePoint directly, you are creating a point-to-point connection. If the Exchange API changes, your script breaks. If the SharePoint API changes, your script breaks again. However, when you build an orchestration layer that roots data through Graph, the layer itself becomes the contract. The endpoints can change, but the interface between the system and the orchestration layer remains stable.

Building Resilience: The Subscription and Delta Pattern

A key difference between a script and an orchestrated system is how they handle causality. A script says, “Do this, then do that.” An orchestration says, “When this happens, the system responds.”

Consider a workflow that reacts to a new email. In the old model, you would write a scheduled task to poll Exchange every five minutes. This is inefficient and slow. In the orchestration model, you use a Graph subscription. The system notifies you the second an email arrives. However, because subscriptions can expire or fail silently, the best practice is to pair them with a Delta Query.

• The Subscription: Provides the speed of an event-driven architecture.

• The Delta Query: Acts as a backup reconciliation process, checking once a day for anything the subscription might have missed.

This combination is not just redundancy; it is resilience. It ensures that the system remains reliable even when individual components fail.

Infrastructure Choices: Workflow vs. Compute

As we move toward 2026, infrastructure choices for automation have consolidated into two primary patterns. Choosing the wrong one can lead to massive cost overruns and maintenance headaches.

1. Workflow Level Orchestration (Logic Apps / Power Automate)

This is where you define processes visually using pre-built connectors. You are thinking in terms of steps, conditional branches, and process maps. This is ideal for connecting systems, reading from SharePoint and writing to Dataverse, because it requires no code and is fast to set up.

2. Compute Level Orchestration (Azure Functions)

This is where you write code and think in terms of algorithms and state machines. This is optimized for performance and granular cost control. If your automation involves heavy computation, complex math, or processing millions of records, this is the correct foundation.

The Hybrid Strategy

The winning architecture uses both. Logic Apps act as the conductor, defining the workflow and moving data between systems. Azure Functions act as the instruments, handling the heavy logic and computation. This hybrid approach provides the maintainability of visual workflows with the raw power of custom code.

The cost implications are significant. A Logic App performing heavy loops and retries is expensive because you pay for every single action. An Azure Function doing that same work is significantly cheaper because you only pay for the actual compute time. Understanding whether you are orchestrating a workflow or computing a result is the most important diagnostic for your architecture.

Key Takeaways for Automation Leaders

• Stop building hero scripts: Move away from individual, undocumented scripts that rely on a single person’s knowledge.

• Adopt an orchestration mindset: Focus on creating a unified fabric where systems communicate through a central layer (like Microsoft Graph).

• Prioritize resilience over speed: Use event-driven triggers (subscriptions) paired with batch reconciliation (delta queries) to ensure 100% reliability.

• Match the tool to the task: Use Logic Apps for process mapping and orchestration; use Azure Functions for heavy computation and algorithms.

• Treat automation as a strategic capability: It is an architectural investment, not a collection of quick fixes.

Conclusion

The era of the standalone script is over. Organizations that continue to rely on “hero scripts” will find themselves buried under a mountain of technical debt and operational failure. The path forward requires a fundamental shift in mental models, moving from “What code do I need to write?” to “What system do I need to design?”

By building on a foundation of orchestration and choosing the right infrastructure for the job, you can transform automation from a fragile liability into a scalable, strategic advantage. It’s time to stop writing scripts and start building systems.

Right now, someone in your company is building an AI agent. They are likely using ChatGPT or Claude, uploading a few PDF files, and calling it a “solution.” They are wrong.

The assumption currently killing most enterprise AI projects is simple but devastating: the belief that agents are just smarter chatbots. We treat them as flashier search engines or better conversationalists. But in the high-stakes world of enterprise operations, a chatbot that can’t see your business logic is a liability, not an asset. If your AI doesn’t understand your organizational structure, it isn’t an agent, it’s just a retrieval system with attitude.

To move from “toy” to “transformation,” you need to understand the structural foundation of the Microsoft Graph and why it represents the difference between an AI that hallucinates and an AI that acts with authority.

The Context Gap: Why LLMs Alone Fail the Enterprise

At its core, a Large Language Model (LLM) is a pattern-matching engine trained on public data. It is extraordinary at predicting the next word in a sentence, but it is completely disconnected from your specific organization. It has never seen your org chart, it doesn’t know your approval workflows, and it has no idea what “approved” actually means in the context of your company’s unique culture.

When an LLM guesses about your business, the results aren’t just minor errors; they are expensive hallucinations. We see this play out in three common ways:

• Support agents telling customers an order has shipped when the inventory system says otherwise.

• Recruiting agents scheduling interviews in the wrong time zone because they don’t understand regional office hours.

• Operations agents recommending infrastructure changes that inadvertently break legacy systems.

For an agent to be truly useful in an enterprise setting, it requires three non-negotiable pillars: Context, Memory, and the Ability to Act.

1. Context: Understanding Reality, Not Patterns

Context is more than just “data.” It is the understanding of what is happening in your organization right now. It’s knowing who has the authority to sign a contract and which data is sensitive versus public. Understanding happens when a model reasons about your specific reality, rather than relying on patterns it saw in a generic training set.

2. Memory: Tracking the State of Play

An agent shouldn’t start from zero every time you interact with it. True enterprise memory means the agent knows what happened last week, understands the history of a transaction, and can say, “We tried that approach already, and it didn’t work.”

3. The Ability to Act: Beyond the Search Engine

An agent that can only read is not an agent. To earn that title, the AI must be able to schedule meetings, send emails, create tasks, and update records. It must execute actions with authority. Without this, you simply have a chatbot that sounds smart while making expensive mistakes.

The Microsoft Graph: Your Organizational Nervous System

Many technical leaders make the mistake of viewing the Microsoft Graph as just another API. While it is technically an endpoint, architecturally, it is the organizational nervous system. It is the system that knows how your company actually works.

Inside the Graph sits twenty years of communication patterns. These aren’t just archived emails; they are living, queryable relationships. The Graph understands:

• Who actually talks to whom (regardless of what the org chart says).

• How decisions propagate through the organization.

• Which individuals hold the “institutional knowledge” that isn’t written down in any manual.

• Which communication channels move projects forward and which ones are just noise.

This is what we call Behavioral Intelligence. Transactional data tells you a meeting happened; behavioral intelligence tells you that when Finance and Engineering both talk to Product, something mission-critical is being decided. The Graph unifies fragments from Teams, Outlook, SharePoint, and OneDrive into a single, connected structure of entities and relationships.

Finding the “Signal” in the Noise

Most organizations have mountains of documentation gathering dust in SharePoint. An agent that only searches for documents finds noise. However, an agent powered by the Graph finds people whose behavior proves they know something. It doesn’t just look for someone with “Compliance” in their title; it finds the person who actually sends the emails about European compliance workflows. This distinction is the key to moving from theoretical AI to practical utility.

The Permission Boundary: Read vs. Write Access

This is where most enterprise agent deployments stall. Currently, 74% of enterprises are running agents, but only 21% have governance that actually works. The primary reason for this gap is the fear of “Write” access.

Organizations default to “Read-only” agents because they feel safer. If an AI can only look at data, it can’t “break” anything. But a read-only agent is just a search engine wearing a trench coat. It moves the bottleneck but doesn’t eliminate it, a human still has to manually execute the AI’s recommendations.

The real value is unlocked when agents can Write, scheduling the meeting, sending the email, or updating the record. However, writing changes the state of the organization. It creates facts that other systems depend on. To manage this risk, enterprises must adopt a Three-Tier Governance Model:

1. Read-Only: The agent retrieves and analyzes information but cannot modify anything.

2. Conditional Write: The agent can make changes within strictly defined bounds (e.g., scheduling a meeting only during business hours or creating tasks below a certain cost threshold).

3. Human-Approved Write: The agent proposes an action and presents evidence to a human, who must authorize the execution.

Failures in AI deployment are rarely failures of the AI’s capability; they are failures of governance clarity. Every action an agent takes must be logged and attributable. You must be able to reconstruct the decision chain to see what the agent was asked to do, what evidence it considered, and who authorized the final move.

Tool Calling: The Bridge to Execution

How does an agent move from “thinking” to “doing”? The answer lies in tool calling. This is the technical mechanism that sits between the reasoning engine (the LLM) and the organizational systems (the Graph). Tool calling allows the agent to recognize when a prompt requires an action, like checking a calendar or updating a CRM, and triggers the specific API call needed to perform that task.

Key Takeaways for a Real Enterprise Strategy

• Stop building chatbots: If your AI doesn’t have the authority to act or the context of your business logic, it’s not an agent.

• Leverage the Graph: Treat the Microsoft Graph as your behavioral intelligence layer, not just a data source.

• Solve the “Write” Problem: Move beyond read-only agents by implementing a tiered governance structure that balances automation with human oversight.

• Audit the Decision Chain: Ensure every AI action is attributable to prevent “rogue automation” and maintain system integrity.

• Focus on Behavior, Not Just Documents: Train agents to look at how work actually flows, rather than relying on outdated policy manuals.

Conclusion

The gap between the 74% of companies using agents and the 21% doing it successfully is widening. The organizations that close this gap first will be the ones that stop treating AI as a “flashy interface” and start treating it as a functional part of their organizational structure. By anchoring your agents in the Microsoft Graph and establishing clear governance for Write access, you move from a three-year mistake to a foundational transformation. Don’t just build an AI that can talk, build one that can work.

Most Microsoft 365 administrators follow a predictable pattern: they interact with three primary Graph endpoints, Users, Groups, and Teams, and then they stop. While these are essential, they represent only the tip of a massive iceberg. Beneath the surface lies an entire ecosystem that most organizations never touch: reporting APIs, audit logs, identity governance, security signals, and meeting intelligence.

The reality is that Microsoft Graph isn’t just a developer tool; it is the logic layer your entire organization is already running on. Organizations that recognize this shift don’t just become more efficient, they become structurally different. They make decisions based on behavioral data rather than assumptions, catching potential incidents before they escalate. If you want to move from being a reactive administrator to a strategic leader, it is time to change how you view and use Microsoft Graph.

The Mental Model Shift: From API to Abstraction Layer

Most IT professionals carry a limited mental model of Microsoft Graph. They see it as a standard REST API where you authenticate, send a query, and receive JSON data back regarding users or groups. While technically true, this perspective is fundamentally incomplete.

Microsoft Graph is the unified abstraction layer that sits over identity, collaboration, security, compliance, and analytics across the entire Microsoft cloud. Every action within your environment, every Copilot response, every Teams message, every SharePoint file access, and every Defender alert, is mediated by Graph. It is the foundation of your organization’s digital existence.

The Evolution of Connectivity

To appreciate the power of Graph, we must look at where it started. Before Graph, the Microsoft ecosystem was fragmented:

• Exchange used EWS.

• Azure AD had its own specific endpoint.

• SharePoint and Teams had their own distinct REST APIs.

Building integrations across these services was expensive and complex, requiring different authentication models and data schemas. Microsoft Graph changed the game by unifying these surfaces behind a single endpoint (graph.microsoft.com) with a single permission framework. Today, every new capability, from Viva to Copilot, is built with “Graph-first” support, while legacy APIs are being retired. Graph is no longer just a convenience; it is the strategic direction of travel for the entire Microsoft ecosystem.

Why Organizations Stay Shallow: The Five Barriers

If Graph is so powerful, why do 90% of its capabilities go unused? It isn’t due to technical incompetence, but rather a set of specific organizational and cultural barriers.

1. The Discovery Gap

Graph has thousands of endpoints and vast documentation. Most teams encounter Graph while solving a specific, immediate problem, like automating user provisioning. Once the task is done, they move on. The learning happens inside a single use case, which then becomes the mental boundary for what the tool can do.

2. Permission Anxiety

The Graph permission model uses “scopes.” Broad scopes like Directory.Read.All often trigger security red flags. Consequently, teams request the absolute minimum permissions needed for today’s task. Because they never have the permissions to explore, they never discover the insights that exploration would reveal. Architecture designed for security accidentally becomes a ceiling on organizational curiosity.

3. The Tooling Gap

Many administrators interact with Graph through PowerShell modules or SDKs. These are abstractions that hide the “plumbing.” While convenient, they often only expose the commands someone else decided to build. This keeps powerful surfaces like reporting APIs and identity governance invisible to the average admin.

4. The Cultural Cycle

IT departments typically build what is requested. However, business stakeholders don’t ask for things they don’t know exist. If the business doesn’t know Graph-driven governance dashboards are possible, they won’t ask for them, and IT won’t build them. This cycle reinforces an environment run on assumptions rather than data.

5. Real Operational Friction

We must acknowledge that Graph isn’t always frictionless. Issues like inconsistent throttling limits, lagging documentation, and unannounced breaking changes are real engineering challenges. However, the organizations hitting these limits are the ones extracting the most value. Friction is often a sign of scale and maturity.

Turning Behavioral Data into Organizational Intelligence

For executives and decision-makers, the true value of Graph lies in behavioral data. Configuration data tells you how a system is set up; behavioral data tells you how your organization actually functions. Graph is the only place where you can query organizational behavior at scale.

Consider the insights available through the 90% of Graph that often goes untouched:

• Adoption: Who is using which services, and at what depth?

• Security: Aggregated alerts across Defender, Entra ID, and Intune in one normalized data plane.

• Identity Governance: Fully automated “joiner-mover-leaver” processes.

• Hidden Endpoints: Data from Planner, Search, Places, and Viva Insights that reveal how work actually happens.

A prime example is the company Structural, which doubled its growth by leveraging Graph within Teams. They didn’t just add features; they understood the logic layer of their collaboration environment and used it to make better decisions about how work was being performed. This is the shift from “How do we do this faster?” to “What does Graph make possible that we haven’t considered?”

Mastering the Reporting APIs

The Reporting APIs are often the first place organizations look for value. However, most people mistake the Admin Center’s bar charts for the full story. The Graph Reporting APIs provide programmatic access to raw behavioral signals across Exchange, Teams, SharePoint, and OneDrive.

Signals vs. KPIs

It is critical to understand that Reporting APIs give you signals, not KPIs. There is no endpoint that tells you “Adoption is up 10%.” Instead, you get raw data, emails read, meetings organized, or files shared. The business meaning must be defined by you.

To get the most out of this data, you must ask the right questions:

• Active users is a volume signal, but active users relative to licensed users is a value ratio.

• Meeting hours per week tracked against productivity reports can serve as a burnout signal.

• File sharing activity compared across departments can highlight training gaps or security risks.

The Reality of Latency

When designing dashboards, keep in mind that reporting data typically lags by 24 to 72 hours. These APIs are built for trend analysis, not live operational monitoring. Successful organizations design their systems around rolling 30-day averages and week-over-week trend lines rather than real-time counters.

Key Takeaways for IT Leaders

• Stop viewing Graph as a phone book: It is a strategic asset and the control plane for your entire Microsoft 365 estate.

• Bridge the Discovery Gap: Encourage your team to look beyond Users and Groups. Explore the reporting, security, and governance endpoints.

• Define Meaningful Metrics: Don’t just report raw numbers. Combine Graph signals to create insights that matter to business stakeholders, such as adoption depth and engagement ratios.

• Accept Engineering Friction: Throttling and documentation gaps are operational hurdles, not reasons to stay shallow. The value on the other side of that friction is immense.

• Automate Governance: Use identity governance and audit log endpoints to move from manual oversight to automated, data-driven guardrails.

Conclusion

Microsoft Graph is much more than a set of endpoints for developers; it is the fundamental logic layer of the modern workplace. By moving past the “Users and Groups” mentality, you can unlock a wealth of organizational intelligence that drives better governance, tighter security, and more informed business decisions. The data is already there, sitting in your environment, waiting to be queried. The only question is: Are you ready to stop using Graph wrong and start using it as the strategic foundation it was meant to be?

The landscape of the modern workplace is shifting at a breakneck pace. From the early days of physical mail servers to the current era of generative AI, the way we collaborate has undergone a radical transformation. For IT leaders, navigating this evolution requires more than just technical savvy, it requires a strategic understanding of how hardware, software, and human expertise intersect to create a seamless user experience. In a recent episode of the M365 FM podcast, Josh Blalock, a Microsoft MVP and expert in Microsoft 365 Copilot and Teams technology, shared his insights on this journey and what the future holds for AI-powered workplaces.

The Evolution of Unified Communications: From On-Prem to the Cloud

Josh Blalock’s journey in the Microsoft ecosystem began over two decades ago in the United States Air Force, where he was tasked with managing Exchange 55 servers. At the time, IT was a world of physical hardware and server rooms. As technology progressed through OCS 2007R2, Lync Server 2013, and Skype for Business, the focus shifted toward Unified Communications (UC), bringing chat, voice, and video into a single, cohesive environment.

For many IT leaders who remember the “on-prem” days, there is a certain nostalgia for the hands-on nature of the work. Josh notes that while the cloud offers incredible scalability and ease of use, it has changed the role of the engineer. “I can’t walk into a server room anymore and hit reset on that server,” Josh explains. This shift from physical maintenance to cloud management means that IT leaders must now focus more on the service experience and the integration of components rather than just keeping the hardware running.

The Path to Becoming a Microsoft MVP: Community and Passion

One of the most valuable assets for any IT professional is the community. Josh’s transition from a generalist to a specialized Microsoft MVP was driven by a desire to share knowledge. He emphasizes that being an MVP is not just about technical expertise; it is about being an evangelist and a community leader. For those looking to elevate their careers or their organization’s profile, Josh offers several key takeaways:

• Find Your Medium: Whether it is blogging, podcasting, or video creation, find a way to share information that aligns with your passions.

• Consistency is Key: Building an audience and a reputation in the Microsoft community takes years of effort and skill-honing.

• Focus on Influence: The goal is to influence and help others navigate complex technologies like Microsoft Teams and Copilot.

Josh famously adopted a cowboy hat as his personal brand during his early video days, a move that made him memorable and unique in a crowded field. This highlights an important lesson for IT leaders: authenticity and unique perspectives are vital when leading digital transformation initiatives.

Why Hardware is More Important Than Ever in the Age of AI

As organizations invest heavily in Microsoft 365 Copilot, there is a growing realization that software is only as good as the data it receives. In the context of AI-powered meetings, this means audio and video quality are paramount. If Copilot is going to accurately summarize a meeting, provide sentiment analysis, or assign action items, it needs a clean, high-quality audio feed.

This is where hardware becomes the “unsung hero” of the AI story. Josh discusses his work with Shure, a company long known for its legendary status in the music and podcasting world (specifically the SM7B microphone). However, Shure has made a significant play in the Microsoft Teams Rooms (MTR) space, recognizing that professional-grade audio is the foundation of a successful AI implementation.

The Role of Shure in the Microsoft Ecosystem

Shure’s expansion into the corporate world includes specialized tools designed to enhance the meeting experience:

• Intellimix Room Kits: Software-based signal processing that ensures clear audio in any environment.

• Ceiling Microphones: Discreeet hardware that captures every voice in a room, regardless of where the speaker is standing.

• The Intellimix Bar Pro: An upcoming solution designed to bring high-end audio and video to diverse meeting spaces.

For IT leaders, the takeaway is clear: Don’t neglect the hardware. An investment in Copilot licenses may not reach its full potential if the physical meeting spaces are equipped with substandard microphones that frustrate the AI’s ability to “hear” and process information.

Introducing the Shure Ignition Program

To bridge the gap between hardware manufacturers and the Microsoft community, Shure has launched the Shure Ignition Program. Modeled after the Microsoft MVP program, this initiative brings together experts who are passionate about Microsoft Teams Rooms and high-quality audio solutions. These evangelists are tasked with telling the story of how hardware enhances the Copilot experience, ensuring that organizations realize the full value of their technology investments.

This program highlights a broader trend: the convergence of AV (Audio-Visual) and IT. IT leaders must now be well-versed in both worlds to ensure that the “AI-powered workplace” is more than just a buzzword, but a functional reality for their employees.

Key Actionable Insights for IT Leaders

Based on the evolution of Teams and the rise of Copilot, here are the steps IT leaders should take today:

1. Audit Your Audio: Before rolling out Copilot to the entire organization, test your meeting room hardware. Ensure that the audio quality is sufficient for AI transcription services.

2. Foster Internal Champions: Look for employees who are passionate about sharing knowledge. Encourage them to become internal “MVPs” who can lead the adoption of new tools.

3. Embrace the Hybrid Story: Recognize that the workplace is no longer just a physical office or a digital space, it is a blend of both. Your hardware strategy must reflect this.

4. Invest in Integration: Focus on solutions that work seamlessly with the Microsoft stack. Tools like Shure’s certified Teams devices reduce troubleshooting time and improve user satisfaction.

Conclusion: The Future of the AI-Powered Workplace

The journey from Exchange 55 to Microsoft 365 Copilot has been one of increasing abstraction and power. While we may no longer be resetting physical servers in a basement, the responsibility of the IT leader has never been greater. By focusing on the intersection of high-quality hardware, strategic software implementation, and community-driven knowledge sharing, organizations can create a workplace that is not only productive but truly inspiring.

As Josh Blalock’s experience shows, the key to success in this new era is passion and preparation. Whether you are choosing the right microphone for a boardroom or configuring Copilot for a global workforce, the goal remains the same: to empower people to do their best work, wherever they are.

In the rapidly evolving landscape of cybersecurity, a fundamental shift is occurring in how organizations protect their digital assets. For years, the industry has focused on a defensive posture, reacting to alerts, patching individual vulnerabilities, and managing endless dashboards. However, as modern threats become more sophisticated, the most successful security leaders are realizing that to truly protect an environment, they must stop thinking like a defender and start thinking like an attacker.

This mindset shift is at the heart of Microsoft Security Exposure Management. It is no longer enough to look at a list of vulnerabilities in isolation. Today’s attackers don’t see a map of severity scores; they see a map of opportunities. They look for the path of least resistance, chaining together minor misconfigurations and overlooked permissions to reach their ultimate goal: your critical data and Tier 0 assets.

The Attacker’s Lens: From Dashboards to Opportunities

Traditional security operations often find themselves buried under a mountain of data, hundreds of open tickets, severity maps, and constant alerts. While these metrics are important, they don’t always reflect the reality of a cyberattack. An attacker enters an environment with a simple goal: gather intelligence, steal credentials, and move through the network undetected.

As highlighted by Microsoft security experts, attackers do not view your environment through the lens of a dashboard. Instead, they look for interesting paths. They are interested in the fastest way to something valuable. While a security team might be busy fixing a high-severity vulnerability on an isolated server, an attacker might be exploiting a “low-risk” misconfiguration in a service account that provides a direct line to a Global Administrator account.

“The problem is that many organizations are still fixing vulnerabilities in isolation, while attackers actually try to chain them together,” notes the transcript. This is where the concept of exposure management becomes a game-changer for the modern Security Operations Center (SOC).

Exposure vs. Vulnerability: Understanding the Difference

One of the most critical distinctions in modern security is the difference between a vulnerability and an exposure. While they are related, they are not the same thing, and treating them as identical can lead to dangerous gaps in your defense.

• Vulnerability: An individual issue, often identified by a CVE (Common Vulnerabilities and Exposures) score, or a specific misconfiguration in a system.

• Exposure: The actual risk created when vulnerabilities, misconfigurations, and excessive permissions are combined. Exposure represents the attack path that a threat actor can actually exploit.

Microsoft Security Exposure Management focuses on proactive risk reduction rather than reactive incident response. By identifying how these issues connect, organizations can prioritize the “breaks” in the attack path that truly matter, effectively shutting down the routes an attacker would take before they ever start their journey.

The Power of the Exposure Graph

To think like an attacker, you need to see the connections between your assets. This is achieved through an Exposure Graph. This tool allows security teams to identify security dependency maps, showing exactly how a weakness in one area, such as an endpoint or an identity, can lead to a compromise in another, such as a cloud application or a database.

By using an exposure graph, you can answer the most important question in security: “What is the fastest path to Domain Admin or Global Admin for my critical assets?”

Prioritizing Tier 0 Assets

Not all assets are created equal. Exposure management allows analysts to reason faster by focusing on the Tier 0 assets, the keys to the kingdom. Instead of trying to fix every single vulnerability, the goal is to identify and protect the critical resources that would cause the most damage if compromised. This shift from “fixing everything” to “fixing what an attacker will exploit first” is the hallmark of a risk-driven, modern SOC.

Real-World Scenarios: Chaining the Path

Consider a practical scenario: A service account has a minor misconfiguration, a specific device has a known vulnerability, and a user has slightly excessive permissions. Individually, none of these might trigger a “critical” alarm in a traditional system. However, when chained together, they create a clear path for an attacker to escalate privileges and exfiltrate sensitive data.

Microsoft Security Exposure Management identifies these chains. It looks across identities, endpoints, cloud environments, and applications to surface these hidden risks. This allows teams to move away from the “noise” of 24-hour alerting and toward a more strategic, automated approach to security.

The Rising Challenge of AI and “Dark Data”

As organizations integrate AI and machine learning into their workflows, the attack surface expands even further. We are now facing the challenge of “Dark Data”, data in the cloud that exists without proper oversight or control. The transcript emphasizes that before you can protect your data, you must know what it is, where it is, and how it flows through your organization.

AI Agents as First-Class Identities

With the rise of AI agents, such as those found in Security Copilot, these tools must be treated as first-class identities. If an AI agent is not properly governed, it can become a subject of privilege elevation. Organizations must enforce strict conditional access policies and monitor for anomalies in how these agents interact with sensitive data. Without governance, relying on external AI tools becomes a significant risk, as your data could effectively fall under policies outside of your control.

New Frontiers in Cloud Attacks

The transcript identifies several emerging threats in the cloud and AI space that exposure management helps mitigate:

• Supply Chain Targeting: Attackers compromising widely used libraries or services to affect multiple organizations.

• AI Model Poisoning: Threatening data integrity by “poisoning” the data used to train machine learning models.

• Sophisticated Social Engineering: Using AI to generate convincing deepfakes or highly targeted fishing contexts.

• Credential Theft in the Cloud: Exploiting poorly configured storage buckets or IAM rules to gain unauthorized access.

Actionable Insights for a Proactive Defense

To successfully transition to an exposure management mindset, organizations should focus on the following actionable steps:

1. Map Your Attack Surface: Use both internal and external perspectives to discover known and unknown assets. Continuous monitoring is essential.

2. Identify Critical Paths: Don’t just look for vulnerabilities; look for the “fastest path” to your most sensitive data.

3. Implement Passwordless Authentication: Use strong multi-factor authentication (MFA) and phishing-resistant mechanisms to close the door on credential stuffing and brute force attacks.

4. Govern Your AI: Ensure AI agents are monitored and governed by the same strict policies as human identities.

5. Shift from Reactive to Proactive: Move your SOC’s focus from responding to alerts after an attack to reducing risk before an attack can occur.

Conclusion: The Future of the Modern SOC

The future of cybersecurity belongs to those who can anticipate the attacker’s next move. By adopting Microsoft Security Exposure Management, organizations can move beyond the exhaustion of alert-driven operations and toward a sophisticated, risk-driven strategy. It is about more than just tools; it is about a philosophical shift in how we view security.

When we stop thinking like defenders and start analyzing our environments through the eyes of an attacker, we gain the clarity needed to break the attack paths that matter most. This proactive approach not only protects our data and our reputation but also empowers our security teams to work with confidence and precision in an increasingly complex digital world.

For many organizations, the current approach to AI agents is fragile. Companies often deploy agents without a clear strategy, leading to redundant tools, lack of oversight, and “hallucinating” assistants that lack domain context. To move past these hurdles, we must look beyond product names and focus on the architectural reality of how agents function. By understanding the infrastructure layer, the part you cannot see in a demo, businesses can transition from experimental projects to robust, operational AI ecosystems.

The Four-Layer Model for Enterprise AI

The primary reason most AI deployments hit a wall is a lack of a mental model. Organizations often choose products based on headlines rather than strategic fit. To solve this, we must stop viewing agents as isolated products and start seeing them as a system comprised of four distinct layers.

1. The Experience Layer

This is the surface where humans interact with AI. It includes tools like Microsoft Scout, GitHub Copilot, and the agents embedded directly into Word or Excel. This layer also encompasses computer-using agents that navigate interfaces just as a person would. While most companies start and stop here, focusing only on discovery makes the setup fragile.

2. The Agent Layer

The agent layer is where specific intelligence lives. These are not generic assistants; they are specialists built for one job. For example, Security Copilot features agents specifically for threat intelligence, while Dynamics 365 hosts agents for sales intent. An agent without domain-specific context is merely a chatbot prone to errors. The challenge at this layer is managing multiple specialists without losing control over what they can access.

3. The Runtime Layer

The runtime is where agents execute their logic, maintain state, and call other tools. Foundry Agent Service serves as the platform for this layer, managing the heavy lifting of scaling and networking. This is also where memory lives, procedural memory for how to perform tasks and user memory for persisting preferences. In this layer, a coordinator agent can delegate tasks to specialists, turning AI into a cohesive workforce.

4. The Governance Layer

Often the missing piece in AI strategy, the governance layer covers identity, policy, and audits. Agent 365 acts as the governance plane, ensuring every agent is treated as a first-class citizen with its own unique identity. This allows for least privilege access and full auditability, moving agents from “invisible features” to governed infrastructure.

Build 2026: When Agents Became Infrastructure

While the headlines focused on voice agents and redesigns, the real milestone of Build 2026 was the General Availability (GA) of Agent 365 and Foundry Agent Service. For the first time, organizations have a governance plane and a runtime plane that communicate seamlessly. This convergence marks the moment AI agents stopped being experimental and became enterprise-grade infrastructure.

Before this shift, agents were essentially “bolted-on” capabilities. If an agent went rogue or accessed sensitive data, there was no clean way to audit or shut it down. Now, agents are identities. Every agent receives its own principal in Entra, meaning it is no longer a shared service account or a human user account mapped to a bot. You are no longer just using an agent; you are hiring one.

Agent 365 and the Power of Identity

By treating agents as first-class identities, Agent 365 changes the security landscape. Because every agent has its own directory identity, IT administrators can apply the same rigorous standards they use for human employees:

• Conditional Access Policies: Control exactly when and where an agent can operate.

• Access Reviews: Regularly audit the permissions granted to autonomous agents.

• Instant Revocation: If an agent’s behavior becomes problematic, its credentials can be revoked in an instant.

• Purview Audit Logs: Every action an agent takes is recorded, providing a clear trail of what was accessed and why.

This level of accountability is essential for scaling AI. It provides the transparency required to move past simple Q&A bots and into autonomous systems that handle sensitive business logic.

Foundry Agent Service: The Execution Engine

If Agent 365 is the “brain” for policy, Foundry Agent Service is the “engine” for execution. Managed by Microsoft, this platform handles the complexities of running agents in sandboxed sessions. Key features of this runtime layer include:

• Procedural Memory: Agents learn how to perform specific workflows across different sessions.

• User and Session Memory: Context is preserved, allowing for more natural and efficient interactions over time.

• Automatic Scaling: Developers define the logic, and the platform handles the infrastructure requirements to scale that logic across the enterprise.

Foundry transforms agents from static tools into dynamic operators that can coordinate with one another to solve complex problems.

The Experience Layer: From Reactive to Proactive

The shift in infrastructure is also changing how we experience AI. We are moving away from the “reactive” model, where a user types a prompt and waits for a response, toward a “proactive” model.

Microsoft Scout is the flagship for this new experience. As an always-on work agent, Scout doesn’t wait for a command. It monitors conversations in Teams, watches context in SharePoint, and surfaces relevant information before you even know you need it. Similarly, computer-using agents are breaking down barriers with legacy systems. By “seeing” the UI and clicking through applications like a human, these agents can automate workflows in systems that lack modern API integrations.

Key Takeaways for AI Strategy

To successfully navigate this new era of enterprise AI, organizations should consider the following actionable insights:

• Shift from Product to Architecture: Stop asking which agent product to buy and start asking how your agent architecture handles identity, runtime, and governance.

• Implement “Least Privilege” for AI: Use Agent 365 to give every agent a unique identity and limit its access to only the data it needs to perform its specific role.

• Focus on Domain Specificity: Avoid generic chatbots. Build or deploy agents at the Agent Layer that are grounded in your specific business context to reduce hallucinations.

• Prepare for Proactive Workflows: Evaluate how always-on agents like Microsoft Scout can fit into your existing workflows to move from a Q&A model to an automated operations model.

Conclusion

The evolution of AI at Build 2026 represents a turning point for the modern enterprise. We have moved beyond the novelty of generative AI and entered the era of operational AI infrastructure. By leveraging the four-layer model and the combined power of Agent 365 and Foundry, businesses can finally build agents that are not only intelligent but also secure, scalable, and fully integrated into the fabric of the organization.

This is an inspiring moment for leaders and developers alike. The tools are no longer experimental; they are production-ready. The future of work isn’t just about having an assistant to help you write an email, it’s about having a governed, reliable system of agents that operate alongside you to drive the business forward.

Every developer has experienced that sinking feeling when they open a legacy enterprise codebase. You’re asked to make a simple change, maybe swap a data provider or add a new notification type, and the lead dev tells you, “We can’t just change that; we’d have to rewrite half the system.”

That is the sound of a system that wasn’t built for longevity. It’s a system where architecture was treated as an afterthought or, worse, confused with “clean code.”

Recently, I sat down with Miguel Castro, a senior engineer and software architect who has been in the Microsoft ecosystem since the days of the Radio Shack TRS-80 and VB1. With decades of experience building everything from cloud SDKs to AI-powered transcription systems, Miguel has seen paradigms come and go. His core thesis for building systems that actually last? Extensibility first.

The Evolution of the.NET Landscape: From Top-to-Bottom to AI

Software development isn’t what it used to be in 1986. Miguel recalls a time when modularity didn’t even exist, programming was a “top-to-bottom” affair. The introduction of functions and subroutines was a radical shift, followed by the drag-and-drop GUI revolution of Visual Basic. Today, we face a new, faceless competitor: AI agents.

While the tools have changed, the fundamental struggle remains the same. Developers often get caught up in the “newness” of technology, whether it’s microservices or AI-powered coding, and forget that the goal of enterprise software is to survive the business. If you aren’t designing for the inevitable changes in business requirements, your system is already obsolete before the first deployment.

Architecture vs. Clean Code: A Controversial Distinction

There is a massive misconception in the.NET community that “clean code” is the same as “good architecture.” It isn’t. In fact, focusing on clean code before you have a solid system design is a recipe for disaster.

“One writes on top of the other,” Miguel explains. “I don’t think you can write clean code without designing a good system first.”

Think about it: “Clean code” is often subjective. What I think is clean, you might think is cluttered. It’s about style, naming conventions, and readability. But architecture? Architecture is objective. It’s about how components connect, how layers interact, and how the system is decomposed into manageable parts.

If you jump straight into coding without a structural design, your code cannot be clean. You will inevitably find yourself writing “spaghetti” logic because the system lacks the proper boundaries to hold clean code. You have to crawl before you can walk, do your design and architecture first, and the clean code will follow naturally.

The “Able” Words of Software

For Miguel, a great architecture is defined by the “able” words:

• Extensible: Can I add a new feature without breaking the old ones?

• Maintainable: Can I fix a bug without a week of regression testing?

• Readable: Can a new dev understand the flow without a 50-page manual?

If your system is extensible, these other qualities tend to fall into place. Extensibility is the foundation upon which long-lasting.NET systems are built.

The Red Flag: Why Enterprise Projects Become Unmaintainable

Why do so many enterprise applications become impossible to maintain? It usually boils down to a single failure: They are not designed to allow enhancement or modification.

When Miguel joins an existing project, he looks for specific warning signals. The biggest one? The “Rewrite” Response. If you ask, “What do I have to do to change this one small part?” and the answer is “We’d have to rewrite all of that,” the architecture is in trouble.

A well-architected system should be modular enough that you can swap out a piece of logic, a “plugin”, without the rest of the house of cards falling down. When a system is rigid, every change feels like a “pain in the ass,” and that’s when developers start cursing the original architect.

Extensibility First: Designing for the Unknown

You might be thinking, “But I can’t predict the future! How can I architect for requirements I don’t have yet?”

This is where the concept of Extensibility First comes in. It’s not about over-architecting or trying to build a “god-system” that does everything. It’s about building the hooks.

Agile Architecture

Architecture doesn’t have to be finished 100% before you start coding. In fact, it shouldn’t be. Miguel advocates for an agile approach to design:

1. Define the Core Connections: Figure out how your major components will talk to each other.

2. Build the Plugin Points: Identify the areas most likely to change (data storage, external APIs, UI logic) and create interfaces for them.

3. Evolve as You Code: As you write components, revisit the architecture. If a component feels “messy,” it’s usually a sign that your architecture needs to be adjusted to accommodate it.

By focusing on how things are connected and how they can be plugged in later, you create a system that can evolve alongside the business. You aren’t predicting the future; you are simply making sure you haven’t locked the doors to it.

Key Takeaways for.NET Architects

• Design before you code: You cannot “clean code” your way out of a bad system design. Decomposition and layering are your best friends.

• Identify your “Rewrite” triggers: If a small change requires a massive overhaul, your architecture lacks extensibility.

• Embrace modularity: Use plugins and clear interfaces to separate concerns. This makes your system readable and maintainable.

• Don’t over-architect, but do architect: You don’t need a perfect plan, but you do need a foundational structure for how components will interact.

• Architecture is an iterative process: Just like your code, your system design should be revisited and refined as the project grows.

Conclusion

In the fast-paced world of.NET development, it’s easy to get distracted by the latest library or the promise of AI-generated code. But as Miguel Castro’s decades of experience show, the “secret” to long-lasting systems isn’t a specific tool, it’s an extensibility-first mindset.

Stop worrying so much about whether your variable names follow a specific style guide and start worrying about whether your system can survive a change in business logic. Build the hooks, define the boundaries, and treat your architecture as a living, evolving entity. That is how you build software that doesn’t just work today, but continues to power businesses for years to come.

For over two decades, the enterprise software industry has operated under a single, unwavering assumption: humans need graphical user interfaces (GUIs) to navigate complexity. We built buttons, forms, dashboards, and navigation trees because the human brain requires visual representation to reason about data at scale. This architecture was not just a design choice; it was a necessity for human-computer interaction.

That assumption is currently collapsing. We are entering the era of Computer Using Agents (CUA), and they do not need dashboards. They do not need search filters, workflow builders, or “intuitive” navigation menus. They require logic, context, and stable APIs. As these agents begin to replace human workflows, the traditional SaaS valuation model is being compressed, and the industry is facing a structural shift that threatens to evaporate $300 billion in equity value.

The UI Was Always a Workaround

To understand why the user interface is dying, we must first recognize what it actually is: a workaround. In the early days of computing, we used command lines and punch cards. The cognitive load was immense because humans had to speak the machine’s language. The arrival of the GUI, the desktop, the window, the mouse, was revolutionary because it compressed the gap between human intent and machine execution.

However, every SaaS product built since then has followed the same three-tier architecture: Database + Business Logic + UI Layer. This cycle, where humans click, machines respond, and humans interpret the results, is now the primary constraint. It introduces latency, errors, and unnecessary costs.

An agent does not operate within this translation loop. It reads data directly, understands structures without visual aids, and operates on logic rather than layout. The dashboards and admin panels we spent decades perfecting are essentially scaffolding designed for the human user. The moment you remove the human constraint, that scaffolding becomes dead weight that slows the system down.

The Death of the Seat-Based Pricing Model

The most immediate threat to the software industry is not technical; it is economic. For 20 years, SaaS revenue has been tied to headcount. The formula was simple: Number of Seats × Monthly Fee = Recurring Revenue. This model worked because headcount growth was a proxy for business expansion.

Agentic workflows break this math entirely. Consider these implications:

• Seat Displacement: In modern pilot programs, a single agent handling invoice reconciliation can process the workload of five human employees.

• Revenue Collapse: If a customer no longer needs five licenses but instead needs only one person to oversee the agent, the vendor’s revenue from that account drops by 80%.

• The Cannibalization Dilemma: If SaaS vendors do not adopt agents, they lose to competitors who do. If they do adopt agents, they cannibalize their own seat-based revenue.

The market is already reacting to this structural incompatibility. SaaS valuation multiples have compressed from 12x revenue to 4x revenue across the board. Investors are repricing the entire category because the link between headcount and software value has been severed.

Why CUA is Friction Masquerading as a Solution

Currently, many are looking toward “Computer Using Agents” that can read a screen and click buttons like a human. While powerful for legacy systems, this is another stopgap. Statistics show that while CUA succeeds on simple UI tasks approximately 67% to 85% of the time, that success rate plummets to 9% to 19% on complex, multi-step workflows.

This failure rate isn’t due to a lack of intelligence in the agent; it’s because the agent is forced to infer intent from visual design rather than operating on explicit logic. For an agent, “usability” does not mean a pretty interface; it means:

• Stable and predictable APIs: Machines need consistent schemas, not changing layouts.

• Explicit logic: Clear boundaries on what the agent is allowed and forbidden to do.

• Machine-readable context: Understanding a JSON object’s meaning without needing a visual legend or chart.

Key Takeaways for the Next Decade of Software

1. Shift from UI to API-First: Business logic must be exposed as callable services, not hidden behind a proprietary UI or workflow builder.

2. New Pricing Architectures: Vendors must move away from headcount-based pricing and toward consumption-based or outcome-based models.

3. Operational Infrastructure: To survive, companies need metering systems and billing engines that can handle variable charges based on work completed rather than seats occupied.

4. Context is King: Agents require more than just data access; they need the organizational “rules of the road”, such as specific regional approval chains or budget constraints, to execute tasks autonomously.

The Move Toward Logic and Context

Mid-market SaaS companies are currently at the highest risk. Unlike enterprise giants, they often lack the cash flow to survive a total repricing of their business model. The vendors who will win the next decade are those scrambling toward hybrid models that blend seat-based fees with usage-based value.

An agent processing an expense report doesn’t just need to know if an amount is under a certain threshold; it needs to understand the context of the request, the region, the department, and the specific budgetary constraints. This level of integration requires a fundamental rebuilding of how software is constructed.

Conclusion

We are witnessing the end of the “Human-Driven UI” era. Software is no longer just a tool for humans to use; it is becoming an environment where agents execute complex logic autonomously. This shift is exposing the fragility of the seat-based pricing model and forcing a massive repricing of the SaaS industry.

The transition from visual interfaces to agentic architectures will be difficult, and for many legacy vendors, it may lead to extinction. However, for those who can move beyond the “workaround” of the GUI and embrace API-first, logic-driven systems, the opportunity to capture value based on actual work performed, rather than just the number of people logged in, is the new frontier of the digital economy.

Read more

Most organizations believe they are at the forefront of the AI revolution. They have invested millions in Copilot, connected their document folders, and encouraged their teams to ask questions. However, a hard truth is emerging: most have not built a transformative AI strategy. Instead, they have simply built search interfaces that talk back.

Read more

For many organizations, the quest for the perfect project management tool feels like an endless cycle of trial and error. On one end of the spectrum, you have high-end, expensive Enterprise Project and Portfolio Management (PPM) platforms that require months of training and a significant financial investment. On the other end, you have simple task lists…

Read more

The enterprise has built its entire intelligence layer on one simple, dangerous assumption: that artificial intelligence is bounded, reversible, and auditable through the same binary lenses we have used for decades. We assume that because we feed it data, we can trace its reasoning and understand exactly how it arrived at a conclusion. This assumption i…

Read more

The assumption behind Infrastructure as Code (IaC) is simple: it makes you faster, removes the guesswork, and eliminates configuration drift. We adopt it because the alternative, clicking around in the Azure portal, manually documenting changes, and hoping someone remembers why a resource was configured a certain way, is untenable at scale. However, whe…

Read more