Five parts, one question each: where does it run, what does it remember, what can it reach, who is it allowed to be, and what did it actually do. What a production agent runtime has to provide goes deeper than this level needs, as do the two component cases: describing tools well enough to be chosen well and credentials scoped to the caller. At this level, remembering the five parts and what each one replaces is enough.
Flash card
Amazon Bedrock AgentCore: the managed runtime and supporting services for running an agent in production on AWS, framework-agnostic and model-agnostic, so adopting it is a hosting decision rather than a rewrite.
- The runtime is serverless and hosts an agent regardless of which framework wrote it. Strands Agents, or another library entirely, describes the loop; AgentCore runs it, gives each conversation its own isolated execution environment, and keeps a long-running session alive across turns without anyone sizing a fleet for it.
- Memory gives an agent short-term state for the conversation in progress and longer-term recall of facts about the person it is serving, held in a managed store with its own retention rules. Memory management becomes configuration: what gets kept, for how long, and per whom, rather than a database somebody on the team operates.
- Gateway turns APIs and AWS Lambda functions a company already has into tools an agent can call, and exposes them over Model Context Protocol [MCP] so any agent that speaks the protocol reaches them the same way. Connecting a system stops being a hand-written adapter per pairing; tool usage, meaning which tool the model picks and when, still depends on how well each one is described.
- Identity gives the agent scoped, short-lived credentials for calling other systems, including on behalf of the person it is acting for, instead of a standing key sitting in the agent’s configuration. Access can then be revoked or narrowed per agent without rotating a secret every consumer shares.
- Observability traces which tools ran, in what order, with what inputs and what came back. An agent chooses its own path, so that trace is what makes its behaviour auditable after the fact and what an operator reads when a run went somewhere unexpected.
Pick it when
Pick it when an agent that works on a laptop needs real users, and the alternative is building the runtime, the memory store, the tool plumbing and the credential handling yourself. It is the hosting answer for an agent built in any framework, against any model, which is why it sits alongside a framework rather than competing with one.
It's the wrong answer when
It is the wrong answer for a fixed sequence of steps that never varies. That is workflow orchestration of a path already known, and AWS Step Functions runs it more cheaply and more predictably than a model deciding each step afresh. It is also the wrong answer for a single prompt-and-response call that uses no tools at all, where an Amazon Bedrock model invocation is the whole application, and it does nothing to make a poor agent good: a badly scoped tool set is still badly scoped once it is hosted.