AgentCore, One Primitive at a Time
A running log of building on Amazon Bedrock AgentCore — Gateway, Identity, Policy, Runtime, Memory, Code Interpreter, Browser — one primitive at a time, each post grounded in something I actually ran.
AgentCore is not one service — it's a set of primitives you reach for one at a time, as the problem in front of you demands it. This is the order I actually built them in: what each piece does, what breaks if you skip it, and what the trace says once it's running for real.
-
How AgentCore Gateway Turns Any API Into an Agent Tool
AgentCore Gateway is a managed front door between agents and tools. It handles inbound auth, outbound auth, and protocol translation once, so any API or Lambda becomes an MCP tool that every connected agent can call. Here is how the wiring actually works.
-
The AgentCore Map: What Each Piece Actually Does
Amazon Bedrock AgentCore is not one service — it is a set of primitives you can use à la carte. Here is the map: what each piece does, which problem it solves, and how they compose, so the names stop blurring together.
-
Two Ways to Authorize an Agent Tool: IAM or OAuth on Amazon Bedrock AgentCore Gateway
When you expose a tool to agents through an AgentCore Gateway, the real decision is who is allowed to call it — SigV4/IAM for callers inside your AWS boundary, or a JWT authorizer for everyone else. Here are the three patterns and when each fits.
-
Who May Call What: Per-User Authorization on AgentCore With Cedar
A valid token proves who is calling. AgentCore Policy is a Cedar engine on the gateway that answers who-may-call-what per user, per tool, per argument — default-deny, before the tool runs. I wired one up and watched it allow, then deny, the same call.
-
Where AgentCore Sits in the Architecture
Place Amazon Bedrock AgentCore before you judge it: a governed server-side hub, entered through a browser where the human already authenticated, reaching tools through a gateway. I built that hub and ran it — an agent inside Runtime, gated by Cedar, grounded through a connector — and from that vantage two things I first read as gaps turned out to live in a layer AgentCore hands off to.
-
AgentCore Runtime: Where an Agent Actually Runs
An agent that thinks, calls a tool, waits, and thinks again is the wrong shape for a Lambda and the wrong thing to leave on a laptop. Amazon Bedrock AgentCore Runtime is the managed answer — a per-session microVM behind an HTTP contract. Here is what that contract actually demands, and what running an agent server-side looks like in the metrics.
-
AgentCore Memory: What an Agent Remembers When the Session Is Gone
A deployed agent's session is a microVM that vanishes when the call ends, so by default it starts every conversation from zero. Amazon Bedrock AgentCore Memory is the managed fix — automatic write, automatic recall, per-user isolation. I wired it into a real agent across two sessions and three tenants to see what it actually does, and where it still fades.
-
AgentCore Code Interpreter: When the Agent Has to Actually Run the Math
An agent will write correct-looking Python and then hand you a plausible number it never computed. AgentCore Code Interpreter is the managed sandbox that makes the agent run the code instead of guessing the output. I wired it into a real analyst task — computing the Pareto frontier of 500+ LLMs from a dated snapshot — and read the trace to see where the computation actually happens.
-
What You Build on the AgentCore Harness
Once AgentCore is placed as a governed server-side hub, the question turns from what it lacks to what you assemble on it. Four use-case shapes teams are shipping in 2026 — agentic analytics, a research copilot, enterprise workflow automation, and support triage — each with the wiring behind it: a Bedrock model doing the reasoning, AgentCore holding the operational parts together.
-
Four Tools, One Loop: The AgentCore Knowledge Worker
An agent that only calls APIs hits a wall when the answer lives in a rendered page, a computation, or last month's session. I wired a four-tool loop inside an AgentCore Runtime — search, browser, Code Interpreter, Memory — and ran it live. The prescriptive prompt is the product surface; the infrastructure is fixed.
-
Browser Use vs. AgentCore Browser: Two Managed Browsers, and Which Layer Each One Wins
AgentCore Browser gives an agent a governed browser inside your AWS account. Browser Use Cloud gives it a natural-language browser with a stealth moat. I ran eleven live experiments against Browser Use — extraction, structured output, profiles, deterministic rerun, MCP, human-in-the-loop, and a stealth benchmark — and put it head-to-head with AgentCore Browser on identical tasks. The interface, the cost, and the differentiator are not where the marketing points.