Two Agent Stacks, One Problem: A2A/MCP on Bedrock vs. LangGraph

For a long time, building with LLMs was dead simple: user prompt → OpenAI API → string back → display it. But once you start building real tools — automated customer agents, code debuggers, interactive tutors — a single prompt call isn't enough.

You need autonomous loops, memory, conditional routing. You need agents. I recently shipped two agentic tools for clients on completely different stacks: one on AWS Bedrock's native Agent protocols, one on LangGraph. Here's my honest comparison from production.

To keep this fair, here are the two real projects:

1. Watchlist Analyst Agent: Monitors financial markets, pulls real-time news, runs sentiment analysis, generates shortlists. Built on AWS Bedrock with custom Model Context Protocol (MCP) servers.

2. Interactive Tutoring Graph: Walks students through coding and math problems. Needs strict state management — track answers, score progress, route to easier or harder questions. Built with LangGraph, React, and a PostgreSQL state checkpoint database.

On AWS Bedrock, orchestration is protocol-driven. Agent nodes are separate services. They talk over A2A (Agent-to-Agent) messages. Each agent owns its own MCP server, exposing tools as schema-validated endpoints. Pretty decoupled — your Analyst agent doesn't need to know how the News agent works. They exchange structured JSON.

LangGraph is a centralized state machine. The whole flow is a directed graph: nodes execute actions or call LLMs, edges handle transitions based on state. State is a shared, typed object passed along the graph. Under the hood it looks like this:

User Answer -> Parse Input -> Check Correctness (Node) -> Conditional Edge (Correct?) 
  ├── Yes -> Increment Score -> Next Question Node
  └── No -> Update History -> Suggest Hints Node -> Loop Back

Agents fail in production. Always. Finding the bug is the nightmare. Did the LLM return malformed JSON? Did a tool call time out? Did the state manager overwrite a history variable?

LangGraph plus LangSmith wins here. Trace-level visibility — exact state before and after every node, system prompt changes, edit and replay individual runs. Debugging feels like debugging normal code.

On AWS Bedrock you're leaning on CloudWatch logs and Bedrock's evaluation logs. Fine for verifying grounding, but in a 6-step loop, finding which transition failed is slow. The feedback loop just isn't as tight as LangSmith.

Neither framework stops hallucinations for you. That's on you.

On Bedrock I built a strict grounding validation layer. System prompt locked down — the LLM can only answer from retrieved news chunks. Not in the source files? Fallback message.

On LangGraph I added a verification node. When the math model outputs an answer, a deterministic Python parser intercepts it, re-runs the equations, checks if the numbers match. They don't? The graph routes back to the model with an error prompt and forces a self-correction before the user sees anything.

Depends on your architectural boundaries.

AWS Bedrock (A2A/MCP) if you're in an enterprise environment where agents need to be separate, decoupled microservices with independent lifecycles. Secure enough for production, scales without extra wiring, fits the AWS ecosystem.

LangGraph if you're building complex, stateful loops where context, history, and custom routing matter. The state machine pattern is intuitive, easy to hold in your head, and the debugging tools make development noticeably faster.

Bedrock bills per model token plus agent orchestration overhead. For the watchlist agent, most of the cost was inference on news summarization, not the A2A plumbing. The upside is you are not maintaining GPU boxes or model downloads — AWS handles that.

LangGraph on my tutoring project ran on a small Postgres instance for checkpoints plus standard API calls to the LLM provider. Cheaper to iterate locally, but I owned the ops: migrations, backup, and LangSmith subscription for traces. For a solo builder that trade-off felt worth it because debugging time dropped sharply.

The watchlist agent needed a temporary "human approval" step before sending a client alert. On Bedrock that meant adding another agent node, updating MCP tool schemas, and redeploying two services. It took most of a day.

The same change on LangGraph was one conditional edge and a new node function. I had it working in an hour. That is the practical difference: protocol-driven micro-agents shine when teams are already split; graph state machines shine when the product logic changes every week.

Ask these four questions before committing: Do agents need separate deploy units? Do you need visual step-by-step debugging? Are hallucinations punished by users or by compliance? And who owns infra — platform team or you?

If you answered yes to separate deploy units and AWS is already your home, start with Bedrock. If you answered yes to fast iteration and complex loops, start with LangGraph. You can wrap either behind the same React frontend — the user should never feel the orchestration war.

Log structured JSON for every agent step: input hash, tool name, latency, token count, and success/fail. On Bedrock that means CloudWatch metric filters; on LangGraph, LangSmith traces plus a Postgres audit table for tutor sessions.

Without those logs you cannot explain a wrong answer to a client or an angry student. With them, you can replay the exact step where the model picked the wrong database or skipped a hint node.