LangGraph builds the agent. AgentCore runs it.

The question I keep getting from engineering teams is some version of “should we build on LangGraph or on Bedrock AgentCore?” It is the wrong question, and answering it as a versus almost always sends people down the wrong path. They are not competitors. They sit at different layers of the stack, and the clearest way to see that is to take the things you actually design when you build an agent and ask, for each one, which tool owns it.

The six things you design in an agent

When you author a real agent, not a demo, you are designing six things:

• State: the typed object that carries everything the agent knows this turn, and the rules for what accumulates versus what gets overwritten.
• Nodes: the discrete steps. Classify intent, plan, generate a query, validate it, run it, retrieve documents, check grounding, synthesise, format the answer.
• Edges: how those steps are wired together.
• Routing: the conditional logic that decides which edge to take, ideally deterministic code reading the state, not the model choosing freely.
• Loops: the reason-act-observe cycle, and the bounds that force it to terminate instead of spinning.
• Checkpoints: persisting the graph’s state so a run can survive a crash, pause for a human, or be replayed for audit.

If you have written anything non-trivial in LangGraph, you have hand-built all six. That is what LangGraph is: a framework for authoring the control flow of an agent as an explicit graph. It gives you StateGraph, reducers, conditional edges, a recursion_limit (25 steps by default before it raises GraphRecursionError), and a checkpointer. It is opinionated about how the agent thinks.

What AgentCore actually is

AgentCore is not that. It is a modular set of managed services for running and operating agents in production: Runtime, Memory, Gateway, Identity, Observability, plus built-in Code Interpreter and Browser tools, all generally available since 13 October 2025. Two more pieces arrived later and on their own schedule. Policy and Evaluations launched in preview on 2 December 2025 and reached GA separately, Policy on 3 March 2026 and Evaluations on 31 March 2026. A tenth piece, a managed agent loop called Harness, came later again: public preview in April 2026, general availability in June 2026. So by this post’s publish date, Policy has had about seven months of production hardening, not the year a single “went GA in late 2025” claim would imply, and Harness about four. The two design facts that matter most:

1. It is framework-agnostic and model-agnostic. It runs agents built in LangGraph, CrewAI, LlamaIndex, Strands, the OpenAI Agents SDK and others, against models inside or outside Bedrock (Claude, Nova, GPT, Gemini, Llama, Mistral). The Runtime service contract speaks HTTP, MCP, A2A and AGUI.
2. AWS’s own framing: the framework owns the orchestration logic, AgentCore owns the runtime infrastructure it runs on. AgentCore does not ask you to redraw your graph. It asks you to deploy it.

So the honest mental model is not “LangGraph or AgentCore.” It is “author in LangGraph, operate on AgentCore,” and the interesting engineering is in the seam between them.

Mapping the six primitives

What you design	Who owns it	What the other layer adds
State (schema, reducers)	LangGraph	AgentCore Memory adds managed short-term and long-term memory that persists across sessions and can be shared across agents (scoped per actor/namespace, your responsibility to configure correctly). It does not define your state schema.
Nodes and edges	LangGraph	AgentCore has no concept of your nodes. The exception is Harness, below.
Routing	LangGraph	AgentCore Policy intercepts every tool call at the Gateway boundary and allows or denies it against Cedar policies, outside your agent’s code. Governance, not routing.
Loops	LangGraph (recursion_limit, token budgets)	AgentCore Runtime gives the loop a durable place to run, up to eight hours per session on the standard microVM path (the maxLifetime default and ceiling there; a capacity-provider deployment can raise it further), with true session isolation.
Checkpoints	LangGraph checkpointer	AgentCore Runtime and Memory change the durability problem entirely. This is the one worth sitting on.
Tools	Either	AgentCore Gateway turns your APIs and Lambda functions into MCP-compatible tools with a few lines, so tools become reusable across agents instead of hard-wired into one.

The checkpoint story is where it gets interesting

Here is the part I did not appreciate until I built an agent on Lambda.

Lambda gives you fifteen minutes and no memory between invocations. A multi-step agent that calls a model, waits, calls a tool, waits, reasons again, can bump into that ceiling, and if the function dies mid-run you have lost every tool call it already made. So on Lambda you need a checkpointer. You persist the graph state at every step, and on the next invocation you resume from the last checkpoint instead of re-running everything. The checkpointer is not a nice-to-have there. It is how you survive a stateless, time-boxed compute model.

One thing the checkpointer does not buy you: a resumed run can replay a tool call whose side effect already landed, because durable state and exactly-once side effects are different guarantees. If a node charges a card or sends an email, resuming from the last checkpoint after a crash can fire it twice. That needs its own idempotency key, keyed off the checkpoint step id, independent of whichever compute layer you are on.

AgentCore Runtime changes the shape of that problem. Sessions are isolated microVMs and can run for up to eight hours on the standard deployment path, with streaming. The runtime holds the session, so you are no longer checkpointing to work around a fifteen-minute wall. Checkpointing becomes what it should have been all along: resilience against genuine failures, a pause point for human-in-the-loop approval, and a replayable trace for audit. Same primitive, completely different reason for reaching for it.

That is the practical lesson. The compute layer you deploy onto quietly dictates how hard your framework’s persistence layer has to work. Pick the runtime first, and half your checkpointer decisions make themselves.

The one place AgentCore does orchestrate: Harness

There is a real exception to “the framework owns the loop.” AgentCore Harness is a managed agent loop, powered by Strands Agents under the hood. You define an agent with CreateHarness and run it with InvokeHarness: a model, a system prompt, tools, memory settings and execution limits as configuration, no orchestration code to write. For a lot of agents, a support assistant, a research task, a data-analysis helper, that is genuinely all you need, and reaching for LangGraph would be over-engineering.

The line I draw: if your control flow is “reason, pick a tool, repeat until done,” Harness is enough. The moment you need explicit routing, bounded repair loops, a grounding gate that can send the agent back to retrieve again, or a human approval step wired into a specific edge, you want a real graph, and that is LangGraph deployed onto Runtime.

How I would choose

• Prototyping a straightforward agent, or you do not want to own orchestration code: Harness on AgentCore.
• Non-trivial control flow, deterministic routing, bounded loops, auditability: author the graph in LangGraph.
• Either way, when it goes to production: deploy onto AgentCore Runtime and adopt Memory, Gateway, Identity, Observability and Policy rather than hand-rolling session isolation, tool plumbing, auth and tracing yourself.
• Non-negotiables like “the agent must never make an authorization decision” or “this tool call needs approval” belong in Policy at the Gateway, outside the model, no matter which framework drew the graph.

The versus framing costs teams weeks, because they treat a runtime decision and an authoring decision as one choice and then relitigate it. Separate the two. LangGraph is how the agent thinks. AgentCore is where it lives. Design each on its own terms and the seam between them is where the good architecture actually is.

One honest limit on this mapping: it is a snapshot of where the line sits today, not a law. Policy, Evaluations and Harness all reached GA well after the rest of AgentCore (March and June 2026 against October 2025), which means the “who owns it” column has already moved at least twice since the services this post describes first shipped, and AWS ships new AgentCore capability on a near-monthly cadence. If you are reading this more than a few months after publication, check the current docs before you redraw this table from memory, the same rule this post applies to itself.

---

Sources: Amazon Bedrock AgentCore developer guide (Runtime lifecycle settings, Policy, Harness), AgentCore FAQs, the AWS “AgentCore is now generally available” announcement (13 October 2025), the AWS News Blog post “Amazon Bedrock AgentCore adds quality evaluations and policy controls for deploying trusted AI agents” (Policy and Evaluations GA, March 2026), and the AWS “AgentCore Harness is now generally available” announcement (June 2026).