Using the Strangler Pattern to Add AI Around Legacy Systems Without Rewriting the Core

Legacy systems often contain years of business rules, data relationships, and operational behavior that make introducing new AI capabilities difficult. Instead of replacing the core application, the Strangler Fig pattern offers a safer approach by adding new functionality around the existing system. This incremental modernization technique introduces seams between components and allows gradual migration of behavior when it makes sense to do so.

To apply the Strangler Fig pattern, start by isolating a specific workflow with a clear input, output, and operational boundary. In the case of an order-management application, an AI component could classify incoming requests, retrieve relevant order information, and suggest actions. This does not require replacing the core order-management system. Instead, an adapter exposes the specific operations the AI component needs to work with.

An important aspect of this approach is putting an adapter between the AI component and the existing system. A common mistake is connecting the AI directly to database tables or internal functions, which can couple model-generated decisions to implementation details that were not designed as public contracts. The adapter provides a controlled boundary that translates between the AI's request format and the existing application's supported operations.

The AI component should not automatically inherit the authority to change business state. Instead, a deterministic validation layer checks whether the proposed action is permitted. The existing application remains responsible for customer identity, order state, inventory, and business rules. The AI proposes, while the application validates and executes the approved operation.

Structured output from the AI integration can be easier to validate, but this output does not guarantee that an action is correct or authorized. Separate validation stages should verify the output structure, resolve referenced entities, check authorization for the requested operation, ensure business invariants are met, and apply risk-based approval rules. Only after these checks should the command be executed through the established application interface, and the result should be recorded.