M365.FM - Modern work, security, and productivity with Microsoft 365

Mirko Peters - Founder of m365.fm, m365.show and m365con.net

Welcome to the M365.FM — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365.FM brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. M365.FM is part of the M365-Show Network. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

  1. 2h ago

    From Excel Expert to Microsoft MVP: Empowering Millions with Data, Dashboards & AI with Karen Abecia [Microsoft MVP]

    aren Abecia shares the remarkable journey that transformed a passion for Microsoft Excel into a global career as one of the world's best-known Excel educators. She explains how discovering creative spreadsheet design early in her career led her to help thousands of professionals improve their work, build confidence, and communicate data more effectively. Her story demonstrates that technical expertise combined with genuine passion can create opportunities far beyond traditional career paths. WHY EXCEL CHANGED HER LIFE For Karen, Excel represents much more than software. It gave her financial independence, allowed her to support her family, opened international opportunities, and became a tool for empowering others. She even has two Excel tattoos to symbolize how profoundly the application influenced both her personal and professional life. Rather than viewing Excel as spreadsheets, she sees it as a platform that gives people confidence, recognition, and career growth.  LEARNING WITHOUT A TRADITIONAL EDUCATION Karen discusses building her career without a university degree and explains why continuous learning has always been essential. She believes that formal education is only one path to success and encourages people to study what genuinely excites them. Her philosophy is simple: lifelong curiosity matters more than traditional credentials.  IS EXCEL REALLY DYING? Despite years of headlines claiming that Excel is becoming obsolete, Karen strongly disagrees. She argues that most people predicting Excel's demise do not truly understand how widely it is used across businesses worldwide. Instead of worrying about these predictions, she focuses on helping people solve real problems with the tools they already rely on every day.  THE SECRET OF A GREAT DASHBOARD Creating dashboards is no longer just about technical skills. Karen believes AI can generate standard dashboards for almost anyone, making creativity and presentation more valuable than ever. She explains that outstanding dashboards create a genuine "wow effect" through thoughtful design, visual storytelling, layout, colors, alignment, and attention to detail rather than simply displaying charts and numbers.  COMMON DASHBOARD MISTAKES Many users focus entirely on calculations while overlooking presentation. Karen explains that inconsistent alignment, poor spacing, mismatched colors, incorrect font sizes, and even spelling mistakes can significantly reduce a dashboard's impact. Small visual improvements often make a much larger difference than adding additional formulas or charts.  TEACHING MILLIONS THROUGH SIMPLICITY Having trained more than 15,000 students, Karen believes effective teaching is not about demonstrating advanced technical knowledge. Instead, it is about helping people become more productive and confident using practical techniques they can immediately apply. Her students come from virtually every industry because almost anyone using a computer can benefit from Excel.  EXCEL, AI, AND THE FUTURE OF PRODUCTIVITY Karen discusses how AI is changing Excel workflows and why she actively experiments with multiple AI assistants, including Microsoft Copilot and Claude. Rather than expecting AI to replace expertise, she uses it to accelerate her own creative process while maintaining her personal design style. She also shares her growing interest in Copilot Agents and Microsoft's rapidly evolving AI ecosystem.  EXCEL VS. POWER BI Rather than viewing Excel and Power BI as competitors, Karen now considers them complementary tools. Different organizations require different solutions depending on their size, budget, and reporting needs. While Excel remains her preferred environment for flexibility and creativity, she recognizes that Power BI provides capabilities Excel cannot easily replace.  BUILDING A COMMUNITY THROUGH EMPATHY Karen believes great teachers never make students feel unintelligent. She reflects on early experiences where technical experts made her feel inadequate and explains how those moments shaped her teaching philosophy. Every class is built around patience, encouragement, and making learners feel capable regardless of their experience level.  AUTHENTICITY OVER PERFECTION One of Karen's biggest lessons is that people connect with authenticity rather than perfection. She openly embraces mistakes, especially when speaking English, and believes showing vulnerability creates stronger relationships with students. Instead of trying to appear flawless, she encourages others to simply be themselves.  BECOMING A MICROSOFT MVP Receiving the Microsoft MVP award was one of the defining moments of Karen's career. She explains how years of consistently helping the community eventually resulted in recognition from Microsoft. More important than the title itself was the validation that her work was making a meaningful impact around the world.  STORIES THAT MADE THE BIGGEST IMPACT Among thousands of student success stories, Karen recalls one of the most unexpected: receiving a message from someone learning Excel while serving time in prison. She also shares emotional stories of people overcoming depression and rebuilding their confidence through learning. These experiences reinforced her belief that education is ultimately about empowering people—not simply teaching software.  QUICK FIRE FAVORITES Karen reveals some of her personal favorites during the rapid-fire round:Excel over Power BIBrigadeiro as her favorite Brazilian foodDark ModePower Query over Pivot TablesCtrl+K as her favorite shortcutCharts Maps as an underrated Excel featureWindows over MacClassroom training over online sessionsDashboard over reportsBackstreet Boys' As Long As You Love Me as her karaoke songOne word for Excel: FlexibilityBALANCING BUSINESS, FAMILY, AND CONTENT CREATION Karen closes the conversation by explaining that she doesn't separate work from life. Ideas flow naturally between family, teaching, entrepreneurship, and content creation. Rather than measuring success by hours worked, she focuses on making every hour meaningful while keeping her children at the center of everything she does. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    From Excel Expert to Microsoft MVP: Empowering Millions with Data, Dashboards & AI with Karen Abecia [Microsoft MVP]
  2. 22h ago

    The Copilot Credit Trap- Why Your AI Economy is Already Broken

    For decades, enterprise software followed a predictable financial model. Organizations purchased licenses, assigned them to users, and budgeted annual IT spending with confidence. AI changes that completely. Modern AI platforms are no longer sold purely as software—they're becoming consumption-based services where autonomous agents perform work on your behalf. Every action, every reasoning cycle, every orchestration task, and every AI workflow consumes credits instead of simply using a fixed license. This episode explains why Copilot Credits fundamentally change enterprise budgeting, why governance becomes more important than licensing, and how organizations must rethink identity, permissions, auditing, FinOps, and AI compliance before autonomous agents become part of everyday business operations. FROM SOFTWARE LICENSES TO AI ECONOMICS Traditional enterprise software was easy to budget. Organizations counted employees, purchased licenses, and forecasted annual costs with relatively little uncertainty. AI introduces a completely different financial model. Instead of paying only for access, organizations increasingly pay for work performed. Every autonomous action performed by an AI agent consumes credits based on: Reasoning complexityRuntimeContext sizeTool usageModel selectionThis transforms AI from a predictable software expense into an operational resource similar to cloud compute. The presentation argues that organizations are no longer purchasing software—they're purchasing autonomous labor, and that fundamentally changes IT economics. THE COPILOT CREDIT TRAP The biggest misconception surrounding Copilot Credits is that they simply represent another licensing model. They don't. Credits become the currency of AI work. A lightweight task may consume relatively few credits. Complex reasoning tasks involving multiple enterprise systems, long context windows, and autonomous orchestration consume dramatically more. Costs now scale according to: Agent behaviorTask complexityOrganizational adoptionWorkflow automationrather than simply employee count. Organizations may believe they have predictable AI costs because licensing appears fixed, while actual consumption grows continuously behind the scenes. This hidden variability creates what the presentation describes as the Copilot Credit Trap. WHY FINANCE CAN NO LONGER PREDICT COSTS Finance departments have traditionally planned annual software budgets using fixed subscription pricing. Consumption-based AI disrupts that model. Instead of budgeting for employees, organizations must now forecast: Daily agent activityDepartmental usageBusiness workflowsCredit consumptionSeasonal demandAutomation growthSmall changes in adoption can produce disproportionately large cost increases. The challenge isn't simply higher spending. It's the loss of financial predictability. Variable AI consumption introduces volatility that traditional IT budgeting processes were never designed to manage. VISIBILITY IS THE FIRST GOVERNANCE PROBLEM Many organizations cannot accurately answer basic questions such as: Which AI agents currently exist?Which departments deployed them?Which systems can they access?Which business processes do they automate?How much do they cost?The presentation describes this as the visibility crisis. Shadow AI deployments appear through: Copilot StudioPower AutomateDepartmental automationThird-party AI integrationsCustom workflowsWithout a complete inventory, governance becomes impossible because organizations cannot secure, monitor, or budget for systems they don't even know exist. PERMISSIONS BECOME MULTIPLIED One of the most significant risks discussed throughout the session is permission amplification. AI agents inherit the permissions of the identities under which they operate. If a user can access HR records, the agent can also access them. If a user can modify SharePoint documents, schedule meetings, or send emails, so can the agent. Unlike humans, however, agents perform these actions at machine speed and enterprise scale. This dramatically amplifies existing governance weaknesses, especially in environments suffering from years of permission creep and excessive data sharing. The presentation argues that AI doesn't create governance problems—it magnifies the ones organizations already have. AUTONOMY REQUIRES NEW GOVERNANCE Traditional software waits for users. Autonomous agents do not. Modern AI systems: Send emailsUpdate recordsSchedule meetingsTrigger workflowsCoordinate with other agentsoften after only an initial approval. As conditions change during execution, agents adapt automatically. This makes traditional approval processes insufficient. Organizations must introduce: Human approval gatesEscalation rulesSpending thresholdsRisk classificationsContinuous monitoringGovernance moves from documentation into active operational control. THE EU AI ACT CHANGES EVERYTHING One of the central themes of the presentation is the approaching regulatory landscape. Organizations deploying AI into HR, finance, customer services, or other sensitive business functions face increasing governance obligations under the EU AI Act. High-risk AI systems require: Risk managementTechnical documentationHuman oversightAudit trailsIncident reportingContinuous monitoringCompliance is no longer simply about technology. It becomes an enterprise operating capability involving legal, compliance, security, and business leadership working together. IDENTITY IS THE FOUNDATION The presentation argues that autonomous agents require independent identities rather than sharing user accounts. Each agent should receive: Dedicated identityScoped permissionsLeast-privilege accessIndependent audit trailLifecycle managementThis enables organizations to distinguish human actions from autonomous agent behavior while improving accountability and reducing operational risk. Identity becomes the foundation upon which every other governance capability depends Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    The Copilot Credit Trap- Why Your AI Economy is Already Broken
  3. 1d ago

    The End of AI Bloat: Why Modern Agents Need Skills

    Many AI agents start out fast, responsive, and surprisingly intelligent. But after a few months of real-world use, something changes. Response times increase, costs rise, prompts become enormous, and accuracy begins to decline. Organizations often respond by upgrading to larger models, expanding prompts, or adding more orchestration—but the underlying problem remains. The issue isn't the model. It's the architecture. This episode explains why monolithic prompts create what is known as the Context Tax, how modular Skills solve the problem through progressive disclosure, and why Skills are becoming the architectural foundation of modern AI agents across Microsoft Copilot Studio, GitHub Copilot, Claude Code, and the broader enterprise AI ecosystem. THE CONTEXT TAX Every enterprise AI project eventually faces the same challenge. At first, an agent contains a relatively small system prompt describing its role, tone, business rules, and guardrails. As the organization grows, more instructions are added: PoliciesCompliance rulesBusiness proceduresExamplesEdge casesDepartment-specific workflowsEventually the prompt becomes thousands of tokens long. Every user request forces the model to process every instruction—even when ninety-five percent of them are completely irrelevant. This hidden processing overhead is called the Context Tax. Rather than making agents smarter, larger prompts increase latency, raise inference costs, introduce reasoning noise, and gradually reduce answer quality. The presentation argues that the real problem isn't insufficient AI capability—it is forcing the model to continuously reason over information it doesn't actually need. WHY AGENTS DEGRADE OVER TIME Agent degradation is remarkably predictable. Organizations usually begin with one comprehensive instruction document that contains everything the AI should know. Initially this works well. Then new departments request additional functionality. Policies evolve. Compliance requirements expand. New workflows are added. Instead of restructuring the architecture, teams simply keep extending the same prompt. The result is context saturation. The model spends increasing amounts of effort searching through irrelevant guidance before finding the instructions that actually matter. This produces several side effects: Higher token consumptionSlower responsesIncreased hallucinationsMore inconsistent reasoningHigher operational costsThe AI hasn't become less intelligent. Its reasoning path has simply become overwhelmed by unnecessary context. ALWAYS-ON GUIDANCE VS SITUATIONAL EXPERTISE One of the most important architectural distinctions introduced in this session is separating always-on guidance from situational expertise. Always-on guidance includes information that applies to every conversation: Agent identityTone of voiceUniversal compliance rulesSecurity requirementsCore behavioral instructionsSituational expertise is different. It only matters when specific scenarios occur. Examples include: Vendor onboardingLeave eligibilityTax regulationsRefund workflowsRegional complianceIncident response proceduresTraditional agents mix both categories into one enormous prompt. Modern agent architectures separate them. Only universal guidance remains permanently loaded. Everything else becomes modular Skills that activate only when required. WHAT IS A SKILL? A Skill is much more than a prompt. It is a reusable package containing: Structured instructionsMetadataTrigger descriptionsOptional scriptsReference documentsTemplatesSupporting assetsThe core of every Skill is the SKILL.md file. This file defines: NameDescriptionPurposeTrigger conditionsWorkflowProcedural guidanceThe orchestrator doesn't initially load the entire Skill. Instead, it evaluates only the metadata. When the user's request matches the Skill description, the complete instructions are loaded into context. This dramatically reduces unnecessary reasoning while keeping specialist knowledge available exactly when needed. THE REASONING BOUNDARY The presentation introduces another important architectural concept: Skills define reasoning boundaries. Rather than forcing an AI model to treat every instruction as universally relevant, Skills establish clear expertise domains. A leave management Skill applies only to leave requests. A procurement Skill activates only during purchasing workflows. A compliance Skill loads only when compliance questions arise. Each Skill becomes an isolated reasoning domain. Instead of thinking about every possible business process simultaneously, the model focuses exclusively on the knowledge required for the current task. This improves both precision and consistency.  PROGRESSIVE DISCLOSURE One of the core design principles behind Skills is Progressive Disclosure. Instead of loading every instruction at startup, agents maintain only a lightweight catalog containing Skill names and descriptions. When a matching scenario appears: The orchestrator identifies the relevant Skill.The Skill loads into context.The task executes.The Skill unloads after completion.Everything else remains outside the context window. This significantly reduces: Token usageLatencyCompute requirementsInfrastructure costsThe architecture keeps the default state intentionally lean. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    The End of AI Bloat: Why Modern Agents Need Skills
  4. 1d ago

    THE DEATH OF THE PROXY: Architecting Dataverse for the Agent Fabric

    For years, Microsoft's recommended architecture for connecting AI assistants like Claude Desktop to Dataverse relied on a local STDIO proxy. It was simple, easy to install, and perfectly suited for individual developers experimenting with AI-powered workflows. But enterprise AI has evolved. Organizations are no longer connecting a single assistant to a single application. They're connecting hundreds—or even thousands—of AI agents across multiple clients, platforms, and business systems. That architectural shift changes everything. This episode explains why the traditional proxy model has reached its limits, why Streamable HTTP fundamentally changes enterprise AI integration, and how Dataverse is evolving from the database behind Power Apps into the governed data backbone for the entire Agent Fabric. WHY THE STDIO PROXY WAS CREATED The original STDIO proxy solved a very specific problem. Early MCP clients like Claude Desktop needed a simple way to communicate with cloud services while running locally on a developer's machine. Instead of exposing an internet-facing endpoint, developers launched a local process that translated communication between the AI client and Dataverse. The advantages were obvious: Simple installationNo HTTP server requiredNo certificatesMinimal infrastructureIsolated execution per userFor individual developers, this architecture worked remarkably well. Every proxy was independent, failures affected only one user, and deployment required little more than installing a small application. The problem wasn't that the proxy stopped working. The problem was that enterprise AI completely outgrew the assumptions behind it. THE PROXY SCALING PROBLEM The proxy architecture assumes one developer. Modern enterprises operate very differently. Instead of one Claude Desktop instance, organizations now deploy: Claude DesktopClaude CodeGitHub CopilotCopilot CLICustom orchestration servicesInternal AI assistantsEach proxy creates: Independent authenticationSeparate connection poolsIndividual infrastructureSeparate monitoringIsolated failure domainsAs organizations scale from ten developers to hundreds or thousands, operational complexity increases exponentially. Instead of managing one governed service, administrators find themselves maintaining hundreds of disconnected proxy processes with little centralized visibility or control. What began as a convenience gradually becomes operational debt. THE LATENCY MYTH One of the strongest arguments for STDIO has always been performance. Microbenchmarks show local inter-process communication taking only a few milliseconds, while HTTP introduces network latency and TLS negotiation. On paper, STDIO appears dramatically faster. However, those benchmarks ignore the actual workload. Most Dataverse operations spend hundreds of milliseconds—or even more than a second—executing business logic, security checks, and database queries. When those execution times are included, HTTP overhead becomes relatively insignificant. Even more importantly, enterprise HTTP deployments benefit from: Connection poolingPersistent sessionsHorizontal scalingLong-lived servicesShared infrastructureMeanwhile, every new proxy instance pays startup costs, authentication overhead, and process initialization repeatedly. The presentation argues that organizations measuring end-to-end performance often find properly optimized HTTP deployments outperform local proxy architectures despite their higher transport latency. STREAMABLE HTTP CHANGES EVERYTHING Instead of every AI client running its own proxy, Dataverse now exposes a single Streamable HTTP endpoint. Every supported AI client connects to exactly the same service. Examples include: Claude DesktopClaude CodeGitHub CopilotVS CodeCustom AI orchestratorsRather than multiplying infrastructure for every new user, organizations scale a single enterprise service. Additional capacity simply means adding more server instances behind a load balancer. Clients continue connecting to the same endpoint while the platform handles scaling transparently. The architecture shifts from isolated desktop utilities to enterprise-grade shared infrastructure. PKCE ENABLES SECURE PUBLIC CLIENTS Moving to HTTP introduces a new challenge: How do desktop applications authenticate without storing client secrets? The answer is PKCE (Proof Key for Code Exchange). Instead of embedding long-lived secrets inside client applications, PKCE generates temporary cryptographic values during authentication. This approach allows applications like: Claude DesktopClaude CodeGitHub Copilotto authenticate securely using Microsoft Entra ID without exposing credentials. Authentication becomes: Secret-freeUser-basedStandards compliantAutomatically renewableThis security model enables enterprises to deploy multiple AI clients without distributing confidential application secrets to every workstation. DATAVERSE BECOMES THE AGENT FABRIC Perhaps the most important architectural shift is how Dataverse itself is positioned. Historically many organizations viewed Dataverse simply as the database behind Power Apps. The presentation argues that this perspective is obsolete. Dataverse now becomes the central business data platform for AI agents. Every supported AI client communicates through the same endpoint. Every request uses: Shared governanceShared authenticationShared business logicShared securityShared audit trailsInstead of building separate integrations for every large language model, organizations expose one governed platform that every compliant client can consume. This transforms Dataverse from an application database into enterprise AI infrastructure. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    THE DEATH OF THE PROXY: Architecting Dataverse for the Agent Fabric
  5. 1d ago

    The Death of the Pipeline: Why AI Agents are Replacing Traditional

    For more than two decades, CI/CD pipelines have been the backbone of modern software delivery. Developers commit code, automated builds run, tests execute, security scans complete, someone approves the deployment, and production is updated. This model transformed software engineering and enabled DevOps to become the industry standard. But the world has changed. Cloud-native applications, Kubernetes, AI, multi-cloud architectures, and thousands of daily deployments have pushed traditional pipelines beyond what they were designed to handle. The real bottleneck is no longer automation—it's the fact that automation still revolves around human decision-making and linear workflows. This episode explores a radical shift: replacing sequential CI/CD pipelines with intelligent, autonomous AI agents that reason, collaborate, and adapt in real time. We'll examine why traditional pipelines are reaching their limits, how agentic systems fundamentally change software delivery, and why governance—not autonomy—is becoming the defining architectural challenge of the next generation of DevOps. WHY THE TRADITIONAL PIPELINE IS BREAKING Traditional CI/CD pipelines were designed around a simple assumption: Humans make the important decisions. A developer commits code. The pipeline builds. Tests execute. Security scans run. Then someone reviews. Someone approves. Someone decides whether deployment should continue. Every approval introduces waiting. Every handoff introduces latency. Every manual decision becomes another bottleneck. This worked perfectly when organizations deployed once every few weeks. Today's cloud-native organizations deploy hundreds or even thousands of times every day. At that scale, human approval is no longer primarily a safety mechanism. It becomes the slowest component in the entire delivery system. The pipeline itself isn't broken. Its underlying operating model is. AUTOMATION ISN'T THE SAME AS INTELLIGENCE Many organizations tried solving pipeline bottlenecks through automation. They built scripts. They created runbooks. They automated approvals. Initially this improved delivery speed. Eventually another problem appeared. Scripts only work inside predefined conditions. Whenever infrastructure changes, scripts begin failing. New Kubernetes versions... Changed APIs... Different deployment strategies... Updated security requirements... Every infrastructure evolution requires maintaining automation itself. Traditional automation has no understanding of context. It executes procedures. It doesn't reason. Organizations eventually spend enormous effort maintaining automation instead of benefiting from it. The presentation argues that static automation reaches a ceiling because modern infrastructure changes faster than rule-based systems can keep up. AI AGENTS CHANGE THE MODEL An AI agent is fundamentally different from a script. Scripts execute instructions. Agents reason. Instead of simply matching predefined rules, an agent continuously: Observes system stateUnderstands contextEvaluates possible actionsChooses the safest strategyLearns from previous outcomesImagine a degraded service. A script simply restarts it. An AI agent first investigates. Is this really a service failure? Is memory leaking? Is traffic unusually high? Would a canary rollout be safer than a restart? Could restarting actually make the situation worse? Rather than following procedures, AI agents operate using policies and objectives. That distinction fundamentally changes software delivery because the system adapts instead of merely executing instructions. FROM PIPELINES TO AGENT FABRICS Perhaps the biggest concept introduced in this session is that the future isn't a faster pipeline—it isn't a pipeline at all. Traditional delivery is sequential. Commit. Build. Test. Deploy. Each stage waits for the previous one. Agentic systems replace this with an AI fabric. Multiple specialized agents operate simultaneously. One analyzes security. Another writes tests. Another validates performance. Another evaluates deployment strategy. Instead of waiting for sequential stages, agents continuously exchange information while reasoning together. Researchers increasingly describe this model as Continuous Agentic Continuous Deployment (CA/CD) where reasoning replaces stage gates. The result isn't simply faster deployment. It's an entirely different operating model built around collaboration rather than sequence. THE SUPERVISOR-WORKER ARCHITECTURE Production AI systems don't consist of one giant intelligent agent. Instead, they increasingly adopt the Supervisor-Worker architecture. A supervisor agent owns the business objective. Specialized worker agents focus on individual domains: SecurityTestingPerformanceDeploymentComplianceWorkers analyze their specific area. The supervisor coordinates the work, combines expert recommendations, and makes the final decision. This architecture provides several advantages: Clear accountabilityEasier auditingBetter scalabilityIndependent specializationEasier maintenanceRather than creating one enormous AI system responsible for everything, organizations compose smaller expert agents that collaborate through orchestration. Companies adopting this architecture are reporting significantly faster delivery cycles while maintaining stronger governance. AUTONOMY ISN'T THE GOAL One of the most important lessons throughout the presentation is that full autonomy is neither realistic nor desirable. Current AI agents still require frequent human correction. Rather than viewing this as failure, organizations should treat it as a natural safety mechanism. The goal becomes appropriate autonomy. Low-risk activities may execute completely automatically. Medium-risk actions require human confirmation. High-risk production deployments remain supervised. Authority expands gradually based on measured performance. Autonomy is earned—not assumed. Successful organizations build tiered governance where AI gains additional responsibility only after consistently demonstrating reliable decision quality. GOVERNANCE BECOMES ARCHITECTURE Traditional governance relied on documents and policies. Agentic systems require something much stronger. Governance becomes architecture. Instead of saying: "Agents should only deploy approved services." Organizations technically prevent any other deployment from happening. Every agent receives: Cryptographic identityScoped permissionsShort-lived credentialsPolicy validationContinuous authorizationComplete audit loggingEvery action is validated immediately before execution. Agents don't merely promise to follow policy. The architecture prevents them from violating it. This represents one of the largest architectural shifts introduced by autonomous software delivery- MULTI-AGENT COMMITTEES Some decisions are too complex for a single agent. The presentation introduces another emerging architectural pattern: The Multi-Agent Committee. Rather than relying on one AI model, multiple specialist agents independently evaluate the same decision. For example: Security AgentPerformance AgentCode Review AgentCompliance AgentEach produces an independent recommendation. The supervisor synthesizes their conclusions before approving deployment. This dramatically improves decision quality because multiple expert perspectives identify different classes of problems. When disagreement occurs, the system naturally escalates to a human instead of forcing artificial certainty. Collective reasoning becomes safer than relying on any individual model. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    The Death of the Pipeline: Why AI Agents are Replacing Traditional
  6. 2d ago

    The Productivity Illusion: Why AI is Breaking Your Engineering KPIs

    At first glance, the numbers look incredible. Deployment frequency is increasing, pull requests are being merged faster than ever, AI is generating more code, and engineering teams appear dramatically more productive. Executive dashboards are filled with green indicators suggesting software delivery has entered a new golden age. But beneath those impressive metrics lies a very different reality. AI has accelerated code generation, but it hasn't eliminated engineering work. Instead, it has shifted the bottlenecks from writing code to reviewing, validating, governing, and understanding it. Organizations are producing significantly more code while simultaneously experiencing more incidents, higher cognitive load, greater technical debt, and increased developer burnout. THE PRODUCTIVITY ILLUSION The central message of this session is simple: More code does not automatically mean more productivity. AI has dramatically increased engineering output, but many organizations are confusing output with value. According to the presentation: AI now generates a significant portion of production code.Pull request throughput has nearly doubled.Developers save substantial time on repetitive coding tasks.Yet production incidents, code churn, review times, and cognitive load have all increased.Rather than removing engineering constraints, AI has simply moved them further downstream into review, testing, operations, and governance. The dashboard still reports success—but the engineering system itself is becoming increasingly fragile. WHY TRADITIONAL KPIs ARE FAILING Many engineering organizations still rely heavily on classic DevOps metrics such as: Deployment FrequencyLead TimeChange Failure RateMean Time To Recovery (MTTR)These metrics were designed for a world where humans wrote nearly all production code. AI fundamentally changes that assumption. Today's bottleneck is no longer writing software. It is understanding software. Deployment frequency may increase while review queues explode. Lead time may decrease while technical debt grows. Change failure rates may appear acceptable while code requires constant rewrites. The presentation argues that traditional engineering dashboards measure activity, not system health. WHEN MORE CODE CREATES MORE PROBLEMS One of the strongest themes throughout the presentation is the unintended consequence of AI-generated software. Developers can now create thousands of lines of code within minutes. Human reviewers, however, still need to verify every important architectural, security, and business decision. As pull requests become larger and more complex: Review times increase dramatically.Senior engineers become bottlenecks.Production incidents rise.Technical debt accumulates faster.More code requires future maintenance.Instead of removing engineering work, AI shifts effort toward verification and understanding. The engineering organization appears faster while becoming increasingly overloaded. THE COGNITIVE LOAD CRISIS Perhaps the most important concept discussed is cognitive load. AI reduces the effort required to write code. It dramatically increases the effort required to understand that code. Developers now spend increasing amounts of time: Reviewing AI-generated implementations.Understanding unfamiliar logic.Switching between contexts.Verifying correctness.Explaining code the AI never documented.The presentation distinguishes between productive engineering effort and unnecessary mental overhead. Instead of solving business problems, engineers increasingly spend their cognitive capacity validating machine-generated output. The result is lower developer satisfaction despite higher apparent productivity. THE TOXIC KPI TRAP Organizations naturally optimize whatever they measure. The problem arises when the metrics themselves no longer represent organizational health. Examples include: Maximizing AI-generated code percentage.Increasing deployment frequency.Optimizing story points.Reducing review duration.Maximizing pull requests per developer.Each metric improves individually. Meanwhile: Rework increases.Stability declines.Technical debt grows.Review quality drops.Engineers burn out.The presentation argues that these KPIs encourage organizations to optimize motion instead of meaningful outcomes. Good numbers do not necessarily represent healthy engineering systems. FROM ACTIVITY TO FLOW A major recommendation is replacing activity-based thinking with flow-based measurement. Instead of asking: "How much did we ship?" Organizations should ask: "How efficiently does work move through the system?" Important flow metrics include: Flow efficiencyQueue ageReview cycle timeWork in Progress (WIP)Bottleneck identificationRework rateThese metrics reveal where work actually becomes blocked rather than simply counting completed deployments. The presentation argues that AI has shifted engineering constraints from development toward review and verification, making flow measurement far more valuable than raw throughput metrics. DORA 5 AND REWORK RATE One of the most practical recommendations is expanding traditional DORA metrics with a fifth dimension: Rework Rate. Rather than simply measuring deployment speed, organizations should track how much recently written code must be rewritten shortly afterward. High rework indicates: Weak verificationPoor code durabilityFragile architecturesInadequate reviewsIncorrect AI usageRework becomes a much stronger indicator of long-term engineering quality than deployment frequency alone. The presentation positions this as one of the most valuable indicators for AI-assisted software development. BURNOUT IS A SYSTEM METRIC Another major insight is that burnout should be viewed as an engineering metric—not merely an HR concern. The presentation connects rising cognitive load with: Developer dissatisfactionIncreased context switchingLonger review cyclesNight and weekend workHigher attritionLower software qualityWhen developers spend most of their day reviewing AI-generated code rather than solving meaningful business problems, engineering quality gradually declines. Organizations that ignore these signals risk losing their most experienced engineers while dashboards continue reporting "improved productivity." Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    The Productivity Illusion: Why AI is Breaking Your Engineering KPIs
  7. 2d ago

    The DevOps Tax: Why Your Platform is Failing

    Welcome to another episode of Knowledge Nuggets with Mirko Peters. Today we're exploring The DevOps Tax—the hidden cost that silently reduces engineering productivity, increases cognitive overload, and prevents organizations from delivering software at scale. DevOps began with a simple but powerful vision: "You build it, you run it." Small, autonomous teams would own their applications from development through production, eliminating handoffs between developers and operations. For many organizations, this approach initially delivered faster releases and better accountability. But as companies grew, so did the complexity. Developers were expected to become experts in Kubernetes, cloud networking, Infrastructure as Code, observability, security, compliance, cost optimization, and CI/CD—all while still building business features. Instead of accelerating innovation, many teams found themselves spending more time managing infrastructure than delivering customer value. In this episode, we'll examine why the DevOps model struggles at enterprise scale, what the DevOps Tax really costs organizations, and how Platform Engineering, Golden Paths, Infrastructure as Code, Policy as Code, and AI-ready governance provide a practical path forward. WHAT IS THE DEVOPS TAX? The DevOps Tax isn't a software licensing cost or another cloud bill. It's the hidden productivity cost created when developers spend the majority of their time solving infrastructure problems instead of building products. Modern developers are expected to understand: KubernetesContainersCloud platformsNetworkingRBACCI/CDInfrastructure as CodeMonitoringDistributed tracingSecurityComplianceCost optimizationDisaster recoveryNone of these activities directly create customer value, yet they consume a significant percentage of engineering capacity. The presentation argues that this "tax" compounds over time through burnout, delayed releases, duplicated effort, and increased organizational complexity, ultimately reducing the return on engineering investment. Research referenced in the session suggests that roughly 74% of developer capacity is consumed by infrastructure toil instead of feature delivery. WHY DEVOPS BREAKS AT SCALE DevOps works remarkably well for small teams. When ten or fifteen engineers own an application, everyone understands the architecture, infrastructure decisions are shared, and feedback loops remain short. Enterprise organizations are different. As hundreds of teams emerge, every group begins selecting its own tools: Different CI/CD platformsDifferent monitoring stacksDifferent Infrastructure as Code frameworksDifferent deployment approachesDifferent security modelsEach individual decision appears reasonable. Collectively, however, they create enormous operational complexity. Documentation diverges. Runbooks become inconsistent. Senior engineers become bottlenecks. Developers spend increasing amounts of time coordinating infrastructure instead of delivering business functionality. The presentation argues that organizations eventually stop managing infrastructure and begin managing organizational chaos. THE COGNITIVE LOAD CRISIS One of the central themes of the session is cognitive load. Developers already need to understand complex business domains. Adding infrastructure decisions on top dramatically increases the amount of mental effort required before writing any business logic. The presentation introduces the concept of Concepts to Ship (CTS). A traditional DevOps environment often requires developers to understand fifteen to twenty different infrastructure concepts before deploying a service. These include: Kubernetes networkingService meshesRBACStorageResource limitsObservabilityDeployment pipelinesSecrets managementNetwork policiesPlatform Engineering aims to reduce that number to only a handful of concepts by abstracting infrastructure behind standardized workflows. Reducing cognitive load ultimately improves productivity, onboarding, software quality, and developer satisfaction. PLATFORM ENGINEERING AS THE SOLUTION Rather than asking every development team to become infrastructure experts, Platform Engineering centralizes common capabilities into a reusable internal platform. Instead of developers designing databases, networking, backup strategies, monitoring, and deployment pipelines from scratch, the platform provides those capabilities as standardized services. This fundamentally changes team responsibilities. Product teams focus on business value. Platform teams focus on delivering infrastructure as a product. Rather than distributing infrastructure complexity to everyone, organizations centralize expertise while preserving developer autonomy. The result is greater consistency, improved governance, and dramatically lower cognitive overhead. GOLDEN PATHS A major concept introduced throughout the presentation is the Golden Path. A Golden Path is an opinionated, pre-built workflow covering the majority of common engineering scenarios. Rather than presenting dozens of infrastructure choices, developers receive a standard approach that already includes: CI/CD pipelinesSecurity scanningMonitoringLoggingDeployment strategiesCompliance validationRollback proceduresDevelopers customize only the business-specific parts of their application. Everything else follows proven organizational standards. Exceptions remain possible, but they become intentional collaboration with the platform team instead of every developer reinventing infrastructure independently. The presentation emphasizes that successful Golden Paths solve approximately eighty percent of common deployment scenarios while continuously evolving based on developer feedback. INFRASTRUCTURE AS CODE AND POLICY AS CODE Platform Engineering depends heavily on automation. Infrastructure as Code transforms infrastructure from manual portal configuration into version-controlled code. This provides: ReproducibilityVersion historyPeer reviewAutomated deploymentComplete audit trailsPolicy as Code extends this concept further. Instead of documenting governance rules inside PDFs or SharePoint pages, security policies become executable code. Organizations can automatically enforce: Encryption requirementsNetwork restrictionsBackup policiesResource standardsSecurity baselinesCompliance stops becoming a manual review process and instead becomes an automated deployment requirement. Developers no longer need to remember every governance rule because the platform enforces them automatically. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    The DevOps Tax: Why Your Platform is Failing
  8. 2d ago

    Microsoft Purview Insider Risk Management - Simply Explained

    Welcome to another episode of Knowledge Nuggets with Mirko Peters. Today we're exploring Microsoft Purview Insider Risk Management, Microsoft's intelligent solution for identifying risky user behavior before it turns into a costly security incident. When organizations think about cybersecurity, they usually focus on external threats—hackers, malware, ransomware, and phishing attacks. But one of the biggest security risks often comes from inside the organization. Employees already have legitimate access to sensitive information. Whether through malicious intent or simple human error, that trusted access can become a significant business risk. Microsoft Purview Insider Risk Management helps organizations identify unusual patterns of user behavior, investigate potential insider threats, and respond appropriately while maintaining strong privacy protections. Rather than assuming every employee is a threat, it uses intelligent risk scoring and machine learning to distinguish between normal business activity and behavior that deserves closer attention. In this episode, we'll explore how Insider Risk Management works, how Microsoft calculates risk, and why privacy remains a central part of the entire solution. WHY INSIDER RISK IS DIFFERENT Traditional cybersecurity is designed to stop unauthorized users from gaining access. Firewalls block unwanted network traffic. Multi-factor authentication verifies identities. Endpoint protection detects malware. These technologies are extremely effective against external attacks. However, they all share one important assumption: Once users successfully authenticate, they are generally trusted. That assumption creates a significant blind spot. Insider threats don't involve breaking into the organization. They involve legitimate users performing activities that become risky over time. Insider risk generally falls into two categories. Malicious insider risk includes intentional activities such as data theft, intellectual property theft, sabotage, or unauthorized data exfiltration. Accidental insider risk includes users mistakenly sharing confidential information, forwarding sensitive emails, copying files to personal storage, or violating security policies without realizing it. Traditional security solutions rarely detect these behaviors because, technically, the user is authorized to perform many of the underlying actions. Microsoft Purview Insider Risk Management focuses on identifying risky behavior rather than simply validating user access. WHAT IS MICROSOFT PURVIEW INSIDER RISK MANAGEMENT? Microsoft Purview Insider Risk Management is a compliance capability within Microsoft Purview that helps organizations identify, investigate, and respond to potentially risky user behavior. Rather than monitoring individual activities in isolation, the system analyzes patterns across Microsoft 365. Signals are collected from multiple Microsoft services, including: Exchange OnlineSharePoint OnlineOneDriveMicrosoft TeamsMicrosoft Entra IDEndpoint activityData Loss PreventionSensitivity labelsMachine learning evaluates these signals over time to determine whether behavior differs significantly from normal activity. The objective is not to spy on employees. Instead, Microsoft focuses on identifying situations where organizations should perform additional review before a genuine security incident occurs. Human investigators always make the final decision. The platform simply highlights behavior that deserves attention. HOW RISK SCORING WORKS Microsoft Purview Insider Risk Management does not generate alerts based on a single isolated action. Instead, it evaluates combinations of activities over time. Examples of monitored indicators include: Large file downloadsEmail forwardingPrinting sensitive documentsUSB file transfersAccessing sensitive SharePoint sitesUploading data to cloud storageUnusual login behaviorAfter-hours activityEach event contributes to an overall risk score. A single large download might be completely normal. However, when combined with several additional indicators—such as forwarding emails to personal accounts after submitting a resignation—the overall pattern becomes significantly more suspicious. Machine learning compares current activity against historical behavior for both the individual user and similar job roles. Downloading source code may be normal for software developers. The same activity performed by someone in Human Resources would represent unusual behavior. The platform continuously learns organizational baselines to reduce false positives while highlighting meaningful anomalies. Importantly, risk scores represent probabilities—not proof of wrongdoing. Human review remains essential before any action is taken. POLICIES, TEMPLATES, AND RISK INDICATORS Microsoft provides predefined policy templates covering common insider risk scenarios. Examples include: Departing employeesData theftData leaksSecurity policy violationsRisky user behaviorAdministrators simply select the template most appropriate for their organization and configure the users or groups that should be included. Behind each policy are dozens of built-in indicators. These include activities such as: External email forwardingPrintingUSB usageCloud storage uploadsSharePoint downloadsOneDrive synchronizationSensitive file accessOrganizations can further improve detection by integrating external business signals. Examples include: HR systemsEmployee resignation noticesBadge access systemsLegal investigationsCompliance eventsThese external signals provide additional context that significantly improves risk scoring accuracy. Rather than monitoring every employee equally, organizations focus on scenarios where risk is genuinely elevated. INVESTIGATING INSIDER RISK When Microsoft identifies suspicious behavior, investigators receive an alert within the Microsoft Purview compliance portal. Each alert includes: Overall risk scoreUser informationTimeline of activitiesAssociated indicatorsSupporting evidenceOne of the most valuable features is the activity timeline. Rather than reviewing isolated events, investigators can understand the complete sequence of actions. For example: File downloadsEmail forwardingUSB transfersAfter-hours activitySharePoint access Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Microsoft Purview Insider Risk Management - Simply Explained

Ratings & Reviews

5
out of 5
3 Ratings

About

Welcome to the M365.FM — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365.FM brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. M365.FM is part of the M365-Show Network. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

You Might Also Like