July 4, 2026

The Architect's Guide to Graph-Powered Agents: Moving Beyond Chat

Most organizations think they're building AI agents, but in reality they're still creating advanced chatbots. This episode explains why the future of Microsoft AI lies beyond conversational interfaces and focuses on Graph-powered, enterprise-grade agents that can understand business context, execute actions, and collaborate across multiple systems.

The discussion explores how Microsoft Graph serves as the operational backbone for intelligent agents by providing secure access to Microsoft 365 data, identities, files, Teams, Outlook, SharePoint, and business applications. Rather than relying on prompts alone, successful agents combine Graph, semantic context, orchestration, memory, and governance to deliver reliable business outcomes.

Listeners learn why enterprise AI requires architectural thinking instead of chatbot design. Topics include agent orchestration, delegated versus application permissions, event-driven workflows, Microsoft Graph APIs, knowledge retrieval, security boundaries, and lifecycle management. The episode also highlights the growing importance of standards such as the Model Context Protocol (MCP) for connecting agents with enterprise systems in a secure and scalable way.

A key message is that AI success depends on strong information architecture. Well-governed data, metadata, and knowledge models enable agents to reason accurately, while poor data quality leads to unreliable results regardless of the language model being used.

By the end of the episode, you'll understand why Graph-powered agents represent the next evolution of Microsoft 365 automation, how they differ from traditional Copilot chat experiences, and why architects should focus on designing intelligent, governed agent ecosystems that automate complete business processes instead of simply generating better answers.

You work in a world where graph-powered agents transform how organizations use ai. These agents move beyond simple chatbots. They use Microsoft Graph to access business data and execute tasks with accuracy. Recent industry reports show that advanced ai agents automate complex processes and boost productivity. You gain explainability, memory, and secure automation when you leverage graph database ai agents. Governance, compliance, and multi-agent orchestration matter when you design intelligent systems for enterprise environments.

Key Takeaways

Graph-powered agents go beyond chatbots by using advanced AI to automate complex tasks and improve productivity.
Microsoft Graph connects people and data, enabling agents to access the right information at the right time for better decision-making.
Architects can enhance workflows and decision-making by leveraging graph databases for context-aware AI systems.
Explainability in AI agents builds trust by allowing users to understand how decisions are made through transparent reasoning.
Persistent memory in agents helps avoid mistakes and improves adaptability by learning from past actions.
Security and compliance are crucial; implement strict permissions and monitoring to protect data and ensure agent accountability.
Multi-agent orchestration allows agents to collaborate effectively, improving task management and operational efficiency.
Using GraphRAG pipelines enhances the accuracy of AI responses by combining retrieval and generation for better contextual understanding.

What Are Graph-Powered Agents?

Evolution from Chatbots to AI Agents

You have likely seen chatbots answer simple questions or follow basic scripts. These tools work with fixed rules and cannot adapt to new situations. Modern ai agents change this landscape. They use advanced models and learn from every interaction. This shift allows them to handle complex tasks and make decisions on their own.

Here is a table that shows the main differences between traditional chatbots and modern ai agents:

Feature	Traditional Chatbots	Modern AI Agents
Architecture	Rule-based with predefined logic	Built around large language models (LLMs)
Learning and Adaptation	Limited or no memory of past interactions	Continuously learn and adapt from past conversations
Decision-making	Follows scripted flows without deeper analysis	Can autonomously make decisions based on complex data
Integration and Scalability	Requires manual intervention for new tasks	Seamlessly integrates with other systems and scales
Operational Efficiency	Frequent script adjustments needed	Uses feedback loops for continuous improvement
Training and Implementation	Extensive manual setup required	Faster and more intuitive deployment
Reasoning across turns	Rigid intent taxonomy, struggles with unpredictability	Can reason about tasks and maintain context

You can see that graph-powered agents go far beyond simple chatbots. They use graph database ai agents to connect information, remember past actions, and reason through multi-step problems.

Role of Microsoft Graph

Microsoft Graph acts as the digital nervous system for your organization. It connects people, documents, and workflows into a single knowledge graph. This structure lets ai agents access the right data at the right time. You can use Microsoft Graph to:

Orchestrate ai agents and give them access to business data and content.
Streamline workflows and boost productivity with Microsoft 365 Copilot.
Extend agent capabilities by connecting to other data sources through APIs.

With Microsoft Graph, you enable graph database ai agents to work together and automate business processes securely.

Why Architects Should Care

As an architect, you shape how your organization uses technology. Graph-powered agents help you automate workflows and improve decision-making. They use graph databases to create an integrated knowledge base. This approach gives your ai systems context-awareness, so they understand relationships and deliver relevant answers.

You benefit from:

Enhanced automation in enterprise workflows.
Context-aware ai that understands your organization’s needs.
Multi-step reasoning that allows agents to solve complex problems.
Explainable and logical ai behavior, which builds trust.
More time for higher-level tasks as agents handle routine work.

When you use graph-powered agents, you create a smarter, more efficient workplace. You also ensure that your solutions remain secure, scalable, and easy to govern.

Graph Database AI Agents: Core Principles

Explainability and Reasoning

Transparent Decision Paths

You want your agents to make decisions that you can understand and trust. Graph databases provide a rich context layer for ai, which helps you trace how agents reach their conclusions. When agents use a knowledge graph, they can cite specific relationships and facts that led to their recommendations. This transparency builds trust and makes it easier for you to explain ai-driven insights to stakeholders. In enterprise architecture, clear reasoning is essential for decision-making and compliance.

Graph databases help agents traverse complex relationships, such as organizational structures, to deliver context-aware responses.
You can see the relationships and facts used by agents, making their actions more auditable.
Agents can reference applications and connections from the knowledge graph, showing exactly how they arrived at their insights.

Visualizing Agent Logic

You gain a powerful advantage when you visualize agent logic. Graph-powered agents allow you to see the flow of information and the steps agents take to solve problems. This visualization helps you identify bottlenecks, optimize workflows, and ensure agents follow organizational policies. You can use tools that display the paths agents take through the knowledge graph, making their logic clear and easy to review.

Tip: Visualizing agent logic helps you spot errors early and improves the reliability of your ai systems.

Core Principle	Description
Complex Relationship Representation	Graph databases excel at representing intricate relationships between data points, unlike traditional databases.
Natural Language Understanding	They utilize advanced natural language processing to interpret user queries effectively.
Agent Orchestration	Frameworks like Langchain facilitate seamless interaction between users, language models, and databases.

Memory and Context with Knowledge Graphs

Persistent Organizational Memory

You need agents that remember past actions and learn from history. Knowledge graphs enhance organizational memory by structuring information as interconnected entities and relationships. This structure allows agents to maintain continuity in their understanding. Agents can avoid repeating mistakes and make informed decisions based on historical data. Persistent memory improves planning and adaptability, helping your organization grow smarter over time.

Contextual Data Retrieval

Agents must retrieve relevant information quickly and accurately. Graph databases enable contextual data retrieval by leveraging frameworks like GraphRAG. This approach uses graph-structured data to improve the accuracy and explainability of ai-generated responses. Agents can initiate searches using vector or full-text methods, then navigate relationships to gather additional context. Knowledge graphs represent both structured and unstructured data with interconnected elements, offering a flexible model for storing and querying complex information.

Note: Contextual retrieval ensures agents deliver answers that fit your organizational architecture and task requirements.

Security, Identity, and Governance

Agent Permissions and Compliance

You must protect your data and ensure agents operate within strict boundaries. Best practices include maintaining an agent registry, defining clear decision rights, and implementing centralized policy configuration. You should use narrow permission bundles and short-lived credentials for agents. Continuous authorization evaluates risk and policy at each action. Guardrails limit agent delegation and tool use, preventing impersonation and excessive privilege accumulation. Emergency controls, such as kill switches, allow fast response to threats.

Microsoft Graph addresses compliance and traceability requirements by integrating Microsoft Purview APIs. You can programmatically send prompts and responses from ai applications into Microsoft Purview for compliance tracking. Azure Admins enable settings without developer action, ensuring seamless support for governance.

Aspect	Description
Broad Vision and Guardrails	The knowledge graph offers a comprehensive context that helps agents operate within factual knowledge and policy constraints, reducing mistakes and ensuring compliance with regulations.
Enhanced Traceability	Every code change and deployment is linked to its origin, facilitating compliance with regulations and making audits and incident investigations more efficient by providing a clear narrative of changes.

Traceability and Auditability

You need to track every action agents take. Require a single identity for each agent to ensure accountability. Enforce consistent policies across platforms and observe agent activity continuously. Log every agent action with full context for auditability. Microsoft Purview settings embedded in Microsoft Foundry support audit and governance outcomes. Developers can use Microsoft Purview APIs to send data from ai applications for governance purposes.

Continuous monitoring identifies risks and compliance gaps.
Specialized controls prevent privilege accumulation and identity spoofing.
Audit logs provide a clear record for incident investigations.

Security and governance are essential for building trust in graph database ai agents and protecting your organizational architecture.

Building Graph-Powered Agents

You play a key role in building agents that drive organizational architecture forward. You need to select the right graph databases, integrate ai models, and orchestrate workflows for scalable solutions. This section gives you practical steps and considerations for each stage.

Selecting Graph Databases

Choosing the right graph databases shapes the performance and reliability of your graph-powered agents. You must evaluate both open-source graph databases and enterprise options to match your needs.

Open-Source and Enterprise Options

You find many open-source graph databases and enterprise platforms available. Open-source graph databases like FalkorDB, Neo4j Community, Memgraph, NebulaGraph, and ArangoDB offer flexibility and community support. Enterprise solutions such as Amazon Neptune, Neo4j Enterprise, TigerGraph, AllegroGraph, and Azure Cosmos DB provide advanced features and integration with business systems.

AllegroGraph stands out for building Context Graphs. It combines knowledge graphs, ontologies, and semantics, making it a strong choice for enterprise architecture. You can use AllegroGraph to scale agents and ensure trustworthy ai-driven insights.

Tip: Open-source graph databases help you experiment and prototype quickly. Enterprise platforms give you robust security and compliance for production environments.

Here is a comparison table to help you evaluate graph databases for ai agent development:

Graph Database	Latency Requirements	Infrastructure Compatibility	AI-Specific Tooling
FalkorDB	Sub-millisecond	Yes	Dedicated SDK
Neo4j Community	Moderate	Mature ecosystem	Lacks enterprise features
Apache AGE	Low	Postgres-native teams	Reduces operational overhead

Performance Considerations

You must consider latency, scalability, and compatibility when selecting graph databases. FalkorDB delivers sub-millisecond latency, which is critical for real-time ai applications. Neo4j Community offers a mature ecosystem but may lack enterprise features. Apache AGE fits teams using Postgres and reduces operational overhead.

You need to match the database to your workload. High-volume queries require low latency and strong infrastructure compatibility. AI-specific tooling helps you connect models and agents efficiently. You should also check support for concurrent consumers and memory management, which affect agent performance and reliability.

Integrating AI Models

You integrate ai models with graph databases to unlock advanced reasoning and memory for your agents. You must focus on security, deployment, and seamless connection to downstream applications.

Model Selection and Connection

You select ai models based on your organizational architecture and data requirements. You must implement data security and access controls for all components. Training data integrity ensures reliable insights and decision-making.

You integrate the DevOps pipeline with the MLOps pipeline to update graphs and scale agents. Good API support lets you connect graph content to applications. You monitor models after deployment to manage inaccuracies and maintain the knowledge graph.

Note: Performance at scale depends on data volume, query time, and support for concurrent users. You must validate data quality to avoid unreliable ai-driven insights.

Here are key considerations for integrating ai models:

Data and user security
Graph deployment model
Integration with downstream applications
Operations and maintenance
Performance at scale

You manage system complexity by building interconnected data structures. You balance speed and accuracy to maintain efficiency. Robust validation mechanisms protect your knowledge and memory from errors.

Structured Tool Calling and MCP

You use structured tool calling and the Model Context Protocol (MCP) to connect ai models with graph-powered agents. MCP provides a standardized framework that links ai systems to external tools and data sources. This enables efficient communication and dynamic context scoping.

MCP replaces fragmented integrations with a universal interface. It exposes app functionality through a machine-readable server, allowing structured requests for automation. Agents can take actions based on natural language instructions, which streamlines automation across teams.

Tip: Structured tool calling lets agents discover and invoke tools seamlessly. MCP enhances agent capabilities in managing and reasoning over graph data.

You use Microsoft Graph to connect agents to business data and workflows. MCP solves the NxM problem by providing a universal interface for ai integrations. You enable agents to automate tasks and deliver insights with dynamic context.

Workflow Orchestration

You orchestrate workflows to manage multi-agent collaboration and supervisory layers. Effective orchestration ensures agents work together, share memory, and deliver reliable outcomes.

Multi-Agent Collaboration

You deploy multiple agents to handle complex tasks. You must address challenges like communication, coordination, specialization, scalability, and cooperative behavior.

Challenges	Solutions
Effective communication	Message passing, shared memory, blackboard systems
Coordination among agents	Dynamic coordination, role assignment, task decomposition
Specialization of agents	Skill-based specialists, role-based team members
Scalability and fault tolerance	Modular, observable graphs for orchestration
Emergent cooperative behavior	Frameworks like LangGraph and AutoGen

You use message passing and shared memory to enable effective communication. Dynamic coordination and task decomposition help agents collaborate. Modular graphs improve scalability and fault tolerance. Frameworks like LangGraph and AutoGen support emergent cooperative behavior.

Tip: Assign roles and tasks to agents based on their skills. Use modular graphs to scale your system and maintain reliability.

Supervisory Layers

You implement supervisory layers to monitor agent activity and enforce guardrails. Supervisory layers provide oversight, conflict resolution, and observability. You use task routing engines, memory and state layers, and monitoring tools to manage workflows.

Here is a table of orchestration patterns:

Orchestration Pattern	Description	Use Case
Sequential	Executes tasks in a specific order	Customer support automation
Concurrent	Executes multiple tasks simultaneously	Data analysis and reporting
Group Chat	Facilitates communication among agents	Not specified
Handoff	Transfers tasks between agents	Customer support automation
Hierarchical	Organizes agents in a hierarchy	Software development pipelines

You use sequential patterns for customer support automation. Concurrent patterns help with data analysis and reporting. Hierarchical orchestration fits software development pipelines. You monitor agents and workflows to ensure compliance and reliability.

Supervisory layers help you maintain control, resolve conflicts, and optimize agent collaboration. You build resilient systems that deliver consistent insights and support decision-making.

You use Microsoft Graph to connect agents, manage memory, and enforce governance. You orchestrate workflows to scale your graph database ai agents and support enterprise architecture.

GraphRAG Pipelines in AI

Combining Retrieval and Generation

You use GraphRAG pipelines to boost the accuracy of ai agents. This method combines retrieval and generation, allowing agents to access structured knowledge and produce relevant answers. The knowledge graph for graphrag acts as a map of connected entities. You build memory into your system by extracting relationships from data and storing them in the knowledge graph. When agents receive a query, they perform retrieval by matching entities and traversing subgraphs. The retrieved context feeds into the language model, which generates answers based on the most relevant information.

GraphRAG pipelines follow a four-stage process. First, you ingest source documents. Second, you extract entities and relationships to build memory in the knowledge graph. Third, you perform retrieval by traversing subgraphs during query time. Fourth, you provide the retrieved subgraph as structured context for answer generation. This approach enables multi-hop reasoning, so agents can draw insights from several related pieces of knowledge instead of relying on isolated text segments.

You improve answer quality by combining retrieval with generation. This process helps agents deliver more faithful and relevant responses.

Enhancing Contextual Understanding

You want agents to understand context and recall memory accurately. GraphRAG pipelines help you achieve this by integrating retrieval with generation. The quality of metadata in your knowledge graph affects the reliability of the entire system. You must govern metadata to ensure agents retrieve trustworthy information. When you use retrieval in GraphRAG pipelines, you enable agents to recall memory and provide answers that fit your enterprise architecture.

Here is a comparison table showing how different retrieval systems perform:

System	Faithfulness	Answer Relevancy	Context Recall
HybridRAG	Superior	Superior	High
GraphRAG	Improved	Better	Moderate
VectorRAG	Lower	Good	High

You see that GraphRAG pipelines offer improved faithfulness and answer relevancy. HybridRAG systems provide the highest context recall, but GraphRAG pipelines balance memory and retrieval for enterprise applications.

Tip: Use governed metadata to strengthen memory and retrieval. This practice ensures agents deliver reliable insights.

Implementation Patterns

You build GraphRAG pipelines using several common patterns. Each pattern helps agents manage memory and retrieval for different tasks. You start with basic patterns like the Basic Retriever or Parent-Child Retriever. Intermediate patterns include Cypher Templates and Dynamic Cypher Generation. Advanced patterns use Graph-Enhanced Vector Search and Global Community Summary Retriever.

Here is a table of implementation patterns:

Pattern Type	Examples
Basic	Basic Retriever, Parent-Child Retriever, Hypothetical Question Retriever
Intermediate	Cypher Templates, Dynamic Cypher Generation, Text2Cypher
Advanced	Graph-Enhanced Vector Search, Global Community Summary Retriever

You follow these steps to build a GraphRAG pipeline:

Store knowledge in a knowledge graph.
Extract entities and ingest them into memory.
Use graph reasoning and retrieval to find relevant information.
Fuse context and construct prompts for agents.
Generate answers with the language model.

Note: Optimize retrieval speed and memory management for best performance. Monitor metadata quality to maintain reliable memory and retrieval.

You use GraphRAG pipelines to automate retrieval, enhance memory, and deliver actionable insights. This approach supports agents in enterprise architecture, helping you build systems that reason, recall memory, and generate answers with high accuracy.

Human–AI Organization Design

Multi-Agent Orchestration

You design human–ai organization systems to help agents collaborate and scale. Multi-agent orchestration uses a graph-based structure to connect people, processes, and technology. This structure improves feedback loops and makes task delegation easier. You move from rigid hierarchies to flexible networks. This shift encourages workflows that adapt quickly to change. When you integrate ai, you create a system where agents and humans work together. Many tech leaders believe that ai will change how organizations operate. You can see performance improvements of up to 2.5 times the baseline when you orchestrate human and ai teams well.

Key Insight	Explanation
Graph-based structure	Enhances connectivity and feedback loops for task delegation.
Shift from hierarchy to networks	Encourages workflows over traditional reporting structures.
Integration of AI	78% of tech leaders expect AI integration in organizational design.
Synergy coefficients	Human–AI orchestration can improve performance by 1.5-2.5x.
Importance of architecture	Poor integration can reduce overall intelligence.

Supervisory layers play a key role. You use these layers to monitor agent actions and maintain traceability. This approach ensures that every decision aligns with enterprise policies. You also gain better control over memory and knowledge sharing between agents.

Governance and Compliance

You must follow strict governance and compliance frameworks when you deploy agents in a human–ai organization. These frameworks help you manage risk and ensure that agents act within policy boundaries. You use platforms like Arthur, Credo AI, IBM watsonx.governance, OneTrust AI Governance, and Fiddler AI to support these needs. Each platform offers features such as self-correction, continuous evaluation, and real-time monitoring.

Platform	Key Features
Arthur	Self-correction, continuous evaluation, end-to-end observability, federated architecture.
Credo AI	Unified governance, risk and policy layer, agent registry, policy packs, governance knowledge graph.
IBM watsonx.governance	AI assurance, governance graph, integration with regulatory frameworks.
OneTrust AI Governance	Privacy and GRC workflows, policy management, inventory, approval workflows.
Fiddler AI	Drift detection, bias dashboards, explainability, real-time monitoring.

You use an enterprise knowledge graph to track agent actions and maintain audit trails. This practice strengthens compliance and supports enterprise architecture. You also ensure that agents have the right permissions and that their memory remains secure.

Organizational Impact

You see measurable impacts when you implement graph-powered agents in your human–ai organization. You lower operational costs by reducing escalations and human oversight. You achieve higher accuracy and consistency in outputs. You deploy and scale ai agents faster. You align agent actions with business policies. You also build holistic organizational memory, which improves decision-making. Richer context in your enterprise knowledge graph gives you a competitive edge. Stronger compliance and risk governance provide audit trails and reduce risk. You connect ai investments to business outcomes and lower technical debt.

Holistic organizational memory deepens procedural knowledge.
Competitive differentiation comes from richer context graphs.
Stronger compliance and risk governance improve audit trails.
Accelerated enterprise ROI links ai investments to outcomes.
Lower implementation cost reduces technical debt.

You create a human–ai organization that adapts, learns, and delivers insights. You use enterprise knowledge graph and memory to support agents and drive success.

Best Practices and Guardrails

Reliability and Robustness

You build reliable agents by following best practices and setting strong guardrails. Structured data models help you define relationships and data types clearly. This reduces guesswork and improves the accuracy of agent responses. Observability lets you monitor agent actions and reasoning. You can spot issues early and fix them before they affect your enterprise architecture. Knowledge graphs allow agents to create precise queries. This leads to deterministic answers and fewer errors in data retrieval.

Best Practice	Description
Structured Data Models	Use explicit models to define relationships and data types for accurate agent responses.
Observability	Monitor agent execution and reasoning to ensure reliable performance and quick issue detection.
Knowledge Graphs	Enable agents to construct precise queries and minimize errors in data retrieval.

You see real-world results when you apply these guardrails. A financial services firm improved fraud detection latency by 30% and reduced false positive resolution times by 40% with enhanced observability. In large API ecosystems, observability helped trace decision latencies and identify bottlenecks that affected user experience.

Transparency and User Trust

You maintain user trust by making agent actions explainable. Guardrails support transparency at every layer. Policy guardrails set ethical guidelines for ai use and user engagement. Procedural guardrails create processes for user feedback and system adaptation. Technical guardrails ensure reliability and transparency in agent operations. Social guardrails focus on continuous feedback and explainable ai, helping users understand agent decisions.

Layer Type	Description
Policy	Sets ethical guidelines for ai and user engagement.
Procedural	Creates feedback processes and adapts systems based on user input.
Technical	Ensures reliability and transparency in agent operations.
Social	Maintains user trust through feedback and explainable ai.

You build trust by showing how agents reach their insights. Explainable ai helps users see the logic behind agent decisions. Guardrails make every step clear and auditable.

Tip: Use explainable ai and feedback loops to strengthen user trust and improve system transparency.

Security and Access Control

You protect enterprise data by enforcing security guardrails. Authentication verifies user identity and prevents unauthorized access. Authorization manages user permissions with role-based access control and least privilege. Encryption secures data at rest and in transit. Auditing logs agent actions and ensures compliance with regulations.

Security Measure	Description
Authentication	Verifies identity using methods like 2FA and biometrics.
Authorization	Manages access with role-based controls and least privilege.
Encryption	Secures data at rest and in transit.
Auditing	Logs actions for compliance and detects suspicious activity.

Microsoft Graph provides strong guardrails for governance and compliance. You use Microsoft Purview to track agent actions and maintain audit trails. Guardrails ensure every agent operates within policy boundaries and keeps your enterprise architecture secure.

Note: Guardrails protect your data, maintain compliance, and support explainable ai in every agent deployment.

Implementation Examples

Sample Architectures

You can design robust systems by combining Microsoft Graph with open-source graph technology. These architectures support scalable agent deployments and secure information flow. The following table highlights resources that help you build and manage graph-powered agents:

Resource	Description
Foundry Agent Service documentation	Fully managed service for building, deploying, and scaling agents; integrates with OpenAI Responses API.
Microsoft Agent Framework documentation	Next generation framework for building graph-based workflows and multi-agent orchestration.
Multi-Agent Reference Architecture	Patterns and building blocks for enterprise multi-agent systems, including orchestration and security.

You can also explore these practical guides:

These resources show how to connect agents, manage workflows, and ensure secure information flow across your enterprise architecture.

Code Patterns

You can implement scalable solutions using proven code patterns. GraphRAG improves retrieval-augmented generation by structuring knowledge into a graph. This approach supports deeper reasoning and more accurate insights. You can use dynamic agent selection to manage latency and cost, and standardized onboarding methods to add new agents quickly. The factory design pattern allows you to create flexible agent instances. Supervisor-orchestrated group chat enables agents to handle multiple intents in a single conversation.

Here is a typical workflow for building a graph-powered agent:

Construct a knowledge graph by extracting entities and relationships from documents.
Convert user queries into graph-based queries.
Extract relevant subgraphs and encode them for processing.
Retrieve context from the subgraph and feed it to the language model.
Generate responses using structured information and context.

You can optimize information flow by using single-intent fast paths, controlling chattiness, and tuning model parameters.

# Example: Subgraph extraction for contextual retrieval
def extract_subgraph(query, knowledge_graph):
    entities = find_entities(query)
    subgraph = knowledge_graph.get_subgraph(entities)
    return subgraph

Performance Optimization

You can boost performance in large-scale deployments by focusing on information flow and communication topology. Optimizing how agents communicate is essential for real-world tasks. You can measure edge importance, use graph autoencoder optimization, or apply reinforcement learning to improve your system. Profiling helps you find bottlenecks, while load testing and monitoring ensure your agents run smoothly.

A strong framework combines localization, graph embedding, and topology control. This approach adapts to device differences and changing network conditions. You can use tools like the NVIDIA NeMo Agent Toolkit to deploy and scale applications, always monitoring information flow for best results.

Tip: Regular profiling and monitoring help you maintain high performance and reliable information flow in your graph-powered agent systems.

You can lead enterprise architecture into the future by designing graph-powered agents. Start with a clear checklist: select the right graph database, connect Microsoft Graph, and build strong feedback loops. Use feedback loops to improve agent reasoning, monitor workflows, and ensure compliance. Feedback loops help you adapt quickly and keep your systems reliable. Explore GraphRAG pipelines and multi-agent orchestration to create feedback loops that drive innovation. Feedback loops will shape the next generation of human–AI organization.

FAQ

What is a graph-powered agent?

You use a graph-powered agent to automate tasks and make decisions. It connects to a knowledge graph, understands relationships, and reasons through complex problems. This agent helps you improve accuracy and efficiency in your organization.

How does Microsoft Graph support agent development?

Microsoft Graph connects your people, documents, and workflows. You use it to give agents secure access to business data. This foundation helps you build agents that automate processes and deliver real results.

Why is explainability important in AI agents?

You need to trust your AI agents. Explainability lets you see how agents make decisions. This builds confidence and helps you meet compliance requirements. You can review each step the agent takes.

How do graph-powered agents improve organizational intelligence?

You gain organizational intelligence when agents use knowledge graphs. These agents connect data, remember past actions, and share insights. This helps your teams make better decisions and adapt quickly.

What security features protect my data with graph-powered agents?

You control access with authentication and authorization. Microsoft Graph uses strong security measures. You can track every agent action with audit logs. This keeps your data safe and supports compliance.

Can I use multiple agents together in my organization?

Yes, you can deploy several agents to handle different tasks. Multi-agent orchestration lets agents collaborate, share memory, and solve complex problems. You manage these agents with supervisory layers for better control.

How do graph-powered agents scale in large enterprises?

You scale agents by choosing the right graph database and using workflow orchestration. Microsoft Graph and enterprise tools help you manage many agents. This supports growth and maintains high performance.

What is the impact of graph-powered agents on organizational intelligence?

You see a boost in organizational intelligence when agents automate workflows and share knowledge. This leads to faster decisions, improved accuracy, and a smarter workplace.

🚀 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:02,720
Right now, someone in your company is building an AI agent.

2
00:00:02,720 --> 00:00:04,440
They're using chat GPT or Claude.

3
00:00:04,440 --> 00:00:05,720
They're uploading some files.

4
00:00:05,720 --> 00:00:08,120
They're calling it a solution and they're wrong.

5
00:00:08,120 --> 00:00:10,600
The assumption killing most agent projects is this.

6
00:00:10,600 --> 00:00:13,200
Agents are just chat interfaces, smarter chatbots,

7
00:00:13,200 --> 00:00:15,440
better search, flashier conversations.

8
00:00:15,440 --> 00:00:16,840
The reality is harder.

9
00:00:16,840 --> 00:00:19,120
An agent without the Microsoft Graph is disconnected

10
00:00:19,120 --> 00:00:20,280
from your business logic.

11
00:00:20,280 --> 00:00:22,320
It can talk, it can generate text,

12
00:00:22,320 --> 00:00:24,920
but it doesn't know what your organization actually does.

13
00:00:24,920 --> 00:00:26,880
It doesn't understand who reports to whom,

14
00:00:26,880 --> 00:00:29,000
where the data flows or why you make decisions

15
00:00:29,000 --> 00:00:29,800
the way you do.

16
00:00:29,800 --> 00:00:31,880
In this episode, we're going beyond the hype.

17
00:00:31,880 --> 00:00:34,160
We're talking about why the graph isn't just an extra layer

18
00:00:34,160 --> 00:00:35,760
you bolt onto an AI system.

19
00:00:35,760 --> 00:00:37,000
It's the structural foundation.

20
00:00:37,000 --> 00:00:39,360
It's the difference between an AI that hallucinates

21
00:00:39,360 --> 00:00:41,360
and an AI that acts with authority.

22
00:00:41,360 --> 00:00:42,320
Who is this for?

23
00:00:42,320 --> 00:00:43,560
You.

24
00:00:43,560 --> 00:00:45,960
If you're an architect deciding if agents are a toy

25
00:00:45,960 --> 00:00:47,400
or a transformation tool,

26
00:00:47,400 --> 00:00:50,200
if you're responsible for systems that touch customer data,

27
00:00:50,200 --> 00:00:52,440
employee records or critical workflows,

28
00:00:52,440 --> 00:00:54,120
if you're sitting in a room where someone says,

29
00:00:54,120 --> 00:00:55,960
let's build an agent and you need to know

30
00:00:55,960 --> 00:00:58,480
if that's a three month project or a three year mistake.

31
00:00:58,480 --> 00:00:59,760
Here are the stakes.

32
00:00:59,760 --> 00:01:02,560
74% of enterprises are running agents right now,

33
00:01:02,560 --> 00:01:05,160
but only 21% have governance that actually works.

34
00:01:05,160 --> 00:01:07,200
That gap isn't closing, it's widening.

35
00:01:07,200 --> 00:01:09,160
And the organizations that close at first

36
00:01:09,160 --> 00:01:11,080
will move faster than everyone else.

37
00:01:11,080 --> 00:01:15,560
The context gap, why LLM's alone fail in enterprise.

38
00:01:15,560 --> 00:01:17,000
Let's start with the foundation.

39
00:01:17,000 --> 00:01:18,000
What is an LLM?

40
00:01:18,000 --> 00:01:20,680
It's a pattern matching engine trained on public data.

41
00:01:20,680 --> 00:01:22,840
It sees patterns in text and predicts what comes next.

42
00:01:22,840 --> 00:01:24,080
That's extraordinary,

43
00:01:24,080 --> 00:01:26,920
but it's also completely disconnected from your organization.

44
00:01:26,920 --> 00:01:29,520
When you ask an LLM about your business, it knows nothing.

45
00:01:29,520 --> 00:01:31,200
It has never seen your org chart.

46
00:01:31,200 --> 00:01:32,960
It doesn't know which systems talk to each other.

47
00:01:32,960 --> 00:01:36,040
It has no idea what approved means in your company

48
00:01:36,040 --> 00:01:38,640
or what happens when an agent tries to move a million dollars

49
00:01:38,640 --> 00:01:39,640
without authorization.

50
00:01:39,640 --> 00:01:40,640
So what happens?

51
00:01:40,640 --> 00:01:41,760
The model guesses.

52
00:01:41,760 --> 00:01:43,120
And when it guesses about your business,

53
00:01:43,120 --> 00:01:46,480
you get hallucinations, not harmless ones, expensive ones.

54
00:01:46,480 --> 00:01:49,760
A support agent tells a customer their orders shipped

55
00:01:49,760 --> 00:01:52,080
when it didn't, a recruiting agent schedules interviews

56
00:01:52,080 --> 00:01:53,360
in the wrong time zone.

57
00:01:53,360 --> 00:01:54,960
An operations agent recommends a change

58
00:01:54,960 --> 00:01:56,440
that breaks your infrastructure.

59
00:01:56,440 --> 00:01:59,400
Enterprise agents need three things, context, memory,

60
00:01:59,400 --> 00:02:00,680
and the ability to act.

61
00:02:00,680 --> 00:02:03,000
Context means understanding what's actually happening

62
00:02:03,000 --> 00:02:04,880
in your organization right now.

63
00:02:04,880 --> 00:02:07,080
Not what training data says companies generally do,

64
00:02:07,080 --> 00:02:09,080
what you do, how meetings get scheduled,

65
00:02:09,080 --> 00:02:11,440
who can approve what, what data is sensitive,

66
00:02:11,440 --> 00:02:12,640
and what is public.

67
00:02:12,640 --> 00:02:14,440
The difference between knowing about something

68
00:02:14,440 --> 00:02:16,560
and understanding it is that understanding happens

69
00:02:16,560 --> 00:02:19,320
when the model reasons about your specific reality,

70
00:02:19,320 --> 00:02:21,360
not patterns it saw in a data set.

71
00:02:21,360 --> 00:02:23,200
Memory means an agent doesn't start from zero

72
00:02:23,200 --> 00:02:24,520
every time you talk to it.

73
00:02:24,520 --> 00:02:25,920
It knows what happened last week.

74
00:02:25,920 --> 00:02:27,840
It understands the history of a transaction.

75
00:02:27,840 --> 00:02:30,080
It can track state across conversations.

76
00:02:30,080 --> 00:02:32,920
It can say we tried that approach already and it didn't work.

77
00:02:32,920 --> 00:02:35,000
The ability to act means an agent isn't just

78
00:02:35,000 --> 00:02:36,080
a fancy search engine.

79
00:02:36,080 --> 00:02:39,040
It can schedule meetings, send emails and create tasks.

80
00:02:39,040 --> 00:02:40,720
It can update records and make decisions

81
00:02:40,720 --> 00:02:42,320
and execute them with authority.

82
00:02:42,320 --> 00:02:45,000
An agent that can only read is not really an agent.

83
00:02:45,000 --> 00:02:46,880
It's just a retrieval system with attitude.

84
00:02:46,880 --> 00:02:49,640
Without those three things, context from your organization,

85
00:02:49,640 --> 00:02:51,720
memory of what happened and authority to act,

86
00:02:51,720 --> 00:02:52,720
you don't have an agent.

87
00:02:52,720 --> 00:02:54,240
You have a chatbot that sounds smart

88
00:02:54,240 --> 00:02:56,360
and hallucinates expensive mistakes.

89
00:02:56,360 --> 00:02:58,880
The Microsoft graph is where all three of these requirements

90
00:02:58,880 --> 00:03:00,080
come together.

91
00:03:00,080 --> 00:03:01,760
Graph as enterprise memory.

92
00:03:01,760 --> 00:03:03,560
Microsoft Graph is not an API.

93
00:03:03,560 --> 00:03:05,240
That is the first thing you have to understand.

94
00:03:05,240 --> 00:03:06,840
Technically, yes, it is an API.

95
00:03:06,840 --> 00:03:08,600
You can call it and send rest requests.

96
00:03:08,600 --> 00:03:10,880
But if you think of it as just another endpoint,

97
00:03:10,880 --> 00:03:12,720
you are missing the architecture entirely.

98
00:03:12,720 --> 00:03:14,760
Graph is the organizational nervous system.

99
00:03:14,760 --> 00:03:17,080
It is the system that knows how your company actually works.

100
00:03:17,080 --> 00:03:20,240
Inside Graph sits 20 years of communication patterns.

101
00:03:20,240 --> 00:03:22,240
These are not archived emails or all documents

102
00:03:22,240 --> 00:03:23,560
sitting in cold storage.

103
00:03:23,560 --> 00:03:25,360
These are living, queryable relationships.

104
00:03:25,360 --> 00:03:26,840
It knows who talks to whom.

105
00:03:26,840 --> 00:03:29,680
It sees how decisions propagate through the organization.

106
00:03:29,680 --> 00:03:31,960
It tracks what gets approved and what gets blocked.

107
00:03:31,960 --> 00:03:34,120
It knows which teams collaborate across boundaries

108
00:03:34,120 --> 00:03:35,920
and which ones never speak to each other.

109
00:03:35,920 --> 00:03:38,600
It identifies the individuals who hold institutional knowledge

110
00:03:38,600 --> 00:03:39,840
that nobody else has.

111
00:03:39,840 --> 00:03:41,320
This is not transactional data.

112
00:03:41,320 --> 00:03:43,840
Transactional data is just a record of what happened.

113
00:03:43,840 --> 00:03:44,840
A meeting was scheduled.

114
00:03:44,840 --> 00:03:47,000
A document was created, a task was assigned.

115
00:03:47,000 --> 00:03:48,080
Those are just events.

116
00:03:48,080 --> 00:03:49,600
They are snapshots.

117
00:03:49,600 --> 00:03:51,800
What graph contains is behavioral intelligence.

118
00:03:51,800 --> 00:03:54,760
It sees the pattern of who initiates meetings with whom.

119
00:03:54,760 --> 00:03:58,120
It understands the structure of which teams rely on each other

120
00:03:58,120 --> 00:03:58,880
to get work done.

121
00:03:58,880 --> 00:04:01,120
It knows which communication channels actually

122
00:04:01,120 --> 00:04:03,520
move decisions forward and which ones are just noise.

123
00:04:03,520 --> 00:04:05,480
It understands that when finance and engineering

124
00:04:05,480 --> 00:04:08,520
both talk to product, something important is being decided.

125
00:04:08,520 --> 00:04:09,880
When you look at your share point sites,

126
00:04:09,880 --> 00:04:11,520
your team's channels, your outlook calendars

127
00:04:11,520 --> 00:04:14,000
and your one drive folders, you are looking at fragments,

128
00:04:14,000 --> 00:04:17,120
individual systems, separate tools.

129
00:04:17,120 --> 00:04:19,200
What you are actually looking at is a knowledge graph,

130
00:04:19,200 --> 00:04:21,720
a connected structure of entities and relationships

131
00:04:21,720 --> 00:04:24,400
that the problem is that the connections are invisible.

132
00:04:24,400 --> 00:04:26,400
They are distributed across multiple systems.

133
00:04:26,400 --> 00:04:29,640
An agent cannot see the structure unless graph stitches it together.

134
00:04:29,640 --> 00:04:30,560
That is what graph does.

135
00:04:30,560 --> 00:04:33,760
It unifies those fragments into a single queryable model.

136
00:04:33,760 --> 00:04:35,760
Your team's data does not live in a separate silo

137
00:04:35,760 --> 00:04:37,680
from your outlook or share point data.

138
00:04:37,680 --> 00:04:39,240
Graph sees them as one organism.

139
00:04:39,240 --> 00:04:41,600
It is one connected system that shows the actual flow

140
00:04:41,600 --> 00:04:43,640
of work and information through your company.

141
00:04:43,640 --> 00:04:47,040
This is how agents discover what your organization actually knows.

142
00:04:47,040 --> 00:04:48,880
An agent can ask who in the company

143
00:04:48,880 --> 00:04:51,800
understands how to onboard a customer in Europe.

144
00:04:51,800 --> 00:04:54,480
Without graph, the model would guess based on titles

145
00:04:54,480 --> 00:04:55,840
or previous conversations.

146
00:04:55,840 --> 00:04:58,080
With graph, the agent can trace actual patterns.

147
00:04:58,080 --> 00:05:01,280
It sees which people participate in European onboarding conversations.

148
00:05:01,280 --> 00:05:04,640
It identifies who sends emails about European compliance.

149
00:05:04,640 --> 00:05:07,920
It knows which teams channels discuss European workflow.

150
00:05:07,920 --> 00:05:10,520
The agent is not searching for people who claim to know something.

151
00:05:10,520 --> 00:05:13,400
It is finding people whose behavior proves they know something.

152
00:05:13,400 --> 00:05:16,320
That distinction matters because the signal is not documents.

153
00:05:16,320 --> 00:05:20,520
Most organizations have mountains of documentation that nobody ever reads.

154
00:05:20,520 --> 00:05:22,880
Procedure manuals, playbooks, policy guides,

155
00:05:22,880 --> 00:05:24,840
they sit in SharePoint gathering dust.

156
00:05:24,840 --> 00:05:27,120
An agent that searches for documents finds noise.

157
00:05:27,120 --> 00:05:28,840
The signal that matters is behavior.

158
00:05:28,840 --> 00:05:30,840
How do people actually use systems?

159
00:05:30,840 --> 00:05:31,880
Which messages get read?

160
00:05:31,880 --> 00:05:33,560
Which documents get shared and reshared?

161
00:05:33,560 --> 00:05:35,600
Which workflows actually get executed?

162
00:05:35,600 --> 00:05:39,320
Behavioral intelligence tells an agent what is real versus what is theoretical.

163
00:05:39,320 --> 00:05:42,720
It shows what people actually do versus what the handbook says they should do.

164
00:05:42,720 --> 00:05:46,040
When graph pulls in that behavioral layer, it transforms context.

165
00:05:46,040 --> 00:05:49,240
An agent no longer has to reason about your organization blindly.

166
00:05:49,240 --> 00:05:51,400
It has a map of how work actually flows.

167
00:05:51,400 --> 00:05:52,840
It knows which decisions matter.

168
00:05:52,840 --> 00:05:54,880
It understands the hidden dependencies.

169
00:05:54,880 --> 00:05:58,160
It sees which individuals are irreplaceable because their knowledge is woven

170
00:05:58,160 --> 00:05:59,880
into the fabric of how decisions get made.

171
00:05:59,880 --> 00:06:01,440
That context is the first piece.

172
00:06:01,440 --> 00:06:04,480
But context is only useful if an agent can do something with it.

173
00:06:04,480 --> 00:06:06,280
But discovery is only half the problem.

174
00:06:06,280 --> 00:06:07,880
Agents also need to act.

175
00:06:07,880 --> 00:06:10,760
Read access versus write access, the permission boundary.

176
00:06:10,760 --> 00:06:12,960
Here is where most agent deployments store.

177
00:06:12,960 --> 00:06:16,040
Right now the vast majority of agents in production are read only.

178
00:06:16,040 --> 00:06:17,560
They can retrieve information.

179
00:06:17,560 --> 00:06:19,720
They can analyze what is in your systems.

180
00:06:19,720 --> 00:06:21,200
They can surface insights.

181
00:06:21,200 --> 00:06:22,440
But they cannot change anything.

182
00:06:22,440 --> 00:06:23,160
They cannot write.

183
00:06:23,160 --> 00:06:23,920
They cannot create.

184
00:06:23,920 --> 00:06:24,760
They cannot execute.

185
00:06:24,760 --> 00:06:25,800
This is not accidental.

186
00:06:25,800 --> 00:06:27,000
It is deliberate.

187
00:06:27,000 --> 00:06:30,280
Organizations default to read only because it feels safer.

188
00:06:30,280 --> 00:06:32,480
If an agent can only look at data, the argument goes,

189
00:06:32,480 --> 00:06:33,960
"What is the worst that can happen?"

190
00:06:33,960 --> 00:06:35,080
It might give you a wrong answer.

191
00:06:35,080 --> 00:06:36,040
It might hallucinate.

192
00:06:36,040 --> 00:06:37,360
But it cannot break anything.

193
00:06:37,360 --> 00:06:40,800
That logic collapses the moment you understand what agents are actually for.

194
00:06:40,800 --> 00:06:43,600
Read only agents are search engines wearing a trench coat.

195
00:06:43,600 --> 00:06:44,920
They are better search engines.

196
00:06:44,920 --> 00:06:45,680
They are faster.

197
00:06:45,680 --> 00:06:48,320
They can reason over your data in ways a keyword search cannot.

198
00:06:48,320 --> 00:06:49,360
But they are not agents.

199
00:06:49,360 --> 00:06:50,480
They are not automating work.

200
00:06:50,480 --> 00:06:53,640
They are surfacing information and asking humans to act on it.

201
00:06:53,640 --> 00:06:56,080
Which means the bottleneck moves, but it does not disappear.

202
00:06:56,080 --> 00:06:58,280
You still need someone to read the agent's recommendation

203
00:06:58,280 --> 00:07:00,040
and then go manually executed.

204
00:07:00,040 --> 00:07:02,640
The real value unlock happens when agents can write.

205
00:07:02,640 --> 00:07:05,320
When they can schedule meetings instead of recommending times.

206
00:07:05,320 --> 00:07:07,760
When they can send emails instead of drafting them.

207
00:07:07,760 --> 00:07:09,880
When they can create tasks instead of listing

208
00:07:09,880 --> 00:07:11,000
what needs to be done.

209
00:07:11,000 --> 00:07:14,560
When they can update records instead of flagging which records need updating.

210
00:07:14,560 --> 00:07:18,120
That is when you move from agent as assistant to agent as worker.

211
00:07:18,120 --> 00:07:20,520
But right access is where governance gets complicated.

212
00:07:20,520 --> 00:07:23,920
Because read access and right access are not on the same spectrum.

213
00:07:23,920 --> 00:07:25,640
They are different categories entirely.

214
00:07:25,640 --> 00:07:27,000
Read access is bounded.

215
00:07:27,000 --> 00:07:29,360
An agent reads what it has been given permission to read.

216
00:07:29,360 --> 00:07:31,960
If it reads something wrong, the error is in interpretation,

217
00:07:31,960 --> 00:07:33,480
not in system integrity.

218
00:07:33,480 --> 00:07:34,800
The data is unchanged.

219
00:07:34,800 --> 00:07:36,640
The organization's state is unchanged.

220
00:07:36,640 --> 00:07:38,240
Right access crosses a line.

221
00:07:38,240 --> 00:07:41,080
When an agent writes, it changes the state of the organization.

222
00:07:41,080 --> 00:07:43,560
It creates facts that other systems depend on.

223
00:07:43,560 --> 00:07:46,120
It makes decisions that affect other people's work.

224
00:07:46,120 --> 00:07:49,840
It commits the organization to actions that have downstream consequences.

225
00:07:49,840 --> 00:07:52,280
That is what right access means in a governance context.

226
00:07:52,280 --> 00:07:55,040
It is not just permission to modify a database field.

227
00:07:55,040 --> 00:07:57,760
It is authorization to act on behalf of the organization.

228
00:07:57,760 --> 00:07:59,240
To speak for the organization.

229
00:07:59,240 --> 00:08:02,280
To change what is true in the organization's systems of record.

230
00:08:02,280 --> 00:08:03,800
Most deployments fail at this boundary

231
00:08:03,800 --> 00:08:05,560
because they do not think about it clearly.

232
00:08:05,560 --> 00:08:07,120
The solution is a three tier model.

233
00:08:07,120 --> 00:08:09,960
First, you have read only where agents can retrieve information

234
00:08:09,960 --> 00:08:11,400
but cannot modify it.

235
00:08:11,400 --> 00:08:12,960
Second, you have conditional write.

236
00:08:12,960 --> 00:08:15,840
This is where agents can make changes within defined bounds.

237
00:08:15,840 --> 00:08:18,480
They can schedule a meeting, but only within business hours.

238
00:08:18,480 --> 00:08:22,360
They can create a task, but only if it is below a cost threshold.

239
00:08:22,360 --> 00:08:25,440
They can send an email, but only to internal recipients.

240
00:08:25,440 --> 00:08:27,360
Third, you have human approved write.

241
00:08:27,360 --> 00:08:29,360
This is where the agent proposes an action,

242
00:08:29,360 --> 00:08:32,160
presents evidence to a human, and waits for authorization

243
00:08:32,160 --> 00:08:33,320
before executing.

244
00:08:33,320 --> 00:08:35,480
Why do most deployments fail between these tiers?

245
00:08:35,480 --> 00:08:37,200
Because the boundaries are fuzzy.

246
00:08:37,200 --> 00:08:39,480
An organization says agents can write

247
00:08:39,480 --> 00:08:41,120
without defining what that means.

248
00:08:41,120 --> 00:08:42,840
An agent gets broad permissions.

249
00:08:42,840 --> 00:08:45,760
It makes a decision that seemed reasonable in isolation

250
00:08:45,760 --> 00:08:47,880
but breaks something downstream.

251
00:08:47,880 --> 00:08:49,680
A marketing agent schedules a customer call

252
00:08:49,680 --> 00:08:51,680
for a time when the sales team is in a meeting.

253
00:08:51,680 --> 00:08:54,280
An IT agent creates an account with too much privilege.

254
00:08:54,280 --> 00:08:57,880
An HR agent sends an offer before the background check completes.

255
00:08:57,880 --> 00:09:00,240
The failures are not failures of AI capability.

256
00:09:00,240 --> 00:09:02,480
They are failures of governance clarity,

257
00:09:02,480 --> 00:09:05,200
which is why every write must be logged and attributable.

258
00:09:05,200 --> 00:09:07,720
Not just something changed, but who authorized it?

259
00:09:07,720 --> 00:09:09,400
What the agent was asked to do?

260
00:09:09,400 --> 00:09:10,600
What evidence it considered?

261
00:09:10,600 --> 00:09:12,040
What it decided and why?

262
00:09:12,040 --> 00:09:14,560
If something goes wrong, you need to reconstruct the decision

263
00:09:14,560 --> 00:09:17,520
chain and understand where the governance boundary broke.

264
00:09:17,520 --> 00:09:20,880
That audit trail is the difference between authorized agent action

265
00:09:20,880 --> 00:09:22,560
and rogue automation.

266
00:09:22,560 --> 00:09:25,440
Tool calling, the bridge between agents and systems.

267
00:09:25,440 --> 00:09:26,680
Now let's get practical.

268
00:09:26,680 --> 00:09:28,800
How does an agent actually connect a graph?

269
00:09:28,800 --> 00:09:32,480
How does it move from understanding context to executing actions?

270
00:09:32,480 --> 00:09:33,640
The answer is tool calling.

271
00:09:33,640 --> 00:09:36,480
This is the mechanism that sits between the model and the system.

272
00:09:36,480 --> 00:09:37,880
It's how the agent decides what to do.

273
00:09:37,880 --> 00:09:39,040
Here's what happens.

274
00:09:39,040 --> 00:09:40,840
You ask an agent a scheduler meeting.

275
00:09:40,840 --> 00:09:42,840
The model doesn't generate a calendar entry directly.

276
00:09:42,840 --> 00:09:45,680
Instead, it recognizes that the user's request requires

277
00:09:45,680 --> 00:09:47,360
a specific function to be invoked.

278
00:09:47,360 --> 00:09:50,600
It decides, I need to call the schedule meeting function.

279
00:09:50,600 --> 00:09:53,000
It determines what parameters that function needs.

280
00:09:53,000 --> 00:09:55,880
Who should attend what time, which room or team's link?

281
00:09:55,880 --> 00:09:58,240
Then it packages that decision as a structured request.

282
00:09:58,240 --> 00:10:01,360
That's tool calling, the LLM deciding which function

283
00:10:01,360 --> 00:10:03,400
to invoke and with what arguments.

284
00:10:03,400 --> 00:10:05,440
Now, there's a difference between function calling

285
00:10:05,440 --> 00:10:08,560
and structured tool use and that distinction matters architecturally.

286
00:10:08,560 --> 00:10:10,960
Function calling is what Azure OpenAI gives you.

287
00:10:10,960 --> 00:10:13,920
You define a set of functions with schemers, name, description,

288
00:10:13,920 --> 00:10:14,960
parameters.

289
00:10:14,960 --> 00:10:16,960
You send those schemers along with your prompt.

290
00:10:16,960 --> 00:10:18,680
The model reads the schemers and decides

291
00:10:18,680 --> 00:10:22,080
whether to call a function, which one, and with what arguments.

292
00:10:22,080 --> 00:10:23,560
It returns a structured response.

293
00:10:23,560 --> 00:10:26,200
You then execute the actual function outside the model.

294
00:10:26,200 --> 00:10:28,000
The result comes back to the model, which

295
00:10:28,000 --> 00:10:30,160
reasons over it and generates a response.

296
00:10:30,160 --> 00:10:31,360
This is the baseline.

297
00:10:31,360 --> 00:10:33,080
Azure OpenAI Function calling works.

298
00:10:33,080 --> 00:10:34,600
It's production ready.

299
00:10:34,600 --> 00:10:36,800
Major agent frameworks build on top of it.

300
00:10:36,800 --> 00:10:39,040
But raw function calling has a limitation.

301
00:10:39,040 --> 00:10:40,280
It's stateless.

302
00:10:40,280 --> 00:10:41,960
Each call is isolated.

303
00:10:41,960 --> 00:10:43,080
The model makes a decision.

304
00:10:43,080 --> 00:10:43,920
You execute it.

305
00:10:43,920 --> 00:10:44,960
The model sees the result.

306
00:10:44,960 --> 00:10:47,120
It makes another decision.

307
00:10:47,120 --> 00:10:49,680
Each step is a separate interaction with the model.

308
00:10:49,680 --> 00:10:51,440
Structured tool use goes deeper.

309
00:10:51,440 --> 00:10:52,760
Instead of scattered function calls,

310
00:10:52,760 --> 00:10:54,480
you organize them into a workflow.

311
00:10:54,480 --> 00:10:55,720
You define nodes.

312
00:10:55,720 --> 00:10:58,760
Decision points where the model reasons about what to do next.

313
00:10:58,760 --> 00:11:01,120
You define edges, transitions between nodes

314
00:11:01,120 --> 00:11:02,760
based on what the model decided.

315
00:11:02,760 --> 00:11:05,920
You chain these together into a directed graph, where each node

316
00:11:05,920 --> 00:11:08,200
is either an LLM call, making a decision

317
00:11:08,200 --> 00:11:10,400
or a tool node executing an action.

318
00:11:10,400 --> 00:11:12,280
Lang graph is the production framework for this.

319
00:11:12,280 --> 00:11:14,960
It treats a workflow as a graph of nodes and transitions.

320
00:11:14,960 --> 00:11:17,160
A planner node decides what steps are needed.

321
00:11:17,160 --> 00:11:19,360
A tool node executes one of those steps.

322
00:11:19,360 --> 00:11:22,560
A verification node checks whether the execution succeeded.

323
00:11:22,560 --> 00:11:24,640
A human approval node waits for authorization

324
00:11:24,640 --> 00:11:25,600
before committing.

325
00:11:25,600 --> 00:11:27,280
The graph nodes which node to go to next

326
00:11:27,280 --> 00:11:28,960
based on what the previous node produced.

327
00:11:28,960 --> 00:11:30,240
Why does this matter?

328
00:11:30,240 --> 00:11:32,480
Because real enterprise workflows are not linear.

329
00:11:32,480 --> 00:11:34,960
An agent doesn't schedule a meeting by calling one function.

330
00:11:34,960 --> 00:11:36,280
It reads someone's calendar.

331
00:11:36,280 --> 00:11:37,600
It checks for conflicts.

332
00:11:37,600 --> 00:11:38,960
It finds available times.

333
00:11:38,960 --> 00:11:40,760
It gets confirmation from the attendees.

334
00:11:40,760 --> 00:11:42,000
It sends the invite.

335
00:11:42,000 --> 00:11:44,000
It documents the meeting in a shared system.

336
00:11:44,000 --> 00:11:46,720
Each step depends on the result of the previous step.

337
00:11:46,720 --> 00:11:48,800
If something fails, the agent needs to backtrack

338
00:11:48,800 --> 00:11:50,320
and try a different approach.

339
00:11:50,320 --> 00:11:52,680
A single function call cannot express this complexity.

340
00:11:52,680 --> 00:11:54,080
A graph can.

341
00:11:54,080 --> 00:11:55,560
The latency cost is real though.

342
00:11:55,560 --> 00:11:57,280
Each tool call adds a network hop.

343
00:11:57,280 --> 00:12:00,240
Read an email, one hop, check a calendar, another hop,

344
00:12:00,240 --> 00:12:02,200
validate availability, another,

345
00:12:02,200 --> 00:12:04,440
the delays compound.

346
00:12:04,440 --> 00:12:06,680
An agent that needs to schedule a complex meeting

347
00:12:06,680 --> 00:12:09,200
with seven attendees across three time zones

348
00:12:09,200 --> 00:12:12,400
might make 30 tool calls, 30 hops.

349
00:12:12,400 --> 00:12:14,120
Even at 50 milliseconds per hop, that's

350
00:12:14,120 --> 00:12:16,440
a second and a half before the user sees a result.

351
00:12:16,440 --> 00:12:19,080
This is why schema design matters more than model capability.

352
00:12:19,080 --> 00:12:20,680
If you design your schemas poorly,

353
00:12:20,680 --> 00:12:22,800
if each schema requires multiple tool calls

354
00:12:22,800 --> 00:12:25,080
to do what one well designed schema could do,

355
00:12:25,080 --> 00:12:28,480
you'll hit latency walls that no model capability can overcome.

356
00:12:28,480 --> 00:12:31,600
A good schema lets the model accomplish more with fewer calls.

357
00:12:31,600 --> 00:12:33,680
It exposes the right level of abstraction.

358
00:12:33,680 --> 00:12:35,520
It bundles related operations together.

359
00:12:35,520 --> 00:12:37,880
Here's a concrete example.

360
00:12:37,880 --> 00:12:40,840
An agent needs to schedule a meeting, bad approach, call

361
00:12:40,840 --> 00:12:44,800
get available times, call send meeting invite, call update

362
00:12:44,800 --> 00:12:47,880
calendar, three functions, three hops.

363
00:12:47,880 --> 00:12:48,800
Better approach.

364
00:12:48,800 --> 00:12:50,520
One scheduler's meeting function that takes

365
00:12:50,520 --> 00:12:53,680
attendees, time, title, and optional parameters.

366
00:12:53,680 --> 00:12:55,760
It handles availability checking internally.

367
00:12:55,760 --> 00:12:57,880
The model makes one call, one hop, same result.

368
00:12:57,880 --> 00:12:59,960
This is the bridge between context and action.

369
00:12:59,960 --> 00:13:02,200
Tool calling is how agents move from understanding

370
00:13:02,200 --> 00:13:04,440
what needs to happen to actually making it happen.

371
00:13:04,440 --> 00:13:06,000
Graph provides the context.

372
00:13:06,000 --> 00:13:08,120
Tool calling provides the execution mechanism.

373
00:13:08,120 --> 00:13:10,440
Together, they transform an agent from an information

374
00:13:10,440 --> 00:13:12,800
system into a decision-making automation.

375
00:13:12,800 --> 00:13:13,920
But there's still a gap.

376
00:13:13,920 --> 00:13:15,320
Tool calling is manual.

377
00:13:15,320 --> 00:13:18,760
An engineer has to define each function, has to write the schemas,

378
00:13:18,760 --> 00:13:20,440
has to maintain them as systems changed.

379
00:13:20,440 --> 00:13:22,880
The bridges are fragile because they're hand-built.

380
00:13:22,880 --> 00:13:23,840
There's a better way.

381
00:13:23,840 --> 00:13:26,080
Tool calling works, but it's manual and fragile.

382
00:13:26,080 --> 00:13:27,440
There's a better way.

383
00:13:27,440 --> 00:13:28,920
Model context protocol.

384
00:13:28,920 --> 00:13:30,280
The standardization layer.

385
00:13:30,280 --> 00:13:32,080
The problem with hand-building tool calling

386
00:13:32,080 --> 00:13:33,240
is that it doesn't scale.

387
00:13:33,240 --> 00:13:34,720
You have one agent framework.

388
00:13:34,720 --> 00:13:36,600
Another team uses a different one.

389
00:13:36,600 --> 00:13:38,640
One model supports OpenAI function calling.

390
00:13:38,640 --> 00:13:40,480
Another uses Claude's tool use.

391
00:13:40,480 --> 00:13:42,560
One integration uses rest.

392
00:13:42,560 --> 00:13:44,880
Another uses GRPC.

393
00:13:44,880 --> 00:13:46,520
Every connection is custom.

394
00:13:46,520 --> 00:13:47,840
Every schema is bespoke.

395
00:13:47,840 --> 00:13:50,840
Every organization is rewiring the same bridges over and over.

396
00:13:50,840 --> 00:13:52,000
This is the NXM problem.

397
00:13:52,000 --> 00:13:53,800
You have N different models and frameworks

398
00:13:53,800 --> 00:13:55,320
trying to talk to N different systems.

399
00:13:55,320 --> 00:13:57,160
That's N times M integration points.

400
00:13:57,160 --> 00:13:59,720
Every time you add a new model or a new system,

401
00:13:59,720 --> 00:14:01,120
the complexity multiplies.

402
00:14:01,120 --> 00:14:04,840
The fragmentation becomes unmentanable.

403
00:14:04,840 --> 00:14:06,720
Model context protocol solves this

404
00:14:06,720 --> 00:14:10,160
by collapsing the complexity into N plus M. One protocol.

405
00:14:10,160 --> 00:14:12,160
Multiple implementations on both sides.

406
00:14:12,160 --> 00:14:14,600
A model doesn't need to know how many systems exist.

407
00:14:14,600 --> 00:14:17,000
A system doesn't need to know how many models want to use it.

408
00:14:17,000 --> 00:14:20,160
They talk through MCP. What is MCP exactly?

409
00:14:20,160 --> 00:14:22,600
It's a wire protocol for agent to tool communication.

410
00:14:22,600 --> 00:14:26,600
It's JSINRPC2.0 sitting on top of HTTP or STDI.

411
00:14:26,600 --> 00:14:29,280
It standardizes how models discover tools,

412
00:14:29,280 --> 00:14:31,040
what information they need to call them,

413
00:14:31,040 --> 00:14:32,560
and how results come back.

414
00:14:32,560 --> 00:14:34,240
A model sends a structured request.

415
00:14:34,240 --> 00:14:35,840
The MCP server receives it.

416
00:14:35,840 --> 00:14:37,520
The server roots it to the right tool.

417
00:14:37,520 --> 00:14:38,720
The tool executes.

418
00:14:38,720 --> 00:14:40,840
The result flows back through the protocol.

419
00:14:40,840 --> 00:14:43,000
The model sees a standard response format

420
00:14:43,000 --> 00:14:45,200
regardless of whether the back end is a database,

421
00:14:45,200 --> 00:14:47,320
an API, or a custom service.

422
00:14:47,320 --> 00:14:48,160
Why does this matter?

423
00:14:48,160 --> 00:14:52,040
Because in 2025, MCP adoption grew 340%.

424
00:14:52,040 --> 00:14:53,400
It's not a niche protocol anymore.

425
00:14:53,400 --> 00:14:54,520
Claude supports it.

426
00:14:54,520 --> 00:14:56,800
ChatGPT supports it. Grok supports it.

427
00:14:56,800 --> 00:14:58,000
Google is building it in.

428
00:14:58,000 --> 00:14:59,520
Microsoft is building it in.

429
00:14:59,520 --> 00:15:00,920
This is not a future scenario.

430
00:15:00,920 --> 00:15:03,000
This is what's happening in production right now.

431
00:15:03,000 --> 00:15:05,360
The adoption happened because MCP solved a real problem.

432
00:15:05,360 --> 00:15:07,840
Organizations were drowning in bespoke integrations.

433
00:15:07,840 --> 00:15:09,720
Every agent needed custom schemas.

434
00:15:09,720 --> 00:15:11,560
Every system needed custom rappers.

435
00:15:11,560 --> 00:15:12,920
MCP flips that model.

436
00:15:12,920 --> 00:15:14,040
You define the tool once.

437
00:15:14,040 --> 00:15:15,400
You expose it through MCP.

438
00:15:15,400 --> 00:15:17,480
Any model that understands MCP can use it.

439
00:15:17,480 --> 00:15:19,640
You don't redefine it for Claude and again for GPD

440
00:15:19,640 --> 00:15:21,320
and again for your internal models.

441
00:15:21,320 --> 00:15:22,640
Once.

442
00:15:22,640 --> 00:15:24,160
Through the protocol.

443
00:15:24,160 --> 00:15:26,320
The performance differences matter architecturally.

444
00:15:26,320 --> 00:15:29,480
Standard MCP, the JSON RPC variant over HTTP,

445
00:15:29,480 --> 00:15:32,520
delivers about 50 to 100 milliseconds per tool call.

446
00:15:32,520 --> 00:15:34,680
That's 1,000 requests per second throughput.

447
00:15:34,680 --> 00:15:36,440
It's reasonable for most workflows.

448
00:15:36,440 --> 00:15:38,040
But if you're building high volume systems,

449
00:15:38,040 --> 00:15:41,040
if you're orchestrating dozens of agent tool calls per second,

450
00:15:41,040 --> 00:15:42,520
that latency becomes noticeable.

451
00:15:42,520 --> 00:15:45,040
This is where GRPC MCP enters the picture.

452
00:15:45,040 --> 00:15:49,480
Instead of JSON RPC over HTTP, it uses GRPC over protobuff.

453
00:15:49,480 --> 00:15:50,840
The performance jump is dramatic.

454
00:15:50,840 --> 00:15:54,280
5 to 15 milliseconds per call, 5 to 10 times faster.

455
00:15:54,280 --> 00:15:57,160
And throughput scales to 10,000 requests per second.

456
00:15:57,160 --> 00:15:59,640
For an architect deciding whether agents can handle production

457
00:15:59,640 --> 00:16:02,000
load, this is the difference between a viable system

458
00:16:02,000 --> 00:16:02,800
and a bottleneck.

459
00:16:02,800 --> 00:16:05,000
The architect's choice when building systems that

460
00:16:05,000 --> 00:16:07,960
needs speed and scale is GRPC MCP.

461
00:16:07,960 --> 00:16:09,560
Not because it's flashier, because it actually

462
00:16:09,560 --> 00:16:12,240
runs fast enough to power real business workflows.

463
00:16:12,240 --> 00:16:14,480
But performance is not the only reason MCP matters.

464
00:16:14,480 --> 00:16:16,640
It's also more secure and governance-friendly

465
00:16:16,640 --> 00:16:18,360
than hand-built integrations.

466
00:16:18,360 --> 00:16:19,040
Here's why.

467
00:16:19,040 --> 00:16:21,320
With custom tool calling, every system needs to know about

468
00:16:21,320 --> 00:16:22,880
every model that might call it.

469
00:16:22,880 --> 00:16:25,520
Every system needs to implement its own authentication,

470
00:16:25,520 --> 00:16:26,840
authorization, and logging.

471
00:16:26,840 --> 00:16:27,720
It's fragmented.

472
00:16:27,720 --> 00:16:28,800
It's error-prone.

473
00:16:28,800 --> 00:16:31,960
Security logic gets re-implemented badly across multiple systems.

474
00:16:31,960 --> 00:16:33,560
MCP centralizes this.

475
00:16:33,560 --> 00:16:36,240
The protocol itself can enforce standardized authentication.

476
00:16:36,240 --> 00:16:39,360
MCP servers can implement uniform permission checking.

477
00:16:39,360 --> 00:16:41,840
Every tool call flows through a single-ordid layer.

478
00:16:41,840 --> 00:16:43,560
The governance boundary becomes clear.

479
00:16:43,560 --> 00:16:45,120
The security model becomes uniform.

480
00:16:45,120 --> 00:16:48,080
An organization can say all tool calls must use MCP,

481
00:16:48,080 --> 00:16:50,000
and then enforce that at the protocol level,

482
00:16:50,000 --> 00:16:53,160
rather than hoping every team implement security correctly.

483
00:16:53,160 --> 00:16:56,480
Microsoft's MCP server for enterprise takes this further.

484
00:16:56,480 --> 00:16:58,040
It's not just a generic protocol anymore.

485
00:16:58,040 --> 00:17:00,240
It's graph data exposed through MCP.

486
00:17:00,240 --> 00:17:01,960
It's your organizational nervous system

487
00:17:01,960 --> 00:17:04,680
wired into every model that supports the protocol.

488
00:17:04,680 --> 00:17:05,920
An agent doesn't have to understand

489
00:17:05,920 --> 00:17:07,800
Graphs Complex API surface.

490
00:17:07,800 --> 00:17:10,560
It understands MCP handles the translation.

491
00:17:10,560 --> 00:17:11,760
The agent gets what it needs.

492
00:17:11,760 --> 00:17:12,960
Graph stays clean.

493
00:17:12,960 --> 00:17:14,120
The boundary is clear.

494
00:17:14,120 --> 00:17:17,200
The standardization layer is where scale becomes possible.

495
00:17:17,200 --> 00:17:18,640
Not because MCP is magic,

496
00:17:18,640 --> 00:17:20,040
but because it takes the fragmentation

497
00:17:20,040 --> 00:17:21,920
out of agent system communication.

498
00:17:21,920 --> 00:17:23,680
MCP is infrastructure.

499
00:17:23,680 --> 00:17:26,160
Now let's talk about what agents actually do with it.

500
00:17:26,160 --> 00:17:28,600
Graph connectors bringing external data in.

501
00:17:28,600 --> 00:17:30,800
Your organizational nervous system is incomplete.

502
00:17:30,800 --> 00:17:33,560
The Microsoft graph sits at the center of your environment,

503
00:17:33,560 --> 00:17:36,840
and it knows exactly what happens inside Microsoft 365,

504
00:17:36,840 --> 00:17:39,520
but in reality, most of the data that actually drives

505
00:17:39,520 --> 00:17:41,520
your decisions live somewhere else.

506
00:17:41,520 --> 00:17:43,000
Your product roadmap is in JIRA.

507
00:17:43,000 --> 00:17:45,040
Your customer contracts are in Salesforce.

508
00:17:45,040 --> 00:17:46,760
Your design assets are in box.

509
00:17:46,760 --> 00:17:49,320
Your technical documentation is in Google Drive

510
00:17:49,320 --> 00:17:50,320
and your vendor agreements.

511
00:17:50,320 --> 00:17:52,560
Those are scattered across a dozen different systems,

512
00:17:52,560 --> 00:17:54,360
depending on which team negotiated them.

513
00:17:54,360 --> 00:17:56,040
Graph connectors are the ingestion layer

514
00:17:56,040 --> 00:17:57,600
for all that third-party content.

515
00:17:57,600 --> 00:18:00,280
They are designed to solve the knowledge-style or problem.

516
00:18:00,280 --> 00:18:02,080
What is actually happening in production right now

517
00:18:02,080 --> 00:18:05,480
is that organizations are connecting Box, Google Drive, JIRA

518
00:18:05,480 --> 00:18:08,480
and Salesforce directly into Microsoft 365.

519
00:18:08,480 --> 00:18:11,240
They are not doing this by exporting data and re-importing it,

520
00:18:11,240 --> 00:18:13,160
and they are not forcing people to switch tools.

521
00:18:13,160 --> 00:18:15,080
Instead, they are making that external content

522
00:18:15,080 --> 00:18:18,080
queryable through the same system that already powers

523
00:18:18,080 --> 00:18:20,240
search, discovery, and agent reasoning.

524
00:18:20,240 --> 00:18:22,760
When a connector is active, an agent does not have to choose

525
00:18:22,760 --> 00:18:25,240
between searching internal knowledge or external systems.

526
00:18:25,240 --> 00:18:26,440
It searches both.

527
00:18:26,440 --> 00:18:29,160
Because the connector has indexed that external content,

528
00:18:29,160 --> 00:18:31,960
the agent sees it as part of the same organizational knowledge

529
00:18:31,960 --> 00:18:32,640
base.

530
00:18:32,640 --> 00:18:34,720
An HR agent recruiting for an engineering role

531
00:18:34,720 --> 00:18:37,720
can query job descriptions in your ATS, skill requirements

532
00:18:37,720 --> 00:18:39,480
in your internal wiki, and historical performance

533
00:18:39,480 --> 00:18:41,760
patterns of similar hires all in one search.

534
00:18:41,760 --> 00:18:43,640
It happens through the unified interface

535
00:18:43,640 --> 00:18:44,760
that graph provides.

536
00:18:44,760 --> 00:18:45,960
But here is the problem.

537
00:18:45,960 --> 00:18:47,840
Most implementations stumble on the difference

538
00:18:47,840 --> 00:18:49,800
between indexing and understanding.

539
00:18:49,800 --> 00:18:51,200
A connector index is content.

540
00:18:51,200 --> 00:18:53,040
It reads data from the external system.

541
00:18:53,040 --> 00:18:54,160
It extracts text.

542
00:18:54,160 --> 00:18:55,840
It makes the content searchable.

543
00:18:55,840 --> 00:18:57,560
That is valuable because it solves the,

544
00:18:57,560 --> 00:18:59,560
I can't find anything problem.

545
00:18:59,560 --> 00:19:01,040
But indexing is not understanding.

546
00:19:01,040 --> 00:19:03,680
When a connector index is a Salesforce Opportunity Record,

547
00:19:03,680 --> 00:19:07,520
it pulls the account name, deal size, stage, and close date.

548
00:19:07,520 --> 00:19:10,160
An agent can find records matching those keywords,

549
00:19:10,160 --> 00:19:12,080
but the agent does not understand the relationships.

550
00:19:12,080 --> 00:19:14,720
It does not know that this specific opportunity

551
00:19:14,720 --> 00:19:17,240
is tied to a customer with a history of delays,

552
00:19:17,240 --> 00:19:19,240
or that they are likely to renegotiate pricing

553
00:19:19,240 --> 00:19:21,360
and require executive approvals.

554
00:19:21,360 --> 00:19:23,440
Understanding requires more than indexing.

555
00:19:23,440 --> 00:19:24,800
It requires context.

556
00:19:24,800 --> 00:19:26,760
You have to connect that indexed data

557
00:19:26,760 --> 00:19:28,880
to other signals the agent already knows.

558
00:19:28,880 --> 00:19:31,640
This is why the governance model for connectors matters.

559
00:19:31,640 --> 00:19:34,760
It determines how much context the agent can actually access.

560
00:19:34,760 --> 00:19:36,800
When you enable a connector, you are making a governance

561
00:19:36,800 --> 00:19:37,200
choice.

562
00:19:37,200 --> 00:19:39,240
You are deciding what data agents can

563
00:19:39,240 --> 00:19:41,600
access from that external system, who can see it,

564
00:19:41,600 --> 00:19:42,760
and what they can do with it.

565
00:19:42,760 --> 00:19:44,360
These are not technical decisions.

566
00:19:44,360 --> 00:19:45,880
They are organizational decisions.

567
00:19:45,880 --> 00:19:47,840
A Salesforce connector that gives agents access

568
00:19:47,840 --> 00:19:50,160
to all opportunities might give them visibility

569
00:19:50,160 --> 00:19:51,800
into deals they should not see.

570
00:19:51,800 --> 00:19:54,400
A GERA connector that exposes every ticket might give agents

571
00:19:54,400 --> 00:19:56,520
access to security issues, customer complaints,

572
00:19:56,520 --> 00:19:58,040
or internal frustrations.

573
00:19:58,040 --> 00:19:59,640
The governance model is simple.

574
00:19:59,640 --> 00:20:02,680
Who can access connector data and underwater conditions?

575
00:20:02,680 --> 00:20:05,840
This has to map back to your organization's data classification.

576
00:20:05,840 --> 00:20:08,200
If something is marked sensitive in Salesforce,

577
00:20:08,200 --> 00:20:09,640
the connector should respect that.

578
00:20:09,640 --> 00:20:12,480
If access is restricted in GERA, the connector should enforce it.

579
00:20:12,480 --> 00:20:14,800
Otherwise, you have solved the knowledge silo problem

580
00:20:14,800 --> 00:20:16,400
by creating a security problem.

581
00:20:16,400 --> 00:20:18,680
Most production pilots start through the 1 million item

582
00:20:18,680 --> 00:20:19,400
free trial.

583
00:20:19,400 --> 00:20:21,720
This lets you test a connector against real data at scale

584
00:20:21,720 --> 00:20:23,840
without committing to a full production setup.

585
00:20:23,840 --> 00:20:26,600
You can see how many items index, how search performs,

586
00:20:26,600 --> 00:20:28,920
and how the connector affects query latency.

587
00:20:28,920 --> 00:20:31,320
You can measure whether the governance model actually works.

588
00:20:31,320 --> 00:20:34,000
And then you expand the connectors bring data in.

589
00:20:34,000 --> 00:20:35,680
But enterprise agents need to orchestrate

590
00:20:35,680 --> 00:20:37,120
across multiple systems.

591
00:20:37,120 --> 00:20:38,640
Graph data connect.

592
00:20:38,640 --> 00:20:40,240
The analytics pipeline.

593
00:20:40,240 --> 00:20:41,920
There is a flip side to this story.

594
00:20:41,920 --> 00:20:44,400
Connectors bring data into Microsoft 365.

595
00:20:44,400 --> 00:20:46,920
But MGDC, Microsoft Graph Data Connect does the opposite.

596
00:20:46,920 --> 00:20:47,960
It moves data out.

597
00:20:47,960 --> 00:20:50,720
Specifically, it extracts Microsoft 365 data at scale

598
00:20:50,720 --> 00:20:52,840
into Azure for analytics and machine learning.

599
00:20:52,840 --> 00:20:54,440
This is where the architecture deepens.

600
00:20:54,440 --> 00:20:56,320
Agents do not just need real time access

601
00:20:56,320 --> 00:20:57,440
to what is happening right now.

602
00:20:57,440 --> 00:20:59,560
They also need to understand patterns and trends.

603
00:20:59,560 --> 00:21:01,760
They need signals that only emerge when you step back

604
00:21:01,760 --> 00:21:04,200
and look at months or years of behavioral data.

605
00:21:04,200 --> 00:21:06,680
Graph data connect is your bulk export pipeline.

606
00:21:06,680 --> 00:21:09,240
You point it at your tenant and tell it which data you want.

607
00:21:09,240 --> 00:21:11,280
Email metadata, meeting patterns,

608
00:21:11,280 --> 00:21:13,320
file collaboration or communication flows.

609
00:21:13,320 --> 00:21:15,520
It pulls that data out and lands it in Azure.

610
00:21:15,520 --> 00:21:18,000
You can put it in a data lake, synapse or fabric,

611
00:21:18,000 --> 00:21:19,640
wherever you want to analyze it.

612
00:21:19,640 --> 00:21:21,080
The extraction happens in batches.

613
00:21:21,080 --> 00:21:22,360
It is not a constant stream.

614
00:21:22,360 --> 00:21:25,000
These are schedule jobs that run on your timeline.

615
00:21:25,000 --> 00:21:26,600
The critical distinction is this.

616
00:21:26,600 --> 00:21:28,720
Real time graph calls are transactional.

617
00:21:28,720 --> 00:21:30,760
An agent makes a request right now

618
00:21:30,760 --> 00:21:32,080
and gets an answer right now.

619
00:21:32,080 --> 00:21:34,080
It reads an email that arrived five minutes ago.

620
00:21:34,080 --> 00:21:35,840
It checks a calendar for tomorrow.

621
00:21:35,840 --> 00:21:37,520
It creates a task this instant

622
00:21:37,520 --> 00:21:40,280
that answers the question, what is the current state?

623
00:21:40,280 --> 00:21:42,560
Batch analytics answers a different question.

624
00:21:42,560 --> 00:21:44,560
What patterns are hiding in the data?

625
00:21:44,560 --> 00:21:47,200
It is not just about what happened but why it happened.

626
00:21:47,200 --> 00:21:48,960
It is not just about individual events

627
00:21:48,960 --> 00:21:50,280
but how they connect.

628
00:21:50,280 --> 00:21:52,800
It is not just the present state but the trajectory.

629
00:21:52,800 --> 00:21:55,800
This is where agents become predictive instead of reactive.

630
00:21:55,800 --> 00:21:57,960
An HR agent does not just react

631
00:21:57,960 --> 00:21:59,560
when someone submits a resignation.

632
00:21:59,560 --> 00:22:01,600
It analyzes years of communication patterns.

633
00:22:01,600 --> 00:22:03,760
It looks at how often people talk to their manager,

634
00:22:03,760 --> 00:22:06,240
how many times they have updated their LinkedIn profile

635
00:22:06,240 --> 00:22:08,400
and whether they have been attending training sessions

636
00:22:08,400 --> 00:22:09,560
or skipping them.

637
00:22:09,560 --> 00:22:11,600
Individually, those signals mean nothing

638
00:22:11,600 --> 00:22:13,480
but when you aggregate them across a year,

639
00:22:13,480 --> 00:22:14,760
they predict attrition.

640
00:22:14,760 --> 00:22:17,120
An agent with access to that behavioral intelligence

641
00:22:17,120 --> 00:22:19,560
can identify flight risks six months

642
00:22:19,560 --> 00:22:21,000
before they become departures.

643
00:22:21,000 --> 00:22:22,880
It can flag when someone is disengaging.

644
00:22:22,880 --> 00:22:25,040
It can recommend interventions before it is too late.

645
00:22:25,040 --> 00:22:27,400
This is what MGDC unlocks, not just data

646
00:22:27,400 --> 00:22:29,760
but behavioral intelligence.

647
00:22:29,760 --> 00:22:31,360
There is a massive difference between knowing

648
00:22:31,360 --> 00:22:33,640
that someone sent fewer emails last month

649
00:22:33,640 --> 00:22:35,360
and understanding that this pattern

650
00:22:35,360 --> 00:22:36,800
combined with their meeting attendance

651
00:22:36,800 --> 00:22:38,120
and project assignments

652
00:22:38,120 --> 00:22:40,200
indicates they are preparing to leave.

653
00:22:40,200 --> 00:22:42,720
Production agents use MGDC output for three things.

654
00:22:42,720 --> 00:22:44,960
First is patent detection, which finds deviations

655
00:22:44,960 --> 00:22:46,160
from normal behavior.

656
00:22:46,160 --> 00:22:47,520
Second is a normally analysis

657
00:22:47,520 --> 00:22:49,840
which helps you understand what caused that deviation.

658
00:22:49,840 --> 00:22:52,400
Third is forecasting, where you project future outcomes

659
00:22:52,400 --> 00:22:53,600
based on current trends

660
00:22:53,600 --> 00:22:55,760
but here is where governance becomes complicated.

661
00:22:55,760 --> 00:22:59,040
MGDC moves sensitive data, workplace communication,

662
00:22:59,040 --> 00:23:00,840
meeting patterns and social graphs

663
00:23:00,840 --> 00:23:02,600
from Microsoft's managed environment

664
00:23:02,600 --> 00:23:04,200
into your Azure subscription.

665
00:23:04,200 --> 00:23:06,840
You now own that data, you control who can access it.

666
00:23:06,840 --> 00:23:08,760
You are responsible for protecting it.

667
00:23:08,760 --> 00:23:11,040
Moving sensitive workplace data to Azure

668
00:23:11,040 --> 00:23:13,040
requires explicit organizational consent.

669
00:23:13,040 --> 00:23:14,640
This cannot just come from IT.

670
00:23:14,640 --> 00:23:16,040
It has to come from the people whose data

671
00:23:16,040 --> 00:23:17,640
is flowing through the pipeline.

672
00:23:17,640 --> 00:23:21,000
This is why MGDC deployments need transparent governance.

673
00:23:21,000 --> 00:23:22,480
You need clear data classification

674
00:23:22,480 --> 00:23:24,640
and explicit communication about what is being extracted

675
00:23:24,640 --> 00:23:25,440
and why.

676
00:23:25,440 --> 00:23:27,240
The deeper pattern here is that MGDC

677
00:23:27,240 --> 00:23:30,000
becomes the foundation for adaptive context layers.

678
00:23:30,000 --> 00:23:32,480
The idea is that agents should not just respond

679
00:23:32,480 --> 00:23:33,560
to immediate requests.

680
00:23:33,560 --> 00:23:35,520
They should understand the organization deeply enough

681
00:23:35,520 --> 00:23:37,520
to anticipate needs, predict problems

682
00:23:37,520 --> 00:23:39,280
and recommend actions that would have been

683
00:23:39,280 --> 00:23:41,400
impossible with transactional data alone.

684
00:23:41,400 --> 00:23:43,840
Think about an agent that analyzes communication patterns

685
00:23:43,840 --> 00:23:45,120
to predict attrition.

686
00:23:45,120 --> 00:23:47,880
A manager has not explicitly said they are thinking of leaving.

687
00:23:47,880 --> 00:23:49,200
There are no resignation letters

688
00:23:49,200 --> 00:23:51,080
and no interviews visible on the calendar.

689
00:23:51,080 --> 00:23:53,000
But the communication graph tells a story.

690
00:23:53,000 --> 00:23:55,200
They are responding more slowly to emails.

691
00:23:55,200 --> 00:23:57,360
They are not joining cross-functional meetings anymore.

692
00:23:57,360 --> 00:23:58,840
They are not initiating projects.

693
00:23:58,840 --> 00:23:59,960
The pattern is clear.

694
00:23:59,960 --> 00:24:01,840
The agent surfaces this as a risk.

695
00:24:01,840 --> 00:24:04,600
The organization intervenes, a conversation happens,

696
00:24:04,600 --> 00:24:07,560
a promotion materializes and the person stays.

697
00:24:07,560 --> 00:24:09,280
That intelligence, that ability to read

698
00:24:09,280 --> 00:24:12,200
the organization's behavioral health lives in MGDC.

699
00:24:12,200 --> 00:24:13,960
It does not live in real-time graph calls.

700
00:24:13,960 --> 00:24:15,720
It lives in the analytics pipeline.

701
00:24:15,720 --> 00:24:18,120
Now we have data flowing in multiple directions.

702
00:24:18,120 --> 00:24:20,120
How do we orchestrate agents across this?

703
00:24:20,120 --> 00:24:23,280
The supervisor agent pattern, orchestration at scale.

704
00:24:23,280 --> 00:24:25,280
Your architecture starts to get interesting here.

705
00:24:25,280 --> 00:24:27,000
Up until now we've talked about context

706
00:24:27,000 --> 00:24:29,480
and tool calling as if one agent does all the work.

707
00:24:29,480 --> 00:24:32,080
But in reality, that's not how the enterprise operates.

708
00:24:32,080 --> 00:24:34,880
Real workflows are too complex for a single brain.

709
00:24:34,880 --> 00:24:36,440
They require different kinds of expertise

710
00:24:36,440 --> 00:24:38,040
happening in a specific order.

711
00:24:38,040 --> 00:24:40,200
Think about a standard HR hiring workflow.

712
00:24:40,200 --> 00:24:41,520
A single agent would have to master

713
00:24:41,520 --> 00:24:43,640
sourcing screening compliance and scheduling.

714
00:24:43,640 --> 00:24:46,640
It would need to generate offers and run background checks.

715
00:24:46,640 --> 00:24:49,040
It would have to decide exactly when to move a candidate

716
00:24:49,040 --> 00:24:51,680
to the next stage and then there are the edge cases.

717
00:24:51,680 --> 00:24:53,600
What happens if a background check fails?

718
00:24:53,600 --> 00:24:55,400
What if the interviewers are all out of the office?

719
00:24:55,400 --> 00:24:56,880
If you build one agent to do it all,

720
00:24:56,880 --> 00:24:58,520
you end up with a bloated monolith.

721
00:24:58,520 --> 00:25:00,320
It gets paralyzed by the complexity.

722
00:25:00,320 --> 00:25:03,480
It can't reason clearly because it's trying to hold too much at once.

723
00:25:03,480 --> 00:25:05,680
The solution is the supervisor worker pattern.

724
00:25:05,680 --> 00:25:08,880
You have one orchestrating agent that coordinates a team of specialists.

725
00:25:08,880 --> 00:25:11,320
Each specialist owns a very narrow domain.

726
00:25:11,320 --> 00:25:13,720
The supervisor doesn't actually execute the work.

727
00:25:13,720 --> 00:25:15,560
It decides which worker should go next,

728
00:25:15,560 --> 00:25:16,920
validates what they produce,

729
00:25:16,920 --> 00:25:18,720
and determines the next step in the chain.

730
00:25:18,720 --> 00:25:20,720
We see this in production HR deployments right now.

731
00:25:20,720 --> 00:25:22,080
Lucy is the supervisor.

732
00:25:22,080 --> 00:25:25,040
When a job requisition comes in, she doesn't process it herself.

733
00:25:25,040 --> 00:25:27,800
Instead, she invokes Rex, the sourcing specialist.

734
00:25:27,800 --> 00:25:31,280
Rex searches the ATS and LinkedIn to find a ranked list of candidates.

735
00:25:31,280 --> 00:25:34,440
Lucy takes that list and checks it against the approval criteria.

736
00:25:34,440 --> 00:25:36,880
Then she calls Olivia, the compliance specialist.

737
00:25:36,880 --> 00:25:39,240
Olivia checks for diversity and policy adherence.

738
00:25:39,240 --> 00:25:40,960
If she finds an issue, she flags it.

739
00:25:40,960 --> 00:25:44,440
Lucy then decides whether to escalate that flag to a human reviewer.

740
00:25:44,440 --> 00:25:45,520
If everything looks good,

741
00:25:45,520 --> 00:25:47,960
Lucy calls Tim, the automation specialist.

742
00:25:47,960 --> 00:25:50,640
Tim handles the interview invites and tracks the responses.

743
00:25:50,640 --> 00:25:52,560
These agents never overlap.

744
00:25:52,560 --> 00:25:54,160
Rex doesn't care about compliance.

745
00:25:54,160 --> 00:25:55,720
Olivia doesn't touch the calendar.

746
00:25:55,720 --> 00:25:57,120
Tim doesn't look for resumes.

747
00:25:57,120 --> 00:25:58,800
Each one does one thing perfectly.

748
00:25:58,800 --> 00:26:00,440
Lucy is the one who knows the order

749
00:26:00,440 --> 00:26:02,080
and what success actually looks like.

750
00:26:02,080 --> 00:26:03,120
But here's the problem.

751
00:26:03,120 --> 00:26:05,240
People often confuse this with a swarm.

752
00:26:05,240 --> 00:26:06,400
A swarm is organic.

753
00:26:06,400 --> 00:26:09,680
It's autonomous agents negotiating with each other to find a solution.

754
00:26:09,680 --> 00:26:11,000
That is not what we're doing here.

755
00:26:11,000 --> 00:26:13,120
In this model, every handoff is explicit.

756
00:26:13,120 --> 00:26:14,240
Every decision is logged.

757
00:26:14,240 --> 00:26:15,920
Every escalation is auditable.

758
00:26:15,920 --> 00:26:18,480
The supervisor worker pattern is a state machine.

759
00:26:18,480 --> 00:26:21,520
You can trace the exact path the requisition took through your system.

760
00:26:21,520 --> 00:26:24,480
You can point to the specific decision that led to the outcome.

761
00:26:24,480 --> 00:26:26,920
For governance, that transparency is everything.

762
00:26:26,920 --> 00:26:29,480
The state machine is how agents track their progress.

763
00:26:29,480 --> 00:26:32,040
The work starts in a received state.

764
00:26:32,040 --> 00:26:33,640
Lucy moves it to sourcing.

765
00:26:33,640 --> 00:26:36,680
Rex finishes his job and the state moves to compliance review.

766
00:26:36,680 --> 00:26:39,640
If a human has to step in, the state moves to escalate it

767
00:26:39,640 --> 00:26:41,560
until they move it back to approved.

768
00:26:41,560 --> 00:26:44,360
This is where LangGraph becomes your production infrastructure.

769
00:26:44,360 --> 00:26:46,400
It isn't just a framework for tool calls.

770
00:26:46,400 --> 00:26:48,360
It's the engine for the state machine.

771
00:26:48,360 --> 00:26:49,600
Each agent is a node.

772
00:26:49,600 --> 00:26:50,920
Each transition is an edge.

773
00:26:50,920 --> 00:26:52,920
Lucy's decisions are rooted through nodes

774
00:26:52,920 --> 00:26:54,680
that determine which path to follow.

775
00:26:54,680 --> 00:26:58,360
The result is a graph you can visualize, reason about, and debug.

776
00:26:58,360 --> 00:27:00,760
And because this is production, you need check pointing.

777
00:27:00,760 --> 00:27:02,760
An HR workflow might take an entire week.

778
00:27:02,760 --> 00:27:06,040
Rex finds candidates on Monday or Olivia reviews them on Thursday.

779
00:27:06,040 --> 00:27:08,120
A human looks at an escalation on Friday.

780
00:27:08,120 --> 00:27:11,160
If the system goes down on Wednesday, you don't want to start over.

781
00:27:11,160 --> 00:27:12,440
The system checkpoints.

782
00:27:12,440 --> 00:27:16,600
It remembers exactly where it was and what happened in the previous steps.

783
00:27:16,600 --> 00:27:18,600
The candidate list doesn't get resourced.

784
00:27:18,600 --> 00:27:20,200
The invitations don't get sent twice.

785
00:27:20,200 --> 00:27:24,040
That resilience is what separates a pilot project from a real production system.

786
00:27:24,040 --> 00:27:25,480
It's how you scale.

787
00:27:25,480 --> 00:27:26,680
This pattern works.

788
00:27:26,680 --> 00:27:29,800
But it only works if agents can actually trust each other.

789
00:27:29,800 --> 00:27:32,360
Multi-agent coordination, handoffs and escalation.

790
00:27:32,360 --> 00:27:34,760
But here's where most multi-agent systems break.

791
00:27:34,760 --> 00:27:38,120
The supervisor model only works if the workers can hand off work

792
00:27:38,120 --> 00:27:39,320
without dropping the ball.

793
00:27:39,320 --> 00:27:40,840
We call this the handoff problem.

794
00:27:40,840 --> 00:27:43,640
If Lucy decides that Rex's candidates need to go to Olivia,

795
00:27:43,640 --> 00:27:45,000
how does that actually happen?

796
00:27:45,000 --> 00:27:46,520
Lucy doesn't send Olivia a message.

797
00:27:46,520 --> 00:27:49,320
She doesn't send an email saying check these three people

798
00:27:49,320 --> 00:27:51,800
in a high volume system that fails immediately.

799
00:27:51,800 --> 00:27:52,840
Messages get lost.

800
00:27:52,840 --> 00:27:54,360
Context gets stripped away.

801
00:27:54,360 --> 00:27:56,520
Olivia wouldn't know why those candidates were picked.

802
00:27:56,520 --> 00:27:58,200
She couldn't tell if the selection was biased

803
00:27:58,200 --> 00:27:59,960
or if the search was thorough enough.

804
00:27:59,960 --> 00:28:02,280
The naive approach is simple message passing.

805
00:28:02,280 --> 00:28:04,280
Agent A tells Agent B to do something.

806
00:28:04,280 --> 00:28:06,840
But that creates the same fragmentation we see with humans.

807
00:28:06,840 --> 00:28:08,280
Information gets translated.

808
00:28:08,280 --> 00:28:09,160
Details get lost.

809
00:28:09,160 --> 00:28:10,680
Assumptions get baked in.

810
00:28:10,680 --> 00:28:13,800
A sourcing agent might output a list ranked by a match quality.

811
00:28:13,800 --> 00:28:17,720
But the compliance agent needs that list grouped by demographic diversity.

812
00:28:17,720 --> 00:28:18,920
The formats don't match.

813
00:28:18,920 --> 00:28:20,520
The expectations don't align.

814
00:28:20,520 --> 00:28:22,600
The architecture that actually works in production

815
00:28:22,600 --> 00:28:23,880
uses shared state.

816
00:28:23,880 --> 00:28:25,400
Instead of passing messages,

817
00:28:25,400 --> 00:28:27,320
there is one authoritative data structure

818
00:28:27,320 --> 00:28:29,880
that every agent reads from and writes to.

819
00:28:29,880 --> 00:28:31,560
Lucy doesn't hand off to Olivia.

820
00:28:31,560 --> 00:28:35,640
She updates the shared state to show the work is now in the compliance phase.

821
00:28:35,640 --> 00:28:38,840
She writes the candidate list and the reasoning behind it into that state.

822
00:28:38,840 --> 00:28:41,720
When Olivia steps in, she looks at that same source of truth.

823
00:28:41,720 --> 00:28:43,320
She sees exactly what Lucy saw.

824
00:28:43,320 --> 00:28:46,040
She performs her review and updates the state with her findings.

825
00:28:46,040 --> 00:28:48,520
When Tim takes his turn, he reads that same data.

826
00:28:48,520 --> 00:28:49,800
No translation is required.

827
00:28:49,800 --> 00:28:51,080
No context is lost.

828
00:28:51,080 --> 00:28:52,760
This is why check pointing is so vital.

829
00:28:52,760 --> 00:28:54,360
The shared state is the check point.

830
00:28:54,360 --> 00:28:55,960
Every agent can resume from it.

831
00:28:55,960 --> 00:28:57,400
Every change is atomic.

832
00:28:57,400 --> 00:29:00,040
Either the update happens completely or it doesn't happen at all.

833
00:29:00,040 --> 00:29:02,920
You never end up with partial data or inconsistencies.

834
00:29:02,920 --> 00:29:06,120
But even with shared state, agents have to validate each other.

835
00:29:06,120 --> 00:29:07,720
Lucy cannot blindly trust Rex.

836
00:29:07,720 --> 00:29:10,520
Olivia cannot assume Tim scheduled the interviews correctly.

837
00:29:10,520 --> 00:29:12,360
The validation pattern is straightforward.

838
00:29:12,360 --> 00:29:14,360
Before you accept an output, you run a check.

839
00:29:14,360 --> 00:29:18,040
Olivia runs a function to see if the candidates actually match the job requirements.

840
00:29:18,040 --> 00:29:21,720
She verifies the calendar isn't already booked before Tim sends the invites.

841
00:29:21,720 --> 00:29:24,040
If the validation fails, the work stops.

842
00:29:24,040 --> 00:29:26,280
An exception is raised and Lucy sees it.

843
00:29:26,280 --> 00:29:30,040
She then decides if Rex should try again or if it's time to call a human.

844
00:29:30,040 --> 00:29:34,280
The escalation trigger is that specific point where the agent hands off to a person.

845
00:29:34,280 --> 00:29:35,880
When does Lucy escalate?

846
00:29:35,880 --> 00:29:38,520
She does it when the decision is something an agent shouldn't make alone.

847
00:29:38,520 --> 00:29:41,160
If Olivia flags a compliance risk, that's an escalation.

848
00:29:41,160 --> 00:29:43,800
That affects legal exposure, not just the process.

849
00:29:43,800 --> 00:29:47,320
If sourcing returns zero candidates after three tries, that's an escalation.

850
00:29:47,320 --> 00:29:49,720
Maybe the job requirements are just unrealistic.

851
00:29:49,720 --> 00:29:52,920
You define these thresholds upfront as part of your governance.

852
00:29:52,920 --> 00:29:55,320
If there's a resume gap over two years, you escalate.

853
00:29:55,320 --> 00:29:58,520
If a candidate comes from a direct competitor, you escalate.

854
00:29:58,520 --> 00:29:59,880
These aren't technical bugs.

855
00:29:59,880 --> 00:30:02,680
They are organizational rules that require human judgment.

856
00:30:02,680 --> 00:30:05,720
Measuring the success of these handoffs is the KPI that matters.

857
00:30:05,720 --> 00:30:07,720
How many tasks finished without a human?

858
00:30:07,720 --> 00:30:09,320
How often did we have to escalate?

859
00:30:09,320 --> 00:30:10,920
What was the time cost when we did?

860
00:30:10,920 --> 00:30:15,960
In mature systems, we see a 45% reduction in manual handoffs when agents use shared state.

861
00:30:15,960 --> 00:30:20,520
It's not because the agents are doing everything, it's because they are reducing the friction in the steps they do handle.

862
00:30:20,520 --> 00:30:22,920
They only escalate when it's truly necessary.

863
00:30:22,920 --> 00:30:27,960
They move the qualified work forward without needing a human to click "Approve" at every single stage.

864
00:30:27,960 --> 00:30:30,280
Coordination works when agents have clear boundaries.

865
00:30:30,280 --> 00:30:32,200
Let's talk about those boundaries.

866
00:30:32,200 --> 00:30:33,880
Identity and least privilege.

867
00:30:33,880 --> 00:30:35,240
The Security Foundation.

868
00:30:35,240 --> 00:30:38,440
This is where the system either holds together or collapses under its own weight.

869
00:30:38,440 --> 00:30:40,280
agents cannot share human credentials.

870
00:30:40,280 --> 00:30:41,240
This is not a preference.

871
00:30:41,240 --> 00:30:42,840
It's a requirement.

872
00:30:42,840 --> 00:30:48,840
And yet, in production deployments across 2026, organizations are still trying to run agents with shared accounts.

873
00:30:48,840 --> 00:30:51,240
A service account password that five agents know.

874
00:30:51,240 --> 00:30:54,040
An API key embedded in three different applications.

875
00:30:54,040 --> 00:30:59,080
A human's credentials delegated to automation because it seemed simpler than setting up separate identities.

876
00:30:59,080 --> 00:31:00,120
But here's the problem.

877
00:31:00,120 --> 00:31:03,800
Every time this happens, governance fails, not eventually, immediately.

878
00:31:03,800 --> 00:31:06,520
Because the moment you can't attribute an action to a specific agent,

879
00:31:06,520 --> 00:31:09,000
you've lost the ability to enforce accountability.

880
00:31:09,000 --> 00:31:12,280
If three agents share an account and something goes wrong, which agent did it?

881
00:31:12,280 --> 00:31:13,320
You have no answer.

882
00:31:13,320 --> 00:31:15,320
You have logs showing the account access to file,

883
00:31:15,320 --> 00:31:17,800
but you have no trace of which agent made the decision.

884
00:31:17,800 --> 00:31:21,800
And you have no way to restrict what that particular agent can do differently next time.

885
00:31:21,800 --> 00:31:23,160
The requirement is clear.

886
00:31:23,160 --> 00:31:24,600
Each agent gets a dedicated,

887
00:31:24,600 --> 00:31:26,040
intro workload identity.

888
00:31:26,040 --> 00:31:27,320
Not a shared service account.

889
00:31:27,320 --> 00:31:29,400
Not a human credential borrowed and delegated.

890
00:31:29,400 --> 00:31:32,200
A separate identity that exists only for that agent.

891
00:31:32,200 --> 00:31:34,840
That identity has its own password or certificate.

892
00:31:34,840 --> 00:31:35,720
Its own permissions.

893
00:31:35,720 --> 00:31:36,760
And its own audit trail.

894
00:31:36,760 --> 00:31:39,160
When Lucy the HR supervisor makes a decision,

895
00:31:39,160 --> 00:31:41,080
the system logs that Lucy made it.

896
00:31:41,080 --> 00:31:43,560
Not some shared account labeled automation.

897
00:31:43,560 --> 00:31:46,040
This is the foundation of least privilege for agents.

898
00:31:46,040 --> 00:31:49,560
Leased privilege doesn't mean minimize what the agent can access.

899
00:31:49,560 --> 00:31:52,840
It means give the agent exactly what it needs to do its job.

900
00:31:52,840 --> 00:31:54,440
Nothing more, nothing less.

901
00:31:54,440 --> 00:31:57,160
A sourcing agent needs to read from the ATS and LinkedIn,

902
00:31:57,160 --> 00:32:00,520
but it doesn't need to read HR files or access the finance system.

903
00:32:00,520 --> 00:32:04,040
And it definitely doesn't need to modify anyone's record or delete data.

904
00:32:04,040 --> 00:32:05,560
The permission model has three layers.

905
00:32:05,560 --> 00:32:06,760
First, graph scopes.

906
00:32:06,760 --> 00:32:08,600
What APIs can this agent call?

907
00:32:08,600 --> 00:32:09,960
Second, connector access.

908
00:32:09,960 --> 00:32:11,880
If this agent uses external data,

909
00:32:11,880 --> 00:32:13,480
which connectors can it query?

910
00:32:13,480 --> 00:32:15,800
Third, data classification.

911
00:32:15,800 --> 00:32:18,200
Some data is marked sensitive or confidential.

912
00:32:18,200 --> 00:32:19,960
Can this agent access it?

913
00:32:19,960 --> 00:32:22,920
An agent that sources candidates might have these permissions.

914
00:32:22,920 --> 00:32:24,360
Read from the ATS connector.

915
00:32:24,360 --> 00:32:25,560
Read from LinkedIn connector.

916
00:32:25,560 --> 00:32:28,680
And read public teams channels where open roles are discussed.

917
00:32:28,680 --> 00:32:29,640
Not write to ATS.

918
00:32:29,640 --> 00:32:30,760
Not read from Salesforce.

919
00:32:30,760 --> 00:32:32,120
Not access personnel files.

920
00:32:32,120 --> 00:32:33,480
It's a narrow permission set.

921
00:32:33,480 --> 00:32:34,760
Specific to its job.

922
00:32:34,760 --> 00:32:36,440
Auditable down to the individual scope.

923
00:32:36,440 --> 00:32:39,000
The compliance specialist agent has different permissions.

924
00:32:39,000 --> 00:32:41,400
Read from the ATS connector to see the candidates.

925
00:32:41,400 --> 00:32:44,280
Read from the HR data repository to check policies.

926
00:32:44,280 --> 00:32:47,160
And read from external compliance databases to verify regulations.

927
00:32:47,160 --> 00:32:48,680
It doesn't have right access to anything.

928
00:32:48,680 --> 00:32:51,400
It can flag issues, but a human or a supervisor agent

929
00:32:51,400 --> 00:32:52,920
makes the decision to act on them.

930
00:32:52,920 --> 00:32:54,120
And that's where things change.

931
00:32:54,120 --> 00:32:55,720
Because most deployments get it wrong,

932
00:32:55,720 --> 00:33:00,120
they over-permission agents to avoid having to manage complex permission hierarchies.

933
00:33:00,120 --> 00:33:02,680
They give an agent access to everything it might need,

934
00:33:02,680 --> 00:33:04,520
plus some things it probably doesn't.

935
00:33:04,520 --> 00:33:07,080
An agent that handles hiring gets full sharepoint access

936
00:33:07,080 --> 00:33:08,840
because it might need to read policies

937
00:33:08,840 --> 00:33:12,360
and an agent that manages IT tasks gets permissions to every system

938
00:33:12,360 --> 00:33:14,680
because we might ask it to do different things later.

939
00:33:14,680 --> 00:33:17,240
Over-permissioning is the number one cause of AI breaches.

940
00:33:17,240 --> 00:33:18,760
Not because agents are malicious,

941
00:33:18,760 --> 00:33:21,880
but because overly broad permissions create a tax surface.

942
00:33:21,880 --> 00:33:24,200
A compromised agent with full system access

943
00:33:24,200 --> 00:33:26,680
isn't just dangerous because of what it was designed to do.

944
00:33:26,680 --> 00:33:30,680
It's dangerous because of all the things a compromised agent could be tricked into doing.

945
00:33:30,680 --> 00:33:33,960
A prompt injection attack that makes an agent export confidential data

946
00:33:33,960 --> 00:33:37,720
becomes viable when the agent has export permissions, it never needed.

947
00:33:37,720 --> 00:33:40,840
Conditional access for agents applies the same policy framework

948
00:33:40,840 --> 00:33:42,200
that protects human users,

949
00:33:42,200 --> 00:33:44,360
not just permissions but risk-based controls.

950
00:33:44,360 --> 00:33:47,960
If an agent is accessing resources from an unusual location, block it.

951
00:33:47,960 --> 00:33:51,960
If an agent is making a pattern of calls that looks like data expiltration flag it,

952
00:33:51,960 --> 00:33:55,080
if an agent is running at a time outside normal operating hours,

953
00:33:55,080 --> 00:33:56,920
require additional validation.

954
00:33:56,920 --> 00:33:59,080
These are the same controls that protect humans.

955
00:33:59,080 --> 00:34:02,600
Now they protect agents, a real example, an email triage agent.

956
00:34:02,600 --> 00:34:04,680
It can read emails from a specific mailbox.

957
00:34:04,680 --> 00:34:05,800
It can flag urgent ones.

958
00:34:05,800 --> 00:34:08,600
It cannot delete emails. It cannot forward them externally.

959
00:34:08,600 --> 00:34:10,120
It cannot access attachments.

960
00:34:10,120 --> 00:34:11,640
It cannot modify the inbox rules.

961
00:34:11,640 --> 00:34:13,000
Every constraint is explicit.

962
00:34:13,000 --> 00:34:15,400
Every permission maps to a specific job function.

963
00:34:15,400 --> 00:34:19,320
The agent is useful because it understands context and escalates appropriately.

964
00:34:19,320 --> 00:34:22,760
It's safe because it cannot cause damage even if it's reasoning is wrong.

965
00:34:22,760 --> 00:34:24,280
Identity is the foundation.

966
00:34:24,280 --> 00:34:26,680
Now let's talk about what happens when things go wrong.

967
00:34:26,680 --> 00:34:30,200
Audit trails and observability, making agents accountable.

968
00:34:30,200 --> 00:34:32,680
Here's what keeps compliance officers awake at night.

969
00:34:32,680 --> 00:34:34,280
We don't know what the agent did.

970
00:34:34,280 --> 00:34:36,920
You have an agent operating in your system, something goes wrong.

971
00:34:36,920 --> 00:34:40,360
Customer data leaked, a financial record was modified incorrectly,

972
00:34:40,360 --> 00:34:42,120
an email was sent that shouldn't have been sent.

973
00:34:42,120 --> 00:34:43,560
Someone asks, what did the agent do?

974
00:34:43,560 --> 00:34:44,520
How did this happen?

975
00:34:44,520 --> 00:34:46,040
Who authorized it?

976
00:34:46,040 --> 00:34:47,000
And the answer comes back.

977
00:34:47,000 --> 00:34:48,200
We don't have that information.

978
00:34:48,200 --> 00:34:49,800
That answer is unacceptable.

979
00:34:49,800 --> 00:34:52,600
And yet, it's what most organizations have right now

980
00:34:52,600 --> 00:34:56,280
because they never wired auditability into their agent deployments.

981
00:34:56,280 --> 00:34:58,120
Auditability means three things.

982
00:34:58,120 --> 00:35:00,120
First, every decision is logged.

983
00:35:00,120 --> 00:35:01,960
When Lucy, the supervisor agent,

984
00:35:01,960 --> 00:35:05,240
decides to escalate something to a human, that decision gets recorded.

985
00:35:05,240 --> 00:35:06,600
What data did she evaluate?

986
00:35:06,600 --> 00:35:08,040
What rule triggered the escalation?

987
00:35:08,040 --> 00:35:09,160
What exact timestamp?

988
00:35:09,160 --> 00:35:12,680
Second, every tool call is captured.

989
00:35:12,680 --> 00:35:15,560
When Tim invokes the calendar API to schedule a meeting,

990
00:35:15,560 --> 00:35:17,000
the system logs the call.

991
00:35:17,000 --> 00:35:18,360
What parameters, what response,

992
00:35:18,360 --> 00:35:20,200
and what the agent did with the result.

993
00:35:20,200 --> 00:35:21,880
Third, every data access is tracked.

994
00:35:21,880 --> 00:35:23,160
Which agent accessed?

995
00:35:23,160 --> 00:35:24,040
Which file?

996
00:35:24,040 --> 00:35:24,440
When?

997
00:35:24,440 --> 00:35:25,080
What did it read?

998
00:35:25,080 --> 00:35:25,880
Did it copy it?

999
00:35:25,880 --> 00:35:26,680
Did it modify it?

1000
00:35:26,680 --> 00:35:27,560
All of it logged.

1001
00:35:27,560 --> 00:35:28,440
But here's the problem.

1002
00:35:29,160 --> 00:35:32,520
Organizations assume that logging and auditability are the same thing.

1003
00:35:32,520 --> 00:35:33,880
They're not logging is data.

1004
00:35:33,880 --> 00:35:36,280
Gigabytes of unstructured text saying what happened.

1005
00:35:36,280 --> 00:35:37,880
Auditability is intelligence.

1006
00:35:37,880 --> 00:35:40,600
The ability to answer specific questions about what happened,

1007
00:35:40,600 --> 00:35:42,520
why it happened, and who was responsible.

1008
00:35:42,520 --> 00:35:44,200
Pervue audit is the backbone here.

1009
00:35:44,200 --> 00:35:47,800
It's Microsoft's unified audit log for Microsoft 365.

1010
00:35:47,800 --> 00:35:49,400
Everything that happens in exchange,

1011
00:35:49,400 --> 00:35:53,720
SharePoint, Teams, OneDrive, and Graph flows into Pervue.

1012
00:35:53,720 --> 00:35:57,000
Agent activity gets captured there alongside human activity.

1013
00:35:57,000 --> 00:35:59,480
Lucy reading a file, logged, Tim sending an email,

1014
00:35:59,480 --> 00:36:01,720
logged Olivia flagging a record, logged.

1015
00:36:01,720 --> 00:36:04,600
One system, one source of truth.

1016
00:36:04,600 --> 00:36:05,640
But here's the nuance.

1017
00:36:05,640 --> 00:36:07,800
Agent logs and human logs are not the same thing.

1018
00:36:07,800 --> 00:36:09,080
When a human access is a file,

1019
00:36:09,080 --> 00:36:11,240
it's because the human decided to access it.

1020
00:36:11,240 --> 00:36:13,080
They searched, they found it, they opened it.

1021
00:36:13,080 --> 00:36:14,520
That's one entry in the log.

1022
00:36:14,520 --> 00:36:16,280
When an agent access is a file,

1023
00:36:16,280 --> 00:36:17,720
the context is different.

1024
00:36:17,720 --> 00:36:19,400
The agent was instructed by its supervisor

1025
00:36:19,400 --> 00:36:21,080
to check compliance on a candidate,

1026
00:36:21,080 --> 00:36:22,760
and the supervisor was following a workflow

1027
00:36:22,760 --> 00:36:25,000
that responded to a specific requisition.

1028
00:36:25,000 --> 00:36:27,880
The access is part of a chain of decisions that extends backward.

1029
00:36:27,880 --> 00:36:29,960
Auditability requires capturing that chain

1030
00:36:29,960 --> 00:36:31,560
not just the access event.

1031
00:36:31,560 --> 00:36:33,480
This is where intelligent dashboards matter.

1032
00:36:33,480 --> 00:36:34,840
Raw logs are noise.

1033
00:36:34,840 --> 00:36:36,280
Thousands of events per hour.

1034
00:36:36,280 --> 00:36:37,720
Hundreds of thousands per day.

1035
00:36:37,720 --> 00:36:39,080
You cannot read them manually.

1036
00:36:39,080 --> 00:36:40,920
You need dashboards that show anomalies.

1037
00:36:40,920 --> 00:36:42,120
That answer questions.

1038
00:36:42,120 --> 00:36:43,400
And that flag patterns.

1039
00:36:43,400 --> 00:36:45,880
A dashboard might show this agent access files

1040
00:36:45,880 --> 00:36:47,960
from three different departments in one hour.

1041
00:36:47,960 --> 00:36:49,000
That's unusual.

1042
00:36:49,000 --> 00:36:50,040
Why?

1043
00:36:50,040 --> 00:36:53,640
A dashboard might show this agent exported data at 2 a.m.

1044
00:36:53,640 --> 00:36:56,200
That violates policy, flag it.

1045
00:36:56,200 --> 00:36:58,360
A dashboard might reconstruct a timeline.

1046
00:36:58,360 --> 00:36:59,800
Requisition arrived Monday,

1047
00:36:59,800 --> 00:37:01,000
sourcing happened Tuesday,

1048
00:37:01,000 --> 00:37:02,760
compliance review happened Wednesday,

1049
00:37:02,760 --> 00:37:04,840
but then compliance flags were overridden

1050
00:37:04,840 --> 00:37:06,440
and hiring proceeded anyway.

1051
00:37:06,440 --> 00:37:08,120
Who overrode them? Why?

1052
00:37:08,120 --> 00:37:10,120
Integration with CM takes this further.

1053
00:37:10,120 --> 00:37:13,240
Your CM, security information and event management system,

1054
00:37:13,240 --> 00:37:14,760
is where security operations lives.

1055
00:37:14,760 --> 00:37:16,200
It's where incidents get detected.

1056
00:37:16,200 --> 00:37:18,440
Agent logs flowing into CM means your security team

1057
00:37:18,440 --> 00:37:20,360
can see agent behavior in the same view

1058
00:37:20,360 --> 00:37:23,480
as network traffic, user logins, and system changes.

1059
00:37:23,480 --> 00:37:25,080
Anomalies that span agent activity

1060
00:37:25,080 --> 00:37:27,000
and network activity become visible.

1061
00:37:27,000 --> 00:37:28,760
An agent exporting data is suspicious,

1062
00:37:28,760 --> 00:37:30,680
but an agent exporting data and uploading it

1063
00:37:30,680 --> 00:37:33,320
to an external cloud storage service is an incident.

1064
00:37:33,320 --> 00:37:35,480
CM sees both events and correlates them.

1065
00:37:35,480 --> 00:37:36,600
A real example.

1066
00:37:36,600 --> 00:37:38,680
An organization discovers that customer data

1067
00:37:38,680 --> 00:37:40,760
was accessed inappropriately over a week.

1068
00:37:40,760 --> 00:37:42,760
Someone asks, "Reconstruct what happened?"

1069
00:37:42,760 --> 00:37:46,200
The auditability system lets you walk backward through time.

1070
00:37:46,200 --> 00:37:46,920
Day one.

1071
00:37:46,920 --> 00:37:50,760
Agent X accessed file Y because it was handling a support ticket.

1072
00:37:50,760 --> 00:37:51,560
Day two.

1073
00:37:51,560 --> 00:37:54,520
Agent X accessed the same file again and then exported it,

1074
00:37:54,520 --> 00:37:55,960
but no reason was logged.

1075
00:37:55,960 --> 00:37:56,600
Red flag.

1076
00:37:56,600 --> 00:37:59,880
Day three, the file was shared externally

1077
00:37:59,880 --> 00:38:02,120
by the export agent without authorization.

1078
00:38:02,120 --> 00:38:04,520
The audit trail shows not just that it happened,

1079
00:38:04,520 --> 00:38:06,120
but where governance broke down,

1080
00:38:06,120 --> 00:38:08,120
where the escalation should have triggered but didn't,

1081
00:38:08,120 --> 00:38:10,280
and where permissions should have blocked it but didn't.

1082
00:38:10,280 --> 00:38:12,040
Observability tells you what happened,

1083
00:38:12,040 --> 00:38:13,800
but you also need to prevent bad things

1084
00:38:13,800 --> 00:38:14,920
from happening in the first place.

1085
00:38:14,920 --> 00:38:17,880
Human approval loops, the safety gate,

1086
00:38:17,880 --> 00:38:20,120
the foundation is built, identity is set,

1087
00:38:20,120 --> 00:38:21,880
permissions are locked, audit trails are running.

1088
00:38:21,880 --> 00:38:23,880
You have an agent that understands context

1089
00:38:23,880 --> 00:38:27,000
and talks to other agents, but a massive problem remains.

1090
00:38:27,000 --> 00:38:28,760
Some decisions need human judgment,

1091
00:38:28,760 --> 00:38:30,280
and you cannot automate that away.

1092
00:38:30,280 --> 00:38:32,360
The question isn't whether humans should stay involved.

1093
00:38:32,360 --> 00:38:33,240
They have to be there.

1094
00:38:33,240 --> 00:38:34,840
The real question is how you involve them

1095
00:38:34,840 --> 00:38:36,840
without breaking the speed of the system.

1096
00:38:36,840 --> 00:38:39,800
If every single action requires a person to stop and think,

1097
00:38:39,800 --> 00:38:41,000
you have built a bottleneck.

1098
00:38:41,000 --> 00:38:43,560
You have turned your agents into fancy suggestion engines.

1099
00:38:43,560 --> 00:38:46,680
The human sees a recommendation, clicks approve, and moves on.

1100
00:38:46,680 --> 00:38:49,640
You have only reduced the manual work by maybe 20%.

1101
00:38:49,640 --> 00:38:53,000
The agent finds a candidate, but a person still screens them.

1102
00:38:53,000 --> 00:38:55,400
The agent picks a meeting time, but a person still confirms it.

1103
00:38:55,400 --> 00:38:57,720
This is not a transformation, it is just theater.

1104
00:38:57,720 --> 00:38:59,960
The solution is the approval loop pattern.

1105
00:38:59,960 --> 00:39:01,880
In this model, the agent proposes an action.

1106
00:39:01,880 --> 00:39:04,280
The human reviews that proposal with the full context,

1107
00:39:04,280 --> 00:39:05,800
the human makes the call.

1108
00:39:05,800 --> 00:39:07,880
The system only executes if it gets the green light.

1109
00:39:07,880 --> 00:39:10,040
The agent doesn't sit around waiting forever.

1110
00:39:10,040 --> 00:39:11,880
And the human doesn't get buried in requests.

1111
00:39:11,880 --> 00:39:14,760
The whole process moves fast enough to actually save time,

1112
00:39:14,760 --> 00:39:17,080
but you must be clear about what needs a signature.

1113
00:39:17,080 --> 00:39:17,960
Not everything does.

1114
00:39:18,920 --> 00:39:21,400
An agent that can only act after a human reviews,

1115
00:39:21,400 --> 00:39:23,960
it isn't really an agent, it is just a form generator.

1116
00:39:23,960 --> 00:39:26,040
The line between doing the work and asking for help

1117
00:39:26,040 --> 00:39:27,480
is where governance actually lives.

1118
00:39:27,480 --> 00:39:29,320
Certain actions always need a human eye.

1119
00:39:29,320 --> 00:39:31,640
Anything involving money belongs in this category.

1120
00:39:31,640 --> 00:39:34,760
Payments, budget shifts, or changes to someone's pay.

1121
00:39:34,760 --> 00:39:37,080
Anything that deletes information needs a check,

1122
00:39:37,080 --> 00:39:40,040
deleting records, closing accounts, or archiving data,

1123
00:39:40,040 --> 00:39:42,600
anything that goes outside the company needs a review.

1124
00:39:42,600 --> 00:39:44,360
External emails, sharing with customers,

1125
00:39:44,360 --> 00:39:47,000
or sending files to people without standard access.

1126
00:39:47,000 --> 00:39:49,320
These actions carry risks that go beyond the moment,

1127
00:39:49,320 --> 00:39:50,920
they have consequences down the line.

1128
00:39:50,920 --> 00:39:54,040
Most routine tasks do not need this level of oversight.

1129
00:39:54,040 --> 00:39:56,360
An agent reading an email doesn't need permission.

1130
00:39:56,360 --> 00:39:59,320
An agent scheduling an internal sync doesn't need a sign off.

1131
00:39:59,320 --> 00:40:01,560
An agent updating a record within its normal range

1132
00:40:01,560 --> 00:40:02,680
doesn't need a human.

1133
00:40:02,680 --> 00:40:04,360
These actions are easy to undo.

1134
00:40:04,360 --> 00:40:05,640
They fit inside the lines.

1135
00:40:05,640 --> 00:40:07,400
The cost of making them wait for a person

1136
00:40:07,400 --> 00:40:09,800
is higher than the risk of the action itself.

1137
00:40:09,800 --> 00:40:12,440
This is where threshold-based approval changes the game.

1138
00:40:12,440 --> 00:40:15,000
You don't approve specific actions, you approve ranges.

1139
00:40:15,000 --> 00:40:18,760
An expense agent might auto-approve any claim under $150.

1140
00:40:18,760 --> 00:40:22,280
It sends claims between $150 and $500 to a manager.

1141
00:40:22,280 --> 00:40:24,680
Anything over $500 goes straight to finance.

1142
00:40:24,680 --> 00:40:26,920
The agent isn't asking for permission every time.

1143
00:40:26,920 --> 00:40:28,040
It is following a rule.

1144
00:40:28,040 --> 00:40:30,280
Small claims are already within its authority.

1145
00:40:30,280 --> 00:40:32,520
The user experience is the biggest hurdle here.

1146
00:40:32,520 --> 00:40:35,160
An approval has to be fast, or it becomes a wall.

1147
00:40:35,160 --> 00:40:36,920
If a person has to read a long story,

1148
00:40:36,920 --> 00:40:40,120
dig for context, and open three different systems to check facts

1149
00:40:40,120 --> 00:40:41,720
that approval takes 10 minutes.

1150
00:40:41,720 --> 00:40:43,960
Now the agent is stuck, the user is waiting.

1151
00:40:43,960 --> 00:40:45,640
The time you were supposed to save is gone.

1152
00:40:45,640 --> 00:40:47,160
The fix is the evidence pack.

1153
00:40:47,160 --> 00:40:49,240
Instead of giving a human a raw request,

1154
00:40:49,240 --> 00:40:51,800
the agent gathers everything they need to decide.

1155
00:40:51,800 --> 00:40:54,600
An expense agent asking for an $800 registration

1156
00:40:54,600 --> 00:40:55,960
doesn't just ask for the money.

1157
00:40:55,960 --> 00:40:58,680
It explains that the employee used their training budget,

1158
00:40:58,680 --> 00:41:00,520
but this conference is a requirement.

1159
00:41:00,520 --> 00:41:02,360
It shows that previous years were approved

1160
00:41:02,360 --> 00:41:03,560
and attaches the receipt.

1161
00:41:03,560 --> 00:41:05,480
It even notes that the supervisor is on board.

1162
00:41:05,480 --> 00:41:07,000
It takes 30 seconds to read.

1163
00:41:07,000 --> 00:41:08,200
One click, done.

1164
00:41:08,200 --> 00:41:09,480
The agent isn't just guessing.

1165
00:41:09,480 --> 00:41:10,680
It provides the logic.

1166
00:41:10,680 --> 00:41:13,320
The human sees exactly what data the agent looked at

1167
00:41:13,320 --> 00:41:14,440
and which rules it applied.

1168
00:41:14,440 --> 00:41:17,240
They see where the decision hit a boundary that required a person.

1169
00:41:17,240 --> 00:41:19,080
The human can still override the system

1170
00:41:19,080 --> 00:41:20,840
if they know something the agent doesn't.

1171
00:41:20,840 --> 00:41:22,280
But usually the info is all there.

1172
00:41:22,280 --> 00:41:23,240
The choice is obvious.

1173
00:41:23,240 --> 00:41:24,520
The approval happens in seconds.

1174
00:41:24,520 --> 00:41:27,960
In a real-world example, an HR agent handles expense reports.

1175
00:41:27,960 --> 00:41:29,800
Small claims go through automatically.

1176
00:41:29,800 --> 00:41:32,760
Medium claims go to managers with a summary and a receipt.

1177
00:41:32,760 --> 00:41:35,320
The manager sees the amount and the recommendation.

1178
00:41:35,320 --> 00:41:36,840
If it looks right, they click once.

1179
00:41:36,840 --> 00:41:38,600
If it looks weird, they ask for more info.

1180
00:41:38,600 --> 00:41:40,920
Large claims go to finance for a policy check.

1181
00:41:40,920 --> 00:41:44,280
Finance sees that same evidence pack plus any compliance flags.

1182
00:41:44,280 --> 00:41:46,600
The agent doesn't wait on people for the boring stuff.

1183
00:41:46,600 --> 00:41:49,480
Humans aren't drowning in approvals they don't actually need to see.

1184
00:41:49,480 --> 00:41:52,920
Approval loops work when the company has clear rules about human judgment

1185
00:41:52,920 --> 00:41:55,160
which leads us to how you manage this at scale.

1186
00:41:55,160 --> 00:41:57,400
Agent 365, the control plane.

1187
00:41:57,400 --> 00:42:00,440
Everything we have talked about, identity, permissions, audit trails,

1188
00:42:00,440 --> 00:42:03,560
and approval loops only works if you have a place to manage it.

1189
00:42:03,560 --> 00:42:05,720
You need a way to see which agents exist.

1190
00:42:05,720 --> 00:42:07,080
You need a way to set the rules.

1191
00:42:07,080 --> 00:42:09,000
You need to know the second things go wrong.

1192
00:42:09,000 --> 00:42:11,400
That is where agent 365 comes in.

1193
00:42:11,400 --> 00:42:14,040
Agent 365 launched on May 1, 2026.

1194
00:42:14,040 --> 00:42:16,200
It costs $15 per user every month.

1195
00:42:16,200 --> 00:42:18,600
For the first time, companies have a single cockpit

1196
00:42:18,600 --> 00:42:21,320
for agent governance right inside Microsoft 365.

1197
00:42:21,320 --> 00:42:22,280
Think of it like this.

1198
00:42:22,280 --> 00:42:25,880
Before agent 365 managing agents was like trying to lock up a house

1199
00:42:25,880 --> 00:42:27,800
when you didn't know how many doors it had,

1200
00:42:27,800 --> 00:42:29,160
you might lock the front door.

1201
00:42:29,160 --> 00:42:30,440
You might bolt the basement.

1202
00:42:30,440 --> 00:42:33,640
But there could be windows you missed or back entrances you forgot about.

1203
00:42:33,640 --> 00:42:35,800
You had agents running in dark corners of the network

1204
00:42:35,800 --> 00:42:37,080
that nobody knew existed.

1205
00:42:37,080 --> 00:42:38,440
You had logs and permissions.

1206
00:42:38,440 --> 00:42:39,640
But you had no inventory.

1207
00:42:39,640 --> 00:42:40,840
You couldn't see the whole system.

1208
00:42:40,840 --> 00:42:44,040
Agent 365 fixes that by answering one simple question.

1209
00:42:44,040 --> 00:42:46,040
What agents are actually running in your company?

1210
00:42:46,040 --> 00:42:47,400
This is much harder than it sounds.

1211
00:42:47,400 --> 00:42:49,480
You have agents built in co-pilot studio.

1212
00:42:49,480 --> 00:42:51,720
You have others running in the power platform.

1213
00:42:51,720 --> 00:42:53,640
You have local agents on developer laptops.

1214
00:42:53,640 --> 00:42:55,960
You have tools from vendors and outside providers.

1215
00:42:55,960 --> 00:42:58,040
You even have agents that IT doesn't know about

1216
00:42:58,040 --> 00:42:59,880
because a team built them in secret.

1217
00:42:59,880 --> 00:43:00,760
This is Shadow AI.

1218
00:43:00,760 --> 00:43:02,840
These are the agents running outside the lines.

1219
00:43:02,840 --> 00:43:05,640
The agent registry in Agent 365 is your source of truth.

1220
00:43:05,640 --> 00:43:06,840
It shows you every agent.

1221
00:43:06,840 --> 00:43:08,440
It lists the ones you built on purpose

1222
00:43:08,440 --> 00:43:09,880
and the ones that showed up anyway.

1223
00:43:09,880 --> 00:43:12,120
It pulls data from Entra, Defender, and Intune.

1224
00:43:12,120 --> 00:43:14,600
It finds agents across 20 different types.

1225
00:43:14,600 --> 00:43:16,280
You see coding agents, desktop apps,

1226
00:43:16,280 --> 00:43:18,280
local tools, and remote servers in Azure.

1227
00:43:18,280 --> 00:43:20,040
The registry gives you the full picture.

1228
00:43:20,040 --> 00:43:21,720
Discovery is only the first step.

1229
00:43:21,720 --> 00:43:23,080
You have to be able to act.

1230
00:43:23,080 --> 00:43:24,920
That is why the risks column matters.

1231
00:43:24,920 --> 00:43:28,120
Agent 365 looks at every agent and flags the problems.

1232
00:43:28,120 --> 00:43:30,280
If an agent has permissions that are too broad,

1233
00:43:30,280 --> 00:43:31,320
it gets a flag.

1234
00:43:31,320 --> 00:43:32,680
If an agent is in production,

1235
00:43:32,680 --> 00:43:34,680
but was never approved, it gets a flag.

1236
00:43:34,680 --> 00:43:36,520
If it touches sensitive data without logging,

1237
00:43:36,520 --> 00:43:37,480
it gets a flag.

1238
00:43:37,480 --> 00:43:39,480
If the behavior looks weird compared to last week,

1239
00:43:39,480 --> 00:43:40,280
it gets a flag.

1240
00:43:40,280 --> 00:43:41,560
Risk isn't just a yes or no.

1241
00:43:41,560 --> 00:43:43,960
It is categorized as high, medium, or low.

1242
00:43:43,960 --> 00:43:45,640
An agent with too much power is high risk.

1243
00:43:45,640 --> 00:43:47,560
An agent that nobody uses is low risk,

1244
00:43:47,560 --> 00:43:49,080
but you should still check on it.

1245
00:43:49,080 --> 00:43:51,480
An agent with no owner is a major red flag.

1246
00:43:51,480 --> 00:43:53,560
If a production agent has been fine for six months

1247
00:43:53,560 --> 00:43:55,400
but suddenly changes its permissions,

1248
00:43:55,400 --> 00:43:56,840
it moves to medium risk.

1249
00:43:56,840 --> 00:43:59,720
These risks make governance something you can actually do.

1250
00:43:59,720 --> 00:44:02,600
A company doesn't have the time to manually check thousands of agents,

1251
00:44:02,600 --> 00:44:04,360
but they can focus on the ones with flags.

1252
00:44:04,360 --> 00:44:07,800
They can ask why an agent has right access to the whole share point tenant.

1253
00:44:07,800 --> 00:44:11,240
They can ask why an agent is suddenly touching data it has never seen before.

1254
00:44:11,240 --> 00:44:13,800
Policy templates bring all these controls together.

1255
00:44:13,800 --> 00:44:16,440
Agent 365 has baseline and enhanced options.

1256
00:44:16,440 --> 00:44:17,960
Baseline is for low risk agents.

1257
00:44:17,960 --> 00:44:20,680
These are the ones that just read info and make suggestions.

1258
00:44:20,680 --> 00:44:23,800
The baseline template sets up standard policies and basic logging.

1259
00:44:23,800 --> 00:44:25,560
Enhanced is for the high risk stuff.

1260
00:44:25,560 --> 00:44:27,160
These are agents that change records,

1261
00:44:27,160 --> 00:44:29,640
sent messages, or touch core business systems.

1262
00:44:29,640 --> 00:44:31,720
Enhanced ads, real-time monitoring,

1263
00:44:31,720 --> 00:44:32,920
and forces human approvals.

1264
00:44:32,920 --> 00:44:34,920
You don't have to build your governance from scratch.

1265
00:44:34,920 --> 00:44:36,200
You just pick a template.

1266
00:44:36,200 --> 00:44:37,960
It puts the right guards in place.

1267
00:44:37,960 --> 00:44:40,440
As you learn what works, you can tweak the templates.

1268
00:44:40,440 --> 00:44:41,640
You change the thresholds.

1269
00:44:41,640 --> 00:44:42,840
You add new rules.

1270
00:44:42,840 --> 00:44:45,800
The templates grow as your company gets better at managing AI.

1271
00:44:45,800 --> 00:44:49,720
Agent 365 is basically mandatory if you are running more than a few agents.

1272
00:44:49,720 --> 00:44:51,240
The alternative is just chaos.

1273
00:44:51,240 --> 00:44:54,520
You end up with agents scattered everywhere with no central view

1274
00:44:54,520 --> 00:44:56,040
and no consistent rules.

1275
00:44:56,040 --> 00:44:58,120
Every team ends up making their own approval process

1276
00:44:58,120 --> 00:44:59,720
or they don't make one at all.

1277
00:44:59,720 --> 00:45:01,400
Every agent has its own way of logging,

1278
00:45:01,400 --> 00:45:02,600
or it doesn't log anything.

1279
00:45:02,600 --> 00:45:04,120
You aren't governing agents at that point.

1280
00:45:04,120 --> 00:45:06,520
You are just jumping from one crisis to the next.

1281
00:45:06,520 --> 00:45:08,680
The sign that a company is actually ready for AI

1282
00:45:08,680 --> 00:45:11,640
is the move from we have agents to we govern agents.

1283
00:45:11,640 --> 00:45:13,000
The early stage is simple.

1284
00:45:13,000 --> 00:45:15,240
You build an agent, it works, and everyone is happy.

1285
00:45:15,240 --> 00:45:16,600
The mature stage is different.

1286
00:45:16,600 --> 00:45:18,840
You have an inventory, you rank them by risk,

1287
00:45:18,840 --> 00:45:20,440
you apply policies across the board.

1288
00:45:20,440 --> 00:45:21,880
You know the moment something changes,

1289
00:45:21,880 --> 00:45:23,480
and you have a plan for when it does.

1290
00:45:23,480 --> 00:45:25,240
Agent 365 is the piece of the puzzle

1291
00:45:25,240 --> 00:45:27,160
that makes that mature state possible.

1292
00:45:27,160 --> 00:45:29,080
Agent 365 is the control plane,

1293
00:45:29,080 --> 00:45:30,920
but governance isn't just about the tech.

1294
00:45:30,920 --> 00:45:32,280
It is about the organization.

1295
00:45:33,000 --> 00:45:35,800
The governance framework, ownership and accountability.

1296
00:45:35,800 --> 00:45:37,720
Here is what kills agent deployments.

1297
00:45:37,720 --> 00:45:38,760
Nobody owns them.

1298
00:45:38,760 --> 00:45:41,160
You build an agent, it works, and you deploy it.

1299
00:45:41,160 --> 00:45:42,680
It starts handling real work.

1300
00:45:42,680 --> 00:45:44,520
But three months later, nobody remembers

1301
00:45:44,520 --> 00:45:45,880
who actually built the thing.

1302
00:45:45,880 --> 00:45:48,200
Nobody knows who is responsible if something goes wrong.

1303
00:45:48,200 --> 00:45:49,320
The agent keeps running

1304
00:45:49,320 --> 00:45:51,480
because nobody has the permission to turn it off.

1305
00:45:51,480 --> 00:45:52,680
Requirements change,

1306
00:45:52,680 --> 00:45:55,160
but the agent is still applying old rules from last year.

1307
00:45:55,160 --> 00:45:57,000
A security vulnerability is discovered

1308
00:45:57,000 --> 00:45:58,200
and nobody patches it

1309
00:45:58,200 --> 00:46:00,200
because the person who understands the code

1310
00:46:00,200 --> 00:46:01,880
left the company six months ago.

1311
00:46:01,880 --> 00:46:03,160
That is a governance failure.

1312
00:46:03,160 --> 00:46:04,840
It is not because of a bad policy.

1313
00:46:04,840 --> 00:46:06,680
It is because nobody has accountability.

1314
00:46:06,680 --> 00:46:08,040
Ownership starts with a person,

1315
00:46:08,040 --> 00:46:09,640
not a team label, not a department,

1316
00:46:09,640 --> 00:46:11,000
a named individual.

1317
00:46:11,000 --> 00:46:12,680
Someone whose job description includes

1318
00:46:12,680 --> 00:46:14,440
maintaining this specific agent.

1319
00:46:14,440 --> 00:46:15,640
Someone who can be contacted

1320
00:46:15,640 --> 00:46:17,320
when decisions need to be made.

1321
00:46:17,320 --> 00:46:19,160
Someone who gets woken up at three in the morning

1322
00:46:19,160 --> 00:46:20,920
if the agent starts behaving wrong.

1323
00:46:20,920 --> 00:46:22,360
That ownership forces clarity.

1324
00:46:22,360 --> 00:46:23,560
It forces accountability.

1325
00:46:23,560 --> 00:46:24,920
It forces someone to actually care

1326
00:46:24,920 --> 00:46:26,840
about whether the agent is running correctly.

1327
00:46:26,840 --> 00:46:29,320
The Racy model translates that ownership into roles.

1328
00:46:29,320 --> 00:46:30,600
Who approves new agents?

1329
00:46:30,600 --> 00:46:32,360
Who reviews them before they go live?

1330
00:46:32,360 --> 00:46:33,720
Who operates them day to day?

1331
00:46:33,720 --> 00:46:35,400
Who escalates when something breaks?

1332
00:46:35,400 --> 00:46:37,640
These are not the same people and that is the point.

1333
00:46:37,640 --> 00:46:39,240
An engineer builds the agent.

1334
00:46:39,240 --> 00:46:41,000
They are responsible for the implementation.

1335
00:46:41,000 --> 00:46:42,600
They understand the code, the logic,

1336
00:46:42,600 --> 00:46:43,960
and the tool integrations.

1337
00:46:43,960 --> 00:46:46,200
But they do not get to approve it for production.

1338
00:46:46,200 --> 00:46:47,880
Approval comes from a business owner.

1339
00:46:47,880 --> 00:46:49,000
This is someone who understands

1340
00:46:49,000 --> 00:46:50,840
what the agent is supposed to accomplish

1341
00:46:50,840 --> 00:46:52,360
and whether it actually does that.

1342
00:46:52,360 --> 00:46:54,040
The business owner is the one who approves it

1343
00:46:54,040 --> 00:46:55,320
for production deployment.

1344
00:46:55,320 --> 00:46:57,240
Once it is live, operations owns it.

1345
00:46:57,240 --> 00:46:58,600
Operations monitors the agent.

1346
00:46:58,600 --> 00:46:59,560
They run the checks.

1347
00:46:59,560 --> 00:47:01,160
They get alerted if something goes wrong.

1348
00:47:01,160 --> 00:47:03,000
But operations does not make business decisions

1349
00:47:03,000 --> 00:47:04,440
about what the agent should do.

1350
00:47:04,440 --> 00:47:05,720
That is the business owner's job.

1351
00:47:05,720 --> 00:47:07,240
And if there is a fundamental problem

1352
00:47:07,240 --> 00:47:09,800
where the agent is causing harm or violating policy,

1353
00:47:09,800 --> 00:47:11,160
operations escalates.

1354
00:47:11,160 --> 00:47:13,000
The escalation goes to a governance committee

1355
00:47:13,000 --> 00:47:14,120
or a security team.

1356
00:47:14,120 --> 00:47:15,320
Someone who can make the decision

1357
00:47:15,320 --> 00:47:17,320
to shut the agent down if necessary.

1358
00:47:17,320 --> 00:47:19,560
This separation of concerns is why Racy works.

1359
00:47:19,560 --> 00:47:20,920
It distributes accountability

1360
00:47:20,920 --> 00:47:23,560
so that no single failure point tanks the whole system.

1361
00:47:23,560 --> 00:47:25,800
The engineer cannot quietly deploy a broken agent

1362
00:47:25,800 --> 00:47:27,720
because the business owner has to sign off.

1363
00:47:27,720 --> 00:47:30,440
The business owner cannot prioritize speed over safety

1364
00:47:30,440 --> 00:47:32,840
because operations and governance have veto power.

1365
00:47:32,840 --> 00:47:34,760
Operations cannot make business decisions

1366
00:47:34,760 --> 00:47:36,920
unilaterally because they are not closest

1367
00:47:36,920 --> 00:47:38,120
to the business problem.

1368
00:47:38,120 --> 00:47:39,400
Risk classification determines

1369
00:47:39,400 --> 00:47:41,000
how strict the process is.

1370
00:47:41,000 --> 00:47:42,440
A low-risk productivity agent

1371
00:47:42,440 --> 00:47:44,520
might just read documents and summarize them.

1372
00:47:44,520 --> 00:47:46,200
That has a lightweight approval process.

1373
00:47:46,200 --> 00:47:47,480
The business owner signs off,

1374
00:47:47,480 --> 00:47:49,320
operations sets it up and it is done.

1375
00:47:49,320 --> 00:47:51,000
But a high-risk agent is different.

1376
00:47:51,000 --> 00:47:52,520
If it modifies financial records

1377
00:47:52,520 --> 00:47:53,960
or makes hiring decisions,

1378
00:47:53,960 --> 00:47:55,800
it goes through a full approval workflow.

1379
00:47:56,600 --> 00:47:58,680
Business Review, security review, compliance review,

1380
00:47:58,680 --> 00:48:00,600
governance sign off, it takes longer.

1381
00:48:00,600 --> 00:48:01,480
That is intentional.

1382
00:48:01,480 --> 00:48:02,440
The risk is higher.

1383
00:48:02,440 --> 00:48:04,040
The approval workflow is the path

1384
00:48:04,040 --> 00:48:05,880
from development to production.

1385
00:48:05,880 --> 00:48:07,720
A developer has an idea for an agent.

1386
00:48:07,720 --> 00:48:09,320
They submit it to a governance board.

1387
00:48:09,320 --> 00:48:11,240
The board evaluates the business case.

1388
00:48:11,240 --> 00:48:12,360
Is this actually needed?

1389
00:48:12,360 --> 00:48:13,560
Does it solve a real problem?

1390
00:48:13,560 --> 00:48:14,680
They evaluate the risk.

1391
00:48:14,680 --> 00:48:15,560
What could go wrong?

1392
00:48:15,560 --> 00:48:16,760
What would the impact be?

1393
00:48:16,760 --> 00:48:18,680
They evaluate the technical design.

1394
00:48:18,680 --> 00:48:20,600
Does it follow our architecture standards?

1395
00:48:20,600 --> 00:48:21,880
Are the permissions appropriate?

1396
00:48:21,880 --> 00:48:24,200
If all three checks pass, it moves to a pilot phase.

1397
00:48:24,200 --> 00:48:26,760
Limited deployment, real data, real users,

1398
00:48:26,760 --> 00:48:29,080
monitoring to see if it actually works as intended.

1399
00:48:29,080 --> 00:48:31,800
Only after the pilot succeeds, does it move to full production.

1400
00:48:31,800 --> 00:48:33,640
And production deployment comes with conditions.

1401
00:48:33,640 --> 00:48:35,080
This agent runs in this team only.

1402
00:48:35,080 --> 00:48:36,600
This agent uses this data only.

1403
00:48:36,600 --> 00:48:38,280
This agent escalates to a human

1404
00:48:38,280 --> 00:48:40,760
if the confidence falls below a certain threshold.

1405
00:48:40,760 --> 00:48:42,040
These are not afterthoughts.

1406
00:48:42,040 --> 00:48:43,560
They are built in from the approval.

1407
00:48:43,560 --> 00:48:46,200
Lifecycle management means the agent has a lifespan.

1408
00:48:46,200 --> 00:48:47,000
It is created.

1409
00:48:47,000 --> 00:48:47,720
It is deployed.

1410
00:48:47,720 --> 00:48:48,680
It is monitored.

1411
00:48:48,680 --> 00:48:50,920
At some point, either it evolves into something new

1412
00:48:50,920 --> 00:48:51,880
or it is retired.

1413
00:48:51,880 --> 00:48:54,120
You do not run agents forever without review.

1414
00:48:54,120 --> 00:48:55,880
You have a quarterly governance review

1415
00:48:55,880 --> 00:48:57,320
where agents are evaluated.

1416
00:48:57,320 --> 00:48:59,160
Are they still serving their original purpose?

1417
00:48:59,160 --> 00:49:00,520
Have requirements changed?

1418
00:49:00,520 --> 00:49:01,960
Is the agent still secure?

1419
00:49:01,960 --> 00:49:03,720
Is the risk profile still appropriate?

1420
00:49:03,720 --> 00:49:05,080
The review is not optional.

1421
00:49:05,080 --> 00:49:06,520
It is built into the process.

1422
00:49:06,520 --> 00:49:09,400
KPMG manages 276,000 agents

1423
00:49:09,400 --> 00:49:12,760
across 138 countries using this exact framework.

1424
00:49:12,760 --> 00:49:14,680
Not because KPMG likes process.

1425
00:49:14,680 --> 00:49:15,880
Because at that scale,

1426
00:49:15,880 --> 00:49:17,800
process is the only thing that keeps chaos

1427
00:49:17,800 --> 00:49:19,400
from consuming the whole system.

1428
00:49:19,400 --> 00:49:20,600
Every agent has an owner.

1429
00:49:20,600 --> 00:49:22,520
Every agent has risk classification.

1430
00:49:22,520 --> 00:49:24,280
Every agent went through approval.

1431
00:49:24,280 --> 00:49:25,800
Every agent is reviewed quarterly.

1432
00:49:25,800 --> 00:49:27,720
That structure is how they scale.

1433
00:49:27,720 --> 00:49:29,080
Data protection for agents.

1434
00:49:29,080 --> 00:49:30,760
DLP and sensitivity labels.

1435
00:49:30,760 --> 00:49:32,600
Agents leak data the way humans do.

1436
00:49:32,600 --> 00:49:34,440
Sometimes by accident, sometimes by design,

1437
00:49:34,440 --> 00:49:36,120
sometimes because they are tricked,

1438
00:49:36,120 --> 00:49:37,960
a human gets a fishing email asking them

1439
00:49:37,960 --> 00:49:39,560
to forward customer data.

1440
00:49:39,560 --> 00:49:42,040
Usually they realize it is suspicious and refuse.

1441
00:49:42,040 --> 00:49:44,440
An agent does not evaluate intent the same way.

1442
00:49:44,440 --> 00:49:46,760
Given agent access to customer data

1443
00:49:46,760 --> 00:49:49,640
and an instruction to send this to the integration partner

1444
00:49:49,640 --> 00:49:50,440
and it sends it.

1445
00:49:50,440 --> 00:49:53,240
If the instruction came from a prompt injection attack

1446
00:49:53,240 --> 00:49:55,480
buried in a document the agent was analyzing,

1447
00:49:55,480 --> 00:49:57,000
the agent has no way to know.

1448
00:49:57,000 --> 00:49:58,520
It followed a logical instruction

1449
00:49:58,520 --> 00:50:00,600
from what looked like an authorized source.

1450
00:50:00,600 --> 00:50:02,040
This is not a theoretical risk.

1451
00:50:02,040 --> 00:50:03,320
This is how breaches happen.

1452
00:50:03,320 --> 00:50:04,360
An agent reads data.

1453
00:50:04,360 --> 00:50:06,440
It is allowed to read a prompt injection attack

1454
00:50:06,440 --> 00:50:09,080
modifies that data before the agent processes it.

1455
00:50:09,080 --> 00:50:11,560
The attack tells the agent to exfiltrate information.

1456
00:50:11,560 --> 00:50:13,000
The agent reasoning logically

1457
00:50:13,000 --> 00:50:14,760
from the modified instructions complies.

1458
00:50:14,760 --> 00:50:15,640
The data is gone.

1459
00:50:15,640 --> 00:50:18,440
Data loss prevention for agents is the first line of defense.

1460
00:50:18,440 --> 00:50:20,840
Per view, DLP does not just apply to humans anymore.

1461
00:50:20,840 --> 00:50:23,400
It now has specific agent enforcement modes.

1462
00:50:23,400 --> 00:50:25,720
When an agent tries to process sensitive data,

1463
00:50:25,720 --> 00:50:28,680
DLP can intercept the flow before the data reaches the model.

1464
00:50:28,680 --> 00:50:30,040
This is the critical moment.

1465
00:50:30,040 --> 00:50:31,800
If DLP blocks the sensitive data here,

1466
00:50:31,800 --> 00:50:32,840
the model never sees it.

1467
00:50:32,840 --> 00:50:35,640
The agent cannot accidentally leak what it never had access to.

1468
00:50:35,640 --> 00:50:38,120
The way this works is that DLP policies get evaluated

1469
00:50:38,120 --> 00:50:39,240
on agent prompts.

1470
00:50:39,240 --> 00:50:41,240
You mark certain data as confidential,

1471
00:50:41,240 --> 00:50:42,520
like customer records,

1472
00:50:42,520 --> 00:50:44,680
financial information, or trade secrets.

1473
00:50:44,680 --> 00:50:46,280
You define a DLP rule.

1474
00:50:46,280 --> 00:50:49,720
If an agent tries to process confidential data, block it.

1475
00:50:49,720 --> 00:50:51,320
When an agent reads a customer email

1476
00:50:51,320 --> 00:50:53,640
marked as confidential and tries to summarize it,

1477
00:50:53,640 --> 00:50:55,320
DLP intercepts the operation.

1478
00:50:55,320 --> 00:50:57,080
The email is not included in the prompt.

1479
00:50:57,080 --> 00:50:59,000
The agent processes a redacted version

1480
00:50:59,000 --> 00:51:00,520
or does not process it at all.

1481
00:51:00,520 --> 00:51:02,360
Every blocked attempt gets logged in per view

1482
00:51:02,360 --> 00:51:03,800
for forensic investigation.

1483
00:51:03,800 --> 00:51:05,000
But DLP is reactive.

1484
00:51:05,000 --> 00:51:06,040
It blocks bad things.

1485
00:51:06,040 --> 00:51:07,800
Sensitivity labels are proactive.

1486
00:51:07,800 --> 00:51:09,000
They mark data at the source

1487
00:51:09,000 --> 00:51:11,400
and control how agents can use it.

1488
00:51:11,400 --> 00:51:13,720
A sensitivity label answers one question.

1489
00:51:13,720 --> 00:51:15,880
What is this data and what can happen to it?

1490
00:51:15,880 --> 00:51:18,520
You mark an email thread as customer confidential.

1491
00:51:18,520 --> 00:51:20,760
Agents can read it for specific business purposes.

1492
00:51:20,760 --> 00:51:22,120
Agents cannot export it.

1493
00:51:22,120 --> 00:51:24,040
Agents cannot use it for model training.

1494
00:51:24,040 --> 00:51:26,280
Agents cannot share it with external systems.

1495
00:51:26,280 --> 00:51:27,800
The label travels with the data.

1496
00:51:27,800 --> 00:51:29,960
If the email is forwarded, the label stays.

1497
00:51:29,960 --> 00:51:31,880
If the content is quoted in a report,

1498
00:51:31,880 --> 00:51:33,560
the label applies to the report.

1499
00:51:33,560 --> 00:51:35,720
But here is the subtle distinction that matters.

1500
00:51:35,720 --> 00:51:38,360
It is the difference between the agent can read this

1501
00:51:38,360 --> 00:51:40,040
and the agent should read this.

1502
00:51:40,040 --> 00:51:42,760
Permissions determine what an agent can technically access.

1503
00:51:42,760 --> 00:51:45,080
A sourcing agent has red access to candidate files.

1504
00:51:45,080 --> 00:51:45,960
That is permission.

1505
00:51:45,960 --> 00:51:48,600
But should a sourcing agent read the detailed performance reviews

1506
00:51:48,600 --> 00:51:49,160
of candidates?

1507
00:51:49,160 --> 00:51:51,720
Technically, the performance reviews might not be restricted.

1508
00:51:51,720 --> 00:51:54,200
The agent has red access to the HR system.

1509
00:51:54,200 --> 00:51:57,480
But organizationally, a sourcing agent should not read that data.

1510
00:51:57,480 --> 00:51:59,080
It is not relevant to their job.

1511
00:51:59,080 --> 00:52:00,440
Reading it creates exposure.

1512
00:52:00,440 --> 00:52:02,760
Sensitivity labels enforce that should.

1513
00:52:02,760 --> 00:52:04,440
They are not permission boundaries.

1514
00:52:04,440 --> 00:52:06,040
They are organizational policy.

1515
00:52:06,040 --> 00:52:08,520
A label says this data is performance data.

1516
00:52:08,520 --> 00:52:11,400
An agent should not process it without executive approval.

1517
00:52:11,400 --> 00:52:13,240
When a sourcing agent queries the system,

1518
00:52:13,240 --> 00:52:14,920
performance data gets filtered out.

1519
00:52:14,920 --> 00:52:16,760
Not because the agent lacks permission.

1520
00:52:16,760 --> 00:52:18,840
Because the label prevents inappropriate use.

1521
00:52:18,840 --> 00:52:21,640
This matters because compliance lives in the should layer.

1522
00:52:21,640 --> 00:52:23,240
Not the can layer.

1523
00:52:23,240 --> 00:52:26,840
An ordered asking why an agent accessed sensitive data

1524
00:52:26,840 --> 00:52:29,480
does not accept it had permission as an answer.

1525
00:52:29,480 --> 00:52:30,920
Regulators want to know why.

1526
00:52:30,920 --> 00:52:33,560
Sensitivity labels force that conversation up front.

1527
00:52:33,560 --> 00:52:36,040
They prevent inappropriate access before it happens.

1528
00:52:36,040 --> 00:52:38,600
Retention and deletion becomes an agent problem

1529
00:52:38,600 --> 00:52:40,440
because agents build context.

1530
00:52:40,440 --> 00:52:41,640
They read documents.

1531
00:52:41,640 --> 00:52:43,560
They build memory from that reading.

1532
00:52:43,560 --> 00:52:45,720
If that document needs to be deleted for compliance,

1533
00:52:45,720 --> 00:52:48,040
for a user request or for data minimization,

1534
00:52:48,040 --> 00:52:49,240
the agent needs to forget it.

1535
00:52:49,240 --> 00:52:51,160
This is not how AI systems usually work.

1536
00:52:51,160 --> 00:52:52,280
Models do not forget.

1537
00:52:52,280 --> 00:52:53,400
But governance requires it.

1538
00:52:53,400 --> 00:52:55,000
Consider an agent that supports customers

1539
00:52:55,000 --> 00:52:56,440
by reading their email history.

1540
00:52:56,440 --> 00:52:59,320
The agent can read customer emails to provide better support.

1541
00:52:59,320 --> 00:53:02,360
But it cannot export those emails or use them to train other models.

1542
00:53:02,360 --> 00:53:04,760
The emails are marked with retention and usage labels.

1543
00:53:04,760 --> 00:53:06,360
When the retention period expires,

1544
00:53:06,360 --> 00:53:08,600
the agent purges that conversation history.

1545
00:53:08,600 --> 00:53:10,360
When the customer requests deletion,

1546
00:53:10,360 --> 00:53:12,120
the agent purges immediately.

1547
00:53:12,120 --> 00:53:14,840
The governance model is built into the agent's data handling.

1548
00:53:14,840 --> 00:53:16,680
This is why data protection is not optional

1549
00:53:16,680 --> 00:53:18,520
when agents handle regulated data.

1550
00:53:18,520 --> 00:53:20,680
It is the guardrail that prevents the system

1551
00:53:20,680 --> 00:53:22,520
from becoming a liability.

1552
00:53:22,520 --> 00:53:24,200
Real-world deployment patterns.

1553
00:53:24,200 --> 00:53:25,320
HR agents.

1554
00:53:25,320 --> 00:53:27,400
HR is where multi-agent orchestration

1555
00:53:27,400 --> 00:53:29,000
proves its value in production.

1556
00:53:29,000 --> 00:53:32,680
It works here because HR workflows force you to get governance right.

1557
00:53:32,680 --> 00:53:34,040
They have three specific traits.

1558
00:53:34,040 --> 00:53:36,840
First, they are high volume, every new hire,

1559
00:53:36,840 --> 00:53:39,240
every onboarding, every benefits question.

1560
00:53:39,240 --> 00:53:41,240
These tasks repeat constantly.

1561
00:53:41,240 --> 00:53:43,160
Second, they are rule-based.

1562
00:53:43,160 --> 00:53:46,440
You have regulations and company policies that cannot be bent.

1563
00:53:46,440 --> 00:53:47,880
Third, they spend multiple systems.

1564
00:53:47,880 --> 00:53:51,720
You have the ATS, the HR IS, payroll, benefits platforms,

1565
00:53:51,720 --> 00:53:52,520
and email.

1566
00:53:52,520 --> 00:53:54,680
No single system owns the full workflow.

1567
00:53:54,680 --> 00:53:57,480
If an agent can only read one system, it is useless.

1568
00:53:57,480 --> 00:54:00,920
This combination means HR cannot tolerate sloppy orchestration.

1569
00:54:00,920 --> 00:54:03,480
You can build an experimental agent that summarizes emails

1570
00:54:03,480 --> 00:54:05,880
and it might work fine, even if it misses some nuance.

1571
00:54:05,880 --> 00:54:08,040
But HR agents have downstream consequences.

1572
00:54:08,040 --> 00:54:10,120
A hiring agent that misclassifies a candidate

1573
00:54:10,120 --> 00:54:11,320
costs the company time.

1574
00:54:11,320 --> 00:54:13,880
An onboarding agent that forgets to provision an account

1575
00:54:13,880 --> 00:54:15,080
kills productivity.

1576
00:54:15,080 --> 00:54:17,640
A support agent that gives the wrong benefits advice

1577
00:54:17,640 --> 00:54:19,160
creates legal exposure.

1578
00:54:19,160 --> 00:54:21,000
The hiring workflow starts with sourcing.

1579
00:54:21,000 --> 00:54:23,000
A sourcing agent queries the ATS,

1580
00:54:23,000 --> 00:54:24,920
linked in and internal referral platforms.

1581
00:54:24,920 --> 00:54:27,320
It returns candidates ranked by match quality.

1582
00:54:27,320 --> 00:54:29,000
This ranking is deterministic.

1583
00:54:29,000 --> 00:54:31,800
It follows explicit criteria like skills,

1584
00:54:31,800 --> 00:54:34,120
experience, and location.

1585
00:54:34,120 --> 00:54:37,480
The agent evaluates candidates against those specific requirements.

1586
00:54:37,480 --> 00:54:39,160
It does not add subjective judgment.

1587
00:54:39,160 --> 00:54:42,520
It does not prefer a candidate just because their background looks interesting.

1588
00:54:42,520 --> 00:54:44,440
It simply evaluates against the rubric.

1589
00:54:44,440 --> 00:54:46,840
From there, the workflow moves to screening.

1590
00:54:46,840 --> 00:54:50,200
A screening agent evaluates the candidates the sourcing agent found.

1591
00:54:50,200 --> 00:54:52,520
But screening is more complex than sourcing.

1592
00:54:52,520 --> 00:54:55,240
This is where subjective judgment enters the process.

1593
00:54:55,240 --> 00:54:57,240
Does this person's background actually fit?

1594
00:54:57,240 --> 00:54:58,520
Beyond just a keyword match?

1595
00:54:58,520 --> 00:54:59,880
Are there red flags in their history?

1596
00:54:59,880 --> 00:55:01,960
Do they meet the culture fit criteria?

1597
00:55:01,960 --> 00:55:03,880
A screening agent is not just an algorithm.

1598
00:55:03,880 --> 00:55:04,680
It is reasoning.

1599
00:55:04,680 --> 00:55:08,120
It reads resumes, understands context, and makes judgments.

1600
00:55:08,120 --> 00:55:09,320
Then comes scheduling.

1601
00:55:09,320 --> 00:55:12,840
An interview scheduling agent coordinates availability across the candidate,

1602
00:55:12,840 --> 00:55:14,680
the interviewers, and the facilities.

1603
00:55:14,680 --> 00:55:15,640
It checks calendars.

1604
00:55:15,640 --> 00:55:16,920
It proposes time slots.

1605
00:55:16,920 --> 00:55:18,200
It sends invitations.

1606
00:55:18,200 --> 00:55:20,600
It even handles rescheduling when conflicts arise.

1607
00:55:20,600 --> 00:55:22,120
Scheduling is purely transactional.

1608
00:55:22,120 --> 00:55:24,760
But it is incredibly time consuming when done manually.

1609
00:55:24,760 --> 00:55:27,320
An agent that handles the saves hours per hire.

1610
00:55:27,320 --> 00:55:28,440
Offer generation follows.

1611
00:55:28,440 --> 00:55:31,240
Once the interview is over and the hiring decision is made,

1612
00:55:31,240 --> 00:55:33,000
an offer agent generates the letter.

1613
00:55:33,000 --> 00:55:36,040
It pulls from templates and inserts candidate data like salary,

1614
00:55:36,040 --> 00:55:37,640
start date, and reporting structure.

1615
00:55:37,640 --> 00:55:39,320
It incorporates regulatory language.

1616
00:55:39,320 --> 00:55:40,680
It adds company-specific terms.

1617
00:55:40,680 --> 00:55:43,640
The offer then gets routed for approval before it is sent out.

1618
00:55:43,640 --> 00:55:45,080
Background checks run in parallel.

1619
00:55:45,080 --> 00:55:47,080
Some organizations run them before the offer,

1620
00:55:47,080 --> 00:55:48,280
while others run them after.

1621
00:55:48,280 --> 00:55:50,360
Either way, an agent tracks the process.

1622
00:55:50,360 --> 00:55:51,480
It submits the request.

1623
00:55:51,480 --> 00:55:52,440
It tracks the status.

1624
00:55:52,440 --> 00:55:53,720
It flags issues.

1625
00:55:53,720 --> 00:55:56,520
It integrates those results back into the hiring decision.

1626
00:55:56,520 --> 00:55:58,440
Each of these steps requires different expertise.

1627
00:55:58,440 --> 00:56:00,840
Sourcing requires understanding qualifications.

1628
00:56:00,840 --> 00:56:02,680
Screening requires judgment about culture.

1629
00:56:02,680 --> 00:56:04,440
Scheduling requires coordination.

1630
00:56:04,440 --> 00:56:06,840
Offer generation requires legal accuracy.

1631
00:56:06,840 --> 00:56:09,880
A single agent trying to handle all of this gets overwhelmed.

1632
00:56:09,880 --> 00:56:11,560
It lacks clear domain boundaries.

1633
00:56:11,560 --> 00:56:15,400
Its decisions become confused because it is switching contexts constantly.

1634
00:56:15,400 --> 00:56:16,520
The error rate climbs.

1635
00:56:16,520 --> 00:56:18,040
And the latency explodes.

1636
00:56:18,040 --> 00:56:20,840
The multi-agent approach assigns each step to a specialist.

1637
00:56:20,840 --> 00:56:22,440
A sourcing agent owns sourcing.

1638
00:56:22,440 --> 00:56:24,120
A screening agent owns screening.

1639
00:56:24,120 --> 00:56:26,120
An interview scheduling agent owns scheduling.

1640
00:56:26,120 --> 00:56:27,800
Each one is an expert in its domain.

1641
00:56:27,800 --> 00:56:29,080
Each one has a narrow scope.

1642
00:56:29,080 --> 00:56:31,880
Each one makes clean decisions within clear boundaries.

1643
00:56:31,880 --> 00:56:33,480
The supervisor coordinates them.

1644
00:56:33,480 --> 00:56:35,320
The hiring manager submits a requisition.

1645
00:56:35,320 --> 00:56:37,400
And the supervisor sees that as a new workflow,

1646
00:56:37,400 --> 00:56:39,000
it invokes the sourcing agent.

1647
00:56:39,000 --> 00:56:40,200
Sourcing completes.

1648
00:56:40,200 --> 00:56:41,960
The supervisor invokes screening.

1649
00:56:41,960 --> 00:56:43,800
Screening flags two top candidates.

1650
00:56:43,800 --> 00:56:45,880
The supervisor invokes scheduling for both.

1651
00:56:45,880 --> 00:56:47,000
Parallel interviews happen.

1652
00:56:47,000 --> 00:56:47,800
Results come back.

1653
00:56:47,800 --> 00:56:49,240
The supervisor evaluates them.

1654
00:56:49,240 --> 00:56:50,760
The hiring manager chooses.

1655
00:56:50,760 --> 00:56:52,680
The supervisor invokes offer generation.

1656
00:56:52,680 --> 00:56:54,040
The offer gets approved.

1657
00:56:54,040 --> 00:56:55,960
The supervisor invokes background checks.

1658
00:56:55,960 --> 00:56:57,320
The results come back clean.

1659
00:56:57,320 --> 00:56:58,440
And the workflow completes.

1660
00:56:58,440 --> 00:56:59,560
The person is hired.

1661
00:56:59,560 --> 00:57:01,640
The metrics that matter here are measurable.

1662
00:57:01,640 --> 00:57:04,440
Time to hire drops because agents eliminate manual handoffs.

1663
00:57:04,440 --> 00:57:06,840
On boarding cycle time shrinks when the same pattern

1664
00:57:06,840 --> 00:57:08,280
handles document collection.

1665
00:57:08,280 --> 00:57:10,440
IT provisioning and benefits enrollment.

1666
00:57:10,440 --> 00:57:13,160
Employee satisfaction rises because the process is consistent.

1667
00:57:13,160 --> 00:57:15,880
Nobody's hiring experience depends on which HR person

1668
00:57:15,880 --> 00:57:17,880
happens to be available that day.

1669
00:57:17,880 --> 00:57:21,080
Imperium labs reduce their manual HR workload by 50%

1670
00:57:21,080 --> 00:57:23,240
using exactly this orchestration pattern.

1671
00:57:23,240 --> 00:57:25,160
They did not do it by replacing humans.

1672
00:57:25,160 --> 00:57:26,680
They did it by eliminating the friction

1673
00:57:26,680 --> 00:57:27,880
that made humans inefficient.

1674
00:57:27,880 --> 00:57:29,000
HR is one use case.

1675
00:57:29,000 --> 00:57:30,040
Let's look at another.

1676
00:57:30,040 --> 00:57:31,720
Real-world deployment patterns.

1677
00:57:31,720 --> 00:57:33,400
IT operations agents.

1678
00:57:33,400 --> 00:57:36,760
IT operations is different from HR in a fundamental way.

1679
00:57:36,760 --> 00:57:39,640
If an HR agent makes a mistake, someone doesn't get hired.

1680
00:57:39,640 --> 00:57:41,000
Or they get unborted slowly.

1681
00:57:41,000 --> 00:57:42,120
That is bad.

1682
00:57:42,120 --> 00:57:44,440
But if an IT operations agent makes a mistake,

1683
00:57:44,440 --> 00:57:46,440
systems go down, infrastructure fails,

1684
00:57:46,440 --> 00:57:47,640
customers lose access.

1685
00:57:47,640 --> 00:57:49,720
The organization emerges money by the minute.

1686
00:57:49,720 --> 00:57:51,640
This is why IT operations is the highest

1687
00:57:51,640 --> 00:57:53,080
stakes orchestration use case.

1688
00:57:53,080 --> 00:57:54,600
The consequences are not delayed.

1689
00:57:54,600 --> 00:57:56,120
They are immediate and measurable.

1690
00:57:56,120 --> 00:57:59,880
The ticket triage workflow is where most IT operations agents start.

1691
00:57:59,880 --> 00:58:01,640
Support tickets arrive constantly.

1692
00:58:01,640 --> 00:58:03,000
Users report problems.

1693
00:58:03,000 --> 00:58:04,120
Equipment breaks.

1694
00:58:04,120 --> 00:58:05,480
Software crashes.

1695
00:58:05,480 --> 00:58:07,160
A human has to read each ticket.

1696
00:58:07,160 --> 00:58:08,680
Understand what is being reported.

1697
00:58:08,680 --> 00:58:10,120
And root it to the right team.

1698
00:58:10,120 --> 00:58:11,880
This is work that happens at volume.

1699
00:58:11,880 --> 00:58:14,760
A medium-sized organization gets hundreds of tickets every day.

1700
00:58:14,760 --> 00:58:16,680
A triage agent reads incoming tickets.

1701
00:58:16,680 --> 00:58:18,360
It extracts the essential information.

1702
00:58:18,360 --> 00:58:19,560
What system is affected.

1703
00:58:19,560 --> 00:58:20,520
What is the symptom?

1704
00:58:20,520 --> 00:58:21,720
Who is impacted?

1705
00:58:21,720 --> 00:58:23,880
It classifies the ticket as a network issue.

1706
00:58:23,880 --> 00:58:24,840
A software issue.

1707
00:58:24,840 --> 00:58:25,880
Or an access issue.

1708
00:58:25,880 --> 00:58:28,280
Based on that classification, it roots the ticket.

1709
00:58:28,280 --> 00:58:30,360
A network issue goes to the network team.

1710
00:58:30,360 --> 00:58:32,280
An access issue goes to identity.

1711
00:58:32,280 --> 00:58:33,800
But triage is not binary.

1712
00:58:33,800 --> 00:58:35,320
Some tickets have overlapping concerns.

1713
00:58:35,320 --> 00:58:37,320
An employee might not be able to access an application

1714
00:58:37,320 --> 00:58:39,320
because their VPN connection is failing.

1715
00:58:39,320 --> 00:58:41,560
That is both a network issue and an access issue.

1716
00:58:41,560 --> 00:58:43,560
The triage agent recognizes the overlap.

1717
00:58:43,560 --> 00:58:45,240
It roots to both teams.

1718
00:58:45,240 --> 00:58:46,840
And flags that they need to coordinate.

1719
00:58:46,840 --> 00:58:49,080
Initial troubleshooting happens in parallel.

1720
00:58:49,080 --> 00:58:50,440
While the ticket is being rooted,

1721
00:58:50,440 --> 00:58:52,520
a troubleshooting agent starts investigating.

1722
00:58:52,520 --> 00:58:53,720
It checks the system status.

1723
00:58:53,720 --> 00:58:55,160
Is the service actually down?

1724
00:58:55,160 --> 00:58:57,000
Or is the user having a local problem?

1725
00:58:57,000 --> 00:58:58,440
It checks the user's configuration.

1726
00:58:58,440 --> 00:59:00,440
Are they using the right VPN settings?

1727
00:59:00,440 --> 00:59:01,880
Did they restart their machine?

1728
00:59:01,880 --> 00:59:03,880
The troubleshooting agent gathers data.

1729
00:59:03,880 --> 00:59:06,360
If it can resolve the issue like restarting a service

1730
00:59:06,360 --> 00:59:08,600
or resetting a password, it closes the ticket.

1731
00:59:08,600 --> 00:59:10,760
If it cannot resolve it, it escalates.

1732
00:59:10,760 --> 00:59:12,840
The ticket goes to a specialist with context.

1733
00:59:12,840 --> 00:59:14,920
The agent says, "Here's what I tried.

1734
00:59:14,920 --> 00:59:15,880
Here is what I found.

1735
00:59:15,880 --> 00:59:17,160
And here is where you need to start.

1736
00:59:17,160 --> 00:59:18,600
Escalation is the clean handoff.

1737
00:59:18,600 --> 00:59:20,920
The triage agent did not waste the specialist time.

1738
00:59:20,920 --> 00:59:22,920
The specialist does not start from zero.

1739
00:59:22,920 --> 00:59:24,280
They start from context.

1740
00:59:24,280 --> 00:59:27,160
That efficiency compounds across thousands of tickets.

1741
00:59:27,160 --> 00:59:29,160
Change management is the second workflow.

1742
00:59:29,160 --> 00:59:32,840
An IT team member wants to update a server or patch software.

1743
00:59:32,840 --> 00:59:34,200
The change cannot just happen.

1744
00:59:34,200 --> 00:59:35,000
It needs approval.

1745
00:59:35,000 --> 00:59:35,800
It needs planning.

1746
00:59:35,800 --> 00:59:38,520
It needs coordination so that it does not break something else.

1747
00:59:38,520 --> 00:59:40,440
A change management agent handles this.

1748
00:59:40,440 --> 00:59:42,120
Someone submits a change request.

1749
00:59:42,120 --> 00:59:43,320
And the agent evaluates it.

1750
00:59:43,320 --> 00:59:44,760
Is this change within policy?

1751
00:59:44,760 --> 00:59:46,120
What systems does it touch?

1752
00:59:46,120 --> 00:59:48,600
The agent checks the change against the dependency graph.

1753
00:59:48,600 --> 00:59:52,120
If a change touches a system that supports critical business functions,

1754
00:59:52,120 --> 00:59:53,720
it gets routed for risk review.

1755
00:59:53,720 --> 00:59:55,720
If it is routine maintenance with low risk,

1756
00:59:55,720 --> 00:59:56,920
it gets approved faster.

1757
00:59:56,920 --> 00:59:58,840
Either way, the agent schedules it.

1758
00:59:58,840 --> 01:00:02,200
It coordinates the timing so that multiple changes do not stack.

1759
01:00:02,200 --> 01:00:04,760
It triggers notifications so the right teams are ready.

1760
01:00:04,760 --> 01:00:06,200
It monitors execution.

1761
01:00:06,200 --> 01:00:08,520
It validates that the change worked as intended.

1762
01:00:08,520 --> 01:00:10,360
Incident response is the third workflow.

1763
01:00:10,360 --> 01:00:11,240
An alert fires.

1764
01:00:11,240 --> 01:00:12,120
The system is down.

1765
01:00:12,120 --> 01:00:13,960
The organization is bleeding money right now.

1766
01:00:13,960 --> 01:00:17,000
An incident response agent does not wait for a human to notice.

1767
01:00:17,000 --> 01:00:18,280
It detects the alert.

1768
01:00:18,280 --> 01:00:20,040
It launches the response immediately.

1769
01:00:20,040 --> 01:00:21,080
It gathers data.

1770
01:00:21,080 --> 01:00:22,360
What is the scope of the impact?

1771
01:00:22,360 --> 01:00:23,800
Which systems are affected?

1772
01:00:23,800 --> 01:00:25,240
Our customers impacted.

1773
01:00:25,240 --> 01:00:27,720
It triggers notifications to the incident commander.

1774
01:00:27,720 --> 01:00:29,880
It opens a communication channel in Slack or Teams.

1775
01:00:29,880 --> 01:00:31,320
It begins remediation.

1776
01:00:31,320 --> 01:00:33,400
Does it have authority to restart a service?

1777
01:00:33,400 --> 01:00:34,760
Can it fail over to a backup?

1778
01:00:34,760 --> 01:00:36,760
Can it isolate a compromised system?

1779
01:00:36,760 --> 01:00:37,880
For anything it cannot do?

1780
01:00:37,880 --> 01:00:39,320
It guides the incident commander.

1781
01:00:39,320 --> 01:00:41,320
It provides the data and the recommendations.

1782
01:00:41,320 --> 01:00:43,320
The communication happens in real time.

1783
01:00:43,320 --> 01:00:46,040
With the agent updating context as the situation evolves.

1784
01:00:46,040 --> 01:00:49,240
But here is where IT operations becomes genuinely complex.

1785
01:00:49,240 --> 01:00:50,760
Nothing exists in isolation.

1786
01:00:50,760 --> 01:00:52,760
A change to one system affects others.

1787
01:00:52,760 --> 01:00:55,880
A network failure impacts applications that depend on that network.

1788
01:00:55,880 --> 01:00:58,520
The agents need to understand IT dependencies.

1789
01:00:58,520 --> 01:01:00,200
Not as a list, as a graph.

1790
01:01:00,200 --> 01:01:03,320
The network knowledge graph represents the infrastructure topology.

1791
01:01:03,320 --> 01:01:04,200
Systems are nodes.

1792
01:01:04,200 --> 01:01:06,120
Dependencies are edges.

1793
01:01:06,120 --> 01:01:07,560
When a system fails,

1794
01:01:07,560 --> 01:01:10,440
the agent does not just flag that the system is down.

1795
01:01:10,440 --> 01:01:11,640
It knows what depends on it.

1796
01:01:11,640 --> 01:01:13,160
It knows what the blast radius is.

1797
01:01:13,160 --> 01:01:14,840
It knows which users are affected.

1798
01:01:14,840 --> 01:01:18,360
It can predict cascading failures if the primary database server is down.

1799
01:01:18,360 --> 01:01:20,280
It knows which applications are impacted.

1800
01:01:20,280 --> 01:01:22,040
It knows how quickly they will fail over.

1801
01:01:22,040 --> 01:01:23,960
And what the recovery time objective is.

1802
01:01:23,960 --> 01:01:26,360
An organization that combined multi agent reasoning

1803
01:01:26,360 --> 01:01:28,040
with a dynamic network knowledge graph

1804
01:01:28,040 --> 01:01:30,520
improved ticket resolution speed by 40%.

1805
01:01:30,520 --> 01:01:33,240
This did not happen because individual agents got faster.

1806
01:01:33,240 --> 01:01:35,960
It happened because agents stopped investigating blind.

1807
01:01:35,960 --> 01:01:37,320
They could see the full picture.

1808
01:01:37,320 --> 01:01:38,680
They understood dependencies.

1809
01:01:38,680 --> 01:01:40,760
They rooted tickets to the right team immediately.

1810
01:01:40,760 --> 01:01:42,760
This pattern generalizes.

1811
01:01:42,760 --> 01:01:45,480
Any domain with complex interconnected systems

1812
01:01:45,480 --> 01:01:47,000
benefits from the same approach.

1813
01:01:47,000 --> 01:01:48,760
IT operations is complex.

1814
01:01:48,760 --> 01:01:51,240
But there's a pattern here that applies to other domains too.

1815
01:01:51,240 --> 01:01:52,840
Real-world deployment patterns.

1816
01:01:52,840 --> 01:01:54,840
Sales and customer success agents.

1817
01:01:54,840 --> 01:01:57,160
Sales is the highest value use case for agents

1818
01:01:57,160 --> 01:01:59,400
because the economics are fundamentally different.

1819
01:01:59,400 --> 01:02:01,240
In HR, agents save time.

1820
01:02:01,240 --> 01:02:04,600
In IT operations, agents prevent downtime.

1821
01:02:04,600 --> 01:02:07,080
But in sales agents directly impact revenue.

1822
01:02:07,080 --> 01:02:10,280
An agent that helps a rep close one extra deal a quarter,

1823
01:02:10,280 --> 01:02:11,320
pays for itself.

1824
01:02:11,320 --> 01:02:13,800
But an agent that helps a rep close five deals

1825
01:02:13,800 --> 01:02:15,560
becomes a strategic asset.

1826
01:02:15,560 --> 01:02:17,720
The lead qualification workflow starts the moment

1827
01:02:17,720 --> 01:02:19,000
of prospect enters the funnel.

1828
01:02:19,000 --> 01:02:21,160
An agent researches them immediately.

1829
01:02:21,160 --> 01:02:22,200
What company are they at?

1830
01:02:22,200 --> 01:02:23,240
What is their industry?

1831
01:02:23,240 --> 01:02:24,520
What is their role?

1832
01:02:24,520 --> 01:02:26,360
What problems are they likely facing?

1833
01:02:26,360 --> 01:02:28,200
The agent pulls from multiple sources.

1834
01:02:28,200 --> 01:02:29,320
CRM history.

1835
01:02:29,320 --> 01:02:29,880
LinkedIn.

1836
01:02:29,880 --> 01:02:30,840
Company news.

1837
01:02:30,840 --> 01:02:31,880
Industry reports.

1838
01:02:31,880 --> 01:02:33,320
Product usage data.

1839
01:02:33,320 --> 01:02:35,160
It synthesizes this into a profile.

1840
01:02:35,160 --> 01:02:36,120
It is not a guess.

1841
01:02:36,120 --> 01:02:38,680
But a data-backed assessment of who this person is.

1842
01:02:38,680 --> 01:02:40,440
And why they might be interested.

1843
01:02:40,440 --> 01:02:41,560
Then comes scoring.

1844
01:02:41,560 --> 01:02:44,440
The agent evaluates the lead against your ideal customer profile.

1845
01:02:44,440 --> 01:02:45,480
How closely do they match?

1846
01:02:45,480 --> 01:02:46,360
What is their urgency?

1847
01:02:46,360 --> 01:02:47,320
What is their buying power?

1848
01:02:47,320 --> 01:02:48,760
The scoring is not a number.

1849
01:02:48,760 --> 01:02:50,120
It is a ranking with reasoning.

1850
01:02:50,120 --> 01:02:52,120
This lead matches because they are in healthcare.

1851
01:02:52,120 --> 01:02:53,560
They have a large IT budget.

1852
01:02:53,560 --> 01:02:54,680
And their company is growing.

1853
01:02:54,680 --> 01:02:56,920
That lead ranks lower because they are in education

1854
01:02:56,920 --> 01:02:58,520
which has different buying patterns.

1855
01:02:58,520 --> 01:03:00,280
The ranking helps the rep prioritize

1856
01:03:00,280 --> 01:03:01,880
instead of working leads randomly.

1857
01:03:01,880 --> 01:03:04,280
They work the most likely to close first.

1858
01:03:04,280 --> 01:03:05,880
Prioritization and outreach follow.

1859
01:03:05,880 --> 01:03:07,720
The agent does not just rank leads.

1860
01:03:07,720 --> 01:03:08,840
It times the outreach.

1861
01:03:08,840 --> 01:03:10,520
Is this the right moment to reach out?

1862
01:03:10,520 --> 01:03:12,200
Did something change in the prospect's world

1863
01:03:12,200 --> 01:03:13,240
that creates urgency?

1864
01:03:13,240 --> 01:03:14,440
Did a competitor win a deal?

1865
01:03:14,440 --> 01:03:15,560
Did they announce funding?

1866
01:03:15,560 --> 01:03:17,240
The agent finds the trigger events.

1867
01:03:17,240 --> 01:03:18,680
It sequences the outreach.

1868
01:03:18,680 --> 01:03:20,520
First an email with relevant insight.

1869
01:03:20,520 --> 01:03:22,120
Then a follow-up with the use case study.

1870
01:03:22,120 --> 01:03:23,640
Then a calendar invite to a demo.

1871
01:03:23,640 --> 01:03:24,600
The sequence is proven.

1872
01:03:24,600 --> 01:03:25,880
The timing is optimized.

1873
01:03:25,880 --> 01:03:27,400
The rep does not have to guess.

1874
01:03:27,400 --> 01:03:29,480
Opportunity management is the next layer.

1875
01:03:29,480 --> 01:03:30,840
A prospect becomes a deal.

1876
01:03:30,840 --> 01:03:33,480
And now the agent tracks that deal through the sales process.

1877
01:03:33,480 --> 01:03:34,360
What stage is it in?

1878
01:03:34,360 --> 01:03:35,480
How long has it been there?

1879
01:03:35,480 --> 01:03:37,000
What is the probability of close?

1880
01:03:37,000 --> 01:03:38,520
The agent does not just report status.

1881
01:03:38,520 --> 01:03:39,960
It recommends next best actions.

1882
01:03:39,960 --> 01:03:41,480
The deal is stuck in evaluation.

1883
01:03:41,480 --> 01:03:44,440
So the next step is to schedule a technical validation.

1884
01:03:44,440 --> 01:03:46,760
The agent sees when the customer is available

1885
01:03:46,760 --> 01:03:49,400
and it knows which internal expert to involve.

1886
01:03:49,400 --> 01:03:52,120
It surfaces recommendations that move deals forward.

1887
01:03:52,120 --> 01:03:54,120
Proposal generation happens in parallel.

1888
01:03:54,120 --> 01:03:55,720
Once evaluation is underway,

1889
01:03:55,720 --> 01:03:57,480
a proposal agent drafts the document.

1890
01:03:57,480 --> 01:03:58,920
It is not a templated form letter.

1891
01:03:58,920 --> 01:04:01,480
It incorporates everything learned about the customer.

1892
01:04:01,480 --> 01:04:02,680
They're specific challenges.

1893
01:04:02,680 --> 01:04:04,040
They're stated priorities.

1894
01:04:04,040 --> 01:04:05,640
They're team structure.

1895
01:04:05,640 --> 01:04:08,280
The proposal reads like it was written specifically for them

1896
01:04:08,280 --> 01:04:09,640
because it was...

1897
01:04:09,640 --> 01:04:12,840
The agent incorporated research and context at every step.

1898
01:04:12,840 --> 01:04:15,880
The rep reviews maybe tweaks a few sentences and sends it.

1899
01:04:15,880 --> 01:04:17,480
Deal tracking happens throughout.

1900
01:04:17,480 --> 01:04:20,600
The agent monitors signals that the deal is progressing or stalling.

1901
01:04:20,600 --> 01:04:24,120
Meeting scheduled, deal momentum increases, decision pushed,

1902
01:04:24,120 --> 01:04:25,480
momentum decreases.

1903
01:04:25,480 --> 01:04:27,640
Key stakeholder leaves the company, red flag.

1904
01:04:27,640 --> 01:04:30,440
The agent alerts the rep to changes immediately.

1905
01:04:30,440 --> 01:04:32,760
Customer success operates on similar principles.

1906
01:04:32,760 --> 01:04:34,360
An agent monitors adoption.

1907
01:04:34,360 --> 01:04:36,360
Is the customer using the product they bought?

1908
01:04:36,360 --> 01:04:37,880
Are they using it the way they should?

1909
01:04:37,880 --> 01:04:39,640
An agent detects churn signals.

1910
01:04:39,640 --> 01:04:41,960
Usage dropping, feature adoption stalling,

1911
01:04:41,960 --> 01:04:43,400
support tickets increasing.

1912
01:04:43,400 --> 01:04:44,600
These are early warning signs.

1913
01:04:44,600 --> 01:04:47,320
The agent alerts the success team before the customer leaves.

1914
01:04:47,320 --> 01:04:49,880
Renewal management uses the same multi-agent pattern.

1915
01:04:49,880 --> 01:04:52,040
An agent tracks contract renewal dates.

1916
01:04:52,040 --> 01:04:53,320
It monitors customer health.

1917
01:04:53,320 --> 01:04:55,400
It identifies expansion opportunities.

1918
01:04:55,400 --> 01:04:57,240
A customer bought three licenses,

1919
01:04:57,240 --> 01:04:59,320
but usage data shows they need five.

1920
01:04:59,320 --> 01:05:00,840
The agent recommends expansion.

1921
01:05:00,840 --> 01:05:02,280
It prepares the business case.

1922
01:05:02,280 --> 01:05:05,480
It schedules the renewal conversation at the optimal time.

1923
01:05:05,480 --> 01:05:07,320
Service now built exactly this system.

1924
01:05:07,320 --> 01:05:09,800
Multiple agents coordinating across CRM,

1925
01:05:09,800 --> 01:05:12,200
communication history and product usage data.

1926
01:05:12,200 --> 01:05:14,920
The metrics they track are directly tied to revenue,

1927
01:05:14,920 --> 01:05:17,880
pipeline velocity, deal size, customer retention.

1928
01:05:17,880 --> 01:05:20,760
This pattern is expanding because every function

1929
01:05:20,760 --> 01:05:22,440
is discovering the same truth.

1930
01:05:22,440 --> 01:05:25,320
Complex workflows benefit from coordinated specialist agents.

1931
01:05:25,320 --> 01:05:28,280
Measuring agent success, the scorecard.

1932
01:05:28,280 --> 01:05:30,840
Here is what separates organizations that scale agents

1933
01:05:30,840 --> 01:05:32,360
from organizations that get stuck.

1934
01:05:32,360 --> 01:05:33,880
They measure the wrong things.

1935
01:05:33,880 --> 01:05:35,640
The instinct is to measure accuracy.

1936
01:05:35,640 --> 01:05:37,160
Did the agent get the right answer?

1937
01:05:37,160 --> 01:05:39,000
For a system that generates text,

1938
01:05:39,000 --> 01:05:40,840
accuracy feels like the natural metric.

1939
01:05:40,840 --> 01:05:42,360
But agents do not generate text.

1940
01:05:42,360 --> 01:05:43,640
They accomplish tasks.

1941
01:05:43,640 --> 01:05:45,160
They are not writing essays.

1942
01:05:45,160 --> 01:05:47,240
They are qualifying leads, scheduling meetings,

1943
01:05:47,240 --> 01:05:49,720
resolving support tickets and managing hiring workflows.

1944
01:05:49,720 --> 01:05:53,400
The right metric for those tasks is not how correct the output was,

1945
01:05:53,400 --> 01:05:55,720
but whether the task completed successfully.

1946
01:05:55,720 --> 01:05:57,720
Accuracy is almost irrelevant.

1947
01:05:57,720 --> 01:05:59,560
A sourcing agent could perfectly describe

1948
01:05:59,560 --> 01:06:01,800
why a candidate matches your job requirements.

1949
01:06:01,800 --> 01:06:02,760
Perfect accuracy.

1950
01:06:02,760 --> 01:06:05,320
But if the candidate turns out to be a bad fit for your team,

1951
01:06:05,320 --> 01:06:06,200
the agent failed.

1952
01:06:06,200 --> 01:06:07,480
You need a different metric.

1953
01:06:07,480 --> 01:06:10,200
Did the qualified candidate actually succeed in the role?

1954
01:06:10,200 --> 01:06:11,240
That is success.

1955
01:06:11,240 --> 01:06:12,600
That is what matters to the business.

1956
01:06:12,600 --> 01:06:14,520
This is why the multi-level scorecard exists.

1957
01:06:14,520 --> 01:06:16,280
You need measurements at three levels.

1958
01:06:16,280 --> 01:06:17,640
And they are not interchangeable.

1959
01:06:17,640 --> 01:06:20,920
Agent-level metrics tell you if an individual agent is doing its job.

1960
01:06:20,920 --> 01:06:25,000
A sourcing agent's task success rate is the percentage of candidates

1961
01:06:25,000 --> 01:06:26,760
who make it to the interview stage.

1962
01:06:26,760 --> 01:06:30,520
A scheduling agent's task success rate is the percentage of meetings

1963
01:06:30,520 --> 01:06:32,200
that actually happen without rescheduling.

1964
01:06:32,200 --> 01:06:33,240
These are narrow metrics.

1965
01:06:33,240 --> 01:06:35,400
They measure one agent's specific function.

1966
01:06:35,400 --> 01:06:37,880
But they are the first place to look when something breaks.

1967
01:06:37,880 --> 01:06:39,960
Workflow-level metrics tell you if the coordinated

1968
01:06:39,960 --> 01:06:41,000
system is working.

1969
01:06:41,000 --> 01:06:44,360
The hiring workflows metrics are different from individual agent metrics.

1970
01:06:44,360 --> 01:06:45,560
Time to hire matters.

1971
01:06:45,560 --> 01:06:47,240
How long from requisition to offer?

1972
01:06:47,240 --> 01:06:48,760
Offer acceptance rate matters.

1973
01:06:48,760 --> 01:06:50,440
Of candidates who receive offers.

1974
01:06:50,440 --> 01:06:51,800
What percentage accept?

1975
01:06:51,800 --> 01:06:53,000
Quality metrics matter?

1976
01:06:53,000 --> 01:06:54,120
Of hired candidates?

1977
01:06:54,120 --> 01:06:56,360
What percentage are still in the role after one year?

1978
01:06:56,360 --> 01:06:58,840
These are the metrics that tell you if the multi-agent orchestration

1979
01:06:58,840 --> 01:07:00,680
is actually improving hiring outcomes.

1980
01:07:00,680 --> 01:07:03,400
Business-level KPIs tell you if the agents are moving the needle

1981
01:07:03,400 --> 01:07:04,280
on what actually matters.

1982
01:07:04,280 --> 01:07:06,120
Revenue impact.

1983
01:07:06,120 --> 01:07:07,320
Cost savings.

1984
01:07:07,320 --> 01:07:08,840
Customer satisfaction.

1985
01:07:08,840 --> 01:07:10,120
Market speed.

1986
01:07:10,120 --> 01:07:12,200
These are the metrics that executives care about.

1987
01:07:12,200 --> 01:07:14,840
If you deploy agents and your hiring metrics look great

1988
01:07:14,840 --> 01:07:17,640
but you are not improving time to market or product quality,

1989
01:07:17,640 --> 01:07:19,000
then the agents are cosmetic.

1990
01:07:19,000 --> 01:07:21,960
Business metrics are what justify continued investment.

1991
01:07:21,960 --> 01:07:25,160
The practical scorecard for a hiring workflow looks like this.

1992
01:07:25,160 --> 01:07:26,120
Agent-level.

1993
01:07:26,120 --> 01:07:28,360
Sourcing agents candidate quality score.

1994
01:07:28,360 --> 01:07:29,880
Screening agents accuracy.

1995
01:07:29,880 --> 01:07:31,880
Scheduling agents on time performance.

1996
01:07:31,880 --> 01:07:32,840
Workflow-level.

1997
01:07:32,840 --> 01:07:33,880
Time to hire.

1998
01:07:33,880 --> 01:07:35,160
Offer acceptance rate.

1999
01:07:35,160 --> 01:07:36,440
New hire retention.

2000
01:07:36,440 --> 01:07:37,320
Business-level.

2001
01:07:37,320 --> 01:07:39,240
Organizational hiring velocity.

2002
01:07:39,240 --> 01:07:40,440
Product launch speed.

2003
01:07:40,440 --> 01:07:41,560
Revenue growth.

2004
01:07:41,560 --> 01:07:44,040
When you are evaluating whether agents are working,

2005
01:07:44,040 --> 01:07:45,240
you read them altogether.

2006
01:07:45,240 --> 01:07:48,600
If agent-level metrics look good but workflow metrics are stagnant.

2007
01:07:48,600 --> 01:07:49,800
The problem is orchestration.

2008
01:07:49,800 --> 01:07:52,440
The agents work individually but do not coordinate.

2009
01:07:52,440 --> 01:07:55,560
If workflow metrics look good but business metrics do not move.

2010
01:07:55,560 --> 01:07:56,760
The problem is scope.

2011
01:07:56,760 --> 01:07:58,520
You are automating the wrong process.

2012
01:07:58,520 --> 01:08:00,760
It is not slowing down anything that matters.

2013
01:08:00,760 --> 01:08:03,080
You need to measure both efficiency and safety.

2014
01:08:03,080 --> 01:08:05,320
This is where organizations make a critical mistake.

2015
01:08:05,320 --> 01:08:06,920
They optimize purely for speed.

2016
01:08:06,920 --> 01:08:08,680
Agents that complete tasks fast.

2017
01:08:08,680 --> 01:08:10,280
Agents that escalate rarely.

2018
01:08:10,280 --> 01:08:11,960
Agents that move workflows forward.

2019
01:08:11,960 --> 01:08:14,120
But if those fast agents are hallucinating,

2020
01:08:14,120 --> 01:08:17,400
violating policy or taking shortcuts that create downstream problems,

2021
01:08:17,400 --> 01:08:19,160
then you have not optimized anything.

2022
01:08:19,160 --> 01:08:21,400
You have just shifted the cost somewhere else.

2023
01:08:21,400 --> 01:08:23,000
A sourcing agent that qualifies quickly

2024
01:08:23,000 --> 01:08:24,920
but misses red flags creates bad hires.

2025
01:08:24,920 --> 01:08:25,960
That is not saving time.

2026
01:08:25,960 --> 01:08:27,720
That is creating cost later.

2027
01:08:27,720 --> 01:08:29,000
The metrics that matter.

2028
01:08:29,000 --> 01:08:30,200
Task success rate.

2029
01:08:30,200 --> 01:08:32,040
Did the agent complete the task correctly?

2030
01:08:32,040 --> 01:08:32,920
Containment rate.

2031
01:08:32,920 --> 01:08:35,480
What percentage of issues resolved without escalation?

2032
01:08:35,480 --> 01:08:36,600
Cost per interaction.

2033
01:08:36,600 --> 01:08:38,920
How much did this workflow cost to complete?

2034
01:08:38,920 --> 01:08:39,800
Hallucination rate.

2035
01:08:39,800 --> 01:08:41,800
How often did the agent make up information?

2036
01:08:41,800 --> 01:08:42,920
Policy adherence rate?

2037
01:08:42,920 --> 01:08:44,200
Did the agent follow rules?

2038
01:08:44,200 --> 01:08:45,400
Escalation frequency.

2039
01:08:45,400 --> 01:08:47,080
How often did it hand off to humans?

2040
01:08:47,080 --> 01:08:48,040
Real example.

2041
01:08:48,040 --> 01:08:50,200
An organization tracking all these metrics found

2042
01:08:50,200 --> 01:08:52,520
that their support agents had high containment.

2043
01:08:52,520 --> 01:08:54,440
They resolved issues without escalation.

2044
01:08:54,440 --> 01:08:56,520
But their hallucination rate was 12%.

2045
01:08:56,520 --> 01:08:58,600
They were confidently giving wrong answers.

2046
01:08:58,600 --> 01:09:00,200
They were escalating the right issues

2047
01:09:00,200 --> 01:09:02,440
but they were confidently misresolving others.

2048
01:09:02,440 --> 01:09:04,760
Once they saw that metric, they understood the problem.

2049
01:09:04,760 --> 01:09:07,720
They were not measuring whether the issue was actually solved.

2050
01:09:07,720 --> 01:09:10,040
They were measuring whether the agent answered

2051
01:09:10,040 --> 01:09:11,320
instead of escalating.

2052
01:09:11,320 --> 01:09:12,760
Once they fixed the measurement,

2053
01:09:12,760 --> 01:09:14,120
they fixed the real problem.

2054
01:09:14,120 --> 01:09:15,960
The metrics themselves become the governor.

2055
01:09:15,960 --> 01:09:17,880
They force you to measure what actually matters.

2056
01:09:17,880 --> 01:09:19,560
Metrics tell you if something is working

2057
01:09:19,560 --> 01:09:21,080
but they also tell you what to fix.

2058
01:09:21,080 --> 01:09:23,720
The governance crisis.

2059
01:09:23,720 --> 01:09:27,000
Why 74% of deployments lack mature controls.

2060
01:09:27,000 --> 01:09:28,920
The numbers tell a story that should terrify

2061
01:09:28,920 --> 01:09:32,120
any architect responsible for enterprise infrastructure.

2062
01:09:32,120 --> 01:09:35,720
74% of organizations are running AI agents in production.

2063
01:09:35,720 --> 01:09:39,080
But only 21% have governance that actually works.

2064
01:09:39,080 --> 01:09:40,440
That gap is not a coincidence.

2065
01:09:40,440 --> 01:09:42,440
It's the inevitable result of moving faster

2066
01:09:42,440 --> 01:09:44,360
than your organizational structures can handle.

2067
01:09:44,360 --> 01:09:47,800
Because in reality, most companies are building without breaks.

2068
01:09:47,800 --> 01:09:48,840
You build an agent.

2069
01:09:48,840 --> 01:09:49,560
It works.

2070
01:09:49,560 --> 01:09:50,680
It solves a problem.

2071
01:09:50,680 --> 01:09:52,840
You deploy it and then other teams see it working

2072
01:09:52,840 --> 01:09:53,960
and want agents to.

2073
01:09:53,960 --> 01:09:55,480
You build more and you deploy more

2074
01:09:55,480 --> 01:09:56,840
but nobody is stopping to ask

2075
01:09:56,840 --> 01:09:58,680
if the infrastructure is actually ready.

2076
01:09:58,680 --> 01:10:00,840
Nobody is checking if the policies you wrote last month

2077
01:10:00,840 --> 01:10:03,160
still apply to the agents you're shipping this month.

2078
01:10:03,160 --> 01:10:06,840
The adoption governance gap is the defining challenge of 2026.

2079
01:10:06,840 --> 01:10:07,960
Agents are everywhere.

2080
01:10:07,960 --> 01:10:09,480
Governance is nowhere.

2081
01:10:09,480 --> 01:10:11,720
And in that gap, problems multiply.

2082
01:10:11,720 --> 01:10:14,200
The no-users can access agent policy floor

2083
01:10:14,200 --> 01:10:16,280
is a perfect case study of what happens

2084
01:10:16,280 --> 01:10:17,880
when governance lags behind.

2085
01:10:17,880 --> 01:10:19,800
An organization tried to be cautious

2086
01:10:19,800 --> 01:10:22,840
and set a policy where no regular users could access agents.

2087
01:10:22,840 --> 01:10:25,240
They wanted only approved people in approved roles

2088
01:10:25,240 --> 01:10:26,920
to have access so the policy was written

2089
01:10:26,920 --> 01:10:28,280
and the setting was configured.

2090
01:10:28,280 --> 01:10:30,440
But the setting didn't actually block the agents.

2091
01:10:30,440 --> 01:10:32,760
There was a gap between what the policy intended

2092
01:10:32,760 --> 01:10:34,600
and what the system actually enforced.

2093
01:10:34,600 --> 01:10:36,520
Some agents still showed up in user catalogs

2094
01:10:36,520 --> 01:10:38,120
and others could still be invoked by people

2095
01:10:38,120 --> 01:10:39,160
who shouldn't have seen them.

2096
01:10:39,160 --> 01:10:41,320
The control failed because nobody validated

2097
01:10:41,320 --> 01:10:43,400
that the policy did what it was supposed to do.

2098
01:10:43,400 --> 01:10:44,600
That's where things change.

2099
01:10:44,600 --> 01:10:45,640
And usually for the worse.

2100
01:10:45,640 --> 01:10:46,840
When the policy didn't work,

2101
01:10:46,840 --> 01:10:48,680
someone started doing manual power shell

2102
01:10:48,680 --> 01:10:50,280
overrides in the middle of the night.

2103
01:10:50,280 --> 01:10:52,760
They manually disabled agents one by one

2104
01:10:52,760 --> 01:10:54,440
with scripts that weren't documented

2105
01:10:54,440 --> 01:10:55,960
or explained to the rest of the team.

2106
01:10:55,960 --> 01:10:57,000
That approach doesn't scale.

2107
01:10:57,000 --> 01:10:58,120
It isn't auditable

2108
01:10:58,120 --> 01:10:59,880
and it definitely isn't repeatable.

2109
01:10:59,880 --> 01:11:01,400
But in the absence of real governance,

2110
01:11:01,400 --> 01:11:03,160
it's what organizations fall back on.

2111
01:11:03,160 --> 01:11:04,680
Then you have the shadow AI problem.

2112
01:11:04,680 --> 01:11:06,600
This is the dark side of the governance gap

2113
01:11:06,600 --> 01:11:08,360
where agents are running in your infrastructure

2114
01:11:08,360 --> 01:11:10,280
that your team doesn't even know about.

2115
01:11:10,280 --> 01:11:12,920
A developer builds an agent locally, containerizes it

2116
01:11:12,920 --> 01:11:14,920
and runs it in a zooer without telling a soul.

2117
01:11:14,920 --> 01:11:16,440
It's pulling from SharePoint,

2118
01:11:16,440 --> 01:11:17,720
querying your databases,

2119
01:11:17,720 --> 01:11:20,360
and sending emails while nobody has classified its risk

2120
01:11:20,360 --> 01:11:21,640
or set up monitoring.

2121
01:11:21,640 --> 01:11:23,880
It stays invisible until something goes wrong

2122
01:11:23,880 --> 01:11:25,720
and then there is the permission explosion.

2123
01:11:25,720 --> 01:11:27,640
This happens because there's no systematic way

2124
01:11:27,640 --> 01:11:29,800
to enforce least privilege when you're moving this fast.

2125
01:11:29,800 --> 01:11:32,760
You give an agent access to the systems it needs today,

2126
01:11:32,760 --> 01:11:35,560
but you also give it access to things it might need next year.

2127
01:11:35,560 --> 01:11:37,160
You give it broader access than necessary

2128
01:11:37,160 --> 01:11:40,120
because being too restrictive slows down the deployment schedule.

2129
01:11:40,120 --> 01:11:43,160
Over time, agents accumulate permissions like digital debt.

2130
01:11:43,160 --> 01:11:45,080
Each new agent starts with broad access

2131
01:11:45,080 --> 01:11:47,800
because nobody has time to calculate exactly what's necessary.

2132
01:11:47,800 --> 01:11:50,280
The system becomes progressively over-pimissioned.

2133
01:11:50,280 --> 01:11:53,400
The audit blind spot is where governance completely breaks down.

2134
01:11:53,400 --> 01:11:55,880
An agent executes an action and something goes wrong

2135
01:11:55,880 --> 01:11:58,920
so someone asks what the agent actually did.

2136
01:11:58,920 --> 01:12:02,280
The logs might show a file was accessed or a record was modified

2137
01:12:02,280 --> 01:12:03,960
but the logs don't show why.

2138
01:12:03,960 --> 01:12:05,960
They don't show what data the agent evaluated

2139
01:12:05,960 --> 01:12:08,040
or what reasoning led to that specific decision.

2140
01:12:08,040 --> 01:12:09,720
They don't show which human approved it

2141
01:12:09,720 --> 01:12:11,560
or if approval was even required.

2142
01:12:11,560 --> 01:12:13,320
The organization has activity logs,

2143
01:12:13,320 --> 01:12:14,760
but they don't have intelligence.

2144
01:12:14,760 --> 01:12:19,080
This matters because 97% of AI breaches stem from insufficient access controls.

2145
01:12:19,080 --> 01:12:21,960
It's not about sophisticated attacks or compromised models.

2146
01:12:21,960 --> 01:12:24,280
It's about agents that had access they shouldn't have had.

2147
01:12:24,280 --> 01:12:26,680
It's about agents taking actions without oversight

2148
01:12:26,680 --> 01:12:29,000
and leaking data because the boundaries were never defined.

2149
01:12:29,000 --> 01:12:31,960
The governance crisis is what enables the security crisis.

2150
01:12:31,960 --> 01:12:33,960
The path forward is straightforward and principled

2151
01:12:33,960 --> 01:12:35,480
but difficult in execution.

2152
01:12:35,480 --> 01:12:38,920
You have to move from ad hoc controls to programmatic governance.

2153
01:12:38,920 --> 01:12:40,680
Stop relying on manual processes

2154
01:12:40,680 --> 01:12:43,880
and stop assuming policies work when you haven't actually tested them.

2155
01:12:43,880 --> 01:12:45,720
Stop letting agents run invisibly.

2156
01:12:45,720 --> 01:12:48,360
You need to build the infrastructure that allows governance at scale.

2157
01:12:48,360 --> 01:12:51,880
That's what agent 365 and the governance framework are designed to provide

2158
01:12:51,880 --> 01:12:53,880
but they only work if you actually use them.

2159
01:12:54,200 --> 01:12:55,640
Building the governance program.

2160
01:12:55,640 --> 01:12:56,680
Practical steps.

2161
01:12:56,680 --> 01:12:59,240
The transition from crisis to control happens in phases.

2162
01:12:59,240 --> 01:13:00,520
You can't fix everything at once.

2163
01:13:00,520 --> 01:13:03,800
If you try to lock down every agent in every process overnight,

2164
01:13:03,800 --> 01:13:05,560
you'll just paralyze the organization.

2165
01:13:05,560 --> 01:13:08,760
You'll make agents look like they slow things down instead of speeding them up.

2166
01:13:08,760 --> 01:13:10,760
The winning approach is methodical but fast.

2167
01:13:10,760 --> 01:13:13,080
Step one is inventory.

2168
01:13:13,080 --> 01:13:15,960
You need to know what agents actually exist in your environment.

2169
01:13:15,960 --> 01:13:18,600
Use agent 365 to scan your infrastructure

2170
01:13:18,600 --> 01:13:21,560
and run discovery across Entra, Defender and Intune.

2171
01:13:21,560 --> 01:13:25,880
Document everything from the agents you built on purpose to the shadow agents running in dark corners.

2172
01:13:25,880 --> 01:13:29,320
Create a spreadsheet with the agent name, the owner, the purpose,

2173
01:13:29,320 --> 01:13:31,080
and exactly what data it touches.

2174
01:13:31,080 --> 01:13:32,600
This inventory is your starting point.

2175
01:13:32,600 --> 01:13:34,440
You can't govern what you can't see.

2176
01:13:34,440 --> 01:13:36,200
Step two is classification.

2177
01:13:36,200 --> 01:13:37,720
Not all agents are equally risky.

2178
01:13:37,720 --> 01:13:39,080
So you have to treat them differently.

2179
01:13:39,080 --> 01:13:42,920
A productivity agent that just reads and summarizes documents is low risk.

2180
01:13:42,920 --> 01:13:46,120
A payment agent that moves actual money is high risk.

2181
01:13:46,120 --> 01:13:49,560
A hiring agent that evaluates candidates sits somewhere in the middle.

2182
01:13:49,560 --> 01:13:53,000
Classify every agent on your list as low, medium or high.

2183
01:13:53,000 --> 01:13:55,480
This classification determines how strictly you govern it

2184
01:13:55,480 --> 01:13:57,480
and whether it needs human approval loops.

2185
01:13:57,480 --> 01:14:00,040
A low risk agent can move through the system faster

2186
01:14:00,040 --> 01:14:02,280
but a high risk agent needs a full review.

2187
01:14:02,280 --> 01:14:04,200
Step three is ownership.

2188
01:14:04,200 --> 01:14:07,880
Go through that inventory and assign an actual person to every single agent.

2189
01:14:07,880 --> 01:14:11,720
Not a team or a department, but a named individual who is accountable.

2190
01:14:11,720 --> 01:14:15,240
That person is responsible for making sure the agent operates correctly

2191
01:14:15,240 --> 01:14:17,240
and responding if there's a security issue.

2192
01:14:17,240 --> 01:14:19,000
Ownership forces accountability.

2193
01:14:19,000 --> 01:14:20,280
And it forces a hard truth.

2194
01:14:20,280 --> 01:14:23,480
If nobody is willing to own an agent, it probably shouldn't exist.

2195
01:14:23,480 --> 01:14:25,320
Step four is approval workflows.

2196
01:14:25,320 --> 01:14:28,520
You need to define the path from development to production

2197
01:14:28,520 --> 01:14:31,480
for a low risk agent, maybe the business owner signs off

2198
01:14:31,480 --> 01:14:32,920
and engineering validates it.

2199
01:14:32,920 --> 01:14:36,440
For a high risk agent, you need business, security, compliance,

2200
01:14:36,440 --> 01:14:38,200
and operations all to sign off.

2201
01:14:38,200 --> 01:14:40,760
Define the criteria and decide who has veto power.

2202
01:14:40,760 --> 01:14:44,600
The workflow is the guardrail that prevents bad agents from reaching production.

2203
01:14:44,600 --> 01:14:47,000
Step five is identity and access controls.

2204
01:14:47,000 --> 01:14:49,880
Every agent gets a dedicated, intro workload identity.

2205
01:14:49,880 --> 01:14:52,920
No sharing human accounts and no standing API keys.

2206
01:14:52,920 --> 01:14:55,160
The agent's identity should have specific roles

2207
01:14:55,160 --> 01:14:57,400
and only the permissions it needs to function.

2208
01:14:57,400 --> 01:15:00,040
Configure conditional access and extend the same policies

2209
01:15:00,040 --> 01:15:01,960
that protect human accounts to your agents.

2210
01:15:01,960 --> 01:15:03,880
If an agent's behavior becomes strange,

2211
01:15:03,880 --> 01:15:06,920
the system should flag it the same way it would for a human.

2212
01:15:06,920 --> 01:15:08,920
Step six is audit logging and monitoring.

2213
01:15:08,920 --> 01:15:12,520
Turn on Pervue Audit and capture every tool call and every data access.

2214
01:15:12,520 --> 01:15:15,240
But don't just collect logs, make them intelligent.

2215
01:15:15,240 --> 01:15:19,160
Build dashboards that show anomalies and flag patterns that look suspicious.

2216
01:15:19,160 --> 01:15:22,920
An agent accessing files from three different departments in one hour is unusual.

2217
01:15:22,920 --> 01:15:25,880
An agent exporting large volumes of data is a red flag.

2218
01:15:25,880 --> 01:15:28,840
The logs are only useful if you can actually reason over them.

2219
01:15:28,840 --> 01:15:30,120
Step seven is escalation.

2220
01:15:30,120 --> 01:15:32,120
Define what happens when something goes wrong.

2221
01:15:32,120 --> 01:15:35,480
When an agent violates a policy or its behavior changes unexpectedly

2222
01:15:35,480 --> 01:15:36,920
who gets the notification?

2223
01:15:36,920 --> 01:15:40,040
Who has the power to shut the agent down immediately?

2224
01:15:40,040 --> 01:15:41,960
Escalation procedures prevent small problems

2225
01:15:41,960 --> 01:15:44,120
from becoming full-blown security incidents.

2226
01:15:44,120 --> 01:15:47,800
Faced rollout matters because you need to prove the model works before you scale it.

2227
01:15:47,800 --> 01:15:50,680
Start with low-risk agents where the blast radius is small

2228
01:15:50,680 --> 01:15:52,840
and failure is easy to recover from.

2229
01:15:52,840 --> 01:15:54,280
Run them through your governance process

2230
01:15:54,280 --> 01:15:57,160
and see if your oversight structure actually catches real problems.

2231
01:15:57,160 --> 01:15:59,880
Only after you've proven the model on low-risk deployments

2232
01:15:59,880 --> 01:16:01,960
should you expand to high-risk ones.

2233
01:16:01,960 --> 01:16:06,600
KPMG governs 276,000 agents using exactly this framework.

2234
01:16:06,600 --> 01:16:08,760
They didn't deploy governance as an afterthought.

2235
01:16:08,760 --> 01:16:11,000
They built the framework first, proved it worked,

2236
01:16:11,000 --> 01:16:12,440
and then expanded systematically.

2237
01:16:12,440 --> 01:16:14,840
That's how you operate at scale without the chaos.

2238
01:16:14,840 --> 01:16:16,120
The future.

2239
01:16:16,120 --> 01:16:17,320
Where this is heading?

2240
01:16:17,320 --> 01:16:18,920
We are at an inflection point.

2241
01:16:18,920 --> 01:16:22,680
The shift happening right now is not about moving from chatbots to better chatbots.

2242
01:16:22,680 --> 01:16:24,600
It is a shift from agents as tools.

2243
01:16:24,600 --> 01:16:27,960
To agents as workers, a tool is something you invoke when you need it.

2244
01:16:27,960 --> 01:16:29,640
You open it, you tell it what to do,

2245
01:16:29,640 --> 01:16:31,080
and you close it when you are done.

2246
01:16:31,080 --> 01:16:32,920
But an agent as a worker is different.

2247
01:16:32,920 --> 01:16:34,760
It operates within boundaries you set.

2248
01:16:34,760 --> 01:16:37,080
It monitors, it detects, it acts.

2249
01:16:37,080 --> 01:16:40,280
You check on it periodically, you set new objectives when needed.

2250
01:16:40,280 --> 01:16:43,960
But it is not waiting for you to pull a lever every time something needs doing.

2251
01:16:43,960 --> 01:16:46,680
This shift forces everything to scale differently.

2252
01:16:46,680 --> 01:16:49,560
You cannot govern 5,000 tools the way you govern 10.

2253
01:16:49,560 --> 01:16:52,280
But you can govern 5,000 autonomous workers.

2254
01:16:52,280 --> 01:16:53,800
If you have the right infrastructure,

2255
01:16:53,800 --> 01:16:57,000
that infrastructure is what we have been building through these sections.

2256
01:16:57,000 --> 01:16:59,800
Graph as the data layer, MCP as the integration standard.

2257
01:16:59,800 --> 01:17:01,640
Languaf as the orchestration framework,

2258
01:17:01,640 --> 01:17:03,880
agent 365 as the governance cockpit.

2259
01:17:03,880 --> 01:17:07,480
Entra and purview as the identity and compliance backbone.

2260
01:17:07,480 --> 01:17:09,160
Graph will remain the central nervous system

2261
01:17:09,160 --> 01:17:11,800
because it is the only system that actually knows your organization.

2262
01:17:11,800 --> 01:17:14,360
It contains two decades of communication patterns,

2263
01:17:14,360 --> 01:17:16,040
relationships and decisions.

2264
01:17:16,040 --> 01:17:17,880
It knows how work actually flows.

2265
01:17:17,880 --> 01:17:21,400
When AI agents operate at scale, they are not operating in a vacuum.

2266
01:17:21,400 --> 01:17:24,280
They are operating inside the live organism of your organization.

2267
01:17:24,280 --> 01:17:26,360
They need real-time access to that context.

2268
01:17:26,360 --> 01:17:27,480
Graph provides it.

2269
01:17:27,480 --> 01:17:33,160
The convergence of MCP, Languaf, and agent 365

2270
01:17:33,160 --> 01:17:35,960
is creating the operating system for agentic workflows.

2271
01:17:35,960 --> 01:17:38,760
MCP standardizes how agents talk to external systems.

2272
01:17:39,160 --> 01:17:41,240
One protocol, many tools.

2273
01:17:41,240 --> 01:17:43,240
Languaf provides the orchestration framework

2274
01:17:43,240 --> 01:17:45,480
that lets agents coordinate with each other.

2275
01:17:45,480 --> 01:17:48,040
Supervisor patterns, multi-step workflows,

2276
01:17:48,040 --> 01:17:49,560
stateful interactions.

2277
01:17:49,560 --> 01:17:52,520
Agent 365 ties it together with governance,

2278
01:17:52,520 --> 01:17:55,560
central identity, central policy, central audit.

2279
01:17:55,560 --> 01:17:59,080
What agentic workflows actually means

2280
01:17:59,080 --> 01:18:01,640
is orchestrated auditable-governed automation,

2281
01:18:01,640 --> 01:18:03,160
not lose agents doing their own thing,

2282
01:18:03,160 --> 01:18:06,200
but coordinated agents operating within clear boundaries,

2283
01:18:06,200 --> 01:18:08,520
leaving trails, escalating when necessary,

2284
01:18:08,520 --> 01:18:10,680
fitting into the broader organizational system.

2285
01:18:10,680 --> 01:18:13,080
An agentic workflow is not an experiment.

2286
01:18:13,080 --> 01:18:14,600
It is core infrastructure.

2287
01:18:14,600 --> 01:18:16,360
It is how the organization operates.

2288
01:18:16,360 --> 01:18:19,880
But there is a skill gap that most organizations have not reckoned with yet.

2289
01:18:19,880 --> 01:18:23,000
Building graph-powered agents requires you to understand both AI

2290
01:18:23,000 --> 01:18:24,120
and enterprise systems.

2291
01:18:24,120 --> 01:18:27,000
You need architects who know Languaf and orchestration patterns.

2292
01:18:27,000 --> 01:18:30,120
But also understand active directory exchange and sharepoint governance.

2293
01:18:30,120 --> 01:18:32,280
You need engineers who can write prompt instructions.

2294
01:18:32,280 --> 01:18:35,640
But also understand data classification and retention policies.

2295
01:18:35,640 --> 01:18:38,200
You need security teams that understand both LLM risks

2296
01:18:38,200 --> 01:18:39,720
and traditional enterprise security.

2297
01:18:39,720 --> 01:18:40,920
Those people are rare.

2298
01:18:40,920 --> 01:18:42,600
Organizations are going to fight over them.

2299
01:18:42,600 --> 01:18:45,000
Why this matters to your organization is simple.

2300
01:18:45,000 --> 01:18:46,760
Agents are not a technology choice anymore.

2301
01:18:46,760 --> 01:18:48,120
They are a structural choice.

2302
01:18:48,120 --> 01:18:50,360
You are deciding whether your organization operates

2303
01:18:50,360 --> 01:18:53,240
with manual processes where humans are the bottleneck.

2304
01:18:53,240 --> 01:18:55,240
Or whether you operate with autonomous workers

2305
01:18:55,240 --> 01:18:56,680
handling routine decisions.

2306
01:18:56,680 --> 01:18:57,880
That is not a tool decision.

2307
01:18:57,880 --> 01:18:59,400
It is an architectural decision.

2308
01:18:59,400 --> 01:19:01,080
It affects how you organize teams,

2309
01:19:01,080 --> 01:19:03,880
how you measure performance, how you allocate resources.

2310
01:19:03,880 --> 01:19:06,840
The decision point is whether you are building isolated agents

2311
01:19:06,840 --> 01:19:08,840
or building an agentic enterprise.

2312
01:19:08,840 --> 01:19:10,360
Isolated agents are experiments.

2313
01:19:10,360 --> 01:19:11,160
You build one.

2314
01:19:11,160 --> 01:19:11,880
It works.

2315
01:19:11,880 --> 01:19:12,600
You add another.

2316
01:19:12,600 --> 01:19:13,640
They do not coordinate.

2317
01:19:13,640 --> 01:19:14,760
They duplicate effort.

2318
01:19:14,760 --> 01:19:16,840
Each one is a custom integration problem.

2319
01:19:16,840 --> 01:19:18,440
An agentic enterprise is different.

2320
01:19:18,440 --> 01:19:19,560
Agents are coordinated.

2321
01:19:19,560 --> 01:19:21,720
They operate within a unified governance framework.

2322
01:19:21,720 --> 01:19:23,000
They use standard protocols.

2323
01:19:23,000 --> 01:19:24,520
They share infrastructure.

2324
01:19:24,520 --> 01:19:26,280
What to do next is not complicated.

2325
01:19:26,280 --> 01:19:27,800
But it requires commitment.

2326
01:19:27,800 --> 01:19:29,560
Start with one high value workflow.

2327
01:19:29,560 --> 01:19:33,320
HR hiring, IT ticket triage, sales lead qualification.

2328
01:19:33,320 --> 01:19:35,960
Pick something where you can measure impact immediately.

2329
01:19:35,960 --> 01:19:36,920
Build the agents.

2330
01:19:36,920 --> 01:19:38,120
Measure the outcomes.

2331
01:19:38,120 --> 01:19:39,240
Did time decrease?

2332
01:19:39,240 --> 01:19:40,280
Did quality improve?

2333
01:19:40,280 --> 01:19:41,400
Did costs go down?

2334
01:19:41,400 --> 01:19:43,640
Once you have proven the pattern on one workflow

2335
01:19:43,640 --> 01:19:45,160
expands systematically.

2336
01:19:45,160 --> 01:19:47,400
Two workflows, then four, then eight.

2337
01:19:47,400 --> 01:19:48,680
Each expansion gets faster

2338
01:19:48,680 --> 01:19:51,000
because you are not rebuilding the governance infrastructure

2339
01:19:51,000 --> 01:19:51,800
each time.

2340
01:19:51,800 --> 01:19:54,040
You are using the framework you already built.

2341
01:19:54,040 --> 01:19:56,920
The core insight that ties everything together is this.

2342
01:19:56,920 --> 01:19:59,080
Graph-powered agents are not about AI.

2343
01:19:59,080 --> 01:20:00,680
They are about enterprise architecture.

2344
01:20:00,680 --> 01:20:04,200
The difference between agents that transform your organization

2345
01:20:04,200 --> 01:20:07,400
and agents that become expensive experiments is whether they

2346
01:20:07,400 --> 01:20:09,400
are built on solid structural foundations.

2347
01:20:09,400 --> 01:20:10,680
Graph provides data.

2348
01:20:10,680 --> 01:20:12,280
MCP provides integration.

2349
01:20:12,280 --> 01:20:14,200
Langgraph provides orchestration.

2350
01:20:14,200 --> 01:20:16,280
Agent 365 provides governance.

2351
01:20:16,280 --> 01:20:19,720
Together they are the stack that lets agents operate at scale.

2352
01:20:19,720 --> 01:20:22,760
Moving beyond chat matters because agents that can only talk

2353
01:20:22,760 --> 01:20:23,560
are not agents.

2354
01:20:23,560 --> 01:20:26,200
They are chatbots with good conversational skills.

2355
01:20:26,200 --> 01:20:27,960
Real agents understand context.

2356
01:20:27,960 --> 01:20:29,400
They act with authority.

2357
01:20:29,400 --> 01:20:31,240
They operate within governance boundaries.

2358
01:20:31,240 --> 01:20:32,680
They change how work happens.

2359
01:20:32,680 --> 01:20:34,040
Not how people talk about work.

2360
01:20:34,040 --> 01:20:35,960
If you are responsible for enterprise architecture,

2361
01:20:35,960 --> 01:20:37,640
you need to understand this now.

2362
01:20:37,640 --> 01:20:38,520
Not next year.

2363
01:20:38,520 --> 01:20:40,440
Not when vendors tell you it is ready.

2364
01:20:40,440 --> 01:20:43,720
Now, the organizations that move first will embed agents

2365
01:20:43,720 --> 01:20:46,520
into their operations before governance becomes the constraint.

2366
01:20:46,520 --> 01:20:48,920
The organizations that wait will spend two years trying

2367
01:20:48,920 --> 01:20:52,120
to retrofit governance into systems that will not build for it.

2368
01:20:52,120 --> 01:20:53,320
Start with one workflow.

2369
01:20:53,320 --> 01:20:54,360
Measure success.

2370
01:20:54,360 --> 01:20:55,080
Expand.

2371
01:20:55,080 --> 01:20:56,360
That is the path forward.

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.

Mirko