Fortress Legacy

Over one weekend, I heard two AI stories that seemed to cancel each other out, then began agreeing with each other.

The first came from a senior bank leader who was not doing the ritual grumble about innovation theater. He described real budgets, real teams, real urgency. The bank was spending, experimenting, appointing owners, and still he did not believe the deep shape of the institution would change easily. Old systems were part of it. Older promises and processes were the heavier part, the things that had survived previous cleanups.

The second came from a founder I know, who was building against a traditional company with a kind of calm menace. Claude Code and Cursor, he said over the weekend, had changed the arithmetic enough that leaving to compete no longer felt romantic. It felt operational.

What struck me was that neither man sounded drunk on novelty or allergic to it. The banker was not hiding from AI. The founder was not selling me magic. They were looking at the same change from opposite doors.

The name I found for the contradiction is Fortress Legacy. It is what happens when an incumbent’s accumulated protection system becomes its redesign cost. Execution has become cheap faster than coordination has become cheap. So the outsider feels new room to build, while the insider feels the old room filling with expensive furniture that cannot simply be thrown out.

The wall is not the code. The code is merely visible stone.

By coordination structure, I mean the tacit, undocumented logic by which people, routines, judgment calls, and local exceptions actually get work done. It is the analyst who knows which customer note matters, the supervisor who remembers why one queue cannot merge with another, the exception that became a standing habit, the approval that exists because someone once lost money publicly. The org chart points at work. The coordination structure does it. It is memory disguised as process, and process defended as prudence by serious people.

The founder’s story made this visible because he was already in year three, growing roughly 2x year over year, and casually mentioned that his AI customer-service system had handled more than 500 WhatsApp queries a day the previous week. He was not adding AI to service. He had designed service around AI.

Then I tried to imagine the same thing inside the bank: not a chatbot on the website, but an AI-run customer channel that customers could actually use when money was at stake, without ceremony.

Immediately the imaginary clean line broke into records, archives, complaints handling, accessibility, security review, vendor review, model-risk review, ownership of the queue across retail, wealth, and small-business banking, accountability for off-script answers, integrations with core systems, and the staffing politics of the existing call center. None of these are irrational. Most are fossils of trust. They are also why the same customer conversation is a weekend build outside and a constitutional convention inside under fluorescent light and sober meeting faces.

The founder could ship a function and then discover the next constraint from live use. The bank would have to ship a committee before it shipped the function, because in a bank the committee is not overhead. It is where many buried promises still have legal names.

By rewritability, I mean how much hidden work logic can be surfaced, named, and rebuilt before the rebuilding itself breaks customer trust, employee judgment, or regulatory peace at once.

Once I had that word, the incumbent choice stopped looking like a single strategy problem. I could see three rational moves. You can patch the fortress and learn where AI is genuinely useful. You can selectively rebuild rooms whose shape was dictated by scarce expert labor. Or you can grow something outside the wall, fund it, buy it, or at least study it before the parent institution teaches it to speak in meeting minutes. All three are sane. All three fail in characteristic ways. That is the taxonomy I heard underneath the weekend.

The first inhabitants of the fortress are the Patch Learners: practical, cautious, and much less foolish than they look from outside.

They put AI where the blast radius is small and the result can be checked by someone already responsible for the work: summaries, first drafts, document search, coding help, internal support, meeting notes, little automations that make tired people less tired. This is the sensible first move in most large organizations. It buys practice without forcing an identity crisis or a board-level theology debate.

I do not think this is cowardice. In the bank conversation, I heard genuine respect for the tools, not a procurement person’s pantomime of enthusiasm. Patch learning maps where confidence forms. It reveals which tasks have clear answers, which managers can judge output, and where small failures stay small enough to teach without theater.

Practice is not metamorphosis. A firm can become fluent in AI and remain recognizably, stubbornly itself for years.

This is why software moved first. Not because programmers are braver or cleaner people, though some will happily imply both, but because code is unusually checkable. Tests fail. Builds fail. Pull requests leave tracks. When Anthropic launched Claude 4 on May 22, 2025, it pointed to Rakuten’s seven-hour Claude Code run less as a circus trick than as a proof that long machine execution can be made boring when the checking machinery is strong. The exciting part was not autonomy. It was bounded autonomy with a red pen nearby, awake, the whole time.

By verification infrastructure, I mean the tests, reviews, audits, sign-offs, and measurable failure points a function uses to decide whether work is acceptable. The official 2025 Developer Survey says only about 3% of developers highly trust AI output, which sounds damning until you notice what they do next: they review, test, argue, and merge anyway. Low trust is survivable when checking is normal. Outside software, low trust often means the experiment stops before learning begins.

That is the Patch Learner’s ceiling. It discovers where the fortress has good light, clean rooms, and honest scales. It also leaves the fortress mostly standing. The organization learns to use AI, but the old pattern of work remains the thing being made more convenient.

The next inhabitants of the fortress are the Selective Rebuilders, who are more dangerous because they ask a less polite question. They are not futurists. They are renovation crews who have noticed that some rooms were built around vanished constraints.

Selective Rebuilders start from an uglier suspicion: some functions are human-scarcity artifacts. By a human-scarcity artifact, I mean a business activity whose shape was determined less by the business need than by the old price of skilled people doing the work. Claims processing, finance close, compliance review, customer service, deal desks, internal reporting: many such functions are not eternal forms. They are compromises that hardened around queues, managers, handoffs, judgment calls, and the amount of expert attention the company could afford to spend on each unit of work. A finance close is not just arithmetic. A claims team is not just claims. Both are histories of scarcity with badges.

The useful question, then, is not which screen gets an AI button. It is whether the function deserves to survive in its current shape. If a service team existed because only humans could read messy intent, route exceptions, draft responses, and remember the unofficial promises, what should that team become when those acts become cheap enough to repeat at scale? That is not an efficiency question. It is a design question wearing the mask of an efficiency question.

This is where the rebuild becomes genuinely treacherous. Too little change preserves the bottleneck and calls it safety. Too much change triggers the institution’s immune response, usually for reasons that are partly correct. The old room may be badly shaped, but people still know where the exits are.

The skeptic deserves a chair here. He has heard twenty years of essays announcing that firms must rewire themselves or die, and he has watched many of those firms continue making money with the serene indifference of a cathedral to TED talks. The difference this time is not that executives have become more visionary. It is that cheap execution has made outside rebuilds newly plausible. The threat is no longer a slide about transformation. It is a small team with working software and customers by Friday.

The third inhabitants are the Outside Funders: incumbents who suspect, correctly, that some futures cannot be learned inside the parent without being domesticated. They build, fund, or buy the thing that might otherwise embarrass them, then try to keep enough distance for it to continue embarrassing them usefully.

Some futures have to be grown outside the wall, not because outside is pure, but because it has fewer inherited reflexes.

That sounds like venture romance, so it is worth draining the romance out of it. A clean-start company does not escape the hard parts. It discovers handoffs, checks, staffing needs, angry customers, exceptions, fraud, liability, and operating boredom after the AI part begins working. This is the founder’s advantage, not because he has no constraints, but because he meets each constraint in the order customers reveal it rather than in the order a legacy institution remembers it.

The failure mode is almost comic. The parent funds or buys the outside thing because it wants the lesson, then imports the approvals, reports, committees, compensation logic, and calendar rhythms that made the lesson necessary. The acquisition succeeds financially and fails epistemically. The company owns the answer and teaches it to forget the question.

This is why the founder’s WhatsApp service system stayed with me. It was not a customer-support anecdote, or even a charming founder anecdote about doing more with less. It was a shape-of-work anecdote, which is much more irritating to incumbents.

The same defenses that protect trust also prevent cheap learning. Records, audits, accountability, staffing commitments, and cross-business ownership are not decorative barnacles. They are how the bank remains a bank rather than a spreadsheet with a logo. But the price of that trust is that experiments arrive already carrying the weight of the institution they are supposed to lighten. The outsider learns by use. The insider learns by permission.

Even the correct incumbent may fail. Tacit knowledge is dense. Verification infrastructure is uneven. The people who understand the old exceptions are often the same people whose cooperation is required to rebuild them. A taxonomy does not make the politics disappear. It only makes the evasions more visible.

Diagnosis is not a rescue plan. It is only a way of refusing the comforting version of the problem long enough to notice the real one.

By the end of the weekend, I no longer thought the bank leader and the founder were disagreeing. They were standing at opposite gates of the same fortress, each accurately reporting the weather on his side. From outside, the wall looked newly climbable because execution had become cheap. From inside, the corridors looked expensive because coordination still had to be paid for in meetings, memory, trust, and signatures.

So the incumbent question is not whether to use AI. That question is already stale. The question is which rooms should be patched for learning, which should be rebuilt because they were designed around scarce expertise, and which future rooms should be seeded beyond the wall before the main building teaches them old manners.

I am not outside this story. I am a part-time fortress creature too, user and critic, bored by committees until I need one of them to have existed before my money, health, or identity is on the line.

Fortress Legacy is the moat that became the floor plan, and then started charging admission to anyone trying to redraw the house.