AgentCore course → Lesson 1

Lesson 1· ~10 min· Reading + retrieval practice

Translating what you already know

You know agentic systems. So don't learn it from scratch. Work out which of the things you currently hand-build it takes off you, and which stay yours.

Start from what you have

You've built or reviewed agents with LangGraph, CrewAI, and MCP tooling. You know what an agent loop is, what a tool call costs you in reliability, and how quickly state management becomes the hard part. Hold all of that. This lesson only adds a map.

The reframe that decides every later conversation

The most common mistake in an AgentCore conversation, made by customers and SAs alike, is treating it as a competitor to the framework the customer already uses. It isn't. AgentCore is deliberately framework-neutral: AWS documents support for CrewAI, LangGraph, LlamaIndex, Google ADK, the OpenAI Agents SDK, Strands, and custom frameworks, with any model in or outside Bedrock, and with MCP and A2A as first-class protocols.Framework, model, and protocol support per the AgentCore Developer Guide overview. Retrieved 2026-08-05.

That neutrality is a deliberate bet: that the durable, hard, undifferentiated work in agentic systems isn't the reasoning loop but everything around it. So the question to put to a founder is never "AgentCore or LangGraph." It is:

The one idea

AgentCore is the operational substrate beneath your agent framework, not a replacement beside it. The real question is which parts of your current plumbing you are willing to stop building yourself.

A three-layer diagram. At the top, your agent logic written in LangGraph, CrewAI, Strands or Google ADK with any model. Below it, two alternative compute choices: Runtime where you own the loop, or harness where AWS owns the loop. Both converge on the same platform beneath, which supplies Gateway for tools, Identity for credentials, Memory for state, and Observability for traces.
Figure 1. The substrate model, and the shape to draw first on any whiteboard. Your agent logic stays yours. Beneath it you make exactly one compute choice: deploy your own loop on Runtime, or declare an agent in configuration and let harness run the loop. Either choice lands on the same platform, which supplies tools, credentials, state, and traces. The fork is the only decision at this layer; everything below it is identical.

Open full-size diagram

What you stop building

This table is the lesson. Read it as a list of things a startup engineering team currently maintains, and what AgentCore offers in place of each.

Mapping your current plumbing onto AgentCore
What you hand-build today AgentCore capability What actually changes
Checkpointer or state store for conversation history Memory Short-term for multi-turn, long-term persisting across sessions, and stores shareable between agents
Tool registry, API wrappers, hand-rolled MCP shims Gateway APIs, Lambda functions, and existing MCP servers become governed MCP tools; large catalogs get semantic search
Secrets handling and per-user token exchange Identity Works with your existing IdP (Cognito, Okta, Entra ID, Auth0) with no user migration
Sandboxed code execution for the agent's own output Code Interpreter Isolated sandbox; Python, JavaScript, TypeScript
A headless browser fleet you keep patched Browser Managed cloud browser runtime; works with Playwright and Browser Use
Span instrumentation and trace export Observability OpenTelemetry-native, so it lands in whatever stack the customer already has
Container platform, autoscaling, session isolation Runtime Serverless, with genuine per-session isolation and built-in identity
The agent loop itself harness GA Optional. Declare model, tools, skills, and instructions in configuration and AWS assembles the loop

Every one of these is independently adoptable. AWS's own framing is that the capabilities "work together or independently."Modularity and per-capability independence, AgentCore FAQs. Retrieved 2026-08-05. That matters commercially more than it sounds: a startup can take Gateway alone and keep everything else, which makes the first conversation much easier than an all-or-nothing platform pitch.

What stays yours

Worth being just as clear about, because it is what reassures a technical founder: your agent logic and graph structure, your prompts, your model choice, your business rules, and your evaluation criteria. AgentCore does not ask for any of them.

The one fork that matters: Runtime or harness

If you remember one distinction from this lesson, make it this one. It is the thing customers get wrong most often, and the two names do not help.

Runtime: you own the loop

You wrote the agent. Maybe it is a LangGraph graph or a CrewAI crew. Runtime is serverless compute purpose-built to host it: fast cold starts, per-session isolation, long-running async support, MCP and A2A.

Reach for it when the customer already has working agent code, or needs orchestration you cannot express in configuration.

harness: AWS owns the loop

You did not write an agent loop at all. You declared one: model, tools, skills, instructions. AWS assembles and runs it. Each session gets its own isolated environment with a filesystem and shell.

Reach for it when the customer is starting fresh, or prototyping, and does not want to own orchestration code.

AWS's own metaphor for the harness is worth borrowing verbatim in a meeting, because it lands quickly: if the model is the brain, the harness is the body. It runs the orchestration loop, executes tools, manages the context window, persists state across turns, recovers from failures, and isolates each session.The brain-and-body framing, and the export-to-code path, from AgentCore harness is now generally available, 17 June 2026. Retrieved 2026-08-05.

Two properties of harness are worth knowing now, because they pre-empt objections you will hear in Lesson 6. It's decoupled from the model, so you can switch model providers mid-session without losing context, for instance planning with one model and writing code with another. And it's not a one-way door: a single CLI command exports the harness orchestration to Strands-based code, running on the same compute and the same primitives, with the Claude Agent SDK named as a future export target.

Say this to a customer

"You don't have to choose between LangGraph and AgentCore. AgentCore runs underneath it. Start with whichever single piece hurts most today. If that's tool access and credentials, start with Gateway and Identity and change nothing else."

Don't overclaim

AWS describes Runtime as having "fast cold starts" but publishes no latency figure, and documents "extended runtime support for asynchronous agents" without stating a ceiling. If a founder asks for numbers, say they aren't published and offer to get them. Don't estimate. Guessing here is how you lose a room of engineers.

Read this next: 10 minutes, highest value

AgentCore Developer Guide: Overview

The single canonical page: every capability with a one-paragraph description and, crucially, the framework and model integrations for each. If you read one AWS page before your next customer meeting, read this one. Skim the capability table and note which names surprise you. Retrieved 2026-08-05.

Retrieval practice

Answer from memory, without scrolling back. Getting one wrong here is more useful than getting it right by looking.

  1. A LangGraph app keeps conversation state in a checkpointer backed by Postgres. Which AgentCore capability replaces it?

    • Gateway, which brokers every outbound tool call
    • Memory, which holds short and long-term state
    • Runtime, which isolates each user session fully

    Answer: B (Memory).

  2. A team has a working CrewAI crew and wants it deployed without rewriting it. Which is the fit?

    • harness, declaring the crew in configuration instead
    • Runtime, deploying the crew code as it stands
    • Gateway, exposing the crew as an MCP tool

    Answer: B (Runtime).

  3. A founder says "we already use LangGraph, so AgentCore isn't for us." What is the accurate reply?

    • AgentCore replaces LangGraph once you reach real scale
    • AgentCore runs beneath LangGraph and keeps it in place
    • AgentCore requires migrating LangGraph graphs to Strands

    Answer: B. It runs beneath, and keeps LangGraph in place.

Where to go next

Lesson 2 takes the fork in Figure 1 seriously: how to choose between Runtime, harness, Lambda, and ECS or EKS, what session isolation actually buys, and what runs in ca-central-1. That last part matters most for your customers specifically.

Two reference cards support this lesson: the terminology card, for AgentCore's genuinely confusable names, and later the service map, for maturity and region footprint at a glance.

Questions to take forward