AWS Bedrock & AgentCore
A runtime for agents. A system for operators.
Amazon Bedrock AgentCore provides the services an agent needs once it leaves a notebook: an isolated runtime, a governed path to tools, identity for callers and outbound credentials, memory, policy on tool calls, tracing and evaluation. Implementation work is mostly deciding how those pieces fit your accounts, identity provider and operating team. This page covers that design; the linked guides compare hosting options and walk through a deployment.
The opportunity
Start with a decision
worth improving.
An agent pilot works in a notebook but now needs controlled tools, repeatable runs and operational visibility. The missing work is the system around the model.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Define the runtime contract
Document the agent's tools, data, state and lifecycle. Identify isolation, identity and concurrency requirements before mapping them to the AWS services available in the target environment.
Connect controlled capabilities
Integrate approved tools and data sources with scoped access. Separate model decisions from action validation and preserve the context needed to inspect a run.
Make operation repeatable
Exercise timeout, cancellation and recovery paths. Connect task-level evaluation with telemetry and release practices so operators can diagnose failures rather than only observe activity.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
Agent runtime and tool architecture
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
AWS integration and deployment design
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Operational evaluation and runbooks
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
Explore the practice
Further capabilities
and implementation detail.
The Complete AWS AI Agent Infrastructure
Amazon Bedrock and AgentCore together form the most comprehensive cloud-native agent infrastructure available. Bedrock provides the declarative management plane — configuring business logic, guardrails, and task execution — while AgentCore provides the low-level modular execution engine with secure microVM runtime, identity-aware tool access, and production-grade observability. ColdAI's AWS practice architects deployments that leverage both layers, delivering framework-agnostic agent systems that run LangGraph, CrewAI, or custom orchestration within enterprise VPC boundaries.
AWS Bedrock & AgentCore Performance
AgentCore Service Architecture
Eight core services powering production-grade autonomous agents
Secure Runtime
Isolated microVM execution environment for hosting any agent framework — LangGraph, CrewAI, or custom Python/LangChain agents — with full control over the orchestration loop.
Memory & Context
Persistent memory layer enabling agents to maintain conversational context, store intermediate results, and recall previous interactions across sessions.
Tool Access & Identity
Identity-aware tool access with fine-grained IAM policies ensuring agents can only invoke approved tools with appropriate permissions.
Policy & Guardrails
Deterministic policy gates that enforce content filtering, PII detection, topic restrictions, and custom business rules before agent actions execute.
Observability Stack
CloudWatch integration, distributed tracing, and custom metrics providing full visibility into agent reasoning chains, tool invocations, and performance.
Multi-Model Orchestration
Route queries to optimal foundation models — Claude, Llama, Mistral, or custom models — based on task complexity, cost constraints, and latency requirements.
Our AWS Agent Deployment Methodology
From architecture to production-grade autonomous systems
Architecture Design
Design the agent topology — selecting between Bedrock Agents for managed deployments or AgentCore for custom framework hosting — with VPC, IAM, and network architecture.
Knowledge Base Integration
Connect agents to enterprise data sources via Bedrock Knowledge Bases, S3, and vector stores for grounded, accurate responses.
Guardrail Configuration
Implement content filters, PII detection, topic restrictions, and custom business rules using Bedrock Guardrails and AgentCore Policy service.
Multi-Agent Orchestration
Build collaborative agent systems where specialized agents handle different aspects of complex tasks with supervisor coordination.
Production Hardening
Deploy with PrivateLink, VPC endpoints, CloudFormation automation, resource tagging, and comprehensive monitoring for enterprise-grade reliability.
Bedrock Agents vs AgentCore
| Capability | Bedrock Agents | AgentCore |
|---|---|---|
| Abstraction Level | High — declarative configuration | Low — modular execution engine |
| Framework Support | AWS-managed agent framework | Any framework (LangGraph, CrewAI, custom) |
| Customization | Action groups, knowledge bases, guardrails | Full orchestration loop control |
| Ideal For | Standard agent use cases with managed infrastructure | Complex, custom agent architectures at scale |
| Security Model | IAM-based with managed guardrails | Isolated microVMs with identity-aware tool access |
Deploy Production-Grade AI Agents on AWS
Our AWS-certified team will design and deploy autonomous agent systems on Bedrock and AgentCore that meet your performance, security, and compliance requirements.
Contact Our TeamIn depth
Go deeper into AgentCore
A comparison of the three ways to host an agent on AWS and a step-by-step deployment of a framework-built agent onto AgentCore Runtime.
- 01ComparisonBedrock Agents vs AgentCore: when to use whichBedrock Agents Classic, the AgentCore harness or AgentCore Runtime? A feature comparison, scenario-based decision guide and migration checklist for AWS teams.
- 02ProcessDeploying a LangGraph or CrewAI agent to AgentCore RuntimeA nine-step process for moving a LangGraph or CrewAI prototype onto Amazon Bedrock AgentCore Runtime with authentication, gateway tools, memory and tracing.
The operating stack around an agent on AgentCore
- Callers and identity
Users and applications authenticate with IAM or with tokens from your identity provider before a session starts.
- Gateway and policy
One entry point for tools, with policies evaluated on each tool call before it runs.
- Runtime or harness
Each session runs in its own isolated microVM, executing your code or a managed agent loop.
- Memory and session state
Short-term events within a session and long-term records extracted across sessions.
- Tools and enterprise systems
APIs, Lambda functions and MCP servers, reached with credentials held by AgentCore Identity.
- Observability and evaluation
Traces, metrics and quality scores in CloudWatch for the people who operate the agent.
Six operator questions and the AgentCore answer to each
| Operator question | AgentCore service | What you still have to decide |
|---|---|---|
| Who may start or call this agent? | Runtime inbound authorization: IAM SigV4, or JWT bearer tokens from an OpenID Connect provider, one or the other per runtime2 | Which identity provider, audiences and clients to trust, and whether the runtime should be reachable only through a gateway |
| What may it reach, and with whose credentials? | Gateway turns APIs, Lambda functions and existing MCP servers into tools; Identity holds OAuth tokens and API keys for outbound calls3 | Which systems become tools, and whether each call acts for the user or for the agent itself |
| What is it allowed to do with a tool? | Policy evaluates every tool call through a gateway against Cedar rules, which can also be drafted in natural language4 | The rules themselves: limits, required approvals, who may call which tool with which arguments |
| What does it remember? | Memory keeps turn-by-turn events within a session and extracts long-term records such as preferences and summaries5 | What must never be stored, how long records live and how memory is scoped per user |
| What happened in a given run? | Observability emits OpenTelemetry-compatible metrics, spans and logs to Amazon CloudWatch6 | Which extra spans to add in your code and who watches the dashboards |
| Is it getting better or worse? | Evaluations scores sessions and traces, online against sampled traffic or on demand from a pipeline7 | The evaluation set, the thresholds that block a release and who reviews regressions |
Service names and features follow the AgentCore developer guide at the time of review; availability can differ by AWS Region.
Hosting starts with who owns the agent loop
There are two ways to host on AgentCore. The managed harness runs the orchestration loop for you from configuration (model, instructions, tools, memory and limits), while Runtime hosts agent code you write in any framework or none8. Amazon Bedrock Agents, the earlier managed service, is now Bedrock Agents Classic, in maintenance mode and closed to accounts without prior usage9.
The choice matters less for the first demonstration than for the second year of operation: who can change the agent's behavior, how a framework upgrade is tested and where multi-agent logic lives. Our comparison of Bedrock Agents Classic, the harness and Runtime sets out that decision, and the deployment walkthrough follows a framework-built agent onto Runtime.
Model selection, Bedrock Knowledge Bases and inference capacity are separate decisions covered on our AWS Bedrock page. An AgentCore agent can use them, or models from other providers, without changing the operating design described here.
Where agent operations on AWS tend to break
Runtime reachable around the gateway
Early signalPolicies and guardrails sit on the gateway, yet some callers still invoke the runtime directly.
MitigationRestrict invocation to the gateway, with a resource-based policy for IAM callers or the authorizer's allowed-workload setting for JWT callers2.
User identity asserted rather than proven
Early signalA calling service passes a user ID header that nothing validates against a signed-in user.
MitigationUse JWT inbound authorization in production and grant the permission for user-ID delegation only to tightly scoped principals2.
Memory shared across users
Early signalLong-term records from one person surface in another person's session.
MitigationScope memory by actor, review what each extraction strategy keeps and exclude data classes that must not be retained.
Traces that stop at the framework boundary
Early signalDashboards show session counts and latency but not which tool call failed or why.
MitigationAdd OpenTelemetry spans for tool calls and key decisions, and check that a failure can be diagnosed from traces alone.
Runaway sessions
Early signalLoops of tool calls or retries continue until the session lifetime ends.
MitigationSet iteration, token and lifetime limits, and alert on sessions that reach them.
Inputs for an AgentCore design workshop
How ColdAI delivers AgentCore work
Our AWS agent work is framework-agnostic: we deploy agents built with LangGraph, CrewAI or custom orchestration loops inside enterprise VPC boundaries1. We begin with a written runtime contract that covers tools, data, state, session lifecycle, isolation and concurrency, and only then choose AgentCore services against it.
The deliverables are the agent runtime and tool architecture, the AWS integration and deployment design, and operational evaluations with runbooks for timeouts, cancellation and recovery1. Model strategy and retrieval design sit with our Bedrock practice, so the two streams can run in parallel without overlapping.
Frequently asked questions
Does AgentCore only work with Amazon Bedrock models?
No. AWS documents Runtime as working with any large language model, including models offered through Amazon Bedrock, Anthropic Claude, Google Gemini and OpenAI, and with frameworks such as LangGraph, Strands Agents and CrewAI or custom code10. Model choice is still a decision to make on quality, latency, cost and data-handling grounds for each workload.
How long can an AgentCore session run?
On the default microVM compute a session can run for up to eight hours; the Instances compute type, which uses AWS-managed EC2 capacity in your account, supports sessions of up to fourteen days10. For work that is merely slow, returning a job reference and storing progress is often cleaner than holding one session open.
Do we have to adopt every AgentCore service?
No. AWS describes the services as modular, usable together or independently11. A common starting set is Runtime or the harness with Observability, then Gateway and Identity as soon as the agent calls real systems, and Policy once tool rules need enforcing outside the agent's code. Memory and Evaluations follow the workload rather than a fixed order.
Can AgentCore agents reach systems inside our VPC?
Yes. Both Runtime and the harness support VPC networking, so an agent can reach private endpoints without exposing them publicly8. Plan the network design with your platform team early, because subnets, security groups, endpoints and DNS for each tool affect a deployment as much as the agent code does.
Where do Knowledge Bases and model routing fit in an AgentCore design?
They are inputs to the agent rather than part of its operating system. A Bedrock Knowledge Base can be connected to an AgentCore agent through a gateway or a retrieval tool9, and model choices are made per request. Our AWS Bedrock page covers model evaluation, retrieval and inference capacity.
Sources
- AWS Bedrock & AgentCore: delivery approach and deliverables — ColdAI
- Authenticate and authorize with Inbound Auth and Outbound Auth — Amazon Web Services
- Amazon Bedrock AgentCore Gateway — Amazon Web Services
- Policy in Amazon Bedrock AgentCore: Control Agent Interactions — Amazon Web Services
- Add memory to your Amazon Bedrock AgentCore agent — Amazon Web Services
- Observe your agent applications on Amazon Bedrock AgentCore Observability — Amazon Web Services
- Amazon Bedrock AgentCore Evaluations is now generally available — Amazon Web Services
- AgentCore harness vs. Runtime — Amazon Web Services
- Amazon Bedrock Agents Classic maintenance mode — Amazon Web Services
- Host agent or tools with Amazon Bedrock AgentCore Runtime — Amazon Web Services
- What is Amazon Bedrock AgentCore? — Amazon Web Services
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- A defined agent workload
- AWS platform and security ownership
- Availability, isolation and budget requirements