Building Production AI Agents with LangGraph and AWS Bedrock AgentCore

AWS lifecycle notice (June 30, 2026) — Amazon Bedrock Agents Classic is in maintenance for new customers after July 30, 2026. Net-new agent builds should use Bedrock AgentCore. Full matrix: lifecycle roundup.

On June 17, 2026, AgentCore Harness reached general availability — a config-driven managed loop on the same platform as Runtime, Memory, Gateway, and Identity (What’s New). That date matters for LangGraph teams because it split the AWS agent story in two: Harness if configuration is enough, Runtime if you bring your own orchestration code.

LangGraph is the second path. AWS documents hosting a StateGraph on AgentCore Runtime with BedrockAgentCoreApp and init_chat_model(..., model_provider="bedrock_converse") (Use any agent framework). As of August 27, 2026, that is the production-shaped integration — not a LangGraph-shaped Harness, and not Agents Classic action groups.

First-party signals we reuse (not new client outcomes) — Gateway server-side tools cut median tool round-trip ~180 ms → ~95 ms on a B2B CRM assistant (12 tools, ~8k turns/day) — Gateway post. Platform TCO silhouette: support-style AgentCore at 50K sessions/mo ~$791/mo platform + model (decision guide). Model your mix on the AgentCore pricing calculator.

Reproduce this — Clone the artifacts under examples/architecture-blog-2026/langgraph-agentcore/. python3 -m py_compile langgraph_runtime_stub.py syntax-checks the Runtime entrypoint sketch. Ship gates live in monday-checklist.md. Open architecture.drawio for the layer diagram.

Opinionated take: put LangGraph on AgentCore Runtime. Keep Harness for the first single-domain agent. Keep Runtime + Strands as the AWS-endorsed multi-agent default if you do not already have a graph. DIY LangGraph on ECS is a keep-the-fleet decision, not a greenfield default in August 2026.

Trade-off you accept: you own graph upgrades, checkpoint semantics, and HITL resume logic in exchange for an explicit, reviewable workflow DAG that Harness config cannot express.

If you are building a general LLM application or a bounded create_agent tool loop — not an explicit graph — start with LangChain on Amazon Bedrock instead of forcing StateGraph.

From simple agents to agent systems

A single turn of LLM → prompt → response is a Bedrock Converse call. That is the right architecture for classification, summarization, and extraction with a fixed schema.

It is the wrong architecture the moment the product needs more than one decision:

• Stateful workflows — a support ticket that is classified, retrieved, acted on, and closed across several model calls.
• Multiple decision points — refund vs. replacement vs. escalate, each with different tools and IAM.
• Conditional execution — skip the write path unless a policy and a human agree.
• Tool usage — CRM, OMS, Knowledge Bases, internal APIs.
• Human intervention — high-impact actions pause until an operator resumes the graph.
• Agent collaboration — a researcher node and a writer node, or a supervisor plus specialists.
• Error handling — retries, compensating steps, and a terminal failure node rather than a hung loop.
• Long-running processes — overnight research, multi-hour coding agents, or a case that spans business days.

Those requirements are application workflow problems. LangGraph’s job is to make the workflow explicit. Amazon Bedrock supplies foundation models. AgentCore supplies production agent infrastructure. Mixing those three layers is how teams ship; collapsing them into “the agent framework will handle production” is how they page.

What is LangGraph?

LangGraph models agent workflows as graphs. The current Graph API names three primitives:

Compiling the graph validates topology and produces an executable that you invoke or stream.

A practical sketch — not a product demo — for a support ticket:

1. classify — rule or small model: intent, risk, language.
2. retrieve — Knowledge Base or runbook search into a state field (citations), not into “the prompt forever.”
3. act — tool node: lookup order, draft a reply.
4. human_gate — interrupt if the intent is refund / account-close / production-change.
5. close — persist outcome; emit the customer-visible message.

Conditional edges send low-risk tickets around the human node. A loop sends a failed tool result back to act with a retry counter in state — and a hard cap, or you will burn tokens until the session TTL saves you.

That is the whole trick: the graph is the control plane for application logic. The LLM is a node, not the orchestrator you cannot inspect.

Context for the Runtime wrapper (Python 3.12+, AWS sample shape; placeholders only):

# Pattern from AWS AgentCore "Use any agent framework" LangGraph sample.
# Pin model IDs to inference profiles your account allows. Set max_tokens.

from langchain.chat_models import init_chat_model
from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()
llm = init_chat_model(
    "us.anthropic.claude-sonnet-4-6",
    model_provider="bedrock_converse",
    max_tokens=1024,
)

@app.entrypoint
def agent_invocation(payload, context):
    tmp_msg = {
        "messages": [
            {
                "role": "user",
                "content": str(payload.get("prompt", "No prompt found in input.")),
            }
        ]
    }
    tmp_output = graph.invoke(tmp_msg)
    return {"result": tmp_output["messages"][-1].content}

# app.run()  # Runtime HTTP contract, typically port 8080

The live stub, including a HITL branch and DRY_RUN=1, is langgraph_runtime_stub.py.

Why stateful AI agents matter

Three different “state” words show up in the same design review. Mixing them is the most expensive LangGraph mistake we see on paper architectures.

Multi-step reasoning needs workflow state so step 4 can see that step 2 already retrieved policy section 4.2 — without resending a 40-page PDF on every hop.

Customer interactions need Memory so Monday’s chat is not amnesia on Tuesday, with actor_id and thread_id on the LangGraph config as AWS documents.

Business processes need workflow state that a compliance reviewer can read as a DAG: “refunds always hit human_gate.” A prompt that says “please ask a human” is not that DAG.

Long-running tasks need checkpoints so a Runtime recycle or a HITL pause does not restart from the user’s first sentence.

Multi-agent coordination needs explicit edges (or a supervisor node) and hop caps. Unbounded peer handoffs are a billing incident. For AWS-endorsed multi-agent primitives without a LangGraph investment, use Harness + Strands instead.

From a real engagement — A B2B CRM assistant, 12 tools, ~8k turns/day. The latency that moved was tool round-trip ~180 ms → ~95 ms after server-side AgentCore Gateway — not “LangGraph made the model faster.” If that assistant had been a cyclic graph with Browser left on, platform compute would have dominated the bill the way we already recorded on support-bot pilots (~3× Runtime-shaped spend). Put writes on Gateway Policy; keep the graph for routing and HITL.

LangGraph for enterprise AI agents

These are architecture sketches. They are not claimed client outcomes.

Customer support. Classify → retrieve policy → lookup order → draft. Refunds and account closure branch to HITL. CRM writes go through Gateway, not a tool that wraps boto3 with *:*.

Research agents. A retrieve-and-critique loop with a max-iteration field in state. Store sources in state; do not trust the model to remember URLs. Long jobs need Runtime session TTL and checkpointing — Lambda’s 15-minute ceiling is the wrong outer orchestrator.

Operations automation. Runbook RAG plus a small set of read tools (describe service, get alarm). Restarts and scale-in stay human-gated. Pair with the eCommerce AgentCore sample if you need a supervisor-plus-specialists shape.

Document processing. Deterministic split/OCR first (Bedrock Data Automation when it fits), then a LangGraph node for exception handling. Do not send every page through an agent loop.

Sales intelligence. Enrichment tools against a controlled CRM read API. No “query Salesforce however you want.”

Multi-agent coordination. Specialist subgraphs with a supervisor node and a hop counter. If you do not already have that graph, prefer Strands Agents-as-Tools on Runtime — same AgentCore host, less framework surface.

LangGraph + Amazon Bedrock

LangGraph does not speak Bedrock natively as a cloud service. You plug in a chat model.

Valid pattern: init_chat_model with model_provider="bedrock_converse" (AWS sample) or ChatBedrockConverse from langchain-aws. Both target the Converse surface on bedrock-runtime. Set max_tokens / maxTokens explicitly. Leaving it unset defaults toward the model maximum and silently reserves far more quota than a normal node needs — a common ThrottlingException cause.

Model abstraction. The graph nodes stay stable if you swap Sonnet for Haiku or Nova on a cheap classify node. Residency and ZDR are Bedrock account/model-path properties, not LangGraph settings. See Bedrock vs OpenAI API when the question is actually “where does the prompt go.”

Enterprise data access. Retrieval belongs in a node that calls Knowledge Bases (Retrieve) or a scoped search API, then writes citations + chunks into state. Agentic “search the intranet” without ACLs is not an enterprise pattern.

Tool integration. Bind tools the model may request, but execute them through IAM-scoped backends. Gateway is the production tool bus; LangGraph ToolNode is the in-graph dispatcher.

Guardrails stay on the Bedrock invoke (or a dedicated step). They are not a LangGraph feature.

LangGraph + AWS Bedrock AgentCore

AWS is explicit: AgentCore Runtime is framework-agnostic. The LangGraph sample adds BedrockAgentCoreApp, an @entrypoint, and graph.invoke (docs). Full sample: awslabs/amazon-bedrock-agentcore-samples langgraph.

Memory is a separate, documented integration: AgentCoreMemorySaver for checkpoints and AgentCoreMemoryStore for long-term extracted memories (Memory + LangChain/LangGraph). Invoke config must include thread_id and actor_id.

Harness vs Runtime. Harness is the paved road when model + instructions + tools + memory config is enough (production guide). Runtime is the paved road when you ship LangGraph (or Strands, CrewAI, a BYO container). Picking Runtime “for flexibility” on a workflow Harness covers means you inherited framework upgrades and loop debugging you did not need.

Gateway + Policy. Graph edges do not authorize refunds. Cedar (or NL→Cedar) on Gateway intercepts tool calls. LOG_ONLY, then ENFORCE. Identity brokers outbound credentials so the container never holds the CRM API key in an env var the model can be tricked into printing.

Observability. Runtime emits OTEL-compatible traces into CloudWatch. Evaluations need the documented span attributes (input, output, tool results). Traces without a golden suite are not a quality gate.

Runtime contract (do not skip): ARM64 images; health endpoint; port 8080 by default; create a Runtime endpoint or nothing is invocable. See the AgentCore Runtime model.

What broke — Teams treating LangGraph checkpoint blobs as “we already have Memory.” After a Runtime recycle the graph resumed the same ticket, but the user preference extracted last week was gone because nothing wrote AgentCore long-term strategies. Detection: operator asked “why is it using miles again”; Memory ListEvents / retrieve showed empty long-term records for that actor_id. Fix: AgentCoreMemorySaver and a Store/strategy configuration; namespace by actor; do not dump the CRM into checkpoint state.

Reference architecture

Open the draw.io diagram.

Business application
    → API / Event (API Gateway, EventBridge)
        → AgentCore Identity (inbound JWT)
            → LangGraph on AgentCore Runtime
                 ├─ State + conditional routing + loops
                 ├─ HITL interrupt / resume ⟲
                 ├─ AgentCore Memory (Saver + Store)
                 └─ AgentCore Gateway → Policy (Cedar)
                      → Enterprise APIs / databases (scoped)
            → Amazon Bedrock (Converse, Guardrails, Knowledge Bases)
            → Observability (OTEL → CloudWatch) + Evaluations

The dashed HITL loop is the point of using a graph: high-impact nodes do not auto-complete.

Production considerations

Security and identity. IAM on Bedrock invoke and AgentCore APIs. VPC for private tools. Identity for user tokens and outbound OAuth. Confused-deputy conditions on resource policies.

Tool permissions. Least privilege per tool. Prompt text is not an ACL. Gateway Policy is.

State management. Keep State small and typed. Large retrieved corpora belong in a store with pointers in State, not a 200k-token checkpoint.

Error handling. Retry only throttling / 5xx. Validation and AccessDenied fail closed. Terminal fail node with an operator-visible reason.

Observability and evaluation. Dashboards on latency, tool error rate, HITL queue time, and token cost per completed ticket. Eval the graph on golden tickets before canary.

Scaling. Runtime scales sessions; you still pay active compute. Cap loops. Default Browser and Code Interpreter off — we have already seen ~3× Runtime-shaped spend when Browser stayed hot on conversational turns (Harness/Strands post).

Human approval. Interrupt before writes that move money, change IAM, or touch production. Resume with an audit actor id.

For Classic-era orchestration language that still helps conceptually, see agentic workflows on Bedrock — implementation path is AgentCore, not Classic.

When LangGraph is a good choice

• You can draw the workflow as a graph and a reviewer can audit the edges.
• You need cycles with a cap (retrieve-until-sufficient, repair-until-tests-pass).
• You need HITL as a first-class node, not a Slack message the graph forgets.
• You already run LangGraph and will not rewrite to Strands this quarter — host it on Runtime, rewire tools to Gateway.
• Multi-agent routing must be an explicit DAG for compliance (not a Swarm with unbounded handoffs).

When a simpler architecture is better

• One Converse call. Classification, rewrite, extract-to-JSON. No graph.
• Deterministic pipeline. Step Functions, Bedrock Flows, or a job queue. Models as tasks, not as the router. See Bedrock Flows and Step Functions patterns.
• First production agent, ≤ ~10 tools, one team. AgentCore Harness.
• Employee knowledge work with connectors and seats. AgentCore vs Quick Suite — do not build LangGraph to replace Quick.

Avoid framework evangelism. A smaller control plane that pages less is the win.

Key architecture principles

1. Model agents as explicit workflows. If you cannot draw the edges, you cannot review them.
2. Keep critical business processes deterministic where possible. Use the model on the ambiguous nodes, not on the refund ledger.
3. Separate agent logic from infrastructure. LangGraph is not IAM, Memory, or Gateway.
4. Limit agent tool permissions. Gateway Policy + IAM; never a warehouse connection in the prompt.
5. Make state explicit. Workflow state ≠ LLM context ≠ AgentCore Memory.
6. Design for failure and recovery. Caps, terminals, checkpoints, idempotent tools.
7. Add human approval to high-impact actions. Interrupt/resume, audited.

What to Do This Week

1. Decide in one sentence: Harness, Runtime + Strands, or Runtime + LangGraph — and why.
2. If LangGraph: define State fields for one real ticket type; add a HITL edge on writes.
3. Wire Bedrock Converse with explicit max tokens and a pinned inference profile.
4. Put one read tool on Gateway; Policy LOG_ONLY if any write exists.
5. Attach Memory with actor_id / thread_id; do not skip Store if you need cross-session facts.
6. Run the pricing calculator at your sessions × duration. Walk the monday-checklist.md.

What This Post Doesn’t Cover

• Strands Graph/Swarm/Agents-as-Tools in depth — Harness + Strands 1.0.
• AgentCore unit prices beyond the calculator-as-of dates — 12-components.
• LangChain create_agent composition — LangChain on AWS.
• HIPAA control mapping for agents — HIPAA Bedrock; Gateway Policy is not a BAA.
• Region-by-region Runtime SKUs — AgentCore regions.

We have not re-benchmarked LangGraph node latency versus Harness on the same CRM tool set for this publish date. Reuse the Gateway ~180→95 ms canary for tool I/O; measure graph overhead in your account before you put p95 in an SLA.

Need a Runtime vs Harness design review for an existing LangGraph prototype? Start with Generative AI on AWS or contact us — AWS Select Tier Partner.