The Great Rewiring: When AI Agents and REST APIs Become Partners, Not Rivals

You’ve spent years perfecting your Spring Boot microservices. You wrote OpenAPI specs. You versioned your endpoints. You debated PATCH vs PUT in code reviews that lasted longer than some relationships.

The agentic AI wave is arriving, and the hot takes are predictable: “REST is dead,” “agents replace everything,” “your API gateway is a dinosaur.”

They’re wrong. Here’s what’s actually going to happen - and it’s far more interesting.

The Take Nobody Is Having

The real future isn’t agents replacing REST APIs. It’s agents orchestrating them.

Picture a layered architecture where the customer-facing interaction layer is powered by A2A - agents discovering each other, negotiating tasks, handling ambiguity in natural language. But underneath, every state mutation, every payment charge, every compliance check still flows through your existing, battle-tested REST endpoints. The agents don’t bypass your APIs. They call them - through MCP tool servers that wrap each API with typed schemas, validation, and audit logging.

This hybrid makes the agentic layer more reliable, not less. Here’s why: the LLM never directly touches your database or payment gateway. Every consequential action passes through a deterministic REST call with the same validation, authentication, and error handling you’ve already built and battle-hardened over years. The agent decides what to do. The API ensures how it gets done is correct.

This is the architecture that will actually ship to production. To prove the concept, I’ve put together AgentCart - an open-source reference implementation you can run locally. Let me walk through how it all fits together.

The Problem With Both Extremes

The Pure Microservices Problem

Every enterprise architect knows the drill. You need Service A to talk to Service B, so you write an API contract, build a client, add request validation, response mapping, error handling, retry logic, circuit breakers, rate limiters, and an API gateway to tie it all together. By the time you’re done, you’ve written more glue code than business logic.

Consider a routine e-commerce order flow:

Five services. At least eight REST endpoints. Dozens of DTOs. Hundreds of lines of validation, mapping, and error handling per service. A Swagger UI that takes 30 seconds to load. And every time the business changes a field name, you’re updating contracts across four repositories.

The services themselves are fine. It’s the coordination between them - the orchestration logic, the saga management, the error recovery, the cross-service data transformation - that’s the real tax.

The Pure Agent Problem

Now consider the opposite extreme: replace everything with agents. No REST APIs. Agents talk to agents, agents talk to databases, agents make decisions and mutate state directly.

This is terrifying for production systems, and for good reason. An LLM might validate a payment field differently on Tuesday than it did on Monday. An agent that directly writes to your database has no guaranteed schema enforcement. When the regulator asks “why did you charge this customer $500?”, you need a deterministic audit trail - not “the agent decided it seemed right.” And prompt injection in a customer-facing agent could cascade into unauthorized state mutations.

Both extremes fail. Pure microservices drown in glue code. Pure agents lack the determinism and auditability that production systems demand.

The answer is a hybrid that plays to each paradigm’s strengths.

The Hybrid Architecture: A2A on Top, REST APIs Under the Hood

Here’s the core insight: use A2A as the coordination protocol between intelligent agents, and use MCP to give those agents access to your existing REST APIs as tools. The agents handle the messy, ambiguous, cross-domain orchestration. The REST APIs handle the precise, validated, auditable state mutations.

Three layers, each doing what it’s best at:

1. A2A Agent Layer - handles discovery, coordination, interpretation, dynamic routing, ambiguity resolution, and customer interaction. Agents can be built in different frameworks (LangGraph, Google ADK, OpenAI SDK, CrewAI) and still interoperate through A2A because the protocol is vendor-neutral.

2. MCP Tool Layer - wraps each REST API as a typed, validated tool that agents can call. This is the trust boundary. The MCP server enforces input schemas, rate limits, authentication, and logging before the request ever hits your API.

3. REST API Layer - your existing Spring Boot services, unchanged. Same validation. Same database transactions. Same compliance. Same audit trails. They don’t know or care that an agent is calling them instead of a React frontend.

The genius of this layering: the agent can never bypass the REST API’s validation. If the Payment Agent hallucinates an invalid currency code, the MCP tool schema rejects it before it reaches the API. If the schema somehow passes, the API’s own @Valid annotations catch it. Two layers of deterministic guardrails around every non-deterministic decision.

Seeing It in Action: AgentCart

To make this concrete, AgentCart implements the full hybrid architecture described above - five Spring Boot REST APIs, five MCP tool servers wrapping them, five A2A agents coordinating above, and a React chat UI at the front. The entire stack runs locally via Docker Compose.

A customer types one sentence. The agents figure out the rest.

The Happy Path: One Sentence to a Confirmed Order

The customer says: “I am customer C-001. I’d like to order 3 Blue Widgets delivered to my default address. Please charge my card token tok-test-visa.”

Behind that single sentence, the Order Agent:

1. Extracts intent and resolves “Blue Widgets” to product WB-001
2. Looks up the customer’s default address from their profile
3. Confirms the order details with the customer
4. Delegates to the Inventory Agent (via A2A) → which calls check_stock and reserve_stock MCP tools → which call the Inventory REST API
5. Delegates to the Payment Agent (via A2A) → which calls charge_customer MCP tool → which calls the Payment REST API
6. Delegates to the Shipping Agent → Notification Agent
7. Saves the order and returns a structured confirmation

Every state mutation - the stock decrement, the payment charge, the shipment creation - went through a deterministic, validated, audited Spring Boot endpoint. The agent coordinated the flow; the APIs ensured correctness.

Here’s what this looks like in LangSmith - the full agent reasoning trace across all five agents, with token counts and latency per step:

Notice the structure: extract_intent (2.5s, 537 tokens) → confirm_with_customer → check_inventory (7.3s, delegated to Inventory Agent) → process_payment (7.7s, delegated to Payment Agent) → arrange_shipping → save_order → send_notification → format_response. Five cooperating agents, each tracked separately, all linked by correlation ID ord-613567a0. Total cost: under a tenth of a cent.

The Failure Path: Agents That Know When to Stop

This is where the hybrid architecture really shows its value. When something goes wrong, the agent doesn’t just fail - it fails safely, with automatic compensation.

Try ordering 500 Widget Racks when only 25 exist. The Inventory Agent checks stock via its MCP tool, which calls the REST API, which returns “insufficient stock.” The Order Agent receives a failed status via A2A - and immediately stops the workflow. No payment is charged. No shipment is created. The customer gets a clear explanation.

Here’s the LangSmith trace for this failure:

Compare the two traces: the happy path hits all five agents across 33 seconds. The failure path runs only two agents (Order + Inventory) in 8 seconds and stops cleanly. The graph short-circuits at _after_inventory - the conditional edge evaluates the inventory result and routes directly to format_response, skipping payment entirely.

This is safer than a traditional saga. In a microservices saga, you’d need explicit compensation logic in a catch block to release reserved stock and reverse the payment if the shipment fails. In the agentic workflow, the LangGraph state machine has explicit conditional edges - each failure path is a visible graph route, not buried error handling.

Why This Hybrid Makes Agents MORE Reliable

The critical insight: the MCP layer wrapping REST APIs acts as a deterministic cage around non-deterministic agent behavior. Here’s the reliability chain:

   Agent decides "I should charge $49.99"        ← Non-deterministic (LLM reasoning)
           │
           ▼
   MCP tool validates: amount > 0? < 50k?        ← Deterministic (Python code)
   Currency in allowlist? Token present?
           │
           ▼
   REST API validates: @NotNull? @Positive?       ← Deterministic (Bean Validation)
   @Pattern on currency? Idempotency key?
           │
           ▼
   Stripe SDK processes charge                     ← Deterministic (payment provider)
           │
           ▼
   Database records transaction                    ← Deterministic (ACID guarantees)
           │
           ▼
   Audit log written                               ← Deterministic (append-only log)

The agent’s non-determinism is confined to the decision layer. Everything below it is deterministic. If the agent hallucinates a bad value, it hits one of two validation walls before any state mutation occurs. The compliance officer sleeps soundly because every charge still flows through the same audited Spring Boot endpoint.

Five Guardrails, Zero Gaps

The hybrid model has five guardrail insertion points, each catching a different class of failure:

  Customer says: "I wanna buy 3 of those blue widgets, charge my Visa"
           │
           ▼
  ┌─ GUARDRAIL 1: Input Understanding Validation ──────────────────┐
  │  LLM extracts: product="blue widget", qty=3, payment="Visa"   │
  │  Confidence check: did the LLM understand correctly?           │
  │  → If ambiguous: ask clarifying question via A2A               │
  │  → If confident: emit structured IntentSchema + proceed        │
  │  → ALSO: prompt injection scan (NeMo / LLM Guard)             │
  │  → ALSO: PII detection - mask credit card numbers before       │
  │    they enter the agent reasoning chain                        │
  └────────────────────────────────────────────────────────────────┘
           │
           ▼
  ┌─ GUARDRAIL 2: Agent Reasoning Validation ──────────────────────┐
  │  Supervisor agent or LangGraph checkpoint reviews the plan:    │
  │  → Is the agent calling tools in a sensible order?             │
  │  → Is it trying to skip inventory check before payment?        │
  │  → Has it exceeded max reasoning steps (loop detection)?       │
  │  → Are A2A task messages well-formed?                          │
  └────────────────────────────────────────────────────────────────┘
           │
           ▼
  ┌─ GUARDRAIL 3: MCP Tool-Level Validation ───────────────────────┐
  │  Before calling the REST API:                                  │
  │  → Schema enforcement: typed inputs, required fields           │
  │  → Business rule checks: amount ceiling, currency allowlist    │
  │  → Rate limiting: max N tool calls per minute per agent        │
  │  → Scope limiting: this agent can only call charge, not refund │
  └────────────────────────────────────────────────────────────────┘
           │
           ▼
  ┌─ GUARDRAIL 4: REST API Validation ─────────────────────────────┐
  │  The same validation that always existed:                      │
  │  → Bean Validation (@NotNull, @Positive, @Pattern)             │
  │  → Database constraints (foreign keys, unique indexes)         │
  │  → Business logic checks (sufficient balance, valid customer)  │
  │  → Idempotency enforcement (duplicate charge prevention)       │
  └────────────────────────────────────────────────────────────────┘
           │
           ▼
  ┌─ GUARDRAIL 5: Output Response Validation ──────────────────────┐
  │  Before the response reaches the customer:                     │
  │  → Structured output parsing (Pydantic schema enforcement)     │
  │  → Sensitive data filtering (strip internal IDs, tokens)       │
  │  → Tone/policy check (no hallucinated promises, no made-up     │
  │    delivery dates, no unauthorized discounts)                  │
  │  → Consistency check: does the response match what the         │
  │    REST API actually returned?                                 │
  └────────────────────────────────────────────────────────────────┘

Five guardrails, each catching a different failure class. A hallucination has to evade all five layers to cause harm - and even then, the three-layer audit trail (A2A task logs + MCP tool call logs + REST API access logs, all linked by correlation_id) shows exactly where it slipped through.

Consistent Responses, Not LLM Roulette

A key concern with agentic workflows: “I don’t want different responses every time.” The solution is to constrain the output, not the reasoning. The agent can reason flexibly about what to do. But when it produces a response, it’s forced through a Pydantic schema - same fields, same types, every time:

class OrderConfirmation(BaseModel):
    order_id: str
    status: str           # confirmed | failed | pending_review
    product_name: str
    quantity: int
    total_amount: float   # Code-calculated, not LLM arithmetic
    transaction_id: str | None
    tracking_id: str | None
    correlation_id: str   # Links to the three-layer audit chain

The agent’s reasoning path might differ between invocations, but the output shape is always identical. Money is always computed in code from the catalog price, never from the model’s arithmetic. And the final confirmation is validated against what the REST services actually returned - if the agent claims “charged $44.97” but the Payment API returned a different amount, the output validator catches the inconsistency.

Agents at the Front Door: Why This Matters for Customers

This might be the most immediately valuable part of the hybrid architecture. Putting an A2A-capable agent at the customer-facing boundary fundamentally changes how users interact with your system.

In the REST world, a customer’s natural intent - “I want 3 blue widgets delivered by Friday to my Sydney office” - gets decomposed into 9 form fields: product dropdown, quantity, delivery date picker, address line 1, line 2, city, state, postcode, country. The frontend translates intent to API calls.

With an agent at the front door, the customer types one sentence. The LLM handles what no @Pattern annotation can: fuzzy product matching (“blue widgets” → WB-001), relative date resolution (“Friday” → 2026-05-23), address from context (“my Sydney office” → lookup from customer profile), anomaly detection (500 units from a customer who usually orders 5), and conflict detection (“cheapest shipping + deliver by tomorrow” → flags the contradiction).

The agent confirms its understanding before acting - “I’ll order 3x Blue Widget at $14.99 each = $44.97, delivered by Friday. Go ahead?” - and only then delegates to the deterministic layers underneath. This confirmation step is Guardrail 1 in action: the customer validates the LLM’s interpretation before any API is called.

The Benefits: Why This Hybrid Wins

1. You keep what works and only replace what hurts. Your Spring Boot services, your database schemas, your compliance controls - all untouched. The only code you’re eliminating is orchestration glue: Feign clients, DTOs, mappers, saga coordinators, circuit breaker configs.

2. New capabilities without new endpoints. Need gift wrapping? Deploy a Gift Wrap Agent with an Agent Card. The Order Agent discovers it at runtime. No new Feign client, no DTO update, no coordinated deployment.

3. Dramatically faster time to market. In microservices, a new cross-service feature takes weeks of contract design, client code, integration testing, and coordinated deployment. In the hybrid model, you build the business logic (REST API + MCP tool), write an Agent Card, and the coordination layer wires it in automatically.

4. Framework and vendor independence. Your Order Agent runs on LangGraph. Your Inventory Agent could run on Google ADK. Your Notification Agent on CrewAI. They all interoperate through A2A because the protocol is vendor-neutral.

5. The compliance story gets better, not worse. In pure microservices, the audit trail is scattered HTTP access logs across five services. In the hybrid model, you have three linked layers of audit - A2A task logs, MCP tool call logs, and REST API access logs - all connected by correlation_id. One query reconstructs the complete decision chain.

6. Observable end-to-end. LangSmith traces the agent reasoning (which node, which LLM call, what tokens). OpenTelemetry traces the MCP-to-REST calls. Both linked by correlation ID. You see the full picture: agent decision → MCP guardrail check → REST API response → database write.

What Each Layer Is Best At

The Tooling Landscape: Hybrid Edition

The Mindset Shift

This hybrid architecture changes how you think about building systems:

From “code the contract” to “describe the capability.” Your REST API still has an OpenAPI spec for non-agent consumers. But for agent-to-agent coordination, the Agent Card describes what the agent can do in natural language. A new agent joining the ecosystem reads Agent Cards to understand who can help with what - no integration meeting required.

From “code every mapping” to “let the agent interpret.” The Order Agent doesn’t need a PaymentRequestMapper. It sends a natural language task to the Payment Agent. The mapping is implicit, not hand-coded.

From “orchestrate every step” to “delegate the goal.” Instead of a 200-line procedural saga, the Order Agent is a state graph that delegates goals (“reserve inventory”, “charge customer”) and makes routing decisions based on outcomes.

And critically: “The agent decides what. The API decides how.” The LLM’s non-determinism is channelled into decisions about routing, interpretation, and coordination - tasks where flexibility is a feature. The actual state mutations remain deterministic and auditable.

A Checklist Before You Adopt the Hybrid

1. Start with one coordination flow. Pick the orchestration layer with the most glue code. Replace the coordination with agents. Keep every REST API underneath.

2. Build MCP servers around your highest-value APIs first. Payment, inventory, and order management are good candidates - frequent calls, clear schemas, benefit from agent-level guardrails.

3. Invest in dual observability. REST-level traces (Jaeger/Datadog) AND agent-level traces (LangSmith/Langfuse) linked together. When something goes wrong, follow the thread from agent decision → MCP tool call → REST API request.

4. Set hard guardrails in the MCP layer. Amount ceilings, rate limits, allowlists, and mandatory fields should be enforced here - not trusted to the LLM.

5. Run the cost model. LLM tokens per interaction × daily volume + existing compute. AgentCart’s happy path costs under $0.001 per order - but at 100,000 orders/day, that’s $100/day in LLM costs alone.

6. Keep REST APIs available for non-agent consumers. Your mobile app, partner integrations, and batch jobs still call REST directly. The agents are a new consumer, not the only one.

Explore the Full Implementation

The entire architecture is open source: github.com/chaubes/a2a-rest-bridge

Five Spring Boot services, five MCP tool servers, five A2A agents, a React chat UI, LangSmith tracing, and Docker Compose to run the whole stack. Clone it, set your OpenAI key (or point it at a local Ollama instance - no cloud key needed), and you’re up and running.

git clone https://github.com/chaubes/a2a-rest-bridge.git
cd a2a-rest-bridge
cp .env.example .env   # add your OPENAI_API_KEY or set LLM_PROVIDER=ollama
docker compose up --build
# Open http://localhost:3000 and place your first natural language order

The Bottom Line

REST APIs aren’t dying. They’re getting promoted.

Instead of being the entire architecture - discovery, contracts, mapping, orchestration, validation, and business logic all tangled together - they become the reliable execution layer underneath an intelligent coordination layer. The A2A protocol handles agent-to-agent discovery and task delegation. MCP handles agent-to-tool access with typed schemas and guardrails. Your Spring Boot services handle the state mutations that need to be exactly right, every time.

The glue code - the Feign clients, the DTOs, the mappers, the saga orchestrators, the circuit breaker configs - that’s what evaporates. The business logic stays.

The developers who thrive in this transition won’t be the ones who throw away their REST APIs. They’ll be the ones who recognise that their APIs were always the valuable part, and that the 60% of code wrapped around them was just expensive plumbing that an intelligent agent layer can now handle dynamically.

Your REST APIs are about to become the most reliable tools in an agent’s toolbox.

The great rewiring has begun.

What would your hybrid architecture look like? Which of your microservices coordination flows would you hand to agents first - and which REST APIs would you wrap in MCP tomorrow? I’d love to hear your thoughts.

The full working implementation - with every pattern described above - is at github.com/chaubes/a2a-rest-bridge.

• ← Previous Post