The temptation you must refuse
The most dangerous idea in enterprise AI integration is the total rewrite dressed up as modernization. It shows up as "let's rebuild this system as AI-native from the ground up," and it is nearly always a mistake. Rewrites of large, working systems are among the highest-risk projects in software; adding AI to the justification does not lower the risk, it just makes the pitch more exciting. We have seen these programs consume years and budgets to reproduce, imperfectly, functionality that already worked.
The alternative is unglamorous and effective: integrate incrementally at the seams. Wrap what exists, add AI capability at well-chosen boundaries, govern it carefully, measure whether it helped, and expand only where the evidence supports it. You keep the business running the entire time. You never bet the company on a single cutover. And you build organizational confidence with each small, reversible win rather than staking everything on one enormous, irreversible one.
What This Looks Like in Practice
Here is the pattern we use to fit AI into stacks that were built long before anyone was thinking about it.
Find the seams, not the core. Every legacy system has boundaries—API layers, integration points, batch handoffs, the edges where data enters and leaves. Those seams are where AI integrates safely, because you can add capability there without opening up the fragile core. A well-placed adapter that adds an AI-driven step at a boundary is worth ten heroic attempts to inject intelligence into the middle of a monolith. Meet the system at its edges.
Wrap, do not rewrite. Treat the existing system as a dependency behind a clean interface, and build the new AI-enabled behavior against that interface. This is standard ports-and-adapters thinking, and it pays off doubly with AI: it isolates the probabilistic, model-driven parts from the deterministic core, and it gives coding agents a legible boundary to work against. Agents like those in Cursor and Claude Code are far more effective building a new adapter with a clear contract than spelunking through undocumented legacy internals—the same as any engineer.
Keep the control plane deterministic. When you add AI at a seam, the surrounding logic—validation, authorization, retries, fallbacks—stays deterministic and testable. The model layer is where the probabilistic behavior lives; everything around it should be predictable code you can reason about and roll back. This separation is what lets you add AI to a system with real consequences without those consequences becoming unpredictable.
Govern access as part of the integration. Which model tier handles which task, what data is allowed to reach it, and where a human must approve an action are integration decisions, not afterthoughts. The providers—OpenAI, Anthropic, and Google's Gemini API—give you tiered models and configuration for exactly these choices. In an enterprise with real data-handling obligations, wiring these controls in at the boundary is far cleaner than trying to bolt governance on after the capability is already threaded through the system.
Measure at the seam, with evals. Because you integrated at a boundary, you can measure at that boundary: is the AI-enabled step producing better outcomes than what it replaced, at acceptable cost and latency? Systematic evaluation—along the lines of OpenAI's evaluation best practices—turns "the demo looked good" into "the numbers say expand." Integration without measurement is just hoping in a more expensive way.
Choose modern runtimes for the new parts. The legacy core stays where it is, but the wrappers, adapters, and AI-facing services you add do not have to inherit its constraints. Deploying new integration layers on a modern edge runtime like Cloudflare Workers keeps the new surface simple and independently deployable, so you can iterate on the AI seam without redeploying the mainframe-adjacent monster behind it.
Done this way, integration becomes a series of small, reversible, measured steps. Each one either earns its place or gets rolled back. Nothing about the business's ability to operate depends on a single leap of faith.
Common Mistakes
The rewrite in disguise. We will keep saying it because enterprises keep trying it: "rebuild it AI-native" is a rewrite, and rewrites of working systems are where budgets go to die. Integrate at the seams instead.
Injecting AI into the fragile core. The instinct to put the intelligence "where the important logic is" leads teams straight into the least testable, most load-bearing part of the system. Add AI at the boundaries, where failure is contained and rollback is cheap.
Skipping the deterministic wrapper. Teams sometimes let model output flow directly into consequential actions with no deterministic guardrail around it. That is how you get a system whose behavior nobody can predict or explain. Keep validation, authorization, and fallbacks as ordinary, testable code.
Integrating without measuring. If you cannot tell whether the AI-enabled seam outperforms what it replaced, you have not integrated AI—you have added cost and complexity on faith. Build the eval into the integration from day one.
Boiling the ocean. The ambition to "transform the whole stack at once" produces multi-year programs that deliver nothing until they deliver everything, which is to say, often nothing. Small, expanding, evidence-backed steps beat grand unified plans in every enterprise integration we have seen.
Why incremental wins
There is a reason the wrap-govern-measure pattern outperforms the grand rewrite, and it is not merely risk aversion. Incremental integration produces learning at every step. Each seam you instrument teaches you something about where AI actually helps in your specific environment—which is never quite what the pilot predicted. That learning compounds. By the time you have integrated three or four boundaries, you have an evidence-based map of where the value is, and your expansion decisions get sharper. A big-bang rewrite, by contrast, forces you to commit to your assumptions before you have learned anything, and then discovers the assumptions were wrong at the most expensive possible moment.
Enterprises do not need to choose between their existing stack and an AI future. The stack is the foundation the AI future gets built on. Fit the new modules carefully into the structure that already stands, measure each one, and expand from what works. It is less dramatic than starting over. It is also the version that succeeds.
The enterprise that integrates AI well is not the one that started over. It is the one that fit modern capability, carefully, into the wall that was already holding up the building.
