[
  {
    "startMs": 2660,
    "text": "Go-live proves that a system exists, but it doesn't prove the people behind the work will actually use it, or that it will ever deliver a single dollar from the deal model. I am Michele Grant, creator of Leading at Scale, and the question every enterprise is confronting right now is: Agent works, does anyone trust it? I have spent over twenty years in enterprise transformation and more than a decade"
  },
  {
    "startMs": 32800,
    "text": "leading M&A integrations across media, tech, and consumer goods. On those deals, trust was not something we crossed our fingers and hoped for after launch. We engineered it before day one through early change management and risk management. So when the platform went live, the teams on the ground actually relied on it."
  },
  {
    "startMs": 63020,
    "text": "AI agents demand the exact same muscle. An agent earns trust when it delivers the value the business budgeted for while staying strictly within the company's approved risk appetite, policies, and regulatory guardrails. In my experience, leadership gets there by answering three straightforward questions: What value does it create?"
  },
  {
    "startMs": 92820,
    "text": "Who is on the hook for it? And what evidence gives it permission to run with greater autonomy? The moment an agent steps out of a sandbox and into a core business workflow, the entire test changes. A pilot tests whether the software functions, but daily operations is where we test whether it creates value within the controls set by leadership."
  },
  {
    "startMs": 122400,
    "text": "Established AI risk frameworks give you strong principles. What they do not give you is how to apply these principles to each agent. For every agent, leadership has to decide four things: What is it permitted to do? Who owns it? What evidence it records, and what triggers an escalation? That work is not an engineering task. We find it is an"
  },
  {
    "startMs": 151820,
    "text": "executive operating mandate, and today I'll show you how to meet it. Let us ground this in a real-world scenario. Picture a fifteen billion dollar acquisition targeting four hundred million in net synergies. The deal has already closed, and the integration efforts are now underway. The integration management office, which we'll also refer to as the IMO"
  },
  {
    "startMs": 181860,
    "text": "today, is driving the synergy roadmap across forty work streams, covering everything from rationalizing vendor contracts to consolidating ERP systems. And every single initiative has a business owner accountable for its bottom-line savings. Every week, analysts in the IMO are going to reconcile the numbers against the general ledger."
  },
  {
    "startMs": 212520,
    "text": "As they track down status from all forty leads, they're also comparing actuals against the plan, then finally assembling the executive deck for the steering committee, which is going to include the CFO, the chief risk officer, business unit heads, and the integration lead. The engineering team builds an agent to automate that first draft. The agent then"
  },
  {
    "startMs": 242120,
    "text": "ingests the weekly updates, reconciles the ledger, runs variance math against the plan, and flags the initiatives that are falling behind. Everything looks good, and they decide to run a four-week pilot. The agent's drafts match the analyst reports line for line. So we can say that the tech works. Now the question is: What value does that steering"
  },
  {
    "startMs": 272000,
    "text": "committee need before they can trust it to run the business? First, the steering committee needs a written value case agreed upon before the agent ever touches production data. In our example, that comes down to three specific metrics. First, let's look at cycle time. If that weekly report eats five business days to compile right now, you're gonna"
  },
  {
    "startMs": 301880,
    "text": "wanna set a hard target such as two days. Your second metric will be analyst capacity. If four analysts spend half of their week building this deck, that is eighty hours a week the agent gives back. That time counts as value only when the integration lead assigns it to the work streams that are behind on their synergy targets and need help getting back on"
  },
  {
    "startMs": 331720,
    "text": "track. Then you only count that value after netting out the compute, licensing, and human review costs of running the agent. Your third metric is the most important one: detection time. That is how long it takes from the first sign of a slip in the data to the moment the steering committee sees it. Cutting the report from five days to two days does not"
  },
  {
    "startMs": 361560,
    "text": "guarantee that the committee sees that slip any sooner The agent has to catch it, and the value case measures that directly. Every single metric requires a pre-deployment baseline. If the IMO cannot state the baseline today, do not deploy. If you can't measure where you started, you can never prove the agent moved the needle. Next, the steering committee"
  },
  {
    "startMs": 391420,
    "text": "needs to know who owns the risk the agent creates. We are going to apply the three lines model to the agent. In the first line, management owns the controls. The integration lead is the accountable executive. She owns the agent's output exactly the way she owned the manual deck. In the second line, risk and compliance oversee the agent and"
  },
  {
    "startMs": 421120,
    "text": "challenge how to run it. How deep they go depends on the agent's exposure. An internal draft scrubbed by a senior analyst warrants a very different review standard than an autonomous agent publishing figures straight to the board. In the third line, internal audit provides assurance, deciding based on material risk when and how the agent enters the annual"
  },
  {
    "startMs": 451140,
    "text": "audit plan. The agent also needs one employee assigned to oversee it every day. In our example, that is the senior analyst who reviews the draft before it reaches the committee. Her role requires four specific capabilities. She has to first understand the operational boundaries. She has to interpret its output with context. She must"
  },
  {
    "startMs": 480880,
    "text": "have the authority to override or reverse it, and she needs a clear kill switch to shut it down safely the second it behaves unexpectedly."
  },
  {
    "startMs": 494340,
    "text": "Accountability also means defining where the agent's authority stops. I document this in a one-page policy called the Human Work Standard. For every fork in the process, it maps the decision, the human role authorized to make it, the required evidence, and the escalation path. These decisions exist at every tier. The senior analyst decides whether"
  },
  {
    "startMs": 524400,
    "text": "a variance is an accounting timing difference or a real cash shortfall. The workstream lead decides how to remediate that shortfall, and the integration lead is going to decide whether to formally flag an initiative as at risk to the steering committee. The agent prepares the analysis behind every one of those decisions, and it stops there. The person who makes the"
  },
  {
    "startMs": 554100,
    "text": "decision owns the consequence. So keeping these decisions with your team does not slow the agent down. It can go into use while each role keeps its authority. The one reason to deli-delay deployment is a decision with no assigned owner. This means if leadership has not agreed who declares an initiative off track, the agent's"
  },
  {
    "startMs": 584040,
    "text": "flags lead to no action. The third question is where the engineers in this room come in. The evidence for greater autonomy comes from how the agent is built. I look for three artifacts. The first is an auditable decision log. For every workstream the agent evaluates, it records the raw data ingested, the tool"
  },
  {
    "startMs": 613860,
    "text": "calls executed, the prompt and the model versions, the output generated, along with the human sign-off. Two engineering choices make that log airtight. First, your core math and reconciliation rules must run in deterministic finance-approved code, not generated as conversational prose from an LLM."
  },
  {
    "startMs": 643700,
    "text": "Second, treat the model's written summary as a helpful explanation, not proof. Your real proof lives in the telemetry. What records were pulled? What deterministic tools ran? And who signed the review?"
  },
  {
    "startMs": 663020,
    "text": "If reported savings do not match the general ledger, the agent does not touch the number. It flags the discrepancy and routes it up. The second artifact is the model inventory record. This captures the accountable executive, data lineage, dependencies across source systems, validation results, escalation paths, and the"
  },
  {
    "startMs": 692920,
    "text": "kill switch runbook. Most importantly, it documents your regression triggers, which are any updates to a prompt, base model, or source API that require full revalidation before running in production again."
  },
  {
    "startMs": 711040,
    "text": "Your third artifact, this is going to be the autonomy scorecard. The steering committee uses it to grant autonomy in four stages. Stage one is shadow mode. The analyst built the report as they do today. The agent runs right alongside them, and the team compares the two Stage two is the supervised draft. The agent compiles the first draft, and"
  },
  {
    "startMs": 740980,
    "text": "the senior analyst reviews every single line item. Stage three is the exception and sample, where the analyst reviews flagged initiatives plus a random sample of the clean ones. Then we have stage four, where it's exceptions only. The analyst reviews only high-risk anomalies supported by periodic independent sampling. Pay"
  },
  {
    "startMs": 770860,
    "text": "close attention to stage four, however, because once humans only look at exceptions, your biggest vulnerability is what the agent failed to flag. So I advise tracking missed material issues through independent sampling, monitoring error severity, and watching your override rate carefully. A falling override rate does not automatically mean the agent is getting smarter. It can also mean the"
  },
  {
    "startMs": 800620,
    "text": "depth of review has slipped. So independent sampling tells you which one of these you are seeing. The scorecard puts those control metrics side by side with your value metrics: cycle time, analyst hours deployed, and your detection time. And with that single-page view, the steering committee can make clean, efficient, data-backed decisions to either promote the agent, hold"
  },
  {
    "startMs": 830580,
    "text": "it where it is, step it back or down to supervised review stage. So let's come back to the three questions. Ask them of every agent you build, fund, or govern. What value does it create? Who is accountable for it? And what evidence permits it to operate with autonomy? In our M&A"
  },
  {
    "startMs": 860580,
    "text": "example today, the agent does not magically create the four hundred million in synergies. Procurement, supply chain, and operating leaders capture that value through the gritty work of integration. But what the agent delivers is clear: verified evidence weeks ahead of schedule, giving leadership the runway to intervene while the deal's synergies can still be captured. Building an agent that"
  },
  {
    "startMs": 890340,
    "text": "works is just the first step. Answering those three questions is what earns it the trust to run at scale. Thank you."
  }
]