First, the setup, because it is absurd. According to Matt, ninety-five percent of Fortune 500s still run a mainframe in some capacity. Roughly thirty thousand organizations are still on Lotus Notes. Healy mentions a government claims system running on hardware funded by a grant from the JFK administration, and a separate agency contracting retirees back out of retirement homes to keep the thing alive. This is the installed base that every "AI-native transformation" slide ignores.
TL;DR
If you want to watch the full CRMKonvo, please go ahead here (optimized for smartphones) or here (optimized for tablets/computers).
Else, be my guest and continue to read.
Or do both …
The graveyard problem, now with agents
Modernization has been on the CIO agenda since CIOs were invented. What changed, is that frontier AI does not mix with data and processes trapped inside sixty-year-old systems. But even worse: if AI lets you build faster, it also lets you fill Alan Trefler's famous "application graveyard" faster than ever. The Lotus Notes graveyard of the 2000s simply reopens as an agent graveyard, or a Claude graveyard; take your pick of tombstone.
Healy does not dodge this. He cites the now-familiar numbers on AI-generated code: roughly eight times more duplicated blocks, double the code churn, and about 1.7 times the vulnerabilities versus human-written code. Convenient for a platform vendor to quote? Absolutely. Wrong? Not so much. His conclusion is the sensible one: what works for a hacker building a toy on a weekend does not survive contact with regulated, mission-critical scale.
"Model, don't code," or low-code wearing an AI hat?
This is the core message. Do not let AI generate an application from the foundation up. Use AI to translate business requirements into a model of the business: the processes, the decisions, the rules. Then let a platform run that model consistently, so ninety percent of the application behaves the same across hundreds of apps and only ten percent is specialized.
Revolutionary? Not quite: this is model-driven development, wearing an AI hat. The new and genuinely valuable move is using AI early: analyzing legacy systems, gathering requirements, researching regulations, and doing it grounded on curated best practices rather than, in Healy's words, "who knows where out there on the internet." That is where the productivity actually lives.
Predictability is the whole ballgame
Businesses want predictability, and probabilistic models are by definition not predictable. Healy's stance is the adult-in-the-room part of the episode. Keep orchestration and governance deterministic; confine agents to tasks like summarization, document handling, content generation, and research; and check their work. Crucially, produce visual, explainable models rather than millions of lines of machine-translated code that no auditor can read. When only about ten percent of enterprises have compelling AI in production, and the two roadblocks are cost and risk, "explainable and deterministic" is not a nice-to-have. It is the entire permission slip.
The pricing tell
Healy spells it out. Token-based pricing measures how much thinking the model does, which is not tied to value at all, and this incentivizes vendors to make the model think more. Pega's, as well as other vendors’, counter is outcome-based pricing: pay per claim, or a percentage of your cost per claim, and burn as many tokens as you like. This is the most buyer-aligned idea in the whole conversation. One caveat is of course that outcome pricing is also a lock-in and margin play, and the real negotiation lives in how you define a "claim" or a “resolution” and what today's baseline cost supposedly is.
The three-month miracle
Then the headline claim. An insurance was quoted by a system integrator seven years and roughly $25 million for a lift-and-shift from COBOL to Java. Pega plus it’s AWS tooling, we are told, produced a working application in three months.
The lift-and-shift critique is dead right: machine-translating COBOL into Java that nobody can read just translates old debt to new debt in the cloud. But "a working application based on their mainframe in three months" is an extraordinary claim resting on a single vendor-chosen reference that also happened to speak at Pega's own event. Before anyone budgets around that number, define "working." Which of the seven systems? What stayed on the mainframe? Who maintained it the day after go-live? And note the honest piece Healy volunteers: mainframe-zero is a fantasy. High-volume, low-latency payment processing stays put. The play is to extract the customer-facing, longer-running workloads and leave the transactional core alone.
The debt you cannot see is architectural
Which brings us to the point that vendors would rather skip: Gartner's observation (behind paywall) that technical debt is increasingly becoming architectural debt. That distinction is important, because swapping COBOL for something modern is a code problem, while re-cutting your solution architecture is a business-continuity problem. You cannot simply stop the enterprise, rebuild the plumbing, and switch it back on. Healy's answer is reasonable if unglamorous: plan top-down for where the business must be in one, three, and five years, let AI do the bottom-up archaeology of what you actually have, and meet in the middle. His genuinely useful framing is that this rationalization work, the sort of thing that used to eat six to twelve months of enterprise-architecture effort, can now be compressed into roughly two weeks. That is the compression worth paying for. Just do not let the same speed refill the graveyard with agents nobody governs.
Before you sign anything: three notes for CX buyers
Buy the archaeology, scrutinize the miracle. The lowest-risk, highest-certainty value is in using AI for legacy analysis, requirements gathering, and regulation research. Fund exactly that. Treat "three months, one platform, done" stories as scope-defined case studies, not as your project plan. Ask what "working" means, what was left running on the mainframe, and who owns maintenance after the confetti settled. A demo is a promise; a reference is a data point; neither is your architecture.
Make explainability and determinism contractual, not aspirational. For regulated CX, the probabilistic parts belong at the task level, boxed in and checked, while the process and governance stay deterministic and auditable. Insist on visual, explainable models. If your vendor cannot show a regulator how a decision was reached, understand that you own that risk, not them. "The AI decided" is not a defense you want to offer an auditor.
Price for outcomes, own the baseline. Outcome pricing beats a token meter hands down, so push for it. Just remember the leverage sits in the definitions: what counts as a claim or resolution, what today's cost really is, and what happens when volumes move. Bring finance and a hard-nosed controller into the room early, not after the first invoice. And govern the citizen-developer and agent sprawl from day one; the alternative is watching your Lotus Notes graveyard reopen under new management.
An unusually grounded hour. Healy sells discipline, not magic, and that alone puts this ahead of most vendor pitches. Just read the three-month case study with your glasses on.
Comments
Post a Comment