No. 05 · Conceptual

The Four Approaches to AI Modernization

From repairing one system at a time to dissolving the application altogether: the four routes by which a government rebuilds itself at speed.

The earlier papers in this collection measured the estate and showed why it cannot be fixed the old way. We know what we run, we know its health, and we know that at the pace government has always worked the repair bill is counted in decades. This paper is about what we do with that knowledge. There are four ways to modernize a government system with AI. They climb in ambition, from the lightest touch to the most complete rebuild, and no single one of them covers everything. A real government estate needs all four.


## §01 Four routes forward

The four approaches are the **AI Garage**, the **AI Factory**, **AI Rationalization**, and **Government 3.0**. The Garage fixes a system in place. The Factory builds a new one to replace it. Rationalization collapses a whole portfolio of overlapping systems into a few modern modules. Government 3.0 dissolves the application altogether and lets AI agents work directly against governed data. Each is suited to a different kind of system, and each asks more of the organization than the one before it.

Which approach a system gets depends on its condition. The Ministry decides with a simple four-way test, applied to one system at a time: tolerate it, invest in it, migrate it, or eliminate it. A healthy system can be tolerated and lightly patched. A sound system on dying technology should be migrated to a new build. A tangle of overlapping systems is a candidate for rationalization. A system with no remaining business need is eliminated. The test is what keeps the effort pointed at the systems where it pays off, and it is what makes the four approaches a plan rather than a menu.


## §02 The AI Garage

The first approach is the lightest. We take one system at a time, the way you take a car into the garage, and fix what is wrong with it. A person clones the code, the AI reads it and makes the repair, the person checks the result, and the change goes back. We call it the Garage. It is the lowest-risk approach and the closest to how teams already work, which is why it was the first one we put into production.

The Garage does three kinds of work, and the right one depends on the system in front of it. It repairs: the AI patches a known flaw, upgrades an out-of-date library, writes a missing test. It remediates: where a system carries a security exposure, that is fixed first, and we work through the portfolio in order of risk, public-facing systems before the back office. And it matches: where the technology underneath a system has reached the end of its life but the way the system works is still sound, the AI rebuilds it on a modern foundation that behaves exactly like the original. The screens and the data land where the user expects them. Only the aging technology underneath is replaced, so a system once reached through a Citrix workaround becomes an ordinary application in a modern browser, back inside a supported lifecycle.

The Garage has a deliberate limit. It treats the symptoms rather than the disease. A repaired system is still the same old system, and a matched rebuild is still the same workflow on newer parts. For many systems that is exactly right, because they work, people rely on them, and all they need is to be made safe and supported. For others it is not enough, because the thing in front of us is the problem. The next three approaches go further.


## §03 The AI Factory

The second approach builds new. Instead of repairing an old system, we build a fresh one from scratch, designed the way we would design it today. We build it in what we call the AI Factory. The factory is made of software, not machinery. Inside it, a team of specialist AI agents works the way a strong delivery team works. One agent designs the architecture. Another writes the code. Others take the database, the testing, the security review, the accessibility, the documentation. They work together against one shared specification, checking and correcting each other until the application is finished.

The Factory is opinionated on purpose. Every application it produces is built the same modern way, on the same foundation, so quality comes from the line itself rather than from any one person's care. The specification is the contract. The agents build to it, the work is checked against it, and a person stays in the loop to accept or reject what the agents produce. Two things then make a Factory-built application different from what it replaces. It is modular, assembled from small parts, none of them much larger than a thousand lines of code, each one small enough to read and check on its own. And the government owns all of it, built on open-source foundations, with no licence we cannot exit and no vendor we cannot leave.

Building new also lets us start clean, free of the dead dependencies and decades-old assumptions of the system it replaces. This is the approach for a system whose technology is beyond saving, and for a brand-new service that has no legacy at all, one of the many new requests that keep arriving while the older work is still underway.

The Factory is the most developed of the four approaches, and it has three moving parts, each the subject of its own paper. The work is shaped and specified in a design environment, where a plain-language request becomes a buildable plan the agents can work to. The agents then build, test, and deploy it inside a secure sandbox under enterprise controls. And the whole effort is tracked and scored in a system that makes progress visible and lets competing approaches race on the same piece of work. This paper introduces the approach. Those three papers show how the Factory actually runs.


## §04 AI Rationalization

The third approach steps back from the single system and looks at a whole ministry at once. Picture a town that grew without a plan. Every building sank its own well, ran its own generator, and paved its own road to the door. Government software grew the same way. Almost every application built its own login, its own file upload, its own reporting, again and again, no two quite alike. Rationalization is the work of mapping what the ministry actually does, then laying the shared infrastructure once, so each common need is built a single time and used by everyone.

This is the approach that Git Insights Ministry makes executable. That tool reads an entire ministry of code at once and proposes a target architecture; rationalization is the act of building it. The pattern repeats wherever it is applied: hundreds of overlapping applications inside a ministry collapse into a small set of well-factored modules, with the common parts built once and shared. In one ministry, 185 applications resolved to 16 modules. Because the AI does the heavy analysis and most of the building, a program that once ran five to eight years can run in weeks to months.

Rationalization delivers the largest near-term gain of any approach in cost, speed, and quality, and it also asks the most of people. Collapsing 185 applications into 16 is a real change for the staff who have built their working habits around the old tools, and that change has to be planned with as much care as the rebuild itself. The technology is the easier half of the problem. The harder half is bringing people with it.

"The same login, rebuilt in dozens of applications, becomes one shared sign-on. Rationalization finds every such duplication and builds it a single time, for everyone." · Paper 5 · The Four Approaches to AI Modernization


## §05 Government 3.0

The fourth approach is the most radical, and it questions whether we need traditional applications at all. In this model the data stays where it is, but it is properly governed and exposed through a clean, well-documented interface that an AI agent can read. On top of that governed data sits a layer of agents. There is no fixed application in the middle. When a person needs to do something, the agent assembles the interface for that task, that person, and that moment, then takes it away again when the work is done.

Two ideas make this work. First, the business rules are written once, as code, drawn straight from legislation, regulation, and policy. As the law changes, the rules change, and every interaction follows the new rule the same day. Second, the AI becomes the customer of the data. Instead of a thousand screens each reaching into the database in their own way, agents read and write through one governed, audited interface. The thousands of separate user interfaces that government maintains today, each one built, patched, and secured on its own, largely disappear, and with them most of the code that has to be kept alive.

This is the most cost-effective and the fastest model of the four, because the most expensive thing in government software, the software itself, is mostly gone. It is also the most demanding. It depends on data being genuinely well governed, on rules being faithfully codified, and on every agent action being observable and accountable to a named person. We are not there yet. But it is the direction the work is pointed, and the choices we make now are meant to be compatible with it. It is, as the saying goes, where the puck is heading.

It helps to see the arc. Government 1.0 was paper and counters. Government 2.0 was digital forms and websites, faster than paper but still slow. Government 3.0 is the public service working with AI agents as first-class workers, accountable at every step, where a request that once took days is answered in minutes.


## §06 All four, and what comes next

These four approaches are compatible within one organization. We do not have to choose just one. A government estate is too varied for that. Some systems are tolerated and lightly patched in the Garage. Some are rebuilt new in the Factory. Some are folded into a larger consolidation through Rationalization. And over time, more and more of the work moves toward the agentic model of Government 3.0. The four-way test, tolerate, invest, migrate, or eliminate, routes each system to the approach that fits it, so the effort lands where it produces the most value. All four are needed to modernize a government at speed.

The target the four approaches reach for ~95%. A reduction of roughly ninety-five percent in the cost and time of building and maintaining government software. That is the difference between rebuilding the estate inside a single term of government and taking the better part of a century at the conventional pace.

Taken together, the four approaches are how we reach that target. We now have a clear picture of how government can be rebuilt. That raises the next question. If AI is going to do this much of the work, repairing, building, consolidating, and in time operating the systems government runs on, how do we make sure it does that work well, safely, and to a standard we can defend? The answer lies in the structure we build around the AI itself. 


We call that structure the harness, and it is the subject of the next paper: **The Well-Built Harness**.

Tags: modernization, architecture, ai-factory, government-3-0, strategy

Open the interactive version