Learnings From the Trenches

Every enterprise software company is asking some version of the same question:

How do we use AI agents to ship faster and unlock new customer value without putting our mission-critical product at risk?

That question matters because AI agents change the economics of software development. They can generate code, tests, documentation, and implementation options at a pace that was not possible before.

It is also a question I'm obsessed with. For most of my career I have scaled and transformed large enterprise software product portfolios, and I believe accelerating that work can unlock real value for these companies and their customers. In recent work with an enterprise software customer, we set out to explore the problem in practice.

What we found is that the bottleneck is not writing code. The real bottleneck is understanding existing behavior, controlling the blast radius of change, validating that change, and shipping with confidence.

Enterprise products carry years of accumulated customer expectations, edge cases, business rules, workflows, permissions, integrations, and operational assumptions. They work. They are trusted. Customers depend on them for business-critical scenarios. And now they need to evolve for a world where AI agents are part of how software is built, maintained, and operated.

The rest of this article covers three questions:

1. What does it mean for enterprise software to be agent-ready?

2. Why is bounded-domain modernization a better path than a big-bang rewrite?

3. Why is a platform needed to manage both the transition and ongoing AI-assisted evolution?

What We Mean by Agent-Ready Enterprise Software

Agent-ready enterprise software is software whose codebase, architecture, specifications, tests, workflows, and operational evidence allow AI agents to safely help maintain and evolve the product. Four elements matter most.

First, it needs the right system context. Agents need to understand business rules, workflows, data models, permissions, integrations, edge cases, and historical decisions. Without that context, they may generate code that looks correct but violates important product behavior.

Second, it needs modular boundaries. Agents are more effective and safer when they can reason about smaller units of functionality with clear interfaces. Modularity reduces blast radius and makes human review easier.

Third, it needs automated validation. Agents can move quickly, but they need tests, comparable workflows, and evidence that their changes preserve expected behavior.

Fourth, teams need guardrails and auditability. As agents become more involved in code changes, teams need to know what changed, why, what evidence was generated, what was approved, and what behavior shifted.

Most enterprise products were not designed with any of this in mind. That is the connection between agent readiness and modernization.

Why Agent Readiness Often Requires Modernization

For mission-critical enterprise products, the challenge is not just legacy technology. It is accumulated behavior.

The agent reads the code, but it cannot see the rule the code was written to enforce, so it confidently "fixes" behavior customers depend on. It makes what looks like a small, local change, but with boundaries long since eroded, that change ripples into reporting, permissions, and integrations it never knew to check. It produces a clean diff that passes review, because neither the agent nor the reviewer has tests that prove behavior was preserved. The regression surfaces in production weeks later. And when it does, no one can reconstruct what the agent changed or why.

The problem is not that the agent is careless. It is that the system gives it nothing to be careful with. Worse, because agents generate quickly and confidently, they remove the slow manual friction that once let a human catch themselves halfway through a risky change. Speed applied to an opaque system does not produce faster good outcomes. It produces faster, more plausible, harder-to-detect mistakes.

This is why agent readiness often requires modernization. Not because every old system must be replaced, but because the context, boundaries, evidence, and history agents need already exist inside the legacy system, just not in a form anyone, human or agent, can use.

Why Not a Big-Bang Rewrite?

The temptation is to attempt a big-bang rewrite. If agents can generate code so quickly, why not recreate the product on a modern stack in one shot?

Because the hard part is not generating code. The hard part is preserving behavior, validating equivalence, integrating with the existing product, and switching over safely.

Large rewrites are tempting because they promise a clean future state: new architecture, new stack, no legacy baggage. But in practice they tend to deliver value late, carry high execution risk, and force teams to maintain two worlds at once. The larger the scope, the harder it is to validate behavior; the harder it is to validate behavior, the harder it is to build confidence; and without confidence, modernization slows down.

Agents accelerate implementation, but they do not remove the need to understand what the software actually does. The existing system remains the reference implementation for the behavior the new system has to preserve.

The Better Transition: One Bounded Domain at a Time

The better unit of modernization is the bounded business domain: small enough to understand, modernize, and validate, but meaningful enough to create real architectural and product value.

Instead of rewriting an entire ERP, for example, teams might start with pricing, invoicing, order approval, entitlement checks, renewal calculations, or claims adjudication. The point is not to pick the smallest piece of code, but to pick a business capability with clear value, understandable boundaries, and enough isolation to validate safely.

This also answers a practical question: how does the modernized domain coexist with the existing product? In most cases the new domain should not replace the old one all at once. It can run alongside the existing product, exposed through clear APIs and routed selectively, while teams use feature flags, shadow execution, parallel runs, or phased cutover to compare behavior before moving production traffic. That model lets teams modernize incrementally while the existing product keeps serving customers.

A Practical Domain-by-Domain Model

The pattern that emerged is straightforward, and each step revealed a capability a platform for agent-ready software needs to support.

1. Select a Bounded Business Domain

Modernization starts with choosing the right slice — important enough to matter, but bounded enough to modernize without pulling the entire product into scope. This is as much a sequencing problem as a technical one. Choose too small a domain and the work may not prove enough; choose too large a domain and the effort starts to look like the big-bang rewrite you were trying to avoid. The right domain sits where business value, visible technical progress, and manageable execution risk intersect.

2. Extract Business Rules From Existing Code and Documents

Before a capability can be reimplemented, its behavior has to be understood: business rules, workflows, data flows, integration points, permissions, error handling, configuration logic, and edge cases. Much of this is implicit in the existing implementation, scattered across code, documents, tickets, wikis, and people's heads. Making it explicit is the core of the work.

AI-assisted engineering can accelerate this. Agents can summarize code paths, infer rules, identify workflows, and draft initial specifications, but they cannot replace human judgment. Product leaders, architects, and engineers still need to review the behavior that matters. The output should be specifications humans can understand, challenge, approve, and use as the basis for implementation and validation.

3. Map Critical Dependencies and High-Risk Change Paths

Enterprise applications rarely evolve into clean boundaries. Over time, business logic, UI behavior, data access, permissions, reporting, integrations, and operational workflows become tangled together. Some dependencies surface early with code analysis; others only emerge once the team starts separating a component from the existing product.

This is where AI coding agents are especially useful, letting teams explore implementation options, test extraction approaches, and identify risks earlier than manual analysis would allow. But speed does not eliminate the need for architectural judgment. The goal is not to make change everywhere faster — it is to understand where change is risky, where interfaces need clarifying, and where the blast radius needs to be reduced.

4. Modularize and Recreate the Component Behind Clear Interfaces and APIs

The architecture of the modernized component determines how safely it can be maintained later. When a system is modular, with well-defined interfaces and APIs, future changes can be isolated: agents can reason about smaller units, developers can review with clearer context, tests can be targeted, and failures can be contained.

The component should also be designed to coexist with the existing product, using the APIs, selective routing, and phased rollout patterns described above. You are not just moving functionality to a new stack — you are creating a component that can participate in a more automated, API-driven, AI-assisted development model.

5. Generate Automated Tests and Evidence of Equivalent Functionality

This is the step that separates responsible modernization from wishful rewriting. A modernized capability needs to behave consistently with what it replaces or augments, and for mission-critical software "it looks right" is not enough. Teams need evidence.

Side-by-side validation is especially valuable: run comparable workflows against the existing and modernized implementations, then compare API responses, UI behavior, data changes, integration behavior, logs, errors, permissions, and downstream effects. Some differences will be intentional, some will reveal obsolete behavior, and some will expose bugs or undocumented assumptions. The important thing is that they are visible, reviewed, and recorded before switching over. Behavioral continuity creates confidence, and confidence is what lets modernization move faster.

6. Instrument the Software for Auditability and Future Agentic Workflows

As agents become more involved in development, auditability becomes more important. Teams need to know what changed, why, what evidence was generated, what tests were run, what behavior shifted, and who approved the change.

Instrumentation should exist in both the existing product and the modernized implementation, so developers and agents can detect deviations, capture evidence, and build a reusable history of decisions and outcomes. Over time, those specifications, dependency maps, test results, workflow comparisons, change logs, and audit trails become part of the product's engineering intelligence — context that helps future agents operate with stronger guardrails.

What Is Actually New Because of AI Agents?

It is fair to ask how much of this is new. Bounded domains, modular architecture, automated tests, APIs, side-by-side validation, and phased migration are not new ideas; good teams have used them for years.

What is new is the speed and scale at which agents can generate and modify software. When code can be generated quickly, the constraint shifts: the bottleneck becomes context, validation, governance, and trust. The engineering system now has to produce machine-usable specifications, expose relevant context, run automated validation loops, capture evidence, and make change auditable. Human review still matters, but it increasingly has to be supported by generated evidence and clear behavioral comparisons.

In other words, AI does not replace engineering discipline. It makes that discipline more important, more explicit, and more automated.

Why a Platform Is Needed

This evolution requires a platform that gives agents the context, guardrails, validation, and auditability needed to safely maintain and evolve enterprise software — and that means doing far more than generating code.

A platform has to help teams understand the existing system, identify bounded domains, extract business rules, map dependencies, generate specifications, orchestrate AI-assisted implementation, run old-vs-new validation, capture evidence, manage approvals, and preserve audit trails. It also has to support ongoing evolution after the first modernization step: once a domain is modernized, agents should be able to inspect its specifications, understand its APIs, propose changes, run tests, compare behavior, generate documentation, and operate within the guardrails the team has defined.

That is what makes enterprise software truly agent-ready — not AI features bolted on top, not faster code generation, and not a one-shot rewrite, but the ability for agents to safely understand, change, validate, and evolve the product with the right context, boundaries, evidence, and human oversight.

For engineering leaders, that is the real opportunity. AI increases the speed of change; enterprise teams need systems that increase the safety, observability, and confidence of change. That is how mission-critical software companies can move faster without breaking the trust their customers depend on.