Modern software engineers are currently facing a frustrating paradox. On one side, they have the fluid, reasoning capabilities of Large Language Models that can plan complex tasks. On the other, they are tethered to rigid, deterministic legacy systems that communicate via strict REST API contracts. When a developer attempts to connect a cutting-edge AI agent to a decade-old internal database or a monolithic ERP system, they hit a wall. The input and output formats of the legacy system are incomprehensible to the agent, and the cost of rewriting thousands of lines of stable production code just to make it AI-compatible is often a non-starter for any risk-averse enterprise.
The Architectural Gap Between REST and A2A
To understand why this integration is so difficult, one must look at the fundamental difference between traditional API design and the emerging Agent-to-Agent (A2A) standard. For years, the REST API has been the gold standard for enterprise architecture. It is built on a deterministic, stateless flow where a client sends a specific parameter to a defined endpoint and receives a predictable response. This structure is highly efficient for standard business functions like creating, reading, updating, or deleting records, as it operates under a strict contract that ensures operational stability.
In contrast, A2A is designed for the autonomy of AI agents. Rather than relying on a fixed set of endpoints, agents use Agent Cards—metadata documents that define their capabilities, characteristics, and constraints. These cards allow agents to discover one another, negotiate tasks, and collaborate without human intervention. While REST focuses on single-endpoint calls, A2A utilizes structured messaging based on JSON-RPC to facilitate reasoning-based coordination. This allows agents to plan and delegate multi-step tasks, shifting the paradigm from simple data retrieval to goal-oriented execution.
Bridging these two worlds usually requires a complete overhaul of the service logic. If a team wants to move a legacy service to a standardized agent communication protocol, they typically have to rewrite the core logic to handle the new messaging format. This introduces a massive risk: the regression test burden. In a complex enterprise environment, changing the internal logic of a stable service to accommodate an AI interface can trigger unforeseen bugs in existing workflows, leading to costly downtime and extended development cycles.
Implementing the Agentic Overlay Pattern
Agentic Overlay solves this tension by introducing a thin interface layer that sits on top of existing REST APIs. Instead of modifying the underlying business logic, the overlay acts as a translator. It allows a system to maintain its original `/api/v2/...` paths for traditional clients while simultaneously exposing new `/a2a/...` paths for AI agents. When an A2A message arrives, the overlay converts it into a REST API request, forwards it to the legacy service, and then wraps the resulting data back into an A2A-compliant response.
This design pattern transforms a static service into a functional agent by adding essential components like Agent Cards, message endpoints, and health checks without touching the source code. The technical core of this implementation lies in the message payload extraction logic. By using a specialized function, the system can handle both standard messages and streaming responses consistently.
def extract_message_payload(message):SendMessage와 SendStreamingMessage 모두에서 페이로드를 추출하여 처리
return message.get('payload')
For tasks that require significant processing time, such as generating complex financial reports or analyzing massive datasets, the Agentic Overlay employs Server-Sent Events (SSE). While a simple calculator service can return a result instantly, long-running agent tasks benefit from SSE to push incremental updates to the user. This prevents the connection from timing out and provides a more responsive experience, mirroring the streaming nature of modern LLM interactions.
The Strategic Trade-off in Legacy Modernization
When deciding how to integrate AI agents into an existing ecosystem, organizations typically choose between three paths, each with a different risk profile. The first is the Separate Stack approach, where developers build a completely new A2A stack alongside the existing REST stack. While this avoids touching legacy code, it creates a resource nightmare. The company must maintain two separate codebases for the same functionality, doubling the infrastructure costs and requiring every single update to be implemented twice.
The second path is Shared Logic Refactoring. In this scenario, developers extract the core business logic into a shared service that both the REST and A2A interfaces call. On paper, this is the cleanest architectural solution. In practice, however, it is the most dangerous. Altering the internal structure of a legacy system often leads to behavioral shifts that are difficult to detect. This necessitates a massive regression testing effort across the entire system, which often extends the transition period from weeks to months.
Agentic Overlay provides a third way. By adding a wrapper layer that leaves the REST endpoints untouched, it preserves the existing build, test, release, and rollback pipelines. There is no need to rebuild the infrastructure or migrate data. The business logic remains a black box that continues to function exactly as it did before, while the overlay provides the AI-ready interface. This approach minimizes both the infrastructure overhead of the separate stack and the validation risk of refactoring.
Scaling with MCP and SDK Integration
Beyond simple connectivity, the Agentic Overlay addresses the growing problem of Agent Sprawl. As companies deploy more specialized agents, managing the proliferation of independent agent servers becomes an operational burden. By reusing existing REST services as agents, organizations can keep their infrastructure lean.
This efficiency is further enhanced by integration with the Model Context Protocol (MCP). MCP allows models to exchange data and tools in a standardized way. By exposing REST APIs as MCP-compatible tools through the overlay, developers can route requests directly within the agent's scope. This eliminates the need to build separate MCP servers for every single tool, simplifying the infrastructure layer while maintaining broad compatibility across different AI models.
To accelerate adoption, official A2A SDKs are available for FastAPI and Starlette applications. These SDKs abstract the complexity of adding `/a2a/` paths and managing the message conversion process. Even for older Flask applications, A2A libraries can be integrated to provide the same functionality. By leveraging the asynchronous processing capabilities of these frameworks, the SDKs ensure that the translation layer adds negligible latency to the request cycle.
For enterprises running monolithic systems—such as legacy internal management tools or old calculation engines—the Agentic Overlay is particularly potent. In these environments, a minor change to a core module can cause a systemic failure. The overlay allows these companies to implement a supervisor agent architecture, where a high-level agent handles intent classification and routing, while the heavy lifting is performed by the battle-tested legacy REST services. The AI manages the collaboration and communication, but the legacy system handles the actual computation, ensuring that stability is never sacrificed for the sake of innovation.
Ultimately, the success of AI agent adoption in the enterprise does not depend on the courage to rebuild everything from scratch. Instead, it depends on the ability to safely wrap existing assets to control risk. By comparing the cost of modifying a REST API against the cost of regression testing, it becomes clear that the overlay is the most pragmatic path toward system modernization.
