← Agent Frameworks 🕐 17 min read
Agent Frameworks

AWS Bedrock Enterprise Agent Blueprints — Architecture Patterns 2026

Brandon Sneider · May 2026

> **Source credibility:** AWS open-source reference implementations (Apache 2.0 / MIT-0). TIER 2 vendor-produced. Architecture patterns are reproducible by any AWS customer.

See also (wiki): wiki/agentic-ai-governance.md · wiki/hitl-deployment-pattern.md · wiki/data-readiness.md · wiki/mlops-ai-platform-engineering.md · wiki/vendor-security-questionnaires.md · wiki/ai-platform-selection.md

Source credibility: AWS open-source reference implementations (Apache 2.0 / MIT-0). TIER 2 vendor-produced. Architecture patterns are reproducible by any AWS customer. No independent n= survey data. Performance claims are AWS-reported. Blueprint count and feature set reflect aws-samples GitHub as of May 2026 — AWS ships new reference implementations weekly, so specific repo counts are snapshots. These case studies are vendor-published and represent selected wins with no control group and no independent verification. Cross-reference against: METR RCT (experienced developers 19% slower), CMU study (40.7% code complexity increase), Atlan 200-deployment analysis (median +159.8% ROI requires workflow redesign first).

Overview

AWS has published more than 800 repositories in the aws-samples GitHub organization covering Bedrock agents, RAG patterns, and agentic workflows. The corpus spans every major enterprise vertical (healthcare/life sciences, energy, financial services, retail, public sector, telco) and every major orchestration pattern (single agent, multi-agent supervisor/subagent, LangGraph hybrid, CrewAI hybrid, Strands framework).

The primary managed runtime for production agent deployments shifted in late 2025–2026 to Amazon Bedrock AgentCore — AWS’s fully managed execution environment for agents. AgentCore replaces the earlier pattern of wiring Bedrock Agents to Lambda action groups and becomes the primary deployment target in new blueprints.

Key frameworks visible across the corpus:

  • Bedrock Agents — AWS-native managed agents with action groups, knowledge bases, guardrails, memory
  • Strands Agents — AWS open-source Python agent framework (strandsagents.com), designed for AgentCore deployment
  • LangGraph on Bedrock — graph-based orchestration calling Bedrock foundation models
  • CrewAI on Bedrock — role-based multi-agent framework with Bedrock as the LLM layer
  • MCP (Model Context Protocol) — cross-agent tool sharing standard adopted across new blueprints

1. AWS Bedrock Agents Architecture

Core Components

Bedrock Agents orchestrate multi-step tasks against foundation models. Four components define every agent:

Action groups — the agent’s tools. Each action group links to either (a) an AWS Lambda function that executes a real API call, or (b) an OpenAPI YAML schema that the agent uses to invoke an HTTP endpoint directly. Action groups give the agent read/write access to databases, APIs, code interpreters, and external services. The retail pet-store workshop illustrates three discrete action groups: database interaction (text-to-SQL via Lambda), REST API calls (OpenAPI spec), and knowledge base retrieval — each as a separately permissioned group.

Knowledge bases — managed vector stores. Bedrock ingests documents from S3, chunks and embeds them, and stores embeddings in a vector store (Amazon OpenSearch Serverless, Aurora PostgreSQL with pgvector, Kendra, Redis Enterprise, or MongoDB Atlas). At query time, the agent retrieves context before generation. AWS provides a separate Knowledge Bases for Amazon Bedrock service that handles the full ingestion pipeline without custom code.

Guardrails — content control layer applied at inference time. Configured separately from the agent, then attached. Covered below in §4.

Memory — session state persistence. Bedrock Agents can retain conversation history across sessions, enabling multi-turn workflows without the host application managing state. AgentCore Memory extends this with cross-agent and cross-session memory (an MCP server exposing memory to any connected agent).

Multi-Agent Collaboration: Supervisor + Subagent Pattern

The primary enterprise architecture for complex workflows: a supervisor agent receives the user request, decomposes it, routes subtasks to specialist subagents, aggregates their outputs, and returns a synthesized response.

The Energy Efficiency Management System workshop (bedrock-multi-agents-collaboration-workshop) shows this pattern in production form:

  • Supervisor: “Energy Efficiency Management Agent” — routes queries, maintains context
  • Subagent 1: Forecasting Agent — consumption data and code interpreter for analysis
  • Subagent 2: Solar Panel Agent — installation/maintenance knowledge + ticket creation
  • Subagent 3: Peak Load Manager Agent — grid optimization decisions

AWS calls this multi-agent collaboration and documents it at docs.aws.amazon.com/bedrock/latest/userguide/agents-multi-agent-collaboration.html. The collaboration is configured in the Bedrock console or via API — no custom orchestration code required.

Communication model: subagents are themselves Bedrock Agents with their own action groups and KBs. The supervisor invokes them through an action group whose Lambda calls the Bedrock Agents API (invoke_agent). Each subagent maintains its own guardrails and permissions boundary.

Amazon Bedrock AgentCore

AgentCore (launched 2025, broadly available 2026) is the managed runtime layer that makes agents production-ready without custom infrastructure:

  • AgentCore Runtime — containerized agent execution environment; handles scaling, health monitoring, and session management. Accepts agents built with Strands, LangGraph, CrewAI, or the Bedrock Agents SDK.
  • AgentCore Gateway — MCP-compatible endpoint router. Converts Lambda functions, OpenAPI specs, and third-party APIs into MCP tool endpoints accessible to any connected agent. Eliminates per-agent Lambda wiring.
  • AgentCore Memory — managed cross-session, cross-agent memory service, exposed as an MCP server.
  • AgentCore Browser Tool — managed headless browser for web-interaction agents (nova-act compatible).
  • AgentCore Code Interpreter — sandboxed Python execution for data analysis agents.

AgentCore represents AWS’s answer to the “prototype-to-production gap” for agents. The healthcare-lifesciences blueprint uses AgentCore Gateway to expose 30+ biomedical database tools (Biomni) as a single MCP endpoint — any agent on the platform can use them without re-implementing authentication or rate limiting.

Inline Agents vs Pre-Built Agents

Pre-built Agents (standard Bedrock Agents) are configured in the AWS console or via CloudFormation/Terraform, assigned an Agent ID, versioned, and invoked by alias. They persist configuration, support aliases for blue/green deployment, and have proper IAM role separation. This is the production pattern.

Inline Agents are created programmatically per-request using the create_agent API without persisting configuration. Use case: dynamic agents where the tool set varies by user context (e.g., a multi-tenant SaaS where each tenant gets a different action group based on their entitlements). The sample-multi-tenant-saas-rag repo demonstrates this with JWT-scoped knowledge bases.

2. Knowledge Base Patterns

Native RAG Pipeline

AWS’s native RAG pipeline: S3 → Bedrock Data Automation (optional pre-processing) → Bedrock Knowledge Bases → OpenSearch Serverless (vector store) → Bedrock Agent retrieval.

Supported vector stores (as of 2026):

  • Amazon OpenSearch Serverless (default, no infrastructure management)
  • Aurora PostgreSQL with pgvector
  • Amazon MemoryDB for Redis
  • Amazon DocumentDB
  • MongoDB Atlas
  • Pinecone

Embedding models available on Bedrock:

  • Amazon Titan Embeddings (v1, v2) — 1,536 and 256-dim variants
  • Cohere Embed (English and multilingual)
  • Amazon Nova Embeddings (newer, announced 2025)

Generation models (partial list):

  • Anthropic Claude 3.5 Sonnet, Claude 3 Haiku, Claude 3 Opus
  • Amazon Nova Pro, Nova Lite, Nova Micro, Nova Sonic (voice)
  • Meta Llama 3.x series
  • Mistral Large, Mixtral 8x7B
  • Cohere Command R+

Advanced RAG Patterns

The advanced-rag-patterns-on-mixtral repo (SageMaker, not Bedrock native) documents two techniques that outperform standard retrieval on enterprise document corpora:

Parent Document Retriever — indexes child chunks for semantic matching, but retrieves the larger parent document for context. Preserves surrounding text that answers “why” questions that chunk-level retrieval misses. Results: significantly more detailed and accurate answers on AWS earnings corpus vs. standard retriever.

Contextual Compression (LLM Chain Extractor / Filter) — after retrieval, passes chunks through a secondary LLM call that extracts only the portions relevant to the query before passing to generation. Reduces noise, improves precision, adds latency (~1 additional LLM call).

Hybrid search (hybrid-search-postgres-opensearch-bedrock repo) — combines BM25 keyword search with vector similarity, then merges ranked results. Outperforms vector-only on queries with specific entity names, part numbers, or domain jargon where semantic similarity alone fails.

Reranking — Bedrock Knowledge Bases supports reranking at retrieval time using Cohere Rerank or Amazon Rerank models. Applied post-retrieval, pre-generation. See the separate retrieval-reranking-enterprise-rag.md file in this pillar for benchmark data.

Metadata filtering — Bedrock KBs support structured metadata attached to chunks at ingest time (e.g., document date, department, classification level). Agents can apply filters at query time, enabling access-controlled retrieval without exposing documents across tenant boundaries.

Knowledge Base for Structured Data

Multiple repos (Setup-Amazon-Bedrock-Agent-for-Text2SQL-Using-Amazon-Redshift-Serverless, bedrock-agent-txt2sql, sample-Dynamic-Text-to-SQL-with-Amazon-Bedrock-Agent) implement text-to-SQL as an action group pattern: the agent receives a natural language query, generates SQL against a schema it holds in its instruction prompt or KB, passes it to a Lambda executor, and returns results. The agentic-architecture-using-bedrock workshop adds a Query Correction Agent — a separate subagent that catches SQL execution errors, analyzes the error + original query, and outputs corrected SQL. This self-healing loop improves reliability on complex schemas.

3. Vertical Blueprints

Healthcare / Life Sciences

Repo: amazon-bedrock-agents-healthcare-lifesciences (36+ reference agents)

The HCLS toolkit covers the full drug development lifecycle:

  • Drug discovery: Target identification, compound optimization, safety signal analysis
  • Genomics: Variant interpretation (HealthOmics integration), single-cell QC, pathway analysis
  • Clinical trials: Trial search, protocol generation, enrollment monitoring
  • Biomarkers: Multi-database analysis, drug label parsing
  • Terminology standardization: 200+ ontologies via OLS MCP server

Architecture shifted in 2026: individual agents decomposed into portable skills (SKILL.md files with domain knowledge + references) and MCP servers (domain tools callable from any platform). This means the same HCLS capabilities work in Claude Code, Amazon Quick, Kiro, or deployed via AgentCore — without re-implementing tool calls on each platform.

Compliance note: HIPAA workloads require AWS BAA before using Bedrock with PHI. AgentCore runs within the customer’s VPC; data does not leave the customer’s AWS account boundary during inference.

Key reference implementation: Research agent with 30+ Biomni database tools (agents_catalog/28-Research-agent-biomni-gateway-tools) — AgentCore Gateway exposes all 30+ biomedical APIs as a single MCP endpoint. Demonstrates the gateway pattern at production scale.

Energy

Repo: agents4energy + agents4energy-agent-template-alpha + sample-renewable-planning-agent

Agents4Energy (A4E) targets oil/gas, utilities, and renewables operators. Production agent handles:

  • Reservoir characterization and well workover assessment
  • Field data analysis (structured data via Athena Federated Query)
  • Supply chain optimization
  • Asset integrity management

Data ingestion: operators upload structured data to S3 (production-agent/structured-data-files/), an AWS Glue crawler automatically creates table definitions, which are loaded into Bedrock Knowledge Base — no schema migration. Athena Federated Query allows the agent to query data across heterogeneous sources (S3, RDS, third-party databases) through a single action group.

The multi-agent workshop (bedrock-multi-agents-collaboration-workshop) uses energy management as its reference implementation: supervisor + Forecasting Agent + Solar Panel Agent + Peak Load Manager. Shows how to decompose a domain (energy) into specialist subagents with clean action group boundaries.

Financial Services

Repo: financial-analysis-multi-agent-collaboration + fsi-genai-bootcamp + DigiDhan-GenAI-FSI-LendingSolution-India + sample-multi-agent-loan-processing + sample-finops-agent

FSI blueprints concentrate on three use cases:

  1. Document analysis — loan applications, regulatory filings, earnings reports via Bedrock Data Automation (intelligent document processing) + KB
  2. Multi-agent orchestration for approvals — loan processing uses a supervisor + credit analysis subagent + compliance check subagent + decision subagent pattern with human-in-the-loop (HITL) approval gates between stages
  3. FinOps/cost governance — sample-finops-agent queries AWS cost APIs and generates natural-language budget analysis; sample-bedrock-cost-tracking-by-department implements cross-account cost attribution for AI spend

The bedrock-cross-region-inference repo documents cross-region inference profiles — a key FSI pattern for latency-sensitive workloads and data sovereignty compliance.

Retail / E-commerce

Repo: agentsforβedrock-retailagent + agentic-architecture-using-bedrock + genai-assistant-for-ecommerce

The retail pet-store workshop (agentic-architecture-using-bedrock) is the most complete end-to-end reference: five agents (orchestrator, KB, query generation, query correction, API), CloudFormation deployment, Streamlit GUI, Aurora RDS + S3. Covers the full pattern for a customer-service agent with database write access.

Public Sector / Education

Repo: AI-Agents-for-Education + educational-course-content-generator-with-qna-bot-using-bedrock + sample-multiagent-orchestration-on-agentcore-for-education + public-sector-bedrock-agents

Education agents focus on adaptive content generation and assessment. The AgentCore-for-education repo uses a multi-agent pattern: curriculum agent (generates course structure) + content agent (generates material) + assessment agent (generates and grades quizzes) orchestrated by a supervisor.

4. Guardrails

What Bedrock Guardrails Blocks

Bedrock Guardrails is a separate service attached to agents and direct model invocations. Six control categories:

1. Denied topics — custom topic definitions the model refuses to engage with (e.g., competitor comparisons, investment advice, off-label drug guidance). Configured per guardrail with natural-language topic descriptions.

2. Content filters — violence, hate speech, sexual content, self-harm, misconduct. Configurable threshold levels (None/Low/Medium/High) for both prompt and response sides independently.

3. PII redaction and blocking — 30+ PII types (SSN, credit card, email, phone, names) with two modes: BLOCK (reject the request) or ANONYMIZE (replace with placeholder token and continue).

4. Grounding check — compares the model’s response against retrieved source documents (KB or provided context). Flags or blocks responses that make claims not supported by the source — hallucination detection for RAG-specific claims.

5. Contextual grounding — related to grounding check; specifically validates that the response stays within the scope of the provided context rather than drawing on parametric knowledge.

6. Word filters — exact-match blocklist for specific terms or phrases.

Integration into Agent Call Chain

Guardrails attach to a Bedrock Agent at configuration time. Every agent invocation passes through the guardrail on both the input (user prompt) and output (model response) sides. The agent call chain becomes:

User prompt → Guardrail input filter → Agent orchestration → 
Model inference → Action group execution (if needed) → 
Model synthesis → Guardrail output filter → Response to user

If either filter triggers, the agent returns a configured blocked response rather than the model output. The detect-guardrails-not-used repo implements a CloudWatch rule that alerts when Bedrock inference calls bypass guardrail evaluation — a compliance monitoring pattern for enterprises with mandatory guardrail policies.

The sample-denied-topics-bedrock-guardrails-generator-evaluator repo automates guardrail configuration: provide a policy document, the tool generates denied-topic definitions and evaluates them against a test set before deployment.

Monitoring: using-bedrock-guardrails-with-bedrock-agents-to-improve-adversarial-robustness demonstrates how guardrail invocation events emit to CloudWatch Logs, enabling dashboards that track activation rates by filter type — essential for adversarial robustness audits.

5. Enterprise Deployment Patterns

Multi-Account Architecture

Standard enterprise pattern: separate AWS accounts per environment (dev/staging/prod) plus a dedicated AI governance account for centralized model access logging. bedrock-access-gateway provides a reverse proxy pattern — internal teams call a unified endpoint, the gateway routes to appropriate Bedrock regions/accounts while enforcing usage quotas and logging all calls.

The multi-account-bedrock-llm-streaming repo shows streaming invocations across account boundaries via API Gateway. The sample-bedrock-inference-profile-mgmt repo manages inference profiles — Bedrock’s mechanism for defining which model variants and regions are available to which accounts, enabling centralized model governance.

Cross-account knowledge base access (sample-for-amazon-bedrock-agent-connect-cross-account-kb): a single centralized KB account stores sensitive enterprise documents; agents in downstream accounts access it via resource-based policies without data duplication. Critical for FSI and healthcare where data residency rules restrict where documents can be stored.

VPC and Private Endpoint Patterns

amazon-bedrock-vpc-endpoints — deploys Bedrock’s VPC interface endpoints (AWS PrivateLink) so all model invocations stay on the private AWS network. No traffic traverses the public internet. Required for regulated workloads under HIPAA, FedRAMP, financial SOC 2.

genai-secure-networking-arch-patterns — documents the full secure networking stack: VPC endpoints for Bedrock + S3 + OpenSearch Serverless, NACLs and security group rules, PrivateLink for cross-account KB access, Route 53 private hosted zones for endpoint resolution.

sample-cross-region-bedrock-private-endpoint — routes inference through a private endpoint that spans regions. Used when primary region lacks a model or when latency to a secondary region is lower for specific user populations.

rag-chatbot-with-bedrock-opensearch-and-document-summaries-in-govcloud — demonstrates RAG deployment in AWS GovCloud (US-East/West), where FedRAMP High and DoD IL2/IL4 workloads run. GovCloud has a subset of Bedrock features; this repo documents the gaps and workarounds.

Cross-Region Inference

bedrock-cross-region-inference — Amazon Bedrock’s cross-region inference feature automatically routes requests to another region when the primary region’s capacity is constrained. Two patterns:

  1. Inference profiles — define a prioritized list of regions; Bedrock routes automatically
  2. Cross-region knowledge bases — replicate KB data to multiple regions using S3 Cross-Region Replication + separate KB deployments; agent routing logic selects the nearest KB

This matters for latency-sensitive voice agents (Nova Sonic) and for European data residency — an EU KB can serve EU users without data leaving the EU, while a US KB serves US users.

Cost Governance and Token Attribution

sample-bedrock-cost-tracking-by-department and sample-bedrock-invocation-analytics implement cost attribution using Bedrock model invocation logging → CloudWatch Logs → Athena queries → QuickSight dashboards. Tags on inference profiles map calls to cost centers.

foundation-models-token-profiling-for-multi-tenant-on-amazon-bedrock — documents per-tenant token accounting for SaaS platforms built on Bedrock, including budget enforcement via Lambda-mediated quota checks before each invocation.

6. Comparison to NVIDIA AI Blueprints

Deployment Model

Dimension AWS Bedrock / AgentCore NVIDIA AI Blueprints (AIQ)
Hosting Fully managed (AWS-operated) Self-hosted on NVIDIA hardware or cloud GPU instances
Infrastructure ownership AWS manages compute, scaling, failover Customer manages GPU cluster, CUDA drivers, NIM containers
Model serving AWS hosts foundation models; customer cannot customize inference infrastructure Customer deploys NIMs; can tune batch size, quantization, inference graph
Data isolation By default multi-tenant within AWS; VPC endpoints and dedicated capacity (Provisioned Throughput) for full isolation Customer controls isolation boundary end-to-end

Speed to Deploy

AWS: a functional RAG agent on Bedrock with a knowledge base takes hours using CloudFormation templates from aws-samples. No ML infrastructure knowledge required. AgentCore handles scaling automatically.

NVIDIA: deploying AIQ with NIM containers requires GPU-capable infrastructure, CUDA compatibility, NIM licensing, and Helm/Kubernetes expertise. Initial deployment measured in days to weeks for a team unfamiliar with the stack.

When speed-to-value matters more than control: AWS wins. When the organization already runs GPU clusters (e.g., HPC or on-prem data centers with NV hardware) and wants to avoid AWS lock-in: NVIDIA wins.

Lock-In Profile

AWS Bedrock: agents, knowledge bases, guardrails, and memory are all AWS-proprietary APIs. Migrating a Bedrock Agent to another cloud requires re-implementing action groups, KB ingestion, and memory. The Strands framework is open-source (Apache 2.0) and portable, but the managed runtime (AgentCore) is AWS-only.

NVIDIA AIQ: the NIM containers and AIQ framework run anywhere with NVIDIA GPUs — on-prem, Azure, GCP, AWS. The agent framework is more portable. The cost is infrastructure complexity.

Guardrails and Compliance

AWS: Bedrock Guardrails is a managed service — AWS maintains it, handles model updates, and it integrates natively into the agent call chain with no additional latency from the customer’s infrastructure. Compliance certifications (HIPAA BAA, SOC 2, FedRAMP Moderate) are AWS’s to maintain.

NVIDIA: guardrails (NeMo Guardrails) are customer-operated. The customer patches, scales, and certifies the guardrail service. Higher control; higher operational burden.

When CIOs Choose Each

Choose AWS Bedrock / AgentCore when:

  • Time to production is the primary constraint
  • The organization lacks dedicated ML infrastructure teams
  • Workloads are cloud-native and AWS-centric (S3, RDS, Lambda, Connect)
  • Regulatory requirements are met by AWS’s existing certifications (HIPAA BAA, SOC 2, FedRAMP)
  • The agent use case is vertically contained (customer service, document Q&A, structured data analysis)

Choose NVIDIA AI Blueprints when:

  • The organization operates private data centers with NV GPU hardware (H100/H200/GB200)
  • Data sovereignty rules prohibit public cloud inference (some EU sovereign cloud requirements)
  • The team needs to customize inference infrastructure (quantization, batching, custom CUDA kernels)
  • Workloads require model fine-tuning with proprietary data that cannot leave the data center
  • The portfolio spans multiple clouds and vendor-agnostic tooling reduces switching costs

Hybrid pattern (visible in several aws-samples repos): use AWS Bedrock for managed knowledge bases, guardrails, and orchestration; run self-hosted NIM models on SageMaker GPU instances or AWS-hosted Bedrock custom model import for proprietary fine-tuned weights. This preserves the AWS managed-services layer while allowing custom model deployment without full NVIDIA stack adoption.

7. Key Operational Patterns from Blueprint Survey

Self-Healing Agents

The query-correction-agent pattern (agentic-architecture-using-bedrock): when a subagent’s action fails (SQL error, API timeout), a designated correction subagent receives the original request + error + failed output and produces a corrected attempt. Eliminates hard failures in multi-step workflows where a single tool call failure would abort the entire session.

The sample-why-agents-fail and sample-genai-reflection-for-bedrock repos document failure taxonomies and reflection loops — agents that evaluate their own output quality before returning to the user.

Circuit Breaker Pattern

sample-agent-tool-circuit-breaker implements a circuit-breaker wrapper around action group tool calls: tracks failure rates per tool, trips to “open” state when threshold exceeded, stops calling the failed tool (preventing cascade), and periodically probes for recovery. This is the agentic equivalent of the microservices pattern and directly addresses the reliability collapse documented in the institute-ai-transformation-enterprise-agent-performance-2026.md file (95%→36% reliability across 20-step chains).

HITL Integration

rag-with-human-support + multiple connect integration repos show two HITL patterns:

  1. Confidence-threshold escalation — agent scores its answer confidence; below threshold, routes to human agent via Amazon Connect
  2. Action-class escalation — specific action types (financial transactions, PII modification, irreversible operations) always require human approval before execution, regardless of confidence

Observability

four-level-observability-example-for-GenAI documents the four layers:

  1. Infrastructure (CloudWatch metrics — latency, error rate, token throughput)
  2. Model (Bedrock model invocation logs — input/output tokens, model ID, latency)
  3. Application (custom business metrics — answer acceptance rate, escalation rate, task completion)
  4. User (session-level analysis — conversation length, abandonment, NPS correlation)

sample-agentic-ai-python-application-with-amazon-cloudwatch shows structured CloudWatch integration for Strands-based agents on AgentCore.

Corpus Statistics (aws-samples as of May 2026)

Category Approximate repo count
Bedrock RAG patterns 50+
Bedrock Agents (single agent) 60+
Multi-agent / AgentCore 80+
Healthcare / Life Sciences 20+
Energy 5+
Financial Services 15+
Retail / E-commerce 10+
Observability and cost governance 10+
Guardrails-specific 5+

The corpus is the most extensive public collection of enterprise AI reference implementations from any single cloud vendor. The shift to AgentCore (visible in repo naming conventions starting ~late 2025) signals AWS’s bet on managed execution as the primary enterprise pattern over DIY Lambda-wired agents.

CIO Decision Framework

Before evaluating Bedrock Agents for a use case, confirm:

  1. Data residency — can inference and embeddings run in the required AWS region? (EU, GovCloud, or standard commercial?) Is cross-region inference acceptable under your data sovereignty policy?

  2. Isolation requirement — do you need Provisioned Throughput (dedicated inference capacity, no shared-tenant risk) or is on-demand acceptable? Provisioned is 2–3× the cost of on-demand at committed usage.

  3. Action group scope — what systems will the agent write to? Each writable system is a privilege escalation surface. Apply ZSP/JIT principles from the zsp-jit-agent-permissions-enterprise.md file to Bedrock Lambda IAM roles.

  4. Guardrail policy documentation — Bedrock Guardrails configurations should be version-controlled and reviewed by compliance. The sample-denied-topics generator automates this; the detect-guardrails-not-used monitor enforces it.

  5. Multi-agent complexity — each additional subagent adds latency (one Bedrock API call per hop) and a new failure point. Start with single-agent patterns; introduce supervisor/subagent only when the task genuinely requires parallel specialist retrieval.

  6. Exit strategy — the Strands framework (open-source) provides the most portable path; agents built on Strands can run outside AgentCore with a runtime swap. Bedrock Agents native (no Strands) has no portable equivalent — migration requires a rewrite.

Brandon Sneider | brandon@brandonsneider.com May 2026