Observability strategy is a tricky concept. Everyone wants to talk about it, but nobody can agree on how they’re talking about it. Consequently, we end up talking past each other without even realizing it.

I like to think of this as a multifaceted spectrum, built up of trade-offs; You pick somewhere on a spectrum in a few different areas, and then you figure out how to optimize the trade-offs, and slowly your strategy emerges from there.

That works up to a point, but then you’ll hit a strategy cliff, usually around three years of implementation (or ~250 engineers). That strategy cliff is when having a single strategy breaks down and stops being sufficient.

It turns out that while you can split up a company into pre-product market fit (pre-PMF), small-to-medium business (SMB) and enterprise, you’re probably going to have all three of these paradigms existing in your company at the same time, regardless of company size. That can be quite confusing to work with.

But rather than splitting up into a million separate strategies, building a meta-strategy around observability can make this much easier to deal with. Let’s walk through how that can happen and what that looks like.

Strategy? What Strategy?

Smaller companies tend to not have an observability strategy, and larger companies tend to want to improve their existing one. That would be one of the spectrums I mentioned earlier.

I find this a lot easier to explain in story form, which is why user journeys are so valuable to me. So let’s talk about a few company personas that we’ll sketch out briefly.

The Pre-PMF Seed Startup

Picture this: You’ve raised a seed round. You have 12 months of runway. You have plans about what users need. You also have plans about your plans. You might even think you know who your users could be. Better yet, you’ve even built something.

Now what? Well … are users using it? Do they like it? Sure, you can email all of them, but there’s a difference between what they say and how they behave, and you’re going to need the right data to see user behavior. Your observability is probably going to look a lot more like user tracking and marketing funnel analysis than it is “hyper-optimize this endpoint to be 2% more efficient.”

And you know what? That’s fine! User journeys are super valuable here, but in a weird way: You don’t know the user journey, and you want to find it out. Typically, you’re only measuring them if you have a good idea of what they are, but pre-PMF? It could be anything.

If you’re thinking that this sounds like an “unknown unknown”, you know, the type of thing observability is supposed to be amazing at approaching, you’re not wrong.

Translating that into the business impact, what really matters is whether you can figure out what that product market fit is, and how it relates to your users and your revenue streams. Rather than observability being an afterthought, leaning into it and integrating it with your user journeys can be the difference between thinking you have product-market fit and being able to observe when you hit product-market fit.

Observability Check for My SMB Era

You found product-market fit. Revenue is growing. You have actual customers who will be angry if things break. Suddenly, you have problems you didn’t have six months ago. Congratulations! Condolences! Everything in between!

This is the pain zone for observability: Your main goal is to keep things from falling over. Everything is going to change every six months, and nothing is going to make sense. You’re going to be building systems faster than you can keep track of them, and you’re going to be duct taping stuff together so much that your eyes will glaze over.

Those user journeys of yours are going to start landing in an uncomfortable middle; you’re still not quite sure about them, but a lot of load-bearing revenue now lies on the personas you’ve built out. Unfortunately, the assurances you get with enterprise scale, enterprise purchase plans, tooling integration and conveniences of large companies with unlimited budgets are still going to seem so far away.

You still want to do more with less, and you want to focus on tool consolidation, but you’re in the uncomfortable spot of simultaneously knowing you have to spend money to make money and saying, “Haha, but what money, right?” Likewise, with your users, you definitely have them, but the confidence you have in how those user demographics have been split is probably going to feel like it varies from day to day.

If only you had a magic wand that you could wave, which would let you know which efforts to focus on. If only you could know those user journeys were driving revenue. If only you had a way to divine the levers of impact that let you maximize operational return on investment (ROI). If only you had … observability. But wait, not that observability. This observability looks way different than the observability you implemented two years ago.

Well, observability actually doesn’t look that different than it does now, does it?

You’re not exactly losing any of the capabilities you needed pre-PMF; you just have more things to care about and different trade-offs to make. Which means that your observability strategy can grow seamlessly from pre-PMF to the SMB era, assuming, of course, that you focused on transferrable skills and technology choices rather than punting operational knowledge until later.

So, even as you’ll likely focus less on adding new user journey experiments, because discovery is less important, they’re still going to be an essential part of your observability strategy. Reliability and cost efforts need similar things and pair well with user journeys, especially if you can correlate that data together.

The O11y-Ship Enterprise

Congratulations! You’ve made it: You can officially say “at our scale” whenever a vendor starts hitting you up. It’s guaranteed to make your colleagues roll their eyes, and you’ll elicit a nervous chuckle from the vendor. Are you running a tool? Pffh, you’re running every tool, and many of them more than once. Your vendor might know more about how your company uses the tool than you do, and you’re the people that bought it in the first place. Those user journeys? Set in stone, baked, ossified; Entire departments exist because those user demographics are the shape they are. You could set your clock on the ability to detect user behavior that you’ve painstakingly curated.

Something interesting happens in this environment. Money changes shape. Rather than trying to reduce cost to an absolute minimum on a case-by-case basis, you start becoming very willing to spend large amounts of money to buy systemic improvements.

And when you’re in that stage, it does mean that tooling integration and catering to people outside the expert domain of tool usage become incredibly important. In addition, your faith in those user journeys and personas have grown to the point where you’re likely to dismiss most contrary experiences and user reports as outliers rather than as signals that your market research was flawed.

After all, in a startup, you can assume that anyone using a tool is probably interested in using that tool — you often don’t have a lot of pressure forcing you to use tools against your will in smaller companies. As for users, you can probably assume you don’t know them, or even if you do… The rule of startups is that “the only constant is change.”

Enterprises, on the other hand, experience mandatory tool consumption on a daily basis. As evidence of this, look no further than that ticketing system that has 37 mandatory fields to create the zillions of reporting charts for management needs. They also have a stickiness of users and a predictability of user behavior that makes it possible to build a foundational enterprise on top of that data. It’s not just a moat; it’s the life of the business.

Projects like Weaver for OpenTelemetry become super important, whereas you’ll likely not care about them as much in smaller companies. Internal platforms, marketplace offerings and other consumption models of observability start making sense as well.

User journeys go from a discovery mechanism, to a profit mechanism, to a basic essential of life. The same goes for blueprints: They sound silly until you need to get tens of thousands of engineers to wrap their heads around a thing they don’t really care a whole lot about. All of the sudden, they become astonishingly necessary.

Observability as a Meta-Strategy

Now, looking at these three sorts of company shapes, one thing that you’ll readily notice is that the main thing they have in common is that they don’t seem to have anything in common. Even if user journeys or observability or “understanding the unknown unknowns” feels constant, the reasons and motivations behind that are going to change. So you might be wondering to yourself how exactly you’re supposed to do this magical meta-strategy thing and solve all your observability problems with one strategy.

Rather than treating strategy as a static document, or treating it as a living one, have a strategy around your strategy and build that into observability. I like to think about the S-curve of technology adoption. Imagine an observability initiative, like “use OpenTelemetry” for example (another example could be “implement user journeys“, whatever that means for you). Every stage of the initiative will start slowly and have an exploration phase before it starts to click. Then it will start to get traction and accelerate through a growth phase as it starts to take hold. Finally, it plateaus as the initiative hits saturation in the company.

Now, imagine that every single observability initiative in your company has its own S-curve. Adding user journey tracking? That’s a curve. Implementing sampling? Another curve. Migrating to OpenTelemetry? Yet another curve. And these curves overlap, intersect and sometimes contradict each other.

Which means that any company is going to find itself with dozens of these S-curves, all overlapping, and you’ll drive yourself up the wall trying to figure out how to build a meta-strategy that handles all these different combinations of strategies to understand where your company is and what you should do.

So instead, I like to think of transitions between strategies. Focus on identifying what stage of a strategy you’re at and build your strategy around understanding how to transition from one stage to another. For example, how do we transition an initiative (or product) from pre-market fit to market fit? How do we transition from SMB to enterprise? Or how do we transition a project from “Oh, I need to use OpenTelemetry” to “Now we’re ready to implement user journeys.” Is that the order you go in? Do you do it in a different order? Why?

If you think of the strategy as understanding inflection points rather than mapping out the combinations, you’ll help prevent yourself from running into the trap of needing to write dozens of strategies to cover every random combination of scenarios. This becomes particularly important when you realize that you’re going to end up with dozens, if not hundreds, of these S-curves all interlapping together.

It’s going to be impossible to predict when you’ll run into certain combinations of strategy inputs, so rather than predicting the future, adapt to the present. After all, building that operational adaptability is one of the strong points of observability. Your ability to do this in your strategy is part of an indication that you are maturing in your observability practice.

Strategy Is Embracing the Tangled Layers

There’s a huge temptation to think of taking a complex domain and attempting to simplify it by removing the complexity. The problem is that true complexity cannot be removed; it can only be handled. That complexity can only be grappled with by reframing your mindset.

But to make matters worse, reframing your mindset only works in that new stage of complexity handling: Once you’ve learned how to handle an SMB, for example, you can’t magically use SMB strategies on your new pre-PMF product line.

So, while you’re going to end up with a series of successive mental model shifts in the company throughout different periods of time and throughout different maturity areas of your various products, each one is going to apply only in that one domain; there’s no universal strategy.

Over time, they’ll proliferate, and you’ll end up having quite the tangled layer of strategies. Embracing the tangled layers, rather than trying to enforce a uniform strategy that can’t exist, will give you the flexibility you need to adapt observability successfully in a world where software development is seemingly changing every few months.

The post Taking Your Observability Strategy to the Next Level appeared first on The New Stack.

I firmly believe that Git worktrees are one of the most underrated features of Git. I ignored them for years because I didn’t understand them or how to adapt them to my workflow.

But that changed as I began using LLM coding tools to do more work in parallel. Being able to work on multiple branches simultaneously is a game changer.

Without git worktrees, working on multiple branches at the same time in the same repository is a pain. There’s the serial approach where you stash your changes, context switch, and pray you didn’t break anything. Or worse, just commit half-finished work with “WIP” messages (looking at you, past me). Or you can have multiple clones of the same repository, but that’s a pain to manage and can take up a lot of disk space.

Git worktrees solve this. They let you have multiple branches checked out simultaneously in different directories that all share the same git database (aka the .git directory). For me, this means I can work on a feature in one terminal, review a PR in another, have Claude Code work on another feature in another terminal, and have all of them share the same git history.

But here’s the thing: creating worktrees manually is tedious. You need to remember where you put them, what to name them, and clean them up later. Also, by default the git worktree is created in the root of the repository unless you specify a different directory.

I wanted something simpler. I wanted something that would work across any repository. No setup, no configuration files, just sensible defaults.

Enter tree-me

I built tree-me, a minimal wrapper around git’s native worktree commands. It adds organizational convention while letting git handle all the complexity.

Instead of this:

# Create worktree manually
mkdir -p ~/worktrees/my-project
git worktree add ~/worktrees/my-project/fix-bug -b haacked/fix-bug main
cd ~/worktrees/my-project/fix-bug
# Now repeat for every repo...

You do this:

tree-me create haacked/fix-bug
# Creates: ~/dev/worktrees/my-project/haacked/fix-bug
# And automatically cds into it

How it works

tree-me uses git-like subcommands and follows conventions so you don’t have to think:

• Auto-detects repository name from your git remote
• Auto-detects default branch (checks for origin/HEAD, falls back to main)
• Organizes by repo: $WORKTREE_ROOT/<repo-name>/<branch-name>
• Delegates to git for all validation, errors, and edge cases
• PR support: Fetches GitHub PRs using git’s native PR refs (requires gh CLI)
• Auto-CD: Automatically changes to the worktree directory after creation
• Tab completion: Complete commands and branch names in bash/zsh

Commands:

tree-me create <branch> [base]        # Create new branch in worktree
tree-me checkout <branch>             # Checkout existing branch (alias: co)
tree-me pr <number|url>               # Checkout GitHub PR (uses gh CLI)
tree-me list                          # List all worktrees (alias: ls)
tree-me remove <branch>               # Remove a worktree (alias: rm)
tree-me prune                         # Prune stale worktree files
tree-me shellenv                      # Output shell function for auto-cd

Examples:

tree-me create haacked/fix-bug              # Create from main/master
tree-me create haacked/fix-bug develop      # Create from develop
tree-me co existing-feature                 # Checkout existing branch
tree-me pr 123                              # Checkout PR #123
tree-me pr https://github.com/org/repo/pull/456
tree-me ls                                  # Show all worktrees
tree-me rm haacked/fix-bug                  # Clean up (supports tab completion)

Conventions

tree-me is a minimal wrapper around git’s native commands. Works with any repo, any language, any setup. The only convention is where worktrees live and how they’re named.

Want worktrees in a different location? Set WORKTREE_ROOT. Need to branch from develop instead of main? Pass it as an argument: tree-me create my-feature develop. Conventions with escape hatches.

Setup

To enable auto-cd and tab completion, add this to your ~/.bashrc or ~/.zshrc:

source <(tree-me shellenv)

This makes tree-me create, tree-me checkout, and tree-me pr automatically cd into the worktree directory. It also enables tab completion for commands and branch names (try tree-me rm <TAB>).

View the full implementation at github.com/haacked/dotfiles/blob/main/bin/tree-me.

The PR workflow

Here’s where it shines. Someone asks you to review a PR while you’re deep in a feature:

tree-me pr 123                  # Fetches, checks out PR, and cds into it
# You're now in: ~/dev/worktrees/dotfiles/pr-123
# Review the code, test it, leave comments
# When done, switch back
tree-me co haacked/my-feature   # Checks out and cds back to your feature
# Back to your work, no stash needed

When you’re done reviewing:

tree-me rm pr-123               # Tab complete to see available branches

Gone. Clean. No accidentally committing review changes to your feature branch.

Installation

Download tree-me and put it somewhere in your PATH:

# Example: copy to ~/bin or ~/.local/bin
curl -o ~/bin/tree-me https://raw.githubusercontent.com/haacked/dotfiles/main/bin/tree-me
chmod +x ~/bin/tree-me

Then enable auto-cd and tab completion (see Setup section above).

That’s it. No dependencies beyond git, bash, and optionally the gh CLI for PR checkout.

Why I built this

I work on multiple repos daily—PostHog, my blog, various open source projects. I was tired of remembering project-specific worktree scripts and hunting for that worktree I created last week.

The philosophy: Don’t recreate what git does well. Add only the minimal convention needed.

Git already handles worktrees perfectly. I just needed organized paths, sensible defaults, and a consistent interface across all my projects.

Directory structure

Everything is organized predictably based on the repository name and branch name:

~/dev/worktrees/<repo-name>/<branch-name>

For example:

~/dev/worktrees/
├── dotfiles/
│   ├── haacked/vim-improvements/
│   ├── haacked/git-tools/
│   └── main/
├── posthog/
│   ├── haacked/feature-flags/
│   ├── pr-789-contributor/
│   └── main/
└── spelungit/
    └── haacked/performance/

One glance and you know where everything is.

What it doesn’t do

tree-me doesn’t copy environment files, install dependencies, or set up project-specific tools. That’s deliberate. Those concerns belong in your project’s setup scripts, not in a generic git tool.

Want to automate environment setup? Add a script to your repo that runs after checkout. Want to copy .env files? Put it in your project’s onboarding docs. tree-me just handles the git worktree ceremony.

Try it

If you work with multiple branches regularly, give worktrees a try. If you work with multiple repos, give tree-me a try. If you hate it, at least you learned about git worktrees (and that’s probably worth more than the script).

Find tree-me at github.com/haacked/dotfiles/blob/main/bin/tree-me. It’s MIT licensed—copy it, modify it, improve it.

Key Insights into Microsoft's AI Landscape

• Copilot Studio: Excels in rapid, low-code/no-code development of conversational AI for quick deployment and Microsoft 365 integration.
• Azure AI Foundry: Offers comprehensive, code-first AI lifecycle management for advanced customization, enterprise-grade solutions, and deep control over models and data.
• Synergistic Approach: The most effective strategy often involves using Copilot Studio as the user-facing interface and Azure AI Foundry as the robust backend engine for complex AI tasks.

In the rapidly evolving landscape of artificial intelligence, Microsoft provides two powerful yet distinct platforms for AI development: Copilot Studio and Azure AI Foundry. While both aim to empower organizations with AI capabilities, they cater to different needs and technical expertise levels. Understanding their individual strengths and, crucially, how they can be strategically combined, is paramount for building effective and scalable AI solutions. This guide delves into the specific scenarios where each platform shines and illustrates the immense benefits of a unified approach.

Copilot Studio: Rapid Conversational AI Development

Simplifying AI Agent Creation for Business Users and Quick Deployments

Copilot Studio is designed for speed and accessibility, making it an ideal choice for users who need to build conversational AI agents without extensive coding knowledge. It offers a low-code/no-code environment that empowers business users, analysts, and citizen developers to create, deploy, and manage AI-powered chatbots and virtual assistants with remarkable efficiency.

Copilot Studio is accessible from https://copilotstudio.microsoft.com and can be used through different licensing options.

Key Characteristics and Use Cases of Copilot Studio

Copilot Studio's appeal lies in its user-friendly interface and seamless integration with the Microsoft ecosystem:

• Low-code/No-code Development: Its visual canvas allows for intuitive design and deployment of agents, making AI accessible to a broader audience.
• Rapid Deployment: Ideal for scenarios requiring quick prototyping and deployment of conversational bots, often within hours or days.
• Microsoft 365 Integration: Tightly integrated with applications like Teams, Outlook, and SharePoint, it's perfect for enhancing productivity within the M365 environment. It can extend Microsoft 365 Copilot's capabilities to connect with external systems.
• Simple Workflows: Best suited for tasks such as IT helpdesk FAQs, HR policy queries, basic customer service, and routine automation.
• Limited Customization Needs: When pre-built templates and standard models are sufficient, Copilot Studio provides a straightforward path to implementation.

Examples of Copilot Studio in action include internal HR bots for answering common employee questions, customer service agents handling FAQs on websites, and bots automating routine tasks like generating reports or summarizing meetings. It prioritizes ease of use and quick time-to-value, making it a go-to for organizations seeking to rapidly implement conversational AI.

Azure AI Foundry: For Advanced AI Development

Comprehensive Control for Developers and Data Scientists

Azure AI Foundry, formerly known as Azure AI Studio, is a code-first, comprehensive platform built for developers and data scientists who demand granular control over the entire AI lifecycle. It provides a robust environment for building, deploying, managing, and monitoring complex, enterprise-grade AI applications.

The Azure AI Foundry Management Center is available from https://ai.azure.com. While there is no specific license cost for using Azure AI Foundry, note that the different underlying Azure services such as Azure OpenAI, Azure AI Search and the LLMs will incur consumption costs.

Key Characteristics and Use Cases of Azure AI Foundry

Azure AI Foundry is tailored for sophisticated AI projects requiring deep customization and robust governance:

• Code-first Environment: It caters to developers and data scientists proficient in languages like Python and tools such as PromptFlow, offering unparalleled control over models and data.
• Full AI Lifecycle Management: From model selection and grounding to prompt testing, deployment, evaluation, tracing, and monitoring, Azure AI Foundry covers every stage of AI development.
• Advanced Customization: Ideal for scenarios requiring specialized models, stronger reasoning capabilities, image analysis, and domain-specific AI solutions.
• Enterprise-Scale Solutions: Designed for production-ready applications that necessitate robust monitoring, tracing, compliance features, data security, and privacy.
• Data-Sensitive Operations: Provides granular control over how AI models handle sensitive internal data, ensuring compliance and security.

Use cases for Azure AI Foundry include developing sophisticated AI agents for cyber threat detection, legal document summarization, visual issue detection in IT support, and orchestrating multi-agent systems. It's the platform of choice for organizations needing to own and manage all aspects of their copilots, ensuring high levels of customization, security, and scalability.

Azure AI Foundry specializes in advanced AI capabilities like Retrieval-Augmented Generation (RAG), model benchmarking, and multi-modal integrations.

When to Use Both

Combining Accessibility with Power for Comprehensive Solutions

For many organizations, the most effective AI strategy isn't choosing between Copilot Studio and Azure AI Foundry, but rather leveraging their complementary strengths. This hybrid approach allows for the agility of low-code development while maintaining the control and power of a code-first platform.

Strategic Integration Models

The synergy between Copilot Studio and Azure AI Foundry can manifest in several powerful ways:

• Frontend/Backend Architecture: Copilot Studio can serve as the intuitive, user-facing conversational interface (the "front door"), while Azure AI Foundry acts as the powerful backend processing engine (the "engine room"). Copilot Studio captures user requests and routes complex queries or reasoning tasks to Azure AI Foundry for processing, leveraging its advanced models, knowledge bases, and enterprise controls.
• Progressive Complexity and Cost Optimization: Begin with Copilot Studio for rapid prototyping and simpler AI agents. As requirements evolve and solutions demand deeper customization, integration with sensitive data, or robust governance, migrate or integrate complex components with Azure AI Foundry. This also allows for cost optimization by handling lightweight tasks in Copilot Studio while scaling heavy inference in Azure AI Foundry.
• Leveraging Custom Models: Azure AI Foundry allows organizations to develop and deploy custom, specialized models. These models can then be directly integrated and consumed within Copilot Studio prompts, enabling low-code agents to leverage highly tailored and powerful AI capabilities.
• Multi-channel Deployment and Enterprise Governance: Deploy Copilot Studio agents across various channels like Teams, web, and mobile, providing a consistent user experience. Simultaneously, utilize Azure AI Foundry for compliance-controlled processing, robust monitoring, and centralized governance of AI assets.

This combined approach allows organizations to harness the benefits of both platforms: the speed and accessibility of Copilot Studio for conversational AI, and the depth of control, customization, and full lifecycle management offered by Azure AI Foundry for advanced, enterprise-grade applications.

Comparative Analysis

A Side-by-Side Look at Capabilities and Best-Fit Scenarios

To further clarify the distinction and complementary nature of these platforms, let's compare their core capabilities and ideal applications:

Getting Started with Building Custom Copilots

If you're exploring how to begin your journey with custom copilots, things should be starting to click. As someone deeply involved in learning experiences, I’ve seen firsthand that customers learn best by doing. So, to help you dive in, I recommend starting with these hands-on Microsoft Learn tutorials:

Copilot Studio:

• Create and deploy an agent - Learn how to build and deploy an agent using Copilot Studio. This tutorial walks you through adding knowledge, testing content updates in real-time, and deploying your agent to a test page: Link to tutorial.
• Building agents with generative AI - Discover how to create agents powered by generative AI. This module outlines key features and prerequisites to get you started: Link to tutorial.
• Create and publish agents - Explore how to design agents tailored to real business scenarios—ones that both customers and employees can interact with: Link to tutorial.

Azure AI Foundry:

• Build a basic chat app in Python - Set up your local dev environment with the Azure AI Foundry SDK, write prompts, run your app code, trace LLM calls, and perform basic evaluations: Link to tutorial.
• Use the chat playground - This QuickStart shows you how to deploy a chat model and experiment with it in the Azure AI Foundry portal’s playground: Link to tutorial.
• Azure AI Foundry documentation - Dive into the full documentation to learn how developers and organizations can rapidly build intelligent apps using prebuilt and customizable APIs and models: Link to tutorial.

Conclusion

Ultimately, the choice between Copilot Studio and Azure AI Foundry, or the decision to use both, hinges on the specific needs, technical capabilities, and strategic objectives of an organization. Copilot Studio offers an accessible entry point into AI, enabling rapid development of conversational agents for everyday business scenarios. Azure AI Foundry provides the deep control and comprehensive toolkit necessary for building complex, scalable, and highly customized AI solutions for the enterprise. The most forward-thinking approach for many organizations will be a hybrid one, leveraging Copilot Studio for agile, user-facing interactions and entrusting Azure AI Foundry with the heavy lifting of advanced AI model management and data processing. This synergistic model allows businesses to achieve both speed and scale, delivering powerful AI experiences while maintaining stringent control and compliance.

Protect it all with Microsoft Security 

Eliminate gaps and get the simplified, comprehensive protection, expertise, and AI-powered solutions you need to innovate and grow in a changing world. The Microsoft Security Community is your gateway to connect, learn, and collaborate with peers, experts, and product teams. Gain access to technical discussions, webinars, and help shape Microsoft’s security products. 

Get there fast 

• To stay up to date on upcoming opportunities and the latest Microsoft Security Community news, make sure to subscribe to our email list.
• Find the latest skilling content and on-demand videos – subscribe to the Microsoft Security Community YouTube channel.
• Catch the latest announcements and connect with us on LinkedIn – Microsoft Security Community and Microsoft Entra Community. 

Index
Community Calls: December 2025 | January 2026 | February 2026 

Upcoming Community Calls 

December 2025 

Dec. 2 | 9:00am | Microsoft Sentinel and Microsoft Defender XDR | Empowering the Modern SOC 

Microsoft is simplifying the SecOps experience and delivering innovation that will allow your team to scale in new ways. Join us for actionable learnings to help your team modernize your operations and enhance protection of your organization. 

Dec. 3 | 8:00am | Microsoft Defender for Identity | Identity Centric Protection in the Cloud Era 

Safeguarding identities is challenging, but Microsoft Defender for Identity offers enhanced visibility, security posture, and protection focused on identity. 

Dec. 4 | 8:00am | Microsoft Defender for Cloud | Unlocking New Capabilities in Defender for Storage 

Discover the latest Microsoft Defender for Storage updates! Explore public preview features: Cloud Storage Aggregated Events and Automated Malware Remediation for Malicious Blobs, with live demos and best practices. 

Dec. 4 | 8:00am | Security Copilot Skilling Series | Discussion of Ignite Announcements 

Get ready for an info-packed session highlighting the latest Security Copilot breakthroughs from Ignite! Discover how powerful agents and Copilot’s seamless integration with Intune, Entra, Purview, and Defender combine to deliver unbeatable, all-around protection. 

Dec. 4 | 9:00am | Microsoft Sentinel | What’s New in the Past 6 Months 

Learn what’s new in Microsoft Sentinel! See deeper Defender integration, evolving data lake capabilities for scalable security, plus demos and real-world use cases to help you stay ahead. 

Dec. 8 | 9:00am | Microsoft Security Store | Security, Simplified: A look inside the Security Store 

Welcome to Microsoft Security Store! During this session, you’ll learn all about this centralized destination where customers can discover, deploy, and manage trusted security solutions built to extend Microsoft’s security platforms like Defender, Sentinel, Entra, Purview, and Intune. 

Dec. 9 | 8:00am | Microsoft Defender XDR | A Deep Dive into Automated Attack Disruption  

Learn what’s new in Microsoft Sentinel! See deeper Defender integration, evolving data lake capabilities for scalable security, plus demos and real-world use cases to help you stay ahead. 

Dec. 9 | 9:00am | Microsoft Sentinel | Part 1: Stop Waiting, Start Onboarding: Get Sentinel Defender-Ready Today 

The Microsoft Sentinel portal retires July 2026—explore the Defender unified portal! Learn to manage incidents in a unified queue, enrich investigations with UEBA and Threat Intelligence, and leverage automation and dashboards for smarter SOC operations. 

Dec. 10 | 8:00am | Azure Network Security | Deep Dive into Azure DDoS Protection 

Explore Azure DDoS Protection! Learn to secure apps and infrastructure with end-to-end architecture, detection and mitigation flow, telemetry, analytics, and seamless integration for visibility and protection. 

Dec. 10 | 9:00am | Microsoft Defender for Cloud | Expose Less, Protect More with Microsoft Security Exposure Management  

Join us for an in-depth look at how Microsoft Security Exposure Management helps organizations reduce risk by identifying and prioritizing exposures before attackers can exploit them. Learn practical strategies to minimize your attack surface, strengthen defenses, and protect what matters most. 

Dec. 11 | 8:00am | Microsoft Defender for Cloud | Modernizing Cloud Security with Next Generation Microsoft Defender for Cloud 

Discover how Microsoft Defender for Cloud simplifies multi-cloud security. Learn to streamline posture management and threat protection across Azure, AWS, and GCP, improving efficiency, reducing risk, and enabling smarter prioritization. 

Dec. 11 | 9:00am | Microsoft Sentinel data lake | Transforming data collection for AI-ready security operations with Microsoft Sentinel 

See how Microsoft Sentinel transforms multi-cloud/multiplatform data collection. Learn a unified, cloud-native approach; ingest from on-prem, Microsoft workloads, and multicloud via codeless connectors (350+; App Assure), plus the roadmap for scaling to AI driven SecOps. 

Dec. 15 | 9:00am | Microsoft Entra | Diving into the New Microsoft Entra Agent ID

Join our first session in the Microsoft Entra Agent ID series to learn why agent identity matters, explore core concepts, and see how it fits into Microsoft’s identity ecosystem. Perfect for developers and product owners building AI agents.

Dec. 16 | 8:00am | Microsoft Defender for Office 365 | Ask the Experts: Tips and Tricks 

Engage in this interactive panel with Microsoft MVPs! Get answers to real-world Defender for Office 365 scenarios, best practices, and tips on migration, SOC optimization, Teams protection, and more. Bring your toughest questions for the live discussion. 

Dec. 16 | 9:00am | Microsoft Sentinel | Part 2: Don’t Get Left Behind: Complete Your Sentinel Move to Defender 

Prepare for the July 2026 transition! Unlock Microsoft Defender’s full potential with data onboarding, retention, governance, Content Hub, analytic rules, MTO for simplified management, and Security Copilot for AI-driven insights. 

January 2026 

Jan.13 | 9:00am | Microsoft Sentinel | AI-Powered Entity Analysis in Sentinel’s MCP Server 

Simplify entity risk assessment with Entity Analyzer. Eliminate complex playbooks; get unified, AI-driven analysis using Sentinel’s semantic understanding. Accelerate automation and enrich SOAR workflows with native Logic Apps integration. 

Jan. 20 | 8:00am | Microsoft Defender for Cloud | What’s New in Microsoft Defender CSPM 

Cloud security posture management (CSPM) continues to evolve, and Microsoft Defender CSPM is leading the way with powerful enhancements introduced at Microsoft Ignite. This session will showcase the latest innovations designed to help security teams strengthen their posture and streamline operations. 

Jan. 22 | 8:00am | Azure Network Security | Advancing web application Protection with Azure WAF: Ruleset and Security Enhancements 

Explore the latest Azure WAF ruleset and security enhancements. Learn to fine-tune configurations, reduce false positives, gain threat visibility, and ensure consistent protection for web workloads—whether starting fresh or optimizing deployments. 

Looking for more? 

Join the Microsoft Customer Connection Program (MCCP)! As a MCCP member, you’ll gain early visibility into product roadmaps, participate in focus groups, and access private preview features before public release. You’ll have a direct channel to share feedback with engineering teams, influencing the direction of Microsoft Security products. The program also offers opportunities to collaborate and network with fellow security experts and Microsoft product teams. Join the MCCP that best fits your interests: www.aka.ms/joincommunity. 

Additional resources 

• Microsoft Security Hub on Tech Community 

• Virtual Ninja Training Courses 

• Microsoft Security Documentation 

• Azure Network Security GitHub 

• Microsoft Defender for Cloud GitHub 

• Microsoft Sentinel GitHub 

• Microsoft Defender XDR GitHub 

• Microsoft Defender for Cloud Apps GitHub 

• Microsoft Defender for Identity GitHub 

• Microsoft Purview GitHub 

Background

In Part 1, we explored how a local LLM running entirely on your GPU can call out to the cloud for advanced capabilities The theme was: Keep your data local. Pull intelligence in only when necessary. That was local-first AI calling cloud agents as needed.

This time, the cloud is in charge, and the user interacts with a Microsoft Foundry hosted agent — but whenever it needs private, sensitive, or user-specific information, it securely “calls back home” to a local agent running next to the user via MCP.

Think of it as:

• The cloud agent = specialist doctor
• The local agent = your health coach who you trust and who knows your medical history
• The cloud never sees your raw medical history
• The local agent only shares the minimum amount of information needed to support the cloud agent reasoning

This hybrid intelligence pattern respects privacy while still benefiting from hosted frontier-level reasoning.

Disclaimer:
The diagnostic results, symptom checker, and any medical guidance provided in this article are for illustrative and informational purposes only. They are not intended to provide medical advice, diagnosis, or treatment.

Architecture Overview

The diagram illustrates a hybrid AI workflow where a Microsoft Foundry–hosted agent in Azure works together with a local MCP server running on the user’s machine. The cloud agent receives user symptoms and uses a frontier model (GPT-4.1) for reasoning, but when it needs personal context—like medical history—it securely calls back into the local MCP Health Coach via a dev-tunnel. The local MCP server queries a local GPU-accelerated LLM (Phi-4-mini via Foundry Local) along with stored health-history JSON, returning only the minimal structured background the cloud model needs. The cloud agent then combines both pieces—its own reasoning plus the local context—to produce tailored recommendations, all while sensitive data stays fully on the user’s device.

Hosting the agent in Microsoft Foundry on Azure provides a reliable, scalable orchestration layer that integrates directly with Azure identity, monitoring, and governance. It lets you keep your logic, policies, and reasoning engine in the cloud, while still delegating private or resource-intensive tasks to your local environment. This gives you the best of both worlds: enterprise-grade control and flexibility with edge-level privacy and efficiency.

Demo Setup

Create the Cloud Hosted Agent

Using Microsoft Foundry, I created an agent in the UI and pick gpt-4.1 as model:

I provided rigorous instructions as system prompt:

You are a medical-specialist reasoning assistant for non-emergency triage.  
You do NOT have access to the patient’s identity or private medical history.  
A privacy firewall limits what you can see.

A local “Personal Health Coach” LLM exists on the user’s device.  
It holds the patient’s full medical history privately.

You may request information from this local model ONLY by calling the MCP tool:
   get_patient_background(symptoms)

This tool returns a privacy-safe, PII-free medical summary, including:
- chronic conditions  
- allergies  
- medications  
- relevant risk factors  
- relevant recent labs  
- family history relevance  
- age group  

Rules:
1. When symptoms are provided, ALWAYS call get_patient_background BEFORE reasoning.
2. NEVER guess or invent medical history — always retrieve it from the local tool.
3. NEVER ask the user for sensitive personal details. The local model handles that.
4. After the tool runs, combine:
      (a) the patient_background output  
      (b) the user’s reported symptoms  
   to deliver high-level triage guidance.
5. Do not diagnose or prescribe medication.
6. Always end with: “This is not medical advice.”

You MUST display the section “Local Health Coach Summary:” containing the JSON returned from the tool before giving your reasoning.

Build the Local MCP Server (Local LLM + Personal Medical Memory)

The full code for the MCP server is available here but here are the main parts:

HTTP JSON-RPC Wrapper (“MCP Gateway”)

The first part of the server exposes a minimal HTTP API that accepts MCP-style JSON-RPC messages and routes them to handler functions:

• Listens on a local port
• Accepts POST JSON-RPC
• Normalizes the payload
• Passes requests to handle_mcp_request()
• Returns JSON-RPC responses
• Exposes initialize and tools/list

Tool Definition: get_patient_background

This section defines the tool contract exposed to Azure AI Foundry. The hosted agent sees this tool exactly as if it were a cloud function:

• Advertises the tool via tools/list
• Accepts arguments passed from the cloud agent
• Delegates local reasoning to the GPU LLM
• Returns structured JSON back to the cloud

Local GPU LLM Caller (Foundry Local Integration)

This is where personalization happens — entirely on your machine, not in the cloud:

• Calls the local GPU LLM through Foundry Local
• Injects private medical data (loaded from a file or memory)
• Produces anonymized structured outputs
• Logs debug info so you can see when local inference is running

Start a Dev Tunnel

Now we need to do some plumbing work to make sure the cloud can resolve the MCP endpoint. I used Azure Dev Tunnels for this demo.

The snippet below shows how to set that up in 4 PowerShell commands:

I have now a public endpoint: 

https://xxxxxxxxx.devtunnels.ms:8081

Wire Everything Together in Azure AI Foundry

Now let's us the UI to add a new custom tool as MCP for our agent:

And point to the public endpoint created previously:

Voila, we're done with the setup, let's test it

Demo: The Cloud Agent Talks to Your Local Private LLM

I am going to use a simple prompt in the agent: “Hi, I’ve been feeling feverish, fatigued, and a bit short of breath since yesterday. Should I be worried?”

Disclaimer:
The diagnostic results and any medical guidance provided in this article are for illustrative and informational purposes only. They are not intended to provide medical advice, diagnosis, or treatment.

Below is the sequence shown in real time:

Conclusion — Why This Hybrid Pattern Matters

Hybrid AI lets you place intelligence exactly where it belongs: high-value reasoning in the cloud, sensitive or contextual data on the local machine. This protects privacy while reducing cloud compute costs—routine lookups, context gathering, and personal history retrieval can all run on lightweight local models instead of expensive frontier models.

This pattern also unlocks powerful real-world applications: local financial data paired with cloud financial analysis, on-device coding knowledge combined with cloud-scale refactoring, or local corporate context augmenting cloud automation agents. In industrial and edge environments, local agents can sit directly next to the action—embedded in factory sensors, cameras, kiosks, or ambient IoT devices—providing instant, private intelligence while the cloud handles complex decision-making.

Hybrid AI turns every device into an intelligent collaborator, and every cloud agent into a specialist that can safely leverage local expertise.

References

• Get started with Foundry Local - Foundry Local: https://learn.microsoft.com/en-us/azure/ai-foundry/foundry-local/get-started?view=foundry-classic
• Using MCP tools with Agents (Microsoft Agent Framework) — https://learn.microsoft.com/en-us/agent-framework/user-guide/model-context-protocol/using-mcp-tools Microsoft Learn
• Build Agents using Model Context Protocol on Azure — https://learn.microsoft.com/en-us/azure/developer/ai/intro-agents-mcp Microsoft Learn

Full demo repo available here.