AgentCore in plain terms
This is a reference page. Read it while a deploy runs, or come back to it when a term in the steps doesn't make sense.
What an agent is
An agent is a model running in a loop. It reads a request, decides whether to call a tool, reads the result, and repeats until it has an answer. You can build that loop on a laptop quickly. Running it for many users at once is where the work is: hosting, isolation between users, credentials for tools, memory, logs, limits and a way to tell whether it's any good.
Amazon Bedrock AgentCore is a set of managed services for that second part. You can use them together or one at a time, and your agent doesn't have to run on AWS to use most of them.
The pieces
| Piece | What it does | Used today in |
|---|---|---|
| Harness | Defines an agent as configuration: model, system prompt, tools, memory and limits. AgentCore runs the agent loop for you. | Kopi Run, Intake |
| Runtime | Serverless hosting for agents. Each session runs in its own isolated microVM. The harness runs on it, and you can also deploy your own agent code to it. | Under every harness |
| Gateway | Turns Lambda functions, OpenAPI specs, Smithy models, API Gateway APIs and MCP servers into MCP tools behind one endpoint, with authentication on both sides. | All three |
| Memory | Short-term memory for the current conversation and long-term memory for facts and preferences, kept separate per user. | Kopi Run |
| Identity | Handles who is calling the agent and which credentials the agent uses for downstream tools. API keys live in a token vault the agent never reads directly. | In the background |
| Policy | Allow and deny rules written in Cedar, checked by Gateway on every tool call. Default deny, and a deny always wins. | Tally |
| Observability | Traces, logs and metrics in CloudWatch GenAI Observability, for agents on AgentCore or anywhere else via OpenTelemetry. | All three, mainly Tally |
| Evaluations | Scores sessions, turns and tool calls with built-in or custom judges, on demand or continuously on live traffic. | Intake |
| Code Interpreter | A sandbox where the agent can run Python or JavaScript. | Intake |
| Browser | A managed browser the agent can drive. | Not today |
| Optimization | Suggests prompt and tool description changes from evaluation results, and A/B tests them. | Optional step in Intake |
Which piece do I need?
| If your problem is... | Start with |
|---|---|
| I want an agent running today and I don't want to write orchestration code | Harness |
| My harness can't do what I need any more | Export the harness to Strands code and run it on Runtime |
| My agent already runs somewhere else | Keep it there. Add Gateway, Policy, Observability or Evaluations on their own |
| My agent calls internal APIs with a shared key | Gateway, with Identity for outbound credentials |
| I need limits the model can't talk its way past | Policy |
| I can't tell what my agent did | Observability |
| I don't know if my agent is getting better or worse | Evaluations |
Harness or Runtime?
Use the harness when configuration is enough: a model, a prompt, tools, memory, maybe skills or a custom container. Changing any of it is an edit and a deploy, and every deploy is a new version you can roll back to.
Use Runtime with your own code when you need custom orchestration, several agents working together, or a framework the harness doesn't use. You don't have to start again: agentcore export harness writes your harness out as a Strands Agents project that runs on the same Runtime with the same Memory, Gateway and Observability.
Words you'll see
| Term | Meaning |
|---|---|
| Session ID | Groups the turns of one conversation. Reuse it to continue; use a new one to start fresh. Must be at least 33 characters, which is why we use UUIDs. |
| Actor ID | Who the agent is talking to. Memory is kept separately for each actor. |
| Tool schema | The name, description and inputSchema of a tool. The model reads it on every turn and shapes its arguments to match. |
| Target | One backend behind a Gateway, such as a Lambda function. Its tools appear as <target>___<tool>. |
| Policy engine | The container for Cedar rules. Attach it to a Gateway in LOG_ONLY mode to watch, or ENFORCE mode to block. |
| Evaluator | A judge that scores agent output. Builtin.* evaluators are provided; you can write your own as a prompt or a Lambda function. |
| Transaction Search | A one-time CloudWatch setting that indexes trace spans. Without it, you won't see traces. |
Regions
Everything used today is available in Asia Pacific (Singapore), ap-southeast-1. The Web Search tool for Gateway isn't available there yet, which is why we don't use it. Check the AgentCore regions page for the current list before you plan your own build.
Sources
Everything on this page comes from the AWS documentation for Amazon Bedrock AgentCore. Read these for the full detail, and check them before you plan your own build, because the service changes quickly.