Modernize with intelligence.

Modernization · adapted from Modernization with Intelligence, chapter 9

The cheapest code to migrate is the code you don't migrate

Stand in front of a legacy application and ask what it actually does. Not how, but what. A rules engine routing claims. A search bar trying to find a product. A form asking a customer twenty-five questions. When those were built, explicit code was the only way to solve the problem. In 2026, for many of them, there is another path.

Most modernization programs ask two questions: how can AI speed up the migration work, and what AI features should the new product have? The third question is usually worth more: which parts of the legacy system should not be migrated at all, because an AI-leveraged component can do the same job with far less code?

Where AI-leveraged replacement works

• Business rules engines. Thousands of accumulated rules become a learned model, an explicit policy layer for anything regulated, and an explanation surface for users and auditors.
• Search and knowledge bases. Custom search and FAQ trees become semantic retrieval that understands questions, not just keywords.
• Form-driven workflows. Complex, infrequent journeys such as claims or onboarding become guided conversations. Routine forms for expert users stay as they are.
• The long tail of reports. Hundreds of rarely viewed dashboards collapse into a natural-language analytics layer. The most-used dashboards remain.
• Document processing, data preparation and triage. One document-understanding service replaces many bespoke parsers; classifiers route tickets and alerts, and humans review only the uncertain cases.

A five-question test for every component

1. What does this component actually do for users or the business?
2. Which AI-leveraged pattern could serve that function?
3. Is there enough data of the right quality to support it?
4. What does a wrong answer cost, and what is the fallback?
5. Does the replacement cut total cost, add user value, or both?

A component that passes all five is a candidate for replacement. One that fails any of them is migrated the classical way.

When not to replace

Keep deterministic rules as code where a regulator or a contract needs them explained. Be wary of small-looking components that hide years of operational subtlety. And where data is thin or the stakes are high, such as a medical or financial decision, classical engineering and strong human oversight remain the responsible choice.

Done with discipline, the payoff is twofold. In the programs I have seen, components where replacement was appropriate typically saw 20 to 40 percent lower direct migration cost. The new system also gains capabilities the old one never had: a rules engine could never tell you which of its rules contradicted each other. Those savings are paid for with real AI engineering: evaluation harnesses, monitoring, guardrails and governance. Skip that, and the savings come back as incidents.

Execution · adapted from Modernization with Intelligence, chapter 15

Eight ways modernization programs fail

Tolstoy said every unhappy family is unhappy in its own way. For modernization he was wrong: failed programs look strikingly alike. What varies is how the failure was explained at the time. Here are the patterns I see most often, how to spot them and what to do instead.

The big-bang rewrite

Spot it: a multi-year plan with all the value at the end. Fix: a sequence of smaller migrations, each with its own cutover and its own value.

Lift, shift and forget

Spot it: the app moved to the cloud with no refactoring, and the cloud bill is higher than the data center. Fix: budget deeper modernization for the components that need it as a planned phase.

The AI feature parade

Spot it: a feature list that reads like a technology demo. Fix: for every AI feature, name the user, the workflow, the metric and the success test.

The model wrapper

Spot it: an AI feature that is one line of integration code with no retrieval, evaluation or monitoring. Fix: treat every AI feature as a small system in its own right.

The unmonitored agent

Spot it: an agent with broad write access and an audit trail nobody reads. Fix: add autonomy one action at a time, each with a risk review and a way to reverse it.

The last-week training sprint

Spot it: training appears only in the final sprint. Fix: build training into every iteration; AI makes good training content cheap to produce.

The vendor dependency trap

Spot it: one named model vendor at the center of the architecture, with no alternative tested. Fix: vendor-neutral interfaces, and regular proof that the alternatives still work.

Compliance after the fact

Spot it: AI features with no documented compliance review. Fix: a standing compliance gate for every feature, model update and prompt change.

Almost all of these share one root cause: confusing activity with progress. Rewrites, rehosting, feature launches and training videos are activities. Outcomes are what users and the business can do that they could not do before. Keep outcomes in front of every decision, and most of these patterns never get started.

Governance · adapted from Modernization with Intelligence, chapter 10

Assistant, copilot or agent? Pick the lowest level that works

Boards keep asking when their company will "deploy agents". It is the wrong first question. The right one is: what level of autonomy does this problem actually need?

Three levels of embedded intelligence

• Assistant. Answers questions and drafts within a session. It sees context but takes no actions. The easiest level to deploy safely, and the most likely to feel bolted on if it is not wired into the product's real data.
• Copilot. Works alongside the user: suggests the next step, fills the next field, drafts the next message, and acts only with explicit consent. It blurs who did what, so consent and undo must be designed in.
• Agent. Pursues a goal across several steps and systems without constant supervision. The most powerful level and the most dangerous. It needs clear limits on what it may do, what it must escalate, what it must log and how its actions are reversed.

Don't deploy an agent to solve an assistant problem. Each step up adds new ways to fail and new governance to run. Start at the lowest level that solves the user's problem, prove its value, and move up only when trust has been earned.

Design rules that get skipped under deadline

• Any action taken for the user needs clear consent that says exactly what will happen.
• Undo should sit right next to the AI's output. Irreversible actions, such as payments, need deliberate confirmation.
• Write a voice and tone guide covering how the assistant handles uncertainty and admits its limits.
• Design for accessibility and multiple languages from day one. An assistant can be one of the best accessibility tools a product has.

Trust ratchets up slowly and breaks quickly. Governance is what lets you climb the ladder without falling off it.

Security · adapted from The Algorithms of Life, chapter 5

Your security stack is trying to become an immune system

While you read this, your body is under attack. Viruses, bacteria and rogue cells are probing your defenses, and you notice none of it. One of the most remarkable distributed systems ever evolved is running quietly in your bloodstream, with no central controller. It learns as it fights and remembers threats it has not seen for decades. Every security team is, knowingly or not, trying to build a digital version of it.

The parallels are close

• Signatures are antigens. Fast and precise against known threats, blind to new ones.
• Behavioral analytics is innate immunity. It learns what normal looks like and flags what looks wrong, without knowing exactly what it is.
• Zero trust is the immune checkpoint. Identity is verified at every boundary; trust is never granted once and for all.
• Self-healing infrastructure is tissue repair. Failed components are replaced without central coordination.
• Incident playbooks are immune memory. Mature teams encode what they learned so the next response is faster.

Beware autoimmunity

The most dangerous failure of a powerful defense is not missing an attack. It is attacking what it was meant to protect. Over-aggressive automated responses lock out real users, quarantine legitimate services and shut down critical flows. As AI takes over more of security response, precision matters more than power.

The immune system is also calm. Most infections are contained without ever reaching your awareness. A mature security operation should work the same way: most incidents resolved quietly, and only the ones that matter reaching a human. Less alarm fatigue, more signal.

The design principles carry straight over: layered defense instead of a single wall, learning from every encounter, memory that speeds the next response, precise separation of self from non-self, and distributed response because central coordination is too slow. Your body runs the most sophisticated zero-trust architecture ever deployed. It is worth studying.

Agentic AI · adapted from The Algorithms of Life, chapter 6

The future of AI is a forest, not a tree

Walk into a forest and stand still. It is far more than a collection of trees. Nobody designed it and nobody manages it, yet it has stayed productive and resilient over timescales that make our longest-running software look like fireflies.

Until recently most AI behaved like a solitary organism: a prompt went in, an answer came out, and the interaction ended. Agentic AI changes that. Systems now plan, act, observe the result and adjust, over long periods, alongside people and other agents. The question stops being "what does the model output?" and becomes "what does this system of models, tools, people and data do over time?" That is an ecological question.

Three principles from ecology

• Diversity is a feature. Monocultures are fragile. A single model on a single data source optimizing a single goal will eventually meet a problem it cannot handle. Diverse agents have blind spots that do not all line up.
• Observability is survival. Tracing, logging, evaluation and interpretability are the senses of an AI system. The cost of not seeing your system is measured in surprises.
• Small interventions have large effects. Ecologists restore a keystone species rather than rebuild a habitat. In AI, the equivalent is a careful prompt, a better tool or a smarter protocol.

Find your keystone

Remove sea otters from a kelp forest and the urchins they eat multiply until the forest collapses. Your AI stack has keystones too: a single evaluation pipeline, a shared dataset, a coordination protocol. Identify them, protect them and invest in them.

A factory foreman optimizes a known process. A gardener tends a system that changes with the weather: weeding, watching, watering, pruning, and never trying to turn a tomato into a pear tree. The organizations that thrive with agentic AI will stop thinking like model builders and start thinking like gardeners.

Govern · global AI policy

One AI governance program, many regimes

Picture a bank that runs AI in India, the UK and the US, with a technology center in Bengaluru serving all three. Its compliance team starts three separate AI projects: one for India's data protection rules, one for the EU AI Act because some customers are in Europe, and one for a patchwork of US state laws. Each has its own spreadsheet, its own consultants and its own deadlines.

That is the expensive way to do it. Read the rules side by side and the same seven requests keep appearing: know your AI and its risk; tell people when AI is involved; keep a human accountable; protect personal data; test for fairness; secure the system and report incidents; and document who owns what.

Build the core once

Put those seven capabilities into one program, ideally on an ISO/IEC 42001 management system with the NIST AI Risk Management Framework as a shared vocabulary. One AI inventory. One risk-tiering method. One set of human-review, testing and incident processes. Then add a thin layer for each market:

• India: DPDP notice, consent and breach duties from May 2027, labels on synthetic content under the 2026 IT Rules, and RBI's FREE-AI expectations for lenders.
• European Union: AI Act transparency now, high-risk conformity work before December 2027, and GDPR for training data.
• United Kingdom: the reformed automated decision rules, with notice, human review and the right to contest.
• United States: state laws such as Colorado's automated decision-making law from January 2027, plus HIPAA and fair-lending rules.
• Asia-Pacific: Korea's AI Basic Act, China's labeling rules and Singapore's guidance for agentic AI.

India as the bridge

India's global capability centers now build AI for parent companies everywhere. They sit exactly where these regimes meet: Indian data law at home, their parents' market rules abroad. A center that runs the common core well becomes a compliance asset for the whole group, not a risk.

There is a nice echo here. India's AI Governance Guidelines call their seven principles sutras, the same word the ninth chapter of The Algorithms of Life explores: short threads that hold a larger idea together. Good governance works the same way. A few well-chosen threads, applied consistently, hold more than a thousand market-specific rules ever will.

Status as at September 2026. Not legal advice.