LangChain and LangGraph on AWS

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.

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 · Tool catalog · Amazon Bedrock AgentCore · Agentic commerce on AWS pattern