That is why the three moves do not end. Defend, re-engineer, and reposition run as three permanent programs, on three different clocks, past whatever date a roadmap slide calls the transformation complete. The skill this piece is about is holding all three together, on one cadence and one scoreboard, running the whole thing as a loop that gets better at changing rather than a plan that gets executed once.

That is a harder discipline than it sounds, because the natural failure mode is tidiness, not laziness. Three programs with three owners and three clocks feels chaotic next to a clean roadmap with a start date and an end date, so the instinct is to impose order: serialize the moves, put them under one owner, or write a three-year plan and call the transformation done once it ships. Every one of those instincts produces a company that looks organized on a slide and loses the window in practice. And the market is not grading patience. By early this year, sell-side analysts were writing about the software sector in language usually reserved for obituaries, one bank analyst describing SaaS as being “sentenced before trial,” a strategist at another floating a “structural decline similar to newspapers,” while software multiples compressed hard enough to erase hundreds of billions in market value inside a week. Whatever pace feels comfortable internally, that is the clock running outside.

The three-move playbook, as a reminder: assess and defend the exposed revenue and cost now, re-engineer the core around AI execution, then reposition the capability as agent-first and sell it. All three are live by this point in the series. This piece is about running them as one transformation instead of three separate kingdoms that happen to share a company. And as with every piece in this series, the worked example is my own function, software product engineering and the business around it, but the loop itself is general: a hospital system, a logistics network, or an insurer runs the same three moves with different nouns.

The playbook: operating the portfolio

Run them in parallel, on three clocks. This is the sequencing discipline carried forward from earlier in the series, and it does not relax once all three moves are underway. Each move keeps its own owner and its own skillset: a revenue-commercial leader on defend, an engineering-transformation leader on re-engineer, a product-and-go-to-market leader on reposition. None of the three waits on another to start or to continue. The invented dependency that costs teams the most is “the product play waits until engineering is transformed.” It sounds disciplined. It is a way of quietly giving up a market window while calling the wait a plan. There are exactly two gates worth respecting, both already carried in this series: context engineering gates throughput inside re-engineer, and inside reposition the gate sits on the market claim itself, not just the product. You do not get to position yourself as the agent-first platform until you have actually run as one internally first. Every other dependency is usually an excuse dressed as caution.

One cadence, one scoreboard. Three independent programs drift into three separate kingdoms unless something holds them together on purpose. That something is a single cross-move sync, on a fixed cadence, and one shared scoreboard that every leader in the room can see at the same time. The scoreboard carries each move’s own metric, at-risk revenue burning down and RPO climbing back up on defend, throughput and the efficiency ratio on re-engineer, readiness and maturity climbing on reposition, and it rolls all three up to the one number a leadership team already tracks and will ask about regardless of how the internal story is told: revenue per dollar spent on the function doing the work. Keep vanity separate from value on that scoreboard the same way each individual move already does. The current era’s favorite vanity number is percentage of code written by AI, and it belongs on the scoreboard only next to cycle time and defect escape rate, where it either becomes a value story or gets exposed. A shared sync that reviews three different sets of vanity metrics is three presentations in one room, not alignment.

Run it as a portfolio of experiments. Inside each move, the work that actually moves the scoreboard is a set of bounded bets, not a single multi-year initiative. Each bet gets a hypothesis, a metric, and kill-or-scale criteria before it starts, not after it disappoints somebody. Run the bets on short cycles, because the tools underneath all three moves are changing fast enough that a quarter-old assumption is often already wrong. Re-baseline on a cadence tighter than most organizations are used to, closer to every couple of sprints than every quarter, and expect that to feel uncomfortably fast, because it is the pace the technology is actually moving at. A bet that clears its criteria graduates. It stops being an experiment and becomes part of the standard operating model, the way the crack team’s proven plays inside re-engineer become the new default rather than a permanent pilot. Agentic products give this discipline its cleanest form, because they force it natively: an agent that starts informational-only and earns each new permission on measured evidence is a kill-or-scale portfolio wearing a product roadmap’s clothes. A bet that fails its criteria gets killed, and the killing has to be visible and named, not quietly archived. An organization that cannot point to something it deliberately stopped doing has been running initiatives that never fail because failure was never defined going in, not experiments.

Close the loop back to the audit. Every pivot inside any of the three moves is new information about where the organization is actually exposed, not just a footnote in that move’s own retro. Feed it back. If a pivot inside re-engineer reveals that context, not raw code generation, was the real constraint, that finding changes what the next pattern audit should go looking for. If the account-by-account scoring inside defend reveals that an entire install base is defensible only after a migration, that finding stops being a renewal problem and becomes product packaging and roadmap work, and the build log below walks through exactly that handoff happening. Part 3 is a loop: each turn’s pivots become an input to the next audit, it does not end the moment reposition ships.

The failure modes. There are four common ways this falls apart. The first is sliding back into a sequence: the parallel launch loses momentum, and running the moves one at a time starts to feel safer than running three programs at once. The second is putting all three moves under one already-overloaded leader because headcount is tight. The third is a fixed multi-year plan with no killed experiments in it. That track record means nobody defined failure before the work started, not that the planning was good. The fourth is reporting vanity metrics, lines of code, tickets closed, feature launches, to a board or investor who is actually asking two simpler questions: is revenue per R&D dollar improving, and are the exposed customers staying.

Figure 1. The operating loop: three parallel tracks feed one shared cadence and scoreboard, work moves through the portfolio of experiments, and every pivot feeds back into the next pattern audit rather than disappearing into a single move’s own retro.

The deliverable is a one-page operating board: the three tracks down the side, the shared scoreboard underneath all of them, and a running experiment log next to it, hypothesis, metric, decision, one row per bet.

Run your own: a blank, instruction-filled version of the board is attached as a download, with the three tracks, the shared scoreboard fields, and an experiment log with kill/scale decision columns built in.

Operating Board Template

9.9KB ∙ XLSX file

Download

Download

The playbook in cards

One concrete way to run all of this: manage the portfolio of bets as a deck of play cards, sixteen plays across the three moves, each card one page in a fixed format, the trigger that fires it, the move, the owner, the metric. A card is a bounded bet with its kill-or-scale criteria written down before it starts, which is the experiment discipline above made physical. The deck is SaaS-centric because that is the function it is proven in; swap the codebase for a claims queue or an engagement backlog and the arc holds. Here are six of the sixteen, compressed to trigger, move, and metric.

Defend

• D1 · Renewal war room. Trigger: at-risk recurring revenue renewing inside twelve months. Move: a cross-functional war room, accounts sequenced by tier then renewal date, one owner and one play per account, weekly cadence to each renewal. Metric: at-risk revenue retained; net revenue retention on the at-risk cohort.

• D4 · Managed decline. Trigger: accounts scored effectively unrecoverable. Move: stop over-investing, manage margin on the way out, and redeploy the capacity to savable accounts. Harvest, do not fight. Metric: capacity redeployed; margin retained on the declining book.

Reposition

• O1 · Make the record agent-addressable. Trigger: capabilities that hold but are not yet exposed as governed tools. Move: expose the system of record and core business logic as governed tools, so customers’ agents connect to you rather than route around you, converting integration depth from a durable defense into a compounding moat. Metric: tool operations exposed; external agent calls.

• O4 · Ship the first revenue agent. Trigger: a buildable agent that sits in the product’s DNA with an outcome-priced path. Move: build and pilot one AI-native, outcome-priced agent on a bounded scope, proving a revenue surface that did not exist a year ago. Price on outcomes, not seats. Metric: the pilot’s outcome metric; new revenue from the surface; pilot-to-paid conversion.

Re-engineer

• E1 · Stand up the crack team on real work. Trigger: no validated proof of AI-augmented delivery. Move: a handpicked team on revenue-relevant work, not a lab, run across a deliberate spread of work types, because AI augmentation differs by type: a mobile feature, a system integration, a new API, and legacy versus greenfield are all different problems. The output is a validated experiment library with before-and-after evidence per work type. Metric: output per engineer, measured per work type, not one blended average.

• E2 · Context-engineer the legacy codebase. Trigger: code output up, throughput flat. Move: build the structured context files, docs, and exposed domain knowledge the AI tools were missing. Context is the unlock, not raw generation. Metric: realized throughput and cycle time; share of the codebase covered by context.

Figure 2. The play deck: sixteen plays across the three moves, six shown at trigger, move, and metric level.

The other ten cards run the same format: RPO extension and re-contracting, re-engaging deep-but-eroding accounts, product tie-ins for eroding features, the shared agent runtime, the data and semantic layer, the tools-registry platform, productization, the AI development lifecycle rollout with its new roles, the people transition, and tracking revenue per R&D dollar over the plan. The full deck, with sequencing, owners, and the evidence behind each play, is part of the toolkit work this series has deliberately kept out of scope. More on that soon.

The build log: running the moves at Aptos

I want to be honest about this the same way I have been about each move on its own: this is mid-flight, not a finished operating system. The structure is the part I would defend most strongly: three parallel workstreams with distinct owners from the start, a monthly cross-workstream sync, a quarterly review that puts all three moves on one page in front of the same room, and a mid-year week-long working session that turned the strategy into an action register, every item with an owner and a date. The pull toward a tidy story, engineering first, then product, then the rest, was real and it was wrong every time we felt it.

Defend: protect the base, buy the runway.

• Turn one was assessment. An external framework rated us resilient, which answers the investor question and nothing else, so we scored every customer and product combination in the recurring-revenue base ourselves in a week-long sprint: independent assessors, no cross-talk, then a leadership calibration pass to argue the outliers and lock the scores.

• Turn two, a quarter later, is execution, where most assessments go to die. The highest-exposure accounts each carry a written retention or migration plan with a named owner, commercial packaging is being built to move an exposed install base onto defensible footing, and a field-enablement motion is equipping the people who own the customer relationships to hold the AI conversation without us in the room.

• The sentence the workstream runs on: defense buys time, it does not change the trajectory. The trajectory belongs to the other two moves; defend buys the runway they burn.

Reposition: from argument to dated portfolio.

• Three products, described here without their names: an outreach agent that engages a retailer’s customers off its own store data, a connector layer that exposes twenty years of domain workflows (transfers, price changes, invoice matching) so any agent, ours or a customer’s, can execute them against the system of record, and a platform on which customers build, run, and govern agents of their own.

• The kills are real, recent, and cheap: the self-hosted platform stack was retired after a three-day proof-of-concept and a cost comparison, and a shared-tenant architecture was ruled out on data isolation grounds even though it was the cheaper build. Evidence, days, decision. The playbook says killed bets have to be visible and named; those are ours.

• The whole path backs into a hard external launch window we do not control, with go/no-go gates and drop-dead dates in between. The first pilots run store-employee facing, the lowest rung of the autonomy ladder from the last piece, and hit a dated gate where they prove their numbers or die.

Re-engineer: from tooling to operating model.

• The crack team graduated, exactly the way the playbook says winners should: no longer an experiment, now a small permanent team of our strongest AI engineers that sets the standard for every pod and takes the frontier projects.

• An AI development lifecycle is being baselined across every engineering team, and the quiet change I think matters most is underway: problem-solving is moving out of meetings and direct messages into open channels AI tools can read, because an agent cannot learn from a conversation it was never in.

• A roles-of-the-future track is defining new job families and asking directly who thrives in this model, and the north star sharpened from a productivity multiple into something starker: production code authored by AI, with humans reviewing, guiding, and architecting.

The credibility move, the one worth naming rather than glossing past, is being willing to say what we pivoted, in public. Two pieces ago I named three: start the product play sooner, fund context engineering before the stall rather than after it, stand up the crack team earlier with more air cover. None were comfortable to write, and that is the point: a team that can tell you what it pivoted, specifically, is running a loop. A team with a clean narrative for every decision is performing one.

Re-baselining is the discipline we are least mature on, and the benchmark plateau shows why it matters. While the curve was near vertical, assumptions went stale because capability kept jumping. Now that it is flat, they go stale the other way: the gains come from context, integration, and workflow redesign, not from waiting on the next model. We are paying for that discipline already, with parts of our coding tool stack on a phased drawdown. The public failures teach the same lesson. The headline reversals were single big bets with no kill criteria set going in. The quiet successes run AI as a loop, not as an initiative with a press release at either end.

The investor lens: reading the operating model

If you are assessing whether a company is actually running its transformation as one program or three disconnected ones, the operating model itself is the tell, more than any individual move’s own metrics.

Parallel or serial, with named owners. Ask to see all three moves on one page, each with a named owner. Three parallel tracks with three real leaders is a team that understands what it is running. A Gantt chart with the moves end to end, or all three routed through one already-overloaded executive, is a team that will lose ground on whatever it deferred, however good that quarter’s story sounds.

One scoreboard, or three sets of vanity metrics. Ask what number rolls all three moves up to something you, as an outside evaluator, can actually compare across companies. If the honest answer is three separate dashboards that do not share a common metric, the organization has not actually unified the transformation, whatever the deck’s cover slide claims.

A portfolio of experiments, or a fixed roadmap. Ask what got killed. A credible operating model can point to specific bets that failed their criteria and were shut down, loudly, with the lesson named. An organization that describes a multi-year plan with a hundred percent survival rate on every initiative either has not been running real experiments or is not telling you about the ones that did not survive.

Do they re-baseline as the tools change, and can they name what they pivoted. This is the single best tell in the whole series, and it holds across all three moves, not just re-engineer. Ask management directly what they would do differently now versus what they said a year ago, and ask specifically what they believed about model capability a year ago that turned out to be wrong. A team with a specific, slightly uncomfortable answer is running a real loop. A team whose answer is that the plan is playing out exactly as designed is either extraordinarily lucky or not being straight with you.

Red flags. A rigid three-year transformation plan presented with no revision history. Zero killed pilots across the entire program. A transformation story whose economics depend on the next model release rather than on work the company controls. A pivot reframed after the fact as “always the plan,” which is the tell that the loop exists on paper for the board and nowhere else in the actual operating rhythm.

The pattern across all four questions is the same one this whole series has pointed at from the first piece: credible transformation work is specific about what did not survive contact with reality. Performed transformation work has a clean answer for everything and evidence for very little of it.

Close: the loop is the playbook

Pull the whole arc together and it reads as one motion, not six separate pieces. The pattern audit told you where you were exposed. The business case funded the response. Defend protected the revenue already in play while the rest of the work got underway. Re-engineer rebuilt how the organization actually produces its core work, on its own longest clock. Reposition turned the rebuilt capability outward into something worth selling rather than only using. And running the moves is the discipline that keeps all of that as one transformation instead of three initiatives that happen to share a logo, closing the loop back into the next pattern audit rather than ending at a launch date.

The companies that win the agentic era are not the ones who drew the cleanest three-year plan at the start, and they will not be the ones who guessed the capability curve right, because nobody is guessing it right. They are the ones who got good at pivoting on evidence, in public if they are honest about it, and kept doing it after the first version of the plan was already wrong.

A closing note

This piece closes Part 3 of the series, the transformation playbook itself. The pattern audit, the business case, and the three moves are the whole operating system, generalized past the software engineering examples I have leaned on for my own worked case throughout. What I build in public from here follows the same rule the whole series has run on: real operating experience first, the framework second, and an honest account of what is still unproven. More on what is next soon.

The ambition almost everyone gets right: AI in the product. Add a copilot, a chat assistant, a summarization feature. It ships fast, it demos well, and inside a year every competitor has shipped the same thing, because a feature built on a foundation model is a feature anyone with the same foundation model can build. Table stakes get you to parity. They do not get you a moat.

Becoming an AI company means building for a world where agents do the work that used to take people, inside your own walls and inside your customers’ walls too. That holds regardless of what you sell: code, insurance coverage, audits, logistics capacity. The compelling version is specific: build agents your customers will actually pay you to use, and expose the infrastructure that lets your customers’ own agents do work through you. That combination, agents customers pay for plus infrastructure customers build on, is what turns AI from a feature into a platform. This piece uses SaaS product engineering as the worked example, because it is the world I build in, but the classify-build-sell arc holds wherever a business has something durable underneath a layer AI is now eating.

The three-move playbook, as a reminder: assess and defend the exposed revenue and cost now, re-engineer the core around AI execution, then reposition the capability as agent-first and sell it. Reposition is move three, the offense, and the one that turns everything the first two moves built into a new revenue line rather than a defended one.

The playbook: becoming the platform

A note on what follows. The examples lean on SaaS, specifically retail SaaS, because that is the product I know well enough to be honest about. The classification lens underneath it is broader than software. A professional-services firm has a client-facing reporting layer that can erode and a proprietary methodology and data set underneath it that does not. A logistics company has a booking interface that can erode and a carrier network and routing engine underneath it that does not. An insurer has a policy-shopping UI that can erode and an underwriting model and claims history underneath it that does not. The question is always the same: does AI absorb the layer you compete on, or does it need the layer you have built.

Classify what you have. Not every product survives the AI shift the same way, and the split runs along one axis: where does the defensibility actually live. Interface-led products, whose value is mostly the view on top of someone else’s data, lose, because an agent reads the underlying data and answers the user directly, no view required. Data-infrastructure products, the governed data and semantic layer other systems and agents need to act on, win, because they become more essential, not less, the more agents there are trying to act. Functional products, a vertical application with its own system of record and workflow built up over years, split: the record and the execution logic hold, because an agent still needs a governed, domain-specific record to act on and cannot cheaply recreate years of accumulated logic, but the screens and workflow configuration erode, because once an agent can drive the record directly, the interface stops being what customers are paying for. Most established software a company has built lives in that third category, and the whole strategic question is which half of it holds. Whatever fully erodes is not a reposition problem, it routes back to Move 1, lock the contract, raise the switching cost, defend it rather than rebuild it.

Build on what holds, in two lanes. Once you know which capabilities hold, there are two distinct ways to capture the upside, and they are not the same product, the same buyer, or the same motion. Lane one is the agents you build yourself, sitting inside the product’s own DNA, a new revenue surface you own and sell on outcomes rather than seats. Lane two is exposing your own business logic and data as governed tools so that other people’s agents, a customer’s own automation, a partner’s platform, can call into you rather than route around you. You cannot conceive of every useful agent a customer might want, and the most valuable ones are often cross-product, so lane two is what keeps you in the value chain on the agents you did not think to build. Many customers already use what you sell as one specialization among several, one system for one part of the job, a different vendor’s tool for another part, and the agents that matter most to them orchestrate across that whole set rather than staying inside any single vendor. A transfer agent in retail is a clean example: it reads sell-through and demand signals from one specialized system, then acts on that read by creating store-to-store transfer orders in your merchandising system. Some of an agent like that is entirely inside your ecosystem. Some of it calls into tools from other services the customer already owns. If your business logic is not exposed as a callable tool, that orchestrating agent routes around you at exactly the step where your record was the one it needed. Both lanes have to converge on one shared piece of infrastructure, an agent runtime, a tools registry, orchestration, observability, and metering, or you end up with scattered point features instead of a platform. The infrastructure is what turns “we shipped an AI feature” into “we are the thing other people’s agents depend on.”

Figure 1. The classification lens, illustrated for SaaS. The underlying question, does AI absorb the layer or need it, applies to any business with a durable record underneath a UI.

Know where you actually sit on the ladder. Most organizations describe themselves as further along than the evidence supports, so it is worth naming the tiers plainly. AI-laggard has no meaningful AI in the product at all. AI-feature has AI bolted onto an otherwise unchanged product, a chat box on top of the same screens. AI-native means the product’s core workflow has been rebuilt around agents doing the work, not just assisting with it. AI-platform means other people’s agents, a customer’s, a partner’s, can run on your infrastructure through governed tools, and you have a business model around that. Most companies, including good ones, are stuck at AI-feature. The platform tier is the moat, because a feature is trivially copyable and a platform other people already depend on is not.

Take the two lanes to market differently. Lane one and lane two sell differently, and treating them as one motion is a common mistake. Lane one sells agents as products: a measurable business outcome the buyer cares about, priced on that outcome or on subscription rather than per seat, proven through a bounded pilot with a small number of real customers before it is sold broadly, to a line-of-business buyer. Lane two sells access: it enables a customer’s own agents to call into your governed tools, priced on usage or a platform fee, sold to a different buyer entirely, the technical and architectural side of the house, and dependent on ecosystem work, documentation, partner tiers, a sandbox, that lane one does not need. The shared infrastructure underneath both lanes is not a third thing you sell. It is what makes either lane sellable at all: without it, lane one is a one-off feature and lane two has nothing to expose. Both lanes depend on the hardest single piece of the whole reposition: turning the people who used to deliver the old product by hand into the people who configure, wire, and tune the agents for a customer. That delivery transformation, not the product work, is usually the long pole, and it is the same forward-deployed-engineer shift the re-engineer move (Piece 19) makes inside the walls, now pointed at customers instead of your own codebase.

Figure 2. Where most organizations actually sit versus where they describe themselves.

Figure 3. The full arc, from classification through the two go-to-market motions, both riding on one shared infrastructure layer.

The deliverable is a one-page reposition plan: your products classified, the two lanes each holding capability maps to, the shared infrastructure checklist, and the go-to-market motion and pricing for each lane.

Run your own: a blank, instruction-filled version of the plan is attached as a download, with the classification, the two lanes, the infrastructure checklist, and the go-to-market columns built in.

Reposition Plan Template

10.2KB ∙ XLSX file

Download

Download

The build log: repositioning at Aptos

Everything above is the general arc. What follows is retail SaaS specifically, because that is the product I run, not because the arc is a retail-only idea. Read it as the worked example, not the definition.

I want to be honest about where this stands. The infrastructure is real and shipping. The go-to-market motion around it is earlier, and some of what I describe here is the plan, not yet the result.

The classification work came out cleaner than I expected once we ran it. Our core products own a governed, vertical-specific record, the certified transaction record, the assortment and allocation logic, the merchandising and CRM data, built up over a long time and specific to fashion and apparel retail in a way a generic system is not. That record holds. The thousands of screens and configurations we built to fit customer workflows over the years is a different story, and once an agent can drive the record directly, that layer stops being the reason a customer stays. I want to be direct about something that would have been uncomfortable to say a year earlier: our front-end, which we would have called dated, stopped being a liability the moment the UI moat disappeared for everyone at once. When a competitor’s polished interface and our plainer one both get replaced by an agent talking to the record underneath, the interface stops being the argument.

The reframe that changed how I think about our own UI debt is one line I picked up from watching how CRM vendors are talking about their own products: once an agent drives the record, the interface reconfigures itself around the task, not the other way around. I did not believe that the first time I heard it. I believe it now, because it describes exactly what happened to our own moat.

On lane one, the clearest example is a customer-outreach agent that identifies a retailer’s high-value customers and sends personalized, store-level outreach automatically, aimed at driving incremental visits to a physical store. It targets a specific, board-legible outcome, not a vague productivity claim, and it is built to progress through stages, starting purely informational and adding capability, a store-visit nudge, a time-limited offer, an in-conversation purchase, as trust in the agent’s judgment grows. That progression matters more than it sounds like it should: selling the whole capability on day one, before either side trusts it, is how pilots die.

On lane two, we are exposing the same governed record as callable tools rather than screens, a runtime, a tools registry, orchestration across multiple agents, observability on every action taken, and metering so a customer can see exactly what an agent cost to run. This is the layer a cross-vendor orchestrating agent, the transfer-agent kind of example from the playbook above, would actually call into: it reads a signal somewhere else and needs our record to act on it, and if that record is not exposed as a tool, we are simply not in the path. The design principle we hold to is that every agent action passes through the same governed layer before it reaches a customer, auth and permissions scoped per tenant, a full trace of what was called and what was changed, cost caps so nothing runs away, and brand or business guardrails so an agent cannot act outside the rules a customer sets. Governed by design, not bolted on after the first incident.

The instinct on lane two was to build the tools first and worry about governance later, ship fast, harden after. We built it the other way, governance as the foundation the tools sit on, and I think that was the right call, though I will not know for certain until an agent does something at scale that a screen never could have, and we find out whether the guardrails actually hold.

Both lanes converge on one shared foundation, and that convergence is the actual platform bet. Point agents without shared infrastructure are just more features. A tools registry, a common orchestration layer, and shared observability across every agent, ours and a customer’s, is what makes the thing compound instead of sprawl.

The go-to-market side is earlier and more honest about it. The two lanes do not sell the same way, and we are treating them as two distinct programs rather than one launch. Lane one, the agents we build, sells to a line-of-business buyer on an outcome, with pilot proof required before broader sale, moving toward outcome-based pricing rather than a flat add-on fee. Lane two, the tools we expose so a customer’s own agents can call in, sells to a technical buyer on the promise of a deepened moat and a metered usage model, and it depends on ecosystem work, developer documentation, a sandbox, partner tiers, that lane one does not need at all. Neither lane sells the shared infrastructure itself, that is what both lanes run on, not a third product. We are running lane one and lane two as genuinely separate workstreams with separate owners, not one program with two features in it.

The hardest workstream I would flag to anyone doing this: turning the people who used to deliver the old product by hand into the people who configure and tune the agents for a customer, agent architecture, tool configuration, model tuning, a real skill shift. It lands differently across three groups. Sales needs product fluency and a new discovery playbook. Support needs to read observability data instead of running a static runbook. Delivery carries the deepest change, from configuring the old product to building on the agent layer for each customer. We treat it as the long pole of the whole program, funded from day one.

The investor lens: reading a reposition claim

If you are assessing whether a company has actually repositioned or is narrating a repositioning, the pattern is consistent across industries.

Is there a platform, or a set of features. Ask for evidence of shared infrastructure, a tools registry, an orchestration layer, observability across every agent, not just a list of AI features shipped this year. A company with five disconnected AI features and no shared layer under them will not compound the way a company with one platform and five agents on top of it will.

Is the pricing outcome-based, or AI bolted onto the old model. Ask specifically how the new capability is priced. Subscription-plus-a-line-item for “AI features” is the old model wearing new packaging. Outcome pricing, or a genuine platform/usage fee for the interoperability layer, is evidence the company actually rebuilt the commercial model, not just the product.

Is external selling gated on internal proof, or is this vapor. Ask what evidence exists that the capability being sold has actually been run, on real work, with a measured result, before it reached a customer. A company that cannot show you that evidence is selling a roadmap, not a product.

Where does the company actually sit on the maturity ladder. Most self-describe as further along than they are. Ask what percentage of the core record is callable as governed tools today, not what the roadmap says it will be. AI-feature dressed up as AI-platform is the single most common overstatement in this category.

Is the delivery transformation funded and staffed, or assumed. Ask who configures the agents for a new customer today, and how many of them there are. A platform strategy with no answer to that question has a product plan and no delivery plan, and the delivery plan is usually the actual constraint on revenue.

The tell across all five, consistent with the rest of this series: a credible reposition is specific about what it has proven and honest about what it has not sold yet. A performed one has a feature list and a story about the future.

Close: feature or platform

AI features get commoditized on a predictable clock, usually inside a year of a capable foundation model becoming generally available, because anyone with access to the same model can ship the same feature. A platform other people’s agents actually depend on does not commoditize the same way, because the switching cost is not the feature, it is everything built on top of the governed layer underneath it. Reposition is the move that decides which one an organization becomes, and it is decided by infrastructure and go-to-market discipline, not by how many AI features made it into this year’s release notes.

Next in Part 3: running the moves. Defend, re-engineer, and reposition are three live programs now, on three different clocks. The closing piece is how you run them as one transformation rather than three disconnected initiatives: the cadence, the shared scoreboard, and the feedback loop that keeps the whole thing honest when a bet does not pay off the way the plan assumed.

The two wrong answers are both popular, and neither is specific to engineering. The first is to lead with the layoff, announce that AI makes the function more efficient, and let a smaller version of the old organization do the same work slightly faster. The second is to roll out an AI tool across whatever the core function is and call the rollout a transformation. Both leave you exactly where you started, an unchanged operating model with a faster typewriter, and both are why so many AI transformations produce a productivity anecdote and nothing that shows up on the P&L a year later.

Re-engineering is neither of those. It is a sequenced rebuild of how the organization’s core work actually gets produced, run in a fixed order because the order is what makes it real rather than theatrical: prove it on live work, systematize what was proven into a new operating model, then bring the organization into the new model deliberately rather than by attrition. That core is whatever the organization actually produces. Software engineering builds code. An insurance operation underwrites policies and adjudicates claims. A professional-services firm delivers engagements. A retailer plans and replenishes. The function differs; the arc does not. Skip a step and you get one of the two wrong answers wearing a transformation’s clothes, in any of them.

The three-move playbook, as a reminder: assess and defend the exposed revenue and cost now, re-engineer the core around AI execution, then reposition the capability as agent-first and sell it. Re-engineering is move two, the longest of the three, and the engine the other two run on.

The playbook: rebuilding the core

A note on what follows. The examples below lean on software product engineering, because that is the function I have run this in myself, prove it, systematize it, bring the people, argued line by line against production code and a real org chart. The arc is not an engineering framework wearing a general label. A claims organization re-engineers claims handling. An underwriting shop re-engineers underwriting. A professional-services firm re-engineers how engagements are scoped and delivered. A merchandising team re-engineers planning and replenishment. Swap “codebase” for “policy file,” “case history,” or “planning cycle” and the four moves below read the same. Software is the worked example because it is the one I can show you honestly, not because the arc stops at the edge of engineering.

Prove it, on work that counts. The rebuild does not start with a framework document. It starts with a small, handpicked team, often called a crack team, pulled from across the function rather than one team, and pointed at real, revenue-relevant work rather than a sandbox. Name the seam early, because it gets confused constantly: the team proving the model is not the team running today’s operation. In software this means it is not the customer-delivery team turning AI loose on client implementations, it is an internal proof engine finding out, on production code, what AI-augmented engineering actually looks like when it ships. In a claims operation the equivalent seam is a proof team working real, closed-loop claims, not the frontline unit still running the current process. The output that matters, in any function, is not a demo. It is a library of proven plays, one per stage of the process, each with a before-and-after and a name someone else can copy. A crack team that cannot point to a shipped, measured result for each entry has not proven anything, however good the readout sounds.

Fund context engineering first, because it is the gate, not the footnote. Every organization that runs this on an existing body of institutional work hits the same wall: output goes up sharply and delivery does not move, because the model can produce plausible work without knowing the years of accumulated decisions sitting underneath it. In software that is a legacy codebase; in insurance it is the policy history and adjudication precedent; in professional services it is the firm’s own prior engagements and house judgment calls. The instinct everywhere is to treat this as a tooling problem and buy a better assistant. It is a context problem, and it is worth being precise about which kind. Context engineering, the term Andrej Karpathy helped popularize, is an active area of research, and most of what has been solved so far is context at the individual level: a well-built context window makes one person’s session with the model dramatically more capable. What almost no organization has solved is context at the institutional scale, the accumulated rules, precedent, and tribal knowledge that live across many people and years, not in any one person’s prompt. That harder, organizational version is the actual gate here, and closing it is plausibly the bigger unlock in this whole shift: it is what would let agents operate with far less human review, because the model finally carries something closer to the institutional memory a senior person holds, instead of needing a human standing beside it to supply that memory case by case. The fix, at whatever scale, is the same shape: commit the missing domain knowledge, the rules, the precedent, the reasons the current pattern exists, into a place the model can actually see it, maintained like any other asset. Fund this line first in the budget. An organization that funds the tool and treats context as an afterthought will get the same flat-throughput result on a longer timeline and a bigger bill.

Systematize it, once the crack team has proven what to systematize. This is where the operating model changes shape, not just the tools inside it, in any function. Working units shrink and there are more of them, because a smaller unit paired with agents can own more surface area than a large one coordinating manually. Roles shift with the units, generally from doing the routine work to directing and reviewing what the agents produce, with the deepest human judgment concentrated on the hardest cases. In software product engineering, where I have run this firsthand, that looks concrete: a pod lead becomes an AI orchestrator, setting the scope and trust boundaries for what the agents are allowed to do and owning the architecture calls. Engineers move from writing most of the code to reviewing and directing what agents produce, spending more of the role on complex logic and judgment. Quality assurance is the most disruptive transition of the four: the role shifts from manual test execution toward an AI-reliability function, building eval suites, watching for drift, setting the guardrails, because the work of running test scripts is exactly the work agents now do faster. Product management, product ownership, and business analysis consolidate into a single orchestrator role, because structured, agent-ready briefs replace a three-person relay of documents. A central enablement function governs the shared pieces across the units: the agent library, the eval and guardrail standards, observability, model choice, context engineering. The specific roles differ elsewhere. An underwriting shop’s analogous shift might be underwriter to underwriting orchestrator and a manual-review role to an AI-exceptions specialist. The pattern, not the job titles, is what travels. None of this is subtle, and the honest version says so before it says otherwise. Say plainly what shrinks, what is new, and run the migration in phases with a hard date rather than a slow drift nobody owns.

Figure 1. The role redesign, illustrated for software product engineering, one row per function. The shift pattern, execution to orchestration, generalizes; the specific titles are this function’s version of it.

Bring the people, and expect it to be genuinely messy. A role redesign on a slide is not a workforce transition. The transition is reskilling and certification against the new roles, and it needs its own instrument, because “are you using the AI tools” is not a useful question once the tools are everywhere. What matters is depth: has this person’s actual practice changed, or are they doing the same job with a faster keyboard. A lightweight adaptation lens, distinct from a training program, tracks that at the pace the technology moves rather than on a quarterly survey, looking at whether someone actively seeks out new capability, how deeply they integrate it into real work, whether they teach what they learn to others, and whether they can name what they have not yet figured out. Score the distribution across the organization, not any one person’s number, and expect the honest starting distribution to sit low. The uncomfortable part, worth saying out loud rather than glossing over, is that the human-to-role mapping does not resolve cleanly. Some people move into the new roles easily. For others, especially in the most disrupted function, there is no obvious next role yet, and pretending otherwise at the kickoff is worse than naming it as an open problem you are actively working.

What the lens is ultimately measuring is best called learnability, not tool proficiency. In practice the population tends to split roughly into thirds. A third become the leaders of the new way of working almost on their own, and pull others along with them. A third will not make it, not for lack of skill but because they will not give up the old way of working long enough to try the new one. The middle third, usually the largest group, can cross over, but only with deliberate help, pairing, coaching, and time, not a training link and a deadline.

One thing about this genuinely surprised me, and it cuts against what past technology disruptions taught me to expect. Age is not the predictor here. I have watched people in their fifties, sixties, and seventies adapt faster and more willingly than people in their thirties. The strongest resistance I have seen sits with engineers who built real professional security on being the specialist, the one who could do the hard technical thing nobody else on the team could do, because AI has leveled exactly that kind of specialization. That group, not the one closest to retirement, is the one struggling the most.

Run one measurement spine under all three tracks. The crack team’s proven plays only count if they were measured, not merely felt, and the new operating model is only provable against a baseline set before it started. The specific numbers are the function’s own, but the shape is constant: a share-of-work-with-real-AI-authorship metric, a cycle-time metric from intake to finished output, a quality or escape-rate metric, a throughput-frequency metric, and output measured as delivered work rather than raw volume produced. In software product engineering that is the share of merged code with real AI authorship, cycle time from idea to production, the bug-escape rate, and deploy frequency. In a claims operation the same spine reads as AI-assisted claims %, cycle time from intake to resolution, the reopened-claim rate, and settlements processed per week. The vanity metric is the one every organization reaches for first because it is the easiest to show a slide about, lines of code, tickets touched, documents reviewed, and it is close to worthless on its own.

Figure 2. The metrics that look like progress against the ones that are, illustrated for software product engineering. The same vanity-versus-value split applies to any function’s version of volume, cycle time, and quality.

Frame the economics as efficiency, not headcount. The number that should move, over the length of the plan, is revenue per dollar spent on the core function, the ratio a PE firm already tracks in its long-range plan for R&D specifically, and the same idea generalizes to any function’s cost line: revenue per dollar of claims-operations spend, per dollar of engagement-delivery spend, whatever the analogous ratio is for the business. As AI lets the same capacity support more revenue, that ratio improves and the function’s cost falls as a share of revenue, without a layoff slide anywhere in the story. This is a genuinely different frame from a cost-cutting narrative, and it is the one that survives scrutiny, because it says the organization got more capable rather than smaller. Keep the model directional here. The mechanics of exactly how much of the ratio’s movement to attribute to AI, and the granular assumptions behind it, are a modeling exercise that belongs in a dedicated readiness assessment, not a public sketch.

The failure modes look similar everywhere. Leading with the cost cut before anything is proven. A big-bang reorg announced before the crack team has shipped anything real, so the org changes shape around a hypothesis instead of evidence. Treating a tool rollout as the whole transformation. And chasing raw volume, lines of code, tickets closed, documents processed, as the scoreboard, which rewards exactly the wrong behavior once agents can generate volume trivially.

Figure 3. The three tracks, run on one measurement spine, with context engineering gating the whole arc.

The deliverable is a one-page re-engineer plan: the three tracks down the side, the measurement spine underneath all of them, and the context-engineering gate marked explicitly as the thing funded first, not last.

Run your own: a blank, instruction-filled version of the plan is attached as a download, with the three tracks, the day-one metrics, and the context-first gate built in as a checklist.

Re Engineer Plan Template

10.6KB ∙ XLSX file

Download

Download

The build log: rebuilding at Aptos

Everything above is the general arc. What follows is software product engineering specifically, because that is the function I run, not because the arc is an engineering-only idea. Read it as the worked example, not the definition.

I want to be honest about where this stands. It is mid-flight, not a finished case study, and some of it is going to look messy in six months in ways I cannot predict yet.

We stood up a dedicated engineering AI crack team, handpicked across the engineering organization, one or two people from nearly every product area rather than a single team pulled aside. The mandate was explicit and a little uncomfortable to say out loud: this team’s job is not to advise the rest of engineering, it is to build the thing the rest of engineering will be asked to follow. We gave it a blunt maturity model with three levels, from simple AI-assisted prompting, through an AI-supercharged developer working with full codebase context, up to the north star, an autonomous AI engineer that takes an epic and carries it end to end, writing its own stories, coding them, testing them, and pushing into the pipeline. The crack team’s mandate was the top level. Everything short of it was a stepping stone, not the destination.

The team ran real projects, not a sandbox. Roughly a dozen and a half production efforts across API rebuilds, integration adapters, transaction-framework work, test-automation migration, and CI/CD modernization, each with a named owner and a two-week reporting cadence, no lengthy decks, just what shipped and what is blocked. The success bar we set was specific on purpose: not zero typing, but every meaningful block of code with an AI origin; no drop in quality; every deliverable actually merged into the standard pipeline and validated automatically rather than “it works on my machine”; and a two-times productivity target as the north star for the first phase, measured, not asserted.

One proof point from that period is worth naming because it is concrete rather than a percentage on a slide. Our QE automation effort migrated its entire automated test suite, over four thousand test cases, onto a new automation platform ahead of a hard internal deadline, saving roughly eighty person-days against the manual estimate. It is one workstream, not the whole organization, but it is the kind of before-and-after entry the proof library is supposed to hold, a number someone else on the team can actually check.

The probe from the pattern audit is what told us where the real constraint sat, and it shaped how we funded the rebuild. Lines of code went up three to four times on our large existing codebases while pull-request throughput stayed roughly flat, and the gap traced back to context, not the tool. That finding is the reason context engineering is funded as the first line in our rebuild budget rather than the thing we get to eventually. It is also the reason greenfield and legacy work are treated as genuinely different problems inside the same transformation, because they are.

The role redesign is drafted, not landed. We have mapped the target roles, the pod lead becoming an AI orchestrator, the AI-reliability role taking shape out of quality assurance, a single product-orchestrator role absorbing what used to be three separate functions, and a central enablement pod governing the shared standards across all of it. What the draft does not pretend to have solved is the human-to-role mapping. Some people move cleanly into the new roles. For others, particularly in the function absorbing the most disruption, there is no obvious seat yet, and I would rather say that plainly than paper over it with a reassuring org chart.

The honest version of a role redesign is the one that admits it is going to get uncomfortable before it gets better. The easy version of this slide shows every box filled and every person mapped to a new title. The real version, the one worth sharing, is the draft with a few boxes still open and a plan for how those conversations happen, not just that they will.

On the people side, we are working from a lightweight adaptation lens rather than a training curriculum, built on the idea that what matters is not whether someone has touched an AI tool but whether their actual working practice has changed. It borrows its shape from learning-agility research used elsewhere for a different purpose, leadership potential, retooled here to ask a narrower, more useful question: is this person changing what they do as the tools around them change. It is scored across a handful of dimensions, weighted toward how deeply someone applies what they learn rather than how curious they are about it, assessed through short structured conversations rather than a survey, and it is explicitly a distribution to watch across the organization, not a scorecard for any one person. The real launch event for something like this is not a communications email. It is the session where managers learn to ask “show me how your work has changed” instead of “are you using the tool,” because the first is a coaching conversation and the second is a compliance question that teaches people to say yes.

Zooming out, the case we are making internally is efficiency, not headcount, and that distinction is not just messaging. Two companies have become the public cautionary tale for getting this backwards, cutting service or support staff on the strength of early AI gains and then quietly rehiring once quality slipped. The companies pointed to as doing it well are not the ones with the loudest layoff headline. They are the ones known for making AI tooling a default expectation of how engineering works, without leading the story with a smaller org chart. We are deliberately telling the efficiency story, revenue per R&D dollar improving as the same engineering capacity supports more of the business, because it is both the more honest framing of what is actually happening and, I think, the more durable one if the organization has to explain itself in eighteen months.

The investor lens: reading a re-engineering effort

If you are assessing whether a re-engineering claim is real, the pattern that separates credible from performed is consistent.

Is there a crack team on real work, or a center of excellence writing decks. Ask what shipped, to production, in the last quarter, and who owns it. A team that can only describe pilots and frameworks has not started the prove-it phase, whatever the deck says about transformation.

Is context engineering funded, or is it the footnote. Ask directly what share of the AI budget goes to making the codebase legible to the tools, versus licenses and compute. An organization that cannot answer, or answers with a number close to zero, will hit the same flat-throughput wall this piece describes, on their timeline instead of yours.

Has the operating model actually changed, or just the tooling. Look for evidence of redesigned working units and roles, not a copilot license rolled out across the same org chart. Ask specifically what the function’s highest-volume production or quality role looks like now versus eighteen months ago, quality assurance in software, claims adjudication in insurance, document review in professional services, whatever the function’s equivalent is. If the answer is “the same team, using a new tool,” the systematize phase has not happened.

Is the people transition managed, or is it a layoff wearing a transformation’s language. Ask about the distribution of adoption across the organization, not a highlight reel of one enthusiastic team. A credible transition names which roles are hardest to remap and says what it is doing about them. A transition that shows only its best case is hiding its hardest one.

Is the scoreboard throughput and function-level efficiency, or raw volume. A team that leads with a volume statistic, lines of code, tickets closed, documents processed, either does not know the difference or is hoping you don’t. Ask for cycle time, output frequency, and the trend in revenue per dollar spent on the function. Those are the numbers that survive a second question.

The tell across all five is the same one that shows up everywhere in this series: a credible re-engineering effort is specific about what it has not solved yet. A performed one has an answer for everything and evidence for very little of it.

Close: rebuild the engine, do not just cut its cost

The order matters more than any individual tactic here, in any function. Prove it before you redesign it. Redesign it before you ask the whole organization to work differently. Fund the context work before the tooling, because the tooling alone will not move the number that matters. Lead with any of this in the wrong order and you get a smaller version of the old organization, dressed as a transformation. Get the order right and the output is a genuine rebuild, measured the way efficiency is already measured, revenue climbing against the cost of the function that produced it, whether that function writes code, underwrites policies, or delivers engagements.

Re-engineering is the longest of the three moves because it is the one that changes how the organization actually works, not just what it is exposed to or what it sells. Everything defend bought time for gets spent here.

Next in Part 3: reposition, agent-first. A re-engineered organization can build things it could not build before. The next piece is about turning that new capability outward, into a platform other people’s agents run on, and what it takes to sell that rather than just use it.

Here is the trap. The audit flagged a set of revenue lines as exposed: products and accounts where AI can now do enough of the work that a customer could credibly switch, or pay you less. The natural reaction is relief that it has not happened yet. “Our relationships are strong, nobody is leaving this year.” That is passive defense, and it is how you find out too late. Active defense assumes an AI-native competitor is about to offer the same outcome for a fraction of the price, and it moves first, while the revenue is still yours and the renewal is still months away.

This piece is the first of three on the moves themselves, one each for defend, re-engineer, and reposition. They run in parallel, on three different clocks, but defend starts today because its clock is the soonest. The exposed revenue is not lost. It is in play. Defense is the program that decides whether you keep it.

The three-move playbook, as a reminder: assess and defend the exposed revenue and cost now, re-engineer the core around AI execution, then reposition the capability as agent-first and sell it. Defend is move one, and the only one whose deadline is set by your customers’ contracts rather than your own plan.

The playbook: defending exposed revenue

Defense is not one motion. It is two, run at the same time. The audit handed you the exposed accounts. Sort them by renewal date and risk tier, then run two tracks against them: a Renewal War Room that works the commercial clock, and a product or service tie-in that raises the structural cost of leaving. The first buys time on the nearest renewals. The second makes the next ones harder to lose.

Set up the board. Take the exposed accounts from the audit and add two columns: the renewal or decision date, and the risk tier. The aging of your at-risk revenue, not its total, is the operational artifact. Then split the work by lead time. Priority one is this year’s high-risk renewals, the critical and at-risk accounts coming up for decision now. Priority two is the wave twelve to twenty-four months out, which you activate now rather than later, because the moves that actually hold those accounts take a year or more to land.

Track one: the Renewal War Room. This is the commercial motion on the near clock. Work the priority-one accounts first, and give every one of them a concrete offer instead of a plea. The standard moves: short-term extensions, three, six, or twelve months, to hold a departing account while you fix the underlying exposure; a tiered set of “paths to stay” built per risk tier, so the conversation is about which option rather than whether; and AI-assisted re-engagement on the accounts that are quietly shopping. Pricing belongs in this room too. Where AI has collapsed the effort behind an hourly or per-seat line, the war room is where you move the exposed accounts to fixed or outcome-based pricing before a competitor forces the question. And the priority-two war room runs in parallel, because a renewal eighteen months out that needs deeper adoption to survive has to be worked eighteen months out. The way to score the room is RPO, the remaining performance obligation, the contracted revenue still ahead of you. Set an RPO baseline on the exposed cohort as the program starts, and track it climbing as accounts are secured, extended, and re-priced.

Track two: the product or service tie-in. This is the structural motion, and it is the half most teams skip. The goal is to make leaving expensive and staying rewarding, with the AI roadmap as the reason. For a software company the tie-ins are concrete: bundle products so the relationship is broader than the one exposed line; drive deeper API and interoperability adoption so the customer’s workflow runs through you; offer early access to the AI roadmap, the agent program, as a retention lever; and deepen data sharing so the switching cost climbs with every month of accumulated history. The framework is broader than software, and the tie-in takes other shapes. A services firm ties in by embedding its people and its AI tooling inside the client’s operations, or co-building a capability the client comes to depend on. A product or hardware company ties in through consumables, connected-data services, and the ecosystem around the core. The principle holds everywhere: deepen the relationship with something AI-enabled and sticky, so the exposed line stops being a standalone thing a customer can swap out.

Figure 1. The two tracks of defense: the Renewal War Room and the product/service tie-in.

Avoid the two scoring errors. Once you have ranked the exposed revenue, there are two symmetrical ways to get the defense wrong. The false negative is “they are not going anywhere,” which under-defends an account that is quietly shopping. The false positive is “they will leave anyway,” which abandons an account you could actually keep. Both got more dangerous the moment AI gave you new re-engagement tools, because the cost of acting fell and the cost of doing nothing rose. Re-test both assumptions against the renewal clock, not against the relationship you remember.

Measure the burndown, scoped to the cohort. The defense scoreboard has two readings that move in opposite directions: the at-risk revenue burning down, and RPO climbing back up. Set the RPO baseline on the exposed cohort as the program starts and track its trajectory as accounts are secured, extended, and re-priced. Scope both numbers to the at-risk cohort specifically, not the whole book, or a healthy base will hide the erosion you were supposed to be fixing.

The deliverable is a one-page defend plan: the exposed accounts down the side, and for each, its renewal date, its risk tier, its war-room move, its tie-in move, its owner, and its metric. Two tracks on one page, and the nearest deadline in the whole transformation.

Figure 2. The defend flow: one prioritized list feeds two parallel tracks, scored by at-risk revenue down and RPO up.

Run your own: a blank, instruction-filled version of the plan is attached as a download, with the two-track moves as dropdowns and an RPO baseline tracker built in.

Defend Plan Template

13.1KB ∙ XLSX file

Download

Download

The build log: how we run defense at Aptos

We run defense as exactly these two tracks, and I want to be honest that it is mid-flight, not a closed case. We call them the Renewal War Room and the Product Strategy, and they run side by side off the same prioritized list of exposed accounts.

The war room is organized by lead time, and that is the part worth copying. Priority one is the current year’s high-risk renewals, the accounts flagged as leaving or critical. For those we work the commercial levers: short-term extensions of three, six, or twelve months to hold a departing account while we address the real exposure, and a tiered set of options per risk tier so every account has a concrete path to stay. Contract-term extension, pushing renewals from one and two years toward three and five on the accounts worth holding, is the least glamorous lever and the one the people who price the business care about most, because it strengthens the contracted base, not just the single account. Priority two is next year’s renewals, and the discipline we hold is to activate that war room now, because the moves that keep those accounts need twelve months or more of runway. Pricing-model change belongs in this room and is a lever I would add. We have not pulled it yet at Aptos, so I am flagging it as a recommendation, not a result.

The product tie-in is the structural track. We bundle products so the relationship is wider than any one exposed module; we drive deeper API and interoperability adoption so the customer’s operation runs through us; we use early access to the AI roadmap, the concierge agent program, as an explicit retention lever; and we deepen data sharing so the switching cost rises the longer a customer stays. The API depth is the one I would underline, because the switching cost it creates is budgetary, not just technical. The more of a retailer’s operational process runs through our integrations, the harder it is to leave, and detangling is itself a software project the customer would have to fund. Our customers, unlike us, do not carry spare software capacity for that work. Most retailers run fixed IT budgets set a year or more in advance, so “rip out the vendor we are wired into” is not a line item they can conjure mid-year. None of these moves is a discount. Each one makes the next renewal a harder decision to walk away from.

One move sits at the edge of defense, and it is worth naming because it bridges into the next piece. Our integration work is a large services line that exists because connecting software is hard, the exact work AI is about to make cheap, so we are building the AI that shrinks our own line on purpose, to keep the customer when the line collapses rather than hand the relationship to whoever disrupts it for us. That is where defend hands off to reposition, two moves from now.

The investor lens: reading the defense

If you are assessing a company’s exposure, the defend program tells you whether management is actually managing the risk or narrating around it.

Is there a program, with an owner and a cohort. A real defense has a named owner and an explicit at-risk cohort with renewal dates. A company that waves at “strong relationships” and cannot show you the exposed accounts by renewal date has not started, whatever the retention number on the last board slide says.

Two tracks, or just discounts. A credible defense runs both a renewal war room and a product or service tie-in. A company whose only answer is short-term extensions and price concessions is buying time it will have to buy again next year, because it is not raising the cost of leaving. Ask what they are doing structurally to make the next renewal harder to walk away from.

Are they working the next wave early. Ask what they are doing about the renewals twelve to twenty-four months out, not just this quarter’s. The tie-in moves that hold those accounts take a year or more to land, so a team only fighting the current fires is already late on next year’s book.

Is the metric scoped honestly. Ask for retention and contracted-revenue trends on the at-risk cohort specifically, not the whole book. A healthy overall base routinely hides erosion in the exposed segment. If they can only show you the blended number, they are either not measuring the right thing or not showing you the part that hurts.

Are they re-pricing, or defending an old model. Where AI has collapsed the effort behind an hourly or per-seat line, ask what they are doing about the price. A company rebuilding the product but leaving the exposed pricing untouched has done half the defense and capped its own upside.

The pattern across all five: credible defense is specific, cohorted, two-tracked, and a little uncomfortable. Performed defense is a blended retention number and a sentence about relationships.

Why defense is a program, not a posture

The exposed revenue is not lost. It is in play, on a clock your customers set, and the only question is whether you treat it as a program with a deadline or a reassurance you repeat until a renewal goes the other way. The companies that keep their exposed revenue are not the ones with the warmest relationships. They are the ones who sorted it by renewal date, assigned every line a play, and were willing to disrupt their own most comfortable revenue before someone else did it for them.

Defense buys you the one thing the rest of the transformation needs: time. What you do with that time is the next move.

Next in Part 3: re-engineer the core. Defending revenue buys the room to rebuild how you build. Re-engineering is the longest of the three moves and the engine of the whole transformation, and it is where “we will be more efficient” either becomes a new operating model or stays a slide. We will get specific: the crack team, the new roles, and the trap that stalls most engineering transformations.

The wrong kind leads with engineering productivity. A slide that says the team will be twenty percent faster, or that AI will write half the code. It feels like progress. It dies in the CFO’s office, and it deserves to, because a productivity percentage is not money. A CFO has watched a decade of tooling promise productivity and has learned the hard lesson: faster does not show up on the P&L unless the cost comes out or the revenue goes up. Capacity you free and then refill is not a saving. It is the same headcount doing more of the same work.

The business case that gets funded is a different document. It is a risk-weighted bet on three pools of dollars: the revenue you keep, the cost you remove, and the revenue you create. Productivity is an input to those numbers, never the number itself. This piece is how you build it, including the part where you bring no productivity slide at all.

The three-move playbook, as a reminder: assess and defend the exposed revenue and cost now, re-engineer the core around AI execution, then reposition the capability as agent-first and sell it. The business case is what turns the audit into the money to run all three.

The playbook: building the number

You already have the inputs. The audit page tells you which lines are exposed, and the probe told you what today’s tools can actually do against them. Now you convert that into three pools of value, risk-weight each with the evidence you already gathered, set it against a clearly itemized ask, and put it on one page. Block a few days.

A note on the examples below. They come from software, because that is the world I built in. The three pools hold in any industry. Only the specifics change.

Pool one, revenue defended (AI sustains the line). For every revenue line the audit marked exposed, the value of acting is the revenue you lose if you do nothing. Not a vision of upside, the avoided loss. Take an analytics product an AI-native rival is starting to undercut: the move is to embed your own AI so the customer has no reason to switch, and the value is the revenue that walks if you do not. Or take a service line like integrations, which exists because connecting software is hard, exactly the work AI is about to make cheap: building that AI yourself is worth most of the line, because a competitor captures it otherwise. Draw the erosion curve from how fast that revenue renews, risk-weight it, and you have the first pool. It is usually the largest and most defensible number in the case, because it sits on revenue you already book.

Pool two, cost removed (AI takes out the work). For every cost-exposed function, the value is the cost AI genuinely takes out. This is the pool people inflate, so build it honestly. The cost comes out in more forms than headcount. Rethinking QA so AI-powered testing replaces a manual effort. Retiring a software license you no longer need because the capability you built with AI now does the job. Ending a long-running consulting or managed-services engagement because an agent covers the work it used to take a team to deliver. Each of those is real cost, but only if you actually stop paying for the thing. A function that costs ten units a year and is sixty percent automatable does not save you six. It saves what is left after you reinvest in the tooling, the oversight, and the model run-cost, and after you actually remove or redeploy the freed capacity. Freed time that stays on the payroll doing the same work changes nothing on the P&L. Count only the cost you will truly take out or convert into revenue.

Pool three, revenue created (AI becomes the product). For the capabilities you decide to reposition, the new revenue you can sell. The AI you built to cut your own cost that customers want for themselves, a QA agent that becomes a testing product they pay for. The service you re-engineer and sell agent-first, priced on the outcome rather than the hour. The agentic positioning play, opening your platform so customers build their own agents on top of it and metering what they consume, a usage-based revenue line that did not exist before agents. This pool is smaller, lands later, and carries the most uncertainty, so it sits last and takes the heaviest discount. Include it, because it is the only pool with real upside. Never lean the case on it.

Risk-weight with the probe, not optimism. Each pool is discounted by how confident the probe made you. A pool sitting on a mature pattern you proved on your own work in Piece 16 takes a light haircut. A pool sitting on an emerging pattern takes a heavy one. The confidence has to come from evidence you generated, not a vendor’s benchmark. A CFO can argue with your optimism. It is much harder to argue with “we ran it on our own work and here is what happened.”

The ask, itemized. A benefit number is only half a business case. The other half is the request: I need this much money, made of these specific things, to capture that benefit. Itemize it, because an unbroken number gets cut and an itemized one gets negotiated. An AI transformation ask has four constituents, and the one people underfund is usually the one that decides whether the whole thing works.

• Talent, the AI crack team. A small, senior team with the mandate and the air cover to set the standard and pull the rest of the organization along.

• Platform, tooling, and compute. The agent infrastructure, the tool and model licenses, and the inference run-cost, which is a recurring line and not a one-time buy.

• Data and context engineering. The work of making your own domain legible to AI: the patterns, the legacy decisions, the institutional knowledge committed somewhere a model can reach. The probe in Piece 16 showed this is the binding constraint, which makes it the line you fund first, not the footnote you fund last.

• Change management and enablement. Adoption, process redesign, and governance, because a capability nobody trusts or uses returns nothing.

Invest $35MM to protect and create $127MM of risk-weighted value, phased so the first wins fund the rest. That sentence is the business case. Everything else is the evidence behind the two numbers.

Always measure against do-nothing. Neither number means anything against zero. The good news is that the cost of inaction is already in the benefit table. The $100MM of revenue defended is exactly what erodes if you act on none of it, which is why it sits there as a gross figure to protect rather than a gain to chase. On top of that sits one cost the table does not try to quantify: for a public or sponsor-backed company, the multiple compression that follows once the market decides you are exposed. Naming the do-nothing cost, the exposed revenue plus that compression, is often the most persuasive figure in the room, because it reframes the $35MM from discretionary spend to defensive necessity.

Phase it so the first wins fund the rest. The audit already found the cells where a mature pattern meets exposed money. Those ship first, return early, and fund the slower, harder phases. In the same illustrative numbers:

Phase one asks for $15MM and returns $40MM, which funds the $20MM of phase two without a second trip to the board. An ask for the whole $35MM up front loses. An ask where phase one visibly pays for phase two wins the room.

Re-engineer the price, not only the product. Where a revenue line is exposed, the case has to include the financial rebuild, not just the technical one. If AI collapses the effort behind something you sell by the hour or the seat, the pricing model that revenue rides on is exposed too. Integration is the clean example. You billed it time-and-materials because it took a team weeks, so when an agent does it in an afternoon, the hourly model that revenue rode on collapses with the effort. The move is to re-price before a competitor forces it: charge a fixed price per integration, or price on the outcome it delivers, turning a shrinking hourly line into a productized one that can actually grow.

The deliverable is a short set of tables on one page, the benefit, the ask, and the phasing, measured against do-nothing.

Figure 1. The case on one page: three risk-weighted benefit pools, the itemized ask, the headline, and the phasing that self-funds.

Run your own: the editable model behind this figure is attached as a download, with the benefit pools, the ask, the phasing, and a reconciliation check built in.

Ai Business Case Model Template

9.85KB ∙ XLSX file

Download

Download

From experience: what makes an AI case different

I have built a lot of business cases over a thirty-year career, across telecom, retail, insurance, and services, on three continents. Most of them rhyme. The AI case breaks the pattern in a few specific places, and those places are exactly where the weak ones fail. I have not yet taken an AI transformation case all the way through a board, so take this as the shape I would insist on, drawn from the cases I have built and the AI audit work I have run, not a victory lap.

The five differences, at a glance:

The AI case differenceThe instinct it breaksWhat the case must doLead with defense”We will be more productive”Headline the revenue you defend; productivity is an input, not the numberNet the recurring AI costAutomation is one-time capexSubtract ongoing inference and context cost from every cost-takeoutFund context firstTools are the big line itemMake data and context engineering the largest, earliest line; it gates everythingWeight with your own evidenceTrust the vendor benchmarkDiscount each pool by what your own probe actually provedRe-engineer the priceRebuild the product, keep the pricingRe-price exposed lines, fixed or outcome-based, before a competitor forces it

Figure 2. The five differences of an AI business case

The first difference is that the headline is defense, not productivity, and AI itself is the reason. The instinct on an AI case is to lead with engineering speed, because that is the visible thing, the team writes more code. When we ran the audit at Aptos, the probe undercut that instinct hard: lines of code were up three to four times while pull-request throughput stayed flat. Anyone who had led with a productivity percentage would have been wrong in a way a good CFO finds in one question. The honest lead is the revenue you defend.

The second difference is that the cost pool carries a real, recurring reinvestment line that older cases did not. Traditional automation was mostly capital you spent once and depreciated. AI carries ongoing inference run-cost and a context-engineering cost that does not go away. A cost-takeout number that ignores them is fiction. The Aptos integration result, work that took senior engineers weeks coming back in under two hours, was real and large, and the honest version of it still nets out the run-cost and the oversight before it reaches the case.

The third difference, and the one that surprises people, is that the biggest line in the ask is often not the tools. It is the data and context work. The Aptos probe was blunt: greenfield flew, the legacy core stalled, and the gap was entirely how much domain context the model could see. That makes context engineering the thing you fund first. Most AI cases bury it as a footnote and then wonder why the pilot never generalized.

The fourth difference is that the benefit has to be risk-weighted by evidence you generate yourself, because AI capability moves month to month and every vendor benchmark is unfalsifiable marketing. The probe is the source of the weights. That is the entire reason the audit runs a probe before the case gets built.

The last is pricing. AI collapses the effort behind work you sell, which exposes the financial model alongside the product. A case that rebuilds the product but leaves seat-based pricing untouched has done half the job. The sharpest version is a service like integration: the moment you can do in two hours what you billed weeks for, the old way of charging for it is gone, and the case has to say what replaces it.

The pattern under all five is the same. A good AI business case is honest about what AI does today, not what the demo implied. Every place these cases fail is a place where someone substituted a vendor’s promise for evidence they could have generated themselves in two weeks.

The investor lens: reading a transformation business case

If you are assessing a company’s transformation, the business case is where you find out whether they understand their own situation. Read it for shape before you read it for numbers.

A productivity headline is a red flag. If the lead number is “X percent engineering productivity” or “half our code is AI-written,” the team is selling activity, not money. Ask where the dollars are. A credible case leads with defended revenue, cost actually removed, and new revenue, in that order.

Make them show the evidence behind the weights. Every value pool should be discounted, and the discount should trace back to something they ran, not a vendor benchmark. Ask what they probed and what it showed. If the confidence comes from a demo, the number is optimism wearing a spreadsheet.

Look for the do-nothing baseline. A case built against zero is a sales pitch. A case built against the cost of inaction, the erosion and the multiple risk, is from a team that has looked at the threat honestly. The absence of a do-nothing number tells you they have not.

Check for a self-funding phase plan. A big-bang ask is a team that has not found its fast win. A phased case where the first move returns early and funds the rest is a team that has actually read its own audit.

Read the ask, not just the benefit. A credible case itemizes what the money buys: talent, platform and compute, data and context engineering, change management. The tell is whether data and context work is funded up front or buried as a footnote. A team that puts most of its money into tools and treats context as an afterthought has not yet learned what gates AI value on a real codebase, and their number will slip.

See whether they re-priced the exposed revenue. A case that rebuilds the product but leaves the old pricing model untouched has done half the work. Where AI collapses the effort behind what they sell, the price has to move too. If it does not appear, the upside is capped and they may not know it.

Why the number matters

The business case is the moment a transformation stops being a vision and becomes a capital-allocation decision. It is also the moment the organization finds out whether its AI ambition can survive contact with a CFO. The cases that survive are the ones built on money that is already on the books: the revenue you would lose, the cost you will truly remove, and a modest, honest bet on revenue you can create.

Bring the productivity slide and you are asking for faith. Bring the three pools, weighted by what you proved and measured against the cost of standing still, and you are asking for a decision. CFOs fund decisions.

Next in Part 3: the three moves themselves, one piece each. You have the page and the funded number. Defend, re-engineer, and reposition are three parallel programs on three different clocks, not a relay race, and the next three pieces take each one in turn. We start with defend, protecting the revenue AI is about to put in play before a competitor does the math for you.

Be clear about what this is not. It is not another pattern map. A pattern map tells you where AI hits an industry in general. An audit tells you, inside your own company, against your own revenue and cost, what to defend, what to rebuild, and what to do first. The pattern map is analysis. The audit is a procedure, with people in a room, data on the table, and a one-page artifact at the end.

Most transformation programs skip it. They open with a vision slide, a maturity curve, and a roadmap with quarters across the bottom. It looks like a plan. It is a wish, because none of it is anchored to the one thing that decides whether AI changes the business or just decorates it: where, today, a human is still the load-bearing part of the work, and how much money sits on top of them. Run the audit and the rest of Part 3, the business case, the sequencing, the staffing, falls out of it almost mechanically. Skip it and you will fund pilots that demo well and move nothing on the P&L.

What follows is how to run the audit in two weeks, what you walk out with, and how it actually went when we ran it.

The three-move playbook, as a reminder: assess and defend the exposed revenue and cost now, re-engineer the core around AI execution, then reposition the capability as agent-first and sell it. The audit is what tells you where to point all three.

The playbook: running the audit

Block two weeks. Put the right people in the room: someone who owns the revenue numbers, the leaders who own the functions under the microscope, and one person fluent in the eight patterns to do the tagging. You are not running a workshop. You are producing one page.

Step one, start with the money, both sides of it. Pull two lists the way finance already reports them. First, the revenue pools, the products and service lines you sell. For each, score how completely AI erodes the value, how hard it is for a customer or competitor to route around you, and the revenue at stake. A revenue pool in the red is a survival problem. To keep it you re-engineer on two fronts at once, the technology and the financial model, which can mean moving from per-seat licenses to outcome-based pricing. The aggressive version is to disrupt your own revenue with AI before a competitor does it to you. Second, the cost pools, the big places you spend to operate. For each, ask how much AI can take out and the cost at stake. A cost pool in the red is a margin opportunity rather than a threat, and now and then the capability you build to cut your own cost turns out to be something customers will pay for. Day one gives you two ranked lists, the revenue you must defend and the cost you can attack. That is your priority order, and you have already done more than most programs manage in a quarter.

Step two, drill into the red, and only the red. Take the top pools, revenue and cost both, and break each into the functions that produce them. Tag every function twice. First, its pattern from the eight, and next to it the note people skip: how mature the autonomous capability for that pattern is right now. Second, keep the revenue-or-cost label on it, because the two drive different moves. Revenue exposure drives defend and re-engineer, the technical and financial rebuild together, and sometimes reposition, when you decide to sell the disruption rather than absorb it. Cost exposure drives re-engineer for margin, and occasionally a new product, when the capability proves valuable outside the building. This is a magnifying glass on the exposed money, not a company-wide census.

Step three, probe before you predict. This is the step most plans skip, and the one that earns the audit its credibility. Do not score a function as “AI can do this today” from a desk. For the cells that matter, especially on the execution side, run a short, bounded, hands-on test: point today’s actual tools at your actual work and see how far they get. A scoring sheet is a guess. A probe is evidence, and evidence is what lets you make a prediction you can defend later in front of a CFO. You cannot honestly forecast the return on a capability you have not tried in your own environment. The probe comes before the money, not after it.

The deliverable, one page, three tiers. Collapse everything onto a single sheet. Functions down the side. Across the top: the three scores, the pattern and its maturity, the revenue-or-cost tag, and a tier. Three tiers only. Now, exposed money on a mature pattern you can act on today, both your threats to defend and your fastest wins. Emerging, the exposure is real but the pattern is not mature enough to run autonomously yet, so the move is groundwork now and autonomy as it catches up. Augmenting, AI assists but the judgment stays human. If it does not fit on one page, you have not made the hard calls.

A stripped-down version looks like this:

Read it in one pass. The “Now” rows are where exposed money sits on a pattern that is already solved, and those are where you start.

Run your own: a blank, instruction-filled version of this sheet is attached as a download. It carries the scoring axes, the dropdowns, and a live tier summary, enough to run a real audit on a Monday

Pattern Audit Worksheet Template

12.1KB ∙ XLSX file

Download

Download

The page is the audit. Everything after this in Part 3 is execution against it, and the very next step, turning that page into a number a CFO will sign, is the business case.

The build log: how we ran it

We ran this at Aptos. I want to be precise about the mechanics, because the sanitized version teaches nothing.

It did not start as a tidy procedure. It started because the market forced it. SaaS multiples were compressing hard, and the question from CIOs had flipped from “what features are coming” to “do I still need all this professional-services spend, and is your platform agent-ready.” We could not answer with a slide, so we pointed a small team at the money, both sides of it. On the revenue side we classified every product and service line low, medium, or high exposure: how substitutable it was by AI, how defensible it was, and the dollars on it. On the cost side we asked a different question, where AI could take real cost out, and we deliberately limited that lens to two areas we controlled and understood, product engineering and professional services, rather than pretending to audit the whole company’s cost base.

The revenue side led somewhere uncomfortable, to disrupting ourselves on purpose. Integration work is a large professional-services revenue line, and it exists mostly because connecting the software is hard. AI is good at exactly that. The honest read was that this revenue is going to be compressed no matter what we do, and the only real choice is whether we do it or a competitor does it to us and takes the customer relationship with it. Moreover, simplifying and reducing costs in this area with AI was the right thing to do in creating value for our customers. So we chose to build the AI that collapses our own integration work, knowing it shrinks a line we bill for today, because the financial re-engineering, finding the next thing to charge for, is less painful than the alternative.

The hardest part was not the analysis. It was resisting our own scores. It is easy to mark a competitor’s product as exposed. It is uncomfortable to put “high substitution potential” next to a line that books real revenue today, and the entire organizational instinct is to find a reason it should be yellow. The honest audit is the one where your own core revenue shows up red. The discipline is refusing to argue it back down.

The cost side produced a surprise. Quality assurance was an obvious place to drive cost down with AI, and we did. What we did not expect was that our customers wanted the same thing for their own testing. The AI-powered QA we built to cut our own cost has become, in early form, a product they can use to test their own configurations. That is the crossover worth watching: a capability built for margin on the cost side can turn into revenue on the outside. It is early days for this one, and it does not happen often, but it is exactly the upside a pure cost-cutting lens never thinks to look for.

Then came the part the org-chart version of an audit always omits. Before we built any business case, before we asked anyone for money, we tried to prove it would work. Not on slides. We pointed the actual AI tools at our actual code to see how far they could get with what exists today, because you cannot forecast a return on a capability you have only read about. On the integration line we had just decided to disrupt, the probe was blunt and convincing: work that took senior engineers weeks came back, end to end, in under two hours. The probe was the audit. The scoring sheet was just where we wrote down what the probe taught us.

It produced the finding I would attach a warning label to. The naive prediction was “AI writes code, so we are faster.” What the probe actually showed was messier. On our large existing codebases, lines of code went up three to four times while velocity and pull-request throughput stayed roughly flat. Code quantity is not code value. The binding constraint was never the tool. It was how much context about our own domain, our legacy patterns, our architectural decisions, the model could actually see. Greenfield work flew. Legacy work stalled until we started committing the missing domain knowledge into the codebase itself.

That gap between the demo and the codebase is where most transformation budgets quietly die. The greenfield pilot looks spectacular, someone extrapolates a company-wide number from it, and then the same approach hits a twenty-year-old codebase and stalls. Probing before predicting is the only thing that catches this in time. An execution audit that skips the probe is optimism with a spreadsheet.

This is why the audit is a phase, not a meeting. The revenue and cost lenses told us where we were genuinely exposed and where the margin was hiding. The probe told us, honestly, how far today’s tools could actually take us against both. Only with all of it in hand could we make a prediction worth funding, and that prediction is the raw material for the next piece, the business case.

The investor lens: reading someone else’s audit

If you sit on the other side of the table, as an operating partner, a diligence lead, or a board member, the audit is one of the highest-signal artifacts you can demand. Most companies cannot produce one. That absence is itself the finding.

Ask for the page, not the deck. A company with a real audit hands you a one-page heatmap of pools and functions scored on substitution, defensibility, and dollars. A company performing transformation hands you a vision deck and a list of pilots. Pilots without a map mean they are spending where it is exciting, not where it is exposed.

Check whether their own revenue is in the red column. An audit where everything the company sells is “defensible” and only competitors are exposed is marketing wearing an audit’s clothes. Credible management can point to their own most-exposed line and tell you what they are doing about it this quarter. The willingness to say “this part of our book is at risk” is the single best proxy for whether the rest of the analysis is honest.

Make them separate the demo from the codebase. When a team claims an AI productivity gain, ask where: greenfield tooling or the core production system. Ask for the throughput number, pull-request throughput or cycle time, not lines of code and not “the developers say it helps.” If the gains live only in standalone projects while the core is untouched, the build side of their transformation has not started, however good the demo.

The audit is cheap to ask for and expensive to fake. Ask for it early. What comes back, and how honest it is about the company’s own exposure, tells you most of what you need to know about whether this is a team that will transform or one that will narrate transformation until the multiple catches up with them.

Why the audit is the whole game

A pattern audit feels like preparation. It is the decision. By the time you have an honest, dollar-weighted page showing where your revenue is exposed, how mature the threat is, and how ready you are to respond, you have already chosen what to defend, what to rebuild, and what to sell. The three moves stop being a strategy you argue about in a room and become a reading of the page.

The companies that win the agentic era will not be the ones with the best vision slide. They will be the ones who looked hard enough at their own business to put their best revenue in the red column, and then did something about it before someone across the table ran the same math for them.

Next in Part 3: the business case. The page tells you where to point. Now you have to fund it, which means turning a risk map into a number a CFO will sign. We will build it the way it actually gets approved, including the part where “we will be more productive” is the weakest argument you can make.

The constraint is that the physical world has latency that the digital world does not. An AI agent can reprice an insurance policy in milliseconds. It cannot retool a production line in milliseconds. It can predict that a bearing will fail in seventy-two hours. It cannot teleport the replacement part to the factory floor. It can optimize a production schedule across six plants simultaneously. It cannot override the fact that Plant 3 has a three-week lead time on a critical casting.

This gap between digital intelligence and physical execution is not a flaw in the AI thesis. It is the defining characteristic of industrial AI. The companies that understand where AI compresses time and where physics remains the bottleneck will transform faster than the ones that treat AI as a universal accelerator. The global AI in manufacturing market reached $34 billion in 2025 and is growing at 35% annually. Agentic AI adoption in manufacturing is projected to quadruple from 6% to 24% by end of 2026. The investment is real. The question is whether it lands on the right problems.

Industrial runs the full set of eight patterns - but with a physical layer underneath every one of them that no other industry shares. The Sentinel pattern watches a machine. The machine is physical. The Conductor pattern coordinates a production run. The production run involves materials, tools, and people in a specific place at a specific time. The Simulator pattern models a factory. The factory exists in three dimensions with constraints that no model fully captures. This is what makes industrial AI both the most impactful and the most humbling application of the framework.

A quick reminder of the playbook: map your business to the eight patterns, then three moves - assess and defend your exposed revenue, re-engineer your core production around AI execution, and reposition as agent-first. This piece applies all three to industrial operations.

The pattern map - how industrial actually works

High exposure - disrupting now

Quality inspection and defect detection is the Sentinel pattern applied to every unit of production. A human inspector on a production line catches defects through visual examination - surface flaws, dimensional errors, assembly mistakes, cosmetic issues. Computer vision systems now perform inline inspection at speeds no human can match - 5 milliseconds per classification, 100% of units inspected, 98-99% accuracy, operating continuously without fatigue. The economics are stark: 50-70% labor savings on inspection alone, with higher consistency and complete traceability. The human inspector who catches three defects per hundred is replaced by a system that catches ninety-eight. The remaining two - the novel defect the model has never seen, the subtle quality issue that requires judgment about whether it matters to this specific customer - that is where human expertise remains. But it is a fraction of the inspection workload.

Predictive maintenance and field service is the Sentinel, Investigator, and Conductor patterns applied to equipment health. A machine vibrates. The vibration pattern changes. An experienced maintenance technician recognizes the change as a bearing approaching failure. Traditional maintenance is either reactive (fix it when it breaks - expensive downtime) or preventive (replace on schedule - wasteful parts and labor). AI-driven predictive maintenance reads vibration, temperature, current, acoustic, and pressure data from sensors across thousands of assets simultaneously, detects degradation weeks before failure, identifies root causes, and generates work orders autonomously. The results are no longer theoretical: 15-30% downtime reduction, 85-90% catastrophic failure prevention, 50-70% less unplanned downtime at mature adopters.

At KORE, we explored a problem that captures where this is heading. Consider a filler machine on an assembly line - a specialized piece of equipment that does one specific thing in a much larger production process. When it breaks, it does not just stop itself. It stops the entire line. The production loss compounds by the hour. And the technician who can actually fix it is a specialist in that specific machine - often the only person within range who understands it - and they may be hours or days away. The cost is not the repair. It is the line sitting idle while the one person who knows the machine travels to it. What we were working on with Control System Integrators, back in 2022, was whether a generalist technician already on site could perform the repair, guided by a specialist who joined remotely - through an AI-generated walkthrough and a VR headset that let the remote expert see exactly what the on-site technician saw. We were building this for an OEM filling-systems builder with over a thousand machines in the field and an engineering team far too small to service them all in person. We did not push it all the way through. But the idea was sound, and it is dramatically more powerful now. In 2022, the AI walkthrough still leaned heavily on the specialist to author it. Today, an LLM that has ingested the machine’s service manuals, maintenance history, and failure modes can generate the guidance in real time, contextualized to the specific fault and the specific machine. The specialist is still there for the moments the model has not seen - but those moments shrink with every repair. The line that used to wait eight hours for a specialist now waits twenty minutes for the AI to walk a generalist through the fix. The bottleneck was never the hands. It was the knowledge, and the knowledge is becoming portable.

Supply chain and demand planning is the Simulator and Investigator patterns applied to the most complex optimization problem in business. What should we produce, in what quantity, at which plant, with which materials, from which suppliers, to meet which demand, at what cost? Supply chain planning has always been a simulation problem - but one run on spreadsheets, ERP modules, and human judgment. AI demand sensing now integrates real-time signals - point-of-sale data, weather patterns, social media trends, economic indicators - to improve forecast accuracy by 15-40%. The planning cycle that took weeks compresses to hours. The scenario modeling that tested three configurations now tests three thousand.

Emerging - invest now

Production scheduling and optimization is the Conductor pattern running across the factory floor. A production schedule must coordinate machines, materials, labor, tooling, quality checks, and shipping deadlines simultaneously. Change one variable - a machine goes down, a material shipment is late, a rush order arrives - and the entire schedule needs to rebalance. Today this is done by production planners with deep experience and ERP systems that struggle with real-time disruption. AI agents that re-sequence schedules autonomously, adjusting to disruptions without human routing, represent the next operational leap. More than 40% of manufacturers plan to adopt AI scheduling tools in 2026.

Robotics and embodied execution is the Reactive and Sentinel patterns gaining a physical body. Traditional industrial robots executed pre-programmed motions inside cages, in structured environments built around their limitations - a robot arm welding the same seam ten thousand times, blind to anything outside its programmed path. LLM-powered robotics changes the nature of the machine. A robot that can interpret an unstructured situation, take instruction in natural language, and act in an environment it was not explicitly programmed for is no longer automation. It is autonomy in the physical world. Warehouse robots, inspection drones, autonomous ground vehicles, and collaborative robots are the deployed reality today. General-purpose humanoid robots are the heavily hyped frontier - real progress, but mostly still staged demonstrations rather than production deployments. The line between the two is whether the robot is executing a fixed routine or reacting to a world it has to interpret. That line is moving fast.

At KORE we provided the connectivity for an Australian drone company called Swoop Aero - and it taught me what embodied autonomy actually solves. Swoop Aero ran bidirectional drone logistics networks delivering medical commodities - vaccines, pathology samples, antiretroviral medication - into remote and rural areas across Malawi, the Democratic Republic of Congo, Mozambique, the Pacific, and parts of Australia and the UK. The problem they solved was not cost. It was reach. These were places where the road either did not exist or could not be relied upon, where the human alternative to a drone was a person on a motorbike taking hours or days, if they could get there at all. The drone closed a physical gap that no amount of digital intelligence could close on its own - because the constraint was never information, it was the last mile of physical distance. Our piece of it was the connectivity that made the fleet reliable: satellite and cellular with redundancy and failover, so a drone carrying a temperature-sensitive vaccine was never out of contact. In that era, the drone flew a planned route and a human monitored the flight, ready to intervene. The LLM-powered version interprets conditions in flight - re-routing around weather, recognizing an unexpected obstacle, handling the exception itself, and escalating to a human only when it hits something genuinely novel. The Sentinel pattern with wings. And the logic generalizes beyond delivery: the same embodied autonomy that put a drone over roadless terrain is what puts a robot into a confined space, a contaminated zone, or a hazardous perimeter - the places we should not be sending people at all. The value is not a cheaper worker. It is removing the human from the gap entirely.

Equipment fleet management and asset intelligence is the Sentinel and Conductor patterns applied to the installed base. An industrial OEM that sells machines - filling systems, compressors, CNC equipment, packaging lines - has thousands of units operating in the field. Each generates data, if anyone can read it. The problem is that most industrial machines were built before connectivity existed.

This is where the real money hides, and it is not where most people look. The machines running on factory floors today were designed to make things, not to talk. They have analog and digital I/O - sensors and signals that were never meant to leave the machine. At KORE, the legacy-machine retrofit was one of the most commercially interesting opportunities we found, precisely because the economics are counterintuitive. For most OEM machine builders, aftermarket services - parts, service, monitoring - represent only about 24% of revenue but contribute 40% to 80% of profit. The machine is sold at thin margins to win the deal. The money is made over the next fifteen years servicing it. The OEM that can instrument its installed base - retrofit third-party I/O boards and sensors onto machines that were never designed for connectivity - turns a one-time product sale into a recurring data and service relationship. The barrier was always integration. Every machine type speaks a different dialect of analog signal, every plant has a different configuration, and making sense of that data stream historically required custom engineering for each deployment. This is exactly what changes in the LLM era. A model can now interpret messy, inconsistent, undocumented machine data - the previously unreadable analog stream - and align it into something coherent without a bespoke integration for every machine. The retrofit that was too expensive to scale becomes economical. The 24%-revenue, 80%-profit aftermarket becomes addressable across the entire installed base, not just the newest machines.

Digital twins and process simulation is the Simulator pattern applied to the physical factory itself. A digital twin is a virtual replica of a production line or plant that simulates failure modes, tests process changes, and validates new configurations without risking actual production. NVIDIA’s Omniverse platform delivers a 1,200x speedup for virtual factory testing, enabling 50% faster commissioning of new lines. The process engineer who spent six months testing a layout change in production now simulates it in days.

Augmenting - human judgment stays

Product design and engineering is the Creator and Advisor patterns applied to the most intellectually demanding work in industrial operations. Designing a new turbine blade, engineering a structural component, developing a pharmaceutical formulation - these require judgment that integrates physics, materials science, manufacturing constraints, customer requirements, and commercial viability. AI generates design candidates, runs structural simulations, optimizes for weight and cost. The engineer provides the judgment about which constraints matter, which trade-offs to make, and whether the design will actually work in the real world.

Strategic sourcing and supplier relationships is the Advisor and Negotiator patterns applied to the commercial backbone of manufacturing. A procurement leader negotiating a long-term supply agreement for a critical material is balancing price, quality, reliability, geographic risk, and relationship continuity. AI can model supplier economics, analyze market conditions, and simulate negotiation outcomes. The procurement executive who understands the supplier’s operational constraints, competitive position, and relationship history provides judgment the model cannot replicate.

Move 1 - Assess and defend

The immediate exposure in industrial operations is concentrated in two areas: quality and maintenance - together representing the largest sources of unplanned cost.

Quality inspection is where the technology is most mature and the ROI is most immediate. Computer vision for defect detection is production-ready, cost-effective, and demonstrably superior to manual inspection for the vast majority of quality checks. The defensive move is straightforward: identify the inspection points where manual labor is performing pattern recognition against known defect types, and deploy computer vision. Protect the quality engineers whose value is in defining quality standards, investigating novel failure modes, and making disposition decisions on borderline product.

Predictive maintenance is where the savings compound. A manufacturer running 200 critical assets with an average unplanned downtime cost of $50,000 per hour that reduces unplanned stops by 40% saves millions annually. But the defensive framing matters: the maintenance engineers whose value is diagnostic judgment - the ones who can identify a root cause the model has not seen, who understand the interactions between machine, material, and process that create failure modes unique to this specific production environment - those are the ones to develop. The technicians whose work is primarily reactive response to known failure modes are doing work that predictive systems will eliminate.

Move 2 - Re-engineer the core

Three areas of industrial operations are candidates for fundamental re-engineering.

The autonomous factory layer. The factory of 2030 does not have fewer sensors or more dashboards. It has an intelligence layer that acts. AI agents monitor equipment health, adjust process parameters, re-sequence production schedules, coordinate material flow, and manage quality - continuously, autonomously, with human oversight for exceptions and novel situations. The shift is from systems that report to systems that act. The production manager does not disappear. The production manager shifts from managing daily operations to managing the intelligence system that manages daily operations.

Supply chain as a real-time nervous system. The traditional supply chain operates on forecasts, purchase orders, and batch planning cycles. The re-engineered supply chain operates on real-time signals - and the hardest part is not the planning logic, it is making sense of fragmented data across every party in the chain.

One of our KORE customers brought us a problem that captures this exactly. They shipped goods that were valuable - but not valuable enough to justify the cost of a dedicated tracker on each item. The shipments left a Hong Kong port in containers, and the containers were not uniform. A single container might hold bottles of a whisky popular in North Carolina alongside a batch of electronics bound for Arizona. Container-level tracking got them to the US port. After that, the shipment fragmented across ground carriers, air carriers, and regional logistics companies, each with their own systems, and visibility collapsed. There were two ways to solve it. Put a cheap tracker on every box - the customer wanted it under $1 per label, battery-powered, with a printed SIM and roaming built in, or at least $1 per trip. We could not get the hardware under $10. Or collect the data from every provider in the chain and stitch it together - the ETL approach - which meant building and maintaining a custom integration to every carrier’s format, update frequency, and terminology. Neither path worked at the economics they needed. The sensor problem is still a hardware problem. But the data-consolidation path is exactly what the LLM era makes cheap. A model can read shipping manifests, carrier status updates, customs documents, and delivery confirmations across different formats and languages and align them into a single shipment-level view - without a bespoke integration to every provider. I left KORE before we finished, but I would be surprised if they have not since dropped an LLM into the middle of that data-alignment problem. The expensive path became the easy one.

Product-as-a-service and outcome-based models. Industrial buyers are shifting from purchasing assets to paying for performance. A manufacturer selling a compressor shifts to selling compressed air at a guaranteed pressure and flow rate. A turbine manufacturer shifts to selling power generation at a guaranteed availability. This transition requires continuous monitoring, predictive maintenance, and autonomous service coordination. The manufacturer that cannot see what its equipment is doing in the field cannot sell outcomes. The one that can is selling a fundamentally higher-margin business.

Move 3 - Reposition as agent-first

The agent-first industrial company does not sell products. It sells operational intelligence.

Consider the industrial OEM that has deployed sensors across its entire installed base. It knows what every machine is doing - performance, health, utilization, environmental conditions. That data does not just enable predictive maintenance for its own service operations. It enables intelligence the customer will pay for. The OEM that can tell a mining company their fleet of haul trucks is operating at 73% efficiency, and that three specific changes would bring it to 88%, is not selling trucks. It is selling mining productivity.

This is the transition from product company to intelligence platform. The industrial company that captures operational data across its customer base can benchmark performance, identify best practices, predict failures, and optimize operations in ways no individual customer could achieve alone. The aggregate intelligence across thousands of installations is the moat.

The most elegant example of this I encountered at KORE started with EV chargers - and it shows how far the platform logic can run. An EV charger has one obvious purpose: charge vehicles. Then operators realized the charger could also display advertising - a second revenue layer on the same physical asset. That much is common. What one EV manufacturer asked us to build was genuinely original. Vehicle software update payloads for EVs are enormous - multiple gigabytes. Pushing them over cellular or home wi-fi is slow and consumes heavy bandwidth. Their idea: use the charger itself as a local server. The update downloads once to the charging station, then any vehicle that comes to charge can optionally pull the update over a private network in the immediate vicinity of the station - no cellular backhaul per car, no waiting on a home connection. The charger becomes an edge node for software distribution. We were building the solution when I left. The charger did not change physically through any of this. The intelligence layered on top of it did - from charging device, to advertising surface, to software distribution platform - each layer worth more than the last, and none of it about the original purpose of the machine. That is the product-to-platform transition in a single asset. The hardware is the cost of entry. The intelligence on top is the business.

The resistance - what makes this hard in industrial

Four structural realities constrain the transformation.

OT/IT convergence is harder than anyone admits. Operational technology - the PLCs, SCADA systems, industrial controllers, and proprietary protocols that run factory floors - was designed for reliability and safety, not data integration. Connecting OT to enterprise IT and AI platforms creates security risks, compatibility challenges, and organizational conflict between OT teams (who prioritize uptime) and IT teams (who prioritize data access). This is not theoretical: at KORE, more than one promising deal stalled on exactly this point - a machine builder ready to move forward, held up by cellular security concerns about connecting their equipment to an outside network. The AI that promises autonomous factory operations requires both worlds to cooperate. Getting there is a multi-year integration program most manufacturers underestimate.

Brownfield dominates greenfield. Most manufacturing investment is not in new factories. It is in existing plants with decades-old equipment, legacy control systems, and established processes. Retrofitting sensors, connectivity, and intelligence onto a thirty-year-old production line is fundamentally different from designing an AI-native factory from scratch. The brownfield reality - which is the reality for the overwhelming majority of the manufacturing base - is where the transformation will succeed or fail.

Safety and regulatory constraints. Manufacturing operates under OSHA, EPA, FDA, and industry-specific safety regulations that constrain how quickly AI can take autonomous action. An AI agent that adjusts process parameters on a pharmaceutical line must satisfy validation requirements designed for human-operated processes. An autonomous system in a food processing facility must navigate food safety regulations that assume human oversight at critical control points. The frameworks are evolving, but they are not yet designed for autonomous industrial AI.

Workforce transition and skills gap. Manufacturing already faces a structural skills shortage. The experienced process engineers, maintenance technicians, and production planners who carry decades of tribal knowledge are retiring faster than they are being replaced. AI can capture and scale some of that knowledge. But the transition requires a workforce that can work alongside AI systems - interpreting their recommendations, overriding them when physical reality diverges from the model, and training them on novel situations. This workforce does not yet exist at scale.

The economic consequence

Industrial is a $16 trillion global sector where the operating leverage of AI is enormous because the cost base is physical. A 5% improvement in OEE across a manufacturing network is not a marginal gain - it is tens or hundreds of millions in throughput, quality, and uptime value. A 30% reduction in unplanned downtime does not just save maintenance cost - it unlocks production capacity previously lost to failures.

The companies that capture this value will not be the ones that deploy the most AI. They will be the ones that deploy AI at the intersection of digital intelligence and physical execution - the specific points where better prediction, faster coordination, or continuous monitoring produces outsized returns because the physical cost of getting it wrong is so high. A bearing that fails catastrophically costs $500,000 in lost production. Predicting that failure three weeks early costs a fraction of that. The asymmetry between prediction cost and failure cost is where industrial AI generates its returns.

The deeper shift is in business model. The manufacturer that sells products competes on features, quality, and price. The manufacturer that sells outcomes competes on intelligence - the depth of its operational data, the accuracy of its predictive models, and the effectiveness of its autonomous service. The first business is a commodity with pressure on margins. The second is a platform with a compounding data advantage. And as the aftermarket economics show - a quarter of revenue, the majority of profit - the intelligence layer was always where the money was. AI just makes it addressable across the entire installed base instead of the newest machines alone.

The factory floor has always been where intelligence meets physics. What changes now is that the intelligence is no longer locked in the heads of experienced operators. It is in the system - learning, predicting, and acting at a speed and scale no human team can match. And increasingly it has a body - robots and drones that close the physical gap the digital layer never could on its own. The operators who remain will be the ones whose judgment the system cannot replicate. There will be fewer of them, and they will be worth more.

Next: Running a pattern audit - the first piece in the transformation playbook. How to map your own business to the eight patterns, identify where AI creates the most value, and build the case for action. The playbook, the build log, and the investor lens - all in one.

Insurance is one of the oldest industries in the world and one of the most intellectually interesting. At its core, insurance is a prediction business. An underwriter evaluates a risk - a building, a driver, a life, a business - and assigns a price that reflects the probability of a future event. The entire edifice rests on the assumption that experienced humans, armed with actuarial data and domain judgment, can price uncertainty better than the market average. For centuries, that assumption has been correct.

AI is not overturning that assumption. It is compressing it. The underwriter who spent three days evaluating a commercial property submission now watches an AI system do it in three minutes. The claims adjuster who took two weeks to investigate a suspicious auto claim now receives a fraud score in seconds. The actuary who built pricing models over months now iterates in hours. The prediction business is not going away. The labor model that delivered it is.

The numbers are already visible. Underwriting timelines are collapsing from days to minutes. Straight-through processing rates for claims have jumped from 10-15% to 70-90% in carriers that have deployed AI at scale. Insurance fraud costs the US economy an estimated $308 billion annually - roughly $900 per policyholder in inflated premiums - and AI-powered detection has improved identification rates by over 30%. The global AI in insurance market is projected to grow from $13 billion in 2026 to over $150 billion by 2034. These are not projections about what might happen. They are measurements of what is happening.

And yet the insurance industry is moving unevenly. Insurtechs have demonstrated what AI-native insurance operations look like. The legacy carriers - the ones with the books of business, the distribution networks, the regulatory licenses, and the decades of claims data - are the ones that will determine whether AI transforms insurance economics or merely accelerates them.

A quick reminder of the playbook: map your business to the eight patterns, then three moves - assess and defend your exposed revenue, re-engineer your core production around AI execution, and reposition as agent-first. This piece applies all three to insurance.

The pattern map - how insurance actually works

Telecom runs on event volume. Retail runs on customer interaction. Insurance runs on judgment under uncertainty. That distinction shapes which patterns dominate and where AI’s impact is most profound.

High exposure - disrupting now

Claims processing and adjustment is the Reactive pattern at the core of insurance operations. A claim arrives - a car accident, a house fire, a medical procedure, a business interruption. The event triggers a sequence: first notice of loss, documentation gathering, investigation, assessment, negotiation, payment. Every step has been performed by humans reading documents, making phone calls, inspecting damage, and exercising judgment about coverage and value. AI collapses the mechanical layers of this sequence. Document extraction, damage assessment from photographs, coverage verification against policy language, payment calculation - these are tasks where AI is already faster and more consistent than human adjusters. The judgment layer - the complex liability determination, the disputed coverage interpretation, the negotiation with a claimant who believes their loss is worth more than the assessment - that remains human. But it is a fraction of the total claims workflow. McKinsey estimates that AI-driven automation can deliver material reductions in loss adjustment expenses across multi-year implementation horizons. The carriers deploying automated claims ecosystems in 2026 are combining triage, damage assessment, and automated payment triggers for straightforward claims, reserving human adjusters for complex and disputed cases only.

Customer service and policy administration is the Reactive pattern applied to the ongoing relationship. Policy changes, coverage questions, billing inquiries, certificate requests, renewal processing - the volume of administrative interactions in insurance is enormous and repetitive. The economics mirror telecom: human interactions are expensive, AI interactions are cheap, and most of the volume is routine. The same platform automation argument applies - an insurance administration system that explains coverage clearly, processes endorsements without phone calls, and proactively notifies policyholders of relevant changes eliminates service calls at the source.

Fraud detection and investigation is the Sentinel and Investigator patterns working in combination - and the stakes are staggering. Insurance fraud costs an estimated $308 billion annually in the United States alone. Property and casualty fraud accounts for $90-122 billion of that total, with roughly 10% of all P&C claims estimated to be fraudulent. Soft fraud - inflating legitimate claims, overstating repair costs, exaggerating injuries - accounts for 60% of incidents. Hard fraud - staged accidents, arson, faked theft - accounts for the rest. Traditional detection relied on rules-based systems and manual investigation. AI changes both the speed and the depth. The Sentinel pattern watches for anomalous patterns across claims data in real time. The Investigator pattern traces suspicious claims through networks of related entities - identifying fraud rings that no individual adjuster would see because the connections span thousands of claims across years. And yet, there is a striking paradox: AI deployments in insurance jumped 87% in 2025, but aggregate fraud losses are not falling. The detection is improving. The prevention has not caught up. The gap between flagging suspicious claims and actually stopping the payout is where the next wave of value sits.

Emerging - invest now

Underwriting and risk assessment is the Investigator and Simulator patterns applied to the core intellectual act of insurance. An underwriter receives a submission - a commercial property, a fleet of vehicles, a directors and officers policy - and must evaluate the risk. Traditionally, this meant reading documents, requesting additional information, consulting loss history, applying guidelines, and exercising judgment. AI is transforming each step. Document ingestion and extraction is automated. Risk profiling draws on data sources the human underwriter could never process - satellite imagery, IoT sensor data, telematics, social media, real-time weather patterns, building code databases. McKinsey describes a near-future underwriting environment where specialized agents collaborate autonomously: an intake agent ingests submission data, a risk profiling agent builds comprehensive profiles, a pricing agent structures the policy, a compliance agent reviews for regulatory adherence, and a decision orchestrator determines whether the case can be approved automatically or requires human escalation. Twenty-two percent of insurers plan to have an agentic AI underwriting solution in production by end of 2026.

The shift from static to continuous underwriting is the deeper disruption. Traditional underwriting evaluates risk at a single point in time - policy inception or renewal. AI-enabled underwriting evaluates risk continuously. A commercial property insurer monitoring IoT sensors in a building can detect a change in fire suppression system status and adjust the risk profile in real time. A fleet insurer receiving telematics data can identify a driver whose behavior has changed and reprice accordingly. The underwriter does not disappear. The underwriter’s role shifts from evaluating a snapshot to managing a continuously updating risk picture.

Policy retention and lapsation management is the Sentinel and Reactive patterns applied to one of the most persistent problems in life insurance. Policy lapsation - where policyholders stop paying premiums and the policy lapses - is an industry-wide drain with reputation, accounting, and customer impact.

Around 2010, I worked with Rama Warrier, a veteran insurance practitioner, to build a solution for this problem. We mapped the entire lapsation landscape - every signal that could predict a policy at risk, every root cause that drove the lapse. The data dimensions were clear: agent attributes (lapsation history, years active, commission earnings, target pressure), customer attributes (age, occupation, salary, credit history, other policies), policy attributes (product type, premium level, payment frequency, term), and external factors (stock market, interest rates, sector performance). The root causes were sharper and more uncomfortable. We categorized them bluntly: “I got fooled” - agent oversold, agent under target pressure, agent misinformed, agent advised termination to sell a new product. “Different purpose” - the customer bought for tax savings or as loan collateral, never intending to maintain the policy. “Don’t understand” - complex product, customer didn’t estimate the premium impact, impulsive buy. “Lazy” - forgot the due date, payment mode too difficult, revival process too complicated. “Genuine reason” - lost a job, financial position changed. The word “agent” in our 2012 analysis referred to the insurance salesperson - and the agent’s commission structure was itself a root cause. Commissions were front-loaded on the first three years of premium, creating a structural incentive to sell and move on rather than to place the right product with the right customer. We had the analytical framework. What we did not have were the tools to act on it at scale. Today, AI running the Sentinel pattern watches every policy against these attributes continuously. It flags the policy that is sixty days from its next premium date where the agent has a lapsation history, the customer bought a complex product they likely do not understand, and the macro environment has shifted against them. The Investigator pattern diagnoses why - is this a “got fooled” lapsation where the intervention is customer education and possible product simplification, or a “genuine reason” lapsation where the intervention is premium restructuring or a policy loan? And the Reactive pattern executes the right campaign - not a generic reminder, but a targeted intervention matched to the predicted root cause. The irony is that “agent” now means something entirely different. The AI agent fixing the lapsation problem is cleaning up after the human agent whose incentives created it.

Reinsurance and portfolio management is the Investigator and Sentinel patterns applied to one of the most complex and least visible layers of insurance operations. Reinsurance is how insurers manage their own risk - ceding portions of their book to reinsurers through treaty arrangements that operate at a portfolio level, legally separate from the underlying direct insurance. The disconnect between reinsurance and direct insurance creates structural operational risk. Policies may not be ceded correctly according to the reinsurance program. Claims that should attract recovery may not be tagged to the right treaty. Aggregate accumulations may breach treaty limits without anyone noticing because the data lives in different systems, sometimes on spreadsheets, sometimes managed manually across offices that are not integrated.

I ran a startup around 2010 that built reinsurance audit solutions for insurers. The business problem was straightforward and universal: omissions and leakages exist in virtually every insurance company’s reinsurance operations. We would extract policy and claims data, enrich it, and run it against the reinsurance program parameters to find what was missing. Every engagement found problems. Cessions that had not been made. Claims recoveries that had not been collected. Small-ticket catastrophe claims not tagged to the right event code, causing XOL recoveries to be lost. Medium-sized risks that slipped through because the system did not enforce the program rules consistently. The deeper problem was not the leakages themselves - it was what they meant for the insurer’s actual risk position. An insurer that thinks it has ceded risk according to its program but has gaps in its cessions is carrying more net exposure than its capital model assumes. That is not an operational inefficiency. It is a solvency question that does not surface until a catastrophic event hits and the expected recoveries are not there. We built this as a periodic audit - extract, enrich, analyze, report. The tools of 2010 demanded it. Today, the same analysis runs as a continuous Sentinel. An AI system reading reinsurance treaty language - the actual contract text, not a simplified rules table - cross-referencing every policy and claim against program terms in real time, flagging cession gaps on the day the risk is written rather than at year-end, monitoring aggregate accumulations against treaty limits continuously. The periodic audit becomes a permanent watch. The insurer operates on known net exposure at all times, not just at audit time.

Actuarial modeling and product design is the Simulator pattern applied to portfolio-level decisions. What happens to our loss ratios if climate patterns shift the frequency of catastrophic events by 15%? What pricing structure optimizes retention versus profitability for a new cyber insurance product? How should we rebalance our geographic exposure given updated flood risk models? These are simulation problems that actuaries have always solved - but with models that took weeks to build and run. AI accelerates the cycle and expands the dimensionality. A portfolio management agent can monitor concentration risk across geography, industry, and peril type, alerting underwriters to emerging accumulations before they become problematic. WTW’s March 2026 survey found that insurers using more sophisticated analytics achieved combined ratios six points lower than slower adopters.

Augmenting - human judgment stays

Complex commercial and specialty underwriting is the Advisor pattern in its purest form. A large construction project, a multinational liability program, a complex reinsurance treaty - these require judgment that integrates technical risk assessment with market knowledge, relationship management, and commercial creativity. AI provides the underwriter with better data, faster analysis, and more comprehensive scenario modeling. The underwriter provides the judgment about which risks to take, how to structure the program, and what terms will make the deal work for both parties.

Regulatory strategy and compliance is the Advisor pattern applied to one of the most heavily regulated industries outside of banking. Insurance regulation varies by state in the US - fifty different regulatory environments - and by country globally. Rate filings, form approvals, market conduct examinations, solvency requirements, consumer protection mandates - the regulatory surface area is enormous. Colorado’s AI Act and the EU AI Act are specifically targeting algorithmic fairness in insurance pricing and claims decisions. The regulatory strategist who understands both the technical capabilities of AI and the political dynamics of insurance regulation provides judgment that no model replicates.

Move 1 - Assess and defend

The immediate exposure in insurance is concentrated in claims operations and customer service - together representing the largest operational cost centers for most carriers.

Claims is where the economics are most dramatic. A carrier processing 500,000 claims per year with an average handling cost of $400 per claim that moves 60% to AI-assisted straight-through processing at $80 per claim saves over $96 million annually. The savings are real, but the defensive framing matters: this is not about replacing adjusters wholesale. It is about identifying which claims genuinely require human judgment - the complex, disputed, high-value, or potentially fraudulent cases - and routing everything else through AI processing. The carriers that defend well will have smaller, more skilled claims teams handling harder work at higher quality. The ones that defend poorly will either over-automate (creating customer experience disasters on complex claims) or under-automate (watching their expense ratios become uncompetitive).

Fraud defense is the area where the gap between AI capability and actual results is most visible. Insurers are spending heavily on fraud detection AI. Fraud losses are not falling. The issue is not detection - it is the workflow after detection. A fraud score that flags a claim as suspicious is only useful if the investigation, evidence gathering, and decision process that follows is fast enough to act before the claim is paid. The carriers that integrate AI detection with AI-powered investigation - automatically gathering supplementary evidence, cross-referencing related claims, identifying network connections - will close the gap. The ones that bolt AI scoring onto a manual investigation process will continue to catch fraud after the money is gone.

Move 2 - Re-engineer the core

Three areas of insurance operations are candidates for fundamental re-engineering.

Underwriting as a continuous intelligence system. The annual renewal cycle is an artifact of a world where risk evaluation was expensive and slow. When the data is streaming - from IoT sensors, from telematics devices, from satellite imagery, from financial feeds - and the models update in real time, the concept of a fixed policy term becomes a commercial choice rather than an operational necessity. The re-engineered underwriting function does not evaluate risk once a year. It monitors risk continuously and adjusts pricing, terms, and coverage recommendations dynamically. The underwriter becomes a portfolio manager rather than a transaction processor.

Claims as an autonomous pipeline. The re-engineered claims operation is not a faster version of the current process. It is a fundamentally different architecture. First notice of loss triggers automated damage assessment (photos analyzed by computer vision), automated coverage verification (policy language parsed against claim facts), automated payment calculation (repair estimates generated from parts and labor databases), and automated payment execution for straightforward claims. Human adjusters receive only the cases that exceed confidence thresholds - complex liability, coverage disputes, suspected fraud, catastrophic losses. The ratio of automated to human-handled claims inverts from the current 15/85 to 70/30 or higher.

Fraud prevention as a real-time system. The current model detects fraud after the claim is filed - and often after it is paid. The re-engineered model prevents fraud at multiple points in the lifecycle. At policy onboarding, AI-based identity validation checks for synthetic or fabricated identities. At first notice of loss, real-time analysis scores the claim against known fraud patterns before an adjuster is assigned. During investigation, AI cross-references the claim against networks of related claims, public records, and third-party data sources to surface connections that no human investigator would find. The goal is not better detection. It is shifting from pay-then-investigate to investigate-then-pay for any claim that exceeds a risk threshold.

Move 3 - Reposition as agent-first

The agent-first insurer does not sell policies. It sells risk intelligence.

Consider what becomes possible when an insurer has continuous visibility into the risks it covers. A commercial property insurer monitoring building systems through IoT sensors does not just price the risk more accurately. It can alert the building owner that a water leak is developing on the third floor before it causes damage. A fleet insurer receiving real-time telematics does not just reprice when a driver’s behavior changes. It can recommend specific interventions - driver coaching, route adjustments, vehicle maintenance - that reduce the probability of the loss occurring at all.

This is the transition from risk transfer to risk prevention. The insurer that prevents losses is more valuable than the insurer that pays for them. And an insurer that prevents losses has structurally better economics than one that processes claims.

The product architecture shifts accordingly. Instead of annual policies with fixed premiums, the agent-first insurer offers continuous coverage with dynamic pricing that rewards risk reduction. Instead of claims processing as the primary service interaction, the agent-first insurer makes risk advisory the ongoing relationship. Instead of competing on price for commoditized coverage, the agent-first insurer competes on the quality of its risk intelligence - the depth of its data, the accuracy of its models, and the effectiveness of its prevention recommendations.

The FNOL advantage is the clearest example of how AI collapses an entire negotiation dynamic. In auto insurance, the party whose insurer gets notified first after an accident gains a structural advantage in the claim negotiation. The FNOL advantage does not change fault placement, but it shapes everything else - how the claim is framed, what evidence is gathered first, how the narrative is positioned. The insurer that starts investigating first controls the early story, and the early story influences how the claim is valued, what is included, what is disputed. Now consider two Teslas in a collision. Both vehicles have 360-degree camera footage. Both have telemetry - speed, braking inputs, steering, GPS coordinates, timestamps accurate to the millisecond. The data from both cars is available immediately. There is no narrative to control because the objective record exists on both sides simultaneously. The FNOL advantage disappears because there is no first - both insurers have the data at the same moment. Two AI agents - one representing each carrier - can assess liability from the footage and telemetry, calculate damage from the images, verify coverage against both policies, and negotiate the settlement. Not in days. Not in hours. In the time it takes the two drivers to exchange information at the side of the road - or before they have even done that. That is the Negotiator pattern collapsing in real time. The information asymmetry that created the FNOL advantage is eliminated by the data. The negotiation that took weeks now takes minutes. The claim is resolved at the moment of the event. This is not faster claims processing. It is a fundamentally different model - and the insurer that builds it first owns a customer experience that no traditional carrier can match.

The embedded insurance opportunity extends this further. An agent-first insurer does not need to own the customer relationship directly. It can embed its risk intelligence into the platforms where risk decisions are made - construction project management software, fleet management systems, supply chain platforms, real estate transactions. The coverage is activated by the context, priced by the data, and managed by agents that operate within the partner’s workflow. The insurer becomes an invisible infrastructure layer that provides risk capacity and risk intelligence wherever it is needed.

The resistance - what makes this hard in insurance

Four structural realities slow the transformation.

Legacy systems and data fragmentation. Most large carriers run on policy administration systems that are decades old - green-screen mainframes with layers of middleware connecting them to modern interfaces. Claims, underwriting, billing, and policy data often sit in separate systems with inconsistent data models. The AI that promises continuous underwriting and real-time fraud detection requires clean, integrated data flowing in real time. Getting there from a legacy carrier’s current architecture is a multi-year, nine-figure program - and the business must keep running while the platform is rebuilt.

Regulatory scrutiny of algorithmic decisions. Insurance regulators are paying close attention to AI-driven pricing and claims decisions. Colorado’s AI Act requires insurers to test for and disclose unfair discrimination in algorithmic underwriting and claims. The EU AI Act classifies insurance pricing as high-risk AI. NAIC model bulletins are being adopted across states. The regulatory direction is clear: AI in insurance must be explainable, auditable, and demonstrably fair. This creates a genuine tension with model performance - the most accurate risk models are often the least explainable, and the regulatory requirement for transparency constrains the complexity insurers can deploy.

Distribution channel complexity. Insurance is sold through agents, brokers, direct channels, aggregators, and embedded partnerships. Each channel has different economics, different data sharing arrangements, and different customer relationship expectations. An AI-native underwriting and claims process that works for a direct-to-consumer model may break the broker relationship that accounts for 60% of commercial lines revenue. The carriers that navigate this will build AI capabilities that enhance the broker’s value rather than disintermediate it - giving the broker better insight, faster quotes, and more responsive service.

Actuarial conservatism and model governance. Insurance is built on centuries of actuarial science. The profession is rightly conservative about model risk - the consequences of a pricing model that is systematically wrong are measured in billions. The governance frameworks for traditional actuarial models are mature and well-understood. The governance frameworks for AI models that update continuously, incorporate unstructured data, and make real-time decisions are not. Building the organizational confidence to let AI-driven models influence pricing and reserving decisions requires actuarial leadership that understands both the potential and the risks of the technology.

The economic consequence

Insurance is a $6 trillion global industry built on two structural costs: the cost of predicting risk and the cost of processing the consequences when the prediction is wrong. AI is collapsing both simultaneously.

On the prediction side, continuous underwriting with richer data sources produces more accurate risk pricing. WTW data shows a six-point combined ratio advantage for carriers using advanced analytics. For a carrier writing $5 billion in premium, six points of combined ratio improvement is $300 million in annual underwriting profit. On the processing side, automated claims handling, AI-driven fraud prevention, and straight-through policy administration reduce the operational cost of delivering insurance by 30-40%.

The carriers that capture both sides of this equation - better predictions and cheaper processing - will generate returns that legacy carriers cannot match. The capital will follow. Insurtech funding surged to $1.13 billion in Q1 2025 alone, a 90% quarterly increase driven primarily by AI capabilities. The insurtechs are building what the legacy carriers are trying to become.

But the incumbents have advantages the insurtechs do not: decades of claims data, established distribution, regulatory licenses in every jurisdiction, and the balance sheets to absorb catastrophic risk. The question is whether those advantages are deployed to build AI-native insurance operations or to protect the current model for another cycle.

The insurer of 2030 will look nothing like the insurer of 2020. It will underwrite continuously, process claims autonomously, prevent losses proactively, and price risk dynamically. The humans in the building will be underwriting specialists managing portfolio-level risk decisions, claims experts handling genuinely complex disputes, and product designers creating new risk solutions that only AI-native platforms can deliver. The rest of the work - the document processing, the routine claims, the standard underwriting, the administrative interactions - will be executed by agents running the patterns this series has described.

The art of pricing risk is not going away. The labor model that has delivered it for centuries is.

Next: Industrial - an industry where AI meets the physical world at scale. Where the patterns run across factory floors, supply chains, and equipment fleets, and where the gap between digital intelligence and physical execution defines the transformation.

The whole kit is open source: github.com/tsachdev/execbrain. The fastest path is to clone it, point Claude at the folder, and say “build me an execution brain” — Claude reads the included build script and sets it up with you, step by step. If you would rather understand it before you build it, read on; this guide is the why and the how, and the repo is the take-and-build.

A warning before you start. This is not a weekend project you set up and admire. It is a system you run every day, and the value compounds only if you actually run it. I will be honest about what broke before it worked, because the parts that broke are the parts the one-hour tutorials skip.

You will need three things: a chat-based AI with tool access and scheduled runs, a state database the AI can reach (I use Asana; Jira works if your team already lives there, SQLite if you want zero dependencies), and a folder the AI can read and write. That is it. No vector database, no custom code, no infrastructure.

The shape of the thing

Three layers, three substrates. Do not collapse them.

State lives in a database. I use Asana: tasks, subtasks, sections, and a percent-complete field, on the free tier. One task per workstream. Subtasks for the deliverables under it. Sections for the lifecycle: active, blocked, queued, stale, done. This is the source of truth for status, and it is structured because status is structured.

Knowledge lives in a wiki of markdown files. One page per entity you care about: a person, an account, an initiative, a concept. Each page compounds over time with dated findings. This is the Karpathy layer, and it is prose because understanding is prose.

Procedure lives in skills. Each kind of work you do gets a written workflow the AI follows: how to draft this, how to reconcile that, how to update the tracker. These are just markdown files with a trigger description. The AI loads the right one for the job in front of it.

The discipline is in the routing. When new information arrives, you decide where it goes. A status fact (”the review is done, ships Friday”) goes to the database. An insight (”this account’s real blocker is a dependency two releases out, not the thing everyone is watching”) goes to the wiki dossier. The same email can produce both. If you let status leak into the wiki, the wiki rots into a log. If you let narrative leak into the database, the database becomes unsortable prose. Keep the line clean.

Step 1: Stand up the state database

Create one Asana project (free tier is enough). Call it whatever your portfolio is. Add sections for the lifecycle: Active, Blocked, Queued, Stale, Completed. Create one task per workstream. In each task’s description, use a fixed structure the AI can read and write reliably:

## Status
Priority / Category / % Complete / Last Session / Depends On

## Completed
(cumulative list)

## Next Actions
(immediate steps)

## Blockers
(or none)

## Notes
(context worth keeping)

## Session Log
(append-only, newest at top, one dated line per session)

The session log is the spine. It is append-only. The AI adds a dated line every time it touches the task and never deletes a prior one. That log is how the system remembers what happened, and it is the first thing you will be glad you enforced.

Add subtasks for the deliverables under each workstream. Subtasks are checkable and give you real progress tracking without a separate tool.

Step 2: Connect the AI to the database

Connect Asana to your AI tool via its connector / MCP (Asana ships one that most tools support). Confirm it can read and write. Test it with a plain request: “what’s the status of all my workstreams.” If it returns the board, you have the read path. Ask it to bump one task to a new percent-complete, and confirm the write path. That round trip is the whole integration. Everything else is instructions.

Step 3: Build the knowledge wiki

Create a folder. Inside it, a wiki/ directory with subfolders for the entity types you deal with: people, accounts, initiatives, concepts. Each page uses a standard template: what this is, your relationship to it, a running summary, and a “Key Findings” section that grows over time. Findings are dated, one or two lines each, and tagged with a rough confidence level so you know later how much to trust them.

The rule that makes this work, straight from Karpathy: you own the schema, the AI owns the content. You decide what the pages look like and what gets a page. The AI writes and maintains them. If a page is wrong, you do not hand-edit it into a fight with the AI’s next update. You feed it the correction and let it reconcile.

Step 4: Write the procedure skills

For each kind of recurring work, write a skill: a short markdown file with a trigger (”when I say draft a follow-up...”) and the steps. If you already run projects with custom instructions in your AI tool, you have these written already. Lift them out and drop them in as skills. That is exactly how I seeded mine. The instructions I had been pasting into separate project setups became a library the brain could load on demand.

Step 5: Write the daily run

This is the engine. A single instruction file that the AI executes on a schedule. Mine does six things in order, and the order matters.

One: pull the backbone. Read every workstream’s open items from the database. This is the skeleton the run hangs everything on.

Two: gather the signal. Read the last 24 hours of inbound across your real channels: email, tickets, team chat. Widen the window after a weekend. Read replies to things you sent, not just new arrivals. This is the sensing step, and it is where the system earns its keep, because no human reliably reads everything every morning.

Three: reconcile into state. For every workstream with new signal, read the current task first, preserve the session log, then update status, next actions, blockers, and dates. Add a dated log line citing where the update came from. If the signal reveals work that is not tracked anywhere, flag it as a possible new initiative. Do not let the AI auto-create tasks. Surfacing is safe; creating is a decision.

Four: propagate to knowledge. Push the material findings into the wiki dossiers. A new fact about an account goes on that account’s page. A new wrinkle in an initiative goes on the initiative’s page. If something active has no page yet, create one. This is what makes the brain compound instead of just refreshing.

Five: draft the actions. For anything overdue, at risk, blocked, or gone quiet, draft a follow-up. Concise, in your voice, addressed to the right person. Create it as a draft. Never send it. Log the draft in the relevant task so the next run knows it is outstanding.

Six: report and update itself. Produce a short summary: what changed, what is flagged, what was drafted for your review. Then update its own memory and logs, because a run that ends without that leaves the brain stale.

The line that makes it safe

Step five is the whole ethic of the system. The run is autonomous. It reads everything and reconciles everything without you. But it cannot send, post, commit, or delete. Those are gated on you, every time, no exceptions, no “just this once” setting.

This is the opposite of where most of these systems are heading, and I built it deliberately. Autonomy everywhere the action is reversible. A human gate at every door that only opens one way. You will let this thing run unattended every morning precisely because you know it cannot do anything you cannot undo.

What broke before it worked

The honest part. None of the tutorials have this because you only learn it on day three.

It picked up partial and stale information at first. The early runs grabbed the wrong thing or an old thing and confidently wrote it down. I had to correct it by hand more than I wanted to. This faded as the wiki filled in and the AI had context for who and what mattered, but the first week is a teaching week. Budget for it.

Every track needed a cold-start anchor. The biggest fix. The system could not bootstrap a workstream’s status from nothing. For one track that runs on a weekly standup, I pointed it at the standup’s baseline document and told it to reconstruct forward from there. Every workstream needs its own version of that anchor, a known-good starting point the run can build from. Without it, the AI guesses, and the guesses are where the partial-information problem comes from. Find the anchor for each track before you trust the run.

It over-drafts, and I let it. It still proposes more follow-ups than I need. I delete the extras. The math is simple: an unwanted draft costs one click, a missed follow-up costs a dropped ball. I will take that trade every day, and I stopped trying to tune it down.

The maintenance has to be non-negotiable. Every note system dies because the upkeep falls to a human who eventually stops. The fix is to make the AI the maintainer and write the upkeep into the run as a rule it cannot skip. The brain updates its own memory and logs at the end of every session. Not optional. A stale brain is worse than no brain, because you will trust it and it will be wrong.

On keeping the sensitive things out

One boundary worth building from day one. The brain reads a lot, and not everything it reads belongs in a file. Identifiers like government numbers, account numbers, anything you would not want sitting in plain markdown, should be kept out by a standing rule. Point the brain at the source document instead of transcribing the sensitive value. Mine has this written into its behavior file, and it has saved me from myself more than once.

Where to start

Do not build all of this at once. Stand up the database and get the read-write round trip working. Live with just that for a few days; even a queryable status board is a real upgrade. Then add the daily run with sensing and reconciliation. Then the wiki. Then the skills. Each layer is useful alone, and stacking them slowly is how you learn where your own routing lines are.

The setup kit, including the run instructions, the wiki templates, the skill format, and the behavior file, is linked below. Take it, strip my structure down to your own, and start.

This is the companion to “The Execution Layer Brain.” If you have not read the why, start there. This was the how.

Setup kit: github.com/tsachdev/execbrain

In April 2026, Andrej Karpathy published a spec for an LLM-maintained personal wiki. The idea spread fast. The insight was simple and correct: stop making the model re-read raw documents at query time. Have it build and maintain a navigable knowledge base instead. Within weeks there were Obsidian builds, security-engineering adaptations, portfolio-leader versions. A genuine pattern took hold.

I built one. Then I noticed what it could not do.

My trigger was not Karpathy. It was a meeting with Greg Buzek, founder of IHL Group and now, by his own title, a Chief AI Orchestrator. Greg handed me a folder of instructions and a working pattern. Karpathy gave me the architecture. Greg gave me the push to actually run it. I mention this because the useful ideas in this space are arriving from two directions at once: the researchers describing the mechanism, and the practitioners proving it inside real industries. Greg is the second kind, and his nudge is why this exists.

Here is the thing the knowledge brain could not do.

A second brain answers “what do I know about X.” That is a retrieval question. But most of my day is not a retrieval question. It is an execution question: what is the status of this, what moved since yesterday, what is now stale, who owes me a reply, what is the one thing I should touch today. The wiki has no good answer for that. A prose knowledge base is the wrong substrate for execution state. It does not sort. It does not roll up. It does not tell you that three things have gone quiet for two weeks.

So I built the other half.

I am not the first to notice the gap. This is a crowded idea right now. Taskade calls action “the rarest layer” and sells a notes-knowledge-action stack. Tiago Forte, who coined “second brain” in the first place, now teaches turning your plan into an execution system. Nous Research shipped Hermes, an open-source agent that bolts onto a Karpathy wiki and auto-executes on a schedule, generating its own skills as it goes. The whole field is converging on the same move: make the execution layer autonomous. Give the agent the keys and let it act.

I built the opposite, and I think the opposite is what a working professional actually wants. Two differences define it. First, the execution layer is gated on a human at exactly one point: the irreversible action. Second, state does not live in the wiki. It lives in a database, because status and understanding have different shapes and the field keeps conflating them.

I call it the execution layer brain, and the architecture has three layers, not one.

Three layers, three substrates

State lives in a database. Not in markdown. I use a project tool with tasks, subtasks, sections, and percent-complete fields. This is the source of truth for “what is the status of things.” It sorts. It rolls up. It answers staleness queries. Critically, it is structured, because status is structured.

Knowledge lives in the wiki. This is the Karpathy layer. Entity pages for the people, accounts, initiatives, and concepts I work with, each compounding over time with dated, confidence-tagged findings. This is the right place for understanding, because understanding is narrative.

Procedure lives in skills. This is the layer almost nobody is writing about. Each kind of work I do has a documented workflow the model follows: how to draft this, how to reconcile that, how to update the tracker. These started as project instructions and became reusable skills. The brain does not just know things and hold state. It knows how to operate each track.

The separation is the whole point. The crowd collapses everything into one wiki. Running this daily taught me why that fails: state and knowledge have different shapes and different half-lives. A status like “the patch ships Monday” is state and belongs in the database. An insight like “their real go-live blocker is a dependency two releases out, not the patch everyone is watching” is knowledge and belongs in the dossier. Same input. Two destinations. If you mix them, the wiki rots into a status log and the status log bloats into prose nobody can query.

The daily loop

Every morning a scheduled run wakes up and senses. It reads the last 24 hours of email, ticket updates, and team messages. On Mondays it widens to 72 to catch the weekend. It reconciles that signal into the state database, preserving an append-only log on every item. It propagates the material findings into the knowledge wiki so the dossiers compound. Then it drafts the follow-ups I owe, for the things overdue or at risk or gone quiet.

Then it stops. It does not send.

The brain senses, but it never acts unattended

This is the most important design decision in the entire system, and it is where I part ways with the rest of the field.

The run is autonomous. It reads my whole inbox and reconciles my entire portfolio without me. But the one irreversible act, sending, is always gated on a human. The drafts sit in my outbox until I read them and hit send.

The current direction of the entire execution-layer conversation is more autonomy. Hand the agent the keys. Let it act on a schedule. Let it close the loop end to end. I understand the appeal, and I think it is a mistake for anything that touches the outside world on your behalf. The excitement is about how much an agent can do on its own. The trust comes from what it deliberately refuses to do on its own. An assistant that reads everything and proposes is a force multiplier. An assistant that sends on your behalf is a liability waiting for its first bad inference, and it will have a bad inference, because they all do.

So I drew the line at the irreversible action and let the rest run wild. The system can read anything, reconcile anything, draft anything. It cannot send, post, commit, or delete. That single boundary is what makes it safe to let it run unattended every morning. Autonomy everywhere it is reversible. A human gate at every door that only opens one way.

What actually made it work

Three honest lessons from running this for real, not from a weekend setup.

Compounding requires a maintenance contract. Every note-taking system dies the same death: the maintenance kills it. The fix is to make the model the maintainer and yourself the schema author. After every task, the brain updates its own memory, logs the session, refreshes its own state. It is non-negotiable in the instructions, because a session that ends without those updates leaves the brain stale, and a stale brain is worse than none.

Cold start needs an anchor per track. The early runs picked up partial or stale information and had to be fed by hand. What fixed it was giving each track a starting point. One of mine has a weekly standup that produces a baseline document. I told the brain to start from that baseline and reconstruct forward from there. Every track needs its own version of that anchor. You discover this on day three, not day one, which is why the tutorials never mention it.

It over-drafts, and that is fine. It still generates more follow-ups than I need. I delete the extras. The cost of an unwanted draft is one click. The cost of a missed follow-up is a dropped ball. I will take that trade every time.

Why the substrate matters

If you take one idea from this, take this one. The second-brain conversation is almost entirely about knowledge. The newer execution conversation is almost entirely about autonomy. Both are missing the same thing: a working life is run on execution state, that state belongs in a database and not a wiki, and the system that maintains it should sense everything but act on nothing irreversible without you.

Karpathy gave us the knowledge brain. The field is now building the execution brain on top of it, and building it to drive itself. I built one that keeps its hands on the wheel and asks before it turns. It made my life measurably easier. I think it will do the same for you.

I run a version of this daily. In the next piece I will show you how to build your own, with the actual setup kit, the file structure, the daily run instructions, and the parts that broke before they worked. If you want the build guide when it drops, follow along here.

Thanks to Greg Buzek for the trigger, and to Andrej Karpathy for the architecture.

This is not a new problem. Global mobile ARPU has collapsed from roughly $35 in 2000 to roughly $10 today, even as data traffic has grown by orders of magnitude. The carriers built highways and watched everyone else build the businesses on top of them. The “dumb pipe” framing has been a cliché for a decade. What makes the current moment different is that AI is simultaneously the biggest threat to how telecom operates internally and the most credible path to escaping the dumb pipe trap - if the industry can execute the transition before the cost structure collapses under its own weight.

Telecom runs more patterns at greater scale than almost any other industry. A major carrier handles billions of network events per day. Millions of customer interactions per month. Hundreds of thousands of field operations per year. Tens of thousands of infrastructure components under continuous monitoring. The execution layer in telecom is not a metaphor. It is the literal operating reality of a business that runs 24 hours a day, 365 days a year, where a four-hour outage makes national news.

The problem is that this massive execution layer runs almost entirely on human labor organized around the eight patterns - and AI is ready to absorb most of it.

A quick reminder of the playbook: map your business to the eight patterns, then three moves - assess and defend your exposed revenue, re-engineer your core production around AI execution, and reposition as agent-first. This piece applies all three to telecommunications.

The pattern map - how telecom actually works

Telecom runs on a dense concentration of patterns, with the heaviest execution weight in exactly the areas where AI capability is most mature.

High exposure - disrupting now

Customer service and support is the Reactive pattern at massive scale - and it is the area where AI will arrive fastest because the hyperscalers will make sure it does. Google, Microsoft, and Amazon are pouring investment into telecom-specific AI customer service platforms, not out of generosity but because a single carrier deployment is worth tens of millions in recurring platform revenue and produces a case study that sells to every other carrier. The economics are well understood: human interactions cost $3-6 each, AI handles the same interaction for a fraction of that, and a carrier running two million interactions per month can save over $60 million annually by moving 70% to AI. The large carriers will get this done. It is not where the differentiation happens.

The higher-order play is platform automation - the recognition that customer support volume is a symptom, not a root cause. Every call about a billing discrepancy is a billing system that did not explain itself. Every call about a plan change is a self-service flow that did not complete. Every call about a service issue is a provisioning system that did not close the loop. The BSS layer - billing, provisioning, order management, customer data - is where the calls originate. A carrier whose BSS is continuously enhanced by AI - minor updates automated, self-service flows that actually resolve, proactive notifications that preempt the question - does not just handle calls more cheaply. It eliminates the calls. That is a fundamentally different economic model than putting an AI agent in front of a broken process.

Network operations and fault management is the Sentinel and Reactive patterns running continuously. The Network Operations Center - the NOC - is the heartbeat of every carrier. Thousands of screens. Hundreds of engineers. Every network element reporting status, every anomaly flagged, every degradation tracked. When something breaks, the Sentinel pattern detects it and the Reactive pattern responds. When something is about to break, the Sentinel pattern should catch it before customers notice. Deutsche Telekom’s MINDR system - a multi-agent AI system built with Google Cloud - already does this across radio access, transport, and core network layers, correlating anomalies and executing corrective measures autonomously. Their earlier RAN Guardian Agent autonomously triggered over 100 remediation actions during its first month in production and reduced the time to manage major network events from hours to approximately one minute. Verizon reports that AI in its network resolves 85% of all issues without manual intervention.

I have spent time in NOCs. The reality of a large-scale network operations center is less glamorous than the vendor demos suggest. Most of what happens in a NOC is pattern matching against known failure modes. An alarm fires. An engineer looks at the alarm, cross-references it against recent changes, checks whether it is a genuine fault or a known false positive, and either escalates or clears it. The experienced NOC engineer is fast at this because they have seen the same patterns hundreds of times. They know that a particular alarm on a particular equipment type at a particular time of day is almost always a scheduled maintenance window that someone forgot to suppress. They know that three seemingly unrelated alarms firing within sixty seconds of each other on the same fiber route is a cable cut, not three independent failures. This is exactly the kind of contextual pattern recognition that AI absorbs completely. The judgment that remains - the decision to reroute traffic through a degraded alternate path during a major outage because you know the commercial impact of dropping a specific enterprise customer - that is still human. But it is a small fraction of the work that a NOC does on a typical day.

Field operations and dispatch is the Conductor pattern at physical scale. A fault is diagnosed remotely but requires a physical repair. A technician must be dispatched - the right technician, with the right skills, the right parts, to the right location, at the right time. The Conductor decomposes the goal into scheduling, routing, parts inventory, skill matching, and customer communication. Today this is a large workforce of dispatchers and coordinators. The re-engineering opportunity is significant: AI-driven dispatch that optimizes across all constraints simultaneously rather than sequentially.

Emerging - invest now

Fraud detection is the Sentinel and Investigator patterns working together. Telecom fraud costs the industry an estimated $39 billion annually worldwide. SIM swap fraud, subscription fraud, international revenue share fraud, roaming fraud - each follows patterns that AI can detect faster and more comprehensively than rule-based systems. The Sentinel watches for anomalous behavior. The Investigator traces the pattern to determine whether it is genuine fraud or a false positive. The speed advantage matters: fraud that compounds for hours or days before detection is fraud that AI can catch in minutes.

Network planning and capacity management is the Simulator pattern applied to infrastructure investment. Where should the next cell tower go? How should spectrum be allocated across a metropolitan area? What happens to network performance if a major enterprise customer doubles their traffic? These are simulation problems that today require weeks of engineering analysis. AI runs these scenarios in hours, testing thousands of configurations against realistic demand models.

Permanent roaming is the story that shows how much intelligence is hiding in network data - and how expensive it is when nobody is looking. Roaming is designed for travelers: you arrive in a new country, your SIM connects as a guest on a local network, and complex inter-carrier agreements handle the billing. But some MVNOs discovered they could use roaming as a deployment shortcut. A European company wanting to deploy connected devices in the US could simply use European SIMs and let them roam on American networks permanently. The wholesale roaming rates were cheap. The logistics were simpler - no need to source local SIMs in every market. It worked, and it flew below the radar for years. Then Covid hit. Travel stopped overnight. Carriers looked at their networks and found millions of SIMs that were still roaming - permanently. These were not travelers. They were trucks with tracking devices, security panels in buildings, medical alert necklaces, parking meters. Regulatory pressure followed. Rules were created. And suddenly companies that had built their entire deployment model on permanent roaming faced a crisis. Swapping a SIM in a phone is trivial. Swapping a SIM in a fleet tracking device bolted to the underside of a truck, or in a medical alert pendant worn by an elderly person who does not understand what a SIM is, is a fundamentally different problem. Many of these companies came to us at KORE for a solution. It was a major effort - negotiations with carriers on timelines and enforcement grace periods, commercial arrangements to ease the transition, and yes, in many cases, actual physical SIM swaps across thousands of devices in the field. The point for this piece is not the operational heroics. It is that an intelligent network would have identified permanent roaming SIMs long before Covid forced the issue. AI analyzing traffic patterns - connection duration, location persistence, data usage profiles - can distinguish a tourist’s phone from a permanently deployed asset tracker in minutes. It can predict the underlying use case from the traffic signature: human device, IoT device, what kind of IoT device, what kind of use case. The problem we spent months sorting out was a problem that should have been visible on day one to a network that was actually reading its own data.

Billing and revenue assurance is the Reactive and Investigator patterns applied to the commercial layer. Every call, every megabyte, every text message generates a billing event. At the scale telecom operates - billions of events per month - the reconciliation, rating, and invoicing process is enormous. Errors compound. Disputes accumulate. Revenue leakage is an industry-wide problem that operators have spent decades trying to solve with increasingly complex billing systems.

The MVNO world is where billing optimization becomes existential rather than incremental. A Mobile Virtual Network Operator buys wholesale capacity from a carrier and resells it to consumers or enterprises. The margin is thin by design - often a few cents per megabyte, a fraction of a cent per SMS, a small percentage on voice minutes. At that margin, billing accuracy is not an operational concern. It is the business model. An MVNO reconciling usage against wholesale invoices from its carrier partner is running a continuous audit across millions of transactions. A rating error that overcharges by 0.1 cents per event is invisible on any individual transaction and devastating at aggregate scale. A wholesale invoice that bills for usage on deactivated SIMs - and they all do, because the carrier’s provisioning systems and billing systems are not perfectly synchronized - represents pure margin erosion that only shows up if someone is looking. AI running the Investigator pattern on billing reconciliation does not just find errors faster. It finds categories of errors that manual auditing never surfaces because no human team can cross-reference millions of CDRs against provisioning records, wholesale rate cards, and device activation logs simultaneously. The MVNO that instruments this properly doesn’t just save money. It discovers that its actual margin on specific traffic types is materially different from what its pricing model assumed - and can reprice accordingly. I have seen billing reconciliation projects at MVNOs recover six and seven figures in annual revenue leakage that had been accepted as a cost of doing business for years.

Augmenting - human judgment stays

Enterprise sales and deal structuring is the Advisor and Negotiator patterns applied to complex commercial relationships. A carrier selling a managed network to a multinational is negotiating across technical requirements, service levels, pricing, geographic coverage, and contract terms simultaneously. AI can model deal economics, generate proposals, simulate counterparty responses. The account executive who understands the customer’s organizational politics, budget cycle, and competitive alternatives provides judgment that the model cannot replicate.

Regulatory and spectrum strategy is the Advisor pattern in a domain where the stakes are measured in billions and the variables are political as much as technical. Spectrum auction strategy, regulatory compliance across jurisdictions, infrastructure sharing negotiations - these require judgment that integrates technical capability with policy understanding and competitive positioning. AI augments the analysis. The regulatory strategist owns the decision.

Move 1 - Assess and defend

The immediate exposure in telecom is concentrated in two areas: customer service and network operations. Together, they represent the majority of operational headcount at most carriers.

Customer service is where the market has already moved. Verizon completed 13,000 layoffs under its new CEO, with explicit references to AI-driven efficiency. T-Mobile has cut hundreds of positions across multiple rounds. Telus employees report being required to use AI “co-pilot” tools on calls, with growing anxiety that they are training their replacements. The industry union Unifor estimates roughly 20,000 jobs have been lost in Canadian telecommunications alone over the past decade through automation and offshoring - and AI is accelerating the trajectory.

The defensive move is not just replacing agents with AI. It is investing in the BSS layer so that the calls stop originating. The carrier that automates billing explanations, completes plan changes through self-service, and proactively notifies customers before they experience a problem is defending on two fronts simultaneously - reducing the cost of handling interactions and reducing the number of interactions that need handling. The carriers that focus only on the first front will find themselves in a cost-reduction race with diminishing returns.

Network operations follows the same logic with higher technical complexity. The NOC engineers whose value is contextual judgment - the ones who can diagnose a novel failure mode, make a real-time routing decision during a major outage, or recognize that a pattern of minor alarms is the early signature of a systemic problem - those are the ones to protect and develop. The engineers whose work is primarily reactive pattern matching against known failure modes are in the same position as the L1/L2 support agents in IT services: doing work that AI already executes better.

Move 2 - Re-engineer the core

Three areas of telecom operations are candidates for fundamental re-engineering, not incremental automation.

Network operations as autonomous systems. Deutsche Telekom’s stated ambition - and it is not alone - is Level 4 autonomous network operations: full automation with human oversight for exceptions. SK Telecom targets the same level by end of 2027. The technical path is clear. Multi-agent systems that monitor network health, predict failures, execute remediation, optimize capacity, and coordinate across network domains - radio access, transport, core - without human intervention for routine operations. The NOC does not disappear. It transforms from a room full of engineers watching screens into a small team of specialists managing exceptions that the autonomous system escalates. NVIDIA’s 30-billion-parameter telecom model, built specifically for network operations, signals where the infrastructure investment is going.

Billing and provisioning as an intelligent layer. The billing stack at most carriers is among the most complex software environments in any industry - decades of accumulated business logic, regulatory requirements, product configurations, and partner integrations. Re-engineering this as an AI-native system means the billing layer does not just process events. It understands them. It detects anomalies in real time rather than during monthly reconciliation cycles. It identifies revenue leakage as it occurs rather than in quarterly audits. It optimizes rate plans based on actual usage patterns rather than broad market segments. For MVNOs, this is the difference between operating on assumed margins and operating on known margins.

Customer experience as a unified agent. Today, a customer’s journey through a telecom provider is fragmented across IVR trees, chatbots, human agents, retail stores, self-service portals, and field technicians. None of these channels shares context effectively. The re-engineered version is a single AI agent that holds the complete customer relationship - knows the account history, understands the network quality at the customer’s location, can diagnose a service issue, process a plan change, schedule a technician visit, and follow up after resolution. The agent does not hand off between channels. It is the channel.

Move 3 - Reposition as agent-first

The dumb pipe problem is real, and it has been real for twenty years. AI offers the first credible path to solving it - but only for the carriers that understand what “connectivity intelligence” actually means.

The agent-first carrier does not sell bandwidth. It sells what happens on the network. It knows in real time which enterprise customer’s traffic patterns are changing in ways that suggest they are scaling a new application. It can tell a logistics company that their IoT deployment in the northeast corridor is experiencing signal degradation that will affect delivery tracking within 48 hours - before the customer notices. It can offer a retail chain dynamic bandwidth allocation that automatically scales during peak shopping hours and scales back overnight, priced on outcomes rather than committed capacity.

The carriers investing in AI-native network architectures - Deutsche Telekom, SK Telecom, T-Mobile, SoftBank - are not doing so purely for cost reduction. They are building the infrastructure to sell intelligence, not just connectivity. The IoT and enterprise segment is where this repositioning is most advanced. A carrier that manages a fleet of connected devices and can offer predictive analytics on device health, usage optimization, and deployment planning is selling a service that commands margin. The connectivity underneath is table stakes. The intelligence on top is the value.

The consumer segment is harder but not impossible. The carrier that can tell you your home network is underperforming because of interference from a new device, automatically reconfigure your router, and proactively offer a plan adjustment based on your actual usage pattern - that carrier has a relationship with you that no competitor can replicate by offering a lower price on a commodity plan.

The intelligent pipe is not theoretical. At KORE, we built early versions of it. SecurityPro started with rule-based intelligence on the Sentinel pattern - a trucking company discovers its drivers are using fleet tracking SIMs to stream video, so the system monitors IP destinations and alerts when a device connects to anything other than the authorized server. A security company needs to know immediately if a panel goes silent, so the system watches for heartbeat gaps and triggers an alert at configurable intervals. A parking meter company gets notified when the IMEI associated with a SIM changes - the signature of a SIM physically removed and placed in a different device, which is fraud.

These are valuable capabilities. They are also deterministic rules applied to known patterns. The leap came in KORE Labs, where we started using the traffic data itself - NetFlow records: bytes, protocol, remote IP, source and destination ports - to build intelligence that no rule set could replicate. Auto-encoders that automatically classify SIMs into behavioral profiles based on their traffic patterns. K-means clustering for anomaly detection against historical baselines. LSTMs that predict future device usage from current traffic signatures. The network was not just carrying data. It was reading the data to understand what each device was, what it was doing, and what it was about to do.

That is the intelligent pipe. The carrier that can look at traffic metadata and determine that a SIM is behaving like a vehicle tracker rather than a security panel - without anyone telling it - is operating on a fundamentally different level from the carrier that sells megabytes. The carrier that can predict a device failure from its usage trajectory is offering a service that the enterprise customer will pay for on top of connectivity. The pipe is the same. The intelligence on top is the margin. KORE was a small player in the larger telecom ecosystem. But the capability we were building is exactly what the largest carriers are now investing billions to achieve. The difference is that they have the network scale, the data volume, and the customer base to make connectivity intelligence a genuine product category - not a feature, but a business.

The resistance - what makes this hard in telecom

Five structural realities slow the transformation in telecom more than in most industries.

The OSS/BSS legacy stack. Telecom operations run on Operations Support Systems and Business Support Systems that represent decades of accumulated complexity. These systems were not designed for real-time AI integration. They were designed for batch processing, manual workflows, and human-mediated decision making. The Reactive and Sentinel patterns require clean, fast event streams. Getting those streams out of legacy OSS/BSS is an integration problem that dwarfs anything a typical enterprise faces. Every carrier knows this. Few have solved it.

Regulatory complexity across jurisdictions. Telecom is among the most heavily regulated industries in the world. Customer data handling, network neutrality, emergency services requirements, spectrum management, accessibility mandates - the regulatory surface area is enormous and varies by country, by state, and sometimes by municipality. AI systems that operate autonomously must navigate this complexity correctly every time. A customer service agent that makes a regulatory error in one interaction creates a support ticket. An AI system that makes the same error across a million interactions creates a compliance crisis.

Union and labor sensitivity. Telecom has a unionized workforce in many markets, and the workforce reductions driven by AI are politically visible. The FCC’s recent proposal to require onshoring of call center operations - voted on unanimously - creates an interesting collision: the regulatory push to bring jobs home meets the economic reality that AI makes the question of where the human agents sit increasingly irrelevant. Carriers navigating this tension will find that transparent, early engagement with labor stakeholders is less expensive than the alternative.

Physical infrastructure constraints. Telecom is not a pure digital business. Cell towers are physical. Fiber is physical. Equipment in central offices is physical. The AI can optimize the decision layer in real time. The physical layer responds on a different timeline - permits, construction, equipment procurement, installation, testing. The gap between what the model recommends and what the infrastructure team can execute is where most telecom AI initiatives underdeliver.

Vendor lock-in and ecosystem complexity. A major carrier’s technology stack involves dozens of vendors across network equipment, billing systems, CRM, workforce management, and operations tools. Each vendor has its own AI strategy, its own data model, its own integration architecture. The autonomous network vision requires these systems to interoperate in ways that no vendor has an incentive to enable and that the carrier must force through procurement leverage and architectural discipline.

The economic consequence

Telecom has spent two decades watching its core product become a commodity. Traffic grows. Revenue does not. The industry’s response has been a cycle of cost reduction, consolidation, and incremental service bundling that has kept the largest carriers profitable but has not solved the fundamental value capture problem.

AI breaks this cycle in both directions simultaneously. On the cost side, the operational savings from autonomous network operations, AI-driven customer service, and intelligent billing are substantial - large enough to fund the transformation itself for any carrier willing to sequence the investment properly. On the revenue side, connectivity intelligence - the ability to see, predict, and act on what is happening across the network in real time - is a new product category that does not exist without AI and that commands margin the commodity pipe never will.

The carriers that execute both sides of this equation will emerge from the transition as fundamentally different businesses. Not larger versions of what they are today, but platforms that sell intelligence and outcomes, with connectivity as the substrate rather than the product. The ones that treat AI as a cost reduction exercise - as most are currently doing - will find they have made themselves more efficient at selling a commodity, which is a path to being a very efficient business that no one values.

Wall Street is watching this play out in real time. Verizon’s CEO has publicly predicted that AI will cause unemployment comparable to the Great Depression within two to five years. Whether that prediction proves accurate is debatable. What is not debatable is that the CEO of one of the world’s largest carriers believes AI will fundamentally reshape the labor market - and is restructuring his own company accordingly. The carriers whose leadership teams reach this conclusion and act on it first will define what the industry becomes. The ones that wait will find the transition imposed on them by competitors and capital markets that have already priced in the structural shift.

The infrastructure that carries the world’s intelligence is about to become intelligent itself. The question for every carrier is whether they will own that intelligence or merely transport it.

Next: Insurance - an industry built on the art of pricing risk. Where the Investigator, Simulator, and Advisor patterns run the core business, and where AI is about to collapse the distance between underwriting judgment and actuarial computation.

The professional services business model has been stable for decades. A client has a problem requiring specialist knowledge. A firm assembles the right people, applies their expertise, and delivers an answer. The client pays for the time those people spent - the research, the analysis, the synthesis, the recommendation. The billing model is the hourly rate or the project fee, and the margin lives in the gap between what the client pays and what the people cost.

That model rests on two assumptions that are both breaking simultaneously. The first is that expertise and execution are inseparable - that the person who knows the answer is also the person who has to do the work of finding it. The second is that the client cannot easily access the analytical layer without the firm. Both were true for a long time. Neither is true now.

AI doesn’t replace the expertise. It separates the execution from the expert. The senior partner whose judgment a client is actually paying for no longer needs to arrive with ten associates who spent three weeks building the model. The model builds itself. What the client is left paying for - explicitly, visibly, without the execution overhead bundled in - is the judgment. And judgment, priced on its own, looks very different from judgment bundled with a hundred hours of associate time.

This is not a future disruption for professional services. It is happening now, in every major firm, managed as a productivity improvement and a headcount efficiency story. What it actually is: the systematic unbundling of expertise from execution. The firms that understand this clearly and restructure around it will thrive. The ones that manage it as a cost optimization exercise will find themselves competing on a price dimension they cannot win.

A quick reminder of the playbook: map your business to the eight patterns, then three moves - assess and defend your exposed revenue, re-engineer your core production around AI execution, and reposition as agent-first. This piece applies all three to professional services.

The pattern map - how professional services actually works

Professional services runs on a dense combination of patterns - more than most industries recognize about themselves. The diagnostic question is where the execution weight sits today and what the exposure looks like when AI runs those patterns instead.

High exposure - disrupting now

Research and analysis is the Investigator pattern running at scale. The associate who spends three weeks conducting market research, reviewing regulatory precedent, or analyzing a target company’s financials is executing an Investigator loop. Question arrives, information is gathered, hypothesis is formed, analysis deepens, insight is synthesized. AI runs this loop faster, more comprehensively, and without the constraint of a single analyst’s available hours. Legal research that took a junior associate a day takes an AI tool minutes. Due diligence that required a team of analysts takes a Conductor-plus-Investigator system hours. The productivity data is already in. The question is whether firms are restructuring around it or absorbing the gain as margin while preserving the headcount model.

A few years ago I was serving on a Customer Advisory Board for a VC. A software company on their radar was doing something genuinely interesting: using ML to convert natural language queries into SQL. The VC team had done thorough work - market sizing, competitive landscape, enterprise use cases, revenue modeling. Weeks of analysis. Good analysis. They were struggling to make the ROI case for enterprise customers and couldn’t get the numbers to work. I reviewed everything and asked one question: “Have you thought about an OEM strategy?” The room shifted. The moment you reframe a niche capability as something embedded into other software products rather than sold direct to enterprise, the entire customer model changes. They went back, did more analysis, and built a significantly stronger case. The original research was necessary. But it was the question - not the research - that unlocked the answer. That is the distinction the billing model has always obscured: the client paid one rate for the weeks of analysis and for the question that made it matter. Those are not the same thing. AI runs the analysis. The question is still yours to ask.

Document and artifact production is the Creator pattern. Every professional services engagement produces artifacts - memos, models, reports, contracts, presentations, filings. These have always been produced by humans who understood what was needed and built it from scratch or from templates. AI produces them from intent. The marginal cost of a first draft - whether it is a due diligence memo, a contract, a financial model, or a board presentation - is collapsing toward zero. The professional who used to spend half their week producing the artifact now spends that time refining and owning it.

Emerging - invest now

Engagement delivery coordination is the Conductor pattern. Every major professional services engagement has a program management layer - workstream coordination, client communication, status synthesis across teams. At a consulting firm this is the engagement manager. At a law firm this is the supervising partner’s coordination overhead. AI handles the coordination layer, surfaces the decisions that require human judgment, and runs the synthesis that currently consumes senior professional time.

Scenario and risk modeling is the Simulator pattern applied to client problems. Strategy scenarios, deal structure modeling, litigation risk assessment, tax scenario planning - these are simulation loops that professional services firms run on behalf of clients, constrained by the time it takes to build and run the models. AI expands the scenario space dramatically and compresses the time from weeks to hours.

Augmenting - human judgment stays

Client advisory and recommendation is the Advisor pattern in its purest form. The managing director who gives a CEO strategic advice, the partner who tells a board how to think about a risk, the counsel who advises a client on the decision they face - this requires human accountability, relationship trust, and the judgment that comes from having navigated similar situations before. AI augments the preparation. The recommendation and the relationship are human.

Negotiation and deal execution is the Negotiator pattern. The lawyer negotiating a transaction, the banker structuring a deal, the consultant facilitating a strategic decision between competing internal stakeholders - these are human-in-the-loop by design. The information asymmetry is narrowing, but the accountability and the relationship remain human.

Move 1 - Assess and defend

Two exposures require immediate attention in professional services.

The first is the junior and mid-level talent model. The pyramid structure of most professional services firms - many juniors, fewer seniors - exists because execution required headcount. Research, analysis, document production, coordination: these activities scale with people. AI executes all of them. The firms that have not mapped which of their revenue lines depend on junior execution are carrying a cost structure and a talent model that are structurally exposed. The defense posture is not to eliminate junior roles - it is to understand precisely which revenue lines they are executing, on what timeline that execution moves to AI, and what the restructured engagement model looks like.

The second is the client relationship. Professional services clients are becoming AI-literate faster than most firms have anticipated. A CFO who can run a preliminary analysis using AI tools before the engagement begins is a different kind of client than one who depended entirely on the firm’s information advantage. The medium-tier client relationship - not strategic enough to be deeply embedded, not transactional enough to be easily replaced - is where relevance risk is highest. The defense here is demonstrating, concretely and quickly, that the firm’s AI-augmented output is materially better than what the client can access themselves.

Move 2 - Re-engineer the core

The production processes most ripe for re-engineering in professional services are the ones that currently consume the most associate and manager time for the least differentiated output.

Research and due diligence. The Investigator pattern running on AI changes what is possible in every engagement that starts with a research phase. M&A due diligence, market entry analysis, regulatory review, competitive intelligence - these processes compress from weeks to days and expand in scope simultaneously. The firm that re-engineers its research production around AI doesn’t just save cost. It delivers a more comprehensive analysis than it could have produced manually, faster than the client expected. The senior professional stops reviewing the work the associates did and starts doing the work only they can do.

Document production. Every major professional services firm produces enormous volumes of documents - contracts, memos, models, presentations, filings. The re-engineered production process uses AI to generate first drafts from structured intent, with the professional reviewing, refining, and signing off. The cost of the production step drops dramatically. The quality of the review step improves because the professional is engaging with a complete draft rather than a blank page.

Engagement coordination. The re-engineered engagement model runs its coordination layer on AI - workstream tracking, client communication drafts, status synthesis, dependency management. The engagement manager’s role shifts from running the coordination to managing the exceptions and the client relationship. Senior professionals get time back that was previously consumed by oversight of coordination mechanics.

Move 3 - Reposition as agent-first

This is the move that most professional services firms are not yet having the right conversation about - and the one that determines whether they define the next decade or are defined by it.

The productized AI service. The firm that takes a high-volume, well-defined professional services workflow - an NDA review, a regulatory compliance check, a standard due diligence process, a tax filing for a defined entity type - and offers it as an AI-delivered service with professional accountability attached is creating something new. Not a software product. Not a consulting engagement. A professional service delivered primarily by AI, with the firm’s expertise embedded in the model and the firm’s accountability attached to the output. The price point opens markets that were previously inaccessible - the mid-market client who couldn’t afford bespoke advice at bespoke rates, the transaction that was too small to justify a full engagement team.

The expert-augmented advisory model. The partner who arrives at a client meeting having run comprehensive scenario modeling, synthesized every relevant precedent, and stress-tested their recommendation against a hundred edge cases is delivering something categorically better than the partner who arrived with the output of a two-week associate engagement. The client who has experienced the difference will not go back. This is the model that justifies premium rates - not because of credential or relationship alone, but because of demonstrably better output.

The knowledge platform. The most ambitious repositioning is turning the firm’s accumulated expertise into an accessible intelligence layer. A law firm’s decades of contract precedent, a consulting firm’s industry benchmarks and case experience, an accounting firm’s regulatory interpretation history - these are proprietary knowledge assets that, structured correctly, can be offered as AI-accessible products to clients who previously could only access them through expensive engagements. The firm becomes a knowledge platform as well as a services firm.

The resistance - what makes this hard in professional services

Four structural realities make the transformation harder than the economics suggest it should be.

The billing model is the business model. The hourly rate and the project fee are not just pricing mechanisms - they are the organizing logic of how professional services firms staff, manage, and evaluate engagements. Shifting to outcome-based or value-based pricing requires renegotiating not just client contracts but the internal economics of how partners are compensated and how engagement profitability is measured. That is a structural change that most firms are not organized to make quickly.

The pyramid is the talent pipeline. Junior professionals in most firms are not just executing work - they are being trained. The associate who does the research becomes the manager who supervises it becomes the partner who advises on it. When AI executes the research, the training path breaks. The firms that don’t actively redesign their talent development model will find themselves with a generation of senior professionals who never learned the foundational work that AI now does - and a pipeline that no longer produces the judgment capacity the model depends on.

Liability attaches to the human. In law, accounting, and most regulated professional services, the professional accountability that makes the Advisor pattern durable also creates specific resistance to AI deployment. The firm that puts its name on an AI-produced output is taking on liability that its risk and compliance frameworks were not designed for. Working through those frameworks - not around them - takes time and requires deliberate institutional effort.

Client trust is relational, not transactional. The professional services client relationship is built over years, often decades. The firm that deploys AI in ways that change the client experience without managing the transition carefully - fewer touchpoints, faster turnaround, less visible human involvement - risks damaging the relationship even when the output is objectively better. The transition requires client communication and expectation management as much as it requires technical capability.

The economic consequence

Professional services has historically been one of the most defensible business models in the economy. High barriers to entry, deep client relationships, regulatory protection in many domains, and a talent model that made the expertise hard to replicate. AI is eroding all four simultaneously - not destroying them, but narrowing the moat in ways that are already measurable.

The level-playing-field consequence is significant. A boutique advisory firm with three senior partners and AI augmentation can now deliver the research depth, analytical breadth, and scenario modeling that a large firm delivered with a twenty-person team. The talent advantage that large firms had - being able to throw headcount at a problem - is being replaced by a tools and judgment advantage accessible at any scale.

The bifurcation is the same as in every industry this series has examined: fast versus slow. The firms that move decisively - that re-engineer their production, build the productized service offerings, and develop the expert-augmented advisory model - will define what professional services looks like in five years. The ones that manage AI as a cost efficiency program while preserving the existing talent pyramid and billing model will find themselves in an increasingly untenable position as clients become more sophisticated and alternatives become more credible.

The unbundling of expertise from execution is not a threat to expertise. It is a clarification of what expertise is actually worth - and an opportunity for the firms whose expertise is genuine to demonstrate it without the execution overhead that used to obscure it.

Next: Telecommunications - an industry running on Reactive, Sentinel, and Conductor patterns at massive scale. Where the re-engineering opportunity is enormous and the agent-first play is largely untapped.

All four foundations are breaking simultaneously. The labor arbitrage assumed the work required humans - AI changes that entirely. The T&M model assumed more hours meant more value - AI makes outcomes measurable and time irrelevant. The client who paid for a senior architect was really paying for judgment that would outlast the technology choices made. What they were also paying for, bundled in, was the documentation, the diagrams, the review cycles, the steering committee presentation. AI produces all of that. The judgment is still the architect’s. The client is now being forced to see the difference. The years-of-experience credential was always a proxy for pattern recognition - AI has ingested every implementation pattern, every configuration guide ever published. The years mean nothing. The judgment still does. But judgment was never what most of the headcount was billing for.

The fourth foundation - ownership - was always the quiet failure of the offshore model. Delivery centers were optimized for following instructions rather than owning outcomes. “Because onshore told me to” was the correct answer in a model that priced compliance over judgment. When AI executes the instruction-following work, the only remaining value is the ownership mindset - the engineer who asks why, pushes back on a bad requirement, surfaces the problem before it becomes a crisis. That mindset was systematically undervalued. AI complies better than any human team. The thing the offshore model never built is now the only thing that matters.

Wall Street has already reached its own conclusion. Accenture lost $14 billion in market value after its Q2 2024 earnings fell short of expectations. By September 2025, it had laid off more than 11,000 employees as part of an $865 million restructuring, with CEO Julie Sweet explicitly stating that roles were being cut where reskilling was not a viable path. In India, the Nifty IT index’s one-year return turned sharply negative as investors repriced the structural exposure of traditional application development and maintenance services. Analysts estimate a 2-3% downside risk to IT services revenue growth over two to three years, with 2026 expected to see higher AI-led deflation as pilots move into production. This is not a market overreaction. It is the market pricing in the structural argument before most firms have acknowledged it publicly.

A quick reminder of the playbook: map your business to the eight patterns, then three moves - assess and defend your exposed revenue, re-engineer your core production around AI execution, and reposition as agent-first. This piece applies all three to IT services.

The pattern map - roughly five plays, give or take

IT services runs on roughly five plays - the lines blur and combinations vary by firm. Understanding which plays your revenue sits in is the diagnostic that makes the three moves specific.

Play 1 - Implement packaged software

Every major enterprise deployment - SAP, Workday, Oracle, Salesforce, ServiceNow - requires an implementation: workstream coordination across data migration, process design, integration, testing, training, and cutover. This is the Conductor pattern at its most complex, with Creator pattern running underneath it. The billing premium has always been justified by the claim that this expertise takes years to accumulate. AI is replicating it. What remains valuable is the judgment that goes beyond the documented pattern - the organizational dynamics, the decision to override the standard approach. That judgment is real. It is also a small fraction of what most implementation engagements bill for.

A ServiceNow implementation I encountered a few years ago is a reasonable illustration. Months of business process mapping and fit-gap assessments with system experts came first. Then an army of business analysts, configuration specialists, and custom code developers. Then the project managers - one layer to manage the delivery army, another to manage my leadership team. Then the client-side mirror: our own people with other day jobs pulled into workstreams they hadn’t planned for, and our own PM to manage the relationship with their PM. I will not delve into the outcome of the project. What I will say is that it was the moment I decided this was not where I wanted to build a career - not because the people weren’t capable, but because the model itself was the problem. The value being delivered was not proportional to the complexity being generated.

Play 2 - Product support

A significant portion of IT services revenue comes from software product companies who use services firms for QA testing, PM support, ancillary product development, and documentation. The work is almost entirely execution - pattern-following at scale.

A large QA operation in a product company has more layers than most people outside it realize. The first layer is in-sprint QA - testers embedded with development teams, catching defects before they compound. The ratio is roughly 5:3 developers to QA engineers at this layer alone. The second layer kicks in when the sprint closes: regression testing, integration testing, performance testing, security testing. The third layer tests as a customer would - product readiness, end-to-end scenarios. Then the management layer to coordinate all three. Then, if the organization has the appetite, a QA automation team whose mandate is to automate the manual work the other three layers are doing. And sitting above it all, occasionally, QA process professionals whose primary output is the quality assurance manual. This is before the penetration testers and compliance teams arrive for their own separate review cycles. AI collapses most of this structure. Test case generation, regression execution, integration validation, performance simulation - pattern-following at scale. The in-sprint QA ratio that justified armies of testers is a direct function of the cost of human test execution. When that cost approaches zero, the ratio becomes a rounding error.

Play 3 - Cloud transformation

Cloud migration became one of the largest IT services revenue streams of the last decade - migration assessment, application refactoring, infrastructure configuration, hyperscaler relationship management. This play runs on Conductor and Creator patterns. AI is automating large portions of both, and the three major cloud providers are building AI-powered migration tools themselves - they have every incentive to make migration cheaper and no incentive to preserve SI services revenue.

The hyperscaler credit economy deserves a closer look because it shaped a decade of IT services revenue in ways that had very little to do with good architecture. A few years ago I was approached by my cloud provider to migrate my applications to the cloud. They offered significant funding - credits that reduced the cost of migration by more than 70%. The SI came with the package. And that is where the incentive misalignment began. My objective was clear: build a scalable cloud architecture that would reduce future infrastructure costs, eliminate the data center overhead, and lower ongoing support spend. The cloud provider’s objective was to start billing me on their platform as quickly as possible. The SI’s objective was to generate as many billable hours as the engagement would bear. The shortest path to cloud billing - lift-and-shift, minimal re-architecture, maximum team size - served two of those three objectives perfectly. Mine was not one of them. We recognized the misalignment, declined the path being recommended, and did the migration slowly and selectively on our own terms. Not every CTO has the standing or the inclination to push back. The hyperscaler credits run into enormous sums across the industry - and the providers have historically shown little interest in how those dollars are spent, only that they are spent on migration. Many SIs took full advantage: higher than normal rates, inefficient team sizes, migration architectures that maximized cloud spend rather than optimized it. The cloud transformation business was, in many cases, a credit arbitrage operation dressed as strategic advisory. AI doesn’t fix misaligned incentives. But it does eliminate the army of people that the misalignment was used to justify.

Play 4 - Maintain, support, and operate

The ongoing revenue stream - L2 and L3 support, application maintenance, database administration, BI and ETL development and maintenance, monitoring and incident response - is the Reactive and Sentinel patterns running on human headcount at scale.

It is worth being honest about this play: the managed support and maintenance model was one of the best uses of offshore delivery the IT services industry ever developed. It worked well for both sides. Own the ticket, fix the issue, close the loop. Own the ETL job, build it to spec, maintain it when it breaks. Instructions were clear. Productivity was measurable. Some providers moved to ticket-based pricing. Many contracts had built-in incentives for the delivery team to reduce their own headcount by five percent year on year as they learned the environment. The model was self-improving by design. The BI and ETL layer sat in the same category - data pipelines, ETL scripts, transformation logic, reporting layers. Unglamorous work. Significant revenue. The very simplicity that made this model work is what makes it the most vulnerable play today. AI learns ETL patterns and ticket resolution logic faster and more completely than any offshore team. The disruption here is not gradual. It is the fastest and most complete of all five plays.

Play 5 - Global Capability Centers

GCCs - dedicated offshore capability centers built by enterprises to capture the cost arbitrage without the SI margin - were created with three explicit objectives, and the gap between aspiration and reality tells you everything about why AI disrupts this model so completely.

The first objective was domain expertise. The GCC was supposed to create an insurance-focused developer, a retail-domain business analyst - not just a Java developer or a SAP BA. Domain expertise did develop, but depth remained a question. Exposure to end customers was limited by design. The offshore team saw the ticket, the requirement, the specification. They rarely saw the business problem that generated it. The contextual judgment that comes from sitting with the customer never transferred. The second objective was cost control. This worked in the early years and then compounded in the wrong direction. With eight to ten percent annual wage inflation in India, a GCC that hired aggressively in its first three years is carrying a cost structure five years later that looks nothing like the original business case. Some GCC cost structures went entirely uncontrolled - the margin story quietly disappeared while the headcount kept growing. The third objective was ownership - solving the “onshore told me to do it that way” problem. The mindset shift required was fundamental: from “my success is my team size” to “my success is my work product’s success.” That shift has been the hardest to make. Incentive structures inside most GCCs still reward headcount growth and delivery velocity - not outcome quality.

GCCs have still largely been commercially successful - many built in partnership with SIs who provided the controlled environment, branding, and HR infrastructure. AI breaks all three value propositions simultaneously. Domain expertise advantage is compressed by AI that has ingested every domain pattern. Cost advantage is under pressure from AI execution that costs less than even the most efficiently run offshore team. And the ownership deficit becomes existential when AI executes the instruction-following work. The value of a GCC was always the volume of capable, affordable headcount. AI eliminates the value of the volume.

Move 1 - Assess and defend

Two exposures demand immediate attention. Revenue concentration by play - most IT services firms have significant exposure in Plays 2 and 4, which are the most immediately disrupted. Map it precisely by client and contract, and prioritize the conversations before the client has already decided to move. And the talent model - the defense posture is not to maintain the bench but to identify clearly which capabilities have genuine expertise value and invest in developing those deliberately rather than letting attrition make the decision.

Move 2 - Re-engineer the core

The re-engineered implementation engagement shifts from a large execution pyramid to a smaller team of domain experts applying judgment to what AI produces - faster delivery, lower staffing cost, more consistent output. The re-engineered QA function uses AI testing frameworks for test generation and regression execution; human QA shifts to strategy and edge case evaluation. The re-engineered support and BI operation deploys AI agents on the L2/L3 queue and data pipeline maintenance; humans handle what requires genuine architectural judgment. The re-engineered cloud practice uses AI for migration mechanics; the architect focuses on the decisions that actually require strategy.

Move 3 - Reposition as agent-first

The IT services firm that encodes its implementation knowledge into an AI-accelerated delivery product offers something a client cannot build and a generic platform cannot replicate - not “we will send you a team” but “we will deploy your platform in half the time at half the cost, with our domain expertise embedded in the AI.” Outcome-based, not time-based. The managed operations service sells guaranteed outcomes - availability SLAs, incident response, continuous improvement - delivered by AI agents with human oversight. Better service, lower price, better margin. The GCC transformation play offers enterprises a path from headcount model to AI-augmented capability model, retaining strategic value while eliminating execution overhead.

The PS arm of a SaaS company deserves its own examination because the disruption here is structural in a way that most SaaS vendors have not yet fully reckoned with. There has always been a PS economy built around software products. In the on-premise era, the implementation-to-ARR ratio was roughly 1:2 - for every dollar of software revenue, two dollars of services revenue followed. With SaaS, that ratio dropped to approximately 1:0.5 as cloud delivery simplified deployment and vendors competed on time-to-value. The problem was already brewing before AI arrived. But PS revenue was never just the one-time implementation. The SaaS complex economy had multiple layers: configuration and integration at go-live, enabling new features, developing custom modules, maintaining customizations through upgrades, performing QA on behalf of customers. Each layer generated recurring services revenue. AI is compressing every layer simultaneously. Implementations become dramatically simpler when AI can generate configuration recommendations and map integrations automatically. At Aptos, I am building an Integration Concierge - an AI agent that takes a description of what needs to be integrated and produces a working integration in days rather than weeks. Custom modules are increasingly being built by customers themselves using AI coding tools. Feature enablement is being AI-facilitated through contextual guidance embedded in the product. Upgrades are being automated. The SaaS complex economy is shrinking - and fast. The PS organizations that defend the existing revenue model while AI systematically eliminates the work that justified it will find the shrinkage accelerating beyond their planning assumptions.

The resistance - what makes this hard

The T&M model bills hours - more hours means more revenue. Re-engineering delivery around AI voluntarily compresses top-line revenue in the short term, which is a rational trade and a very difficult board conversation when quarterly revenue is the primary metric. Client contracts specify resource levels and time commitments - transitioning to outcome-based models requires renegotiating agreements written for a different world. The talent base was built for execution, not judgment - developing genuine advisory capacity from a compliance-optimized workforce is a multi-year transformation, not a retraining program. And the ownership deficit is cultural. Delivery teams were rewarded for compliance - team size, utilization, velocity. Reorienting from “my success is my team size” to “my success is my work product’s success” requires leadership will that most organizations underestimate. When the instruction-following work moves to AI, teams that never developed ownership have nothing left to offer. The cultural transformation is the survival condition.

The economic consequence

The offshore arbitrage was always a labor arbitrage, not an expertise arbitrage. AI eliminates the labor cost. The arbitrage is gone. What survives is genuine expertise - implementation knowledge accumulated over decades, domain understanding that goes beyond the documented pattern, client relationships built over years. Real assets. Also a small fraction of what most IT services firms have been billing for.

A boutique firm with deep domain expertise and AI augmentation can now deliver what a large SI delivered with a hundred-person team. The talent advantage of scale is being replaced by a tools and judgment advantage accessible at any scale. Fast versus slow. The firms that move decisively will emerge stronger. The ones that preserve the T&M model and the talent pyramid will find themselves in an accelerating race to the bottom, competing against AI tools with no margin requirements and no bench to carry.

The years-of-experience premium is gone. What remains is the judgment that those years - in the best cases - actually produced. It is time to price it honestly, deliver it efficiently, and stop bundling it with execution overhead that AI now renders unnecessary.

Next: Professional Services - law firms, management consulting, accounting, and financial advisory. A different kind of expertise business, with different pattern profiles and a different disruption dynamic. Where the billing model is even more bundled and the unbundling even more consequential.

Retail CEOs are carrying two distinct sets of concerns right now, and most AI conversations only address one of them. The first is operational: margins compressing for a decade, store labor that is simultaneously the largest cost and the primary service differentiator, inventory decisions made months in advance for a customer whose preferences shift in weeks. These are execution problems. They have always been execution problems. What changes is that the operational layer - a thousand decisions a day across stores, supply chains, and digital channels - is now something AI can run faster, cheaper, and more continuously than any human organization can.

The second set of concerns is less discussed but more consequential for valuation: the customer relationship. AI doesn’t just automate what retailers already do. It enables a precision and personalization of customer engagement that was previously impossible at scale. The Concierge Agent that identifies a high-value customer who hasn’t visited in six weeks, knows their purchase history and size preferences, and initiates a relevant, timely conversation that drives a store visit - that is not a cost reduction. It is a new revenue motion. The retailer who deploys it has a commercial capability their competitors don’t.

The same logic extends to product creation and sourcing. AI-assisted trend analysis that synthesizes consumer signals, social data, and competitive positioning in real time changes what the buying team can see before they commit. AI-generated product content that adapts to individual customer context changes the conversion surface. These are not efficiency improvements layered onto existing processes. They are structural expansions of what a retail business can do commercially.

The disruption in retail is not coming from a new kind of company. It is coming from the widening gap between retailers rebuilding their execution layer and commercial capabilities around AI - and those managing it as an efficiency initiative. That gap is already measurable. In three years it will be structural.

A quick reminder of the playbook: map your business to the eight patterns, then three moves - assess and defend your exposed revenue, re-engineer your core production around AI execution, and reposition as agent-first. This piece applies all three to retail.

The pattern map - how retail actually works

Retail runs on more patterns simultaneously than almost any other industry. The diagnostic question is not which patterns retail uses - it uses most of them - but where the exposure sits and on what timeline.

High exposure - disrupting now

Three business functions are running on patterns that AI is already executing at scale elsewhere, and where the disruption timeline is shortest.

Customer-facing operations - abandoned cart recovery, loyalty threshold responses, returns and exchange handling, contact centre resolution - are Reactive loops. An event arrives and a response is required. Today those responses involve humans at multiple points. AI closes the loop faster, cheaper, and without the labor overhead. The retailers who have moved here are already compounding the advantage.

Supply chain - stockout replenishment triggers, inventory drift detection, supplier delay alerts - combines the Reactive and Sentinel patterns. Something happens and the system responds; simultaneously, something is drifting toward a problem and needs to be caught before it becomes a crisis. Most retailers catch these signals in weekly reviews. A Sentinel agent catches them in real time, before the cost compounds.

Store operations - dynamic task assignment, compliance and shrinkage monitoring, price change propagation - runs on Reactive, Sentinel, and Conductor patterns simultaneously. Tasks need to be assigned based on real-time conditions. Anomalies need to be caught continuously. Workstreams across a store opening or promotional event need to be coordinated. The store manager running all of this manually is the most expensive coordinator in retail.

Emerging - invest now

Two functions are earlier in the disruption curve but moving fast, and where the investment made now compounds.

Merchandising and buying runs on the Investigator and Simulator patterns. Trend analysis, competitive intelligence, buying plan scenario modeling, promotion design and post-mortem - these are research and modeling loops that today require teams of analysts and weeks of work. AI compresses them to hours and expands the scenario space from five to five hundred. The merchant’s role shifts from executing the analysis to interrogating it.

Marketing and content runs on the Creator and Conductor patterns. Personalised outreach at scale, product descriptions, campaign creative, seasonal launch coordination - the marginal cost of producing this content is collapsing toward zero. The retailer still running a content team manually producing copy for ten thousand SKUs is carrying cost that is already obsolete.

Augmenting - human judgment stays

Two functions remain firmly in the human domain - not because AI can’t assist, but because the decisions carry accountability that requires a human to own them.

Buying strategy and vendor management - buying decisions, brand partnership strategy, vendor negotiations, real estate portfolio decisions - runs on the Advisor and Negotiator patterns. The analysis is AI-augmented. The decision and the relationship are human.

Capital and strategic planning - market entry modeling, portfolio stress testing, pricing strategy - runs on the Simulator and Advisor patterns. AI models a thousand scenarios. The executive committing capital is still the human applying judgment to what the model produces.

Most large retailers, in my experience, are still in the early stages of this transition - and moving more slowly than the opportunity warrants. Customer-facing automation is the most attacked area, with LLM-based agents now handling support interactions in ways that genuinely feel different from the rule-based chatbots that came before. The supply chain instrumentation is a different story - most of what is running there still relies on traditional automation and pre-LLM approaches. The event-driven replenishment triggers, the inventory monitoring, the demand signals - that work has been underway for years and largely hasn’t made the leap to LLM-based execution yet. The genuinely new capability is only beginning to land.

Store operations is the area that has changed least. Two observations from the fashion, footwear, and apparel segment - which is where my direct exposure sits, with the caveat that the big box operators are considerably further along. The first is a fashion retailer with a strong customer-centricity culture, where the store associate is the product. These are experienced sellers who operate their section of the store like a small business - they know their customers, they drive repeat visits, they own the relationship. This retailer has moved beyond traditional BI and analytics in meaningful ways, deploying AI tools that give those associates better signal about who to reach out to and when. The model is not replacing the associate. It is making the associate more effective at the thing they were already exceptional at. The second observation is associate training - an area where AI adoption has been notably high. Consider a mixed cart return: a customer arrives at the register with items from multiple transactions, some eligible for return, some not, some subject to different policies. It gets complicated fast. The traditional response is a supervisor call - a delay, a queue, a frustrated customer. An AI agent invoked in that moment can either guide the associate through the resolution or, in more advanced deployments, facilitate the transaction directly. Most retailers are at the former stage. The latter is where this is heading.

Move 1 - Assess and defend

Two exposures demand immediate attention.

The first is labor. The Reactive pattern accounts for the majority of frontline retail labor - contact centre agents, fulfillment teams, store associates responding to operational exceptions. AI is already executing these loops in production at retailers who have moved. The organizations that haven’t are carrying a cost structure that is structurally exposed on a two to three year timeline. The defense posture here is a clear map of which labor-dependent Reactive loops are most at risk and a timeline for rebuilding them before a competitor’s cost advantage becomes visible to customers.

The second is the customer relationship. Loyalty runs on relevance, and relevance is eroding faster than most retailers recognize. The medium-tier loyalty customer - not engaged enough to be sticky, not disengaged enough to have already left - is the segment most at risk. Not from a competitor’s better product, but from a competitor’s better signal detection. The defense here is identifying that segment precisely and getting ahead of the relevance decline before it becomes churn.

Move 2 - Re-engineer the core

The production processes in retail most ripe for re-engineering are not the ones that look most like automation. They are the ones where human execution of a pattern has been the constraint on speed, quality, and commercial reach.

Merchandising and buying. The buying decision today is made by humans working from historical data, market intuition, and vendor relationships. The Investigator and Simulator patterns applied here produce something qualitatively different: a buying recommendation built on real-time demand signals, competitor pricing, trend data, customer behavioral patterns, and scenario modeling across hundreds of variables simultaneously. The merchant’s role shifts from building the analysis to challenging it - applying the judgment that comes from knowing a category, a customer, and a vendor relationship in ways the model doesn’t. Better decisions, made faster, with fewer expensive mistakes at the margin.

Supply chain planning. The weekly S&OP process - demand planning, inventory positioning, replenishment decisions - is a Conductor pattern running on a large team of planners, analysts, and coordinators. The re-engineered version runs the coordination layer autonomously, surfaces the decisions that require human judgment, and executes routine replenishment without human involvement. The planning team stops aggregating spreadsheets and starts managing exceptions and edge cases.

Content and marketing production. The content surface in retail is enormous - product descriptions, promotional copy, personalised outreach, visual merchandising guidance, campaign creative across dozens of channels. Today this requires significant headcount and produces inconsistent output at high cost. The Creator pattern running on AI produces this content at scale, adapted to individual customer context and channel requirements, at a fraction of the current cost. The marketing team shifts from producing content to defining the brief and curating the output.

Move 3 - Reposition as agent-first

This is the move that separates the retailers who survive the transition from the ones who lead it.

The Concierge Agent. A retailer that deploys a personalised AI agent - one that knows a specific customer’s purchase history, preferences, loyalty status, and local store inventory - and uses it to initiate a relevant, timely conversation with that customer is not automating outreach. It is offering something that did not exist before: a shopping relationship that feels personal, responds in real time, and drives conversion without requiring a human associate to initiate every interaction. The commercial model for this is not an internal efficiency story. The retailer that can demonstrate measurable sales lift from Concierge Agent interactions is offering their brand partners and wholesale vendors a capability they will pay for. The agent becomes a revenue line, not just an operational tool.

Precision sourcing and product creation. AI-assisted trend synthesis changes the buying team’s view before they commit capital. The retailer whose buyers are working from a real-time synthesis of consumer signals, social data, and competitive positioning is making fundamentally better sourcing decisions than the one whose buyers are working from last season’s sell-through and a trade show visit. At scale, this is a margin story: fewer wrong bets, faster response to emerging signals, less inventory trapped in categories that already peaked.

The platform play. The most ambitious version of the agent-first repositioning is owning the intelligence layer. A retail technology platform that exposes operational data - inventory, customer, transaction, supply chain - through an AI-accessible layer becomes the foundation that brands and operators build their agent strategies on top of. The platform stops being a system of record and becomes a system of intelligence. Customers and brand partners build on it rather than around it.

My early conversations with retail CIOs about the Concierge Agent have been genuinely encouraging - and revealing about where the real pain sits. Store traffic is a critical metric in the fashion, footwear, and apparel segment. Every CIO I have spoken with knows this and is actively trying to move it. What they also know is that their existing CRM tools have been attempting the same thing for years - and consistently falling short. The problem is precision. The message goes out to a broad segment. The product-to-customer match is approximate. The conversion to actual foot traffic is a small fraction of what the model predicted. The signal-to-noise ratio is poor enough that customers start ignoring the communications entirely.

The Concierge approach is landing differently in these conversations. The specificity of matching a known customer to a relevant product, an in-store event, or a moment when their size is actually in stock at their nearest location - that is the precision the CRM model never had. The response has been less “interesting technology” and more “this solves a problem we have been trying to solve for a long time.”

What has been equally notable is the shift in the conversation itself. For most of my interactions with retail technology leadership, the framing is maintain and don’t break - keep the systems running, minimize disruption, manage the upgrade cycle. The Concierge Agent conversation is a revenue conversation. It is about driving traffic, increasing basket size, improving loyalty tier progression. That shift in framing - from cost center to revenue contributor - changes the energy in the room. It has changed ours too.

The resistance - what makes this hard in retail

Four structural realities slow the transformation in retail more than in most industries.

Legacy systems at the core. Most large retailers run on transaction processing infrastructure designed before real-time data architecture existed. The Reactive and Sentinel patterns require clean, fast event streams from the operational layer. Getting those streams out of a legacy POS and OMS is an integration problem that takes time and engineering investment to solve before any of the AI applications on top of it can work properly.

Organizational structure mirrors the old process. Retail organizations are structured around the functions that the old production process required - buying teams, planning teams, marketing teams, store operations teams. The re-engineered production process cuts across those structures. The merchant who owned the buying decision end to end is now one input into an AI-augmented recommendation. That is a political problem as much as a technical one.

Customer trust is fragile. Retail customers have a low tolerance for AI interactions that feel impersonal, irrelevant, or manipulative. The Concierge Agent that sends the right message at the right moment builds trust. The one that sends the wrong message at the wrong moment - or that feels like surveillance rather than service - destroys it faster than any human misstep would. The bar for behavioral model quality is high, and the cost of getting it wrong is a customer relationship, not a support ticket.

The physical layer moves at a different clock. Retail is not a pure digital business. Inventory is physical. Stores are physical. Supply chains involve physical goods moving through physical infrastructure. The AI can optimize the decision layer in real time. The physical layer responds on a different timeline. The gap between what the model says and what the supply chain can execute is where most retail AI initiatives underdeliver against their promise.

The economic consequence

The retail industry has historically rewarded scale. The largest retailers could afford the best systems, the most sophisticated planning teams, the deepest vendor relationships. AI is changing that equation in a way that most large retailers haven’t fully reckoned with.

The cost of deploying serious AI capability - Reactive loop automation, Sentinel monitoring, Concierge Agent outreach, AI-assisted trend analysis - is a fraction of what equivalent capability required even five years ago. A mid-size regional retailer can now instrument its supply chain, personalize customer outreach, and model buying scenarios with tools and economics that were previously available only to the largest operators. The investment required to be genuinely competitive on the execution and customer engagement dimensions is no longer a function of scale.

This is the level-playing-field consequence of AI in retail. The large incumbent whose advantage was operational sophistication and data depth will find that the moat is narrower than it looks. The smaller, nimbler retailer who moves decisively on the three-move playbook - defends its loyalty base, rebuilds its core processes, deploys a Concierge Agent - can close the gap on customer relevance and operational efficiency faster than any previous technology cycle allowed.

The bifurcation that matters is no longer large versus small. It is fast versus slow. The retailers who move - regardless of size - will define the next decade of the industry. The ones who wait, regardless of how large they are, will find the window closing faster than their planning cycles anticipated.

Retail has always rewarded execution. What changes now is that execution capability is no longer the exclusive property of the companies that could afford to build it.

Next: IT Services - the industry built on labor arbitrage, billed by the hour, and credentialed by years of experience. All three foundations are breaking simultaneously.

What I found is that work has always followed eight patterns. Not nine. Not twelve. Eight. And they haven’t changed in decades, maybe centuries. The Reactive loop that a claims adjuster runs today is architecturally identical to the one a medieval toll collector ran. The Investigator loop that a market researcher runs is the same loop a Renaissance natural philosopher ran. The Conductor pattern that a program manager runs is the same pattern a military logistics officer ran. The patterns are ancient. What changes is who - or what - executes them.

This series has gone deep on each pattern. What I want to do in this final piece is step back and answer the questions the series has been building toward. Not “what is happening” - that case has been made across eight pieces. But “what do you actually do with this?” The practitioner question. The one that matters when you put down the reading and go back to your organization.

The disruption is not uniform - and the sequence matters

The first thing to understand about acting on this framework is that the eight patterns do not disrupt on the same timeline. Some are already being executed by AI at scale. Others are years away from full displacement. Getting the sequence wrong - investing in defending patterns that are already gone, or ignoring patterns that are actively being attacked - is the most common and costly mistake organizations make.

Here is the honest sequence, as best as I can read it.

Already executing autonomously at scale: Reactive and Sentinel. The infrastructure exists, the economics are proven, and the early movers are already compounding. If your business runs primarily on these patterns - high-volume event-driven workflows, continuous monitoring and detection - the disruption is not coming. It is here. The question is whether you are restructuring on your own terms or waiting to restructure under pressure.

At KORE, where I was CTO, we managed connectivity for IoT devices at scale - machines that couldn’t go dark. When a device stopped responding, a Level 2 operator took the call, ran a defined sequence, issued a SIM reset, and filed a precise ticket describing the customer’s business and the exact failure. The work was real. The pattern was fixed. The human executing it was, in retrospect, optional. That loop is running on AI agents today. The question is whether it is running on yours.

Executing well in bounded contexts, expanding fast: Creator and Investigator. AI-generated artifacts and AI-driven research loops are production-grade in most professional domains. The productivity multipliers are real and documented. The displacement of roles that primarily executed these patterns is already visible in hiring data across software engineering, marketing, consulting, and legal research. The window for organizations to restructure around these patterns on their own terms is narrow.

Emerging capability, rapid maturation: Conductor and Simulator. The architecture is proven, production implementations exist, and the economic case is clear. But the deployment curve is earlier - most organizations are in early adoption rather than full displacement. The organizations that invest in Conductor and Simulator capability now are building a compounding advantage. The ones that wait are watching that advantage accumulate on the other side.

Structurally durable, augmenting fast: Advisor and Negotiator. The human stays in the loop by design - not because AI can’t execute, but because the pattern requires human accountability, relationship trust, and the judgment that comes from having skin in the game. AI is raising the quality ceiling of what advisors and negotiators can deliver. The displacement here is not of the human but of the layer that was doing synthesis and research without adding genuine judgment. The credential without the judgment is what gets displaced.

The strategic implication: your sequencing priority should match where your organization’s exposure actually sits - not where the general AI narrative says the disruption is happening. A professional services firm primarily running Investigator and Creator patterns faces a different and more immediate challenge than a financial services firm running Sentinel and Advisor patterns. The framework’s value is in making that specificity legible.

The services disruption is not a prediction - it is happening now

I have made one claim throughout this series more consistently than any other, and I want to restate it plainly in the close: services businesses will be disrupted faster and more completely than SaaS companies. Not eventually. Now.

The reason is structural and it does not require prediction. SaaS companies systematized patterns into software. They have switching costs, deep integrations, long-term contracts, and compounding product moats. AI disrupts them - but it disrupts them incrementally, as a better version of what they built, constrained by the same customer relationships and switching cost economics they built their defensibility on.

Services businesses have none of that. Their product is human execution of a pattern. A consulting firm’s product is humans executing the Investigator and Creator patterns. A law firm’s product is humans executing the Investigator, Advisor, and Negotiator patterns. An IT services company’s product is humans executing the Reactive and Conductor patterns. When AI can execute the same patterns at a fraction of the cost, there is no switching cost protecting the incumbent. The billing model doesn’t evolve. It collapses.

This is already visible in the economics of every major professional services category. The productivity multipliers are not theoretical. The headcount math is being done inside every major firm right now, reframed as efficiency improvement and digital transformation. What it actually is: the systematic removal of human execution from patterns that AI now runs better, faster, and cheaper. The firms that acknowledge this clearly and restructure around it will survive. The firms that manage it as a cost optimization exercise will not recognize the existential nature of what is happening until it is too late.

The bifurcation inside every role

Across eight patterns and dozens of professional roles, one structural consequence appears again and again. The bifurcation.

Every role being disrupted by AI splits into two fundamentally different kinds of work. The thinking work - judgment, risk assessment, relationship management, the questions nobody asked yet - survives and often expands with AI augmentation. The grunt work - production, aggregation, synthesis, routing, formatting - moves to AI execution.

Early in my consulting career, I was on an engagement in Australia where the client wanted more visibility into our approach. Consultants were pulled off delivery to write an approach document. Then a document explaining how to navigate the approach document. Then a summary for stakeholders who didn’t have time for the full version. A colleague named Freddi looked up from his screen and delivered the most precise diagnosis of consulting waste I have ever heard: “I don’t have time to review your approach document, or the summary to the approach, or the approach to the summary.” Four consultants, billing by the hour, producing documents about documents. The intent existed. The judgment existed. The production cost was the entire problem. That is the Creator pattern’s grunt work in its purest form - and it is exactly what AI now eliminates.

This is not a comfortable message for the people whose careers have been built primarily on grunt work. But the bifurcation is not a future scenario. It is visible right now in the PM who still spends most of their week on status reports. In the associate who still spends most of their week building models. In the analyst who still spends most of their week assembling decks. In the advisor who still spends most of their week on research synthesis.

The people in those roles have a choice that is narrowing. They can move toward the thinking work - develop the judgment, the client relationships, the organizational credibility that AI cannot replicate - and find that AI gives them leverage they never had before. Or they can continue executing the grunt work and find that AI does it better, faster, and without the overhead.

The organizations that create the conditions for that transition - that invest in developing judgment capacity rather than just deploying productivity tools - will build a fundamentally more capable workforce. The ones that simply deploy AI to compress headcount will save money in the short term and hollow out their institutional knowledge in the medium term.

The Playbook: What You Do After You’ve Mapped

I get asked this question more than any other. You’ve read the patterns. You’ve mapped your business - your revenue lines, your functions, your products - against the eight. You can see where the exposure is and roughly on what timeline. Now what?

Three moves. They run in parallel once you’re clear on the map. The sequencing is about priority and dependency, not about finishing one before starting the next.

Move 1 - Assess and defend.

The map tells you where the exposure is. The first move is to quantify it precisely and protect what matters most. Not at the category level - at the revenue line level. Which customers, which products, which service lines are most exposed, on what timeline, with what renewal or retention pressure in the next twelve to eighteen months.

The output of this move is a defense posture: which relationships get immediate attention, which contracts need restructuring, which product lines need acceleration to stay competitive. This is not a strategy exercise. It is a working list with owners and deadlines.

The mistake most organizations make here is treating this as the whole response. Defending what you have buys time. It does not change the trajectory. A law firm that extends client relationships without changing how it delivers legal work is deferring the problem, not solving it. Defense is necessary. It is not sufficient.

Move 2 - Re-engineer your production.

This is the first offensive move - and it is structurally different from defense. You are not protecting existing revenue. You are rebuilding how the work gets done.

Every business running on the eight patterns has a production process - the way the work actually flows from input to output. A software company has an engineering process. An insurance carrier has a claims process. A law firm has a research, drafting, and review process. A consulting firm has an analysis and delivery process. In every case, that production process was designed around human execution of the patterns. AI changes what that process can look like - dramatically.

The re-engineering move is to take your core production process and rebuild it around AI execution of the pattern layer. Not automate the edges. Rebuild the core. The insurance carrier that rebuilds claims processing around AI execution - with humans reviewing only what genuinely requires judgment - is not doing the same work more efficiently. It is running a structurally different operation with structurally different economics. The law firm that rebuilds legal research and drafting around AI execution is not just faster. It is operating at a cost basis that changes what it can profitably offer and to whom.

This is where the margin expansion comes from. And that margin funds the third move.

Move 3 - Reposition as agent-first.

This is the move most organizations haven’t thought through yet. And it is the one that separates the firms that define the next decade from the ones that survive it.

You have mapped your patterns. You have defended your revenue. You have rebuilt your production around AI execution. Now the question is: can you offer that AI execution as a product - and stand behind what it produces?

The law firm that offers an NDA agent, prices it on outcomes, and puts its professional reputation behind the output is not automating a workflow. It is creating a new commercial model. One that opens a market that didn’t exist before - clients who couldn’t afford bespoke legal work at bespoke rates but will pay for AI-delivered work with professional accountability attached. The insurer that offers an underwriting agent to brokers. The consulting firm that offers AI-executed market analysis as a product. The SaaS company that exposes its platform as the layer enterprise customers build their own AI agents on top of.

In each case the move is the same: take the pattern execution you have rebuilt internally and offer it externally as a commercial capability. With skin in the game. That last part is what makes it defensible - the professional accountability, the domain expertise behind the agent, the willingness to stand behind what it produces. That is not something a generic AI platform can replicate. It is the thing that only you, with your domain depth and your client relationships, can credibly offer.

This is disrupting yourself before someone else does it for you. The firms that move here first will define their categories. The ones that wait will find themselves competing against the ones that didn’t.

Three moves. One sequence.

Defend what you have while you still have the relationships and the runway to act. Re-engineer your production before the margin compression forces you to do it under pressure. Reposition as agent-first before a competitor or a new entrant does it first and takes the market you could have owned.

The map tells you where you are. The playbook tells you what to do next. The only variable is whether you move before the window closes or after.

What comes next in this series

The eight patterns are the framework. The playbook is the action model. What comes next is applying both to specific industries - not at the category level, but at the level of real business processes, real revenue lines, and real decisions that leaders in those industries are making right now.

Each industry piece will take the three-move playbook and run it through a specific sector: which patterns that industry runs on, where the exposure sits, what re-engineering the production process actually looks like, and what agent-first repositioning could mean commercially. The goal is not analysis. It is a working template that a leader in that industry can pick up and use.

The industries I am planning to cover, in order:

Retail - first, because it is the industry I know best and because the Reactive pattern disruption is already the most visible. The Concierge Agent opportunity, the re-engineering of merchandising and supply chain operations, and what agent-first retail looks like in practice. Publishing May 18.

IT Services - the industry built on labor arbitrage, billed by the hour, and credentialed by years of experience. All three foundations are breaking simultaneously. Publishing May 26.

Professional Services - consulting, law, accounting. The industry most exposed to the Creator, Investigator, and Conductor patterns. What re-engineering delivery actually means for a Big Four firm or a mid-market law practice, and what the agent-first commercial model looks like when professional accountability is the differentiator.

Telecommunications - an industry I know from the inside, having led technology at a global IoT connectivity platform. Telecom runs on a dense combination of Reactive, Sentinel, and Conductor patterns at massive scale. The re-engineering opportunity is enormous. The agent-first play - offering connectivity intelligence as an autonomous capability rather than a managed service - is largely untapped.

Beyond these four I have a working list - financial services, healthcare, manufacturing - but I want to hear from you. Which industry do you want the playbook applied to? Which business processes in your sector feel most exposed, most ripe for re-engineering, or most ready for an agent-first commercial model? I will prioritize based on where the conversation goes.

Reply in the comments or reach out directly at ctolayer.substack.com. The best industry deep dives will come from the people living inside them.

The Execution Layer continues with industry deep dives beginning May 18. Retail first.

Game theorists have a precise name for this structure. It is a Bayesian game — a game where each player has private information about their own type, and must form beliefs about the other player’s type from the signals they observe. The entire craft of negotiation — anchoring, bracketing, strategic concession patterns, deliberate ambiguity, the walkaway that may or may not be real — exists because of that informational structure. Every move is both a signal and a probe. Every concession reveals something and obscures something else. Two magicians showing tricks to each other, each trying to infer the other’s deck from what gets revealed.

AI is changing the information structure of that game. Not completely, and not all at once. But structurally, and faster than most negotiators have recognized. And when the information structure changes, the equilibrium shifts — with precise, well-understood consequences for where advantage now lives.

The pattern, precisely defined

The Negotiator pattern is the most structurally complex in this framework. Every other pattern involves a single principal — a goal, a problem, a decision — and an agent executing against it. The Negotiator pattern involves two or more parties with competing interests, each pursuing a resolution that serves their position, neither fully in control of the outcome.

The pattern has three architectural components. First, each party has a position — what they want, what they’ll accept, what they won’t. Second, there is a resolution space — the range of outcomes both parties could accept, which may or may not overlap. Third, there is a process — the structured interaction through which the parties move from opening positions toward a resolution, or determine that none is possible.

AI operates at all three levels. It augments each party’s understanding of the resolution space before the negotiation begins. It processes information in real time during the negotiation, updating assessments as new signals arrive. And in increasingly capable implementations, it conducts elements of the negotiation directly — drafting proposals, modeling counteroffers, flagging where movement is possible and where it isn’t.

What makes this pattern distinct from the Advisor pattern is that the AI is not advising a single principal toward a better decision. It is operating in a space where the outcome depends on the behavior of another party — a party that is also, increasingly, AI-augmented. That symmetric augmentation is precisely what shifts the equilibrium.

The information game ends — and the equilibrium shifts

A skilled human negotiator preparing for a significant transaction historically spent days or weeks building their picture of the counterparty. What are their alternatives? What is their financial pressure? What have they accepted in comparable transactions? What is their actual flexibility on terms they’ve marked as firm? Some of this was accessible through research. Most required inference — reading signals, testing positions, watching reactions. The information asymmetry was never absolute, but it was real enough to be decisive.

AI democratizes the research layer completely. Everything publicly knowable about a counterparty — their financial position, their comparable transactions, their stated priorities, their historical negotiation behavior, their competitive alternatives, the market benchmarks that define what’s reasonable — is now assembled and synthesized before the first meeting. Both sides have this capability. Both sides arrive with a comprehensive model of the other’s position.

In game theory terms, the negotiation is moving from a Bayesian game toward a complete information game — where both players have near-full visibility into the relevant parameters. This is not a minor adjustment. It changes which strategies are viable, which moves are credible, and where the equilibrium lands. In a Bayesian negotiation, bluffing is a coherent strategy. In a complete information game, it collapses. The counterparty’s AI has already assessed your alternatives. Your claimed walkaway price is benchmarked against comparable transactions. The strategies that depended on information asymmetry are being systematically invalidated.

The examples that reveal the shift

Negotiating a SaaS deal. A mid-market software vendor negotiating a new enterprise contract used to hold a meaningful information advantage over the prospect. Not anymore. The vendor’s AI has assembled the prospect’s tech stack, contract renewal dates, budget cycle, and competing platforms being evaluated. The prospect’s AI has assembled the vendor’s pricing architecture, typical discount patterns by deal size, competitive win/loss profile, and churn risk from losing this deal. Both sides arrive with a near-complete model of the other’s position. The Bayesian game has largely been played before the first meeting begins.

What remains is the complete information game: who actually has a competing offer versus who is performing one, who has a genuine pricing floor versus who will fold under pressure. Commitment credibility is now the entire game. And the vendor who designed the conversation — who anchored on value rather than price, who framed the comparison set before the prospect did — wins more consistently than the vendor who showed up to defend a price sheet.

Negotiating an M&A deal. Both sides have AI running comparable transaction analysis. The buyer’s AI has benchmarked every relevant deal in the sector — revenue multiples, earnout structure, rep and warranty terms, management retention arrangements. The seller’s banker has run the same analysis. The information asymmetry on market terms is functionally zero. Neither side can credibly claim their proposed terms are standard when the other side has already read every comparable deal.

The negotiation shifts rapidly from “what is market” to “what do we actually want.” The private information that survives is the founder’s non-financial priorities, the buyer’s genuine strategic rationale, the timeline pressure neither side has disclosed. And the mechanism design advantage is decisive: the seller who controls the data room — what is provided, in what format, in what sequence — is designing the game the AI agents are being run on. Both sides have the same analytical tools. The side that designed the information architecture wins.

Negotiating an enterprise contract renewal. The formal negotiation — pricing, support terms, implementation commitments — gets resolved efficiently. Both sides have near-complete information, the Pareto frontier is clear, and the AI-augmented negotiators find the efficient outcome faster than any previous cycle.

Then the negotiation stalls. Not on price or terms. It stalls because the retailer’s IT leadership lost confidence in the vendor’s delivery team following a failed implementation eighteen months ago. That failure isn’t in any database. It isn’t in the comparable transaction analysis. It is a relationship wound that has never been formally acknowledged. The AI declared the negotiation complete when the variables were resolved. It produced an agreement. Not a resolution. The human who sensed that dynamic, named it, and addressed it directly is the one who closed the contract and kept the relationship.

What survives when the Bayesian game is over

Three things become more valuable as the information layer commoditizes. Each has a precise game-theoretic basis.

Genuine private information. Not everything is public. Your actual walkaway number — not the one you’ve signaled, the real one. The internal deadline that hasn’t been disclosed. The strategic rationale behind a position that you haven’t shared because sharing it would reveal your hand. In game theory, private information that cannot be inferred from observable signals is the last remaining source of informational advantage in a near-complete information game. Its value increases precisely because everything else has been neutralized.

Commitment credibility. Thomas Schelling’s work on commitment devices showed that the ability to credibly constrain your own future choices is a source of strategic power: if the counterparty believes you genuinely cannot accept less, your position is stronger than if they think you’re performing a limit you’d abandon under pressure. When both sides have full analytical coverage, commitment credibility becomes the primary currency. The bluff that worked when the counterparty couldn’t verify your alternatives doesn’t work when their AI has already assessed them. You either have a real walkaway number or you don’t. The AI just makes it harder to pretend otherwise.

Speed and real-time modeling. In repeated game theory, the player who responds fastest to new information controls the tempo. AI-augmented negotiators model counterproposals in real time — a term sheet arrives with twelve variables adjusted, and the AI instantly assesses which concessions are acceptable, which combinations create problems, what the package means for overall deal value. The party that can move faster with more confidence controls the pacing. Delays are where pressure builds and positions harden.

The practitioner insight: mechanism design is the last edge

AI is very good at optimizing within a defined game. Specify the players, the strategies, the payoffs, and the information structure — and the AI finds the efficient outcome faster and more accurately than any human team. For well-defined negotiation parameters, AI augmentation produces better results than unaided human negotiation.

What breaks down is the negotiation that escapes its defined game. Complex negotiations rarely stay within the variables defined at the outset. The acquisition target where the founder cares deeply about employee retention post-close — a variable that wasn’t in the term sheet but is decisive for whether the deal holds. The commercial contract where the legal terms are agreed but the relationship between account teams is broken and nothing in the contract resolves it. The labor negotiation where the formal demands are a proxy for a grievance that no contract term addresses.

These are situations where the game needs to be redefined — where a human has to sense what the negotiation is actually about, name it, and address it directly. The AI that optimized the defined variables has done useful work. The human who recognized that the defined variables weren’t the real game is the one closing the deal.

And this is where mechanism design — the branch of game theory concerned with designing negotiation structures that produce good outcomes — becomes the most durable edge in an AI-augmented world. Who designs the game has always mattered. Now it matters more than anything else. The party that defines the variables, sets the agenda, controls the anchoring, and shapes the resolution space before the AI agents start optimizing is operating at a level that no amount of real-time augmentation on the other side can fully compensate for. Mechanism design is a human act. The negotiator who shows up having already shaped the game holds the position that AI cannot take away.

The fully autonomous negotiator — and where it works

The most advanced implementations of the Negotiator pattern remove the human from the loop entirely. Algorithmic trading is negotiation at machine speed — buyers and sellers reaching price resolution through automated agents on defined parameters. Programmatic advertising is the same structure applied to media buying. In each case the game is fully specified — variables known, value functions defined, resolution criteria clear — and human involvement adds latency without adding value.

The boundary of full automation lies where the game is fully specifiable. Supply chain contract renewals on established terms. Standard commercial agreements with well-defined parameters and market benchmarks. Routine procurement within established vendor relationships. Where it breaks down is wherever the game isn’t fully specifiable in advance — the M&A deal where variables emerge through diligence, the regulatory negotiation where the agency’s posture is evolving, the commercial negotiation where the relationship is itself part of what’s being negotiated. In these contexts the AI has done useful preparation work. The human who applies judgment to the undefined variables is the one closing the deal.

The economic consequence

The Negotiator pattern’s economic consequence is less about headcount and more about the redistribution of strategic advantage.

Organizations that deploy AI augmentation will systematically outperform those that don’t — not because they’re smarter but because they enter every negotiation better prepared, process information faster, and manage positions more precisely against a near-complete information baseline. The information asymmetry that used to favor the party with better resources and more experienced negotiators narrows. A well-prepared smaller counterparty with AI augmentation can hold its own against a large organization relying on institutional experience that no longer exclusively belongs to them.

The professional negotiators — M&A advisors, labor relations specialists, commercial lawyers — whose primary value was information advantage and analytical depth face the same dynamic every advisor faces when AI democratizes the analytical layer. What survives is commitment credibility, relational intelligence, and the ability to close deals that require something more than optimization of defined variables.

What also survives — and this is the Negotiator pattern’s most important implication — is mechanism design. The party that defines the game before it is played holds the most durable advantage in an AI-augmented negotiation. When both players have AI running the analytical layer, the player who designed the game wins more often than the player who merely played it well.

The information game is ending. The design game that replaces it rewards a different kind of intelligence — and a different kind of preparation.

The Negotiator is the eighth and final pattern in this framework. Next: a synthesis piece — given all eight patterns, what do you actually do? A practitioner’s guide to identifying which patterns apply to your organization, how to sequence adoption, and what the transformation actually looks like.

For most of the history of complex decision-making, that testing was expensive, slow, and partial. Not because organizations didn’t value it. Because simulation has always had a ceiling — and for the most important decisions, that ceiling was hit long before the model was actually complete.

AI changes where that ceiling is. But not in the single, undifferentiated way most people describe. It changes two distinct things, in two very different ways. Understanding the difference is the key to understanding what the Simulator pattern actually does — and where it falls short.

The pattern, precisely defined

The Simulator pattern has a clean architectural signature. A decision is pending. Before committing, a Simulator agent constructs a model of the relevant system and runs it forward under a range of assumptions. The outputs are not predictions. They are a structured map of the uncertainty space — which assumptions are load-bearing, where the model breaks down, which scenarios produce unacceptable outcomes, which variables the decision is most sensitive to.

The human’s role is to define the decision context, specify what matters, and apply judgment to the simulation outputs. The agent handles model construction, assumption variation, parallel execution, and results synthesis.

This is architecturally distinct from the Investigator pattern, which I covered in Piece 4. The Investigator runs a loop to answer a question about what is true now. The Simulator runs a loop to map what could be true next. One is retrospective, one is prospective. Both terminate on confidence — but confidence about very different things.

What AI changes in the Simulator pattern is not one thing but two. And conflating them produces a muddled picture of what’s actually new.

The first change: removing the human from the simulation loop

Mathematical and computational simulation is not new. Monte Carlo methods have been used in financial risk modeling since the 1960s. Finite element analysis can predict where a structure fails under load before the first prototype exists. Computational fluid dynamics simulates airflow over a wing before a single test flight. Agent-based models have been used in economics and epidemiology for decades. We have been very good at simulating physics, chemistry, materials, and mathematics for a long time.

What AI changes here is operational, not conceptual. The underlying models are still mathematical constructs. The differential equations don’t change. But the workflow around them does — substantially.

Building a stress test scenario today means a human analyst specifying parameters, writing code or configuring tools, running the model, interpreting outputs, adjusting assumptions, and iterating. That loop is slow, requires specialist skill, and constrains how many scenarios get explored before the decision gets made. A strategy team might produce five scenarios. A risk committee might model ten. Not because five or ten is the right number — because more than that exceeded the time and headcount available.

An AI agent running the same loop removes most of that friction. It constructs the scenario, varies the parameters systematically across a range the analyst specifies, runs the iterations in parallel, synthesizes the outputs, and flags the findings that actually change the decision — the tail risk that doesn’t appear until scenario 87, the interaction effect between two variables that none of the first twenty runs exposed. The human analyst shifts from running the model to interrogating its outputs. The number of scenarios explored goes from ten to a thousand. The time it takes goes from weeks to hours.

This is real and it matters. But it is incremental improvement on an existing capability. It makes simulation faster, cheaper, and more accessible. It does not change the fundamental nature of what is being simulated.

The second change: the half that was always missing

Here is the harder problem, and the more interesting one.

Mathematical simulation has always had a gap. It can model physical systems, financial distributions, and aggregate statistical behavior with extraordinary precision. What it cannot model — what it has never been able to model adequately — is individual human behavior.

This is not a gap in computing power. It is a structural limitation of the modeling approach. If you want to include human actors in a simulation, pre-LLM you had three options. You could abstract them as rational agents — demand curves, utility functions, equilibrium assumptions. This works for aggregate behavior under stable conditions and breaks down anywhere humans actually behave like humans. You could use rule-based agents — manually specifying the decision logic for each actor type. Brittle, unable to generalize beyond the rules you encoded, incapable of responding to novel situations. Or you could use actual humans — running expensive, slow war games with executives playing competitor roles, small samples, heavily biased by who happened to be in the room.

None of these is satisfactory for the simulation of complex decisions where the behavior of specific human actors is the variable that matters most. How does a specific competitor respond to a price move? How does a regulator with a documented enforcement posture react to a new product filing? How do consumers in a specific demographic with specific price memory and social dynamics respond to a product launch? How does an organizational team behave when a project is under severe schedule pressure and a key dependency fails?

In every one of these cases, the thing that determines the outcome is not physics or mathematics. It is human behavior — contextual, contingent, social, and resistant to rule-based encoding.

LLMs change this. Not perfectly, and with important caveats. But materially.

In 2023, a Stanford team led by Joon Sung Park populated a virtual environment with twenty-five LLM-powered agents — each with memory, goals, and the capacity for reflection — and observed what happened. The agents formed opinions, initiated relationships, spread information through their social network, and coordinated spontaneous group activities that none of them had been explicitly programmed to organize. The behavior was emergent — arising from individual agents each pursuing their own goals, not from centrally specified rules. It was, for the first time, behaviorally plausible simulation at the individual agent level.

In the same year, MIT economist John Horton proposed the conceptual framework for what LLMs had actually created. He called it homo silicus — an implicit computational model of human behavior that, because of how LLMs are trained on the full breadth of human-generated text, carries within it a model of how humans reason, respond to incentives, exhibit biases, and make decisions. Give a homo silicus endowments, information, preferences, and constraints, and observe its behavior. His experiments, replicating classic behavioral economics studies from Kahneman, Charness and Rabin, and Samuelson and Zeckhauser, found results qualitatively similar to the original human subject studies. When results diverged, the divergence was itself informative — pointing to where LLMs carry systematic biases from their training that differ from human populations.

The implication for simulation is precise. LLMs don’t replace mathematical models. They fill the gap that mathematical models have always left open: the behavioral layer. Seed an agent with a competitor’s known strategy, public statements, cost structure, and historical behavior — and it responds to your moves in contextually plausible ways. Model a regulatory process where the agency has a documented enforcement posture and a set of prior rulings — and simulate how it responds to your filing. Run a consumer simulation where individual agents have price memory, social networks, and demographic-specific behavioral tendencies — and watch emergent demand patterns arise from their interactions that your aggregate demand curve never would have predicted.

Agentic LLMs take this further. A network of agents — each with their own context, memory, goals, and constraints — can simulate a market, an organization, a negotiation, a supply chain disruption, or a regulatory process with both the mathematical precision of traditional simulation and the behavioral plausibility of human actors. The simulation is no longer half a model. It is, for the first time, approaching whole.

Where this matters most

These two changes — operational acceleration and behavioral completeness — show up differently in different domains. Some decisions benefit primarily from the first. Some require the second. The most consequential decisions need both.

Financial portfolio stress testing. This is primarily the first change. The math of portfolio stress testing is well established. What changes with AI is the operational loop — continuous stress testing across every position, every day, varying correlation assumptions, liquidity conditions, and factor exposures in parallel rather than in a periodic batch. The portfolio manager doesn’t wait for the quarterly risk report to know where the exposures are. But the models are still mathematical. The behavioral layer matters here at the aggregate level — what do other market participants do? — and that is still the harder problem.

Competitive strategy and market entry. This is where both changes matter, and the second one matters more. A management team deciding whether to enter a new market is running a simulation of competitor response, regulator behavior, and customer adoption — all of which are human behavioral questions that mathematical models handle poorly. An AI Simulator seeded with everything knowable about the specific competitors — their stated strategy, their cost structure, their historical response patterns, the incentives of the individual executives who would make the decision — produces a more useful response distribution than any hand-coded rule set could. The human team stops guessing about the behavioral layer and starts reading a probability distribution generated from plausible behavioral models.

Supply chain disruption planning. Both changes, deeply intertwined. The mathematical layer — inventory flows, logistics constraints, lead time distributions — is well established. What traditional supply chain simulation misses is the behavioral layer: how do specific suppliers behave under financial stress? How do logistics partners prioritize customers when capacity is constrained? How do procurement teams in customer organizations respond to scarcity signals? The organizations that modeled supply chain scenarios going into 2020 with only the mathematical layer were better prepared than those who didn’t simulate at all. The ones who could also model the behavioral responses of their key counterparties would have been better prepared still.

Clinical trial design. The second change creates genuine new capability here. Before a Phase III trial commits hundreds of millions of dollars to a specific protocol, the design team makes dozens of decisions resting on assumptions about patient behavior — dropout rates, protocol adherence, response heterogeneity across subpopulations, site coordinator behavior under enrollment pressure. These are behavioral assumptions that get encoded as statistical distributions and largely assumed stable. A behavioral simulation layer that models individual patient decision-making, site coordinator dynamics, and investigator behavior produces a richer and more realistic picture of protocol feasibility than aggregate statistical assumptions alone.

The practitioner insight: the model is still the risk — in both layers

Here is the thing that most Simulator commentary misses. The second change — behavioral simulation via LLMs — does not eliminate the fundamental risk of simulation. It relocates it.

The original risk is well understood: the model contains assumptions, and the assumptions are where the real uncertainty lives. The 2008 financial crisis is the canonical example. The risk models were sophisticated. They ran continuously. They produced precise probability distributions. They were wrong not because the simulation was poorly executed but because the mathematical model assumed that house price correlations across geographies were low and stable. A structural assumption that had been true for decades was catastrophically false in the scenario that actually occurred. The simulation produced false confidence from a structurally incomplete model.

The behavioral simulation layer introduces its own version of this risk. LLMs trained on human-generated text carry the biases, blind spots, and distributional skews of that training data. A homo silicus is not a neutral model of human behavior — it is a model of the humans whose writing dominated the training corpus, behaving in the ways that corpus suggests they behave. Horton’s own research flags this: in some behavioral economics replications, the LLM results diverge from human subjects in ways that suggest systematic biases in how the models encode human preferences. A competitive response simulation seeded with a competitor’s public communications may miss the private strategic reasoning that never made it into training data. A consumer behavioral model may reflect the online-articulate population that generates text, not the full consumer population making the purchase.

The practitioner discipline the Simulator pattern demands is therefore aggressive assumption interrogation in both layers — not just the mathematical one. What are the behavioral assumptions this model is making about each actor? Where are those assumptions drawn from, and what is the population they represent? What would have to be true about the behavioral model for all the scenarios to be wrong in the same direction?

AI accelerates simulation and extends it into the behavioral domain. It does not automatically surface the model’s blind spots in either layer. That requires the human judgment to ask the right questions about the model itself — not just to read the outputs it produces.

The economic consequence

The Simulator pattern creates a compounding competitive advantage. Organizations that test their models before committing make better decisions. Better decisions compound. The gap between organizations that simulate well and those that don’t widens with every major decision made.

What AI changes is twofold, matching the two changes described above.

On the operational side, simulation capability is being democratized. Serious simulation previously required dedicated teams, specialist infrastructure, and institutional knowledge that took years to build. A major bank could run sophisticated stress tests. A mid-market lender couldn’t. A pharmaceutical giant could run virtual trial variations. A biotech startup couldn’t. AI removes most of that barrier. The cost of running sophisticated scenario models drops from requiring a specialist team and weeks of work to requiring a well-constructed model and hours of compute. The advantage stops being an advantage of resources and becomes an advantage of judgment — who asks the right questions of the model, who interrogates the assumptions, who knows what findings actually change the decision.

On the behavioral side, the competitive advantage is more profound and less equally distributed. Building useful behavioral simulation requires deep domain knowledge about the specific actors being modeled — their documented behavior, their incentives, the context that shapes their decisions. The organization that has spent years watching a specific competitor, regulator, or customer population has the raw material to build a behavioral model that actually reflects that actor. The organization that hasn’t has only generic priors. The democratization here is partial — the tools are available to everyone, but the domain knowledge that makes behavioral simulation accurate is still concentrated in the organizations that have accumulated it through experience.

There is also a second-order consequence that will take longer to play out but matters more. As simulation — both mathematical and behavioral — becomes accessible and expected, the standard of care for major decisions will rise. Boards will ask what scenarios were modeled. Regulators will expect evidence of stress testing. Investors will want to see the simulation outputs behind a capital allocation decision. The decision-maker who shows up with a base case and intuition — who has not run the model, has not explored the behavioral response distribution, has not asked what happens in the tail — will be increasingly exposed.

The future is always uncertain. The question is no longer whether you can afford to simulate it. It is whether you have modeled the humans in it as carefully as you have modeled the math.

Next: Pattern 8 — Negotiator. The final pattern. Two parties, competing interests, a resolution that neither fully controls. What happens when AI enters the space between them — and whether that changes the outcome or just the cost of reaching it.

Every pattern in this series describes a loop where AI removes the human from execution. The Reactive pattern replaces the human handler. The Creator replaces the human producer. The Conductor replaces the human coordinator. In each case, the argument is the same: AI executes the pattern better, faster, and cheaper. The human either moves up — to judgment, oversight, strategy — or moves out.

The Advisor pattern is the exception. Not because AI can’t execute it. It can. The models are capable of synthesizing complex information, generating well-reasoned recommendations, and delivering them clearly. The reason the human stays in the Advisor pattern isn’t capability. It’s structure.

Some decisions require a human to own them. Not as a quality gate. Not as a compliance checkbox. But because the person receiving the advice needs to know that another human — with skin in the game, with professional accountability, with a reputation that can be damaged — looked them in the eye and said: this is what I recommend.

That is the Advisor pattern. And it is the most durable pattern in the framework.

The pattern, precisely defined

The Advisor pattern has a deceptively simple structure. A human — the advisor — receives a situation requiring judgment. They gather information, analyze it, synthesize it, and deliver a recommendation. The person receiving the recommendation decides what to do. The advisor does not act. They advise.

What makes this architecturally distinct from every other pattern is the deliberate placement of the human at the point of recommendation. In the Reactive pattern, the agent acts autonomously and escalates to a human only at genuine decision points. In the Conductor pattern, the human sets the goal and the AI manages execution. In the Advisor pattern, the human is the execution — the synthesis, the judgment, the delivery are all human acts, and they are human acts by design.

The AI’s role in the Advisor pattern is augmentation at every step before the recommendation is made. Research, data synthesis, scenario modeling, precedent retrieval, draft generation — all of this is AI-accelerated. But the advisor reads it, applies their judgment, and owns the output. The recommendation carries their name. Their accountability. Their credibility.

That structure is load-bearing. Remove it, and you don’t have an Advisor pattern anymore. You have a Creator pattern with a human rubber-stamping the output — which is a very different thing, and which clients in high-stakes advisory contexts can sense immediately.

What AI augmentation actually does to the advisor

The common framing is that AI makes advisors more efficient — they can handle more clients, turn around analysis faster, cover more ground in less time. That is true, and it understates what actually changes.

AI augmentation doesn’t just make the Advisor pattern faster. It changes the quality of the inputs available to human judgment — and in doing so raises the floor of what good advice actually requires.

Consider what an advisor does before giving a recommendation. They read. They synthesize research, prior decisions, comparable cases, regulatory precedent, market data. They model scenarios — what happens if this goes wrong, what does the downside look like, which assumptions are load-bearing. They probe edge cases — the situation that looks clean until you ask what happens in the tail. They assess risk — not just the obvious risks, but the ones the client hasn’t thought to worry about yet.

Every one of these steps has historically been bounded by time, by the advisor’s own pattern recognition, and by the research that was feasible to gather before the meeting. An advisor preparing for a board risk review had time to read the management materials, draw on their own experience, and perhaps scan a handful of relevant cases. That was the quality ceiling.

AI removes that ceiling. A financial advisor with AI scenario modeling can stress-test a client’s portfolio against thirty years of market history — multiple regimes, multiple crisis scenarios, correlation breakdowns — in the time it used to take to build two scenarios by hand. A physician with AI diagnostic support doesn’t just surface the likely diagnosis faster; they catch the drug interaction the chart doesn’t make obvious, retrieve the clinical literature on the rare differential, model the treatment outcomes across the patient’s specific comorbidity profile. A lawyer walking into a negotiation with AI precedent retrieval has read every relevant case and regulatory ruling, not just the ones there was time to find. They know where the edge cases are before the other side raises them.

This is not about speed. It is about comprehensiveness. The advisor who uses AI well is bringing a qualitatively different level of preparation to every engagement — and that preparation shows up in the quality of the questions they ask, the risks they surface, and the recommendations they make. The advisor who doesn’t use it is bringing the same level of preparation they always did. In a world where the augmented advisor exists, that is no longer good enough.

Where this pattern lives — and why it persists

The Advisor pattern concentrates in domains where the cost of a wrong recommendation falls on a specific human, where accountability cannot be delegated to a system, and where the relationship between advisor and client carries weight that no AI output can replicate.

Wealth management and financial planning. A client is deciding whether to sell a concentrated equity position, restructure their estate, or move significant assets into alternatives. The analysis is largely quantitative — tax modeling, scenario analysis, correlation modeling, drawdown risk. AI executes all of it better than a junior analyst could a decade ago. But the recommendation — delivered by a financial advisor who knows this client’s family, their risk tolerance, the anxiety they carry about money, the business they’re trying to sell in three years — is a human act. The client is not buying the analysis. They are buying the judgment of someone who will be accountable to them at the next quarterly review if it goes wrong.

Medical diagnosis and treatment planning. A physician reviewing a complex case has access to AI diagnostic tools that surface differential diagnoses, flag drug interactions, retrieve relevant clinical literature, and model treatment outcomes. The AI catches patterns the physician would miss. And yet the treatment recommendation is the physician’s — signed, accountable, legally and ethically theirs. This is not sentimentality about human doctors. It is recognition that the patient needs to trust someone, that trust requires accountability, and that accountability requires a human to own the recommendation.

Legal counsel. A client facing a complex transaction, a regulatory matter, or litigation needs to know what to do. AI retrieves precedents faster, drafts memos more efficiently, and models outcomes more comprehensively than any associate team could. The attorney who uses all of this well gives dramatically better counsel than one who doesn’t. But the counsel is theirs. The professional privilege, the ethical obligation, the malpractice exposure — all of it attaches to the human advisor.

Board oversight — the example that sharpens everything. The most underexamined instance of the Advisor pattern is the corporate board. Directors on an audit committee, a cybersecurity committee, or a compensation committee are practicing the Advisor pattern in its purest form: they receive information from management, apply independent judgment, and advise — through board approval, through guidance, through the questions they ask in the room. They do not operate the business. They oversee it. And the quality of that oversight is entirely dependent on the quality of preparation they bring to the meeting.

Today that preparation follows a familiar workflow. Board materials arrive days before the meeting. Directors review them — along with whatever they happen to know from their own experience — and show up prepared to discuss. For a cybersecurity committee, that means reading the CISO’s update, perhaps reflecting on a breach they know about from another context, and applying judgment to whether management’s posture seems adequate. For a compensation committee, it means reviewing the proxy materials, checking a benchmarking report, and assessing whether the proposed executive pay package is defensible.

This is not a bad process. It is a human-bandwidth-constrained process.

Consider what that process looked like at Wyndham Hotels between 2008 and 2010. The company suffered three separate data breaches in under two years — 619,000 payment card numbers compromised, more than $10 million in fraudulent charges, customer data exfiltrated to a server registered in Russia. The failures were fundamental: no firewalls in place, default usernames and passwords on servers, no encryption of stored payment data, no meaningful network monitoring. When the FTC sued and the case reached the Third Circuit, the board was actually found to have exercised its business judgment in the shareholder litigation. Technically, they did their job. They reviewed the materials management gave them. They applied their judgment. They approved the direction.

The question the Wyndham case forces is not whether the board was negligent in the legal sense. It is whether the board had what it needed to ask the right questions.

A cybersecurity committee operating today, with AI-augmented preparation, receives something categorically different from what Wyndham’s board had. The management materials are not read in isolation — they are read alongside an AI-synthesized analysis of comparable breach incidents in the hospitality sector, the specific controls that failed in each case, the regulatory actions that followed, and a gap analysis against current standards including PCI-DSS and NIST. The AI flags that Wyndham’s described posture — no mention of network segmentation, no discussion of third-party access controls, no logging and monitoring program — matches the profile of companies that experienced significant breaches. It surfaces the FTC’s enforcement posture under Section 5, the SEC’s current cybersecurity disclosure requirements, and comparable cases where boards were found to have asked insufficient questions.

The director walking into that meeting asks different questions. Not because they are smarter. Because they are better prepared. The AI has done the synthesis, the precedent retrieval, the gap analysis, and the scenario modeling — and handed it to a human who now applies their judgment to a much richer picture of what the risks actually are.

The same logic applies to a compensation committee reviewing executive pay. Today a director reads the proxy materials and the benchmarking report management commissioned. With AI augmentation, they also receive an independent synthesis of proxy data across comparable companies, a flag that the proposed metrics have a known gaming pattern documented in the academic literature, a summary of recent SEC comment letters on similar pay structures, and a scenario model showing what the payout looks like under each performance band against the company’s actual peer group. The committee member asking whether this package is truly aligned with shareholder interest is asking that question with independent analysis that management didn’t prepare for them.

This is the Advisor pattern operating at its full potential. The judgment is human. The accountability is human. The relationship — between director and management team, between board and shareholders — is human. The preparation that makes the judgment worth having is AI-augmented, comprehensive, and available before the meeting starts.

The failure mode: when advisors use AI as a crutch

The Advisor pattern has a specific failure mode that the other patterns don’t share. In the Reactive or Creator patterns, the risk is that AI executes poorly. In the Advisor pattern, the risk is that the human stops advising and starts relaying.

An advisor who uses AI to generate the recommendation and delivers it without genuine engagement — who hasn’t interrogated the assumptions, applied their own judgment to the output, or considered what the model doesn’t know about this specific client — is not practicing the Advisor pattern. They are using AI as a crutch to produce the appearance of good advice without doing the hard work of actually giving it.

Clients are going to notice this faster than most advisors expect. And the reason is the same force that is elevating the best advisors: AI is in the client’s hands too.

Think about what happened when the internet and then Google democratized access to information. Before Google, a doctor, a lawyer, or a financial advisor held an information advantage that was structural. Clients couldn’t easily access what the advisor knew. The advisor’s credibility rested partly on expertise and partly on that asymmetry. Google collapsed the asymmetry. Clients showed up to appointments having already read the relevant articles, already knowing the questions to ask, already aware of options the advisor hadn’t mentioned. The advisor who had been coasting on information advantage suddenly had to justify their value in a different way.

AI is a more dramatic version of the same shift. A client with access to a good AI model can synthesize research, model scenarios, retrieve precedents, and generate options that would have required a junior associate team a decade ago. They are not experts. But they are informed — often more comprehensively informed than the advisor who hasn’t kept pace. When that client sits across from an advisor who is essentially presenting what the AI told them, dressed in professional language, they will know. Not because they can prove it. Because the recommendation won’t feel inhabited. It won’t reflect what the advisor knows about them, their specific situation, their history. It will feel like it was printed, not thought.

The advisors who fail to adapt will not lose clients slowly. The timeline is short — two years, perhaps less in domains where clients are already AI-literate. The ones who survive are the ones who use AI to do what they always should have been doing: deep preparation, comprehensive synthesis, rigorous scenario modeling, genuine engagement with the client’s specific situation. The ones who don’t will find that clients have access to something better and are no longer willing to pay for something worse.

The economic consequence

Here is the simplest version of the economic consequence: clients are going to stop paying for advice that AI can do for them.

That is not a forecast. It is already the direction the market is moving, in every advisory domain, as clients become more AI-literate and the floor for what good advice looks like rises. The advisor who was providing value primarily through information synthesis — reading the research, building the scenarios, finding the comparable cases — is delivering something clients can increasingly access themselves. Not as well, perhaps. But well enough to ask why they are paying professional rates for it.

What clients will pay for is the part AI cannot provide: the independent judgment applied to the synthesis, the professional stamp on the final recommendation, the accountability that attaches to a human who is willing to say — I looked at everything, and this is what I advise. That is not commoditizing. It may in fact become more valuable as AI raises the floor, because the judgment that distinguishes excellent advice from adequate advice becomes more visible, not less.

But the pricing model that bundles synthesis and judgment into a flat fee — the billable hour, the retainer, the AUM percentage — is under pressure in a way it has never been before. When clients can see the synthesis being done in real time, when they arrive at the meeting already holding a comprehensive AI-generated analysis of their situation, they will ask what exactly the professional fee is covering. The advisors who can answer that question clearly — I am providing the independent judgment, the accountability, and the synthesis of factors the AI can’t access — will be able to defend their rates. The ones who can’t will face compression.

And in some domains, the pricing model itself will shift. Contingency fees and performance-linked compensation are not new in law or financial advisory — but they are going to become more common, and more expected, as the stakes of advice become more legible to clients. If AI has already done the analysis and laid out the options, the advisor’s value is increasingly concentrated in the final call — the choice, the recommendation, the willingness to be accountable for the outcome. Pricing that recommendation on outcomes rather than hours is a natural consequence of that concentration. Not for physicians, where the ethical constraints are clear and the outcomes too complex to attribute cleanly. But for lawyers structuring a transaction, financial advisors managing a portfolio, or board directors overseeing management — the question of whether the advisor’s fee reflects whether they were right is going to become less theoretical.

The shift mirrors what happened after Google. Before search democratized information, professional advisors charged for access and synthesis. After search, the ones who survived charged for judgment. AI is doing the same thing again, faster, across a broader surface area of what advisors actually do. The advisors who recognize this now — who are already building practices around judgment, accountability, and genuine client relationships — are positioned well. The ones who are waiting to see how it plays out are already behind.

Next: Pattern 7 — Simulator. The pattern that runs the future before you commit to it. What it means when scenario modeling becomes continuous, cheap, and available before every significant decision.

What doesn’t get said clearly enough is this: clients have always known they were paying for two different things. And only one of them felt worth what they were charged.

They will pay serious money for the partner who understands their business well enough to decompose a complex problem correctly — who knows which workstreams depend on each other, which risks are real versus theoretical, which findings will change the decision and which won’t. That judgment is hard. It requires experience, domain depth, and the kind of intuition that only comes from having gotten it wrong before.

What they resent — even when they don’t say so — is paying the same rate for the update that summarizes what they already know, the spreadsheet that tracks what everyone agreed to last Tuesday, the deck reformatted for the steering committee that was already in the working team view. That work is not trivial. It takes time and attention. But it is not what they are buying when they hire the firm. It is the tax they pay to access the person they actually want.

The Conductor pattern is the first AI pattern that directly attacks that tax.

The pattern, precisely defined

The Conductor pattern has a clean architectural signature. A complex goal arrives — one that is too large, too multidimensional, or too parallel for a single agent to handle well. A Conductor agent receives it. It does not execute the goal directly. It does three things.

First, it decomposes. The goal is broken into sub-tasks, each with a defined scope, a clear output format, and the right tools and context for execution. A goal like “assess this acquisition target” becomes five discrete tasks: financial model analysis, commercial due diligence, technical diligence, legal exposure review, management team assessment.

Second, it routes. Each sub-task goes to the agent best equipped to handle it — a financial analysis agent with access to the model and benchmark corpus, a legal agent with access to the contract data room, a technical agent with access to the code repository. These agents are specialized. They don’t need to know about each other. They receive a scoped task and return a structured result.

Third, it synthesizes. The Conductor aggregates the results, identifies conflicts — the financial model shows strong revenue growth; the commercial diligence shows two customers representing 60% of ARR with renewal risk — and produces a coherent output that reflects the full complexity of the goal.

This is architecturally distinct from a pipeline of sequential API calls. The Conductor makes dynamic decisions: which agents to invoke, in what order or in parallel, how to handle low-confidence results, when to re-route, and when the synthesis is sufficient. It is an intelligent orchestrator. The plan changes as results come in.

The critical observation is that the Conductor operates at the level of the goal, not the execution. It is the management layer — and management is exactly where the expensive bundling has always happened.

Where the bundle is most expensive

The examples that reveal the Conductor pattern’s real economic weight are not in software development — that’s been covered. They’re in industries where the coordination overhead has been bundled with expertise for so long that clients have stopped thinking of them as separate things.

Enterprise platform deployment. Every major software rollout — SAP, Workday, Oracle — involves parallel workstreams that a delivery team spends months orchestrating: data migration, process design, integration testing, user training, infrastructure preparation, change management, cutover sequencing. Each workstream requires different expertise. Each produces outputs that feed the others. A program director at a systems integrator bills at $350–500 an hour to manage this coordination — tracking dependencies, flagging blockers, synthesizing status across workstreams, re-sequencing when something slips. The client pays that rate because the coordination work is real and getting it wrong is expensive. But they are not paying it because dependency tracking and status synthesis require rare human judgment. They’re paying it because the person who does those things well is the same person whose deployment experience they actually need — and you can’t currently buy one without the other.

M&A due diligence. When a private equity firm evaluates an acquisition target, parallel workstreams run simultaneously — financial, commercial, technical, legal, HR, environmental. Each produces a memo. A deal team synthesizes it into a go/no-go recommendation. That synthesis is worth every dollar it costs. The financial model that assumes 20% growth while commercial diligence quietly shows two customers representing 60% of ARR on annual contracts — someone has to catch that conflict, understand what it means for the valuation, and have the conviction to surface it clearly. That is the judgment the client is buying. What they are also buying, and would prefer not to, is the six weeks and the dozen associates who spent most of their time building the same models, formatting the same memos, and chasing the same document requests that every diligence process generates.

Complex commercial insurance underwriting. A large commercial risk arrives — an industrial facility, a multinational liability program, a complex construction project. Specialist underwriters assess different exposure dimensions: property, casualty, environmental, business interruption, reinsurance structure. A lead underwriter synthesizes it into a pricing recommendation. The lead underwriter’s judgment about how these exposures interact — which risks compound each other, where the portfolio is concentrated, which coverage gaps create liability the client hasn’t priced — that is valuable and hard to replace. The process of aggregating five separate specialist assessments, identifying the inconsistencies, and producing a structured recommendation that surfaces the decisions requiring human review — that is the coordination tax. It has been priced like expertise because it required a senior person’s time. It doesn’t have to anymore.

The profession built entirely around this pattern

There is a profession built entirely around the Conductor pattern. It is the Project Manager — whose job is to decompose a complex goal into a work breakdown structure, map dependencies, identify the critical path, route work to specialists, track execution, surface blockers, and produce status reports that give leadership predictability. PMI has codified this into a certification curriculum with over a million practitioners globally. The role exists everywhere complex parallel work exists — software delivery, civil engineering, aerospace, pharmaceuticals, large-scale retail transformation. The pattern is universal. The job title changes. The function is identical.

Here is the uncomfortable truth the profession doesn’t talk about enough: the PM role has been losing its seat at the table for years. Not because coordination isn’t valuable — it is. But because the role gradually collapsed into its administrative surface area. The weekly status report. The RAID log. The dependency tracker. These outputs became the job. And when the job became the outputs, the profession became the person who produces them. Clients tolerate paying for it. They don’t respect it.

AI changes this — but not in the way most people frame it.

The common framing is that AI handles the grunt work and frees up the PM to do the thinking work. That is true, but it undersells what actually happens. The thinking work that matters most — risk decomposition, dependency modeling, scenario analysis, identifying what the program is not seeing — is not just enabled by AI. It is made qualitatively better.

A PM running a risk assessment today is bounded by cognitive load, available time, and the limits of their own pattern recognition. A PM with an AI Conductor does something different. They run structured decomposition across every workstream and ask: where are the hidden dependencies the team hasn’t modeled? They run scenario trees and ask: if workstream three slips by two weeks, what is the full propagation across the critical path? They surface the question nobody has asked yet — not because they thought of it first, but because the AI flagged an anomaly in the dependency graph that no one had caught. This is the shift that restores the profession’s relevance. Not doing the same work faster. Doing work that wasn’t possible before — the kind of risk and insight generation that makes a program director genuinely indispensable, not just administratively necessary.

The project manager who leans into this runs fifteen to twenty programs instead of five, brings AI-augmented insight to every engagement, and earns back the seat at the table the role has been quietly losing. That PM is not a coordinator. That PM is a strategist with analytical leverage no previous generation of the role ever had.

The other outcome is more direct. Many PMs have built careers primarily on the grunt work — not because they couldn’t do the thinking work, but because the grunt work was always there, always urgent, always filling the week. When it moves to the AI Conductor, what remains is the thinking work. And for the people who were executing the pattern rather than managing it, there is no role left.

Why decomposition is the hard part — and why it still needs a human

Here is the practitioner insight that determines whether a Conductor system produces genuine value or confident-sounding noise: the quality of any Conductor system is determined almost entirely by the quality of its decomposition, not the quality of its subagents.

This is directly connected to the elevated role described above. The AI Conductor manages execution. But the decomposition — how the goal gets broken down, what the scope boundaries are, which workstreams depend on each other, and what each agent needs to return to enable synthesis — that still requires domain expertise and judgment to get right. It is, in fact, the core of the thinking work that survives.

Decomposition fails in three specific ways, and each failure is invisible until the synthesis arrives.

Scope leakage. Two agents receive tasks with overlapping scope and produce conflicting analyses of the same question. The synthesis buries the conflict rather than resolving it. The output looks coherent. It isn’t. A PM who has run complex programs knows where the scope boundaries break down — because they’ve seen it happen. That knowledge is what the decomposition requires.

Dependency inversion. Agent B’s task requires Agent A’s output as input — but the decomposition treated them as parallel. Agent B runs on stale assumptions. The Conductor produces a result that is internally inconsistent without flagging it. Modeling real dependencies — not just the ones the org chart suggests — requires understanding how the work actually flows, not how it was planned to flow.

Resolution policy absence. When subagents return conflicting results — and in any complex analysis, they will — the Conductor needs a defined resolution policy. Escalate to a human? Weight by confidence? Initiate a secondary investigation? Most early Conductor implementations don’t have one. They produce false consensus: the synthesis papers over the disagreement rather than surfacing it as a genuine decision point. The program director who knows which conflicts are real and which are modeling artifacts is the one who sets that policy correctly.

Getting decomposition right is the engineering discipline that separates Conductor systems that compound in value from those that produce impressive-looking nonsense. It requires deep domain knowledge, and explicit output contracts — structured schemas that define what each subagent returns and what the Conductor needs to synthesize. The real competitive moat is not in the underlying models, which are commoditizing. It’s in the decomposition logic refined through hundreds of real engagements in a specific domain. That is proprietary. It compounds. And it is exactly what a senior PM or program director with AI augmentation builds over time — the kind of structured domain knowledge that makes every subsequent engagement better than the last.

The economic consequence

Professional services has always bundled coordination and expertise into a single rate card. A senior partner bills at $1,200 an hour for their judgment — and for the coordination overhead required to bring the right specialists to bear on a problem. An engagement manager at a systems integrator bills at $400 an hour to run the delivery workstream. A program director at a pharma CRO bills for months of trial coordination. In each case, the grunt work and the judgment get priced together, because until now they required the same person.

The client always knew they were getting two things. They tolerated paying for both because they had no alternative. The person whose decomposition thinking they needed was the same person chasing the status updates. You couldn’t buy the judgment without buying the overhead.

AI is ending that arrangement.

The bifurcation that shows up most visibly in the PM role runs through every coordination-intensive profession: the engagement manager whose week is consumed by workstream synthesis and status reporting, the deal coordinator whose value was organizational memory and availability, the program director whose primary output was the dashboard nobody had time to build themselves. In each case, the same split: judgment work that survives and expands; grunt work that moves to the Conductor.

What survives: domain expertise, strategic judgment, relationship trust, and the human capacity to navigate ambiguity with organizational credibility. The people who were doing those things — and whom the grunt work was crowding out — will find that AI gives them leverage they never had.

What doesn’t: the coordination layer that has been priced as if it required rare human skill, because until now it did.

The firms that will navigate this transition are the ones that can answer honestly which part of their value proposition is expertise and which is coordination. Many have confused the two for a long time, because the billing model made the confusion comfortable. The Conductor pattern will resolve that confusion directly — through pricing pressure, margin compression, and clients who finally have the option to stop paying coordination rates for work that an AI Conductor can now execute better, faster, and at a fraction of the cost.

That is not disruption arriving from outside the industry. It is the client getting what they always wanted: the judgment, without the tax.

Next: Pattern 6 — Advisor. The most intentionally constrained pattern in the framework. The human is in the loop by design — not because AI can’t execute, but because the structure requires it. What that means when AI augments every step of it, and why it may be the most durable pattern of all.

Every investigation has a clock. It always has.

The question is never whether you will eventually find the answer. Given enough time and enough skilled people, almost any investigation resolves. The real question — the one that determines value in every knowledge-intensive industry — is how long the loop runs before confidence is high enough to act.

A typical M&A due diligence process runs six to twelve weeks. A competitive intelligence study takes three to six weeks. A financial fraud investigation at a large institution can run months before the pattern becomes clear enough to act on. In each case, the cost of the investigation scales with its duration. And in each case, the decisions that depend on its output wait.

According to McKinsey, 40 percent of respondents in a recent M&A survey report that AI has enabled 30 to 50 percent faster deal cycles. McKinsey & Company That number understates what is actually changing. Because the Investigator pattern doesn’t just run faster with AI. It changes what confidence means — and therefore when the loop stops.

The pattern, precisely defined

The Investigator pattern has a specific architecture: a question drives an iterative reasoning loop — gather, synthesize, re-hypothesize — until confidence is sufficient to act. The pattern terminates not on a deadline, not on a budget, but on a confidence threshold.

This is architecturally distinct from the Reactive, Sentinel, and Creator patterns. Reactive agents respond to events. Sentinel agents watch for anomalies. Creator agents produce artifacts. Investigator agents reason toward insight. The output is not an action, not an alert, and not a document — it is a conclusion with a confidence level attached.

That distinction matters because the thing that limits human Investigator loops is not intelligence. It is capacity. A skilled analyst can follow a hypothesis wherever it leads. The problem is that following a hypothesis requires gathering information, synthesizing it, forming a new hypothesis, and gathering more information. Each iteration takes time. Each piece of information retrieved requires a human to read, evaluate, and integrate it. The loop runs at human speed.

AI changes the rate of iteration. The same loop — gather, synthesize, re-hypothesize — now runs orders of magnitude faster. The question that used to require six weeks of investigation can now be answered in hours. The confidence threshold hasn’t changed. The time to reach it has.

The structure of a real investigation: hypothesis trees, not linear loops

Here is where most descriptions of the Investigator pattern oversimplify. A real investigation is not a single linear loop running one hypothesis to ground. It is a hypothesis tree — a top-level question that decomposes into sub-hypotheses, each of which must be investigated independently, with the results synthesized back up to the top level. The synthesis often changes the top-level answer entirely.

A concrete example from technology due diligence in M&A.

The top-level question is: what is the technology risk of this acquisition? The opening hypothesis is that tech debt is manageable — say, 15 to 20 percent of R&D spend going to debt service is a reasonable baseline for a mature SaaS company. If that holds, the acquisition budget and integration timeline are credible.

But the moment you begin the investigation, the hypothesis decomposes. The company has four product lines. Each was built at a different time, by different teams, with different architectural choices. The tech debt question cannot be answered at the company level — it must be answered at the product line level, because the answer is different for each one.

So the single hypothesis becomes four parallel sub-investigations: what is the tech debt profile of Product Line A? B? C? D? Each involves gathering codebases, interviewing engineering leads, reviewing incident logs, assessing test coverage, evaluating infrastructure costs. Each sub-loop iterates until confidence is sufficient.

Then comes the synthesis — and this is where the real insight lives. When you pull the product-line answers back up to the company level, the picture often looks nothing like the opening hypothesis. One product line is clean, scalable, well-tested — low debt, high confidence in the budget. Another is a patchwork of workarounds accumulated over eight years, with tech debt so significant that the next two years of R&D budget are spoken for just to maintain it, let alone extend it. A third is somewhere in between.

The consequence is not just a revised tech debt estimate. It is a completely restructured valuation model. You are no longer valuing a single company with a blended R&D profile. You are valuing four distinct businesses with different margin structures, different growth trajectories, and different capital requirements. Some product lines may deserve a premium multiple. Others may require a discount or a carve-out conversation. The deal structure, the price, the earn-out conditions — all of it needs to be reconsidered from the ground up.

That reframing is the most valuable output of the investigation. And it almost never happens under traditional timelines, because the analysis that triggers it runs out of time before it can.

The examples worth understanding

M&A due diligence — where time kills the analysis.

M&A due diligence costs typically range from 0.5 to 2 percent of deal size. Dealroom On a $500 million acquisition, that is $2.5 to $10 million in professional fees, and a typical process runs six to twelve weeks. That timeline is not determined by how long the analysis actually needs to run — it is determined by how long human Investigator loops take sequentially. And sequential is the operative word, because that constraint shapes what gets investigated and what gets left on the table.

Running four sequential product line deep dives — code review, engineering interviews, incident log analysis, infrastructure cost assessment — takes three to four weeks per product line under traditional methods. Under a twelve-week timeline, with legal, financial, and commercial workstreams running simultaneously, you get one or two product lines done properly and the rest done superficially. The hypothesis tree is never fully explored.

Here is what AI actually changes. The sub-loop work — pulling data, extracting code metrics, analyzing incident logs, building the preliminary tech debt model for each product line — used to take one to two analyst-weeks per product line. That same work now takes hours. The spreadsheet construction, the data extraction, the pattern identification across thousands of lines of code and log entries — all of that runs in parallel, simultaneously across all four product lines.

That compression is not incremental. It is what makes the modeling conversation possible within the deal timeline. The analyst who used to spend 80 percent of their time building the spreadsheet now spends 80 percent of their time on the back-and-forth with AI that turns the product line findings into a revised valuation model — adjusting multiples, stress-testing assumptions, running scenarios on different deal structures. The insight that used to be theoretically available but practically unreachable is now within the timeline.

Companies using AI for due diligence report 30 to 40 percent lower professional service fees and a 25 percent reduction in post-merger integration costs. Open Ledger But the fee reduction is the smaller part of the story. The larger part is that the valuation hypothesis — the one that opens as a single company-level question and should resolve as four distinct product line valuations — actually gets fully explored. The deal that looked straightforward at the blended level gets properly structured at the product line level. That structural insight, produced because the hypothesis tree had time to run completely, is where the real value lies.

Financial fraud investigation.

A fraud investigation is a pure Investigator loop under acute time pressure. Every day the loop runs is another day the fraud continues. A suspicious pattern surfaces — anomalous transactions, unusual counterparty behavior, timing inconsistencies — and the investigator begins iterating. Pull the records. Map the relationships. Form a hypothesis. Test it against more data. Re-hypothesize.

Human fraud investigators work sequentially, one thread at a time, integrating new information at reading speed. AI investigators run multiple hypotheses simultaneously, integrating large information corpora in seconds, re-ranking hypotheses continuously as new data arrives. The pattern that would have taken a human team three months to establish can now be surfaced in days. In financial fraud, that compression is not a productivity improvement — it is a containment mechanism.

Market and competitive intelligence.

Every significant strategic decision should be preceded by a proper investigation. In practice, many are made on partial information — not because the information doesn’t exist, but because gathering and synthesizing it takes longer than the decision window allows. The competitive intelligence study that requires six analyst-weeks gets abbreviated to two, and the conclusions reflect the truncation.

AI collapses the time between hypothesis and evidence. A parallel investigation running across public filings, news feeds, patent databases, job postings, pricing signals, and customer feedback simultaneously surfaces what a full human team would have found — before the strategic window closes. The decision gets made on full information rather than on whatever could be assembled in time.

The sharpest insight: the loop terminates on confidence, not time

Human Investigator loops terminate for one of two reasons: the analyst reaches sufficient confidence to act, or they run out of time and budget before reaching it. In practice, the second reason is far more common than anyone admits. Deadlines impose artificial termination on investigations that could have continued productively. The loop stops not because the answer has been found, but because the resources to continue have been consumed.

This is the hidden cost of slow investigation that never appears in any budget. Decisions made on insufficient confidence. Acquisitions completed with product line tech debt unresolved. Fraud patterns missed because the investigation was wound down. Market entries launched without a clear competitive picture.

AI changes the termination condition. When the loop runs at machine speed, the constraint shifts from time and budget to confidence. The investigation continues until the answer is clear — not until the resources run out. That is qualitatively different. And it produces qualitatively better decisions.

The architecture underneath

The Investigator pattern requires a different architecture from the patterns covered so far. Reactive and Sentinel systems optimize for throughput. Creator systems optimize for output quality. Investigator systems optimize for something different: progressive confidence under a time constraint.

The hypothesis manager is the core component. It maintains the investigation state — the current hypothesis tree, the confidence level at each node, the evidence supporting or challenging each branch, and the criteria that would change the top-level answer. In the M&A tech due diligence example, the hypothesis manager holds the state of all four product line sub-loops simultaneously, routes new findings to the correct branch, and tracks when each branch has reached sufficient confidence to contribute to the synthesis.

The retrieval layer enables parallel execution. Rather than a single analyst running sequential queries, the Investigator architecture deploys multiple retrieval agents simultaneously — each assigned to a specific sub-hypothesis, each pulling from the relevant data sources. Code repositories, incident logs, infrastructure cost data, engineering interview notes — all processed in parallel. What used to take three weeks per product line now takes hours.

This is the point that matters most architecturally. The spreadsheet work — pulling financial data, structuring it, running preliminary calculations — used to be the majority of where analyst hours went. An AI-driven Investigator system collapses that work to minutes. The analyst who used to spend 80 percent of their time building the spreadsheet now has 80 percent of their time available for the modeling conversation that changes the deal.

The synthesis engine integrates findings across sub-hypotheses and updates the top-level confidence. The termination condition evaluates whether the threshold has been reached — and this is where the most important design work happens. Calibrating termination correctly, so the loop stops when confidence is genuine rather than when resources run out, is the frontier of production-grade Investigator-pattern systems.

Retrieval-augmented generation provides the retrieval and synthesis layers. Agentic loops with tool use — web search, database queries, document analysis, API calls — provide the iteration mechanism. Tools like Harvey for legal investigation, Perplexity for open-web research, and the bespoke due diligence agents being built inside leading M&A practices are early productizations of this architecture. The category is accelerating fast. Within two years, the Investigator loop will be as productized as the Reactive loop is today.

Next: Pattern 5 — Conductor. The pattern that doesn’t execute and doesn’t investigate — it orchestrates. And the one that becomes the critical architectural layer as the other seven patterns proliferate.