AGENT INFRASTRUCTURE / 07

Amazon Bedrock AgentCore

Build, deploy and operate AI agents

THE BIG PICTURE

An agent with tools and memory

AgentCore MemoryOptional context across interactions

Example using AgentCore Runtime: the agent can call tools through Gateway and use Memory for context. Identity controls access.

AgentCore provides services for building, deploying and operating agents with your chosen models
Use its components together or independently; an agent framework is still a separate choice
Runtime hosts agents and tools; Gateway connects tools; Memory retains conversation context
Identity manages credentials; Policy governs tools; Observability and Evaluations assess behavior
Harness offers a managed agent loop; Registry catalogs agents, tools and related resources

Serverless Runtime sessions use isolated microVMs with separate CPU, memory and filesystems
Reuse a runtime session ID for one conversation; keep different users in separate sessions
Runtime supports real-time responses, streaming and asynchronous agent workloads
Choose managed EC2 Instances when you need supported GPU workloads or longer-lived sessions
Filesystem persistence is configurable; durable business records still need a deliberate storage plan

Deploy an ECR container image or use supported direct code deployment through the AgentCore tooling
Implement the contract for your protocol: HTTP, MCP, A2A or AG-UI have different interfaces
For HTTP agents, /invocations receives work and /ping reports readiness and background activity
Updating a Runtime creates an immutable version; named endpoints can stay pinned to a tested version
The DEFAULT endpoint follows the latest version; use a separate production endpoint for controlled rollouts

Gateway can convert APIs and Lambda functions into MCP-compatible tools behind one endpoint
Attach existing MCP servers as targets and aggregate their available tools for your agents
Tool definitions describe inputs; clear schemas and descriptions help the model select valid calls
Semantic tool search finds relevant tools without putting an entire large catalog in every prompt
Gateway also supports HTTP passthrough and inference targets; choose the target type explicitly

Inbound authentication verifies callers; outbound credentials authorize access to a target service
Runtime calls can use IAM SigV4 signing or configured OAuth bearer-token authentication
Gateway authorization and its target credentials are separate configurations with separate permissions
A runtime execution role grants AWS API access; a model prompt does not grant that authority
Restrict model, tool and data permissions to the operations each agent actually needs

AgentCore Identity represents agents as workload identities and manages access to credential providers
Credential providers support OAuth flows and API keys for external services
User-delegated OAuth access requires the user consent flow; autonomous access uses a suitable grant
Integrate an existing identity provider rather than creating another user directory for each agent
Keep tokens and API keys out of prompts and logs; scope credentials to the intended user and provider

Short-term Memory stores conversation events grouped by actor ID and session ID
Long-term Memory extracts useful knowledge across sessions through configured memory strategies
Strategies can retain facts, user preferences and summaries; no strategy means no automatic extraction
Namespaces organize long-term records; choose retrieval scope and access rules for each tenant
Your agent retrieves and supplies relevant memories as context; this does not train the model weights

Browser provides isolated sessions for navigating sites, filling forms and reading web content
Browser automation works with libraries such as Playwright; Live View allows human interaction
Custom browsers can record sessions to S3 for replay; recording is a configured feature
Code Interpreter executes Python, JavaScript and TypeScript in a managed sandbox for data tasks
Configure tool networking and roles, save useful outputs, and close sessions when work is complete

Associate a policy engine with Gateway to evaluate tool requests before the target is called
Policies can constrain the caller, tool and input parameters, such as a permitted transaction amount
Author rules in Cedar or compatible Dogwood; natural language authoring generates policies for review
The policy engine uses default-deny and forbid-wins semantics; test both allowed and denied calls
Gateway policy governs that access path; backend IAM and application authorization still matter

AgentCore Observability exposes logs, metrics and traces through Amazon CloudWatch
OpenTelemetry-compatible instrumentation records model calls, tool spans and agent execution paths
Built-in metrics exist by default; detailed traces and additional spans depend on telemetry setup
Inspect session latency, token usage and error rates; separate model delays from failed tool calls
Choose log retention and redact sensitive content before adding prompts or tool results to telemetry

Evaluations measures agent and tool behavior using built-in evaluators or custom evaluation logic
Use on-demand or batch assessment for test data, and online evaluation for sampled production traces
Evaluation requires supported framework instrumentation and the relevant telemetry configuration
Compare task completion, answer quality and tool use before changing prompts, models or tool schemas
Quality scores help diagnose behavior; they do not replace deterministic tool access policies

Check Region availability for every chosen component, model and credential-provider integration
Budget for the AgentCore components you use plus model inference and downstream service charges
Keep development and production endpoints, credentials and memory scopes separate
Make tools retry-safe: a repeated model or network request must not repeat an unwanted side effect
Pin dependencies and validate auth, memory retrieval and tool failures with realistic test sessions

Use AWS documentation for current limits, availability, and pricing.