My last post talked about the problems that Logic Entombment poses for AI; now, let's talk about how we can start to fix them. One thing I've noticed in every conversation about modernizing legacy systems is that the prescription arrives before the diagnosis. Someone reads about Domain-Driven Design or microservices, gets excited, and immediately wants to rearchitect everything. I've been guilty of this myself.
The problem is that "rearchitect everything" is a multi-year program that requires sustained organizational will, significant budget, and a level of engineering maturity that most companies are still building toward. If you treat it as Step 1, you either never start or you start and stall out halfway through, leaving yourself with the operational complexity of two architectures and the benefits of neither. I've seen both outcomes more than once.
The more useful question isn't "what should our architecture look like eventually?" It's "What is the minimum change that makes our business logic callable by an AI today?"
To answer that, you need to know where you actually are. Here's how I think about it.
Level 1: Fully entombed
Your core business logic lives inside applications that have no external interface. Stored procedures in the database. Monolithic codebases where pricing, eligibility, and workflow rules are tightly coupled to UI rendering and data persistence. Nothing can call your business logic except your own application, and it can only do so through the full transaction stack.
Most established organizations with systems older than ten years are here, at least in some part of their stack. This is the norm, not the exception.
Level 2: Partially wrapped
Some systems have been given a REST API or a middleware layer. Maybe your CRM is accessible via API, but your order management system isn't. Maybe you wrapped your product catalog a few years ago, but the pricing engine is still buried. Coverage is inconsistent. AI can reach some functions cleanly and hits walls in others.
This is where many digital transformation programs end up and then stall. The easy systems got wrapped, and the hard ones didn't.
Level 3: Modular core
Your major business domains have been separated, and each has its own well-defined interface. Billing, inventory, customer profile, and pricing are independently callable, testable, and deployable. The tight coupling between them has been broken. Data flows through defined contracts rather than shared database tables. The services work. The problem is that they were designed for human-facing workflows rather than enabling systems to work with them autonomously. An AI agent can call them, but it has to poll for changes, handle side effects explicitly, and do a lot of translation work on the responses it gets back.
This isn't a bad place to be; you're still able to do a lot, but you just can't achieve the full potential for AI unless you make your systems more able to operate without a human-initiated action.
Level 4: AI-ready
Your architecture is composed of discrete, independently callable services. An AI agent can invoke your pricing logic without triggering an email. It can check eligibility in a read-only way. It can compare outcomes across multiple options before committing to one. Your data emits structured events that downstream systems can consume reliably.
Most of the content you'll read about AI-ready architecture describes Level 4 as if it's where you start. It's where you're trying to get to.
The practical question is: what's the right move from Level 1, and what's the right move from Level 2? Because they're different.
From Level 1: Wrap, don't rewrite
If you're fully entombed, the fastest path forward is not rearchitecting. It's wrapping. Build a facade, a REST or GraphQL layer that sits in front of the legacy system and translates requests. The underlying code doesn't change. You're not touching the stored procedures. You're building a translation layer that gives AI (and anything else modern) a clean interface.
This is less satisfying than a proper architectural redesign. It's also achievable in weeks rather than years, and it lets AI projects move forward while the deeper modernization happens in parallel. Pick the specific functions your AI initiative needs most. The ones with the clearest inputs and outputs and the lowest coupling to side effects, and start there.
From Level 2: Be systematic about coverage
If you're partially wrapped, the problem is usually that the wrapping happened opportunistically rather than strategically. Systems got APIs when someone needed them, not according to a plan.
The move here is to map which business logic your AI initiatives actually need, trace where that logic lives, and systematically close the gaps in API coverage. This is more achievable than it sounds because AI projects tend to need a focused set of capabilities it's rarely "wrap everything" and more often "wrap these five functions."
Domain-Driven Design is worth introducing here, but not as an architectural blueprint, rather as a diagnostic tool. Use it to identify the natural boundaries in your business logic, the places where one domain's rules end and another's begin. That's where your services should break. You don't have to implement it all at once. You just need a map of where you're going so that each wrapping decision moves you in the right direction rather than creating new coupling.
From Level 3: Eventing
At this stage, the focus is on introducing event emission and read-only query support. When your pricing service recalculates, it should emit an event that downstream systems, including AI agents, can consume without having to ask. When your eligibility service gets called, it should support a dry-run mode that returns a result without writing anything. These aren't architectural overhauls. They're targeted additions to existing services that already work.
The organizations that modernize successfully treat it as a continuous program of incremental extraction, not a single transformation event. Netflix is a great example of this. They've had many services over the years, with a gradual migration while the service stayed live. Most companies aren't Netflix, and they don't need to be. They just need to make a series of small, deliberate moves that each leave the system more callable than it was before.
Figure out which level you're at. Make the right move for that level. Don't skip ahead.
Tomorrow I want to close this out with the part that doesn't get talked about enough: why this is actually an accounting problem, not an architectural one.