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:
- 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.
- 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.
One honest gap in that framing: AgentCore is not the only place a LangGraph graph can run. LangGraph ships its own managed runtime, the product most people still know as LangGraph Platform or LangGraph Cloud, now folded into what LangChain's current docs call LangSmith Deployment. Its fully managed Cloud tier runs your agent inside LangChain's own AWS and GCP infrastructure, not your AWS account. Its self-hosted and hybrid tiers run your own Kubernetes cluster, which trades a managed service for a cluster you now operate. AgentCore Runtime is neither of those: the agent runs inside your own AWS account on a managed microVM, under the IAM you already administer, and AgentCore Observability ships built-in CloudWatch metrics and a per-agent log group out of the box, not a separate vendor dashboard you also have to maintain. If you are already on AWS and the thing you actually want is for the infrastructure boundary to stay your account rather than a vendor's, that is the concrete reason to deploy LangGraph onto AgentCore Runtime instead of onto LangGraph's own platform, not just "because AWS."
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.
Checkpointing is not idempotency
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.
One sharp edge worth knowing before you lean on that eight-hour number: it covers active execution, not idle waiting. A session only stays alive while your code reports itself busy on its own /ping health check; left idle, with no pending work, it is auto-terminated after fifteen minutes regardless of the eight-hour ceiling. So the eight hours does not buy you a longer wait for a human. A human-in-the-loop pause that outlasts fifteen minutes is not "the session waits." It is "checkpoint, let the session end, and resume a new one from that checkpoint once the human responds," the same discipline you would need on Lambda, not a reason to skip it because the runtime feels long-lived. What the eight hours actually buys you is sustained active work Lambda cannot: Lambda's own fifteen-minute ceiling is a hard execution limit that fires even while the function is genuinely busy, so a long document-parsing pass or a multi-tool research loop that runs continuously for forty-five minutes has nowhere to go on Lambda without being chopped into checkpointed segments. On AgentCore Runtime, as long as the agent keeps reporting HealthyBusy, that same continuous run just keeps going.
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, the /ping idle-session timeout, Policy, Harness, Observability/CloudWatch integration), 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), the AWS "AgentCore Harness is now generally available" announcement (June 2026), and LangChain's LangSmith Deployment documentation (deployment options and tiers).
Top comments (0)