Amazon Bedrock AgentCore: The Production Guide for Net-New AI Agents on AWS

AWS lifecycle notice (June 30, 2026) — Amazon Bedrock Agents Classic is now Bedrock Agents Classic, in maintenance for new customers after July 30, 2026. Net-new agent builds should use Bedrock AgentCore. Full matrix: lifecycle roundup.

On June 17, 2026, AgentCore Harness reached general availability — a managed, config-driven agent loop on the same platform as Runtime, Memory, Gateway, and Identity (What’s New). Combined with the June 30 lifecycle batch that puts Agents Classic into maintenance for new customers after July 30, 2026, the default path for net-new production agents on AWS is no longer Classic action groups.

This guide is the architecture map for that path: what AgentCore is in mid-2026, when to pick Harness vs Runtime, how Memory / Gateway / Identity fit together, and what a honest Classic cutover looks like. Deep dives on pricing components, Gateway server-side tools, and AgentCore vs Quick Suite TCO stay in their own posts — link out, do not duplicate.

First-party signals we reuse here — Gateway canary on a B2B CRM assistant (12 tools, ~8k turns/day): median tool round-trip ~180 ms → ~95 ms after server-side Gateway (Gateway post). First-party TCO silhouette (July 2026): ~500-employee Quick Suite stack ~$3,580/mo vs AgentCore support-style agent at 50K sessions/mo ~$791/mo platform + Haiku-like inference (decision guide).

Reproduce this — Model platform spend on the AgentCore pricing calculator (list rates as of 2026-07-04, us-east-1). For Gateway cutover shape, use the public artifacts: server-side vs client matrix and Responses Gateway sketch.

What AgentCore Is Now (Not a Classic Wrapper)

Amazon Bedrock AgentCore is a modular agent platform: build, deploy, and operate agents with any supported framework and foundation model, with managed isolation, memory, tools, identity, and observability (AWS overview).

Mentioned, not covered deep here: Payments (x402 microtransactions), Registry (org catalog), Optimization (eval-driven config experiments). See What this post doesn’t cover.

Opinionated take: treat AgentCore as the paved road for customer-facing and product-embedded agents. Treat Amazon Quick Suite as the paved road for employee permission-aware knowledge work. Hybrid is normal at 200+ employees — not indecision.

Two Entry Paths: Harness vs Runtime

                    ┌─────────────────┐
                    │  Your product   │
                    │  / API layer    │
                    └────────┬────────┘
                             │
              ┌──────────────┴──────────────┐
              ▼                             ▼
     ┌────────────────┐            ┌────────────────┐
     │ AgentCore      │            │ AgentCore      │
     │ Harness        │            │ Runtime        │
     │ (config loop)  │            │ (your code)    │
     └────────┬───────┘            └────────┬───────┘
              │                             │
              └──────────────┬──────────────┘
                             ▼
         Memory · Gateway · Identity · Browser · CI · Observability

Choose Harness when:

• You want a production agent from configuration in hours, not a framework repo
• Tools are Gateway/MCP/inline and the loop is standard reason→act→observe
• You may later export to Strands on the same platform without re-platforming memory/tools

Choose Runtime when:

• You already ship LangGraph / CrewAI / Strands / custom Python and need AWS isolation + identity
• You need long-running async agents, multi-agent A2A, or a custom container image
• Orchestration logic is the product (complex branching, human-in-the-loop graphs)

What broke — Early 2026 prototype path that treated AgentCore as “enable memory on a Classic agent alias.” The team kept InvokeAgent + Classic action groups, then discovered Gateway Policy, Identity JWT inbound, and Harness/Runtime were the documented production surfaces — not Classic aliases. Detection: architecture review against the AgentCore developer guide before a compliance audit. Fix: rebuild tools as Gateway targets and pick Runtime (existing Python agent) instead of forcing Classic. Lesson: lifecycle banners are not a migration recipe; Classic and AgentCore are different control planes.

Memory: Strategies, Not Just a DynamoDB Flag

AgentCore Memory supports short-term (session) and long-term (cross-session) stores. Long-term extraction is driven by strategies — built-in (semantic, summarization, user preference, episodic), overrides, or self-managed pipelines (memory strategies).

Harness can provision managed memory with defaults (semantic + summarization, event expiry) so you are not inventing a summary table on day one. Runtime frameworks integrate via the Memory APIs and SDKs.

Design rules that matter in production:

1. Namespace memory by user (or tenant) — never a shared global notebook for multi-tenant SaaS.
2. Set retention / TTL early — Memory event and retrieval charges compound when facts live forever (pricing guide).
3. Keep Knowledge Bases for documents; keep Memory for interaction state. Duplicating PDFs into Memory is a cost and quality bug.

Tools: Gateway, MCP, and Policy

Gateway turns OpenAPI, Smithy, Lambda, and existing MCP servers into agent-callable tools with ingress/egress auth. For Responses API server-side execution (discover → select → execute without a client tool loop), see the Gateway server-side tools post — including the ~180 → ~95 ms median tool RTT benchmark on a 12-tool CRM assistant.

Policy sits on Gateway: Cedar (or natural language converted to Cedar) intercepts tool calls before execution — who can call which tool with which arguments. That is the control you want for write tools in finance and healthcare, not a prompt that says “please be careful.”

Opinionated take: once you cross ~10 tools or need shared OAuth SaaS connectors, prefer Gateway over ad-hoc Lambda wiring in the app. Keep a client confirmation loop only when product requires human approval before every write.

Identity and Session Isolation

Every Runtime/Harness session runs in an isolated microVM. Session A must not leak conversation state or filesystem into Session B.

AgentCore Identity ties the agent workload identity to enterprise IdPs (Cognito, Okta, Entra ID, Auth0). For per-user credential scoping into third-party tools (Google, Slack, etc.), prefer inbound JWT/OAuth on the harness/runtime so Identity can bind tokens to the end user — SigV4 caller paths do not get the same on-behalf-of story today (Harness security).

Scope IAM execution roles per agent. An over-privileged agent role is automated lateral movement with a chat UI.

Observability and Quality

Observability emits OpenTelemetry-compatible telemetry into CloudWatch — step-level visibility across model calls, tools, and memory operations. Forward to Datadog/New Relic/etc. only if that stack speaks OTEL and you accept dual-ingest cost.

Traces tell you what happened. Evaluations tell you whether it was good. Wire evals into CI before you scale session volume; thirteen built-in evaluators and custom judges exist — region availability for Evaluations has been preview-limited; confirm current regions before committing a launch gate.

Production Reference Architecture

A durable customer-facing assistant on AgentCore typically looks like this:

1. Edge — API Gateway / ALB + your auth (or JWT passed through to AgentCore Identity).
2. Entry — Harness (InvokeHarness) or Runtime (InvokeAgentRuntime) — not Classic InvokeAgent for net-new.
3. Memory — user-scoped STM/LTM with TTL and strategies matching the product (preferences vs episodic).
4. Gateway — tool catalog (Lambda/OpenAPI/MCP) + Policy for write paths.
5. Optional — Browser / Code Interpreter only on turns that need them (always-on burns duration).
6. Observability + Evaluations — CloudWatch + nightly/weekly eval suites.
7. Model — Bedrock (or OpenAI-compatible / Gemini via Harness provider support) chosen for price-performance; switchable without rewriting tool IAM if Gateway owns tools.

# Conceptual control-plane shape (not a copy-paste SDK pin).
# Confirm field names against the AgentCore API reference for your SDK version.
#
# Path A — Harness: CreateHarness / UpdateHarness / InvokeHarness
#   model + system prompt + tool/Gateway refs + memory config
#
# Path B — Runtime: CreateAgentRuntime + container/framework artifact
#   JWT authorizer (optional) + execution role + VPC config
#
# Shared: Gateway targets, Memory resource, Identity credential providers

Cost Reality (Platform vs Model)

Do not budget AgentCore as “DynamoDB GB-month plus per-invocation.” As of the rates wired into our calculator (2026-07-04, us-east-1):

Model tokens remain the largest line for most agents. Lean Runtime+Memory deployments often land roughly 1.15× model spend; full Browser+CI+Gateway+Identity stacks closer to 1.4× — directional, not a guarantee. Work the numbers on the AgentCore pricing calculator and the 12-components post.

Classic → AgentCore: Honest Cutover Posture

Classic tutorials on this site (agentic workflows, Classic tool-use, Classic multi-agent supervisor) remain useful for understanding the old loop. They are not the recommended implementation path for net-new builds. Prefer Gateway + Harness/Runtime; use the multi-agent supervisor post as pattern language, not as Classic CloudFormation you copy into production in Q3 2026.

What to Do This Week

1. Decide Harness vs Runtime with one sentence of justification (config vs custom code).
2. Inventory tools; if ≥10 or multi-team, draft Gateway targets and Policy for writes.
3. Define Memory namespaces + TTL before the first production user.
4. Run the pricing calculator with your sessions × active seconds × peak memory.
5. If you still have a Classic prototype, schedule a cutover design review — not a silent alias rename.

What This Post Doesn’t Cover

• Exact unit prices beyond calculator-as-of dates — always check AWS AgentCore pricing.
• Identity federation deep-dive (token vault, custom claims, multi-IdP) — follow-on post.
• Evaluations CI design and Optimization A/B — follow-on.
• Payments, Registry, Optimization product setup.
• EU AI Act classification for autonomous write tools.
• GovCloud / every region matrix — confirm regional availability in AWS docs before procurement language.

We have not re-benchmarked Harness cold-start p95 across every commercial region on the same day as this update — measure in your target Region before committing UX copy that promises “instant” first messages.

Related reading

• AgentCore pricing: 12 components
• Gateway server-side tool execution
• AgentCore vs Amazon Q / Quick Suite decision guide
• Glossary: Bedrock AgentCore
• AgentCore pricing calculator
• Amazon Bedrock consulting · Generative AI on AWS

Need a production readiness assessment (Harness vs Runtime, Gateway Policy, Memory TTL, cost model)? Contact FactualMinds — AWS Select Tier Partner with AgentCore delivery experience across financial services, healthcare, and SaaS product agents.