The Chief AI Officer Show

98% of IT leaders say they're using AI, yet 43% aren't measuring ROI and 80% admit they're not using it to its potential. Olga Lagunova, Chief Innovation and Technology Officer at GoTo, says the industry won the adoption battle but hasn't reached the outcomes it needs.Olga breaks down GoTo's federated AI steward model, where functional leaders own roadmaps and a central enablement team provides infrastructure. She explains why SMB pragmatism shaped their practical AI principles and how 39% of employees already report AI is eroding their skills.Topics discussed:Why 98% AI adoption still produces an outcomes gapGoTo's federated AI steward model for scaling transformationHow SMB customer pragmatism shaped practical AI principlesBuilding progressive trust with autonomous agents80% of customer context is unstructured and agents need itFrom tool to actor, how agency changed the AI equationDesigning agent governance around identity and guardrailsThe skill erosion problem 39% of employees already feelListen to more episodes: Apple Spotify YouTube

Eric Ries built the Lean Startup methodology, helped advise on Anthropic's long-term benefit trust structure, and is now making an argument most enterprise leaders aren't ready to hear: deploying AI agents inside a company with bad governance isn't just a compliance risk, it's an existential one. His new book, Incorruptible, makes the case that the same slow-moving forces that corrupt companies over decades will be dramatically accelerated by AI, and that the standard governance playbook most executives have been handed is the actual source of the problem.In this conversation, Eric and Ben cover the legal and structural traps that silently strip companies of mission control long before anyone notices, why Anthropic walking away from a $200M Pentagon contract turned into an unexpected competitive advantage, and what AI leaders specifically need to do before they deploy agents at scale. Eric is direct about what he thinks leaders are getting dangerously wrong right now, and he pulls no punches.Topics Discussed:Why standard "best practice" corporate documents are structurally designed to separate mission from controlCorporations as slow AIs, and why agents deployed inside misaligned companies will amplify existing extractive behavior at machine speedHow Anthropic walking away from a $200M contract without knowing the outcome became a case study in principled governance paying offWhy SOC 2 offers no real protection when AI vendors cannot control what enters their own training dataBenchmark inflation as evidence that major AI vendors lack basic data governance over their own training pipelinesWhy contractual penalties are functionally worthless when vendor liabilities exceed assets by a factor of 10 to 100The AIUC and insurance-based standard-setting as a collective procurement lever enterprise buyers aren't usingThe four governance moves a CAIO can make within their own span of control before the board ever gets involveListen to more episodes: Apple Spotify YouTube

Intercom launched outcome-based pricing before the market had a framework for it, before inference costs made it profitable, and before customers knew how to budget for it. Fergal Reid, Chief AI Officer, was inside that decision and he shares exactly how they modeled their way through it, what two bets he personally owned, and why they went to $1 per resolution knowing it was a loss.That pricing story is inseparable from their model strategy. Fergal walks through the production data that led them to conclude that Opus 4.5 didn't outperform Sonnet 4.0 on their RAG customer service task, what that told them about the limits of general intelligence at the application layer, and why it pushed them to build Apex, their own model trained via reinforcement learning on an open-weight base specifically for customer service. With 85% of Intercom's own support volume now fully automated, the bets held.Topics discussed:Outcome-based pricing mechanics: the $2 beta, the loss-leader move to $1, and the two assumptions Fergal had to ownWhy Opus 4.5 failed to outperform Sonnet 4.0 on a production RAG task and what that signalsIntelligence saturation at the application layer and why more general capability stops moving the needleBuilding Apex: using reinforcement learning on open-weight models to reshape expertise distributionThe internal bet on going all-in on Fin over a Copilot bridge productWhy outcome-based pricing is now a customer expectation for high-value AI products, including a new $10/outcome productWhy 85% automation in customer service still hasn't driven fast adoption, and what actually moves the curveWhy Fergal takes the possibility of recursive self-improvement seriously when most application-layer leaders don'tListen to more episodes: Apple Spotify YouTube

What happens when a journalist turned Amazon product manager becomes the Chief AI Officer of one of the world's largest international broadcasters? You get someone who sees the AI threat to media not just as a distribution problem, but as a full production chain crisis that requires a fundamentally different organizational architecture.Marie Kilg, Chief AI Officer at Deutsche Welle, makes the case that legacy media's survival depends on something most AI transformation conversations ignore: data interoperability across systems that were never designed to talk to each other. With 32 languages, siloed editorial teams, and decades of layered organizational structure, Deutsche Welle's path to an AI-powered content flywheel starts at the infrastructure layer, not the model layer.Topics Discussed:Why AI threatens the full media production chain, not just distributionThe flywheel model: feeding audience data back into editorial decisionsData interoperability as the core prerequisite for AI at scale in mediaWhy "push a button and AI does it" expectations are damaging real implementationHow metadata automation surfaces hidden infrastructure debtOrganizational change mechanisms vs. culture change in large public broadcastersTech companies underestimating journalism as a discipline

Most security leaders treat AI as a new threat category requiring new defenses. Rohit Parchuri, SVP and Chief Information Security Officer at Yext, pushes back hard on that. His argument: if your foundational controls are solid, AI does not require you to rebuild anything. What it does is amplify whatever you already have, gaps included, which makes the real question not "what new controls do we need?" but "how well are we actually executing on what we already built?"Rohit walks host Ben Gibert through how Yext is operationalizing this at scale: threat-modeling AI as just another system with inputs, processing, and outputs; building AI security testing directly into the existing CI/CD pipeline rather than standing it up as a separate track; investing heavily in data classification and taxonomy to solve DLP before deploying any AI tool internally; and establishing an AI Excellence Committee with cross-functional representation to run a single governance funnel across every AI request in the company. He also makes the case that the CISO who earns a seat at the AI strategy table is the one who deeply understands the business value chain, not just the threat landscape.Topics discussed:Threat-modeling AI as a system instead of a threat categoryWhy existing security controls are sufficient for AI todayIntegrating AI security testing into CI/CD without adding process overheadData classification and taxonomy as prerequisites for safe internal AI adoptionUsing an AI Bill of Materials as a transparency mechanismHow Yext's AI Excellence Committee runs a single governance funnelBuild vs. buy decision-making for AI security toolingWhat separates strategic CISOs from tactical operators in the age of AIThe CISO's role in enabling AI adoption rather than blocking it

Diamond Bishop has spent 15 years building AI systems at Microsoft (Cortana), Amazon (Alexa), and Facebook (PyTorch) before founding an AI DevOps startup that Datadog acquired. Now running Datadog's AI Skunk Works, a deliberately small interdisciplinary team modeled on Lockheed's original, he's focused on a question most enterprise AI teams aren't asking yet: what does your product look like if humans are no longer the primary customer?That question drives everything from Bits AI, their production SRE and security agent, to a set of longer-range bets organized around three pillars: personalized agent learning, enterprise agent infrastructure, and eval. Diamond breaks down how he structures each one, why the demo-to-production gap comes down to data and eval rather than model capability, and where the real unsolved problems in agent development still sit.Topics discussed:Bits AI's capabilities in production across SRE incident response, security analysis and code generationThree-pillar agent development framework: personalized learning, enterprise infrastructure and evalLoRA-style adapter architecture for layering custom per-user agents on top of first-party agentsWhy SRE agent startups without proprietary observability data face a structural disadvantage at production scaleService graph and entity relationship context as a structured alternative to RAG for DevOps agentsSkunk Works team design: staying small and interdisciplinary to move like a startup inside a public companyThe shift from human-operated cloud services to ambient AI-native services built to run with fewer humans over timeCrawl-walk-run path for enterprise agent adoption: from LangGraph-based Python agents to continuously learning systemsWhy concentrating AI research investment in transformer scaling creates long-term architectural riskBuilding agent-native tooling rather than repurposing interfaces designed for humans

Most enterprise AI initiatives die in pilot purgatory because organizations chase peripheral use cases instead of embedding AI into core business processes. Vineet Moroney, Chief Transformation Officer at Xoriant, a 6,000-person engineering services firm, has built a measurement system that eliminates this problem: tie AI directly to three financial metrics (revenue, margin, brand multiple) and make 50% of performance bonuses dependent on them.His framework separates AI revenue into two categories: "with AI" (AI-led service transformation like platform modernization) and "for AI" (building AI capabilities on customer platforms). AI margin captures efficiency gains from tool usage that improve project delivery economics. AI multiple quantifies brand value and downstream revenue from innovative deployments. This structure forces teams to distinguish between projects that matter and expensive experiments.When Xoriant's CFO wanted to reduce Days Sales Outstanding, Vineet built an invoice payment prediction model at 87% accuracy that eliminated a five-person AR team and cut DSO by two days. The solution required no expensive models, just strategic business case selection. For manufacturing clients, he's deploying edge AI on legacy sensor infrastructure for predictive maintenance without sensor replacement, creating new service revenue streams from installed equipment bases.Topics discussed:Three-part AI revenue model distinguishing "with AI" service transformation from "for AI" capability building on customer platformsCompensation structure allocating 50% of performance bonuses across AI revenue generation, margin improvement, and brand multipleThe EXB framework quantifying AI returns through efficiency gains, experience improvements via customer lifetime value, and business impact from downstream revenueTwo-week POC to 90-day production methodology with AI assurance testing protocols for non-deterministic system validationFive prerequisite elements for POC survival: strategic alignment, C-suite sponsorship, urgent business need, allocated budget, and core process focusEdge AI monetization on legacy sensor infrastructure for predictive maintenance and service offering creation without hardware replacementInvoice payment prediction at 87% accuracy reducing five-person AR teams to single-person operations while cutting DSO by two daysWhy golden dataset POCs fail at scale due to latency, inconsistency, and infrastructure readiness gapsSales approach for skeptical executives: lead with customer pain points, prove with similar completed work, commit to rapid production timelinesMiddle management resistance as the primary adoption barrier despite CEO enthusiasm and junior staff willingness to adopt AI tools

Lenovo cut parts planning from six hours to 90 seconds by treating infrastructure architecture as a first-class constraint, not an afterthought. Linda Yao, VP and GM of Hybrid Cloud and AI Solutions, has deployed AI across manufacturing, healthcare diagnostics, and enterprise operations. Her core thesis: most organizations fail at scale not because of use cases or data quality, but because they architect pilots in sandboxes that can't translate to production enterprise data centers.Through Lenovo's internal deployments and customer implementations, Yao has built a systematic approach to moving past experimentation. Her team developed what they call an AI library of battle tested use cases with proven deployment architectures, from computer vision systems that augment special education therapists to diagnostic tools preventing blindness in underserved regions. The methodology centers on a critical insight: ongoing monitoring and model management represents the capability gap causing implementations to plateau after initial deployment.Topics discussed:Five-stage methodology where ongoing monitoring of drift, model updates, and agent evolution separates successful deployments from stalled pilotsInfrastructure architecture coherence requirement between pilot and production environments to enable actual scalingEnterprise planning agents orchestrating across personal wellness, workload management, and digital employee experience using full device stack ownershipAI factory model for rapid diagnostic tool development and field distribution in resource constrained healthcare settingsHybrid deployment trend reversing decade long cloud first mentality due to data governance and compliance requirementsFour pillar readiness assessment covering security, data quality, people capability, and technology infrastructure before deploymentBuild leverage partner philosophy for full stack integration with pre tested component validation and reference architecturesLiquid cooling technology deployment addressing GPU energy consumption and data center sustainability constraints at scale

Lawrence Jones, product engineer at incident.io, describes how their AI incident response system evolved from basic log summaries to agents that analyze thousands of GitHub PRs and Slack messages to draft remediation pull requests within three minutes of an alert firing. The system doesn't pursue full automation because the real value lies elsewhere: eliminating the diagnostic work that consumes the first 30-60 minutes of incident response, and filtering out the false positives that wake engineers unnecessarily at 3am.The core architectural decision treats each organization's incident history as a unique immune system rather than fitting generic playbooks. By pre-processing and indexing how a specific company has resolved incidents across dimensions like affected teams, error patterns, and system dependencies, incident.io generates ephemeral runbooks that surface the 3-4 commands that actually worked last time this type of failure occurred. This approach emerged from recognizing that cross-customer meta-models fail because incident response is fundamentally organization-specific: one company's SEV-0 is an airline bankruptcy, another's is a stolen laptop.The engineering challenge centers on building trust with deeply skeptical SRE teams who view AI as non-deterministic chaos in their deterministic infrastructure. Lawrence's team addresses this through custom Go tooling that enables backtest-driven development: they rerun thousands of historical investigations with different model configurations and prompt changes, then use precision-focused scorecards to prove improvements objectively before deploying. This workflow revealed that traditional product engineers struggle with AI's slow evaluation cycles, while the team succeeded by hiring for methodical ownership over velocity.Topics discussed:Balancing precision versus recall in agent outputs to earn trust from SRE teams who are "hardcore AI holdouts"Pre-processing incident artifacts (PRs, Slack threads, transcripts) into queryable indexes that cross-reference team ownership, system dependencies, and historical resolution patternsModel selection strategy: GPT-4.1 for cost-effective daily operations, Claude Sonnet for superior code analysis and agentic planning loopsBacktest infrastructure that reruns thousands of past investigations with modified prompts to objectively validate changes through scorecard comparisonsBuilding ephemeral runbooks by extracting which historical commands and fixes worked for similar incidents, filtered by what the organization learned NOT to do in subsequent incidentsPrioritizing alert noise reduction over autonomous remediation because the false positive problem has clearer ROI and lower riskWhy AI engineering teams fail when staffed with traditional engineers optimized for fast feedback loops rather than tolerance for non-deterministic iterationBuilding entirely custom tooling in Go without vendor frameworks due to early ecosystem constraints and desire for native product integrationThe evaluation problem where only engineers who invested hundreds of hours building a system can predict how prompt changes cascade through multi-step agentic workflows

Alexander Page transitioned from sales engineer to engineering director by prototyping LLM applications after ChatGPT's launch, moving from initial prototype to customer GA in under four months. At Big Panda, he's building Biggy, an AIOps co-pilot where reliability isn't negotiable: a wrong automation execution at a major bank could make headlines.Big Panda's core platform correlates alerts from 10-50 monitoring tools per customer into unified incidents. Biggy operates at L2/L3 escalation: investigating root causes through live system queries, surfacing remediation options from Ansible playbooks, and managing incident workflows. The architecture challenge is building agents that traverse ServiceNow, Dynatrace, New Relic, and other APIs while maintaining human approval gates for any write operations in production environments.Page's team invested months building a dedicated multi-agent system (15-20 steps with nested agent teams) solely for knowledge graph operations. The insertion pipeline transforms unstructured data like Slack threads, call transcripts, and technical PDFs with images into graph representations, validating against existing state before committing changes. This architectural discipline makes retrieval straightforward and enables users to correct outdated context directly, updating graph relationships in real-time. Where vector search finds similar past incidents, the knowledge graph traces server dependencies to surface common root causes across connected infrastructure.Topics discussed:Moving LLM prototypes to production in months during GPT-3.5 era by focusing on customer design partnershipsEvaluating agentic systems by validating execution paths rather than response outputs in non-deterministic environmentsBuilding tool-specific agents for monitoring platforms lacking native MCP implementationsArchitecting multi-agent knowledge graph insertion systems that validate state before write operationsImplementing approval workflows for automation execution in high-consequence infrastructure environmentsDesigning RAG retrieval using fusion techniques, hypothetical document embeddings, and re-representation at indexingScaling design partnerships as extended product development without losing broader market applicabilitySeparating read-only investigation agents from write-capable automation agents based on failure consequence modeling