再構築ではなくレトロフィット：レガシーエンタープライズサービスを変革するエージェンティックオーバーレイ Retrofit, don’t rebuild: Agentic overlays for transforming legacy enterprise services

Enterprises run on large estates of REST-based services that handle critical business functions, from order management to claims processing, yet almost none of these systems were designed to be consumed by AI agents. In a technical collaboration published on the AWS Machine Learning Blog, AWS and the article's authors propose what they call an agentic overlay: a thin wrapper layer that makes existing REST services usable by large language model agents without rewriting the underlying applications. The idea matters because it reframes modernization away from expensive, risky rebuilds and toward incremental retrofitting of systems that already work.

The problem the overlay addresses is a mismatch in how software is consumed. Traditional REST APIs assume a deterministic caller that already knows which endpoint to hit, what parameters to send, and how to interpret the response. AI agents operate differently: they reason over a task, decide which capabilities to invoke, and translate between natural language intent and structured calls. Bridging that gap by hand, endpoint by endpoint, is slow, and rebuilding legacy services as agent-native systems is often impractical given their embedded business logic, compliance constraints, and operational dependencies.

An agentic overlay sits between the agent and the existing service. Conceptually, it exposes legacy REST endpoints as a set of tools or actions that an agent can discover and call, while handling the translation, orchestration, and guardrails in between. Rather than altering the service, the overlay describes its capabilities in a form the agent's model can reason about, maps the agent's chosen action to the correct underlying API request, manages authentication and parameter validation, and shapes the response back into something the agent can use. Because it is a wrapper, the original service keeps serving its existing consumers unchanged, which lowers the blast radius of adoption and lets teams modernize one capability at a time.

This work fits into a broader set of AWS tools for building agents. Amazon Bedrock provides access to foundation models and, through features such as Bedrock Agents and action groups, already supports invoking APIs defined by OpenAPI or function schemas. The overlay pattern appears to generalize that approach, emphasizing a reusable layer that can front many existing services rather than a bespoke integration for each one. It also aligns with the industry's growing interest in standardized ways to connect models to external systems, most visibly the Model Context Protocol, which defines a common interface for exposing tools and data sources to agents. An overlay can be seen as a way to project legacy functionality into these emerging interfaces.

For practitioners, the technical detail that typically determines success is the quality of the capability descriptions. Agents rely on clear, well-scoped tool definitions to choose actions correctly, so an overlay's value depends heavily on accurate metadata, sensible naming, and constraints that prevent the model from constructing invalid or unsafe requests. Equally important are the cross-cutting concerns the overlay can centralize: identity and authorization, rate limiting, input and output validation, auditing, and observability. Concentrating these controls in one layer is likely easier to govern than scattering them across many ad hoc integrations, which is a meaningful consideration for regulated enterprises.

The approach should be understood alongside conventional legacy modernization strategies, sometimes framed as the "rehost, replatform, refactor, rebuild" spectrum. An agentic overlay does not replace those options; it is closer to an additive layer that extends reach while deferring deeper change. That can be an advantage when the underlying service is stable and valuable, but it is not a universal answer. Overlays add latency, introduce another component to operate, and inherit whatever limitations the underlying API imposes. Services with poor documentation, inconsistent error handling, or brittle contracts may need cleanup before an overlay can reliably expose them.

As a pattern, the agentic overlay reflects a pragmatic stance now common across the agent tooling landscape: meet existing systems where they are. Organizations evaluating it will likely want to weigh the speed of retrofitting against long-term architectural goals, and to pilot the approach on lower-risk services before extending it to mission-critical workflows. The AWS post positions overlays as one practical route to making enterprise systems agent-ready, rather than a wholesale replacement for traditional modernization.