--- title: LangChain and LangGraph on AWS description: Run LangChain and LangGraph on Amazon Bedrock and AgentCore — where the framework earns its keep, where a plain control loop wins, and how to keep agent code debuggable at 3am. url: https://www.factualminds.com/integrations/langchain-aws/ category: ai updated: 2026-08-30 --- # LangChain and LangGraph on AWS > AgentCore is bring-your-own-framework, so LangGraph runs on it unchanged. The question worth asking is not whether you can, but whether the orchestration you have actually needs a graph. ## AgentCore does not care which framework you use Amazon Bedrock AgentCore is bring-your-own-framework. LangGraph, Strands, CrewAI, or three sequential prompts with an explicit control loop all run on the same substrate — session-isolated runtime, gateway for tools, memory with access control, identity propagation, observability and evaluations. That removes the infrastructure question from the framework decision entirely, which is useful, because it leaves the question that actually matters. ## The question that matters: does your workflow need a graph? LangGraph models an agent as a state graph with nodes and edges. That is genuinely valuable when the workflow is **cyclic and stateful** — the agent loops, revisits earlier steps, and branches on accumulated context. A large share of production agents are not that. They are: retrieve, decide, act, check. Three model calls and a control loop, written explicitly, that any engineer can read top to bottom. The commonly cited practitioner argument here is worth taking seriously — that it is often easier to write the thing as sequential prompts with an explicit control loop, because it is easier to debug, monitor and control the output flow. We agree often enough that our default is the least abstraction that solves the problem. **The selection criterion we actually use:** can the on-call engineer, who did not build this, read the control flow at 3am and work out which tool it called and why? If the framework helps with that, take it. If it obscures it, the framework is a cost. ## Where the tool boundary belongs This is the most consequential design point on the page, and the one most often got wrong. Frameworks let you define tools as decorators. That is convenient and it produces a **convention** — it constrains the well-behaved case and nothing else. Under adversarial input, a prompt-injected instruction can persuade a model to attempt an action a decorator does not stop. Route tools through **AgentCore Gateway** instead. The catalog becomes an enforced boundary: authentication, customer-configurable rate limits, and Cedar authorization evaluating every write **outside the model**. A model can be argued out of a system prompt. It cannot be argued out of an authorization policy. The secondary benefit: the boundary survives a framework upgrade. Decorators do not. ## Two things no framework gives you **Evals.** A golden dataset with a pass bar enforced in the deployment pipeline. An agent without one is a system whose quality you are asserting rather than measuring. See [agent evals](/glossary/agent-evals/). **Cost ceilings.** Per-conversation token budgets and model routing by task, with CloudWatch alarms firing before the threshold rather than after the invoice. Framework abstraction tends to make token consumption *less* visible, not more, which is a reason to instrument it deliberately. ## Our recommendation Start without a framework. Add LangGraph when you hit a workflow that is genuinely graph-shaped and you can name why — not when the tutorial suggests it. **The trade-off we are accepting:** this is slower if your team already has real LangGraph depth, and existing expertise is a legitimate reason to override the default. What we will not trade away is the tool boundary — that belongs in Gateway regardless of what runs above it. ## Related reading [AI agent](/glossary/ai-agent/) · [Tool catalog](/glossary/tool-catalog/) · [Amazon Bedrock AgentCore](/glossary/bedrock-agentcore/) · [Agentic commerce on AWS pattern](/patterns/agentic-commerce-on-aws/) ## Run LangGraph on Bedrock AgentCore 1. **Choose the model access path first** — LangChain talks to Bedrock through its AWS integration package. Decide early whether you are calling the Converse API for cross-model portability or a model-specific path, because switching later touches every call site. Converse is the default for anything that might change models. 2. **Decide whether you need a graph at all** — LangGraph is worth it when the workflow is genuinely cyclic and stateful — an agent that loops, revisits earlier steps, or branches on accumulated state. Three sequential prompts with an explicit control loop is easier to debug, monitor and reason about, and it is what a large share of production agents actually are. 3. **Deploy onto AgentCore Runtime rather than raw Lambda** — AgentCore gives you session-isolated execution, so one runaway loop cannot degrade a neighbour, plus memory, identity propagation and observability as managed services. The framework runs inside it unchanged — you are choosing where it executes, not rewriting it. 4. **Put tools behind Gateway, not in the framework** — Resist defining tools purely as framework decorators. Route them through AgentCore Gateway so the tool catalog is an enforced boundary with authentication, rate limits and Cedar authorization on writes — enforcement the model cannot be prompted around, and which survives a framework upgrade. 5. **Wire evals and cost ceilings before launch** — Build a golden dataset with a pass bar enforced in the deployment pipeline, and set per-conversation token budgets with CloudWatch alarms that fire before the threshold. Neither of these is a framework feature, and neither is optional. ## FAQ ### Do we need LangChain if we are on Bedrock? Often not, and this is worth being blunt about. If your workload is retrieval plus a prompt, or a fixed sequence of three model calls, the framework adds an abstraction layer between you and a Bedrock API that is already reasonable to call directly. Where LangChain and especially LangGraph earn their keep is genuinely cyclic, stateful orchestration — an agent that loops, revisits earlier state, and branches on accumulated context. Choose against the workflow you actually have, not the one in the framework tutorial. ### LangGraph or Strands on AgentCore? Both run on AgentCore, so this is not an infrastructure decision. LangGraph brings an explicit graph model and a large ecosystem, which helps when your team already knows it or when the workflow is genuinely graph-shaped. Strands is AWS-native and tends to produce less abstraction between you and the model. Our default is the least abstraction that solves the problem, because whoever is on call is the one who has to read it. If the team has real LangGraph depth, that experience is a legitimate reason to pick it. ### What could go wrong with a framework-heavy agent stack? Debuggability at the worst moment. When an agent behaves oddly in production, you need to see which tool it called, with what arguments, and why — and heavy abstraction layers make that trace harder to follow, especially for whoever is on call rather than whoever built it. The second risk is upgrade churn: agent framework APIs move fast, and a major version bump is a real maintenance event you will own. Neither is a reason to avoid frameworks; both are reasons to keep the control flow explicit and readable. ### Should tools be defined in the framework or in AgentCore Gateway? Gateway, for anything that writes. A tool defined purely as a framework decorator is a convention — it constrains the well-behaved case and nothing else. Routing tools through Gateway makes the catalog an enforced boundary with authentication, rate limits and Cedar policy evaluated outside the model, which is what holds up under prompt injection. It also means the boundary survives a framework upgrade, which decorators do not. ### When should we not use a framework at all? When the workflow is three prompts and a control loop, which is more production agents than the ecosystem admits. Explicit sequential calls with your own loop are easier to debug, easier to monitor, and easier for a new engineer to read. The honest test: if you cannot articulate what the framework is doing for you beyond structuring code you could have structured yourself, you are carrying an upgrade obligation for no return. --- *Source: https://www.factualminds.com/integrations/langchain-aws/*