The Preview Frontier

Almost every July–October 2025 blog you will read describes AgentCore as "seven services": Runtime, Memory, Gateway, Identity, Browser, Code Interpreter, Observability. All seven reached GA (the platform went GA on October 13 2025 — [VOLATILE], confirm on AWS What's New). That list is no longer complete.

Since GA, AWS has been steadily adding modules to the live "Core services" table on the overview page. As of writing, the newer entries are:

The reason this lesson exists is twofold. First, completeness: a course that stops at seven services is already out of date. Second — and more important — discipline. These modules are at different maturity levels, and several are pure preview. The single source of truth is the live docs table, not this lesson and not any blog. Bookmark it.

Runtime hosts an agent you wrote and packaged. Harness inverts that: you describe the agent declaratively and let AWS run the loop. In a single API call you specify the model, the system prompt, and the tools inline — Harness then handles orchestration, tool execution, memory, and response generation for you. There is no container to build and no entrypoint to wire.

Think of it as the fastest path from idea to a working agent: the model-as-config idea pushed all the way to its limit. Conceptually the request looks like this:

# Conceptual shape — define model + system prompt + tools inline,
# Harness runs the agent loop. Verify exact API/params on the live docs.
response = client.invoke_harness(
    model="<a supported Bedrock model id>",   # [VOLATILE] — verify live
    system_prompt="You are a research assistant. Cite every source.",
    tools=[
        {"name": "search_web", "description": "...", "input_schema": {...}},
        {"name": "read_url",   "description": "...", "input_schema": {...}},
    ],
    input="Summarize the latest AgentCore pricing changes.",
)

Crucially, Harness keeps AgentCore's headline isolation guarantee: each session runs in its own isolated microVM with filesystem and shell access, the same security boundary you get in Runtime. So an agent can write a file, run a shell command, and reason over the result — all inside an ephemeral sandbox that is torn down when the session ends.

The trade-off versus Runtime is the usual managed-vs-modular one: Harness gives you speed and zero plumbing, but you give up the control of bringing your own framework and container. The CLI config-based harness path is labeled preview as of writing.

LLM guardrails are probabilistic — they reduce bad outputs but cannot guarantee them. AgentCore Policy adds a deterministic control plane on top. You author fine-grained rules — in natural language or in Cedar, AWS's open-source policy language — and Policy integrates with Gateway to intercept every tool call before it executes. A non-deterministic agent proposes an action; a deterministic policy decides whether it is allowed.

This is the same interception model you already know from Gateway: tools are namespaced per target with the triple-underscore prefix (${target_name}___${tool_name}), and the policy engine sits in front of that call. A Cedar rule reads like access-control logic:

// Conceptual Cedar rule — verify exact entity/schema shape on the live docs.
// Permit reads, but forbid any refund tool above a threshold.
permit (
  principal,
  action == Action::"InvokeTool",
  resource
) when {
  resource.tool like "orders___get_*"
};

forbid (
  principal,
  action == Action::"InvokeTool",
  resource
) when {
  resource.tool == "payments___issue_refund" &&
  context.amount > 100
};

Because the rule is deterministic and evaluated before execution, you can prove an agent can never call payments___issue_refund for more than $100 — something no system prompt or LLM guardrail can promise.

Status is volatile. Policy now appears in the first-party Core services table on the overview page (verified June 2026), but its exact GA-vs-preview status and GA date are still [VOLATILE] — confirm on the live overview/pricing pages and AWS What's New before relying on it in production. Pricing is billed per authorization request (plus a per-token charge for natural-language authoring) — [VOLATILE], verify the live pricing page.

Observability tells you what happened — latency, cost, the trace of tool calls, where it failed. It does not tell you whether the answer was any good. AgentCore Evaluations is the purpose-built service that closes that gap: automated, consistent, data-driven assessment of task execution, edge-case handling, and output reliability.

The key architectural fact: Evaluations rides the same OTEL traces as Observability. Both read OpenTelemetry traces with GenAI semantic conventions (emitted by frameworks like Strands and LangGraph). That means online evaluation can sample a configurable percentage of production traces and score them directly in the Observability dashboard — no code changes to your agent.

It ships with 13 built-in evaluators plus trajectory matchers and custom evaluators:

Session-level:  Goal Success Rate
Trace-level:    Helpfulness, Correctness, Coherence, Conciseness,
                Faithfulness, Harmfulness, Instruction Following,
                Response Relevance, Context Relevance, Refusal, Stereotyping
Tool-level:     Tool Selection Accuracy, Tool Parameter Accuracy
Trajectory:     Exact Order / In-Order / Any Order Match   (+ custom)

The clean mental split to carry away:

Observability = what happened / how fast / what cost / where it failed. Evaluation = was it correct / helpful / safe.

Evaluations launched in public preview at re:Invent 2025 and reached GA on March 31 2026 — online + on-demand evaluation, 13 built-in evaluators, custom evaluators, Observability integration, and nine launch regions ([VOLATILE], confirm on AWS What's New). Built-in evaluators are billed per input/output token; custom evaluators per 1k evals (verify the live pricing page).

The last cluster of newer modules addresses what happens once an org has many agents and tools.

AgentCore Registry is a centralized catalog for discovering and governing agents, MCP servers, tools, skills, and custom resources across an organization. It adds a governed publish → review → approve workflow and hybrid semantic + keyword search, so a builder can find an approved, vetted tool instead of re-implementing it — and a platform team can gate what gets published. It pairs naturally with Gateway: Gateway is the runtime tool surface, Registry is the catalog and governance layer in front of it. Registry is listed as preview, with a free allotment of records before per-record pricing kicks in ([VOLATILE]).

AgentCore Payments lets agents make microtransaction payments to access paid APIs, MCP servers, and content, using the x402 protocol (HTTP 402 "Payment Required", repurposed for agent-to-service payments). You get wallet integration, configurable spending limits, and observability over what the agent spent. Wallet providers supported as of writing: Coinbase CDP and Stripe (via Privy).

# Conceptual shape — spending limits are the safety primitive for autonomous spend.
# Verify exact API/params and wallet setup on the live docs.
wallet = payments.create_wallet(
    provider="coinbase_cdp",          # or "stripe_privy"
    spending_limit={"amount": 50, "period": "day"},
)
# Agent hits a paid endpoint; x402 negotiates payment within the limit.

Payments incurs no AWS charge — it is pass-through to the wallet provider's rates. It is preview. The discipline note bears repeating here especially: do not put an autonomous agent in front of a real wallet on a preview service without a hard, audited spending limit and a fresh status check.

AgentCore Optimization rounds out the list: it provides recommendations for tuning agents plus A/B tests to validate changes against real behavior. As of writing, the recommendations are free during public preview; full GA pricing is TBA. Treat it as a feedback loop on top of Evaluations and Observability — measure, get a recommendation, A/B test it, keep what wins.

That brings us to the real lesson, which is not any one module but a discipline for all of them:

1. Teach (and build for) the concept, not the version. Harness is a managed loop; Policy is deterministic interception; Evaluations is trace-based scoring. Those concepts are stable. The status, pricing, and exact API are not.
2. Link the live status page, every time. The canonical truth is the "Core services" table on what-is-bedrock-agentcore.html and the pricing page — not this lesson, not a blog, not your memory.
3. Frame every volatile fact as "as of writing — verify the live page." Preview-vs-GA status, pricing numbers, GA dates, region lists, and SDK versions all move. Never assert them as timeless facts.
4. Hedge or omit the unverified. A module can appear in the live "Core services" table before a What's New post pins down its exact status, pricing, and regions — flag those as volatile, don't bank on them.
5. Never ship a preview feature as production-ready. Preview means: API can change, no SLA, may not be in your region, pricing may shift. Prototype on it freely; gate it behind a status check before it touches production traffic.

Production-ready today (GA):  Runtime · Memory · Gateway · Identity ·
                              Browser · Code Interpreter · Observability ·
                              Evaluations (GA Mar 31 2026)
Moving target (verify live):  Harness · Policy · Registry ·
                              Payments · Optimization

The builders who get burned are the ones who read one blog, memorized "seven services," and never went back to the live page. Don't be that builder.