June 15, 2026

STOP BUILDING SILOED AGENTS: The Logic App Nervous System

In this episode, we explore why many organizations are making a critical mistake when building AI solutions: creating agents that operate in isolation. While individual agents can be powerful, they often become disconnected silos that lack the ability to coordinate across systems, processes, and business functions.

The conversation focuses on Azure Logic Apps as the “nervous system” for enterprise AI, providing the orchestration layer that connects agents, applications, and workflows. Rather than viewing agents as standalone tools, organizations should design them as part of a larger ecosystem where events, messages, and automated processes enable collaboration and intelligent decision-making.

We discuss the principles of event-driven architecture, the role of integration in modern AI systems, and how Logic Apps can connect Microsoft 365, Azure services, business applications, and external platforms. The episode also covers governance, scalability, and operational visibility, showing how organizations can move from fragmented automation to coordinated, enterprise-wide intelligence.

Whether you're an architect, developer, or IT leader, this episode offers practical insights into building resilient multi-agent systems and explains why the future of enterprise AI depends not just on smarter agents, but on the connections between them.

You often see teams deploy AI agents for customer service or IT support. These isolated agents create chaos in enterprise environments. Fragmented systems and data silos limit access to important information. High integration and maintenance costs drain resources. Manual interventions become necessary when disconnected agents cannot automate end-to-end workflows. Logic apps solve these challenges. You use logic apps to STOP BUILDING SILOED AGENTS and create a unified architecture. Logic apps orchestrate workflows, connect agents, and enable event-driven processes. Logic apps provide visibility, explainability, and built-in governance, making your operations efficient and scalable.

Key Takeaways

Stop building siloed agents. Focus on creating a unified architecture that enhances collaboration across your organization.
Recognize the limitations of local optimization. Ensure that every agent aligns with your broader business goals to avoid fragmented systems.
Avoid operational debt. Each new agent adds maintenance costs. Streamline your processes to reduce manual interventions and improve efficiency.
Implement orchestration with Logic Apps. This centralizes control, allowing agents to work together seamlessly and manage complex workflows.
Adopt event-driven architecture. This approach enables your agents to respond instantly to changes, improving responsiveness and scalability.
Utilize connectors as neural pathways. They link Logic Apps to various systems, ensuring smooth data flow and reducing manual tasks.
Embrace stateful workflows. They allow agents to remember past actions, enhancing continuity and reliability in long-running processes.
Prioritize security and compliance. Use strong authentication methods and monitor your systems to protect sensitive data and maintain trust.

Stop Building Siloed Agents

The Chatbot Mirage

You might feel excited when your team builds a new chatbot or AI agent. The demo works. The agent answers questions and solves problems. This success can make you believe that more agents will bring more value. However, you soon realize that these agents only solve local problems. They do not help your entire organization work better together.

Local vs Enterprise Optimization

When you focus on local wins, you miss the bigger picture. Each department creates its own agent to handle specific tasks. These agents do not share information or coordinate with each other. You end up with many small solutions that do not add up to a strong enterprise system. If you want to stop building siloed agents, you must think about how every agent fits into your larger business goals.

Operational Debt

Every new agent adds to your workload. You must maintain, update, and support each one. Over time, this creates operational debt. You spend more time fixing problems and less time improving your business. If you do not stop building siloed agents, you will face growing costs and more manual work.

Architectural Weaknesses

Demo Success vs Scale Failure

A chatbot may work well in a demo, but things change when you try to scale. You might see one agent succeed, but dozens of agents can create chaos. Without a plan to stop building siloed agents, you face broken workflows, lost data, and frustrated users. You need a strong architecture to support growth.

The Point-to-Point Trap

Many teams connect agents directly to APIs, databases, or SaaS platforms. This approach seems simple at first, but it quickly becomes a problem as you add more agents.

Integration Sprawl

The average enterprise now uses 110 SaaS applications, compared to just 8 in 2015.
Employees spend about 36% of their workday switching between apps and searching for information in disconnected systems.

When you do not stop building siloed agents, you create a web of point-to-point connections. This leads to integration sprawl. Your systems become harder to manage and your users waste time.

Credential Proliferation

Each direct connection needs its own credentials. As you add more agents, you must manage more passwords and secrets. This increases your security risks and makes it harder to keep your systems safe. If you want to stop building siloed agents, you need a better way to handle identity and access.

Tip: Focus on building a unified architecture. This will help you stop building siloed agents and reduce complexity across your organization.

Why Agents Fail at Scale

Reasoning vs Orchestration

You may think that smart agents can solve every problem. In reality, reasoning alone does not guarantee success. Agents need orchestration to work together and manage complex tasks. When you deploy agents without orchestration, you face several challenges:

Governance and observability become difficult.
Integration with legacy systems slows progress.
Teams must supervise autonomous systems and manage risks.
Without standardized platforms, your projects stay stuck in pilot mode.

Transitioning from legacy mainframes to cloud-native microservices, or merging massive databases, often amplifies data problems. Deploying AI does not clean up these issues; it usually makes them worse.

You must treat agents as production systems from the start. This approach ensures reliability, security, and lifecycle management.

Stateless vs Stateful Workflows

Stateless workflows treat each interaction as independent. You use them for simple tasks like generating a response or running a quick API call. Stateful workflows allow agents to remember context and handle multi-step reasoning. This difference shapes how agents perform in real-world environments.

Aspect	Stateless Workflows	Stateful Workflows
Scalability	Achieves 99.9% linear scaling efficiency.	Limited scalability due to session information.
Cost	Cost-efficient; best for budget scenarios.	2-3x more expensive due to memory and session management.
Performance	Faster per request (50-150ms).	Slower per request (150-500ms) due to context management.
User Experience	Worse for multi-turn conversations and complex workflows.	Superior for multi-turn conversations and advanced tasks.
Use Cases	Translation, API queries, simple classifications.	Customer service, sales, healthcare, multi-step processes.

Process Persistence

You need process persistence for tasks that last longer than a single interaction. Stateless agents cannot remember previous steps. Stateful workflows maintain context and allow agents to resume tasks after interruptions. This capability is essential for onboarding, approvals, and other long-running processes.

Workflow Recovery

Workflow recovery helps you avoid losing progress when something goes wrong. Stateful workflows can checkpoint and restore tasks. You gain reliability and continuity, even when agents face errors or interruptions.

Governance and Observability

You cannot govern what you cannot observe. Without ecosystem-wide observability and decision traces, you cannot answer questions like "Why did the agent do that?" Audit, forensics, and trust become impossible. You must pair observability with strong governance to ensure reliability and traceability.

Untraceable Actions

When agents operate without observability, risks remain invisible until incidents occur. You need to capture decision history, contextual inputs, workflow interactions, and system logs over time. This practice supports accountability and compliance.

Fragmented Error Handling

Fragmented error handling makes oversight difficult. You must review, document, and act on signals proactively. Observability surfaces signals such as decision traces and tool usage. Governance ensures these signals lead to improvements and prevent risks from becoming incidents.

Observability is a governance requirement for agent-driven systems. The EU AI Act mandates traceability, technical documentation, human oversight, and logging of system activity. You must build these capabilities into your agent ecosystem to scale successfully.

Logic Apps as the Nervous System

Imagine your organization as a living body. Each AI agent acts like a muscle or an organ, performing a specific function. However, without a central nervous system, these parts cannot work together. Logic Apps serve as the central nervous system for your enterprise AI. They coordinate actions, transmit signals, and ensure every agent and system responds at the right time.

Orchestration Layer

You need more than smart agents to achieve real business results. Logic Apps provide an orchestration layer that connects agents, people, and systems. This layer acts as the command center, guiding each agent through complex workflows. You can design workflows that:

Trigger agents based on business events.
Route tasks to the right person or system.
Combine human decisions with automated actions.
Monitor every step for reliability and compliance.

When you use Logic Apps, you can connect agents to enterprise systems like SAP or Salesforce. You can also use conditional logic and parallel execution to handle multiple tasks at once. This orchestration layer helps you avoid common mistakes, such as unnecessary complexity or ignoring latency. You can optimize costs by choosing the right models for each task and ensure observability by monitoring every agent.

Tip: Identify where human input is needed in your workflows. Design your orchestration to include these checkpoints for better results.

Effective orchestration strategies include:

Agent Loop: Let workflows think and act in cycles until they reach a goal.
Integration with Enterprise Systems: Use connectors to link agents with business platforms.
Support for Human and Autonomous Execution: Blend automation with human oversight.

Event-Driven Architecture

You want your agent ecosystem to be responsive and scalable. Event-driven architecture makes this possible. In this model, agents and workflows react to events instead of waiting for scheduled tasks. For example, a new customer record or a file upload can trigger an entire process.

Event-driven architecture separates agent management from execution. Message queues handle traffic spikes, so your system stays stable even during busy times. Listeners activate agents only when new data arrives, which reduces idle costs and improves speed. Event Grid lets agents respond to events from many sources, making your system more flexible.

Agents can react instantly to business changes.
You can process information as soon as it appears.
Loose coupling between workflows increases scalability.

You gain a system that grows with your needs and adapts to new challenges. Event-driven architecture turns your Logic Apps into the central nervous system that keeps every part of your organization in sync.

Connectors as Neural Pathways

Connectors act like the nerves in your central nervous system. They link Logic Apps to hundreds of external systems, making sure information flows smoothly between agents and business platforms. You can use connectors to pull in data, automate tasks, and reduce manual work.

Microsoft 365 Integration

You can connect Logic Apps to Microsoft 365 tools like Teams, Outlook, SharePoint, and OneDrive. This integration allows agents to:

Access emails, calendars, and files.
Automate meeting scheduling and notifications.
Update documents and share information across teams.

With these connectors, you reduce context switching. Agents can pull in customer details, project updates, or shipment statuses directly into their workspace. You streamline repetitive tasks, such as routing conversations or sending alerts, without leaving the Microsoft 365 environment.

Custom APIs

Sometimes, you need to connect to systems that do not have prebuilt connectors. Logic Apps let you build custom APIs as neural pathways. You can:

Integrate with third-party tools like CRM, TMS, or project management platforms.
Automate actions such as creating tickets, updating statuses, or logging emails.
Apply smart rules to route tasks or respond to specific business events.

“Connectors have had a significant impact on our operations because we can now access all the information we need without ever leaving our inbox. Plus, smart rules allow us to identify potentially harmful emails and quarantine them based on alerts in our fraud detection software. This helps us verify and prevent spoofing or fraud attempts before our carrier sales team even sees them.” — Brandon Bay, EVP, Logistics Group International

Prebuilt and low-code connectors make it easy for you to enhance productivity. You can automate workflows, reduce errors, and improve efficiency across your organization.

Key benefits of using connectors:

Integrate external data from multiple systems in one place.
Automate repetitive tasks and reduce manual effort.
Simplify integration with prebuilt and low-code solutions.

Logic Apps, as the central nervous system, use connectors to ensure every agent and system communicates effectively. You gain a unified, event-driven architecture that supports growth, agility, and innovation.

Building Agent Ecosystems

Agent Loop Action

You can build smarter agents by using the Agent Loop. This approach helps agents learn and adapt over time. The Agent Loop works in three main steps:

Reasoning (Think): The agent looks at its goal and the current situation. It decides what to do next.
Action (Act): The agent uses Logic Apps' connectors to carry out the chosen action.
Reflection (Learn): The agent checks the results and updates its understanding for the future.

The Agent Loop repeats these steps in cycles. This lets your agents improve with each round. They learn from their actions and adjust their strategies based on what happens. You get agents that do not just follow rules—they get better at their jobs over time.

Multi-Agent Collaboration

You need agents that can work together, not just alone. Multi-agent collaboration lets you solve bigger problems by dividing tasks among specialized agents. For example, in a smart healthcare system, one agent can monitor patient data while another manages appointments. This teamwork ensures accuracy and continuity.

To make collaboration work, you should focus on these key areas:

Agent Orchestration: Manage how agents start, stop, and hand off tasks.
Common Communication Protocol: Use a standard way for agents to talk to each other.
Reasoning and Planning Engine: Break down big goals into smaller tasks and assign them to the right agents.
Knowledge and Memory Management: Let agents share data so they do not repeat work.
Security and Trust Framework: Make sure only trusted agents can access sensitive data.
Human-Agent Teaming Interface: Allow people to monitor and guide agent activities.

You can set up your platform so each agent has its own tools and permissions. This makes it easy to add new agents or change their roles. You do not need to be an engineer to configure these systems, which helps your whole team get involved.

Cross-Tenant Coordination

You may need agents to work across different Microsoft 365 tenants, especially in large organizations or after mergers. Cross-tenant coordination helps you keep security and scalability strong.

Aspect	Description
Cross-Tenant Operational Standardization	You use API-driven normalization to keep investigations consistent across all tenants. This builds a unified model that adapts to each client’s needs.
Acceleration of Detection and Response	You collect evidence and validate threats quickly. This lets you act fast and limit the time attackers spend in your system.
Closed-Loop Learning and Continuous Improvement	You use feedback loops to improve detection and risk models for each tenant. This keeps your system accurate without sharing sensitive data between tenants.

Identity and Security

You must protect your data when agents work across tenants. Use strong authentication and authorization methods. This ensures only approved agents can access the right resources.

Managed Identities

Managed identities help you avoid password sprawl. You do not need to store or rotate secrets. Logic Apps can use managed identities to connect securely to resources in any tenant.

Workload Federation

Workload federation lets agents authenticate without secrets. You use federated credentials and token exchange to build trust between tenants. This supports zero trust security and makes your agent ecosystem safer and easier to manage.

Tip: Build your agent ecosystem with these practices to ensure security, scalability, and continuous improvement.

Stateful Workflows and Memory

Stateful workflows give your agents the ability to remember past actions and keep track of ongoing tasks. You gain a system that adapts, learns, and maintains continuity across sessions. This approach helps you manage complex, long-running processes that require persistent memory and coordination.

Checkpointing and Persistence

Checkpointing lets your workflow pause and resume without losing progress. You set safe boundaries where the system saves its state. If an error or crash happens, your workflow can restart from the last checkpoint instead of starting over.

Checkpoints store results in memory for quick access or in a database for long-term durability.
You preserve successful steps even if other parts fail, which improves recovery efficiency.
You ensure that agents can resume tasks after interruptions, maintaining reliability.

When you use checkpointing, you reduce the risk of losing important data. Your agents can handle tasks that last hours, days, or even weeks. This makes your workflows resilient and dependable.

Approval Handling

Automated workflows often need human approval. You must design approval steps that are clear, secure, and easy to manage. Best practices include:

Ask only for the data you need, then collect missing information in chat.
Keep approvals in-thread with fallback paths and clear owners.
Separate knowledge automation from change actions.
Tag automated finishes for honest reporting.
Review one dashboard weekly and improve the slowest step.
Use least-privilege roles and keep sensitive flows private.
Publish short rules so requesters know what to expect.

You build trust and transparency by following these practices. Your approval process stays organized, and you avoid confusion or delays. You also protect sensitive information by limiting access and keeping flows private.

Recovery and Coordination

Recovery and coordination ensure that your workflows continue smoothly, even when agents fail or tasks get interrupted. You use monitoring to detect errors and orchestrators to manage recovery.

Detection: Monitoring notices when an agent stops or an error occurs.
Isolation: The orchestrator marks the task as failed and checks the last checkpoint.
State Preservation: Results from previous steps are safely stored.
Recovery Action: The orchestrator restarts the agent or assigns a new one, using saved context.
Resume Workflow: The new agent continues from the last checkpoint, and other agents wait for results.

You maintain continuity and avoid losing progress. Your system adapts to failures by recovering quickly and coordinating tasks among agents. This approach keeps your workflows efficient and reliable.

Stateful workflows and memory transform your agent ecosystem. You gain personalized responses, manage complex tasks, and coordinate multiple agents. Your system learns from experience, maintains persistent identity, and delivers consistent results across long-running processes.

Best Practices for Agent Integration

Custom Connectors

You often need to connect your agents to systems that do not have ready-made connectors. Custom connectors give you the flexibility to build these links yourself. They help you solve unique integration challenges and make sure your agents work with any system your business uses.

Here are some reasons why custom connectors matter:

Tailored Integration Solutions: You can design connectors that fit your exact needs. This ensures your agents work smoothly with your existing tools and data.
Enhanced Functionality and Flexibility: Custom connectors let you create advanced workflows and map data in ways that standard connectors cannot. You get more control over how information moves between systems.
Competitive Advantage: By using custom connectors, you reduce manual work and speed up your processes. This leads to better productivity and a stronger customer experience.

Tip: Start by identifying which systems need custom connectors. Build and test these connectors to make sure they meet your business goals.

Logic-in-API Contracts

You need clear rules for how your agents share data and complete tasks. Logic-in-API contracts set these rules. They define what information goes into each step (StepInput) and what comes out (StepOutput). This makes your workflows predictable and easy to manage.

Logic-in-API contracts act as formal agreements between different parts of your workflow. Each agent knows exactly what to expect. This reduces confusion and mistakes. When you use these contracts, you make your agent ecosystem more reliable. You also make it easier to update or add new agents in the future.

Note: Standardizing your data flow with logic-in-API contracts helps you avoid errors and keeps your workflows consistent, even as your system grows.

Security and Compliance

Protecting sensitive data is a top priority when you integrate agents. You must follow strong security and compliance practices to keep your information safe.

Encryption Standards: Use TLS 1.3 for secure communication and AES-256 for storing data. This keeps your information safe from unauthorized access.
Identity and Access Management: Apply OAuth2 or OpenID Connect for authentication. Use Role-Based Access Control (RBAC) to limit who can see or change sensitive data.
Monitoring and Response: Connect your agent workflows to a Security Information and Event Management (SIEM) system. This helps you spot and respond to threats quickly.
Regulatory Compliance: Make sure your integrations follow laws like GDPR and HIPAA. Start with compliance in mind to avoid problems later.

Always review your security settings and update them as threats change. Keeping your agent integrations secure protects your business and builds trust with your users.

Error Handling Intelligence

You need strong error handling to keep your agent integrations reliable and safe. Intelligent error handling does more than just catch mistakes. It helps you find problems early, fix them quickly, and learn from every failure. You build trust in your system when you can explain what went wrong and how you solved it.

Start by using a unified observability platform. Tools like Datadog, Dynatrace, or New Relic let you monitor all your agents and workflows in one place. You can see logs, traces, and alerts from every part of your system. This makes it easier to spot issues before they become big problems.

Specialized monitoring tools help you track how your AI agents behave. Platforms like LangSmith let you trace, debug, and evaluate agent interactions. You can see each step an agent takes and understand why it made certain choices. This level of detail helps you improve agent performance and fix errors faster.

Structured logging is another key practice. You should log every important action in a consistent format. Use unique trace IDs for each request. This lets you follow a problem from start to finish, even if it moves across different systems. Clear logs make it easier to find the root cause of an error.

Set up health checks and alerts for your most important workflows. Automated health checks test if your agents and connectors are working as expected. If something fails, alerts notify you right away. You can respond quickly and keep your business running smoothly.

Tip: Review your error logs and alerts regularly. Look for patterns and recurring issues. Use these insights to improve your workflows and prevent future problems.

You also need to plan for changes in your agents and connected systems. AI models and APIs change over time. A new version might break an old integration or change how data is handled. To manage this, use version pinning to lock your agents and APIs to known-good versions. Monitor for updates and test changes in a safe environment before rolling them out. Staged rollouts and adapter patterns help you adjust to new versions without breaking your workflows.

By following these practices, you create an agent ecosystem that can handle errors intelligently. You gain resilience, faster recovery, and a system that learns from every failure. This approach keeps your integrations strong, even as your business grows and changes.

Getting Started with Logic Apps

Quick Wins

You can start using Logic Apps quickly, even if you have never built a workflow before. Logic Apps gives you a simple way to automate tasks and connect your systems. You do not need to write code to get results. Here is a step-by-step guide to help you begin:

Open the Azure Portal and sign in with your Azure credentials.
Search for "Logic App" in the portal and select it.
Choose the plan that fits your needs. If you are new, the Consumption Plan works best for simple projects.
Set up your Logic App by picking a Resource Group, giving it a name, choosing a Region, and deploying it.
Build your first workflow by picking a trigger. For example, you can set it to send a daily email or start when a file is uploaded.

Tip: Start with a small workflow, such as sending yourself a daily summary email. This helps you learn how triggers and actions work together.

You can see results right away. Logic Apps lets you connect to many services, like Microsoft 365, Outlook, or SharePoint. You can also add more actions to your workflow as you get comfortable. Each step you take builds your skills and shows you the power of automation.

Resources and Roadmap

As you grow your Logic Apps skills, you will want to scale your solutions and manage more complex workflows. Microsoft provides many resources to help you along the way. The table below highlights some key tools and features you can use:

Resource	Description
Azure Logic Apps	Orchestrate workflows and multi-agent business processes at Azure scale, enabling intelligent, goal-driven processes.
Power Automate migration to Azure Logic Apps (Standard)	Offers scalability for large workflows with high throughput and low latency, along with performance optimization features.
Azure Logic Apps	Provides out-of-the-box connectors and the ability to create custom connectors, facilitating seamless automation across teams.
Azure Logic Apps	Features a visual workflow designer and organizational templates for faster workflow creation and governance.

You can use the visual designer to build workflows without writing code. Templates help you start faster and follow best practices. Out-of-the-box connectors let you automate tasks across your favorite apps. If you need more, you can create custom connectors for your unique business needs.

Note: As you move from simple workflows to enterprise-scale solutions, review the available resources and plan your roadmap. This helps you build a strong, scalable automation platform for your organization.

You move from siloed agents to orchestrated ecosystems and gain stronger enterprise AI outcomes. Fragmented systems increase costs and cause agents to forget prior interactions. Centralized operations enhance collaboration and improve decision-making. A unified framework for governance boosts efficiency and reduces duplicated efforts. Logic Apps act as your nervous system, connecting agents and workflows. Start integrating your agents and explore event-driven architecture. For next steps, review Microsoft’s documentation and try building a simple workflow to see the benefits firsthand.

FAQ

What are agents in Logic Apps, and why do they matter?

Agents act as digital workers in your workflows. You use agents to automate tasks, connect systems, and manage data. Agents help you build scalable architecture and improve efficiency. You can coordinate agents for real-time communication and adaptive workflows.

How do Logic Apps support real-time event-driven design?

Logic Apps use event-driven design to trigger workflows instantly. You can set up event-driven agents that respond to changes in data or systems. This approach gives you real-time updates and lets you automate processes without delays.

Can I build multi-agent systems for complex workflows?

Yes, you can create multi-agent systems with Logic Apps. You assign each agent a role in your architecture. Agents share context and work together to complete tasks. This setup boosts scalability and supports autonomous operations.

How do I ensure data interoperability and seamless integration?

You connect agents to different platforms using Logic Apps connectors. This ensures data interoperability and seamless integration. You can move data between systems, maintain context, and keep workflows running smoothly.

What is the best way to test your AI solution in Logic Apps?

You should test your AI solution by running sample workflows. Check how agents handle context and real-time events. Review logs for errors. Refine agent instructions to improve results. Testing helps you build reliable and scalable architecture.

How do I create a standard edition logic app for AI agents?

You start in the Azure portal. Choose to create a standard edition logic app. Add your agents and set up workflows. Use connectors for event-driven agents and real-time triggers. This method supports multi-agent systems and improves scalability.

What makes no-code AI agent development possible in Logic Apps?

Logic Apps offer a visual designer. You drag and drop actions to build workflows for your AI agent. You do not need to write code. This no-code AI agent approach lets you focus on architecture, context, and event-driven design.

How do I manage context and memory in adaptive workflows?

You use stateful workflows to store context. Agents remember past actions and share information. This helps you coordinate multi-agent systems and maintain real-time operations. Adaptive workflows adjust to changes and keep your architecture flexible.

Tip: Always review your workflows for context sharing and real-time triggers. This practice ensures your agents work together and your architecture stays strong.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

1
00:00:00,000 --> 00:00:04,680
The flow is not the agent, it is the assumption that agents can manage their own integrations.

2
00:00:04,680 --> 00:00:09,200
Most organizations deploying co-pilots and custom bots in 2026 are building the same mistake

3
00:00:09,200 --> 00:00:11,760
they made with point-to-point APIs a decade ago.

4
00:00:11,760 --> 00:00:16,400
They are creating direct connections, scattering credentials across systems, maintaining no central

5
00:00:16,400 --> 00:00:19,600
state, and enforcing zero-cross-tenant governance.

6
00:00:19,600 --> 00:00:24,120
What actually works is the opposite, agents should reason, but they should not execute alone.

7
00:00:24,120 --> 00:00:27,440
If you are listening to this, you probably already have multiple co-pilots running inside

8
00:00:27,440 --> 00:00:29,440
your Microsoft 365 tenant.

9
00:00:29,440 --> 00:00:33,720
Maybe you have a team's bot for IT support, a co-pilot studio agent for customer service,

10
00:00:33,720 --> 00:00:37,640
and a handful of power-automate flows, handling notifications and approvals.

11
00:00:37,640 --> 00:00:39,360
Each one was built by a different team.

12
00:00:39,360 --> 00:00:42,720
Each one solved a local problem, and each one probably impressed the room when it was

13
00:00:42,720 --> 00:00:43,720
demoed.

14
00:00:43,720 --> 00:00:45,440
But here is the question nobody asks in those demos.

15
00:00:45,440 --> 00:00:50,120
They ask what happens when ten of these bots need to coordinate the same end-to-end

16
00:00:50,120 --> 00:00:51,120
process.

17
00:00:51,120 --> 00:00:55,600
They do not ask what happens when an employee onboarding workflow starts in one system, waits

18
00:00:55,600 --> 00:00:59,920
for an approval in another, provisions resources in a third tenant, and then checks back after

19
00:00:59,920 --> 00:01:00,920
30 days.

20
00:01:00,920 --> 00:01:01,920
That is not a conversation.

21
00:01:01,920 --> 00:01:06,160
That is a long-running business process that crosses boundaries, survives failures, and

22
00:01:06,160 --> 00:01:07,720
remembers what it was doing.

23
00:01:07,720 --> 00:01:09,640
And no chatbot can handle that alone.

24
00:01:09,640 --> 00:01:12,640
The research on Enterprise AI in 2026 is clear.

25
00:01:12,640 --> 00:01:16,520
The sophistication of the underlying large language model matters less than the environment

26
00:01:16,520 --> 00:01:18,160
in which the agent acts.

27
00:01:18,160 --> 00:01:20,560
You can have the best reasoning engine in the world.

28
00:01:20,560 --> 00:01:25,520
But if it is wired directly to a dozen APIs, with its own credentials, its own error handling,

29
00:01:25,520 --> 00:01:28,640
its own business logic, then it is not an Enterprise agent.

30
00:01:28,640 --> 00:01:32,160
It is a script with a nice interface, and scripts do not scale.

31
00:01:32,160 --> 00:01:35,520
The chatbot mirage, when demos become liabilities.

32
00:01:35,520 --> 00:01:37,520
Every organization starts in the same place.

33
00:01:37,520 --> 00:01:38,840
A department builds a bot.

34
00:01:38,840 --> 00:01:42,920
The bot answers questions from a SharePoint site or pulls records from Dataverse.

35
00:01:42,920 --> 00:01:44,400
It works in a 30 minute demo.

36
00:01:44,400 --> 00:01:46,360
People applaud, the project gets budget.

37
00:01:46,360 --> 00:01:50,320
And then another department builds another bot for a different use case, connecting to

38
00:01:50,320 --> 00:01:53,160
a different set of systems with a different set of credentials.

39
00:01:53,160 --> 00:01:57,560
This is exactly how co-pilot studio and power platform are designed to be consumed.

40
00:01:57,560 --> 00:02:01,400
Citizen developers and business analysts can spin up conversational agents without writing

41
00:02:01,400 --> 00:02:02,400
code.

42
00:02:02,400 --> 00:02:05,640
They can add knowledge sources, define tools, and set triggers.

43
00:02:05,640 --> 00:02:09,000
So the agent runs autonomously when an email arrives or a ticket is created.

44
00:02:09,000 --> 00:02:11,520
The tutorial videos make it look effortless.

45
00:02:11,520 --> 00:02:14,360
And for a single use case inside a single tenant, it mostly is.

46
00:02:14,360 --> 00:02:16,560
The problem begins when you multiply this pattern.

47
00:02:16,560 --> 00:02:20,280
The IT support bot connects directly to Microsoft Graph to read group memberships.

48
00:02:20,280 --> 00:02:24,360
The sales notification flow calls Dynamics 365 with stored credentials.

49
00:02:24,360 --> 00:02:28,640
The customer service agent writes tickets to service now using a separate integration.

50
00:02:28,640 --> 00:02:30,360
None of these bots know about each other.

51
00:02:30,360 --> 00:02:31,880
None of them share state.

52
00:02:31,880 --> 00:02:37,280
And if the CRM API changes or the organization moves to a new incident management platform,

53
00:02:37,280 --> 00:02:39,920
every dependent bot must be updated individually.

54
00:02:39,920 --> 00:02:42,960
In many cases, the original developers have moved on.

55
00:02:42,960 --> 00:02:46,760
The integration code is buried inside prompts, tool definitions, and connection strings

56
00:02:46,760 --> 00:02:48,920
that nobody has fully inventoryed.

57
00:02:48,920 --> 00:02:52,160
The intelligence teams discover they cannot answer basic questions about which agents can

58
00:02:52,160 --> 00:02:55,760
read HR data or send emails on behalf of users.

59
00:02:55,760 --> 00:02:59,520
Compliance auditors look for a central log of cross tenant actions and find nothing because

60
00:02:59,520 --> 00:03:01,640
each bot logs to its own silo.

61
00:03:01,640 --> 00:03:03,120
This is the chatbot mirage.

62
00:03:03,120 --> 00:03:05,480
It is local intelligence without global coherence.

63
00:03:05,480 --> 00:03:07,800
It is impressive demos that mask systemic fragility.

64
00:03:07,800 --> 00:03:08,800
The bots are not bad.

65
00:03:08,800 --> 00:03:10,880
The architecture underneath them is.

66
00:03:10,880 --> 00:03:12,200
Point to point poison.

67
00:03:12,200 --> 00:03:13,640
The integration trap.

68
00:03:13,640 --> 00:03:16,160
Here is the number that should terrify every architect.

69
00:03:16,160 --> 00:03:19,780
The number of connections in a point to point integration model grows with the product of

70
00:03:19,780 --> 00:03:21,200
agents and systems.

71
00:03:21,200 --> 00:03:24,840
Three agents talking to five systems is not 15 manageable connections.

72
00:03:24,840 --> 00:03:30,720
It is 15 separate implementations of authentication, retry logic, business rules, and error handling.

73
00:03:30,720 --> 00:03:35,320
At a fourth agent and the problem does not grow linearly, it multiplies.

74
00:03:35,320 --> 00:03:37,160
Change becomes expensive and risky.

75
00:03:37,160 --> 00:03:41,280
When a critical business rule changes, every automation and agent that encodes that rule

76
00:03:41,280 --> 00:03:44,440
must be located, updated, tested, and redeployed.

77
00:03:44,440 --> 00:03:48,400
Some will be found quickly, others will be forgotten until they break in production.

78
00:03:48,400 --> 00:03:52,280
During transitions, some agents may use the old system while others use the new one, leading

79
00:03:52,280 --> 00:03:56,160
to inconsistent data, duplicate records, and customer facing errors.

80
00:03:56,160 --> 00:03:58,320
Security and compliance controls are decentralized.

81
00:03:58,320 --> 00:04:02,080
Multiple app registrations, secrets, and keys proliferate each with its own permission set

82
00:04:02,080 --> 00:04:03,480
and life cycle.

83
00:04:03,480 --> 00:04:07,160
Security teams struggle to maintain least privilege access because each bot was configured

84
00:04:07,160 --> 00:04:11,360
by a different person with a different understanding of what the bot actually needs.

85
00:04:11,360 --> 00:04:15,560
Troubleshooting reviews become a paper exercise, revoking access for one agent might inadvertently

86
00:04:15,560 --> 00:04:19,640
affect others if they share a credential, or it might be overlooked entirely if the inventory

87
00:04:19,640 --> 00:04:21,200
is incomplete.

88
00:04:21,200 --> 00:04:22,440
Observability is fragmented.

89
00:04:22,440 --> 00:04:26,120
When something goes wrong, there is no central place to see the chain of actions across

90
00:04:26,120 --> 00:04:28,120
different agents and tenants.

91
00:04:28,120 --> 00:04:32,000
Troubleshooting requires spelunking through logs in many different services, correlating

92
00:04:32,000 --> 00:04:36,120
timestamps across disconnected systems, and hoping someone remembers how a specific

93
00:04:36,120 --> 00:04:39,480
bot was wired together six months ago.

94
00:04:39,480 --> 00:04:42,600
Despite the point integrations also struggle with long running processes.

95
00:04:42,600 --> 00:04:47,280
A bot that tries to handle an employee onboarding workflow on its own must implement its own

96
00:04:47,280 --> 00:04:51,400
persistence, correlation IDs, timers, and retry logic.

97
00:04:51,400 --> 00:04:54,240
It must remember where it was when a server restarts.

98
00:04:54,240 --> 00:04:58,200
It must handle the case where an approval takes three days instead of three minutes.

99
00:04:58,200 --> 00:04:59,880
Most bots do not implement this well.

100
00:04:59,880 --> 00:05:01,160
Some do not implement it at all.

101
00:05:01,160 --> 00:05:05,120
They assume the process is a single conversation, and that assumption is broken.

102
00:05:05,120 --> 00:05:06,640
The cross-tenant nightmare.

103
00:05:06,640 --> 00:05:10,840
Most of this chaos happens inside one tenant, but many real organizations operate more than

104
00:05:10,840 --> 00:05:11,840
one.

105
00:05:11,840 --> 00:05:15,160
Mergers and acquisitions leave you with multiple entry directories.

106
00:05:15,160 --> 00:05:18,960
Regional sovereignty requirements force data into separate tenants.

107
00:05:18,960 --> 00:05:21,720
Subcigaries and joint ventures need controlled collaboration.

108
00:05:21,720 --> 00:05:25,800
Partner organizations want to share processes without sharing credentials.

109
00:05:25,800 --> 00:05:29,600
Traditional integration approaches assume a single tenant architecture where all resources

110
00:05:29,600 --> 00:05:32,080
live under one identity authority.

111
00:05:32,080 --> 00:05:34,480
Cross-tenant scenarios break that assumption immediately.

112
00:05:34,480 --> 00:05:38,600
A service principle in one tenant cannot simply call an API in another.

113
00:05:38,600 --> 00:05:42,080
Tokens must be obtained for resources in different directories.

114
00:05:42,080 --> 00:05:44,960
Administrators must coordinate permission grants while maintaining security policies

115
00:05:44,960 --> 00:05:46,600
that may conflict.

116
00:05:46,600 --> 00:05:49,280
Microsoft Entra does provide cross-tenant collaboration features.

117
00:05:49,280 --> 00:05:53,640
B2B guest accounts let users from one tenant access resources in another.

118
00:05:53,640 --> 00:05:57,560
Multitenant applications can be registered in one tenant and granted permission in others,

119
00:05:57,560 --> 00:05:59,720
subject to an admin consent process.

120
00:05:59,720 --> 00:06:03,600
These mechanisms work for human users and carefully designed applications, but they

121
00:06:03,600 --> 00:06:09,440
were not built for dozens of autonomous agents making unattended API calls across boundaries

122
00:06:09,440 --> 00:06:10,840
at machine speed.

123
00:06:10,840 --> 00:06:15,200
An orchestration approach that does not explicitly address cross-tenant identity and authorization

124
00:06:15,200 --> 00:06:17,800
will run into friction at the first serious deployment.

125
00:06:17,800 --> 00:06:19,160
The bot works in the demo tenant.

126
00:06:19,160 --> 00:06:23,120
It fails in production because the managed identity cannot be assigned directly to another

127
00:06:23,120 --> 00:06:24,120
tenant.

128
00:06:24,120 --> 00:06:26,560
The developer switches to a client secret as a workaround.

129
00:06:26,560 --> 00:06:27,880
That secret gets rotated.

130
00:06:27,880 --> 00:06:31,360
The bot breaks it two in the morning and nobody can figure out why because the error is

131
00:06:31,360 --> 00:06:34,840
buried inside a prompt response instead of a centralized workflow log.

132
00:06:34,840 --> 00:06:36,360
This is not a corner case.

133
00:06:36,360 --> 00:06:41,120
For organizations that have invested heavily in Microsoft 365 and Power Platform, multi-tenant

134
00:06:41,120 --> 00:06:46,160
reality is the default and most agent architectures ignore it until it is too late to why agents

135
00:06:46,160 --> 00:06:48,240
need memory, the stateful gap.

136
00:06:48,240 --> 00:06:51,400
There is a fundamental distinction that most bot builders miss.

137
00:06:51,400 --> 00:06:55,960
Stateless automations execute quickly in response to a single event and they do not maintain

138
00:06:55,960 --> 00:06:58,280
long term state beyond basic logging.

139
00:06:58,280 --> 00:07:02,880
A power automate flow that sends an email whenever a sharepoint item is created is stateless.

140
00:07:02,880 --> 00:07:03,880
Each run is independent.

141
00:07:03,880 --> 00:07:05,720
It starts at acts it finishes.

142
00:07:05,720 --> 00:07:10,240
If the server restarts mid run, the flow might fail but it does not need to resume from

143
00:07:10,240 --> 00:07:11,400
where it left off.

144
00:07:11,400 --> 00:07:12,960
Stateful orchestrations are different.

145
00:07:12,960 --> 00:07:15,640
They maintain a notion of process state over time.

146
00:07:15,640 --> 00:07:17,320
They handle multi-step interactions.

147
00:07:17,320 --> 00:07:21,120
They pause for hours or days and employee onboarding workflow that starts when an offer

148
00:07:21,120 --> 00:07:22,120
is accepted.

149
00:07:22,120 --> 00:07:26,480
Then waits for various approvals, triggers provisioning, sends welcome communications

150
00:07:26,480 --> 00:07:29,680
and checks back after 30 days is inherently stateful.

151
00:07:29,680 --> 00:07:30,880
It must remember where it is.

152
00:07:30,880 --> 00:07:32,240
It must survive restarts.

153
00:07:32,240 --> 00:07:35,600
It must handle partial failures without starting over from the beginning.

154
00:07:35,600 --> 00:07:37,280
Copilot Studio handles reasoning.

155
00:07:37,280 --> 00:07:41,600
It interprets user intent, plans multi-step actions and interacts conversationally.

156
00:07:41,600 --> 00:07:43,520
But it was not designed to be a workflow engine.

157
00:07:43,520 --> 00:07:46,320
It does not persist state across long running processes.

158
00:07:46,320 --> 00:07:51,640
It does not manage correlations, timeouts, compensating actions or cross tenant handoffs.

159
00:07:51,640 --> 00:07:56,080
Logic apps, by contrast, was built for exactly this kind of business process orchestration.

160
00:07:56,080 --> 00:08:00,880
It can pause and resume workflows, persist state to Azure storage, recover from failures

161
00:08:00,880 --> 00:08:03,120
and interleave human and machine steps.

162
00:08:03,120 --> 00:08:07,440
The research on a genetic workflow patterns in 2026 converges on a simple truth.

163
00:08:07,440 --> 00:08:09,680
Copilot Studio should handle the reasoning layer.

164
00:08:09,680 --> 00:08:12,640
Azure Logic apps should handle the execution and integration layer.

165
00:08:12,640 --> 00:08:16,120
When you try to make Copilot Studio do both, you end up with a reasoning engine that is

166
00:08:16,120 --> 00:08:20,520
also responsible for persistence, retry, logic and cross system coordination.

167
00:08:20,520 --> 00:08:22,000
That is not a good division of labor.

168
00:08:22,000 --> 00:08:24,840
It is like asking your brain to also pump your blood.

169
00:08:24,840 --> 00:08:26,520
The nervous system exists for a reason.

170
00:08:26,520 --> 00:08:30,240
This is the stateful gap and it is the single biggest reason why autonomous agents fail

171
00:08:30,240 --> 00:08:31,640
at enterprise scale.

172
00:08:31,640 --> 00:08:35,760
They can think, but they cannot remember, they can act, but they cannot coordinate.

173
00:08:35,760 --> 00:08:39,360
And without a stateful orchestration layer between the agent and the enterprise, every

174
00:08:39,360 --> 00:08:43,240
long running process is a liability waiting to happen.

175
00:08:43,240 --> 00:08:48,040
The nervous system, how logic apps changes everything, so the model is broken.

176
00:08:48,040 --> 00:08:51,840
But the fix is not another platform and it is not a bigger, large language model.

177
00:08:51,840 --> 00:08:56,280
The fix is architecture, specifically it is treating your agents like muscles that connect

178
00:08:56,280 --> 00:09:00,120
to a central nervous system instead of brains that connect to everything directly.

179
00:09:00,120 --> 00:09:04,440
In a human body, muscles do not contain their own intelligence about when to contract

180
00:09:04,440 --> 00:09:06,800
or how to coordinate with other muscles.

181
00:09:06,800 --> 00:09:10,800
The nervous system handles perception, decision-routing and action coordination.

182
00:09:10,800 --> 00:09:13,240
The muscles execute, the nervous system governs.

183
00:09:13,240 --> 00:09:16,880
And if you sever the connection, the muscle may still have potential energy, but it cannot

184
00:09:16,880 --> 00:09:18,040
act in a coordinated way.

185
00:09:18,040 --> 00:09:20,400
Your organization is full of muscles right now.

186
00:09:20,400 --> 00:09:24,600
Pilots and outlook, bots and teams, flows in power automate, custom agents built on Azure

187
00:09:24,600 --> 00:09:25,600
OpenAI.

188
00:09:25,600 --> 00:09:27,120
Each one has local capability.

189
00:09:27,120 --> 00:09:31,120
But none of them are connected to a central nervous system that coordinates what they do

190
00:09:31,120 --> 00:09:34,960
when they do it and how they hand off to each other across tenant boundaries.

191
00:09:34,960 --> 00:09:39,240
As your logic apps can function as that nervous system, it is a workflow engine built for declarative

192
00:09:39,240 --> 00:09:44,400
orchestration with deep connectors into Microsoft 365, Dynamics, Dataverse, Azure Services

193
00:09:44,400 --> 00:09:46,600
and hundreds of third party APIs.

194
00:09:46,600 --> 00:09:49,920
It can host stateful orchestrations that span multiple systems and tenants.

195
00:09:49,920 --> 00:09:53,840
It can be triggered by events from agents, encode the authoritative business process and

196
00:09:53,840 --> 00:09:56,520
call back out to agents or human users as needed.

197
00:09:56,520 --> 00:10:00,920
When identity is handled via managed identities and workload identity federation, this orchestration

198
00:10:00,920 --> 00:10:05,400
layer can operate securely at scale without spreading secrets and static credentials across

199
00:10:05,400 --> 00:10:07,560
every bot in your environment.

200
00:10:07,560 --> 00:10:09,160
The key shift is this.

201
00:10:09,160 --> 00:10:12,440
Agents should call the orchestrator, not the backend systems directly.

202
00:10:12,440 --> 00:10:17,640
The orchestrator exposes well-defined operations that represent business-level capabilities.

203
00:10:17,640 --> 00:10:21,600
It crossed tenant onboarding for candidate X, Openers severity one incident.

204
00:10:21,600 --> 00:10:23,200
Start a partner data sharing workflow.

205
00:10:23,200 --> 00:10:27,160
The agent does not need to know which Azure subscriptions or graph endpoints are used, which

206
00:10:27,160 --> 00:10:30,320
tenants must be contacted or which approvals are required.

207
00:10:30,320 --> 00:10:31,760
It simply calls the orchestrator.

208
00:10:31,760 --> 00:10:35,640
The orchestrator maintains the canonical process definition, the state, the error handling

209
00:10:35,640 --> 00:10:37,040
and the audit trail.

210
00:10:37,040 --> 00:10:41,680
This separation of concerns allows agents to focus on interpreting user intent and interacting

211
00:10:41,680 --> 00:10:46,760
conversationally, while the orchestrator focuses on reliable, policy compliant execution

212
00:10:46,760 --> 00:10:48,440
across systems and tenants.

213
00:10:48,440 --> 00:10:52,480
It mirrors established software architecture patterns like facades, anti-corruption layers

214
00:10:52,480 --> 00:10:54,240
and saga orchestrators.

215
00:10:54,240 --> 00:10:59,040
And for organizations already invested in Microsoft 365 and Azure, Logic Apps is the most

216
00:10:59,040 --> 00:11:01,480
natural candidate to implement it.

217
00:11:01,480 --> 00:11:03,520
Standard versus consumption, choose wisely.

218
00:11:03,520 --> 00:11:06,080
But not every Logic App deployment can pull this off.

219
00:11:06,080 --> 00:11:08,840
There is a choice you have to make first and most people make it wrong.

220
00:11:08,840 --> 00:11:11,400
Azure Logic Apps offers two principle hosting models.

221
00:11:11,400 --> 00:11:15,200
The consumption model runs multi-tenant Logic Apps in a shared environment and charges

222
00:11:15,200 --> 00:11:16,880
based on actions executed.

223
00:11:16,880 --> 00:11:20,680
It is easy to start with, especially for smaller workloads or sporadic automations.

224
00:11:20,680 --> 00:11:24,280
The portal experience is friendly and you can build a working flow in minutes.

225
00:11:24,280 --> 00:11:27,320
For many citizen developers, consumption feels like the obvious path.

226
00:11:27,320 --> 00:11:32,000
The standard model hosts Logic Apps in single tenant infrastructure based on Azure functions.

227
00:11:32,000 --> 00:11:36,160
It supports improved performance, virtual network integration, custom connectors and

228
00:11:36,160 --> 00:11:39,480
the ability to organize multiple workflows into a single app.

229
00:11:39,480 --> 00:11:43,760
It also integrates with Azure DevOps, GitHub and Infrastructure as code tools.

230
00:11:43,760 --> 00:11:47,160
Workflows are stored as JSON definitions that can be version controlled,

231
00:11:47,160 --> 00:11:49,840
dived, reviewed and deployed through pipelines.

232
00:11:49,840 --> 00:11:52,960
For autonomous agent orchestration, consumption is a liability.

233
00:11:52,960 --> 00:11:57,240
It supports only stateful workflows, which is good, but it has concurrency limits and less

234
00:11:57,240 --> 00:11:59,320
control over the underlying compute.

235
00:11:59,320 --> 00:12:02,880
Its environment and data loss prevention model can become complex at scale.

236
00:12:02,880 --> 00:12:07,480
And its lifecycle management and DevOps integration, while improved over time, are not as deep as

237
00:12:07,480 --> 00:12:10,320
Logic Apps standard with code first workflows.

238
00:12:10,320 --> 00:12:12,720
Standard is the only serious option for a nervous system.

239
00:12:12,720 --> 00:12:17,120
It gives you the compute isolation, networking controls and deployment trigger that enterprise

240
00:12:17,120 --> 00:12:18,360
orchestration demands.

241
00:12:18,360 --> 00:12:22,720
It lets you run stateful and stateless workflows side by side in the same logic app resource,

242
00:12:22,720 --> 00:12:26,920
which matters when you need fast synchronous responses for some operations and durable long-running

243
00:12:26,920 --> 00:12:28,640
processes for others.

244
00:12:28,640 --> 00:12:32,400
And it positions you for the agent loop action and other AI integrated capabilities that

245
00:12:32,400 --> 00:12:35,600
Microsoft is delivering primarily through the standard runtime.

246
00:12:35,600 --> 00:12:39,720
The research on Logic Apps, standard versus consumption for orchestration workloads in

247
00:12:39,720 --> 00:12:41,480
2026 is consistent.

248
00:12:41,480 --> 00:12:45,840
If you are building a mission critical integration backbone that will coordinate agent behavior

249
00:12:45,840 --> 00:12:50,160
across business units and tenants, you need the control that standard provides.

250
00:12:50,160 --> 00:12:53,960
Consumption is fine for personal productivity flows and departmental automations.

251
00:12:53,960 --> 00:12:58,720
It is not fine for the central nervous system of your enterprise AI architecture.

252
00:12:58,720 --> 00:13:01,040
Stateful workflows, the agent's memory.

253
00:13:01,040 --> 00:13:04,760
Once you are on standard, the first capability you need to understand is state.

254
00:13:04,760 --> 00:13:08,440
And this is where Logic Apps separates itself from every other automation tool in the Microsoft

255
00:13:08,440 --> 00:13:09,440
stack.

256
00:13:09,440 --> 00:13:13,320
Stateful workflows persist their state to external storage at multiple checkpoints throughout

257
00:13:13,320 --> 00:13:14,320
a run.

258
00:13:14,320 --> 00:13:16,320
Every action, every decision, every weight state is recorded.

259
00:13:16,320 --> 00:13:20,360
If the runtime restarts, the workflow resumes from its last checkpoint instead of starting

260
00:13:20,360 --> 00:13:21,360
over.

261
00:13:21,360 --> 00:13:25,360
If an action fails, you can inspect exactly what the inputs and outputs were at that specific

262
00:13:25,360 --> 00:13:26,360
step.

263
00:13:26,360 --> 00:13:30,400
If an approval takes three days, the workflow sleeps efficiently, consuming minimal resources

264
00:13:30,400 --> 00:13:34,000
while it waits and wakes up precisely when the response arrives.

265
00:13:34,000 --> 00:13:37,720
This persistence is not just a reliability feature, it is a memory feature.

266
00:13:37,720 --> 00:13:41,040
And memory is what turns a reactive bot into a proactive agent.

267
00:13:41,040 --> 00:13:45,600
An agent that initiates a cross-tenant onboarding process needs to remember that it is waiting

268
00:13:45,600 --> 00:13:49,200
for a background check in one tenant and a manager approval in another.

269
00:13:49,200 --> 00:13:52,600
It needs to know that step three cannot begin until step two completes.

270
00:13:52,600 --> 00:13:56,080
And it needs to handle the case where step two fails with a specific error code that means

271
00:13:56,080 --> 00:13:58,280
the target system is down for maintenance.

272
00:13:58,280 --> 00:14:02,800
In 2024, Microsoft introduced the agent loop action in Logic Apps standard.

273
00:14:02,800 --> 00:14:06,160
This is a first-class workflow action that hosts the agent's reasoning loop driven by

274
00:14:06,160 --> 00:14:07,400
a large language model.

275
00:14:07,400 --> 00:14:10,960
It exposes tools via Logic Apps connectors and custom APIs.

276
00:14:10,960 --> 00:14:14,720
And it maintains memory and state across iterations within the workflow run.

277
00:14:14,720 --> 00:14:19,640
The agent thinks about its goal, acts by invoking a tool, learns from the result, and then thinks

278
00:14:19,640 --> 00:14:20,640
again.

279
00:14:20,640 --> 00:14:24,240
This think-act learn cycle is embedded directly in the workflow engine, not bolted on top

280
00:14:24,240 --> 00:14:25,240
of it.

281
00:14:25,240 --> 00:14:29,280
The difference between a bot that forgets an agent that persists intent is the difference

282
00:14:29,280 --> 00:14:34,440
between a conversation that starts fresh every time and a process that survives interruptions,

283
00:14:34,440 --> 00:14:39,640
from partial results, and continues toward a goal across hours or days.

284
00:14:39,640 --> 00:14:43,880
Stateful workflows give agents that persistence, and without it, you do not have autonomous

285
00:14:43,880 --> 00:14:44,880
agents.

286
00:14:44,880 --> 00:14:47,800
You have stateless scripts that pretend to be intelligent.

287
00:14:47,800 --> 00:14:52,160
Connectors as neural pathways memory means nothing if the agent cannot reach the muscles.

288
00:14:52,160 --> 00:14:56,120
In the nervous system metaphor, the connectors are the neural pathways that carry signals

289
00:14:56,120 --> 00:14:59,520
from the orchestrator to the systems that do the actual work.

290
00:14:59,520 --> 00:15:04,160
Logic Apps ships with hundreds of built-in connectors for the Microsoft ecosystem, SharePoint,

291
00:15:04,160 --> 00:15:11,960
OneDrive, Outlook, Teams, Dynamics 365, Power BI, Dataverse, Azure Service Bus, Event Grid,

292
00:15:11,960 --> 00:15:13,720
Key Vault, Storage.

293
00:15:13,720 --> 00:15:19,000
These connectors encapsulate authentication, endpoint details, and API semantics into actions

294
00:15:19,000 --> 00:15:21,400
that appear in the workflow designer.

295
00:15:21,400 --> 00:15:26,080
When a Logic app uses a connector, it configures a connection that can be based on a managed identity

296
00:15:26,080 --> 00:15:32,120
or secure secret stored in Key Vault rather than on user credentials or hard-coded strings.

297
00:15:32,120 --> 00:15:36,860
For systems without ready-made connectors, Logic Apps can call HTTP-based APIs using the

298
00:15:36,860 --> 00:15:38,560
built-in HTTP action.

299
00:15:38,560 --> 00:15:42,460
But the more robust pattern for enterprise orchestration is the custom connector.

300
00:15:42,460 --> 00:15:46,920
Custom connectors allow developers to describe an API using Open API or other metadata, and

301
00:15:46,920 --> 00:15:51,680
Logic Apps then exposes it in the designer like any other first-class component.

302
00:15:51,680 --> 00:15:55,880
This is particularly useful for internal APIs, legacy systems, and proprietary enterprise

303
00:15:55,880 --> 00:15:59,960
logic that needs to be surfaced to agents in a controlled, governed way.

304
00:15:59,960 --> 00:16:04,160
In a nervous system architecture, connectors and custom connectors become the nerves through

305
00:16:04,160 --> 00:16:06,480
which the orchestrator reaches muscles and sensors.

306
00:16:06,480 --> 00:16:09,600
Agents do not need to know how to call these connectors directly.

307
00:16:09,600 --> 00:16:13,120
They simply request that the orchestrator perform certain actions.

308
00:16:13,120 --> 00:16:17,640
The orchestrator manages the connection, the authentication, the retry logic, and the error

309
00:16:17,640 --> 00:16:18,640
handling.

310
00:16:18,640 --> 00:16:22,800
This division of labor makes it easier to update integrations as APIs change, and it

311
00:16:22,800 --> 00:16:27,880
allows security teams to centralize and scrutinize every connection that crosses a tenant boundary.

312
00:16:27,880 --> 00:16:33,240
By 2026, the dominant pattern for custom connectors is what architects call "logic in API."

313
00:16:33,240 --> 00:16:37,320
Proprietary enterprise logic, such as pricing engines, eligibility rules, and risk scoring

314
00:16:37,320 --> 00:16:40,800
is wrapped as secure lifecycle managed APIs with clear contracts.

315
00:16:40,800 --> 00:16:45,280
These APIs are then described with Open API specifications and published as custom connectors

316
00:16:45,280 --> 00:16:46,480
inside Logic Apps.

317
00:16:46,480 --> 00:16:51,320
The result is a standardized interface that any agent or workflow can call without understanding

318
00:16:51,320 --> 00:16:53,080
the underlying complexity.

319
00:16:53,080 --> 00:16:56,680
And when the business rule changes, you update the API and the connector, you do not update

320
00:16:56,680 --> 00:16:58,680
a dozen different bots.

321
00:16:58,680 --> 00:17:02,320
Orchestrator first architecture, which brings us to the pattern that makes all of this work.

322
00:17:02,320 --> 00:17:05,800
And it is the exact opposite of how most teams build agents today.

323
00:17:05,800 --> 00:17:10,400
The naive pattern is to give the large language model a set of tools that directly call external

324
00:17:10,400 --> 00:17:11,400
systems.

325
00:17:11,400 --> 00:17:15,760
The agency's functions for reading SharePoint, sending emails via graph, updating dataverse,

326
00:17:15,760 --> 00:17:17,400
and calling a custom API.

327
00:17:17,400 --> 00:17:21,280
It decides which to invoke, constructs the parameters, and executes the call.

328
00:17:21,280 --> 00:17:22,520
This works in small demos.

329
00:17:22,520 --> 00:17:26,360
It fails in production because the agent has direct access to low-level systems.

330
00:17:26,360 --> 00:17:31,200
It has no central place to enforce business rules, manage state or log actions for compliance.

331
00:17:31,200 --> 00:17:34,080
The robust pattern is orchestrator first tool calling.

332
00:17:34,080 --> 00:17:36,000
The agent sees a different set of tools.

333
00:17:36,000 --> 00:17:38,120
These tools do not call external systems directly.

334
00:17:38,120 --> 00:17:39,520
They call Logic Apps.

335
00:17:39,520 --> 00:17:44,560
Each tool maps to an HTTP triggered workflow that represents a business-level capability.

336
00:17:44,560 --> 00:17:47,800
Initiate cross-tenant onboarding, request-incident escalation.

337
00:17:47,800 --> 00:17:49,200
Start partner data sharing.

338
00:17:49,200 --> 00:17:52,880
When the agent calls such a tool, the Logic app receives the request and implements the

339
00:17:52,880 --> 00:17:54,160
full orchestration.

340
00:17:54,160 --> 00:17:56,040
It validates the request against policies.

341
00:17:56,040 --> 00:17:59,760
It calls Microsoft Graph or other APIs via managed identity.

342
00:17:59,760 --> 00:18:00,920
It waits for approvals.

343
00:18:00,920 --> 00:18:02,120
It handles errors.

344
00:18:02,120 --> 00:18:05,760
And it returns a structured response that the agent can use to inform its next reasoning

345
00:18:05,760 --> 00:18:06,760
step.

346
00:18:06,760 --> 00:18:08,080
This separation has several advantages.

347
00:18:08,080 --> 00:18:11,600
It constrains what the agent can do to actions that are explicitly designed and reviewed

348
00:18:11,600 --> 00:18:12,600
by humans.

349
00:18:12,600 --> 00:18:16,760
It centralizes process logic in Logic Apps where it can be versioned, tested, and governed

350
00:18:16,760 --> 00:18:18,600
through standard DevOps pipelines.

351
00:18:18,600 --> 00:18:23,000
It allows identity and permissions to be managed via managed identities and enter ID rather

352
00:18:23,000 --> 00:18:26,840
than via custom tokens buried inside the agent's prompt or configuration.

353
00:18:26,840 --> 00:18:29,280
It simplifies debugging and observability.

354
00:18:29,280 --> 00:18:33,680
Since each tool call corresponds to a well-defined Logic app run with full run history.

355
00:18:33,680 --> 00:18:38,240
For the M365FM audience, this pattern is the bridge between co-pilot studio and Azure.

356
00:18:38,240 --> 00:18:42,280
It lets you keep the conversational experiences and reasoning capabilities that co-pilot studio

357
00:18:42,280 --> 00:18:46,920
does well while moving execution, state management, and cross-tenant coordination into Logic

358
00:18:46,920 --> 00:18:48,520
Apps where they belong.

359
00:18:48,520 --> 00:18:49,520
Agents reason.

360
00:18:49,520 --> 00:18:50,520
Orchestrators execute.

361
00:18:50,520 --> 00:18:52,120
That is the architecture that scales.

362
00:18:52,120 --> 00:18:53,680
The identity problem.

363
00:18:53,680 --> 00:18:55,520
Where production implementations die.

364
00:18:55,520 --> 00:18:58,440
Now, everything we have covered so far is architecture.

365
00:18:58,440 --> 00:19:01,280
An architecture is easy to draw on a whiteboard.

366
00:19:01,280 --> 00:19:04,800
What actually breaks in production is not the workflow, it is the identity layer.

367
00:19:04,800 --> 00:19:08,600
And this is where most implementations die before they ever reach a second tenant.

368
00:19:08,600 --> 00:19:12,480
In Microsoft Entra ID, workloads authenticate using service principles.

369
00:19:12,480 --> 00:19:16,560
An application is registered, permissions are granted, and a service principle object

370
00:19:16,560 --> 00:19:18,920
represents that apps identity within a tenant.

371
00:19:18,920 --> 00:19:22,480
Traditional patterns rely on client secrets or certificates that the application uses to

372
00:19:22,480 --> 00:19:24,160
obtain tokens.

373
00:19:24,160 --> 00:19:26,720
Secrets must be stored, rotated, and protected.

374
00:19:26,720 --> 00:19:28,880
Certificates have life cycles that must be managed.

375
00:19:28,880 --> 00:19:33,280
And as the number of apps grows, the secret sprawl becomes a serious operational risk that

376
00:19:33,280 --> 00:19:34,720
security teams dread.

377
00:19:34,720 --> 00:19:37,160
To address this, Azure introduced managed identities.

378
00:19:37,160 --> 00:19:41,160
A managed identity is essentially an automatically managed service principle attached to an Azure

379
00:19:41,160 --> 00:19:45,040
resource such as a Logic app, Function app, or App Service.

380
00:19:45,040 --> 00:19:48,640
The platform handles the life cycle of the credentials, allowing the resource to obtain

381
00:19:48,640 --> 00:19:54,200
tokens for Azure services and Microsoft Graph without storing secrets in code or configuration.

382
00:19:54,200 --> 00:19:58,080
Managed identities can be system assigned tied to the life cycle of the resource or user

383
00:19:58,080 --> 00:20:02,400
assigned, which is a standalone identity that can be shared among multiple resources.

384
00:20:02,400 --> 00:20:04,440
This works beautifully inside one tenant.

385
00:20:04,440 --> 00:20:06,400
The Logic app has a managed identity.

386
00:20:06,400 --> 00:20:09,960
You grant that identity permission to read from SharePoint or write to Dataverse.

387
00:20:09,960 --> 00:20:12,800
The platform handles the token acquisition behind the scenes.

388
00:20:12,800 --> 00:20:14,520
There are no connection strings to leak.

389
00:20:14,520 --> 00:20:16,160
There are no secrets to rotate.

390
00:20:16,160 --> 00:20:20,160
And if the Logic app is deleted, the system assigned identity is automatically cleaned up.

391
00:20:20,160 --> 00:20:22,240
But Cross-Tenant is where this pattern hits a wall.

392
00:20:22,240 --> 00:20:26,480
You cannot assign a managed identity from tenant A directly to a resource in tenant B.

393
00:20:26,480 --> 00:20:28,160
The identity authorities are separate.

394
00:20:28,160 --> 00:20:29,800
The token endpoints are different.

395
00:20:29,800 --> 00:20:33,720
And the consent frameworks that work for human users do not translate cleanly to unattended

396
00:20:33,720 --> 00:20:35,720
workload authentication at scale.

397
00:20:35,720 --> 00:20:38,960
This is the exact moment where most teams give up and reach for a client secret.

398
00:20:38,960 --> 00:20:43,240
They create a service principle in the target tenant, generate a secret, and embed it

399
00:20:43,240 --> 00:20:46,800
somewhere in the agent's configuration or the workflows connection string.

400
00:20:46,800 --> 00:20:47,800
It works.

401
00:20:47,800 --> 00:20:51,520
It is also exactly the pattern that creates the security sprawl we are trying to escape.

402
00:20:51,520 --> 00:20:52,680
The secret expires.

403
00:20:52,680 --> 00:20:53,680
The bot breaks.

404
00:20:53,680 --> 00:20:57,760
Someone generates a new secret and updates it in a configuration file that nobody remembers

405
00:20:57,760 --> 00:20:58,760
to audit.

406
00:20:58,760 --> 00:21:02,080
And six months later, your compliance team finds an active credential that should have been

407
00:21:02,080 --> 00:21:03,080
revoked.

408
00:21:03,080 --> 00:21:05,560
The Cross-Tenant identity problem is not a footnote.

409
00:21:05,560 --> 00:21:09,800
It is the primary reason why multi-tenant agent orchestration fails in production and solving

410
00:21:09,800 --> 00:21:13,760
it requires a different approach to authentication entirely.

411
00:21:13,760 --> 00:21:15,280
Secretly authentication.

412
00:21:15,280 --> 00:21:17,560
Managed identities and workload Federation.

413
00:21:17,560 --> 00:21:19,360
The fix is not going back to secrets.

414
00:21:19,360 --> 00:21:21,560
It is going deeper into identity Federation.

415
00:21:21,560 --> 00:21:25,880
And by 2026, Microsoft has built the tooling to make this practical, managed identities

416
00:21:25,880 --> 00:21:27,400
remain the foundation.

417
00:21:27,400 --> 00:21:31,840
For resources inside a single tenant, they are the correct and only pattern you should use.

418
00:21:31,840 --> 00:21:35,120
But for Cross-Tenant scenarios, you need workload identity Federation.

419
00:21:35,120 --> 00:21:38,240
This is a pattern in which a workload running in one environment can authenticate to

420
00:21:38,240 --> 00:21:43,120
enter ID in another tenant without secrets by presenting a trusted token issued by its own

421
00:21:43,120 --> 00:21:44,440
identity provider.

422
00:21:44,440 --> 00:21:46,760
Here is how it works in practice for logic apps.

423
00:21:46,760 --> 00:21:51,040
You configure a trust relationship in the target tenant using the Azure AD token exchange

424
00:21:51,040 --> 00:21:52,040
mechanism.

425
00:21:52,040 --> 00:21:56,240
The source workload, which could be a logic app with a managed identity in tenant A, presents

426
00:21:56,240 --> 00:21:58,280
a token from its own identity platform.

427
00:21:58,280 --> 00:22:02,240
The target tenant validates that token based on the pre-configured Federation setup and

428
00:22:02,240 --> 00:22:07,800
issues an access token that the workload can use to call APIs in the target tenant.

429
00:22:07,800 --> 00:22:11,280
No client secret is ever created, stored or rotated.

430
00:22:11,280 --> 00:22:15,000
The trust is based on cryptographic verification, not shared passwords.

431
00:22:15,000 --> 00:22:19,280
Microsoft EntraAgentID extends this foundation with identity and security layers designed

432
00:22:19,280 --> 00:22:21,040
specifically for AI agents.

433
00:22:21,040 --> 00:22:25,400
It provides blueprints that describe an agent's permissions, behaviors, and identity model.

434
00:22:25,400 --> 00:22:29,640
It lets you define whether an agent should use a workload identity pattern or a user delegated

435
00:22:29,640 --> 00:22:30,640
pattern.

436
00:22:30,640 --> 00:22:33,920
And it governs how many agent identities exist per blueprint, allowing you to choose

437
00:22:33,920 --> 00:22:39,280
between one shared identity for a class of agents or many granular identities for individual

438
00:22:39,280 --> 00:22:40,800
agent instances.

439
00:22:40,800 --> 00:22:43,040
This matters enormously for orchestration.

440
00:22:43,040 --> 00:22:47,520
When an autonomous agent calls a logic app to initiate a cross tenant process, the call

441
00:22:47,520 --> 00:22:50,520
itself can be authenticated through agent ID.

442
00:22:50,520 --> 00:22:55,080
The orchestrator then uses its own managed identity or federated trust to execute actions

443
00:22:55,080 --> 00:22:56,560
in the target tenant.

444
00:22:56,560 --> 00:23:00,120
Every step of the chain is authenticated, authorised, and logged.

445
00:23:00,120 --> 00:23:03,520
There are no shared secrets buried in configuration files.

446
00:23:03,520 --> 00:23:07,160
There are no long-lived credentials that can be stolen or forgotten.

447
00:23:07,160 --> 00:23:10,040
The zero-trust posture this enables is straightforward.

448
00:23:10,040 --> 00:23:11,560
Verify explicitly.

449
00:23:11,560 --> 00:23:16,240
Every request is authenticated and authorised based on identity, device, location, risk,

450
00:23:16,240 --> 00:23:17,240
and policy.

451
00:23:17,240 --> 00:23:18,720
Use least-privileged access.

452
00:23:18,720 --> 00:23:22,560
Granular permissions and just enough access are enforced at every step.

453
00:23:22,560 --> 00:23:28,200
Assume breach, segment, monitor, and log everything, including cross tenant flows.

454
00:23:28,200 --> 00:23:31,680
Logic apps with managed identities and workload identity federations give you the technical

455
00:23:31,680 --> 00:23:35,640
primitives to implement these principles without inventing custom security code.

456
00:23:35,640 --> 00:23:38,440
This is secretless authentication at enterprise scale.

457
00:23:38,440 --> 00:23:42,520
And it is the only authentication model that makes autonomous agent orchestration viable

458
00:23:42,520 --> 00:23:44,400
across multiple tenants.

459
00:23:44,400 --> 00:23:48,720
Custom connectors, the contract layer, but identity only gets you through the door.

460
00:23:48,720 --> 00:23:53,200
What happens inside the room matters just as much, and inside the room agents need boundaries.

461
00:23:53,200 --> 00:23:57,440
They need contracts that tell them exactly what they can do and exactly how to do it.

462
00:23:57,440 --> 00:24:00,400
Without those contracts agents hallucinate capabilities.

463
00:24:00,400 --> 00:24:02,560
This is where custom connectors become critical.

464
00:24:02,560 --> 00:24:07,040
A custom connector is a packaged description of an API, most often using open API or

465
00:24:07,040 --> 00:24:11,680
swagger, plus authentication configuration, operation definitions, and schema mapping.

466
00:24:11,680 --> 00:24:15,600
It is surfaced as a first class component in the Logic Apps Designer, which means it appears

467
00:24:15,600 --> 00:24:18,440
alongside built-in connectors like SharePoint and Outlook.

468
00:24:18,440 --> 00:24:22,160
The workflow author selects it, configures the connection, and uses typed fields just

469
00:24:22,160 --> 00:24:23,960
like any other action.

470
00:24:23,960 --> 00:24:28,680
For proprietary enterprise logic, custom connectors are the contract layer that keeps agents

471
00:24:28,680 --> 00:24:30,000
from improvising.

472
00:24:30,000 --> 00:24:35,600
And an agent needs to calculate a price, check an eligibility rule, or score a risk profile.

473
00:24:35,600 --> 00:24:39,480
It should not be writing raw HTTP calls with handcrafted JSON payloads.

474
00:24:39,480 --> 00:24:43,560
It should be calling a custom connector that exposes a typed action named calculate price

475
00:24:43,560 --> 00:24:46,480
or check eligibility with defined inputs and outputs.

476
00:24:46,480 --> 00:24:48,680
The agent knows exactly what parameters to provide.

477
00:24:48,680 --> 00:24:51,640
The orchestrator knows exactly what responds to expect.

478
00:24:51,640 --> 00:24:55,120
And the security team knows exactly what business capability is being invoked.

479
00:24:55,120 --> 00:25:00,480
By 2026, the dominant pattern for exposing internal capabilities is logic in API.

480
00:25:00,480 --> 00:25:02,800
Domain critical logic lives in internal services.

481
00:25:02,800 --> 00:25:05,760
Those services are wrapped with open API specifications.

482
00:25:05,760 --> 00:25:09,800
The specifications are published as custom connectors inside Logic Apps, and the connectors

483
00:25:09,800 --> 00:25:13,800
are versioned, governed, and deployed through the same CI/CD pipelines that manage the rest

484
00:25:13,800 --> 00:25:14,960
of the infrastructure.

485
00:25:14,960 --> 00:25:17,000
This has a profound effect on agent behavior.

486
00:25:17,000 --> 00:25:21,240
When an agent's tools are well-defined custom connectors, it cannot hallucinate a capability

487
00:25:21,240 --> 00:25:22,240
that does not exist.

488
00:25:22,240 --> 00:25:25,880
It cannot call an endpoint that has not been reviewed and published.

489
00:25:25,880 --> 00:25:29,720
And it cannot bypass business rules by constructing its own raw API calls.

490
00:25:29,720 --> 00:25:33,240
The connector is the contract, the contract is the guardrail, and the guardrail is

491
00:25:33,240 --> 00:25:35,600
what makes autonomous agents safe at scale.

492
00:25:35,600 --> 00:25:37,320
Governance teams benefit, too.

493
00:25:37,320 --> 00:25:40,960
Instead of reviewing every prompt and every tool definition inside a dozen different

494
00:25:40,960 --> 00:25:44,240
bots, they review the open API contract once.

495
00:25:44,240 --> 00:25:47,520
They approve the operations, the scopes, and the data types.

496
00:25:47,520 --> 00:25:51,800
And every agent that uses that connector inherits those boundaries automatically.

497
00:25:51,800 --> 00:25:56,480
When the business rule changes, the API is updated, the connector is versioned, and every

498
00:25:56,480 --> 00:26:01,040
workflow that uses it gets the new behavior through standard deployment processes.

499
00:26:01,040 --> 00:26:02,760
Error handling as intelligence.

500
00:26:02,760 --> 00:26:05,360
And once the agent is inside and doing work, it will fail.

501
00:26:05,360 --> 00:26:06,520
This is not a possibility.

502
00:26:06,520 --> 00:26:07,520
It is a certainty.

503
00:26:07,520 --> 00:26:11,960
APIs go down, tokens expire mid-flight, rate limits kick in during peak hours, and data

504
00:26:11,960 --> 00:26:16,560
validation fails because a downstream system changed its schema without telling anyone.

505
00:26:16,560 --> 00:26:18,360
The question is not whether failures happen.

506
00:26:18,360 --> 00:26:21,680
The question is whether your architecture can handle them without human intervention every

507
00:26:21,680 --> 00:26:22,680
single time.

508
00:26:22,680 --> 00:26:27,040
Logic apps, standard provides the error handling primitives that make this possible.

509
00:26:27,040 --> 00:26:30,440
Scoped actions let you wrap a set of steps in a container that can succeed or fail as

510
00:26:30,440 --> 00:26:31,520
a unit.

511
00:26:31,520 --> 00:26:35,880
Configure run after settings, let you define alternative parts for success, failure, skipped

512
00:26:35,880 --> 00:26:37,680
actions, and timeouts.

513
00:26:37,680 --> 00:26:40,640
Do until loops with delays implement retries and back-off.

514
00:26:40,640 --> 00:26:46,120
And the term-lit action lets you end a workflow gracefully when an unrecoverable error is detected.

515
00:26:46,120 --> 00:26:50,120
But agentic workflows in 2026 go beyond these classic patterns.

516
00:26:50,120 --> 00:26:54,360
They use what architects call "Guarded Try Catch" where the AI agent itself participates

517
00:26:54,360 --> 00:26:55,560
in error triage.

518
00:26:55,560 --> 00:26:59,120
When a failure occurs, the orchestrator captures the error details and presents them to the

519
00:26:59,120 --> 00:27:00,440
agent's reasoning loop.

520
00:27:00,440 --> 00:27:02,360
The agent analyzes the error type.

521
00:27:02,360 --> 00:27:06,280
It decides whether this is a transient issue that warrants a retry, a permission failure

522
00:27:06,280 --> 00:27:11,000
that requires escalation to a human, or a data problem that needs a compensating action.

523
00:27:11,000 --> 00:27:13,400
It then instructs the orchestrator on the next step.

524
00:27:13,400 --> 00:27:15,280
This is self-healing workflow behavior.

525
00:27:15,280 --> 00:27:17,920
The agent loop action in logic apps.

526
00:27:17,920 --> 00:27:20,320
Standard maintains memory across these iterations.

527
00:27:20,320 --> 00:27:23,880
It remembers that step three failed with a rate limit error.

528
00:27:23,880 --> 00:27:28,040
It remembers that the system recommended waiting 60 seconds before retrying, and it remembers

529
00:27:28,040 --> 00:27:32,440
that the retry succeeded so the process can continue to step four without starting over

530
00:27:32,440 --> 00:27:33,920
from the beginning.

531
00:27:33,920 --> 00:27:35,400
Adaptive retry takes this further.

532
00:27:35,400 --> 00:27:39,640
Instead of static retry accounts with fixed delays, the orchestrator uses the error context

533
00:27:39,640 --> 00:27:41,800
to choose the right recovery strategy.

534
00:27:41,800 --> 00:27:45,880
A rate limit from Microsoft Graph probably means you should back off and retry with exponential

535
00:27:45,880 --> 00:27:46,880
delay.

536
00:27:46,880 --> 00:27:49,920
A permission denied error from a cross tenant call probably means the federation trust has

537
00:27:49,920 --> 00:27:52,200
expired and a human needs to reauthorize it.

538
00:27:52,200 --> 00:27:56,320
A schema validation error probably means the downstream system changed its contract and

539
00:27:56,320 --> 00:27:59,160
the integration team needs to update the custom connector.

540
00:27:59,160 --> 00:28:00,840
These are fundamentally different failures.

541
00:28:00,840 --> 00:28:02,640
They deserve fundamentally different responses.

542
00:28:02,640 --> 00:28:07,120
The difference between a fragile bot and a resilient agent is not the absence of errors.

543
00:28:07,120 --> 00:28:10,320
It is the architecture that surrounds the error when it happens.

544
00:28:10,320 --> 00:28:15,120
Several workflows with scoped error handling, adaptive retry and AI assisted triage turned

545
00:28:15,120 --> 00:28:18,400
failures from show stopping events into managed deviations.

546
00:28:18,400 --> 00:28:22,800
The process survives, the state persists, and the agent learns what to do differently next

547
00:28:22,800 --> 00:28:24,160
time.

548
00:28:24,160 --> 00:28:27,840
Governance from human in the loop to human on the loop, which brings us to the governance

549
00:28:27,840 --> 00:28:29,720
question that nobody wants to ask.

550
00:28:29,720 --> 00:28:34,360
If agents can reason, execute across tenants, handle errors and retry on their own, then

551
00:28:34,360 --> 00:28:36,640
the question is what exactly humans are for.

552
00:28:36,640 --> 00:28:39,160
And the answer depends entirely on what the agent is doing.

553
00:28:39,160 --> 00:28:43,800
In the loop means the agent stops and waits for explicit human approval before taking any

554
00:28:43,800 --> 00:28:46,240
action that crosses a risk threshold.

555
00:28:46,240 --> 00:28:50,120
Every email send, every data modification, every cross tenant provisioning action requires

556
00:28:50,120 --> 00:28:51,760
a human to click approve.

557
00:28:51,760 --> 00:28:52,760
This is safe.

558
00:28:52,760 --> 00:28:57,240
It is also slow and at scale it creates a bottleneck that defeats the purpose of automation.

559
00:28:57,240 --> 00:29:01,240
Human on the loop means the agent executes within predefined guardrails and humans review

560
00:29:01,240 --> 00:29:05,040
exceptions, patterns and outcomes rather than individual actions.

561
00:29:05,040 --> 00:29:08,840
The guardrails are enforced by the orchestrator not by the agent's good intentions.

562
00:29:08,840 --> 00:29:11,280
The orchestrator checks policy before executing.

563
00:29:11,280 --> 00:29:13,360
It logs every action with full context.

564
00:29:13,360 --> 00:29:17,320
It raises alerts when anomaly detection flags unusual behavior.

565
00:29:17,320 --> 00:29:21,760
And it escalates to humans only when the deviation falls outside the predefined boundaries.

566
00:29:21,760 --> 00:29:26,400
For routine operations like updating a customer record, sending a standard notification, or

567
00:29:26,400 --> 00:29:30,440
queering a nonsense of data set, human on the loop is the correct model.

568
00:29:30,440 --> 00:29:34,120
The orchestrator enforces the guardrails, the agent operates within them, and humans review

569
00:29:34,120 --> 00:29:37,480
dashboards and reports to ensure the system is behaving as expected.

570
00:29:37,480 --> 00:29:41,720
For high stakes transactions like financial transfers, personnel actions or cross tenant data sharing

571
00:29:41,720 --> 00:29:45,920
that involves regulated information, human in the loop may still be required.

572
00:29:45,920 --> 00:29:49,400
The orchestrator can root these actions through approval workflows automatically.

573
00:29:49,400 --> 00:29:54,120
It can present the human reviewer with the full context of what the agent is trying to do,

574
00:29:54,120 --> 00:29:56,560
why it is trying to do it, and what the consequences are.

575
00:29:56,560 --> 00:29:57,680
The human makes the decision.

576
00:29:57,680 --> 00:30:01,400
The orchestrator records the decision, and the agent continues or aborts based on that

577
00:30:01,400 --> 00:30:02,640
recorded outcome.

578
00:30:02,640 --> 00:30:07,280
Azure Logic Apps provides the run history and audit trails that make both models viable.

579
00:30:07,280 --> 00:30:11,200
The action is logged with inputs, outputs, time stamps and identity information.

580
00:30:11,200 --> 00:30:15,480
Tenant isolation policies can block or restrict shared connections across tenants, allowing

581
00:30:15,480 --> 00:30:17,920
only specific trusted tenants to be called.

582
00:30:17,920 --> 00:30:21,720
An entra workload identities with conditional access policies can detect anomalous sign-in

583
00:30:21,720 --> 00:30:25,560
behavior and block risky agent actions before they execute.

584
00:30:25,560 --> 00:30:28,880
Governance is not a separate layer that you add after the agents are built.

585
00:30:28,880 --> 00:30:31,320
It is a property of the orchestration architecture.

586
00:30:31,320 --> 00:30:35,520
And if your orchestrator cannot enforce guardrails, log actions and escalate exceptions, then

587
00:30:35,520 --> 00:30:36,960
you do not have governance.

588
00:30:36,960 --> 00:30:37,960
You have hope.

589
00:30:37,960 --> 00:30:39,160
A day in the life.

590
00:30:39,160 --> 00:30:41,080
How the nervous system actually runs.

591
00:30:41,080 --> 00:30:44,980
Let me walk you through a concrete scenario so you can see how this architecture behaves

592
00:30:44,980 --> 00:30:46,640
when everything is connected.

593
00:30:46,640 --> 00:30:49,680
Imagine a multinational company with three entrants.

594
00:30:49,680 --> 00:30:52,280
Tenant A is the corporate headquarters in Amsterdam.

595
00:30:52,280 --> 00:30:57,080
Tenant B is a regional subsidiary in Singapore that operates under local data residency requirements.

596
00:30:57,080 --> 00:31:01,200
Tenant C is a partner organization that provides specialized logistic services.

597
00:31:01,200 --> 00:31:05,480
An employee in Amsterdam initiates a request through a co-pilot studio agent embedded in teams.

598
00:31:05,480 --> 00:31:09,800
The employee says they need to onboard a new contractor who will work across all three entities.

599
00:31:09,800 --> 00:31:13,800
The co-pilot agent interprets the intent, extracts the contractor's details and calls

600
00:31:13,800 --> 00:31:16,560
a logic app in tenant A via an HTTP trigger.

601
00:31:16,560 --> 00:31:19,600
The call is authenticated using the agent's entra agent ID.

602
00:31:19,600 --> 00:31:23,400
The logic app in tenant A receives the request and starts a state full workflow.

603
00:31:23,400 --> 00:31:24,560
Step one is validation.

604
00:31:24,560 --> 00:31:28,840
It checks the contractor's details against corporate policy using a custom connector that talks

605
00:31:28,840 --> 00:31:30,880
to the internal HR policy engine.

606
00:31:30,880 --> 00:31:32,680
The connector returns a structured response.

607
00:31:32,680 --> 00:31:36,760
The contractor is cleared for basic onboarding but flagged for additional security review

608
00:31:36,760 --> 00:31:39,400
because the role involves cross tenant data access.

609
00:31:39,400 --> 00:31:40,480
Step two is rooting.

610
00:31:40,480 --> 00:31:43,360
The logic app branches based on the policy response.

611
00:31:43,360 --> 00:31:48,000
Because the contractor needs access to tenant B and tenant C, the orchestrator initiates parallel

612
00:31:48,000 --> 00:31:49,000
sub-work flows.

613
00:31:49,000 --> 00:31:53,080
The sub-work flow for tenant B uses workload identity federation to authenticate to the Singapore

614
00:31:53,080 --> 00:31:54,680
tenant's entra instance.

615
00:31:54,680 --> 00:31:59,240
It calls a separate logic app that lives in tenant B, passing the contractor details and

616
00:31:59,240 --> 00:32:00,240
the security flag.

617
00:32:00,240 --> 00:32:04,480
The tenant B logic app handles local provisioning according to Singapore's data residency rules.

618
00:32:04,480 --> 00:32:09,240
It provisions a local mailbox, assigns regional security groups and schedules a local compliance

619
00:32:09,240 --> 00:32:10,240
training session.

620
00:32:10,240 --> 00:32:14,680
Meanwhile, the sub-work flow for tenant C uses a different federation trust to reach the

621
00:32:14,680 --> 00:32:15,680
partner tenant.

622
00:32:15,680 --> 00:32:19,400
It calls a custom connector that exposes the partner's logistics onboarding API.

623
00:32:19,400 --> 00:32:23,160
The partner system confirms the contractor's eligibility and returns a temporary access

624
00:32:23,160 --> 00:32:25,360
token with a 30-day expiration.

625
00:32:25,360 --> 00:32:28,720
The orchestrator stores this token in Azure Key Vault and logs the grant in the central

626
00:32:28,720 --> 00:32:29,720
audit trail.

627
00:32:29,720 --> 00:32:31,280
Step three is waiting.

628
00:32:31,280 --> 00:32:33,240
The main workflow in tenant A pauses.

629
00:32:33,240 --> 00:32:35,480
It has initiated actions in two other tenants.

630
00:32:35,480 --> 00:32:39,480
It has recorded the pending security review flag and it now enters a wait state that can

631
00:32:39,480 --> 00:32:41,440
last up to 30 days.

632
00:32:41,440 --> 00:32:44,240
During this wait, the workflow consumes minimal resources.

633
00:32:44,240 --> 00:32:46,520
Its state is persisted to Azure storage.

634
00:32:46,520 --> 00:32:50,480
If the runtime restarts, the workflow resumes exactly where it left off.

635
00:32:50,480 --> 00:32:54,360
Ten days later, the security team in Amsterdam completes the enhanced review.

636
00:32:54,360 --> 00:32:57,880
They approve the contractor through a power app that writes an approval record to date

637
00:32:57,880 --> 00:32:58,880
of us.

638
00:32:58,880 --> 00:33:04,160
The app was configured with a dataverse trigger that watches for this specific approval status.

639
00:33:04,160 --> 00:33:07,880
When the record updates, the trigger fires and the workflow resumes from its wait state.

640
00:33:07,880 --> 00:33:09,160
Step four is completion.

641
00:33:09,160 --> 00:33:14,200
The workflow verifies that both tenant B and tenant C sub-work flows complete it successfully.

642
00:33:14,200 --> 00:33:16,800
It checks that the security approval is on file.

643
00:33:16,800 --> 00:33:20,520
It sends a welcome email to the contractor using a shared mailbox connector.

644
00:33:20,520 --> 00:33:23,640
It provisions the final corporate resources in tenant A.

645
00:33:23,640 --> 00:33:27,480
And it schedules a 30-day access review checkpoint by writing a follow-up task to a shared

646
00:33:27,480 --> 00:33:28,480
planner board.

647
00:33:28,480 --> 00:33:33,080
Throughout this entire process, no human manually coordinated the handoffs between tenants.

648
00:33:33,080 --> 00:33:35,840
No client secrets were exchanged across boundaries.

649
00:33:35,840 --> 00:33:38,480
No agent had direct access to every system.

650
00:33:38,480 --> 00:33:41,000
The co-pilot agent reasoned about the request.

651
00:33:41,000 --> 00:33:43,520
The logic apps orchestrated the process.

652
00:33:43,520 --> 00:33:46,480
The state was maintained across 10 days and 3 tenants.

653
00:33:46,480 --> 00:33:50,360
And every action was logged with the identity of the caller, the time, the inputs and the

654
00:33:50,360 --> 00:33:51,360
outputs.

655
00:33:51,360 --> 00:33:52,360
This is not science fiction.

656
00:33:52,360 --> 00:33:55,440
This is what the architecture delivers when you start building siloed agents and start

657
00:33:55,440 --> 00:33:57,120
building a nervous system.

658
00:33:57,120 --> 00:33:59,720
Now managed identity federation actually works.

659
00:33:59,720 --> 00:34:03,720
I want to go deeper on workload identity federation because this is the piece that most architects

660
00:34:03,720 --> 00:34:06,160
get wrong on their first attempt.

661
00:34:06,160 --> 00:34:08,680
And when they get it wrong, they revert to secrets.

662
00:34:08,680 --> 00:34:10,400
And secrets are the beginning of the end.

663
00:34:10,400 --> 00:34:12,880
Here is the actual pattern that works in 2026.

664
00:34:12,880 --> 00:34:17,360
In the source tenant, you have a logic app with a system assigned managed identity.

665
00:34:17,360 --> 00:34:20,200
That identity is registered as an application in EntryD.

666
00:34:20,200 --> 00:34:25,280
In the target tenant, you create a federated identity credential on that application registration.

667
00:34:25,280 --> 00:34:28,920
The federated credential trust tokens issued by a specific source, which in this case is

668
00:34:28,920 --> 00:34:32,960
the managed identity token endpoint from the source tenant's Azure infrastructure.

669
00:34:32,960 --> 00:34:37,560
When the logic app needs to call an API in the target tenant, it first requests a token

670
00:34:37,560 --> 00:34:41,200
for its own managed identity from the Azure Instance metadata service.

671
00:34:41,200 --> 00:34:44,480
That token is a standard JSON web token signed by the Azure platform.

672
00:34:44,480 --> 00:34:48,160
The logic app then presents this token to the target tenant's token endpoint, along with

673
00:34:48,160 --> 00:34:51,680
the application ID of the registered app and the requested resource scope.

674
00:34:51,680 --> 00:34:56,040
The target tenant verifies the token signature against the Azure platform's public keys.

675
00:34:56,040 --> 00:35:00,160
It checks that the issue matches the federated credential configured on the app registration.

676
00:35:00,160 --> 00:35:03,560
And if everything validates, it issues an access token for the target resource.

677
00:35:03,560 --> 00:35:07,840
The access token that the target tenant issues is scoped to the permissions that were granted

678
00:35:07,840 --> 00:35:09,400
during admin consent.

679
00:35:09,400 --> 00:35:13,360
If the app registration only has permission to read user profiles, that is all the access

680
00:35:13,360 --> 00:35:14,600
token can do.

681
00:35:14,600 --> 00:35:18,360
If it needs right access to SharePoint sites, that permission must be explicitly granted

682
00:35:18,360 --> 00:35:19,520
and consented.

683
00:35:19,520 --> 00:35:21,160
This is least privileged by design.

684
00:35:21,160 --> 00:35:23,800
Now here is the critical part that many teams miss.

685
00:35:23,800 --> 00:35:25,640
The federated credential is not a secret.

686
00:35:25,640 --> 00:35:27,040
It is a trust relationship.

687
00:35:27,040 --> 00:35:31,680
You configure it once through the Azure portal, ARM templates or Microsoft Graph API.

688
00:35:31,680 --> 00:35:35,400
It contains the issuer URL, the subject identifier and the audience.

689
00:35:35,400 --> 00:35:37,080
There is no password to rotate.

690
00:35:37,080 --> 00:35:38,880
There is no certificate to renew.

691
00:35:38,880 --> 00:35:42,840
And if the source managed identity is deleted, the federated credential becomes inert because

692
00:35:42,840 --> 00:35:44,600
the token requests stop.

693
00:35:44,600 --> 00:35:48,160
For multi tenant orchestration, you repeat this pattern for each target tenant that your

694
00:35:48,160 --> 00:35:49,800
orchestrator needs to reach.

695
00:35:49,800 --> 00:35:53,800
The logic app in tenant A might have three separate federated credentials configured, one for

696
00:35:53,800 --> 00:35:57,440
tenant B, one for tenant C and one for development environment.

697
00:35:57,440 --> 00:35:59,080
Each trust relationship is independent.

698
00:35:59,080 --> 00:36:01,240
Each can be revoked without affecting the others.

699
00:36:01,240 --> 00:36:05,480
And each is monitored through entro workload identities analytics, which can detect anomalous

700
00:36:05,480 --> 00:36:07,480
sign-in patterns and risky behavior.

701
00:36:07,480 --> 00:36:11,520
This pattern requires more setup than copying a client secret into a connection string.

702
00:36:11,520 --> 00:36:12,520
That is the point.

703
00:36:12,520 --> 00:36:13,840
The extra setup is the governance.

704
00:36:13,840 --> 00:36:17,520
Every trust relationship is explicit, documented and auditable.

705
00:36:17,520 --> 00:36:21,520
That is exactly what enterprise security teams need when they are asked to approve autonomous

706
00:36:21,520 --> 00:36:24,040
agents that operate across organizational boundaries.

707
00:36:24,040 --> 00:36:26,880
The agent loop action, what it is and why it matters.

708
00:36:26,880 --> 00:36:31,600
In 2024, Microsoft announced the agent loop action at build and by 2026 it has become

709
00:36:31,600 --> 00:36:35,680
the core primitive for agenteic decision modeling inside logic app standard.

710
00:36:35,680 --> 00:36:36,960
This is not a marketing feature.

711
00:36:36,960 --> 00:36:39,920
It is a fundamental change in what a workflow engine can do.

712
00:36:39,920 --> 00:36:44,080
The agent loop action is a first class workflow step that hosts an AI agent's reasoning loop

713
00:36:44,080 --> 00:36:46,520
directly inside the logic app's runtime.

714
00:36:46,520 --> 00:36:49,640
It connects to an Azure open AI deployment or another supported model.

715
00:36:49,640 --> 00:36:52,240
It exposes a set of tools that the model can call.

716
00:36:52,240 --> 00:36:56,720
And it manages the iterative cycle of reasoning, tool invocation and result evaluation within

717
00:36:56,720 --> 00:36:58,280
a single workflow run.

718
00:36:58,280 --> 00:37:01,040
Here is what happens when an agent loop action executes.

719
00:37:01,040 --> 00:37:04,040
The workflow starts the action with an initial prompt or goal.

720
00:37:04,040 --> 00:37:06,080
The action sends that goal to the language model.

721
00:37:06,080 --> 00:37:10,880
The model analyzes the goal, considers the available tools and decides what to do next.

722
00:37:10,880 --> 00:37:15,520
It might decide to query a database, call an API or ask a human for clarification.

723
00:37:15,520 --> 00:37:17,520
It returns a structured tool call request.

724
00:37:17,520 --> 00:37:21,880
The agent loop action receives the tool call request and roots it to the appropriate logic

725
00:37:21,880 --> 00:37:23,840
apps, connector or custom action.

726
00:37:23,840 --> 00:37:27,560
It executes the tool, it captures the result and it passes that result back to the language

727
00:37:27,560 --> 00:37:28,760
model as an observation.

728
00:37:28,760 --> 00:37:30,160
The model now has new information.

729
00:37:30,160 --> 00:37:34,000
The reasons again, it decides on the next step and the cycle continues until the goal is

730
00:37:34,000 --> 00:37:37,840
achieved, an error occurs or a maximum iteration limit is reached.

731
00:37:37,840 --> 00:37:41,320
What makes this powerful is that the loop maintains memory across iterations.

732
00:37:41,320 --> 00:37:45,320
The model sees the full conversation history of the loop, including every previous thought

733
00:37:45,320 --> 00:37:47,120
every tool call and every result.

734
00:37:47,120 --> 00:37:51,000
This means the agent can handle multi-step reasoning without losing context.

735
00:37:51,000 --> 00:37:54,760
It can recover from partial tool failures by trying alternative approaches.

736
00:37:54,760 --> 00:37:58,240
And it can explain its reasoning by referencing the sequence of actions it took.

737
00:37:58,240 --> 00:38:01,640
For the orchestrator first architecture we have been discussing, the agent loop action

738
00:38:01,640 --> 00:38:03,200
sits at the agent boundary.

739
00:38:03,200 --> 00:38:06,920
The co-pilot studio bot or external front end interprets the user's natural language

740
00:38:06,920 --> 00:38:09,480
request and translates it into a structured goal.

741
00:38:09,480 --> 00:38:12,240
It calls a logic app via HTTP trigger.

742
00:38:12,240 --> 00:38:16,480
The logic app executes the business process orchestration, which may include one or more

743
00:38:16,480 --> 00:38:19,400
agent loop actions for decisions that require reasoning.

744
00:38:19,400 --> 00:38:23,280
The agent loop handles the cognitive work, the surrounding workflow handles the execution,

745
00:38:23,280 --> 00:38:26,200
state, error handling and cross tenent coordination.

746
00:38:26,200 --> 00:38:30,280
This separation is clean, it is maintainable, and it is exactly what you need when your

747
00:38:30,280 --> 00:38:34,720
agent's reasoning capabilities will change every six months as new models are released.

748
00:38:34,720 --> 00:38:39,800
But your business process logic must remain stable and auditable for years.

749
00:38:39,800 --> 00:38:41,360
Building your first custom connector.

750
00:38:41,360 --> 00:38:42,360
Let me get practical.

751
00:38:42,360 --> 00:38:45,920
You have an internal API that calculates pricing for enterprise contracts.

752
00:38:45,920 --> 00:38:50,200
Right now your co-pilot agent is calling that API through a raw HTTP action with a handcrafted

753
00:38:50,200 --> 00:38:51,560
JSON payload.

754
00:38:51,560 --> 00:38:55,840
That works until the API changes its input format or until the citizen developer copies

755
00:38:55,840 --> 00:39:00,560
the HTTP call into another bot with slightly different parameters or until the security team

756
00:39:00,560 --> 00:39:04,960
asks for an inventory of every place that calls the pricing engine and you realize you

757
00:39:04,960 --> 00:39:06,440
do not have one.

758
00:39:06,440 --> 00:39:10,440
The fix is a custom connector and the process is simpler than most people assume.

759
00:39:10,440 --> 00:39:12,960
One is to document the API using open API.

760
00:39:12,960 --> 00:39:17,120
If your pricing API already has an open API specification, you are halfway done.

761
00:39:17,120 --> 00:39:18,800
If it does not, you create one.

762
00:39:18,800 --> 00:39:22,880
The specification describes the endpoint, the HTTP method, the authentication scheme,

763
00:39:22,880 --> 00:39:26,200
the input parameters with their data types and the response schema.

764
00:39:26,200 --> 00:39:30,400
For a pricing engine, the inputs might include custom material, product code, contracturation

765
00:39:30,400 --> 00:39:32,240
and discount eligibility flag.

766
00:39:32,240 --> 00:39:37,240
The response might include base price, applied discounts, final price, currency code and

767
00:39:37,240 --> 00:39:38,760
expiration timestamp.

768
00:39:38,760 --> 00:39:42,600
Step 2 is to create the custom connector in the Azure portal or power platform admin

769
00:39:42,600 --> 00:39:43,600
center.

770
00:39:43,600 --> 00:39:45,160
You import the open API specification.

771
00:39:45,160 --> 00:39:49,000
You configure the authentication, which for an internal API might be Microsoft, Android

772
00:39:49,000 --> 00:39:52,040
ID, OAuth or an API key stored in Azure Key Vault.

773
00:39:52,040 --> 00:39:55,320
The platform generates the connector definition and makes it available in the Logic Apps

774
00:39:55,320 --> 00:39:56,320
designer.

775
00:39:56,320 --> 00:39:57,920
Step 3 is to test.

776
00:39:57,920 --> 00:40:01,640
You create a test workflow that uses the custom connector to call the pricing API with

777
00:40:01,640 --> 00:40:02,880
sample data.

778
00:40:02,880 --> 00:40:06,080
You verify that the inputs appear as typed fields in the designer.

779
00:40:06,080 --> 00:40:11,040
You verify that the response fields are available for downstream actions and you verify that authentication

780
00:40:11,040 --> 00:40:13,880
works correctly with the chosen identity model.

781
00:40:13,880 --> 00:40:15,320
Step 4 is governance.

782
00:40:15,320 --> 00:40:18,560
You publish the connector to a specific environment or solution.

783
00:40:18,560 --> 00:40:22,880
You document what operations it exposes, what data it accesses and what permissions it

784
00:40:22,880 --> 00:40:23,880
requires.

785
00:40:23,880 --> 00:40:27,160
You add it to your connector catalog so other teams can discover it.

786
00:40:27,160 --> 00:40:31,480
And you set up CICD so that when the pricing API changes, the open API spec is updated,

787
00:40:31,480 --> 00:40:35,160
the connector is regenerated and the new version is deployed through a managed pipeline.

788
00:40:35,160 --> 00:40:38,280
Now when an agent needs a price, it does not make a raw HTTP call.

789
00:40:38,280 --> 00:40:40,480
It calls the enterprise pricing connector.

790
00:40:40,480 --> 00:40:43,280
The orchestrator knows exactly what capability is being invoked.

791
00:40:43,280 --> 00:40:47,280
The security team knows exactly which workflows have access to pricing data.

792
00:40:47,280 --> 00:40:51,680
And when the pricing engine adds a new parameter for carbon offset calculations, you update

793
00:40:51,680 --> 00:40:53,240
the connector once.

794
00:40:53,240 --> 00:40:56,360
Every workflow that uses it inherits the new field automatically.

795
00:40:56,360 --> 00:40:58,960
This is what Logic and API means in practice.

796
00:40:58,960 --> 00:41:01,760
Your proprietary business logic is wrapped in a contract.

797
00:41:01,760 --> 00:41:03,440
The contract is published as a connector.

798
00:41:03,440 --> 00:41:06,920
And the connector is the only thing agents are allowed to touch.

799
00:41:06,920 --> 00:41:08,520
Error routing patterns in detail.

800
00:41:08,520 --> 00:41:12,120
I want to spend more time on error handling because this is where beautiful architectures

801
00:41:12,120 --> 00:41:13,920
go to die in production.

802
00:41:13,920 --> 00:41:16,600
And I want to show you the specific patterns that prevent that death.

803
00:41:16,600 --> 00:41:18,840
The first pattern is the scope to try catch.

804
00:41:18,840 --> 00:41:22,600
In Logic App Standard, you wrap a set of related actions inside a scope block.

805
00:41:22,600 --> 00:41:26,880
You configure the scope with run after settings that define what happens when the scope

806
00:41:26,880 --> 00:41:30,280
succeeds, fails, is skipped or times out.

807
00:41:30,280 --> 00:41:32,680
Inside the scope you place the normal workflow path.

808
00:41:32,680 --> 00:41:35,240
Outside the scope you place the error handling path.

809
00:41:35,240 --> 00:41:38,840
When an action inside the scope fails, the scope itself is marked as failed.

810
00:41:38,840 --> 00:41:41,120
The run after trigger on the error path fires.

811
00:41:41,120 --> 00:41:44,760
The error path receives the failure details, including the action name, the error code,

812
00:41:44,760 --> 00:41:46,360
the error message and the status.

813
00:41:46,360 --> 00:41:48,080
It can then branch based on the error type.

814
00:41:48,080 --> 00:41:52,160
A 429 status code from Microsoft Graph means rate limiting.

815
00:41:52,160 --> 00:41:54,440
The error path waits 60 seconds in retries.

816
00:41:54,440 --> 00:41:58,600
A 401 status code means the federated credential has expired.

817
00:41:58,600 --> 00:42:02,640
The error path creates an escalation ticket in service now and terminates the workflow

818
00:42:02,640 --> 00:42:03,640
gracefully.

819
00:42:03,640 --> 00:42:07,680
A 500 status code from an internal API means the downstream system is down.

820
00:42:07,680 --> 00:42:12,280
The error path logs the incident, sends an alert to the operations team and enters a

821
00:42:12,280 --> 00:42:14,400
long wait state before retrying.

822
00:42:14,400 --> 00:42:17,200
The second pattern is the agent assisted error triage.

823
00:42:17,200 --> 00:42:22,320
When a scope fails inside an agent loop action, the orchestrator does not just retry blindly.

824
00:42:22,320 --> 00:42:24,640
It presents the error context to the language model.

825
00:42:24,640 --> 00:42:28,760
The model reads the error code, the message and the history of previous attempts.

826
00:42:28,760 --> 00:42:30,320
It classifies the failure.

827
00:42:30,320 --> 00:42:32,160
It proposes a recovery strategy.

828
00:42:32,160 --> 00:42:34,560
And the orchestrator executes that strategy.

829
00:42:34,560 --> 00:42:38,600
This is where the research on agentic error routing in 2026 gets interesting.

830
00:42:38,600 --> 00:42:41,760
The best implementations do not treat all failures the same.

831
00:42:41,760 --> 00:42:45,720
They categorize them into transient failures that warrant retry, permission failures that

832
00:42:45,720 --> 00:42:50,480
require human escalation, data failures that need compensating actions, and systemic failures

833
00:42:50,480 --> 00:42:52,920
that should abort the entire workflow.

834
00:42:52,920 --> 00:42:56,160
The classification is not hard coded in the workflow JSON.

835
00:42:56,160 --> 00:42:59,880
It is inferred by the agent based on the error context in the process history.

836
00:42:59,880 --> 00:43:02,480
The third pattern is the compensating action.

837
00:43:02,480 --> 00:43:06,360
In long running state full workflows, some steps cannot simply be retried.

838
00:43:06,360 --> 00:43:09,800
If a workflow already debited an account and then failed on the next step, retrying

839
00:43:09,800 --> 00:43:11,840
the debit would double charge the account.

840
00:43:11,840 --> 00:43:16,560
The compensating action reverses the debit before the workflow attempts the sequence again.

841
00:43:16,560 --> 00:43:20,400
Logic app state full workflow support this through carefully designed scope structures

842
00:43:20,400 --> 00:43:24,520
where each irreversible action is paired with a compensating action that runs only if the

843
00:43:24,520 --> 00:43:26,640
overall scope fails.

844
00:43:26,640 --> 00:43:31,040
These three patterns together, scoped error handling, agent assisted triage, and compensating

845
00:43:31,040 --> 00:43:34,960
actions are what separate a proof of concept from a production orchestration.

846
00:43:34,960 --> 00:43:36,040
They are not glamorous.

847
00:43:36,040 --> 00:43:39,960
They do not demo well, but they are the reason your agents keep running at 2 in the morning

848
00:43:39,960 --> 00:43:42,720
when the API you depend on goes down.

849
00:43:42,720 --> 00:43:43,960
Stateful versus stateless?

850
00:43:43,960 --> 00:43:45,200
When to use each?

851
00:43:45,200 --> 00:43:48,400
By now you are probably wondering whether every workflow in your nervous system needs

852
00:43:48,400 --> 00:43:49,400
to be stateful.

853
00:43:49,400 --> 00:43:50,400
The answer is no.

854
00:43:50,400 --> 00:43:54,520
An understanding when to use each type is critical for both performance and cost.

855
00:43:54,520 --> 00:43:56,720
Stateless workflows run entirely in memory.

856
00:43:56,720 --> 00:44:00,040
They do not persist intermediate state or run history to Azure storage.

857
00:44:00,040 --> 00:44:04,200
This makes them much faster and more scalable for short-lived operations.

858
00:44:04,200 --> 00:44:09,040
A stateless workflow can handle HTTP requests with low latency and high throughput because

859
00:44:09,040 --> 00:44:12,720
it is not waiting for storage rights between actions, but the tradeoff is strict.

860
00:44:12,720 --> 00:44:18,040
The maximum execution time for a stateless workflow in Logic app standard is 5 minutes.

861
00:44:18,040 --> 00:44:20,760
If the workflow has not completed by then, it is terminated.

862
00:44:20,760 --> 00:44:25,400
There is no resume, there is no checkpoint, and there is no detailed run history for debugging.

863
00:44:25,400 --> 00:44:28,560
Stateful workflows persist state to external storage at every action.

864
00:44:28,560 --> 00:44:32,160
This adds input output overhead and reduces raw throughput.

865
00:44:32,160 --> 00:44:36,720
But they can run for hours or days, they support callbacks, approvals and external events.

866
00:44:36,720 --> 00:44:40,800
They resume after restart and they provide full run history with every input and output

867
00:44:40,800 --> 00:44:43,440
captured for debugging and audit purposes.

868
00:44:43,440 --> 00:44:46,240
For the nervous system architecture you use both.

869
00:44:46,240 --> 00:44:48,120
These workflows are your reflexes.

870
00:44:48,120 --> 00:44:52,720
They handle quick validation checks, simple lookups and synchronous responses that an agent

871
00:44:52,720 --> 00:44:54,080
needs immediately.

872
00:44:54,080 --> 00:44:55,920
Stateful workflows are your long-term memory.

873
00:44:55,920 --> 00:45:00,240
They handle onboarding processes, multi-day approvals, cross-tenant coordination and any process

874
00:45:00,240 --> 00:45:02,360
that needs to survive interruptions.

875
00:45:02,360 --> 00:45:06,360
Community benchmarks from 2025 and 2026 show a clear pattern.

876
00:45:06,360 --> 00:45:10,320
Converting a simple HTTP triggered workflow from stateless to stateless under similar load

877
00:45:10,320 --> 00:45:15,640
conditions typically increases throughput by a factor of 3 to 5 and reduces latency by

878
00:45:15,640 --> 00:45:17,240
roughly half.

879
00:45:17,240 --> 00:45:18,720
These are not minor differences.

880
00:45:18,720 --> 00:45:22,000
They are architectural differences and they matter when your orchestrator is handling hundreds

881
00:45:22,000 --> 00:45:23,800
or thousands of agent requests per hour.

882
00:45:23,800 --> 00:45:26,080
But the benchmark numbers come with a caveat.

883
00:45:26,080 --> 00:45:30,160
The performance gain only matters if the workflow fits the stateless constraints.

884
00:45:30,160 --> 00:45:34,720
If your process needs to wait for an approval or retry over hours or coordinate across

885
00:45:34,720 --> 00:45:38,360
multiple systems with unpredictable timing then stateless is not an option.

886
00:45:38,360 --> 00:45:42,760
It is a trap and the 5 minute limit will break your process in production when the CFO takes

887
00:45:42,760 --> 00:45:45,120
three hours to respond to an approval request.

888
00:45:45,120 --> 00:45:49,760
The correct pattern is to design your orchestration so that stateless workflows handle the fast

889
00:45:49,760 --> 00:45:55,440
predictable paths and stateful workflows handle the slow, complex, multi-tenant processes.

890
00:45:55,440 --> 00:45:58,520
Both run side by side in the same logic app standard resource.

891
00:45:58,520 --> 00:46:02,800
And the orchestrator roots agent requests to the appropriate workflow type based on the

892
00:46:02,800 --> 00:46:04,480
nature of the task.

893
00:46:04,480 --> 00:46:07,560
Real numbers, what this costs and how it performs.

894
00:46:07,560 --> 00:46:11,120
Let me be direct about performance and cost because executives will ask.

895
00:46:11,120 --> 00:46:16,320
And you need to have answers that are grounded in real measurements rather than marketing slides.

896
00:46:16,320 --> 00:46:20,280
Logic app standard runs on an app service plan or a functions premium plan.

897
00:46:20,280 --> 00:46:22,560
You pay for the underlying compute not per action.

898
00:46:22,560 --> 00:46:26,240
This means that once you have provisioned the plan your cost is relatively predictable

899
00:46:26,240 --> 00:46:28,600
regardless of how many workflows run.

900
00:46:28,600 --> 00:46:32,880
For a nervous system handling moderate enterprise load, a single app service plan instance might

901
00:46:32,880 --> 00:46:34,560
cost a few hundred dollars per month.

902
00:46:34,560 --> 00:46:39,560
At higher scales you scale out to multiple instances and the cost increases linearly with

903
00:46:39,560 --> 00:46:41,920
compute.

904
00:46:41,920 --> 00:46:45,480
Consumption based logic apps by contrast charge per action execution.

905
00:46:45,480 --> 00:46:48,000
For low volume scenarios, this can be cheaper.

906
00:46:48,000 --> 00:46:51,920
But for high volume orchestration where workflows execute thousands of actions per hour,

907
00:46:51,920 --> 00:46:56,000
the per action billing can quickly exceed the cost of a dedicated standard plan.

908
00:46:56,000 --> 00:47:00,320
The research on logic app standard versus consumption for enterprise orchestration consistently

909
00:47:00,320 --> 00:47:04,800
shows that standard becomes more cost effective once you cross a threshold of a few thousand

910
00:47:04,800 --> 00:47:07,640
action executions per day.

911
00:47:07,640 --> 00:47:11,160
This is harder to generalize because it depends on what your workflows do.

912
00:47:11,160 --> 00:47:15,480
A stateless workflow that calls a fast internal API and returns a result might complete in

913
00:47:15,480 --> 00:47:16,480
under a second.

914
00:47:16,480 --> 00:47:20,800
A stateful workflow that waits for three external approvals across two tenants might take three

915
00:47:20,800 --> 00:47:24,880
days to reach completion but the actual compute time consumed is only a few minutes because

916
00:47:24,880 --> 00:47:27,680
the workflow sleeps efficiently between weight states.

917
00:47:27,680 --> 00:47:32,520
What matters for agent orchestration is throughput, latency for synchronous operations and reliability

918
00:47:32,520 --> 00:47:34,280
for long running processes.

919
00:47:34,280 --> 00:47:38,400
Visual workflows in standard can handle high throughput scenarios when designed correctly

920
00:47:38,400 --> 00:47:42,080
but they will always have higher latency per action than stateless due to the storage

921
00:47:42,080 --> 00:47:43,080
persistence.

922
00:47:43,080 --> 00:47:47,280
The key is to use stateless for the fast path and stateful for the durable path rather

923
00:47:47,280 --> 00:47:50,800
than trying to force every process into a single workflow type.

924
00:47:50,800 --> 00:47:53,920
For reliability, the numbers strongly favor standard.

925
00:47:53,920 --> 00:47:58,240
Stateful workflows with checkpoint persistence can resume after infrastructure failures, region

926
00:47:58,240 --> 00:47:59,960
outages and runtime updates.

927
00:47:59,960 --> 00:48:04,800
The run history provides the observability that operations teams need to diagnose issues.

928
00:48:04,800 --> 00:48:09,200
And the integration with Azure Monitor application insights and log analytics gives you centralized

929
00:48:09,200 --> 00:48:12,120
logging across all your orchestration workflows.

930
00:48:12,120 --> 00:48:15,000
Tenant isolation and cross tenant security configuration.

931
00:48:15,000 --> 00:48:18,800
I want to return to security for a moment because there is a specific configuration that

932
00:48:18,800 --> 00:48:22,120
many organizations overlook until it is too late.

933
00:48:22,120 --> 00:48:26,280
Azure Logic Apps supports tenant isolation policies that control whether connections can

934
00:48:26,280 --> 00:48:28,680
be shared across tenant boundaries.

935
00:48:28,680 --> 00:48:32,280
Azure Logic Apps connectors allowed connection sharing via consent links.

936
00:48:32,280 --> 00:48:37,480
A user in tenant A could create a connection to an office 365 resource and share that connection

937
00:48:37,480 --> 00:48:39,160
to workflows in another tenant.

938
00:48:39,160 --> 00:48:41,440
This created a significant security concern.

939
00:48:41,440 --> 00:48:45,760
A shared connection could silently grant broad access to resources in one tenant from another

940
00:48:45,760 --> 00:48:48,160
tenant if the sharing was not tightly controlled.

941
00:48:48,160 --> 00:48:51,280
To address this, Microsoft added tenant isolation policies.

942
00:48:51,280 --> 00:48:54,800
As a tenant administrator, you can now block access to and from your tenant through shared

943
00:48:54,800 --> 00:48:56,120
connections altogether.

944
00:48:56,120 --> 00:49:00,640
Before you can allow connections only to specific trusted tenants explicitly listing which tenants

945
00:49:00,640 --> 00:49:01,640
are permitted.

946
00:49:01,640 --> 00:49:05,400
This is a critical control for any organization that operates in a multi-tenant environment

947
00:49:05,400 --> 00:49:07,120
or collaborates with partners.

948
00:49:07,120 --> 00:49:10,640
The recommended configuration for a nervous system architecture is to block shared connections

949
00:49:10,640 --> 00:49:14,200
by default and allow only specific tenants that have been reviewed and approved by your

950
00:49:14,200 --> 00:49:15,600
security team.

951
00:49:15,600 --> 00:49:19,920
Each allowed tenant should have a documented business justification, a reviewed federation

952
00:49:19,920 --> 00:49:23,520
trust configuration, and a monitored connection pattern.

953
00:49:23,520 --> 00:49:25,600
Anything else is blocked at the tenant boundary.

954
00:49:25,600 --> 00:49:29,600
This policy works in conjunction with managed identities and workload federation.

955
00:49:29,600 --> 00:49:33,600
Even if a tenant is on the allowed list, the actual authentication is handled through federated

956
00:49:33,600 --> 00:49:35,800
trust, not through shared connection links.

957
00:49:35,800 --> 00:49:38,840
The tenant isolation policy prevents accidental sharing.

958
00:49:38,840 --> 00:49:43,880
The federation trust ensures that only explicitly authorized workloads can cross the boundary,

959
00:49:43,880 --> 00:49:47,200
and the monitoring layer detects anomalies in cross tenant traffic patterns.

960
00:49:47,200 --> 00:49:52,560
Together, these three layers create a defense and depth model for cross tenant agent orchestration.

961
00:49:52,560 --> 00:49:54,800
The policy says, "Who is allowed to connect?"

962
00:49:54,800 --> 00:49:57,040
The federation says, "Who is allowed to authenticate?"

963
00:49:57,040 --> 00:49:59,520
And the monitoring says, "What is actually happening?"

964
00:49:59,520 --> 00:50:03,120
Missing any one of these layers creates a gap that a determined attacker or a careless

965
00:50:03,120 --> 00:50:05,280
developer can exploit.

966
00:50:05,280 --> 00:50:07,680
Monitoring and observability for the nervous system.

967
00:50:07,680 --> 00:50:11,520
An orchestration architecture without observability is a black box that your operations team will

968
00:50:11,520 --> 00:50:12,600
learn to hate.

969
00:50:12,600 --> 00:50:17,040
And agent orchestration adds specific observability challenges because the process spans multiple

970
00:50:17,040 --> 00:50:20,160
systems, multiple tenants, and multiple reasoning iterations.

971
00:50:20,160 --> 00:50:22,280
The foundation is Logic Apps Run History.

972
00:50:22,280 --> 00:50:27,080
The workflow execution in standard is recorded with a unique run identifier, start time,

973
00:50:27,080 --> 00:50:30,200
end time, status, and a detailed action by action log.

974
00:50:30,200 --> 00:50:33,840
For stateful workflows, you can inspect the inputs and outputs of every action.

975
00:50:33,840 --> 00:50:37,800
For workflows that include agent loop actions, you can see the reasoning iterations, the tool

976
00:50:37,800 --> 00:50:39,600
calls, and the responses.

977
00:50:39,600 --> 00:50:42,200
But run history alone is not enough for a nervous system.

978
00:50:42,200 --> 00:50:43,880
You need distributed tracing.

979
00:50:43,880 --> 00:50:48,080
When a copilot agent calls a Logic app, which calls another Logic app in a different tenant,

980
00:50:48,080 --> 00:50:52,000
which calls a custom connector that invokes an internal API, you need a single trace

981
00:50:52,000 --> 00:50:56,080
identifier that follows the request across all those boundaries.

982
00:50:56,080 --> 00:50:59,680
Azure application insights and open telemetry integration in Logic Apps.

983
00:50:59,680 --> 00:51:00,920
Standard provide this capability.

984
00:51:00,920 --> 00:51:04,960
You configure a correlation ID at the entry point and it propagates through every downstream

985
00:51:04,960 --> 00:51:05,960
call.

986
00:51:05,960 --> 00:51:09,980
You also need alerting, not generic alerts that fire every time a workflow fails because

987
00:51:09,980 --> 00:51:10,980
workflows will fail.

988
00:51:10,980 --> 00:51:12,920
You need alerts that detect patterns.

989
00:51:12,920 --> 00:51:16,840
A sudden spike in rate limit errors from Microsoft Graph might indicate that your agent is

990
00:51:16,840 --> 00:51:19,200
making too many calls and needs throttling Logic.

991
00:51:19,200 --> 00:51:23,800
A series of permission denied errors across multiple tenants might indicate that a federated

992
00:51:23,800 --> 00:51:25,320
credential is expiring.

993
00:51:25,320 --> 00:51:29,200
A workflow that normally completes in 10 minutes but suddenly starts taking an hour might

994
00:51:29,200 --> 00:51:33,760
indicate a storage performance issue or a downstream API slowdown.

995
00:51:33,760 --> 00:51:34,920
Dashboards are the third layer.

996
00:51:34,920 --> 00:51:38,640
Your operations team needs a single pane of glass that shows the health of the orchestration

997
00:51:38,640 --> 00:51:39,640
layer.

998
00:51:39,640 --> 00:51:42,960
The metrics that matter include how many workflows are running right now, how many are in

999
00:51:42,960 --> 00:51:47,480
weight states, what the average completion time is for cross tenant onboarding processes,

1000
00:51:47,480 --> 00:51:51,720
and how many agent loop actions required more than three iterations to reach a conclusion.

1001
00:51:51,720 --> 00:51:55,100
These metrics tell you whether your nervous system is healthy, whether agents are behaving

1002
00:51:55,100 --> 00:51:57,720
as expected, and where bottlenecks are forming.

1003
00:51:57,720 --> 00:52:02,000
Building this observability stack takes effort, but it is non-negotiable for production

1004
00:52:02,000 --> 00:52:03,520
agent orchestration.

1005
00:52:03,520 --> 00:52:06,960
Because when an autonomous agent makes a decision that affects a customer, an employee,

1006
00:52:06,960 --> 00:52:11,880
or a financial transaction, you must be able to explain exactly what happened, why it happened,

1007
00:52:11,880 --> 00:52:14,120
and what the agent did next.

1008
00:52:14,120 --> 00:52:14,960
Antipatens.

1009
00:52:14,960 --> 00:52:15,960
What not to do?

1010
00:52:15,960 --> 00:52:18,240
I have spent most of this video describing what to build.

1011
00:52:18,240 --> 00:52:22,320
Let me spend a few minutes on what to avoid, because the anti-patents are just as important,

1012
00:52:22,320 --> 00:52:24,040
and they are alarmingly common.

1013
00:52:24,040 --> 00:52:25,920
Antipatent one is the God agent.

1014
00:52:25,920 --> 00:52:30,640
This is a single copilot or bot that has been given direct access to every system in

1015
00:52:30,640 --> 00:52:31,640
the organization.

1016
00:52:31,640 --> 00:52:35,680
It can read email, update databases, provision users, and send payments.

1017
00:52:35,680 --> 00:52:38,520
It is convenient because there is only one agent to maintain.

1018
00:52:38,520 --> 00:52:42,560
It is also catastrophic because a single prompt injection or misclassification can cause damage

1019
00:52:42,560 --> 00:52:44,480
across every system simultaneously.

1020
00:52:44,480 --> 00:52:48,280
A nervous system architecture prevents this by constraining agents to high-level orchestrator

1021
00:52:48,280 --> 00:52:51,000
calls rather than direct system access.

1022
00:52:51,000 --> 00:52:53,120
Antipatent 2 is the secret graveyard.

1023
00:52:53,120 --> 00:52:57,240
This is what happens when every bot has its own connection string, API key, or client

1024
00:52:57,240 --> 00:52:59,400
secret stored in a different location.

1025
00:52:59,400 --> 00:53:03,600
Some are in environment variables, some are in key vaults that nobody monitors, some are

1026
00:53:03,600 --> 00:53:06,240
hard-coded in prompts or tool definitions.

1027
00:53:06,240 --> 00:53:10,440
When a secret expires or is compromised, you have no central inventory of what breaks.

1028
00:53:10,440 --> 00:53:12,800
The fix is managed identities and federation.

1029
00:53:12,800 --> 00:53:17,120
There should be exactly zero client secrets in your agent orchestration layer.

1030
00:53:17,120 --> 00:53:19,600
Antipatent 3 is the stateless long runner.

1031
00:53:19,600 --> 00:53:23,160
This is the workflow that was designed as stateless because someone read a benchmark showing

1032
00:53:23,160 --> 00:53:27,520
that stateless is faster, but the process actually needs to wait for approvals, handle callbacks

1033
00:53:27,520 --> 00:53:29,000
and survive restarts.

1034
00:53:29,000 --> 00:53:31,240
So the developer adds hacky workarounds.

1035
00:53:31,240 --> 00:53:34,520
External databases store the state, cron jobs pull for completion.

1036
00:53:34,520 --> 00:53:38,120
And the resulting system is slower, more expensive, and less reliable than a native state

1037
00:53:38,120 --> 00:53:39,640
full workflow would have been.

1038
00:53:39,640 --> 00:53:44,480
If your process lasts longer than five minutes or needs to survive interruptions, use stateful.

1039
00:53:44,480 --> 00:53:47,200
The benchmark numbers do not matter if the architecture is wrong.

1040
00:53:47,200 --> 00:53:50,320
Antipatent 4 is the human in the loop everything approach.

1041
00:53:50,320 --> 00:53:54,240
Some organizations are so afraid of autonomous agents that they require human approval for

1042
00:53:54,240 --> 00:53:55,440
every single action.

1043
00:53:55,440 --> 00:53:59,360
The result is a system that is technically automated but practically manual.

1044
00:53:59,360 --> 00:54:02,680
Agents spend most of their time waiting for humans to click approve buttons.

1045
00:54:02,680 --> 00:54:06,720
And the humans, overwhelmed by approval volume, start clicking approve without reading

1046
00:54:06,720 --> 00:54:07,720
the context.

1047
00:54:07,720 --> 00:54:09,640
This is neither efficient nor secure.

1048
00:54:09,640 --> 00:54:13,440
The correct approach is to define risk-based guardrails, automate the low-risk actions,

1049
00:54:13,440 --> 00:54:16,640
and reserve human review for the genuinely high-stakes decisions.

1050
00:54:16,640 --> 00:54:18,680
Antipatent 5 is the skip standard movement.

1051
00:54:18,680 --> 00:54:23,520
This happens when a team wants to save money or avoid Azure complexity so they build their

1052
00:54:23,520 --> 00:54:27,800
orchestration in consumption logic apps or power automate cloud flows.

1053
00:54:27,800 --> 00:54:30,520
These platforms are excellent for their intended use cases.

1054
00:54:30,520 --> 00:54:35,000
They are not excellent for enterprise scale agent orchestration that requires custom connectors,

1055
00:54:35,000 --> 00:54:39,520
virtual network integration, agent loop actions, and deep DevOps control.

1056
00:54:39,520 --> 00:54:43,000
Skipping standard because it seems harder is a decision that creates technical debt from

1057
00:54:43,000 --> 00:54:44,000
day one.

1058
00:54:44,000 --> 00:54:46,640
The deployment roadmap from zero to nervous system.

1059
00:54:46,640 --> 00:54:51,040
So the architecture works, the security works, the governance works, the observability works,

1060
00:54:51,040 --> 00:54:54,960
the next question is how you actually start and how you avoid the common trap of trying

1061
00:54:54,960 --> 00:54:58,200
to orchestrate everything on day one and failing.

1062
00:54:58,200 --> 00:55:00,280
Here is a practical seven phase roadmap.

1063
00:55:00,280 --> 00:55:01,520
Phase one is inventory.

1064
00:55:01,520 --> 00:55:06,600
You map every agent, bot, flow, and custom integration that currently exists in your environment.

1065
00:55:06,600 --> 00:55:10,320
You document what systems each one touches, what credentials it uses, and what business

1066
00:55:10,320 --> 00:55:11,880
processes it claims to support.

1067
00:55:11,880 --> 00:55:15,960
This is not glamorous work, it is audit work, and it is essential because you cannot orchestrate

1068
00:55:15,960 --> 00:55:17,240
what you cannot see.

1069
00:55:17,240 --> 00:55:18,880
Phase two is selection.

1070
00:55:18,880 --> 00:55:23,600
You identify one end-to-end process that crosses multiple systems and hurts when it breaks.

1071
00:55:23,600 --> 00:55:27,800
Employee onboarding is a common choice because it touches HR systems, identity platforms,

1072
00:55:27,800 --> 00:55:30,280
email provisioning, and security approvals.

1073
00:55:30,280 --> 00:55:34,720
After order processing is another good candidate because it crosses organizational boundaries.

1074
00:55:34,720 --> 00:55:38,040
Pick a process that is painful, visible, and has executive sponsorship.

1075
00:55:38,040 --> 00:55:40,960
Do not pick the most complex process in the organization.

1076
00:55:40,960 --> 00:55:43,320
You are building confidence, not proving a point.

1077
00:55:43,320 --> 00:55:44,320
Phase three is design.

1078
00:55:44,320 --> 00:55:48,560
You build the first orchestrator logic app for the selected process using logic app standard.

1079
00:55:48,560 --> 00:55:53,680
You define the workflow triggers, the branching logic, the connector calls, and the error handling

1080
00:55:53,680 --> 00:55:54,680
parts.

1081
00:55:54,680 --> 00:55:58,680
You use stateful workflows because the process will involve weights and approvals.

1082
00:55:58,680 --> 00:56:03,240
You use managed identities for every connection that stays inside your primary tenant.

1083
00:56:03,240 --> 00:56:06,040
And you document the design so the security team can review it.

1084
00:56:06,040 --> 00:56:07,440
Phase four is identity.

1085
00:56:07,440 --> 00:56:10,720
You migrate every credential in the orchestrator to manage the identities.

1086
00:56:10,720 --> 00:56:14,520
For connections that need to reach other tenants, you configure workload identity federation

1087
00:56:14,520 --> 00:56:16,320
with explicit trust relationships.

1088
00:56:16,320 --> 00:56:20,560
You remove every client's secret, every connection string, and every hard-coded token.

1089
00:56:20,560 --> 00:56:23,240
You test every federated connection end-to-end.

1090
00:56:23,240 --> 00:56:26,720
And you document the trust relationships in your identity governance catalog.

1091
00:56:26,720 --> 00:56:28,480
Phase five is connectorization.

1092
00:56:28,480 --> 00:56:31,720
You identify the proprietary business logic that your agents need to access.

1093
00:56:31,720 --> 00:56:34,840
You wrap that logic in internal APIs with open API specifications.

1094
00:56:34,840 --> 00:56:37,480
You publish those APIs as custom connectors in logic apps.

1095
00:56:37,480 --> 00:56:38,560
You test the connectors.

1096
00:56:38,560 --> 00:56:39,560
You version them.

1097
00:56:39,560 --> 00:56:43,560
And you add them to your connector catalog so other teams can discover and reuse them.

1098
00:56:43,560 --> 00:56:45,240
Phase six is agent integration.

1099
00:56:45,240 --> 00:56:48,680
You introduce the first autonomous agent that calls the orchestrator instead of calling

1100
00:56:48,680 --> 00:56:49,760
APIs directly.

1101
00:56:49,760 --> 00:56:54,080
This might be a co-pilot studio agent, a team's bot, or a custom Azure open AI agent.

1102
00:56:54,080 --> 00:56:57,920
You configure it with a small set of high-level tools that map to logic app endpoints.

1103
00:56:57,920 --> 00:57:01,860
You test the full flow from user request through agent reasoning through orchestrator execution.

1104
00:57:01,860 --> 00:57:06,040
You verify that the agent cannot bypass the orchestrator and access systems directly.

1105
00:57:06,040 --> 00:57:08,280
And you measure the end-to-end latency and reliability.

1106
00:57:08,280 --> 00:57:09,440
Phase seven is expansion.

1107
00:57:09,440 --> 00:57:12,160
You add more processes to the orchestration layer one at a time.

1108
00:57:12,160 --> 00:57:14,560
You reuse existing connectors wherever possible.

1109
00:57:14,560 --> 00:57:16,560
You share workflow patterns across teams.

1110
00:57:16,560 --> 00:57:20,280
And you build the monitoring and alerting stacks so your operations team can see the health

1111
00:57:20,280 --> 00:57:22,640
of the entire nervous system as it grows.

1112
00:57:22,640 --> 00:57:24,400
This roadmap takes months, not weeks.

1113
00:57:24,400 --> 00:57:29,280
But it works because it builds confidence incrementally, each phase delivers a concrete, verifiable

1114
00:57:29,280 --> 00:57:30,280
improvement.

1115
00:57:30,280 --> 00:57:33,840
And by the time you reach phase seven, your organization has already seen the value of

1116
00:57:33,840 --> 00:57:35,840
orchestration in production.

1117
00:57:35,840 --> 00:57:38,080
The future of agent orchestration.

1118
00:57:38,080 --> 00:57:40,360
But this is not just about fixing today's mess.

1119
00:57:40,360 --> 00:57:44,120
It is about building for what is coming and what is coming will make today's agent landscape

1120
00:57:44,120 --> 00:57:45,120
look primitive.

1121
00:57:45,120 --> 00:57:50,840
By late 2026 and into 2027, the capabilities of large language models will continue to accelerate.

1122
00:57:50,840 --> 00:57:55,480
Accounts will reason over longer contexts, plan more complex multi-step actions and interact

1123
00:57:55,480 --> 00:57:57,520
with richer multimodal inputs.

1124
00:57:57,520 --> 00:58:01,160
New models will be released on schedules that make the current pace feel slow.

1125
00:58:01,160 --> 00:58:04,640
And every agent you have built will need to upgrade its reasoning engine without breaking

1126
00:58:04,640 --> 00:58:06,000
its execution layer.

1127
00:58:06,000 --> 00:58:08,440
This is why the nervous system architecture is future-proof.

1128
00:58:08,440 --> 00:58:12,160
When a new model becomes available, you update the agent loop action configuration to

1129
00:58:12,160 --> 00:58:13,640
point to the new deployment.

1130
00:58:13,640 --> 00:58:15,320
The orchestrator logic does not change.

1131
00:58:15,320 --> 00:58:16,840
The business rules do not change.

1132
00:58:16,840 --> 00:58:19,080
The cross tenant connections do not change.

1133
00:58:19,080 --> 00:58:20,800
You see the reasoning engine upgrades.

1134
00:58:20,800 --> 00:58:24,480
And because the orchestrator constrains what the agent can do through typed custom connectors

1135
00:58:24,480 --> 00:58:28,840
and governed workflow definitions, a more powerful model does not create new security

1136
00:58:28,840 --> 00:58:29,840
risks.

1137
00:58:29,840 --> 00:58:32,760
It simply makes better decisions within the same guardrails.

1138
00:58:32,760 --> 00:58:36,600
Microsoft is also expanding Entra agent ID with deeper governance features.

1139
00:58:36,600 --> 00:58:40,080
Blueprint-based permission management will allow you to define entire classes of agents

1140
00:58:40,080 --> 00:58:44,680
with standardized identity models, scope permissions and behavioral policies.

1141
00:58:44,680 --> 00:58:48,640
You will be able to deploy a new agent that inherits the governance profile of its blueprint

1142
00:58:48,640 --> 00:58:53,720
automatically rather than configuring each agent's identity and permissions manually.

1143
00:58:53,720 --> 00:58:57,340
Logic app standard will continue to evolve with deeper AI integration, more connector

1144
00:58:57,340 --> 00:59:00,720
coverage and improve performance for stateful workflows.

1145
00:59:00,720 --> 00:59:04,820
The gap between stateful and stateless throughput is already narrowing as the runtime optimizes

1146
00:59:04,820 --> 00:59:05,820
storage patterns.

1147
00:59:05,820 --> 00:59:09,480
And the integration with Azure Service, Bus, Event Grid and Kubernetes will make the

1148
00:59:09,480 --> 00:59:13,840
orchestration layer even more capable for event-driven and containerized workloads.

1149
00:59:13,840 --> 00:59:18,000
The shift from reactive triggers to proactive event-driven, agentec workflows is already

1150
00:59:18,000 --> 00:59:19,000
underway.

1151
00:59:19,000 --> 00:59:22,800
Instead of waiting for a user to ask a question, agents will monitor event streams, detect

1152
00:59:22,800 --> 00:59:27,560
patterns and initiate orchestrated processes before the user even knows they need something.

1153
00:59:27,560 --> 00:59:32,080
A supply chain agent might notice an inventory anomaly, trigger a logic app that checks

1154
00:59:32,080 --> 00:59:37,040
supplier availability across three tenants and present the purchasing manager with a prevalidated

1155
00:59:37,040 --> 00:59:40,040
order recommendation before the stockout occurs.

1156
00:59:40,040 --> 00:59:41,600
This is the direction of travel.

1157
00:59:41,600 --> 00:59:45,520
Agents will become more autonomous, processes will become more proactive, and the orchestration

1158
00:59:45,520 --> 00:59:49,960
layer that governs them will become the most critical infrastructure in your cloud environment.

1159
00:59:49,960 --> 00:59:53,760
The organizations that invest in this architecture now will not just survive the transition, they

1160
00:59:53,760 --> 00:59:55,240
will define it.

1161
00:59:55,240 --> 00:59:57,680
The co-pilot studio to Logic Apps Bridge.

1162
00:59:57,680 --> 01:00:00,200
I have talked about the architecture in abstract terms.

1163
01:00:00,200 --> 01:00:04,280
Let me get specific about how co-pilot studio and logic apps actually connect because this

1164
01:00:04,280 --> 01:00:08,560
is the bridge that most Microsoft focused organizations need to build first.

1165
01:00:08,560 --> 01:00:13,240
Co-pilot studio excels at reasoning, natural language understanding and conversational interaction.

1166
01:00:13,240 --> 01:00:17,440
You define an agent with a description, knowledge sources, tools and triggers.

1167
01:00:17,440 --> 01:00:21,960
You enable generative orchestration so the agent can dynamically decide which tools to call

1168
01:00:21,960 --> 01:00:23,680
based on the user's intent.

1169
01:00:23,680 --> 01:00:26,800
You publish the agent to channels like Teams, WebChat or email.

1170
01:00:26,800 --> 01:00:29,240
The tool layer is where the integration happens.

1171
01:00:29,240 --> 01:00:34,000
In co-pilot studio, a tool is an action that the agent can invoke to accomplish a task.

1172
01:00:34,000 --> 01:00:38,080
By default, these tools are powerplatform connectors or AI prompts, but you can also call a

1173
01:00:38,080 --> 01:00:44,160
power automate Cloudflow or an external HTTP endpoint.

1174
01:00:44,160 --> 01:00:46,040
Here is the practical pattern.

1175
01:00:46,040 --> 01:00:50,640
You create a logic app with an HTTP trigger that defines a specific business capability.

1176
01:00:50,640 --> 01:00:54,480
The trigger schema specifies exactly what inputs the orchestrator expects.

1177
01:00:54,480 --> 01:00:58,840
For example, an onboarding initiation trigger might expect employee name, start date, department

1178
01:00:58,840 --> 01:01:00,400
and security clearance level.

1179
01:01:00,400 --> 01:01:02,080
The schema is typed and validated.

1180
01:01:02,080 --> 01:01:04,960
There is no ambiguity about what the agent should provide.

1181
01:01:04,960 --> 01:01:08,680
In co-pilot studio, you add a tool that calls this HTTP endpoint.

1182
01:01:08,680 --> 01:01:12,520
You describe the tool in natural language so the generative orchestration engine knows

1183
01:01:12,520 --> 01:01:13,520
when to use it.

1184
01:01:13,520 --> 01:01:17,640
The description might say initiate cross tenant employee onboarding when the user provides

1185
01:01:17,640 --> 01:01:19,800
employee details in a start date.

1186
01:01:19,800 --> 01:01:24,560
You configure authentication so the HTTP call uses the agent's credentials or a service

1187
01:01:24,560 --> 01:01:27,080
principle that both systems trust.

1188
01:01:27,080 --> 01:01:31,240
When a user asks the agent to onboard a new employee, the agent's reasoning loop analyzes

1189
01:01:31,240 --> 01:01:32,240
the request.

1190
01:01:32,240 --> 01:01:35,200
It determines that onboarding initiation is the right tool.

1191
01:01:35,200 --> 01:01:37,800
It extracts the employee details from the conversation.

1192
01:01:37,800 --> 01:01:41,560
It constructs the HTTP request with the required parameters.

1193
01:01:41,560 --> 01:01:43,800
And it sends the request to the logic app trigger.

1194
01:01:43,800 --> 01:01:48,320
The logic app receives the request, validates the schema and starts the orchestration.

1195
01:01:48,320 --> 01:01:51,440
It might branch immediately to handle different employee types.

1196
01:01:51,440 --> 01:01:52,680
It might pause for approvals.

1197
01:01:52,680 --> 01:01:55,520
It might call other logic apps in different tenants.

1198
01:01:55,520 --> 01:01:59,200
And when the process reaches a milestone or completion, it returns a structured response

1199
01:01:59,200 --> 01:02:03,040
to the agent, the agent receives the response and incorporates it into its reasoning.

1200
01:02:03,040 --> 01:02:07,680
It might tell the user that the onboarding process has started, that three approvals are pending,

1201
01:02:07,680 --> 01:02:11,920
and that the new employee will receive a welcome email once the security review is complete.

1202
01:02:11,920 --> 01:02:15,880
If the user asks follow-up questions, the agent can make additional orchestrator calls to check

1203
01:02:15,880 --> 01:02:18,520
status, modify details or escalate issues.

1204
01:02:18,520 --> 01:02:22,600
This bridge is powerful because it preserves what co-pilot studio does well while delegating

1205
01:02:22,600 --> 01:02:23,720
what it does poorly.

1206
01:02:23,720 --> 01:02:25,280
The agent handles the conversation.

1207
01:02:25,280 --> 01:02:28,920
The orchestrator handles the execution, but the agent never touches a database directly.

1208
01:02:28,920 --> 01:02:31,720
The orchestrator never tries to interpret natural language.

1209
01:02:31,720 --> 01:02:35,920
Each system operates at the layer where it is strongest and they communicate through well-defined

1210
01:02:35,920 --> 01:02:41,120
HTTP contracts that both teams can understand, version and test.

1211
01:02:41,120 --> 01:02:42,280
Migrating from siloed bots.

1212
01:02:42,280 --> 01:02:43,560
A real example.

1213
01:02:43,560 --> 01:02:47,320
Let me walk through a migration scenario so you can see how this transition actually happens

1214
01:02:47,320 --> 01:02:48,560
in practice.

1215
01:02:48,560 --> 01:02:51,560
Imagine a manufacturing company that has grown through acquisition.

1216
01:02:51,560 --> 01:02:55,960
They have four separate Microsoft 365 tenants from three prior companies plus the original

1217
01:02:55,960 --> 01:02:57,280
parent organization.

1218
01:02:57,280 --> 01:03:00,600
Each tenant has its own co-pilot or bot for some local function.

1219
01:03:00,600 --> 01:03:03,720
Tenant one has a team's bot that handles IT support tickets.

1220
01:03:03,720 --> 01:03:08,540
It connects directly to service now, reads knowledge bases from SharePoint and sends notification

1221
01:03:08,540 --> 01:03:10,720
emails through Exchange Online.

1222
01:03:10,720 --> 01:03:15,040
Tenant 2 has a co-pilot studio agent that answers HR questions and can submit time off requests

1223
01:03:15,040 --> 01:03:17,640
to a legacy SAP system through a custom API.

1224
01:03:17,640 --> 01:03:21,360
Tenant 3 has a power automate flow that monitors a shared mailbox for customer complaints

1225
01:03:21,360 --> 01:03:24,400
and routes them to the appropriate regional team.

1226
01:03:24,400 --> 01:03:28,480
Tenant 4 has a custom Azure OpenAI agent that summarizes production reports and emails

1227
01:03:28,480 --> 01:03:29,720
them to managers.

1228
01:03:29,720 --> 01:03:34,080
None of these agents know about each other, non-share state, each has its own credentials,

1229
01:03:34,080 --> 01:03:37,480
its own error handling and its own understanding of business rules.

1230
01:03:37,480 --> 01:03:41,920
When the company decides to standardize, employ on-boarding across all four entities,

1231
01:03:41,920 --> 01:03:46,520
the IT team realizes that no single bot can handle the end-to-end process because the process

1232
01:03:46,520 --> 01:03:50,760
crosses every tenant boundary and touches every system.

1233
01:03:50,760 --> 01:03:54,840
The migration starts with an inventory, the team documents every agent, every connection,

1234
01:03:54,840 --> 01:03:58,160
every credential and every business rule that each agent claims to implement.

1235
01:03:58,160 --> 01:04:01,960
They discover that three different agents have their own logic for provisioning email accounts,

1236
01:04:01,960 --> 01:04:03,760
each implemented slightly differently.

1237
01:04:03,760 --> 01:04:07,680
Two agents use the same service now connection, but with different user accounts.

1238
01:04:07,680 --> 01:04:11,520
And one agent has a client secret that expired six months ago and was never renewed, meaning

1239
01:04:11,520 --> 01:04:14,760
it has been failing silently on a subset of its tasks.

1240
01:04:14,760 --> 01:04:16,280
Phase 2 is process selection.

1241
01:04:16,280 --> 01:04:19,640
The team chooses contractor on-boarding as the first orchestrated process because it is

1242
01:04:19,640 --> 01:04:23,360
painful, visible and cross-tenant by definition.

1243
01:04:23,360 --> 01:04:27,120
They design a single logic app in standard plan that lives in the primary tenant.

1244
01:04:27,120 --> 01:04:31,440
The logic app exposes an HTTP trigger for initiate contractor on-boarding.

1245
01:04:31,440 --> 01:04:36,200
It uses stateful workflows because the process involves approvals that can take several days.

1246
01:04:36,200 --> 01:04:40,440
It uses managed identities for connections inside the primary tenant, and it configures

1247
01:04:40,440 --> 01:04:44,800
workload identity federation for connections to the three subsidiary tenants.

1248
01:04:44,800 --> 01:04:46,400
Phase 3 is connector creation.

1249
01:04:46,400 --> 01:04:49,440
The team wraps the common capabilities into custom connectors.

1250
01:04:49,440 --> 01:04:52,240
A provisioning connector handles mailbox and group assignments.

1251
01:04:52,240 --> 01:04:55,200
A service now connector handles ticket creation and status checks.

1252
01:04:55,200 --> 01:04:59,280
An HR system connector handles time off requests and contractor status updates.

1253
01:04:59,280 --> 01:05:02,360
Each connector is documented, versioned and published to the organization's connector

1254
01:05:02,360 --> 01:05:03,360
catalog.

1255
01:05:03,360 --> 01:05:05,400
Phase 4 is agent integration.

1256
01:05:05,400 --> 01:05:09,080
The IT support bot-intenant-1 is updated so that instead of creating tickets directly in

1257
01:05:09,080 --> 01:05:13,080
service now, it calls the orchestrator with a request to initiate on-boarding.

1258
01:05:13,080 --> 01:05:18,600
The HR agent-intenant-2 is updated so that instead of calling the legacy SAP API directly,

1259
01:05:18,600 --> 01:05:21,040
it calls the orchestrator with employee details.

1260
01:05:21,040 --> 01:05:25,360
The complaint flow in tenant 3 is updated so that high priority complaints that require

1261
01:05:25,360 --> 01:05:29,680
cross tenant coordination are wrote to the orchestrator instead of being handled locally.

1262
01:05:29,680 --> 01:05:31,440
Phase 5 is decommissioning.

1263
01:05:31,440 --> 01:05:35,320
As the orchestrator proves itself, the team gradually retires the direct connections that

1264
01:05:35,320 --> 01:05:37,320
the individual bots were using.

1265
01:05:37,320 --> 01:05:40,000
The duplicated provisioning logic is removed from the bots.

1266
01:05:40,000 --> 01:05:42,280
The expired client secrets are revoked.

1267
01:05:42,280 --> 01:05:47,200
And the direct SAP API access that the HR bot had is restricted so that only the orchestrators

1268
01:05:47,200 --> 01:05:49,360
managed identity can reach it.

1269
01:05:49,360 --> 01:05:52,880
Six months after starting the migration, the company has a single orchestration layer

1270
01:05:52,880 --> 01:05:55,680
that handles contractor onboarding across all four tenants.

1271
01:05:55,680 --> 01:05:59,080
The process is audited, compliant and resilient to failures.

1272
01:05:59,080 --> 01:06:01,640
The individual agents still exist, but they are thinner.

1273
01:06:01,640 --> 01:06:02,640
They reason.

1274
01:06:02,640 --> 01:06:03,640
They converse.

1275
01:06:03,640 --> 01:06:04,640
They call the orchestrator.

1276
01:06:04,640 --> 01:06:07,880
And the orchestrator remembers, coordinates and executes.

1277
01:06:07,880 --> 01:06:09,280
This is what migration looks like.

1278
01:06:09,280 --> 01:06:10,280
It is not a big bang.

1279
01:06:10,280 --> 01:06:11,280
It is incremental.

1280
01:06:11,280 --> 01:06:12,280
It is architectural.

1281
01:06:12,280 --> 01:06:16,120
And it works because each phase delivers a concrete, visible improvement that builds

1282
01:06:16,120 --> 01:06:18,160
confidence for the next phase.

1283
01:06:18,160 --> 01:06:19,560
Common objections answered.

1284
01:06:19,560 --> 01:06:23,200
Whenever I present this architecture to leadership teams, I hear the same objections.

1285
01:06:23,200 --> 01:06:27,640
Let me address them directly because if you are going to sell this inside your organization,

1286
01:06:27,640 --> 01:06:31,440
you need answers that are grounded in reality rather than enthusiasm.

1287
01:06:31,440 --> 01:06:33,160
Objection one is that this is too complex.

1288
01:06:33,160 --> 01:06:34,480
We already have bots that work.

1289
01:06:34,480 --> 01:06:36,800
The question is why we would add another layer.

1290
01:06:36,800 --> 01:06:38,920
The answer is that your bots work in isolation.

1291
01:06:38,920 --> 01:06:40,640
They do not work in coordination.

1292
01:06:40,640 --> 01:06:44,760
And the complexity of adding an orchestration layer is significantly less than the complexity

1293
01:06:44,760 --> 01:06:48,760
of maintaining 15 point to point integrations that each have their own credentials, error

1294
01:06:48,760 --> 01:06:50,720
handling and business logic.

1295
01:06:50,720 --> 01:06:52,200
The orchestrator is complex once.

1296
01:06:52,200 --> 01:06:54,240
The point to point model is complex forever.

1297
01:06:54,240 --> 01:06:56,080
And it multiplies with every new bot.

1298
01:06:56,080 --> 01:07:00,240
Objection two is that Copilot Studio and Power Automate are good enough.

1299
01:07:00,240 --> 01:07:01,440
We do not need Azure.

1300
01:07:01,440 --> 01:07:04,720
The answer is that Copilot Studio handles reasoning brilliantly.

1301
01:07:04,720 --> 01:07:07,640
Power Automate handles departmental automation well.

1302
01:07:07,640 --> 01:07:11,320
Neither was designed for enterprise-grade cross tenant orchestration with custom connectors,

1303
01:07:11,320 --> 01:07:14,560
stateful long-running processes and deep DevOps integration.

1304
01:07:14,560 --> 01:07:18,840
Logic App Standard is the professional integration surface for exactly these scenarios.

1305
01:07:18,840 --> 01:07:22,440
It is not a replacement for Copilot Studio or Power Automate.

1306
01:07:22,440 --> 01:07:25,640
It is the layer beneath them that makes them enterprise-ready.

1307
01:07:25,640 --> 01:07:28,160
Objection three is that our developers do not know logic apps.

1308
01:07:28,160 --> 01:07:32,320
The answer is that Logic App Standard uses a designer experience that is familiar to anyone

1309
01:07:32,320 --> 01:07:34,280
who has built power automate flows.

1310
01:07:34,280 --> 01:07:37,760
The JSON workflow definitions are readable and version controllable.

1311
01:07:37,760 --> 01:07:41,680
And the transition from citizen developer to integration professional is smoother than

1312
01:07:41,680 --> 01:07:45,880
the transition from low code to custom code in Azure functions or Kubernetes.

1313
01:07:45,880 --> 01:07:48,920
If your team can build a power automate flow, they can build a logic app.

1314
01:07:48,920 --> 01:07:51,680
The gap is smaller than most people assume.

1315
01:07:51,680 --> 01:07:56,160
Objection four is that managed identities and federation are too hard to configure.

1316
01:07:56,160 --> 01:08:00,160
The answer is that they are harder than copying a client secret and they should be.

1317
01:08:00,160 --> 01:08:02,240
The extra configuration is the security.

1318
01:08:02,240 --> 01:08:06,480
Every federated trust relationship you create is explicit, documented and auditable.

1319
01:08:06,480 --> 01:08:10,240
Every managed identity you assign is automatically rotated by the platform.

1320
01:08:10,240 --> 01:08:15,120
And every secret you avoid is one less credential that your security team has to track, rotate

1321
01:08:15,120 --> 01:08:16,800
and worry about being stolen.

1322
01:08:16,800 --> 01:08:18,600
The difficulty is the feature.

1323
01:08:18,600 --> 01:08:20,920
Objection five is that stateful workflows are too slow.

1324
01:08:20,920 --> 01:08:25,360
The answer is that stateful workflows add input/output overhead and that does increase latency

1325
01:08:25,360 --> 01:08:26,560
per action.

1326
01:08:26,560 --> 01:08:31,320
But for the processes that matter most to autonomous agents, the durability and observability

1327
01:08:31,320 --> 01:08:32,920
are worth the speed trade-off.

1328
01:08:32,920 --> 01:08:36,280
You use stateless workflows for the fast synchronous paths.

1329
01:08:36,280 --> 01:08:39,960
You use stateful workflows for the long running processes that need to survive restarts

1330
01:08:39,960 --> 01:08:41,040
and waits.

1331
01:08:41,040 --> 01:08:44,840
The correct architecture uses both and the benchmark numbers only matter when you choose

1332
01:08:44,840 --> 01:08:46,920
the wrong type for the wrong job.

1333
01:08:46,920 --> 01:08:49,760
Objection six is that this is overkill for our current scale.

1334
01:08:49,760 --> 01:08:52,680
The answer is that architecture decisions are not about today's scale.

1335
01:08:52,680 --> 01:08:54,240
They are about tomorrow's scale.

1336
01:08:54,240 --> 01:08:58,240
If you build point-to-point integrations today, you are building the exact technical debt

1337
01:08:58,240 --> 01:09:01,960
that will prevent you from adding the next agent, the next tenant or the next business

1338
01:09:01,960 --> 01:09:02,960
process.

1339
01:09:02,960 --> 01:09:07,000
An orchestration layer is not overkill, it is insurance against the future complexity

1340
01:09:07,000 --> 01:09:10,680
that every growing organization eventually faces.

1341
01:09:10,680 --> 01:09:12,320
The 30-day pilot plan.

1342
01:09:12,320 --> 01:09:16,320
If you are convinced and you want to start, here is a concrete 30-day pilot plan that delivers

1343
01:09:16,320 --> 01:09:18,960
a working orchestrator without boiling the ocean.

1344
01:09:18,960 --> 01:09:20,480
Week one is discovery.

1345
01:09:20,480 --> 01:09:23,720
Spend five days mapping one specific process that hurts.

1346
01:09:23,720 --> 01:09:27,400
Document every system it touches, every team involved, and every failure mode that currently

1347
01:09:27,400 --> 01:09:28,400
waste time.

1348
01:09:28,400 --> 01:09:30,240
Do not try to map your entire agent estate.

1349
01:09:30,240 --> 01:09:31,240
Pick one process.

1350
01:09:31,240 --> 01:09:35,000
If you cannot identify a single process that crosses two or more systems and fails at

1351
01:09:35,000 --> 01:09:38,480
least once a month, then your organization is not ready for orchestration.

1352
01:09:38,480 --> 01:09:39,800
Solve that first.

1353
01:09:39,800 --> 01:09:41,080
Week two is design.

1354
01:09:41,080 --> 01:09:45,080
Spend three days designing the orchestrator logic app for your chosen process.

1355
01:09:45,080 --> 01:09:46,080
Define the trigger schema.

1356
01:09:46,080 --> 01:09:47,880
Map the workflow branches.

1357
01:09:47,880 --> 01:09:51,880
Identify which connections can use managed identities and which will need federation.

1358
01:09:51,880 --> 01:09:53,280
Sketch the error handling path.

1359
01:09:53,280 --> 01:09:57,160
And create a simple custom connector if your process touches an internal API.

1360
01:09:57,160 --> 01:09:58,160
Do not build everything.

1361
01:09:58,160 --> 01:09:59,600
Build enough to prove the pattern.

1362
01:09:59,600 --> 01:10:01,840
Spend two days on identity configuration.

1363
01:10:01,840 --> 01:10:04,440
Set up the managed identity for your logic app.

1364
01:10:04,440 --> 01:10:07,160
Consider the federated trust for any cross tenant connections.

1365
01:10:07,160 --> 01:10:10,480
Test each trust end to end with a simple HTTP request.

1366
01:10:10,480 --> 01:10:13,040
Document the configuration so your security team can review it.

1367
01:10:13,040 --> 01:10:17,240
And do not proceed to week three until every identity connection works in isolation.

1368
01:10:17,240 --> 01:10:18,800
Week three is built in test.

1369
01:10:18,800 --> 01:10:20,840
Build the workflow in logic app standard.

1370
01:10:20,840 --> 01:10:24,800
Use the designer for the main structure and switch to code view for fine tuning.

1371
01:10:24,800 --> 01:10:26,720
Test each branch independently.

1372
01:10:26,720 --> 01:10:29,600
Simulate failures by temporarily breaking connections.

1373
01:10:29,600 --> 01:10:32,040
Verify that your error handling paths fire correctly.

1374
01:10:32,040 --> 01:10:35,880
Test the full end to end flow at least three times with different input scenarios.

1375
01:10:35,880 --> 01:10:37,760
Week four is integration and demo.

1376
01:10:37,760 --> 01:10:40,240
Connect your existing agent to the orchestrator trigger.

1377
01:10:40,240 --> 01:10:44,800
This might be a co-pilot studio tool, a power automate flow that calls an HTTP endpoint

1378
01:10:44,800 --> 01:10:46,280
or a simple test script.

1379
01:10:46,280 --> 01:10:49,760
Run the full flow from agent request through orchestrator execution.

1380
01:10:49,760 --> 01:10:50,920
Capture the run history.

1381
01:10:50,920 --> 01:10:52,600
Show the logs to your security team.

1382
01:10:52,600 --> 01:10:55,760
And present the results to stakeholders with concrete metrics.

1383
01:10:55,760 --> 01:10:56,760
Time saved.

1384
01:10:56,760 --> 01:10:57,800
Errors caught.

1385
01:10:57,800 --> 01:11:00,240
Manual handoffs eliminated.

1386
01:11:00,240 --> 01:11:03,400
At the end of 30 days, you will not have a full nervous system.

1387
01:11:03,400 --> 01:11:04,400
But you will have proof.

1388
01:11:04,400 --> 01:11:08,680
You will have a working orchestrator that handles one real process with real credentials, real

1389
01:11:08,680 --> 01:11:11,360
error handling and real cross system coordination.

1390
01:11:11,360 --> 01:11:14,560
And that proof is what you need to justify the next phase of investment.

1391
01:11:14,560 --> 01:11:18,480
If the pilot works you scale, if it does not work, you learned what broke before you committed

1392
01:11:18,480 --> 01:11:20,000
to a full migration.

1393
01:11:20,000 --> 01:11:21,160
Either outcome is valuable.

1394
01:11:21,160 --> 01:11:25,680
The only losing move is to keep building siloed agents and hope the problem solves itself.

1395
01:11:25,680 --> 01:11:26,680
It will not.

1396
01:11:26,680 --> 01:11:28,080
It will get worse.

1397
01:11:28,080 --> 01:11:30,800
Power automate versus logic apps, where each belongs.

1398
01:11:30,800 --> 01:11:34,080
I want to be clear about the relationship between power automate and logic apps because

1399
01:11:34,080 --> 01:11:38,960
this confuses a lot of teams and confusion here leads to bad architecture decisions.

1400
01:11:38,960 --> 01:11:41,880
Power automate is designed for citizen developers and business users.

1401
01:11:41,880 --> 01:11:44,520
It is tightly integrated into Microsoft 365.

1402
01:11:44,520 --> 01:11:46,200
It has a friendly low-code interface.

1403
01:11:46,200 --> 01:11:51,240
It handles departmental automation, personal productivity workflows and simple approvals

1404
01:11:51,240 --> 01:11:52,240
with grace.

1405
01:11:52,240 --> 01:11:57,080
If a business analyst needs to send a notification when a SharePoint list item changes, power automate

1406
01:11:57,080 --> 01:11:58,080
is the right tool.

1407
01:11:58,080 --> 01:11:59,400
It takes 10 minutes to build.

1408
01:11:59,400 --> 01:12:04,040
It lives inside the business user's world and it does not require Azure expertise.

1409
01:12:04,040 --> 01:12:07,040
Logic apps is designed for integration professionals and developers.

1410
01:12:07,040 --> 01:12:08,200
It lives in Azure.

1411
01:12:08,200 --> 01:12:12,240
It supports advanced networking, custom connectors, code first workflow definitions and deep

1412
01:12:12,240 --> 01:12:13,600
DevOps integration.

1413
01:12:13,600 --> 01:12:18,160
It is the professional surface for building integration backbones, stateful orchestrations

1414
01:12:18,160 --> 01:12:20,120
and cross tenant coordination.

1415
01:12:20,120 --> 01:12:23,800
If an architect needs to build a nervous system that governs agent behavior across business

1416
01:12:23,800 --> 01:12:27,480
units and multiple entry directories, logic apps is the right tool.

1417
01:12:27,480 --> 01:12:30,400
The two platforms share the same underlying workflow engine.

1418
01:12:30,400 --> 01:12:32,880
They share many connectors and they can call each other.

1419
01:12:32,880 --> 01:12:35,440
A power automate flow can trigger a logic app.

1420
01:12:35,440 --> 01:12:37,640
A logic app can call a power automate flow.

1421
01:12:37,640 --> 01:12:39,240
This is not an either or choice.

1422
01:12:39,240 --> 01:12:43,400
It is a both and choice with each platform handling the layer where it is strongest.

1423
01:12:43,400 --> 01:12:46,080
The mistake is to try to make power automate do everything.

1424
01:12:46,080 --> 01:12:49,680
When a business user builds a flow that grows to touch five systems, handle error routing

1425
01:12:49,680 --> 01:12:54,080
and coordinate across tenants that flow has outgrown power automate.

1426
01:12:54,080 --> 01:12:57,920
It has become an integration workload that needs the governance, observability and life

1427
01:12:57,920 --> 01:13:00,280
cycle management that logic apps provides.

1428
01:13:00,280 --> 01:13:03,720
The correct response is not to restrict the business user's creativity.

1429
01:13:03,720 --> 01:13:07,680
It is to migrate that flow into logic app standard and expose it back to the business

1430
01:13:07,680 --> 01:13:11,280
user through a well-defined connector or HTTP endpoint.

1431
01:13:11,280 --> 01:13:13,840
The nervous system architecture does not replace power automate.

1432
01:13:13,840 --> 01:13:15,160
It elevates it.

1433
01:13:15,160 --> 01:13:17,920
Business users continue to build flows for local automation.

1434
01:13:17,920 --> 01:13:21,600
But when those flows need to participate in enterprise-wide processes, they call the

1435
01:13:21,600 --> 01:13:22,600
orchestrator.

1436
01:13:22,600 --> 01:13:24,560
The orchestrator handles the complexity.

1437
01:13:24,560 --> 01:13:28,720
The business user keeps the simplicity and the architecture scales without creating sprawl.

1438
01:13:28,720 --> 01:13:30,320
The economics of orchestration.

1439
01:13:30,320 --> 01:13:34,600
Before I close, let me address the question that every CFO and every IT budget owner will

1440
01:13:34,600 --> 01:13:35,600
ask.

1441
01:13:35,600 --> 01:13:37,800
They want to know what this costs and what it saves.

1442
01:13:37,800 --> 01:13:39,560
The cost side is straightforward.

1443
01:13:39,560 --> 01:13:43,640
Computable logic apps standard sits on either an app service plan or a functions premium

1444
01:13:43,640 --> 01:13:44,640
plan.

1445
01:13:44,640 --> 01:13:47,880
After an enterprise workload, you are looking at a few hundred to a few thousand dollars

1446
01:13:47,880 --> 01:13:52,440
per month in compute, depending on the number of instances, the geographic distribution,

1447
01:13:52,440 --> 01:13:55,000
and the storage requirements for stateful workflows.

1448
01:13:55,000 --> 01:13:58,840
This is predictable infrastructure cost, not per action billing that surprises you at

1449
01:13:58,840 --> 01:14:00,320
the end of the month.

1450
01:14:00,320 --> 01:14:02,760
Custom connectors add a small amount of development overhead.

1451
01:14:02,760 --> 01:14:06,000
You need someone who can write or maintain open API specifications.

1452
01:14:06,000 --> 01:14:09,280
You need a CICD pipeline that can deploy connector updates.

1453
01:14:09,280 --> 01:14:12,000
And you need governance review for each new connector operation.

1454
01:14:12,000 --> 01:14:13,000
This is not free.

1455
01:14:13,000 --> 01:14:17,320
But it is significantly cheaper than maintaining duplicate integration logic inside a dozen different

1456
01:14:17,320 --> 01:14:18,320
bots.

1457
01:14:18,320 --> 01:14:21,520
Workload identity federation requires andro configuration work.

1458
01:14:21,520 --> 01:14:26,080
Setting up federated credentials, cross tenant trust relationships, and conditional access policies

1459
01:14:26,080 --> 01:14:27,960
takes time from your identity team.

1460
01:14:27,960 --> 01:14:29,520
This is front loaded effort.

1461
01:14:29,520 --> 01:14:32,480
Once the trusts are configured, they run automatically.

1462
01:14:32,480 --> 01:14:36,200
And the ongoing operational cost is lower than the manual secret rotation and incident response

1463
01:14:36,200 --> 01:14:37,800
that client secrets demand.

1464
01:14:37,800 --> 01:14:40,480
The savings side is where the business case becomes compelling.

1465
01:14:40,480 --> 01:14:44,360
Every point to point integration that you replace with a connector based orchestration eliminates

1466
01:14:44,360 --> 01:14:45,360
duplicate logic.

1467
01:14:45,360 --> 01:14:50,320
When a business rule changes, you update the orchestrator once instead of updating six bots.

1468
01:14:50,320 --> 01:14:54,920
When an API changes, you update the custom connector once instead of fixing raw HTTP calls

1469
01:14:54,920 --> 01:14:56,840
scattered across multiple agents.

1470
01:14:56,840 --> 01:15:00,760
And when a credential needs rotation, you update the managed identity trust once instead

1471
01:15:00,760 --> 01:15:03,680
of scrambling to find every place a secret was embedded.

1472
01:15:03,680 --> 01:15:05,440
The bigger savings are in risk reduction.

1473
01:15:05,440 --> 01:15:10,920
A compliance audit that finds scattered credentials, undocumented API access, and inconsistent business

1474
01:15:10,920 --> 01:15:12,240
logic is expensive.

1475
01:15:12,240 --> 01:15:16,760
It triggers remediation projects, security reviews, and sometimes regulatory findings.

1476
01:15:16,760 --> 01:15:20,640
An orchestration architecture with centralized logging, managed identities, and governed

1477
01:15:20,640 --> 01:15:22,680
connectors is auditable by design.

1478
01:15:22,680 --> 01:15:27,440
The security team can answer questions about who can access what, when they access it, and

1479
01:15:27,440 --> 01:15:28,440
what they did.

1480
01:15:28,440 --> 01:15:29,440
This is not a soft benefit.

1481
01:15:29,440 --> 01:15:33,640
It is a hard cost avoidance that most organizations only appreciate after they have suffered

1482
01:15:33,640 --> 01:15:34,760
through a bad audit.

1483
01:15:34,760 --> 01:15:36,960
The team structure question is equally important.

1484
01:15:36,960 --> 01:15:39,600
You do not need a new army of Azure developers.

1485
01:15:39,600 --> 01:15:43,560
You need a small integration team, perhaps two or three people who understand logic, app

1486
01:15:43,560 --> 01:15:46,440
standard, intro identity, and open API.

1487
01:15:46,440 --> 01:15:50,760
They build the orchestrator, maintain the connectors, and manage the cross tenant trusts.

1488
01:15:50,760 --> 01:15:54,960
Business users and citizen developers continue to build agents in co-pilot studio and flows

1489
01:15:54,960 --> 01:15:56,280
in power automate.

1490
01:15:56,280 --> 01:15:59,200
But they call the orchestrator instead of wiring direct connections.

1491
01:15:59,200 --> 01:16:00,720
The division of labor is clean.

1492
01:16:00,720 --> 01:16:04,280
The skill requirements are reasonable, and the organizational change is smaller than most

1493
01:16:04,280 --> 01:16:05,280
people fear.

1494
01:16:05,280 --> 01:16:08,120
The return on investment for this architecture is not immediate.

1495
01:16:08,120 --> 01:16:09,120
It compounds.

1496
01:16:09,120 --> 01:16:11,200
Month one delivers a working pilot.

1497
01:16:11,200 --> 01:16:14,880
Month six delivers the first migrated process with measurable time savings.

1498
01:16:14,880 --> 01:16:18,880
Month 12 delivers audit ready governance, and the ability to add new agents without adding

1499
01:16:18,880 --> 01:16:20,120
new integration debt.

1500
01:16:20,120 --> 01:16:24,520
And month 18 delivers the strategic flexibility to adopt new AI models, new tenants, and

1501
01:16:24,520 --> 01:16:28,400
new business partnerships without rebuilding your integration layer from scratch.

1502
01:16:28,400 --> 01:16:29,640
That is the economics.

1503
01:16:29,640 --> 01:16:34,000
Front investment in architecture, ongoing savings in maintenance, and compounding returns in

1504
01:16:34,000 --> 01:16:36,080
speed security and scale.

1505
01:16:36,080 --> 01:16:40,760
The one question before your next agent project, before you greenlight your next co-pilot,

1506
01:16:40,760 --> 01:16:45,320
your next bot, or your next automation project, ask one question.

1507
01:16:45,320 --> 01:16:49,520
Consider whether this agent needs to coordinate with other agents, systems, or tenants to complete

1508
01:16:49,520 --> 01:16:50,960
a real business process.

1509
01:16:50,960 --> 01:16:53,360
If the answer is no, build it in isolation.

1510
01:16:53,360 --> 01:16:57,600
Use co-pilot studio, use power automate, solve the local problem, and move on.

1511
01:16:57,600 --> 01:17:01,440
But if the answer is yes, do not build another silo, do not wire another point to point

1512
01:17:01,440 --> 01:17:04,560
connection that your future self will curse in 12 months.

1513
01:17:04,560 --> 01:17:08,440
Do not pretend that a chatbot with direct API access is an enterprise architecture.

1514
01:17:08,440 --> 01:17:09,440
It is not.

1515
01:17:09,440 --> 01:17:11,360
It is a demo that escaped into production.

1516
01:17:11,360 --> 01:17:14,960
Instead build the nervous system first, design the orchestrator, define the connectors,

1517
01:17:14,960 --> 01:17:19,320
configure the identities, and then let your agents plug into something that can remember,

1518
01:17:19,320 --> 01:17:20,800
coordinate, and recover.

1519
01:17:20,800 --> 01:17:24,640
The agents will be thinner, they will be cheaper to maintain, and they will be capable

1520
01:17:24,640 --> 01:17:27,360
of things that isolated bots can never achieve.

1521
01:17:27,360 --> 01:17:31,200
This is the shift from building intelligent tools to building intelligent systems, tools

1522
01:17:31,200 --> 01:17:35,120
in press and demos, systems deliver in production, and the gap between the two is where most

1523
01:17:35,120 --> 01:17:37,600
agent investments go to die.

1524
01:17:37,600 --> 01:17:41,880
Agents do not fail because of bad AI, they fail because of missing orchestration.

1525
01:17:41,880 --> 01:17:46,560
Every impressive demo becomes a liability when it is wired directly to a dozen APIs, with

1526
01:17:46,560 --> 01:17:50,160
no central state, no cross tenant governance, and no recovery plan.

1527
01:17:50,160 --> 01:17:54,240
Azure Logic App Standard, stateful workflows, managed identities, custom connectors, and

1528
01:17:54,240 --> 01:17:58,600
workload identity federation form the nervous system that makes autonomous agents enterprise

1529
01:17:58,600 --> 01:17:59,600
ready.

1530
01:17:59,600 --> 01:18:01,560
Agents reason, orchestrators execute.

1531
01:18:01,560 --> 01:18:05,640
That is the architecture that scales across tenants, survives failures, and proves compliance

1532
01:18:05,640 --> 01:18:06,640
to auditors.

1533
01:18:06,640 --> 01:18:10,440
If this changed how you think about agent architecture, follow me on LinkedIn, and if you want the

1534
01:18:10,440 --> 01:18:15,400
next deep dive on deploying your first orchestrator in production, the next video in this series

1535
01:18:15,400 --> 01:18:16,480
is already in production.

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.