The AgentCore Service Catalog

The first lesson framed AgentCore as managed, serverless production primitives. This lesson hands you the full map of what's in the box so nothing surprises you later in the course.

The critical mental model: AgentCore is modular. The AWS overview describes the services as working "together or independently." You do not adopt the whole platform to get value. You can use only Gateway (to expose your APIs as MCP tools), only Code Interpreter (a managed sandbox), or only Memory (a managed store) — while your agent runs on EKS, ECS, or Lambda. Each service has its own SDK/API surface and is independently billable.

That modularity is why "the service catalog" is the right framing. Treat each entry as a building block with its own purpose, its own pricing dimension, and its own GA/preview status — not as a feature of one big product.

There is a naming trap to clear first. "Amazon Bedrock AgentCore" (modular, code-first infrastructure) is a distinct product from the older "Amazon Bedrock Agents" (the fully managed, configuration-first agent product). The next lesson disambiguates them in depth — for now, just know the catalog below belongs to AgentCore, and despite the "Bedrock" in the name it is explicitly not limited to Bedrock models.

These seven were announced together at preview (AWS Summit NY, July 16 2025) and all reached general availability. They are the backbone of the rest of this course — a full module is devoted to several of them.

A useful way to bucket them: Runtime is the hosting primitive; Memory and Identity are stateful services your agent leans on; Gateway, Browser, and Code Interpreter are the ways your agent reaches the outside world (tools, the web, code execution); Observability is how you see what happened.

All seven definitions trace to the one page you should bookmark: the live what-is-bedrock-agentcore.html overview.

Here is the part that trips people up. The catalog keeps growing. If you only read the July–October 2025 blogs, you will miss everything below. These modules were added after the original seven, and their availability is the most volatile thing in this lesson.

The honest summary of status as of writing — and exactly the kind of fact that drifts:

• Original 7 — GA (Oct 13 2025).
• Harness, Registry, Payments, Optimization — preview.
• Evaluations — GA (March 31 2026).
• Policy — now listed in the first-party Core services table; GA-vs-preview status volatile, confirm on the live page.

Do not teach (or build a production dependency on) the preview modules as if they were production-ready without a live status check.

Because the services work together or independently, there are three recognizable adoption patterns. They are not mutually exclusive — they're points on a spectrum from "adopt everything" to "adopt one thing."

1. All-in (the paved path). You scaffold with the AgentCore CLI and let the services interlock: Runtime hosts the agent, Memory persists context, Gateway exposes tools, Identity authorizes inbound and outbound calls, Observability monitors, and Policy governs every tool call. This is the end-to-end production agent the capstone builds toward.

2. A la carte. You run your agent on EKS / Lambda / ECS and adopt only the AgentCore pieces you need — only Gateway, or only Code Interpreter, or only Browser, or only Memory. Each is consumable on its own because each has its own SDK/API surface.

3. Tool provider. You combine Gateway + Registry to publish governed MCP tools that other teams' agents discover and consume — an internal tool marketplace.

Conceptually, an end-to-end agent layers like this:

        Caller (user / app)
              │  inbound auth (Identity)
              ▼
   ┌─────────────────────────┐
   │  AgentCore Runtime       │  ← hosts your container (any framework)
   │   • your agent code      │
   └───────┬──────────┬───────┘
           │          │  outbound auth (Identity token vault)
     reads/writes     ▼
      Memory     AgentCore Gateway ── MCP tools ──▶ your APIs / Lambdas
                      │
                Policy (Cedar) intercepts each tool call
           Browser / Code Interpreter = built-in tools
                      │
              Observability (CloudWatch + OTEL) sees it all

The key takeaway: there is no "AgentCore monolith" you turn on. You pick the blocks, and the SDK/CLI wire them together when you want the paved path.

This is the most important habit this lesson teaches, and it's worth stating bluntly.

The canonical "7 services" list you'll see in most July–October 2025 blogs is no longer the full list. Harness, Policy, Evaluations, Registry, Payments, and Optimization were added afterward, and their statuses keep moving.

So whenever you read a "here are the AgentCore services" list — in a blog, a conference recap, a Stack Overflow answer, or even this course — reconcile it against the live source:

• The live "What is AgentCore" overview page is the authoritative service list. Its "Core services" table keeps growing.
• The pricing page is a second cross-check: a service that's independently billable shows up there with its dimension (and preview modules are often flagged free or pass-through).

Why this matters beyond pedantry: building on a preview module means accepting that its API, pricing, and even existence can change before GA. Mistaking a preview module for GA is a production risk, not a trivia error. The discipline is simple — concept from the course, status from the live page, every time.

When you see a "7 AgentCore services" claim, ask:
  1. Is this from mid-2025? → it's almost certainly stale.
  2. Open what-is-bedrock-agentcore.html → count the live "Core services" table.
  3. For any module you'll depend on → confirm preview vs GA before you build.