The full stack, deployed

The runtime runs the loop; Memory, Gateway, and Identity give it recall, tools, and delegated authority. This closing chapter of the part adds the agent's hands (Code Interpreter and Browser) and its governance (Observability, Policy, Evaluations), then assembles the whole thing into one end-to-end deployment with a production checklist. This is where the six AgentCore components stop being a list and become a system. Follow-along is illustrative; the architecture is the deliverable.

Code Interpreter and Browser: managed hands

Chapter 19 decoded these as session-shaped microVM sandboxes; here are the calls. Code Interpreter gives the agent a stateful interpreter session, the escape from the token economy that lets it compute over data instead of reading it token by token:

# illustrative
from bedrock_agentcore.tools.code_interpreter_client import CodeInterpreter
ci = CodeInterpreter(region="us-east-1")
ci.start()                                  # a fresh isolated session
result = ci.invoke("code_interpreter", {
    "language": "python",
    "code": "import pandas as pd; print(df.groupby('svc').p99.max())"})
ci.stop()                                   # session destroyed

The session is stateful across calls (load data once, refine across turns, like a notebook), runs in a microVM, and its network access is controllable, the egress-is-the-control lesson as a session setting: default it to no egress, allowlist only what a task needs. Browser is the same session model for a headless browser the agent drives (via CDP, with a live-view for audit), and AWS's Nova Act drives it through Playwright, the same judgment-from-a-model, hands-from-open-source split as everywhere in this stack. Both are the buy side of the sandbox decision: a maintained microVM sandbox by the session, versus the DIY Firecracker service you build only when egress policy or fleet economics force it.

Observability: sessions become traces

Chapter 40 built a tracer by hand; AgentCore emits the real thing. With observability enabled (an environment flag and the ADOT layer), every session and turn emits OpenTelemetry spans with the generative-AI semantic conventions, the standard attribute names for model, tokens, and tool calls, and they flow into CloudWatch's GenAI Observability dashboard and Transaction Search:

# illustrative env on the runtime
AGENT_OBSERVABILITY_ENABLED=true
OTEL_EXPORTER_OTLP_ENDPOINT=<managed>

The trajectory-is-the-unit principle is exactly what you get: a session is a trace, its turns and tool calls are child spans, token counts are attributes, and because the format is open OTEL, the same stream feeds CloudWatch or any OTEL backend you already run. The runtimeSessionId from Chapter 60 is the correlation key: one id ties the invocation, the trace, and the Memory events together, so "show me everything session X did" is one query, the gate-9 promise on managed rails.

Policy: rules the model cannot argue with

Chapter 20 placed Policy on the control ladder's top rung; here is what it is. You author rules in natural language ("this agent may read any ticket but may only close tickets it opened this session"); AgentCore compiles them to Cedar, the open-source, formally verified policy language; and enforcement happens in the platform, on every tool call, outside the model's reasoning loop. The placement is the whole value: a Cedar rule evaluated by the platform is not part of the conversation, so no jailbreak reaches it, there is nothing linguistic to reach. The natural-language authoring is ergonomics; the compiled Cedar is what runs, and it is inspectable and versionable like any policy-as-code. Policy went GA in early 2026, and the general lesson travels beyond AWS: every agent platform needs a place rules are enforced that the model cannot argue with, and if yours lacks a policy engine, that place is IAM plus your gateway, never the prompt alone.

Evaluations: graders on managed rails

Chapter 41 built the eval discipline; AgentCore Evaluations supplies the machinery over your session traces. Built-in evaluators score the qualities agent work actually has, tool-selection accuracy, goal success, correctness, helpfulness, safety, context relevance, run continuously or on demand against captured trajectories, and surface next to the traces they judge. The buy-versus-own split is unchanged: the graders are supplied, but the golden task set that defines "good" for your domain, the judge calibration against human labels, and the CI gate that blocks a bad prompt change remain your architecture. Managed Evaluations shortens the build of gate 8; it does not build the gate.

The end-to-end deploy

Now assemble it, the realistic sequence for a production copilot on AgentCore:

  1. Build the agent in any framework (Strands, LangGraph, or the Part 1 loop), wrapped in BedrockAgentCoreApp with @app.entrypoint.
  2. Provision the shared resources: a Memory store with your strategies, a Gateway fronting your internal APIs, Identity credential providers for the third-party systems the agent acts on.
  3. agentcore configure and agentcore launch: the CLI runs the ARM64 CodeBuild, pushes to ECR, creates the runtime with its execution role and an endpoint.
  4. Enable observability (the env flag) so sessions emit traces from the first invocation.
  5. Attach a Policy for the tool actions that must be bounded outside the model, and stand up an Evaluations job over the trace stream.
  6. Invoke with a per-user runtimeSessionId; the platform gives each session its own microVM, warm across the user's turns, idle-billed to near zero between them.

The result is a governed, observed, memory-backed agent that acts as its users, and the striking part is how much of the production bar it inherits: session isolation (gate 2), tracing (gate 9), and identity plumbing (gate 1) are largely done, while budgets, failure semantics, resumability, and evals (gates 3, 5, 6, 8) stay yours, exactly the AgentCore verdict's scorecard, now confirmed at the wire level.

A production checklist

Before this AgentCore agent takes real traffic:

  • Execution role scoped to exactly the model, ECR repo, logs, and tool permissions it uses, nothing broader (Chapter 60).
  • Identity for every third-party call, so no user token is ever in a prompt or the execution role (Chapter 61).
  • Code Interpreter / Browser egress defaulted off, allowlisted per task (Chapter 30).
  • A Policy on every consequential tool action, enforced outside the loop (Chapter 20).
  • Observability on, with runtimeSessionId correlating traces, memory, and logs (Chapter 40).
  • An eval gate in CI and a canary over live traces, with a calibrated judge (Chapter 41).
  • A budget enforced by your ledger, because AgentCore does not know your token budget (Chapter 23).
  • A Classic-migration check: since Bedrock Agents Classic is closed to new customers, new builds start on AgentCore, and any Classic action groups migrate to Gateway MCP tools.

Don't be confused: AgentCore replaces the runtime, not the platform. The full stack in this chapter is an excellent execution-plane answer, it hosts, isolates, observes, and governs a single agent's loop beautifully. It is not the Hive control plane. The budget ledger, the token governor, the scheduling layer, the verification mesh, the fleet fan-out, those are the half of the production bar that is not for sale, and they run around AgentCore, not inside it. Buy the runtime; own the platform. That has been the book's posture in every part, and it is the last word of this one.

Part 12 closed the wire-level gap the conceptual chapters left: the two request shapes, the economics as ARNs, Guardrails, batch, and Knowledge Bases as config, the Runtime contract as a runnable server, and Memory, Gateway, Identity and the governance stack as deployable resources. With Part 2 and Part 3 for the concepts and this part for the hands-on depth, the AWS agent stack is covered from mental model to wire.

👉 The glossary and references close the book.