The Agent Works. Does Anyone Trust It? — Michele Grant, Leading at Scale

Michele Grant argues that an AI agent's technical accuracy is not enough to justify running a core business process. Using an illustrative M&A integration scenario, she lays out a framework built on measurable value against a baseline, three lines of accountability, a Human Works Standard, auditable evidence such as decision logs and model inventories, and staged autonomy governed by independent sampling and an autonomy scorecard.

9 min read
The Agent Works. Does Anyone Trust It? — Michele Grant, Leading at Scale
source: https://www.youtube.com/watch?v=-a2oTS9J67U

Trust Is Engineered Before Launch

Michele Grant opens with a point that many AI deployments miss: go-live proves that a system exists, but it does not prove that the people behind the work will use it, or that it will ever deliver value from the deal model. Drawing on more than twenty years in enterprise transformation and over a decade of M&A integrations across media, tech, and consumer goods, she argues that trust was never something her teams hoped for after launch. It was engineered through early change management and risk management before day one. AI agents, in her view, demand the same discipline.

Her working definition is precise. 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. Leadership reaches that point by answering three questions: What value does it create? Who is accountable for it? What evidence gives it permission to run with greater autonomy?

Grant draws a sharp line between a pilot and daily operations. A pilot tests whether the software functions. Daily operations test whether the agent creates value within the controls leadership has set. She notes that established AI risk frameworks offer strong principles but do not explain how to apply them to each individual agent. For every agent, leadership must decide four things: what it is permitted to do, who owns it, what evidence it records, and what triggers an escalation. She frames this as an executive operating mandate rather than an engineering task.

The Illustrative Acquisition Scenario

To ground the framework, Grant uses a hypothetical $15 billion acquisition targeting $400 million in net synergies. The deal has closed, and an integration management office (IMO) is coordinating 40 workstreams, from vendor contract rationalization to ERP consolidation. Each initiative has a business owner accountable for its bottom-line savings. Every week, IMO analysts reconcile figures against the general ledger, collect status from all 40 leads, compare actuals to plan, and assemble an executive deck for a steering committee made up of the CFO, the chief risk officer, business unit heads, and the integration lead.

An engineering team builds an agent to produce that first draft. It ingests weekly updates, reconciles the ledger, runs variance calculations, and flags lagging initiatives. After a four-week pilot, its drafts match the analysts’ reports line for line. Grant’s point is that this proves the technology works, but not that the steering committee should trust it to run a core business process. She is careful to say that the deal values and capacity figures are illustrative. They explain the operating framework and are not disclosed results or proof that the agent produced the projected synergies.

Measuring Value Against a Baseline

The first requirement is a written value case agreed upon before the agent touches production data. Grant identifies three metrics.

  • Cycle time: if the weekly report currently takes five business days, a realistic target might be two.
  • Analyst capacity: if four analysts each spend half their week on the deck, that is 80 hours a week returned. This counts as value only when the integration lead reassigns those hours to workstreams that are behind on synergy targets, and only after netting out compute, licensing, and human review costs.
  • Detection time: the interval between the first sign of a slip in the data and the moment the steering committee sees it. Grant warns that shortening the report does not guarantee faster detection. The agent must actually catch the slip, and the value case should measure that directly.

Every metric requires a pre-deployment baseline. Her rule is blunt: if the IMO cannot state its baseline today, do not deploy. Without a starting point, there is no way to prove the agent moved the needle, and a faster report is useful only if it changes a decision or releases capacity that the organization actually redeploys. The framework exists so that an attractive demo does not become its own business case.

Accountability Across Three Lines

Grant applies the three lines model to the agent. In the first line, management owns the controls. The integration lead is the accountable executive and owns the agent’s output just as she owned the manual data. In the second line, risk and compliance oversee the agent and challenge how it operates. The depth of that review scales with exposure. An internal draft reviewed by a senior analyst warrants a very different standard than an autonomous agent publishing figures directly to the board. In the third line, internal audit provides independent assurance and decides, based on material risk, when and how the agent enters the annual audit plan.

Beyond the lines, the agent needs a named daily overseer. In the example, this is a senior analyst who reviews drafts before they reach the committee. Grant specifies four capabilities this person must have: a clear understanding of operational boundaries, the ability to interpret output with context, the authority to override or reverse it, and a kill switch to shut it down safely if it behaves unexpectedly.

The Human Works Standard

To make authority explicit, Grant uses a one-page policy she calls the Human Works Standard. For every decision point in the process, it maps the decision, the human role authorized to make it, the required evidence, and the escalation path. Decisions exist at every tier. The senior analyst decides whether a variance is an accounting timing difference or a real cash shortfall. The workstream lead decides how to remediate a shortfall. The integration lead decides whether to formally flag an initiative as at risk to the steering committee. The agent prepares the analysis behind each decision and stops there. As Grant puts it, the person who makes the decision owns the consequence.

She argues that keeping decisions with the team does not slow the agent down. It allows the agent to go into use while each role keeps its authority. The one reason she would delay deployment is a decision with no assigned owner. If leadership has not agreed who declares an initiative off track, the agent’s flags lead to no action.

Evidence for Autonomy: Logs, Inventory, and Scorecards

Greater autonomy must be earned with evidence that comes from how the agent is built. Grant looks for three artifacts.

The first is an auditable decision log. For every workstream evaluated, it records the raw data ingested, the tool calls executed, the prompt, the model version, the output generated, and the human sign-off. Two engineering choices make this log reliable. Core math and reconciliation rules should run in deterministic, finance-approved code rather than being generated as conversational prose by an LLM. The model’s written summary should be treated as a helpful explanation, not as proof. The real proof lives in telemetry: what records were pulled, which deterministic tools ran, and who signed the review. If reported savings do not match the general ledger, the agent does not alter the number. It flags the discrepancy and routes it upward.

The second artifact is the model inventory record. It captures the accountable executive, data lineage, dependencies across source systems, validation results, the escalation path, and the kill switch runbook. Most importantly, it documents regression triggers, meaning any update to the base model or a source API that requires full revalidation before the agent returns to production.

The third artifact is an autonomy scorecard, which the steering committee uses to grant autonomy in stages.

Four Stages of Autonomy and the Problem of Missed Issues

Grant describes a progression. In stage one, shadow mode, analysts build the report as they do today while the agent runs alongside them and the two outputs are compared. In stage two, the supervised draft, the agent compiles the first draft and the senior analyst reviews every line item. In stage three, the analyst reviews lagging initiatives along with a random sample of the remaining claims. In stage four, exceptions only, the analyst reviews only high-risk anomalies, supported by periodic independent sampling.

Grant emphasizes that stage four carries the greatest vulnerability, because humans are no longer looking at everything, and the biggest risk becomes what the agent failed to flag. Missed material issues matter as much as flagged ones, so she recommends tracking them through independent sampling, monitoring error severity, and watching the override rate closely. A falling override rate does not automatically mean the agent is improving. It can also mean that the depth of review has slipped. Independent sampling is what reveals which of these is happening.

The scorecard places these control metrics beside the value metrics of cycle time, analyst hours deployed, and detection time. With that single view, the committee can decide whether to promote the agent, hold it where it is, step it back, or return it to supervised draft review.

Returning to the Three Questions

Grant closes by returning to her three questions, which she asks of every agent that is built, funded, or governed. What value does it create? Who is accountable for it? What evidence permits it to operate with autonomy? In the M&A example, the agent did not create the $400 million in synergies. Procurement, supply chain, and operating leaders captured that value through the difficult work of integration. What the agent delivers is verified evidence weeks ahead of schedule, which gives leadership time to intervene while synergies can still be captured. As her final line makes clear, building an agent that works is only the first step. Answering those three questions is what earns it the trust to run at scale.

Share post

Stay In The Loop! Subscribe to Our Newsletter.

Get updates straight to your inbox. No spam, just useful content.

Recommended for You

Giving AI Agents Memory That Learns — Jake Broekhuizen, LangChain

Giving AI Agents Memory That Learns — Jake Broekhuizen, LangChain

Jake Broekhuizen of LangChain Labs argues that observability alone does not make agents improve. Using a financial services agent whose tone drifted from advisory to pushy, he shows how traces only become useful memory when a filtered lesson is written back as durable context the agent reads on its next run. The talk covers semantic, episodic, and procedural memory, the working versus long-term memory distinction, the read-write cycle, and how LangSmith and Context Hub support capture, analysis, and updates, along with lessons about keeping only signal, caching, and human review of procedural changes.

When Should AI Systems Use Super Agents?

When Should AI Systems Use Super Agents?

Grant Miller explains the paradox of "super agents" in AI systems – their immense power comes with significant risks. He details concerns like privilege abuse and expanded attack surfaces, contrasting them with the benefits of unified organizational intelligence and workflow coordination. The solution proposed is an architecture of "agent swarms," guided by principles of least agency, isolation, observability, and human oversight, to build secure and scalable agentic systems.