The AI “Captain America Serum” and Rebuilding the Broken Enterprise

Matt Peters is co-founder and CEO of Fixify, a platform that applies AI to IT service and security operations. Before founding Fixify, he was Chief Product Officer at Expel, one of the better-regarded MDR companies of the last decade. Earlier, he was VP of Worldwide Operations at Mandiant during the height of the APT era — the period when nation-state threat attribution became a public discipline and incident response teams were routinely walking into some of the most complex intrusions ever documented. That combination of product thinking, operational scale, and hands-on threat exposure shapes how he reads the current AI transformation, and it's what this conversation is about.

The anchor here is Fixify's 2026 benchmark report: 50,000 tickets across 30 organizations, and a finding that cuts against the prevailing AI hype. Resolution times improved dramatically. First-response times didn't move. Peters explains why — and uses that gap to build a broader argument about where AI actually changes the unit economics of security and IT work, and where the organizational debt underneath most enterprises will cause AI initiatives to collapse regardless of which model you're running on top of them. If you're a CISO or CIO deciding where to put real budget behind AI in 2026, this episode covers the failure patterns and the few places where the ROI is genuine.

Hampton North is the premier US based cybersecurity search firm. Start building your security team with Hampton North

Sysdig is the leader in AI-powered real-time cloud defense; stop watching and start defending

Fixify's benchmark report looked at 50,000 tickets across 30 organizations and found resolution times improved 16 times over with AI. First-response times were unchanged. That asymmetry is the right place to start because it tells you something about where the constraint actually sits.

First-response time in a well-run help desk is already optimized for human expectations. If someone sends a Slack message or submits a ticket, they're expecting a reply in human time — sixty or ninety seconds. Getting faster than that doesn't move anything. What does move things is what happens after triage, once a request requires someone to go ask a question, wait for an approval, loop in a security team, or chase down a manager. That's where the time goes. Not in active work — in waiting for humans to come back to something they've already mentally filed away.

What AI trims is that accumulated slack. An automated workflow doesn't put a task down and pick it back up. It waits, receives the response, and acts. And where older automation would break on ambiguous replies — a user typing "yup, sounds good" instead of pressing the approval button — a well-designed AI layer has enough discernment to treat that as a valid confirmation and keep moving. That's not a dramatic capability. It's a boring one. It's also where the 16x lives.

Peters spends a fair amount of time on the Stanford Digital Economy Lab's study of 51 successful AI deployments, and the finding that deserves the most attention is this: roughly 60% of those successful programs had a prior failure. The teams that eventually got AI working had already tried and gotten it wrong once.

The reason most projects fail, according to both that study and Peters's own experience at Fixify, comes down to organizational infrastructure. The data is unstructured. The application catalog doesn't exist. Nobody can answer who owns a given system or what the approval policy is. The average company Fixify works with has over 150 applications, and a non-trivial portion of those are unknown to the IT team in any operational sense — meaning there's no owner documented, no access policy defined, nothing to hand an AI agent so it can do the right thing.

This maps directly to the 2025 MIT NANDA study finding that 95% of generative AI pilots produced no measurable financial output, and that misalignment of organizational incentives was the primary cause. Peters's read is similar: the technology is largely interchangeable. The Stanford study found that which LLM you're running on top of didn't meaningfully differentiate outcomes. What mattered was whether the organizational substrate — the data, the ownership model, the process definition — was solid enough for AI to do useful work on top of it.

The implication for anyone running an AI initiative is that the scoping work that happens before you touch the technology is where most of the value is created or destroyed. Picking the problem carefully, auditing the data that underlies it, and mapping the approval and ownership structure around it is the project. The AI part is relatively fast once that's done.

Peters references a book called Predictions Machines to make a point that's easy to agree with in principle and hard to act on in practice. When the cost of something drops dramatically, the obvious move is to do more of that thing. But the organizations that actually capture transformational value are the ones that use the cost drop to redesign everything around it.

The shipping container analogy is apt. You could respond to cheaper freight by shipping more of the same things. Or you could move manufacturing to different parts of the world and rebuild global supply chains. The technology enabled both. Most organizations chose the first option; the ones that chose the second captured most of the value.

The mental model Peters uses to get there: assume you have an infinite number of people. Now ask what you would do differently. If you can do quality control on every output instead of sampling, what does your process look like? If every person in the organization can query your CRM directly and get analytics in seconds, do you still need the reporting meeting? If a new application can be prototyped in three hours, do you need the full specification process before anyone writes a line of code?

The point is not that every workflow gets rebuilt. It's that the scarcity that shaped your current workflow may no longer be real, and if you don't examine it directly, you'll optimize for a constraint that doesn't exist anymore. Peters calls the failure to do this a poverty of vision — incremental AI adoption that leaves the underlying process architecture intact while slightly reducing the cost of running it.

The CMDB problem Peters raises isn't new to anyone who's been inside a security program for more than a year. Walk into most organizations and ask for an authoritative asset inventory. You won't get one. What's different now is that this organizational debt, which was previously a security compliance problem, has become a direct blocker to AI ROI.

AI agents working on IT workflows need to know what applications exist, who owns them, what the access policies are, and what the approval chain looks like. If that information doesn't exist, the agent either fails or, worse, produces confident-sounding outputs built on bad inputs.

Peters's recommendation is to treat the data cleanup as the first deliverable, not a prerequisite someone else handles before the real project starts. Identify the specific process you want to improve. Then trace backward to the data that process depends on. Have a data engineer look at it before anything else. Make sure naming conventions are consistent, ownership is mapped, and the key fields are populated accurately enough that an agent can act on them.

The broader lesson from the Stanford study — that the intervening LLM technology is largely interchangeable — reinforces this. No amount of model quality compensates for structural data problems. The organizations that succeeded had invested in getting the organizational infrastructure right first, often after a first attempt failed precisely because they hadn't.

Peters spent years at Mandiant watching the gap between sophisticated nation-state actors and lower-tier threat actors. That gap was once a useful signal — TTPs were bespoke enough that attribution was often possible just from behavioral analysis. That's no longer reliable. The capabilities that used to require a nation-state are now close to off the shelf, and AI is accelerating the timeline at every stage of the attack lifecycle.

The Sysdig research Peters references — initial access to admin privileges in cloud accounts in under ten minutes, weaponized exploits appearing in the wild within a day of a text description of a vulnerability — represents a fundamental change in what patch discipline and detection capability need to look like. The average age of a vulnerability used in breaches was historically around five years. The assumption that defenders have time to work through patching backlogs in normal priority cycles is gone.

On the defensive side, Peters sees AI making a real difference in signal processing and response automation — reducing the cost of monitoring more surface area and making the "what now" question in an active incident more answerable for teams that don't live in response work every day. But he's clear that this doesn't close the gap. Defenders have moved the needle; attackers still hold the advantage.

The practical counsel for security leaders: have a clear mental model of the business's risk register before you're making decisions under pressure. Know which assets are crown jewels, what the actual dollar exposure looks like on each risk (the general counsel's office is a useful calibration point here), and which scenarios are compensating-control problems versus which ones are shut-it-down-right-now problems. Run tabletops not because the plan will survive contact but because the exercise surfaces the gaps — including the basic one where nobody knows the phone numbers they'd need to call at 2 a.m.

Peters's framework for durability distinguishes between experience, skills, and traits. Experience and skills have always been subject to obsolescence — specific domain knowledge that gets automated away, tools that stop being relevant. Traits are different. Curiosity, systems thinking, and the ability to communicate with clarity are not things AI cheapens.

On communication specifically: LLMs will make it easier to produce polished prose, but Peters argues this actually raises the stakes for genuine clarity of thought rather than reducing them. If your team is generating tremendous volume of output and nobody can articulate what they're actually trying to accomplish, the AI is amplifying noise, not signal.

The other durable trait is business curiosity — understanding the organization well enough to apply systems thinking to it. Peters observes that the CIOs he interviews who are succeeding all share this: they've learned the business, not just the technology stack. As AI reduces the premium on domain-specific expertise, the value of knowing what the organization is actually trying to accomplish, and how changes in one place ripple into others, goes up. That's a skill you build by being curious about the parts of the business that aren't your department, and it's one that doesn't depreciate.

Guests — Matt Peters, co-founder and CEO of Fixify; former Chief Product Officer at Expel; former VP of Worldwide Operations at Mandiant.

Books mentioned — The Myths of Innovation by Scott Berkun; Prediction Machines (referenced as Predictions Machines) by Ajay Agrawal, Joshua Gans, and Avi Goldfarb; Turn the Ship Around! by L. David Marquet.

Frameworks / models / tools named — Stanford Digital Economy Lab Enterprise AI Playbook (51 successful deployments study); MIT NANDA Initiative 2025 generative AI pilot study; Verizon Data Breach Report; Sysdig zero-day clock / vulnerability exploitation timeline research; CMDB (Configuration Management Database); MCP (Model Context Protocol); tabletop exercises; Fixify platform; HubSpot; Hex.

Other people / shows / resources referenced — Sergey (Sysdig threat research, zero-day clock); Bruce Schneier (VulnOps discussion); APT3 (threat group referenced from Mandiant era); Expel (MDR); Profit Security (real-time MDR agent context).