Wa Review
- 365 installs
- 234 repo stars
- Updated August 4, 2026
- aws-samples/sample-well-architected-skills-and-steering
WA Review is a Claude skill that runs a full cross-pillar AWS Well-Architected Framework review of a workload's code and IaC to produce evidence-backed findings and prioritized remediation.
About
This skill performs a full AWS Well-Architected Framework review by analyzing code, IaC and configurations to produce evidence-backed findings with risk assessment and prioritized remediation. A solutions architect or developer uses it for a comprehensive all-pillars assessment rather than a single-pillar deep-dive. It bundles reference material including an agentic-AI lens covering security, reliability, performance, operations and cost questions for AI workloads.
- Runs a full cross-pillar AWS Well-Architected review from code, IaC and configs
- Produces evidence-backed findings with risk assessment and prioritized remediation
- Includes an agentic-AI lens (AGENTSEC, AGENTREL, AGENTPERF, AGENTOPS, AGENTCOST)
Wa Review by the numbers
- 365 all-time installs (skills.sh)
- Ranked #399 of 1,039 Cloud & Infrastructure skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
wa-review capabilities & compatibility
- Capabilities
- security assessment · reliability improvement plan · performance efficiency · operational excellence · sustainability optimization
- Works with
- aws
- Use cases
- security audit · devops
- Pricing
- Free
What wa-review says it does
Perform a full AWS Well-Architected Framework review by analyzing code, IaC, and configurations to produce evidence-backed findings with risk assessment and prioritized remediation.
comprehensive architecture review
npx skills add https://github.com/aws-samples/sample-well-architected-skills-and-steering --skill wa-reviewAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 365 |
|---|---|
| repo stars | ★ 234 |
| Last updated | August 4, 2026 |
| Repository | aws-samples/sample-well-architected-skills-and-steering ↗ |
What it does
Run a comprehensive cross-pillar AWS Well-Architected review of a workload from its code and IaC.
Who is it for?
a comprehensive all-pillars Well-Architected review of an AWS workload
Skip if: single-pillar deep-dive when a specific pillar skill exists, learning WA concepts or generating visual artifacts, creating architecture decision records, migration readiness assessment
When should I use this skill?
you want a comprehensive cross-pillar Well-Architected review
What you get
A full cross-pillar WA review with evidence-backed findings, risk assessment and prioritized remediation.
- cross-pillar evidence-backed findings
- risk assessment
- prioritized remediation plan
By the numbers
- bundles an agentic-ai lens with 7 AGENTSEC, 8 AGENTREL and 7 AGENTPERF reference files
- version 2.1.0
Files
{
"skill_name": "wa-review",
"evals": [
{
"id": 1,
"prompt": "I have a serverless e-commerce app on AWS using API Gateway, Lambda, DynamoDB, S3, and CloudFront. It handles about 10k orders per day. Can you do a Well-Architected review?",
"expected_output": "A systematic 307-BP-level Well-Architected review with per-question assessment table (all 57 questions), BP ID citations, pillar scorecard, risk matrix, Eisenhower prioritization, and serverless-specific findings.",
"assertions": [
"The output includes a per-question assessment table covering all 57 WA questions (OPS 1-11, SEC 1-11, REL 1-13, PERF 1-5, COST 1-11, SUS 1-6) with Status and Risk Level columns",
"Findings cite specific Best Practice IDs (format like SEC03-BP02, REL06-BP01, COST05-BP03) demonstrating BP-level evaluation",
"The output includes a pillar scorecard with numerical scores (1-5) per pillar",
"Risk assessment uses Impact x Likelihood matrix producing Critical/High/Medium/Low classifications",
"The output includes an Eisenhower-matrix prioritized remediation plan with four quadrants (Do First, Plan, Delegate, Defer)",
"Findings include serverless-specific issues referencing Lambda cold starts, DynamoDB capacity modes, API Gateway throttling, or CloudFront caching"
],
"process_assertions": [
"Response covers all 57 questions (not just 5-10 high-level themes)",
"Findings are backed by specific BP IDs, not just pillar-level comments",
"A prioritized remediation plan using Eisenhower matrix is included",
"Architecture overview or discovery summary is presented before evaluation"
],
"knowledge_assertions": [
{
"claim": "Lambda cold start optimization is addressed under PERF",
"source": "AWS Well-Architected Performance Efficiency Pillar - PERF 1/PERF 3",
"rationale": "Serverless workloads must address cold start latency as a performance concern"
},
{
"claim": "DynamoDB on-demand vs provisioned capacity is evaluated under COST",
"source": "AWS Well-Architected Cost Optimization Pillar - COST 7/COST 8",
"rationale": "10k orders/day warrants evaluation of capacity mode and pricing model"
}
]
},
{
"id": 2,
"prompt": "Review my architecture: we have a monolithic Java app on a single EC2 instance, MySQL on RDS single-AZ, no backups configured, SSH access with shared keys, no monitoring besides CloudWatch basic metrics. It's a customer-facing SaaS product.",
"expected_output": "A review with 57-question table showing majority 'Not Implemented', BP-level citations for critical gaps, risk matrix showing multiple Critical/High findings, low pillar scores (1-2), and Eisenhower prioritization recognizing business criticality mismatch.",
"assertions": [
"Per-question assessment table covers all 57 questions with majority marked Not Implemented or Partially Implemented",
"BP IDs cited for critical gaps: REL02 (network topology), REL11 (backups), SEC03 (permissions/shared keys), SEC08 (compute protection), OPS06 (observability)",
"Risk assessment: single EC2 = Critical (Severe x High), no backups = High (Severe x Medium), shared SSH keys = Critical (Severe x High), single-AZ RDS = High (Severe x Medium)",
"Pillar scorecard shows low scores (1-2) across most pillars",
"Eisenhower Do First quadrant includes: enable backups, replace SSH keys with SSM/IAM",
"Review recognizes business criticality mismatch — customer-facing SaaS with minimal reliability",
"Recommendations are organized by Eisenhower quadrant (Do First, Plan, Delegate, Defer)"
]
},
{
"id": 3,
"prompt": "Can you do a quick WA review? We use ECS Fargate with ALB, Aurora PostgreSQL multi-AZ, ElastiCache Redis, CloudFront, WAF, GuardDuty, and deploy via CDK Pipelines with canary deployments. We have CloudWatch dashboards, X-Ray tracing, and automated scaling. Savings Plans are in place.",
"expected_output": "A quick review covering all 57 questions at question level with high maturity scores, acknowledging strengths, no manufactured Critical findings, and suggesting only advanced improvements.",
"assertions": [
"Per-question assessment covers all 57 questions at question level (quick review mode)",
"Pillar scorecard shows high maturity scores (3-5 range)",
"Does NOT classify majority of findings as Critical — architecture is solid with multi-AZ, WAF, GuardDuty, canary deployments",
"Prominently acknowledges existing strengths: canary deployments, multi-AZ Aurora, WAF, GuardDuty, X-Ray, automated scaling, Savings Plans",
"Suggests advanced improvements: chaos engineering, multi-region DR, game days, sustainability, SLA-based alerting",
"Includes Eisenhower-matrix or equivalent prioritized remediation plan"
]
},
{
"id": 4,
"prompt": "Review only the Security and Reliability pillars for my workload: API Gateway with Lambda authorizer, DynamoDB with encryption at rest, S3 buckets for user uploads, VPC with public and private subnets, and NAT Gateway. No WAF, no GuardDuty, single-AZ RDS for metadata, no DLQ on SQS.",
"expected_output": "A pillar-scoped review evaluating ONLY Security (SEC 1-11) and Reliability (REL 1-13) with BP citations, without findings for other pillars.",
"assertions": [
"Review is scoped to ONLY Security and Reliability — does NOT produce findings for Cost, Performance, Sustainability, or Operational Excellence",
"Per-question table covers the 24 scoped questions (SEC 1-11, REL 1-13) with Status and Risk Level",
"BP IDs cited: SEC04 (detective controls/GuardDuty), SEC05 (network protection/WAF), REL10 (fault isolation/single-AZ RDS), and DLQ gap referenced as REL06 or REL07",
"Risk assessment: no WAF = Medium, no GuardDuty = Medium, single-AZ RDS = High, no DLQ = High",
"Eisenhower prioritization covers only the scoped findings",
"Pillar scorecard shows only Security and Reliability scores (not all 6)"
]
},
{
"id": 5,
"prompt": "WA review for our GenAI application: we use Bedrock with Claude for inference, a RAG pipeline with OpenSearch Serverless for vector storage, Lambda for orchestration, S3 for document ingestion, and DynamoDB for conversation history. We have no guardrails, no content filtering, no model evaluation pipeline, and prompts are stored in plaintext in the code.",
"expected_output": "A full review with core 57-question assessment PLUS Generative AI lens applied separately, citing both core BP IDs and GenAI lens references (GENSEC, GENOPS, etc.).",
"assertions": [
"Core framework: per-question table covers all 57 WA questions evaluated FIRST before lens",
"Lens identification: explicitly identifies Generative AI lens applies and loads lens-specific questions",
"BP citations from BOTH core (SEC01, SEC06, OPS04) AND GenAI lens (GENSEC01-06, GENOPS01-05)",
"GenAI-specific findings: no guardrails = High, no content filtering = High, no model eval pipeline = Medium, prompts in plaintext = High",
"Lens findings in SEPARATE section after core framework findings",
"Eisenhower prioritization covers both core and lens findings",
"Pillar scorecard for core 6 pillars included"
]
}
]
}
{
"skill_name": "wa-review",
"prompts": [
{"text": "do a full Well-Architected review of my workload", "should_trigger": true},
{"text": "comprehensive architecture review across all pillars", "should_trigger": true},
{"text": "evaluate our infrastructure against the WA Framework", "should_trigger": true},
{"text": "WA review of our ECS application", "should_trigger": true},
{"text": "cross-pillar analysis of our serverless architecture", "should_trigger": true},
{"text": "architecture health check covering security reliability cost performance", "should_trigger": true},
{"text": "assess our workload against all 57 WA questions", "should_trigger": true},
{"text": "Well-Architected Framework evaluation for our platform", "should_trigger": true},
{"text": "review our architecture holistically", "should_trigger": true},
{"text": "do a complete WA assessment before our annual review", "should_trigger": true},
{"text": "deep-dive into our IAM policies and encryption", "should_trigger": false},
{"text": "identify single points of failure and recovery gaps", "should_trigger": false},
{"text": "optimize our AWS costs and right-size instances", "should_trigger": false},
{"text": "improve database query performance", "should_trigger": false},
{"text": "reduce our workload's carbon footprint", "should_trigger": false},
{"text": "assess CI/CD pipeline and observability coverage", "should_trigger": false},
{"text": "plan our migration from on-premises to AWS", "should_trigger": false},
{"text": "create an ADR for choosing between DynamoDB and Aurora", "should_trigger": false},
{"text": "teach me the Well-Architected pillars and design principles", "should_trigger": false},
{"text": "generate a WA improvement roadmap diagram", "should_trigger": false}
]
}
{
"version": "2.1.0",
"organization": "AWS",
"date": "June 2026",
"abstract": "Perform a full AWS Well-Architected Framework review by analyzing code, IaC, and configurations to produce evidence-backed findings with risk assessment and prioritized remediation.",
"references": [
"https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html"
],
"triggers": [
"full Well-Architected review",
"comprehensive architecture review",
"all pillars assessment",
"WA review",
"cross-pillar analysis",
"architecture health check",
"workload assessment",
"Well-Architected Framework evaluation"
],
"not_for": [
"single-pillar deep-dive when a specific pillar skill exists (use security-assessment, reliability-improvement-plan, cost-optimization-review, performance-efficiency, sustainability-optimization, or operational-excellence instead)",
"learning WA concepts or generating visual artifacts (use wa-builder instead)",
"creating architecture decision records (use architecture-decision-record instead)",
"migration readiness assessment (use migration-readiness instead)"
],
"metadata": {
"service": [
"well-architected"
],
"task": [
"review",
"assess",
"audit"
],
"persona": [
"solutions-architect",
"developer",
"platform-engineer"
],
"workload": [
"any"
]
}
}
AGENTCOST01
Pillar: Unknown Best Practices: 4
---
AGENTCOST01-BP01 Use the reflection pattern to design efficient agent reasoning loops
Unbounded reasoning loops consume tokens unpredictably and can result in higher than expected token consumption for routine tasks. A bounded reflection pattern gives you predictable token budgets and preserves decision quality.
Desired outcome:
- You have explicit termination conditions for every agent: a maximum iteration count, a
confidence threshold, and a per-session token budget.
- You apply reflection selectively, triggering full self-correction only when initial
output quality falls below a threshold.
- You track per-cycle token consumption and decision quality so termination parameters
can be tuned from data rather than guesswork.
Common anti-patterns:
- Running agents without iteration limits or cost caps, allowing indefinite token
consumption without progress toward the task.
- Applying expensive reflection and self-correction to every output, regardless of
whether the initial answer was already good.
- Operating without per-cycle token instrumentation, so no one can tell which reasoning
phase drives cost.
- Using fixed iteration counts instead of confidence thresholds, which either wastes
tokens on unnecessary iterations or cuts off complex reasoning prematurely.
- Building reflection patterns without budget guardrails, so unbounded loops consume
tokens before alerts fire.
Benefits of establishing this best practice:
- Predictable token consumption through bounded reasoning cycles with explicit
termination conditions.
- Selective reflection preserves decision quality for ambiguous cases while reducing
token waste on straightforward tasks.
- Cost-quality baselines reveal which reasoning patterns deliver the best trade-offs,
enabling data-driven tuning of thresholds.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
Every reflection loop assumes that another iteration will improve the answer more than it costs, which works with ambiguous tasks but often loses value on straightforward ones. Without that contract, agents reflect on every output regardless of whether reflection improves quality. The discipline is to emit a structured confidence signal alongside each action, inspect it in the orchestration layer, and short-circuit the loop when confidence clears a threshold. Otherwise the loop runs until it hits a hard iteration ceiling, which is both the slowest and most expensive outcome for the common case.
Enforcement matters as much as the contract. Iteration caps expressed only in the system prompt can drift past under adversarial inputs or prompt injections. Amazon Bedrock AgentCore Policy applies Cedar policies at the Amazon Bedrock AgentCore Gateway boundary, so iteration and token limits are rejected at the traffic layer rather than noticed after they're exceeded. Amazon Bedrock AgentCore Runtime provides session-isolated execution and consumption-based pricing, so each session carries its own budget and one runaway session doesn't corrupt accounting for others.
Selective reflection separates ambiguity handling from cheaper routine work. Score the initial output against a lightweight rubric, a small model or heuristic, and gate full reflection on that score. Tag reflection outcomes with the task category so you can see where reflection consistently improves quality and where it adds cost with no benefit. Categories that never benefit from reflection should have the trigger disabled entirely. Amazon Bedrock AgentCore Evaluations supports LLM-as-a-Judge assessment of decision quality, which gives you an objective confidence signal rather than a self-reported one from the agent being evaluated.
The plan, execute, verify, and reflect phases within a reflection cycle have different reasoning intensities. Routing planning and verification to smaller, faster models while reserving the largest model for execution captures cumulative savings on the frequent low-cost phases, offsetting the higher per-token cost of the infrequent high-intensity phase.
Implementation steps
- Define explicit termination conditions per agent: Set a
maximum iteration count, a confidence threshold, and a per-session token budget, and enforce them through Amazon Bedrock AgentCore Policy Cedar policies at the AgentCore Gateway boundary so enforcement happens at the traffic layer rather than in application code.
- Instrument per-cycle token consumption: Enable [Amazon
Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html) to capture per-session token counts through OpenTelemetry, and configure Amazon CloudWatch alarms on anomalous per-cycle patterns.
- Establish objective confidence thresholds: Configure
Amazon Bedrock AgentCore Evaluations to score decision quality through LLM-as-a-Judge, and anchor early-termination thresholds to measured quality rather than self-reported confidence.
- Gate reflection on initial output quality: Score each
initial output with a lightweight rubric and trigger the full reflection pass only when the score falls below a configurable threshold, keeping reflection overhead off the straightforward cases.
- Recalibrate thresholds on a cadence: Review
cost-quality baselines monthly (or quarterly for stable workloads) and adjust confidence thresholds, iteration limits, and reflection triggers based on the distribution of observed outcomes.
Resources
Related best practices:
- [AGENTCOST01-BP02 Optimize multi-agent collaboration cost
through efficient handoff patterns](agentcost01-bp02.html)
- [AGENTCOST01-BP03 Implement cost-effective patterns like
hybrid supervisor for multi-agent coordination](agentcost01-bp03.html)
- [AGENTCOST02-BP01 Architect tiered model
selection for cost-performance optimization](agentcost02-bp01.html)
- [AGENTCOST07-BP01 Implement automated cost
controls with intelligent cutoffs](agentcost07-bp01.html)
Related documents:
- [Amazon Bedrock
AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html)
Bedrock AgentCore Policy](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html)
- Amazon Bedrock AgentCore Evaluations
- [Evaluate
models in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation-judge.html)
- [Agentic AI
patterns and workflows on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-patterns/introduction.html)
Related videos:
- [AWS 2025 - AgentCore
Observability: Monitor and Debug with OpenTelemetry](https://www.youtube.com/watch?v=wWQgawUPr1k)
- [AWS re:Invent 2024 - Balance
cost, performance & reliability for AI at enterprise scale (AIM3304)](https://www.youtube.com/watch?v=Lwvv8Q33eeE)
- [AWS re:Invent 2024 -
Sustainable and cost-efficient generative AI with agentic workflows (AIM333)](https://www.youtube.com/watch?v=tFiDkSG2ess)
Related examples:
Related workshops:
Related services:
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost01-bp01.html
---
AGENTCOST01-BP02 Optimize multi-agent collaboration cost through efficient handoff patterns
In multi-agent systems, the largest hidden cost is redundant context that travels with every handoff. Structured handoff messages and shared memory keep coordination cost proportional to task complexity rather than conversation length.
Desired outcome:
- You have handoff messages carrying only the task specification,
relevant facts, and constraints, not full conversation transcripts.
- You have collaborating agents sharing common context through a
managed memory layer instead of re-transmitting it on every handoff.
- You track per-handoff and per-workflow coordination costs as
distinct metrics.
Common anti-patterns:
- Passing full conversation history in every handoff, causing
input token cost to scale with conversation length regardless of relevance to the receiving agent.
- Building deep supervisor hierarchies where multi-level nesting
adds orchestration model invocations at each layer, so coordination cost exceeds execution value.
- Skipping shared memory for collaborating agents, re-transmitting
common facts in every agent's context window and causing linear cost growth with agent count.
- Running multi-agent workflows without handoff cost tracking,
reducing the risk of identification of workflows where coordination overhead has grown disproportionate to the execution work.
Benefits of establishing this best practice:
- Coordination overhead stays proportional to task complexity
rather than conversation length or agent count.
- Shared memory removes redundant context transmission, reducing
per-handoff token cost.
- Per-handoff cost visibility enables data-driven tuning of
multi-agent interaction patterns.
Level of risk exposed if this best practice is not established: High
Implementation guidance
The most expensive thing an agent can send is context the receiver already has (or doesn't need). Every handoff that copies the full conversation across the boundary pays again for information that never changed. Treat handoff messages as structured summaries containing the task specification, relevant facts, and constraints the worker must respect. Amazon Bedrock AgentCore Memory enables write-once, read-many patterns where one agent stores a fact under a session ID and actor ID, and every collaborator reads it without re-embedding it in their own prompt. Amazon Bedrock AgentCore Gateway adds the corresponding discipline on the tool side, using MCP-compatible Semantic Tool Selection to present only tools relevant to the current intent rather than the full catalog.
Context distillation means that a small model call or a Lambda function can compress incoming context into the minimum sufficient information for the next agent's task before the handoff crosses the boundary. The cost of the distillation call is typically less than the cost of repeatedly transmitting untrimmed context through deeper workflows.
Every supervisor-worker layer adds at least one inference for delegation and one for synthesis. Hierarchies deeper than three levels compound that overhead quickly, and most deep hierarchies can be flattened by replacing intermediate supervisors with direct worker-to-worker communication through the AgentCore Runtime Agent-to-Agent protocol. The diagnostic metric is the orchestration-to-execution token ratio. Supervisors should consume no more than 20% of total workflow tokens, leaving 80% for workers doing execution. A ratio that drifts above 20% means coordination has grown disproportionate to work.
Visibility is a prerequisite for these patterns. Amazon Bedrock AgentCore Observability provides distributed tracing so agent-to-agent communication costs appear as their own category rather than hidden inside aggregate workflow cost. Amazon Bedrock AgentCore Evaluations runs in real time against live tool-call traces and as offline test suites in CI/CD pipelines, so redundant or unnecessary invocations are caught early.
Implementation steps
- **Design structured handoff
messages:** Replace full conversation history with a summary object containing the task specification, relevant facts, and the constraints the receiving agent must respect. Version the message schema so receivers can reject malformed handoffs.
- **Insert context distillation at
boundaries:** Add a small-model call or Lambda function that extracts minimum sufficient context before each handoff, so input tokens at transitions reflect current task needs rather than accumulated history.
- **Configure shared memory with
ownership rules:** Provision Amazon Bedrock AgentCore Memory accessible to all collaborating agents, and document which agent owns writes to each namespace so shared state has a clear provenance.
- Flatten deep hierarchies:
Audit multi-agent workflows for supervisor-worker depth greater than three levels, and replace intermediate supervisors with direct worker-to-worker communication through the AgentCore Runtime Agent-to-Agent protocol where the routing can be made explicit.
- **Expose specialized agents through
Gateway:** Publish agents as tools through Amazon Bedrock AgentCore Gateway MCP server capabilities, and turn on Semantic Tool Selection so collaborating agents see only tools relevant to the current request.
- **Evaluate tool-call efficiency in CI
and in production:** Run Amazon Bedrock AgentCore Evaluations against live tool-call traces to flag inefficient usage at runtime, and against offline test suites in the CI/CD pipeline to catch regressions before deployment.
- **Track the orchestration-to-execution
ratio:** Tag every invocation with workflow-id and agent-role, build CloudWatch dashboards that display the supervisor-to-worker token ratio per workflow, and configure AWS Budgets alerts when orchestration overhead exceeds 20% of total workflow token cost.
Resources
Related best practices:
- [AGENTCOST01-BP01 Use
the reflection pattern to design efficient agent reasoning loops](agentcost01-bp01.html)
- [AGENTCOST01-BP03
Implement cost-effective patterns like hybrid supervisor for multi-agent coordination](agentcost01-bp03.html)
- [AGENTCOST01-BP04 Design
agent hierarchies and delegation patterns that reduce coordination overhead](agentcost01-bp04.html)
- [AGENTCOST05-BP02
Implement distributed cost tracing for multi-agent workflows](agentcost05-bp02.html)
Related documents:
- [Amazon
Bedrock AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)
- [Amazon
Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html)
- [Amazon
Bedrock AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html)
- [Amazon
Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html)
- [Amazon
Bedrock AgentCore Evaluations](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html)
- [Agentic
AI patterns and workflows on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-patterns/introduction.html)
Related videos:
- AWS 2025 - AgentCore Deep Dive: Memory
- [AWS re:Invent 2024 - Balance cost, performance & reliability
for AI at enterprise scale (AIM3304)](https://www.youtube.com/watch?v=Lwvv8Q33eeE)
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Multi-agent tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/01-AgentCore-runtime/03-advanced-concepts)
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Evaluations tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/07-AgentCore-evaluations)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost01-bp02.html
---
AGENTCOST01-BP03 Implement cost-effective patterns like hybrid supervisor for multi-agent coordination
Many multi-agent workflows pay for AI reasoning at the coordination layer for decisions that rules could make at no additional charge. Matching each orchestration decision to the cheapest mechanism capable of handling it removes that hidden cost.
Desired outcome:
- You select orchestration patterns from workflow determinism
analysis rather than defaulting to AI supervision.
- You have deterministic routing running without model
invocations, and AI supervisors reserved for genuinely ambiguous cases that need natural language understanding.
- You track orchestration cost separately from worker cost and
maintain documented pattern-selection criteria.
Common anti-patterns:
- Using AI supervisors for deterministic workflows, invoking
expensive foundation models for routing decisions that straightforward rules handle.
- Defaulting to AI supervision without evaluating whether the
routing logic follows explicit rules.
- Tracking only aggregate workflow cost without decomposing
orchestrator compared to worker spend, which hides disproportionate coordination overhead.
Benefits of establishing this best practice:
- Rule-based routing handles deterministic branches without model
invocations, reducing per-routing-decision cost to near zero.
- Hybrid patterns match each routing decision to the cheapest
capable mechanism.
- Documented pattern-selection criteria help prevent
over-provisioning AI supervision for new workflows.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
Workflow determinism is a property, not an assumption. At every orchestration point, the routing decision is either a selection across a finite, enumerable set of conditions (task type, output classification, error code) or a judgment call across an open-ended input space. The first class costs nothing to route with rules, and the second requires model reasoning. Most multi-agent workflows contain both, but teams often pay for AI supervision across the whole workflow because the pattern defaults that way. Conducting the determinism analysis up front is the difference between spending model tokens on routing that a conditional could handle and spending them only where the input genuinely demands natural-language interpretation.
Enforcement happens outside the agent code. Amazon Bedrock AgentCore Policy runs Cedar policies at the Amazon Bedrock AgentCore Gateway boundary, applying deterministic routing rules based on task attributes, user identity, or tool requirements without invoking an inference. Worker agents deploy on Amazon Bedrock AgentCore Runtime at the leaf nodes where reasoning actually happens. Keeping routing and reasoning on separate rails lets each one evolve independently and be monitored on its own metrics.
For partially deterministic routing, a tiered hybrid pattern helps you align costs. A lightweight classifier (a small Amazon Bedrock model or a rule-based heuristic) attempts rule-based routing first and escalates to the full AI supervisor only when its confidence falls below a configured threshold. The escalation rate is the signal for whether the tier is tuned correctly. If the rate is too high, the classifier needs refinement. If it is too low, the supervisor is over-provisioned and the classifier can absorb more cases.
Quantitative thresholds provide rule-based routing for workflows with fewer than ten deterministic branches, a lightweight classifier for routing across ten to fifty categories, and AI supervisors only for unbounded category spaces that require natural-language understanding. The orchestration overhead ratio (supervisor tokens divided by total workflow tokens) is the ongoing diagnostic. When it drifts above the baseline, the pattern needs reassessment, not a larger budget.
Implementation steps
- **Conduct workflow determinism
analysis:** At each orchestration point in the workflow, classify the routing decision as fully deterministic, partially deterministic, or open-ended, and record the rationale as an architectural decision record so downstream reviewers can audit why each pattern was chosen.
- **Apply Cedar policies for
deterministic routing:** Configure Amazon Bedrock AgentCore Policy with Cedar policies at Amazon Bedrock AgentCore Gateway for every fully deterministic branch, so these routing decisions run without model invocations.
- **Insert a lightweight classifier for
partially deterministic routing:** Deploy a small model or rule-based heuristic that attempts rule-based routing first and escalates to a full AI supervisor only when its confidence falls below a configurable threshold, and log the escalation rate as a tuning signal.
- **Separate orchestration cost from
worker cost:** Configure Amazon Bedrock AgentCore Observability to attribute tokens to orchestrator and worker tiers separately, calculate the orchestration overhead ratio per workflow, and alert when the ratio drifts above the baseline recorded for that pattern.
Resources
Related best practices:
- [AGENTCOST01-BP01 Use
the reflection pattern to design efficient agent reasoning loops](agentcost01-bp01.html)
- [AGENTCOST01-BP02
Optimize multi-agent collaboration cost through efficient handoff patterns](agentcost01-bp02.html)
- [AGENTCOST01-BP04 Design
agent hierarchies and delegation patterns that reduce coordination overhead](agentcost01-bp04.html)
- [AGENTCOST05-BP02
Implement distributed cost tracing for multi-agent workflows](agentcost05-bp02.html)
Related documents:
- [Amazon
Bedrock AgentCore Policy](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html)
- [Amazon
Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html)
- [Amazon
Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html)
- [Agentic
AI patterns and workflows on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-patterns/introduction.html)
Related videos:
- [AWS re:Invent 2024 - Balance cost, performance & reliability
for AI at enterprise scale (AIM3304)](https://www.youtube.com/watch?v=Lwvv8Q33eeE)
- [AWS re:Invent 2024 - Sustainable and cost-efficient generative AI
with agentic workflows (AIM333)](https://www.youtube.com/watch?v=tFiDkSG2ess)
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Policy tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/08-AgentCore-policy)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost01-bp03.html
---
AGENTCOST01-BP04 Design agent hierarchies and delegation patterns that reduce coordination overhead
Supervisor cost in agent hierarchies grows with the verbosity of capability descriptions and the frequency of check-ins. Compact manifests and autonomous workers keep coordination cost proportional to workflow complexity rather than step count.
Desired outcome:
- Your agent hierarchies use the shallowest orchestration
structure capable of managing the workflow.
- You have supervisor agents operating on compressed capability
manifests that minimize input tokens per routing decision.
- Your worker agents complete multi-step sub-tasks autonomously,
escalating to supervisors only for task assignment and result validation.
- You track orchestrator cost as a distinct category with a target
supervisor-to-worker cost ratio.
Common anti-patterns:
- Including verbose natural-language descriptions of every
worker's capabilities in routing prompts, which inflates token cost that then scales linearly with worker count.
- Requiring supervisor check-ins after each sub-step, which
multiplies coordination overhead when workers could complete multi-step work autonomously.
- Tracking only aggregate workflow cost without decomposing
orchestrator compared to worker expense, so disproportionate coordination overhead hides in the total.
Benefits of establishing this best practice:
- Compressed capability manifests reduce supervisor input-token
cost per routing decision.
- Autonomous workers remove supervisor round-trips for
intermediate decisions.
- Per-tier cost attribution surfaces optimization opportunities
where coordination overhead exceeds execution value.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
Supervisor cost has two main drivers: how expensive each routing decision is and how many times routing happens.
The first is controlled by manifest size. Supervisors that describe workers in paragraphs of natural language pay for those paragraphs on every routing call, and that cost scales linearly with worker count. Short, structured capability manifests (description, input schema, output schema, under 200 tokens each) cut this cost without sacrificing routing quality, because the supervisor doesn't need prose to choose between workers that have distinct schemas.
The second is controlled by context relay. When context flows from parent to worker through the supervisor, every byte of that context is transmitted twice: once into the supervisor, and once into the worker as part of the routing response. Amazon Bedrock AgentCore Memory removes that doubling by letting workers read shared context directly from memory using the session's actor ID and session ID, so the supervisor only routes rather than relays. Amazon Bedrock AgentCore Gateway reduces it further by supporting runtime tool discovery through Model Context Protocol, so the supervisor prompt doesn't need to enumerate every tool the workers can call. Amazon Bedrock AgentCore Policy controls which tools each worker is allowed to invoke autonomously, making it safe to shift decisions downward without losing governance.
Workers designed with sufficient tool autonomy and clear success criteria can complete multi-step sub-tasks, returning a single structured result with a confidence score. The supervisor then makes an efficient accept-or-reject decision rather than re-reasoning from scratch at each intermediate step. For workflows with repeatable decomposition patterns, a plan-then-execute approach compresses this further, where one supervisor invocation generates the full task plan, then workers execute the plan without further supervision.
Track the supervisor-to-worker cost ratio. Set a target (for example, supervisor tokens no more than 15% of worker tokens) and alert when it is exceeded. A breach typically signals that manifest compression, worker autonomy, or plan-then-execute adoption is needed.
Implementation steps
- **Compress worker capability
descriptions:** Replace natural-language capability descriptions with structured manifests (description, input schema, output schema) under 200 tokens each, and use Amazon Bedrock AgentCore Gateway runtime tool discovery to avoid listing tools in the supervisor prompt.
- **Redesign workers for autonomous
multi-step completion:** Give each worker sufficient tool autonomy and clear success criteria to complete its sub-task end-to-end, and require the worker to emit a confidence score in every response so the supervisor can make accept-or-reject decisions without re-reasoning.
- **Apply policy and shared memory for
direct context access:** Configure Amazon Bedrock AgentCore Policy through Gateway to enforce worker tool-access boundaries, and provision Amazon Bedrock AgentCore Memory so workers read shared context directly instead of receiving it relayed through the supervisor.
- **Track supervisor-to-worker cost
ratio:** Configure Amazon Bedrock AgentCore Observability to attribute tokens per tier, build Amazon CloudWatch dashboards showing the supervisor-to-worker ratio per workflow, and alert when the ratio exceeds a 15% target.
Resources
Related best practices:
- [AGENTCOST01-BP02
Optimize multi-agent collaboration cost through efficient handoff patterns](agentcost01-bp02.html)
- [AGENTCOST01-BP03
Implement cost-effective patterns like hybrid supervisor for multi-agent coordination](agentcost01-bp03.html)
- [AGENTCOST05-BP01
Establish agent-level reasoning cost tracking and attribution](agentcost05-bp01.html)
- [AGENTCOST05-BP02
Implement distributed cost tracing for multi-agent workflows](agentcost05-bp02.html)
Related documents:
- [Amazon
Bedrock AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html)
- [Amazon
Bedrock AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)
- [Amazon
Bedrock AgentCore Policy](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html)
- [Amazon
Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html)
- [Agentic
AI patterns and workflows on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-patterns/introduction.html)
Related videos:
- AWS 2025 - AgentCore Deep Dive: Gateway
- [AWS 2025 - AgentCore Observability: Monitor and Debug with
OpenTelemetry](https://www.youtube.com/watch?v=wWQgawUPr1k)
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Multi-agent tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/01-AgentCore-runtime/03-advanced-concepts)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost01-bp04.html
---
AGENTCOST02
Pillar: Unknown Best Practices: 4
---
AGENTCOST02-BP01 Architect tiered model selection for cost-performance optimization
Running every agent task on the largest available model inflates inference cost by an order of magnitude for work that smaller models handle correctly. Match each task to the cheapest model capable of acceptable quality, and escalate only when confidence drops.
Desired outcome:
- You have agent tasks classified into complexity tiers, with a
documented routing policy mapping each tier to a specific foundation model.
- You have cascading patterns that escalate to higher-cost models
only when a lower tier's confidence falls below threshold.
- You track cost-per-correct-response across tiers and refresh
routing decisions with the data rather than with intuition.
Common anti-patterns:
- Using the largest available model for all agent tasks without
assessing task complexity, inflating inference costs for routine operations.
- Hard-coding static model assignments without confidence-based
escalation, which either over-provisions routine tasks or under-provisions complex edge cases.
- Tracking aggregate costs without decomposing agent performance
by model tier, hiding opportunities to shift workloads to cheaper models.
- Failing to monitor customized model performance after switching
to a smaller tier, allowing cost savings to mask hidden quality degradation.
Benefits of establishing this best practice:
- Tiered selection reserves expensive models for genuinely complex
reasoning and routes routine tasks to cost-effective alternatives.
- Model cascading minimizes premium model invocations through
confidence-based escalation.
- Specialized models for domain-specific tasks deliver higher
accuracy at lower cost than general-purpose alternatives.
Level of risk exposed if this best practice is not established: High
Implementation guidance
Task complexity is an important property to measure. At every agent invocation, the reasoning you need is either lightweight (classification, format conversion, intent extraction), moderate (multi-step reasoning, summarization), or genuinely complex (open-ended analysis, multi-constraint optimization). These three classes map to different price points across the Amazon Bedrock model catalog, and treating them identically means you pay the complex-class price for every low-complexity task. Classifying upfront and routing accordingly is where most of the cost headroom sits.
A lightweight pre-classifier gives you that routing decision without invoking the main model first. Rule-based heuristics or a small model can analyze request characteristics like input length, structured or unstructured format, constraint count, and reasoning depth, assigning scores that map to tier thresholds (for example, below 0.3 for simple, 0.3 to 0.7 for moderate, above 0.7 for complex). The pre-classifier must cost less than the tier price differential to produce net savings on first-attempt routing. For multimodal tasks the principle extends further. Route document extraction to Amazon Bedrock Data Automation and audio interactions to Amazon Nova Sonic rather than sending raw images or audio through expensive general-purpose vision models.
Model cascading is a fallback mechanism when the classifier is uncertain. Have the lower-tier model return a structured response with a self-assessed confidence score and escalate to the next tier only when confidence falls below a threshold. Primary, secondary, and tertiary fallback chains catch timeouts and failures by moving up a tier rather than retrying the same one, improving completion rates without retry waste. Amazon Bedrock AgentCore Runtime is designed to support multiple frameworks and LLM providers, and Amazon Bedrock AgentCore Policy enforces guardrails that help prevent expensive model calls when task complexity doesn't justify the cost.
Pricing tier is independent of model size. Amazon Bedrock capacity, limits, and cost optimization documents Flex for development and testing at the lowest per-token cost, Standard for production, and Priority only for latency-sensitive user-facing interactions where throttling risk must be minimized. Batch inference offers up to 50% savings for non-time-sensitive workloads like report generation, training data preparation, or offline evaluation. For consistent high-volume traffic, Reserved Tier commitments provide 30 to 50% savings against on-demand pricing. With Amazon Bedrock AgentCore Evaluations, you can benchmark multiple model options against your actual task distribution, measuring cost-per-correct-response and refreshing the routing policy quarterly as new models become available.
Implementation steps
- **Classify agent tasks into complexity
tiers:** Document a model routing policy mapping each tier (simple, moderate, and complex) to a specific Amazon Bedrock model, and commit the policy as an architectural decision record so downstream reviewers can audit the rationale.
- **Select pricing tier per
environment:** Use Flex for development and testing, Standard for production, and Priority only for latency-sensitive user-facing agents, and evaluate Amazon Bedrock Reserved Tier commitments for consistent high-volume workloads.
- **Insert a task complexity
pre-classifier:** Deploy rule-based heuristics or a small-model call that scores each request on input length, structure, constraint count, and reasoning depth before the main invocation, and make sure the classifier costs less than the tier price differential.
- **Implement model cascading on
confidence:** Have each lower-tier response include a self-assessed confidence score, and escalate to the next tier when confidence falls below the configured threshold rather than retrying at the same tier.
- **Configure fallback chains per task
category:** Define primary, secondary, and tertiary model options, with automatic escalation on timeout or failure instead of retry, so transient failures move up a tier rather than repeating the same cost.
- **Route non-time-sensitive tasks to
batch inference:** Use Amazon Bedrock batch inference for report generation, data enrichment, and offline evaluation to capture up to 50% savings over on-demand pricing.
- **Benchmark specialized compared to
general-purpose models:** Run Amazon Bedrock AgentCore Evaluations on your actual task distribution, measuring cost-per-correct-response so routing choices are grounded in outcome data.
- **Review routing policies
quarterly:** Use AWS Cost Explorer and Amazon CloudWatch dashboards to inspect observed escalation rates, and adjust tier assignments when cascade escalation patterns indicate mis-tuned thresholds.
Resources
Related best practices:
- [AGENTCOST01-BP01
Use the reflection pattern to design efficient agent reasoning loops](agentcost01-bp01.html)
- [AGENTCOST01-BP04
Design agent hierarchies and delegation patterns that reduce coordination overhead](agentcost01-bp04.html)
- [AGENTCOST02-BP02 Cost
optimize token consumption through efficient prompt engineering](agentcost02-bp02.html)
- [AGENTCOST02-BP04
Implement model customization for long-term cost reduction](agentcost02-bp04.html)
- [AGENTCOST05-BP01
Establish agent-level reasoning cost tracking and attribution](agentcost05-bp01.html)
Related documents:
- [Amazon
Bedrock AgentCore Evaluations](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html)
- [Effective
cost optimization strategies for Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/effective-cost-optimization-strategies-for-amazon-bedrock/)
- [Use
Amazon Bedrock Intelligent Prompt Routing for cost and latency benefits](https://aws.amazon.com/blogs/machine-learning/use-amazon-bedrock-intelligent-prompt-routing-for-cost-and-latency-benefits/)
- [Optimizing
cost for using foundational models with Amazon Bedrock](https://aws.amazon.com/blogs/aws-cloud-financial-management/optimizing-cost-for-using-foundational-models-with-amazon-bedrock/)
- [Economics
for agentic AI on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-economics/index.html)
- [Guidance
for Cost Analysis and Optimization with Amazon Bedrock Agents](https://aws.amazon.com/solutions/guidance/cost-analysis-and-optimization-with-amazon-bedrock-agents/)
- [Agentic
AI patterns and workflows on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-patterns/introduction.html)
- [Amazon
Bedrock model pricing](https://aws.amazon.com/bedrock/pricing/)
- [Amazon
Bedrock capacity, limits, and cost optimization](https://docs.aws.amazon.com/bedrock/latest/userguide/capacity-limits-cost-optimization.html)
- [Amazon
Bedrock batch inference](https://docs.aws.amazon.com/bedrock/latest/userguide/batch-inference.html)
Related videos:
- [AWS re:Invent 2024 - Balance cost, performance & reliability
for AI at enterprise scale (AIM3304)](https://www.youtube.com/watch?v=Lwvv8Q33eeE)
- [AWS re:Invent 2024 - Mastering model choice: The 3-step Amazon
Bedrock advantage (AIM391)](https://www.youtube.com/watch?v=Vu91YwZxskY)
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Evaluations tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/07-AgentCore-evaluations)
Related tools:
- [Strands
Agents Model Providers](https://strandsagents.com/docs/user-guide/concepts/model-providers/)
Related services:
- [Amazon
Bedrock](https://aws.amazon.com/bedrock/)
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost02-bp01.html
---
AGENTCOST02-BP02 Cost optimize token consumption through efficient prompt engineering
Every token in a system prompt is paid for on every invocation, so prompt bloat compounds linearly with traffic. Compressing system prompts, tool descriptions, and output formats makes the fixed cost of each agent call proportional to the decision it has to make, not the verbosity of its instructions.
Desired outcome:
- You have agent system prompts compressed to the minimum tokens
needed for accurate task completion.
- You have tool descriptions presented dynamically based on the
current task rather than transmitted in full on every call.
- You constrain output length explicitly so verbose responses
don't compound across multi-turn reasoning.
- You version prompts and track cost-per-task per version so
efficiency changes are measurable over time.
Common anti-patterns:
- Writing verbose system prompts with lengthy persona descriptions
and redundant explanations, inflating the fixed token cost on every invocation.
- Including every tool description in every invocation regardless
of task relevance, which inflates input tokens when only a subset of tools applies.
- Allowing unconstrained output length without formatting
directives, enabling verbose responses that compound across multi-turn reasoning cycles.
- Treating prompts as uncontrolled strings rather than versioned
artifacts, so regressions in token efficiency go unnoticed until a billing review.
Benefits of establishing this best practice:
- Fixed-cost reductions from prompt compression compound across
every agent invocation in high-volume deployments.
- Dynamic tool loading transmits only task-relevant tools,
reducing tool description overhead in proportion to catalog size.
- Prompt versioning with token tracking makes compression an
ongoing, measurable practice rather than a one-off cleanup.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
The system prompt is the largest fixed cost in every model invocation, which means every unnecessary sentence is paid for again each time the agent is called. Start by auditing prompts with Amazon Bedrock AgentCore Observability to measure token footprints, then compress systematically. Replace verbose instructions with structured directives, tighten role definitions, and remove redundant explanations.
Tool descriptions behave the same way. If the prompt carries the full tool catalog even when only three tools are relevant, you are paying for the rest of the catalog on every call. Amazon Bedrock AgentCore Gateway uses MCP-based Semantic Tool Selection to present only the tools relevant to the current intent, and Amazon Bedrock AgentCore Memory manages conversation state across multi-turn sessions so you don't pay for manual history concatenation.
In your context window, allocate tokens across the system prompt (20 to 30%), user context (30 to 40%), few-shot examples (10 to 20%), and agent scratchpad (20 to 30%), and adjust based on your agent's reasoning patterns. For few-shot examples in particular, test whether the model performs well zero-shot before paying for examples on every call. When examples are needed, identify the minimum count that maintains task accuracy against the quality baseline. Two or three examples are typically enough, and dynamic example selection from a semantic index keeps only the relevant ones in context.
Output length is the last thing to adjust. Explicit formatting directives in the system prompt (response structure, maximum length) directly control output token costs. Treat prompts as versioned artifacts. Record token count, task success rate, and cost-per-task for each version using AgentCore Observability telemetry, and establish a monthly review cadence that tracks cumulative savings in AWS Cost Explorer.
Implementation steps
- **Audit and compress system
prompts:** Use Amazon Bedrock AgentCore Observability to measure token footprints for every prompt, then apply compression to minimize prompt size while maintaining decision accuracy.
- **Present tools dynamically through
Gateway:** Use Amazon Bedrock AgentCore Gateway Semantic Tool Selection to present only relevant tools per invocation, and compress tool descriptions to tool name, one-sentence description, and concise parameter schema.
- Constrain output length:
Add explicit output formatting directives to the system prompt and configure model-specific token limit parameters to enforce hard caps on response size.
- **Use managed memory for multi-turn
context:** Configure Amazon Bedrock AgentCore Memory so conversation state is maintained automatically instead of re-transmitted as full history.
- **Reduce few-shot example
overhead:** Evaluate whether each agent task needs examples at all, then reduce to the minimum effective count of two to three. Load examples dynamically from an Amazon S3-hosted library using semantic similarity retrieval.
- **Version prompts and track
efficiency:** Record token count and task success rate per prompt version, and establish a monthly optimization review cadence that tracks cumulative savings against cost-per-task targets.
Resources
Related best practices:
- [AGENTCOST01-BP01
Use the reflection pattern to design efficient agent reasoning loops](agentcost01-bp01.html)
- [AGENTCOST02-BP01
Architect tiered model selection for cost-performance optimization](agentcost02-bp01.html)
- [AGENTCOST02-BP03 Use
intelligent caching to reduce redundant model invocations](agentcost02-bp03.html)
Related documents:
- [Amazon
Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html)
- [Amazon
Bedrock AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html)
- [Amazon
Bedrock AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)
- [Economics
for agentic AI on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-economics/index.html)
Related videos:
- [AWS re:Invent 2024 - Sustainable and cost-efficient generative AI
with agentic workflows (AIM333)](https://www.youtube.com/watch?v=tFiDkSG2ess)
- [Strands
Tools: Building Custom AI Agents with Python](https://www.youtube.com/watch?v=EGhIZCfOvG4)
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Runtime tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/01-AgentCore-runtime)
Related tools:
- [Strands
Agents Custom Tools](https://strandsagents.com/docs/user-guide/concepts/tools/custom-tools/)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost02-bp02.html
---
AGENTCOST02-BP03 Use intelligent caching to reduce redundant model invocations
Agents repeat work constantly: identical prompts, semantically equivalent requests, the same planning steps across similar tasks. Caching at the prompt, semantic, and plan-template layers changes repetition from a recurring expense into a one-time cost paid on the first invocation.
Desired outcome:
- You have prompt caching enabled for stable system prompts so the
cacheable prefix is reused across invocations at reduced rates.
- You have a semantic cache that serves responses for functionally
equivalent requests above a configurable similarity threshold.
- You have plan templates cached and instantiated for recurring
task patterns rather than regenerated each time.
- You track cache hit rates and cost savings per caching layer.
Common anti-patterns:
- Transmitting identical system prompts and tool descriptions on
every invocation at full input token cost rather than cached prefix rates.
- Using exact-match lookups when functionally equivalent requests
use different wording, causing cache misses on semantically identical tasks.
- Applying one cache TTL across all task types without
distinguishing static reference data from time-sensitive information, returning stale responses that degrade quality.
- Deploying customized models without monitoring cache-assisted
performance, missing opportunities to validate that expected cost reductions actually materialize.
Benefits of establishing this best practice:
- Prompt caching reduces input token costs by reusing cached
system instructions across invocations at reduced rates.
- Semantic caching helps prevent redundant reasoning by serving
cached responses for functionally equivalent tasks.
- Plan template reuse reduces model invocations for the planning
phase of recurring task patterns.
Level of risk exposed if this best practice is not established: High
Implementation guidance
Caching for agents works at three distinct layers, and each layer has a different failure mode.
Amazon Bedrock prompt caching is the highest-impact layer for agents with large stable system prompts. Amazon Bedrock stores the key-value state of the cached prefix and reuses it at reduced rates. Design so that the cacheable prefix (system prompt, tool descriptions) is stable across invocations, because any dynamic content mixed in invalidates the cache. Refactor to move user-specific or session-specific content out of the cacheable prefix.
Semantic caching addresses the idea that two requests that mean the same thing are rarely identical in wording. Generate an embedding of each incoming request with a lightweight model and query Amazon OpenSearch Service Serverless for similar prior requests above a configurable threshold such as cosine similarity greater than 0.95. The threshold helps you tune, as higher values reduce false positives but lower hit rates, and the right value depends on how much response variance your agent tolerates. Store cache entries with TTLs calibrated to each task type's freshness requirements, so reference data cached for hours doesn't pollute tasks that need up-to-date market or inventory information.
Don't overlook plan template caching. Agent planning outputs are highly repeatable for recurring task patterns, like an onboarding checklist, a support triage decomposition, or a reporting workflow plan. Store these plans keyed by task type and input parameter signature, and instantiate cached templates with current parameters rather than regenerating new plans each time. Amazon Bedrock AgentCore Memory manages conversation state by extracting and persisting key information, reducing input token costs from repeated history transmission.
Cache correctness depends on invalidation. Event-driven invalidation purges stale entries the moment source data changes, which is what makes aggressive caching safe for moderately volatile data. Measure impact with AWS Cost Explorer and Amazon CloudWatch integrated with Amazon Bedrock AgentCore Observability, and alarm when hit rates fall below targets.
Implementation steps
- **Enable prompt caching for stable
prefixes:** Turn on Amazon Bedrock prompt caching for agents with system prompts larger than 1,000 tokens, and refactor the prompt to move dynamic content out of the cacheable prefix.
- **Deploy a semantic cache
layer:** Stand up an OpenSearch Serverless index with embedding-based similarity, configure similarity thresholds per task type, and set per-task TTLs. Accept quantization only when accuracy loss remains below two percent on task success rate.
- Cache plan templates: Key
plan templates by task type and input parameter signature, and perform a pre-invocation lookup before generating a new plan.
- **Use managed memory for session
state:** Configure Amazon Bedrock AgentCore Memory session identifiers so multi-turn conversation state is maintained without manual history concatenation.
- **Design event-driven invalidation and
monitor hit rates:** Wire event-driven cache invalidation to source data changes, and create CloudWatch dashboards that display hit rates across prompt, semantic, and plan-template caches with alarms when hit rates fall below target.
Resources
Related best practices:
- [AGENTCOST02-BP01
Architect tiered model selection for cost-performance optimization](agentcost02-bp01.html)
- [AGENTCOST02-BP02 Cost
optimize token consumption through efficient prompt engineering](agentcost02-bp02.html)
- [AGENTCOST03-BP01
Design cost-effective retrieval systems with tiered memory](agentcost03-bp01.html)
Related documents:
- [Amazon
Bedrock Prompt Caching](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html)
- [Effectively
use prompt caching on Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/effectively-use-prompt-caching-on-amazon-bedrock/)
- [Optimize
LLM response costs and latency with effective caching](https://aws.amazon.com/blogs/database/optimize-llm-response-costs-and-latency-with-effective-caching/)
- [Amazon
Bedrock AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)
- [Amazon
Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html)
- [Economics
for agentic AI on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-economics/index.html)
Related videos:
- [AWS re:Invent 2024 - Balance cost, performance & reliability
for AI at enterprise scale (AIM3304)](https://www.youtube.com/watch?v=Lwvv8Q33eeE)
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Memory tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/04-AgentCore-memory)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost02-bp03.html
---
AGENTCOST02-BP04 Implement model customization for long-term cost reduction
Customizing smaller models for a high-volume recurring task can optimize per-invocation costs into a one-time training expense that amortizes across every future call. The math only works when volume and task stability are high enough to justify the investment, so the decision needs to start with a break-even calculation, not an enthusiasm for fine-tuning.
Desired outcome:
- You have specialized models handling high-volume recurring tasks
at materially lower per-invocation cost than general-purpose foundation models.
- You have a customization pipeline that captures decision
patterns from production and refreshes models on a scheduled cadence.
- You validate decision quality with A/B testing against
foundation models before routing production traffic to a customized model.
- You track inference cost savings and decision quality side by
side so positive ROI is provable rather than assumed.
Common anti-patterns:
- Fine-tuning on synthetic data that misrepresents production task
distributions, causing underperformance that offsets cost savings through lower task completion rates.
- Applying customization to low-volume task categories where
training costs exceed projected inference savings, wasting effort on optimization that doesn't reach positive ROI.
- Treating customization as a one-time project without continuous
adaptation, allowing specialized models to drift as workload patterns change.
- Routing production traffic to customized models without A/B
testing against foundation models, risking quality degradation that undermines cost savings.
- Deploying customized models without instrumenting inference
latency, token costs, and quality metrics, reducing the risk of validation that the expected cost reduction materialized.
Benefits of establishing this best practice:
- Fine-tuned smaller models achieve comparable accuracy at lower
per-invocation cost through reduced token consumption and faster inference.
- One-time training costs amortize across thousands of
invocations, delivering compounding returns for high-volume tasks.
- Continuous adaptation pipelines keep specialized models aligned
with evolving workload patterns rather than decaying silently.
Level of risk exposed if this best practice is not established: High
Implementation guidance
Calculate current monthly inference cost for the target task category using Amazon Bedrock AgentCore Observability, estimate the reduction from a smaller customized model, and compare against one-time customization costs plus ongoing refresh. When monthly inference costs exceed $500 and task volume exceeds 10,000 invocations per month, customization typically reaches break-even within 6 to 12 months. Make the break-even explicit: (one-time training cost + quarterly refresh cost × planning horizon in quarters) divided by monthly inference savings. For a $5,000 training run that saves $400 per month, break-even lands at month 13, which is acceptable for workloads with multi-year lifespans but not for experimental projects.
Knowledge distillation transfers capability from a large teacher model to a smaller student model at lower per-invocation cost. The training data should come from production invocation logs filtered for high-confidence, successful completions. Parameter-efficient fine-tuning methods like QLoRA quantize base model weights to four-bit precision and train only adapter parameters, making single-GPU fine-tuning viable for smaller teams. Amazon Bedrock model customization jobs and Amazon SageMaker AI AI Training Jobs with QLoRA support fine-tuning without managing training infrastructure, and Amazon Bedrock Custom Model Import brings the results into Amazon Bedrock for serving.
Validation helps prevent quality regressions that occur from these cost optimizations. With Amazon Bedrock AgentCore Runtime, you can split production traffic between foundation and customized models during A/B testing, and Amazon Bedrock AgentCore Evaluations runs LLM-as-a-Judge assessments against both arms. Accept quantization only when accuracy loss stays within your acceptable quality threshold on task success rate. Treat customization as a pipeline: periodically extract high-quality examples from production logs, schedule quarterly refresh jobs, and gate promotion on A/B validation so drift doesn't compound silently between refreshes.
Implementation steps
- **Conduct a customization cost-benefit
analysis:** Calculate current monthly inference costs for high-volume task categories, identify where training costs amortize within your planning horizon, and compare fine-tuning investment (training compute plus ongoing maintenance) against projected cumulative inference savings.
- **Curate training data from production
logs:** Extract high-quality examples from production invocation logs by filtering for invocations with low error rates and acceptable latency using AgentCore Observability metrics. Target 500 to 1,000 examples per task category. Query Amazon CloudWatch for invocations where latency falls within the p50 to p90 range and error_type is absent, review a sample manually to verify quality, and store the curated dataset in Amazon S3.
- **Run distillation or
fine-tuning:** Use Amazon Bedrock model customization jobs or Amazon SageMaker AI AI Training Jobs with QLoRA, and validate using Amazon Bedrock AgentCore Evaluations against a held-out test set.
- **Import and A/B test customized
models:** Use Amazon Bedrock Custom Model Import and deploy through Amazon Bedrock AgentCore Runtime, routing a traffic slice to the customized model before promoting it to handle production volume.
- **Schedule quarterly refresh
jobs:** Automate training data extraction and retraining on a quarterly cadence, with A/B validation as the promotion gate to catch drift at each refresh rather than at annual review.
Resources
Related best practices:
- [AGENTCOST02-BP01
Architect tiered model selection for cost-performance optimization](agentcost02-bp01.html)
- [AGENTCOST02-BP02 Cost
optimize token consumption through efficient prompt engineering](agentcost02-bp02.html)
- [AGENTCOST05-BP01
Establish agent-level reasoning cost tracking and attribution](agentcost05-bp01.html)
Related documents:
- [Model
customization in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/custom-models.html)
- [Amazon
Bedrock Custom Model Import](https://docs.aws.amazon.com/bedrock/latest/userguide/model-customization-import-model.html)
- [Amazon
Bedrock AgentCore Evaluations](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html)
- [Evaluate
models in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation-judge.html)
- [Economics
for agentic AI on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-economics/index.html)
- [Guidance
for Cost Analysis and Optimization with Amazon Bedrock Agents](https://aws.amazon.com/solutions/guidance/cost-analysis-and-optimization-with-amazon-bedrock-agents/)
Related videos:
- [AWS re:Invent 2024 - Mastering model choice: The 3-step Amazon
Bedrock advantage (AIM391)](https://www.youtube.com/watch?v=Vu91YwZxskY)
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Evaluations tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/07-AgentCore-evaluations)
Related services:
- [Amazon
Bedrock](https://aws.amazon.com/bedrock/)
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost02-bp04.html
---
AGENTCOST03
Pillar: Unknown Best Practices: 3
---
AGENTCOST03-BP01 Design cost-effective retrieval systems with tiered memory
Agent memory has to serve two opposing needs at once: fast access for active context, and cheap storage for history that is rarely touched. Tiered memory matches each class of data to infrastructure priced for its actual access pattern, and selective retrieval keeps token costs proportional to what the current task needs.
Desired outcome:
- You have short-term working memory on high-performance storage
and long-term memory on cost-effective tiers, with automatic lifecycle transitions between them.
- You retrieve only top-K relevant items per reasoning step rather
than loading full memory stores into context.
- You track retrieval operations per session and use the data to
tune tier assignments and access patterns.
Common anti-patterns:
- Storing all agent memory in expensive high-performance storage
regardless of access frequency, incurring unnecessary costs for rarely accessed historical interactions.
- Retrieving entire memory stores for each reasoning step,
consuming excessive input tokens when targeted top-K retrieval would suffice.
- Using single-tier storage for all memory regardless of access
pattern, wasting resources on uniform infrastructure for data with distinct access profiles.
- Deploying memory systems without retrieval cost monitoring,
hiding inefficient access patterns inside aggregate session cost.
Benefits of establishing this best practice:
- Tiered storage matches each memory category to its access
pattern, reducing costs for historical data without sacrificing active session performance.
- Selective top-K retrieval limits context to the most pertinent
items, avoiding token charges for irrelevant historical data.
- Automated tier lifecycle management scales across thousands of
sessions without manual intervention or over-provisioning.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
The cost of agent memory comes from two decisions: where data lives and how much of it you pull into the model's context window. Amazon Bedrock AgentCore Memory handles the first decision as a managed service. Short-term memory stores turn-by-turn session context on fast storage, while long-term memory extracts and consolidates key insights across sessions into cheaper tiers.
For agents on Amazon Bedrock AgentCore Runtime, this removes the need to build storage tiers and promotion policies by hand. When a custom implementation is required, define explicit promotion and demotion policies based on access frequency so frequently accessed items stay on low-latency storage and rarely accessed items migrate to lower-cost tiers automatically.
Retrieval volume is the second decision, and it has a direct effect on input token cost. Amazon Bedrock Knowledge Bases provides managed vector retrieval with semantic search. K (the number of chunks returned per query) is the central cost-quality knob: higher K gives the agent more context but pushes more tokens into every invocation. Start with K=5 and tune against the trade-off between completeness and cost, not from a preference for safety.
Index design is a less obvious but still important cost consideration. For Amazon OpenSearch Service Serverless-backed Knowledge Bases, HNSW parameters (ef_construction and m) balance index build cost against query accuracy and recall. OpenSearch Serverless charges based on indexed data volume and query compute, so tuning these parameters is a direct cost decision, not just a quality decision. Higher ef_construction values improve recall but raise both build and query cost, while lower values reduce cost but risk missing relevant items.
Additionally, consider retrieval batching. Pre-fetching the full task context at initiation and caching it in the agent's working memory avoids per-step retrieval overhead. Amazon Bedrock AgentCore Observability provides OpenTelemetry-compatible telemetry that identifies which retrieval patterns drive the most token consumption, and Amazon CloudWatch Logs Insights queries reveal access patterns that should inform tier reassignments.
Implementation steps
- **Adopt managed tiered
memory:** Integrate Amazon Bedrock AgentCore Memory for short-term and long-term memory with automatic lifecycle management, and document which namespaces each agent writes to and reads from.
- **Configure selective
retrieval:** Use Amazon Bedrock Knowledge Bases with top-K semantic search, starting at K=5 and tuning based on observed reasoning quality and token cost.
- **Tune vector index
parameters:** Adjust HNSW ef_construction and m on the Amazon OpenSearch Service Serverless backing store to balance index build cost, query latency, and recall accuracy for your workload.
- **Pre-fetch context at task
initiation:** Replace per-step retrievals with a single batch pre-fetch at task start, cached in working context so the model doesn't pay retrieval overhead on every reasoning step.
- **Instrument retrieval
operations:** Enable Amazon Bedrock AgentCore Observability and set Amazon CloudWatch alarms when retrieval frequency exceeds expected bounds per session.
- **Review access patterns
weekly:** Run CloudWatch Logs Insights queries to reveal expensive retrieval patterns and never-accessed items, and use the results to reassign tiers and retire dead entries.
Resources
Related best practices:
- [AGENTCOST01-BP02
Optimize multi-agent collaboration cost through efficient handoff patterns](agentcost01-bp02.html)
- [AGENTCOST02-BP03
Use intelligent caching to reduce redundant model invocations](agentcost02-bp03.html)
- [AGENTCOST03-BP02 Cost
optimize through intelligent compression and pruning of context windows](agentcost03-bp02.html)
- [AGENTCOST03-BP03
Implement cost-optimized state persistence and lifecycle management](agentcost03-bp03.html)
Related documents:
- [Amazon
Bedrock AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)
- [Amazon
Bedrock Knowledge Bases](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html)
- [Economics
for agentic AI on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-economics/index.html)
- [Guidance
for Cost Analysis and Optimization with Amazon Bedrock Agents](https://aws.amazon.com/solutions/guidance/cost-analysis-and-optimization-with-amazon-bedrock-agents/)
Related videos:
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Memory tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/04-AgentCore-memory)
Related workshops:
- [Getting
started with Amazon Bedrock AgentCore - Lab 2: Memory](https://catalog.workshops.aws/agentcore-getting-started/en-US/30-add-memory)
- [Diving
Deep into Bedrock AgentCore - Memory](https://catalog.workshops.aws/agentcore-deep-dive/en-US/50-agentcore-memory)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost03-bp01.html
---
AGENTCOST03-BP02 Cost optimize through intelligent compression and pruning of context windows
In long-running agent sessions, raw conversation history can silently drive costs up, as every turn gets paid for again on every subsequent invocation. Compression, selective retrieval, and pruning keep context proportional to what the agent needs for the current decision rather than growing with session length.
Desired outcome:
- You compress older conversation turns into summaries so
historical context doesn't multiply per-invocation token cost.
- You retrieve only the top-K most relevant memory items per
reasoning step.
- You prune duplicates, superseded reasoning, and irrelevant tool
results before each invocation.
- You monitor context window utilization and alert on sessions
approaching overflow.
Common anti-patterns:
- Including full conversation history in every invocation
regardless of task relevance, causing linear token cost growth with session length.
- Allowing raw interaction history to accumulate without
compression, so context windows are dominated by historical turns with diminishing value.
- Deploying agents without context utilization monitoring, missing
sessions that approach overflow thresholds and trigger costly re-invocation errors.
- Retrieving excessive RAG chunks or oversized chunk lengths when
smaller, targeted retrievals would maintain reasoning quality at lower cost.
- Failing to prune duplicate or superseded information, paying
tokens on content that doesn't contribute to the current reasoning task.
Benefits of establishing this best practice:
- History compression helps prevent linear token cost growth in
long-running sessions, making persistent assistants economically viable.
- Selective retrieval includes only high-value context relevant to
the current task, reducing token waste from marginally relevant data.
- Context window monitoring helps prevent overflow errors that
trigger costly re-invocation with truncated context.
Level of risk exposed if this best practice is not established: High
Implementation guidance
Amazon Bedrock AgentCore Memory separates short-term and long-term memory, which is the architectural pattern behind rolling summarization. Short-term memory holds raw recent turns, and long-term memory automatically extracts and consolidates key insights across sessions. For agents on AgentCore Runtime, this dual-tier behavior implements rolling summarization without custom code, and it is the difference between a persistent assistant whose token cost is bounded and one whose cost grows linearly with conversation age.
Selective retrieval helps handle the problem of conversation history cost. AgentCore Memory's RetrieveMemoryRecords operation performs semantic search with relevance scoring and metadata filtering, so you can pre-filter by recency or topic before the similarity search runs. Configure top-K between three and five items per reasoning step.
Context pruning assists with retrieval by removing duplicates between summaries and recent turns before each invocation, dropping superseded reasoning steps, and stripping irrelevant tool results. The goal is a target context utilization of 60 to 80% of the model's window, which leaves enough headroom for responses while still benefiting from available context.
RAG chunk sizing also helps solve this problem. When retrieving from Amazon Bedrock Knowledge Bases, chunk sizes of 256 to 512 tokens balance retrieval precision against context bloat, and limiting retrieved chunks to the minimum needed helps prevent marginally relevant data from crowding out the current task. The verification that compression isn't silently hurting quality is a correlation check: pair context utilization with task success rate in CloudWatch Logs Insights and track whether aggressive pruning correlates with success-rate degradation.
Amazon Bedrock AgentCore Observability exposes token usage metrics that feed CloudWatch dashboards and alarms. Alarms on sessions consistently above 80% utilization flag the candidates for tighter summarization, correlating those same metrics with task success rates confirms whether the compression is paying off in cost without paying in quality.
Implementation steps
- **Adopt managed rolling
summarization:** Integrate Amazon Bedrock AgentCore Memory for managed compression, or implement custom rolling summarization that compresses the oldest N turns after every N turns.
- **Configure relevance-scored
retrieval:** Use AgentCore Memory's RetrieveMemoryRecords with relevance thresholds and metadata filtering, retrieving only the top-K most relevant items per reasoning step.
- **Prune context before each
invocation:** Remove duplicates, superseded reasoning steps, and irrelevant tool results before each model call so the context window reflects what the current decision needs.
- Tune RAG chunk size:
Optimize Amazon Bedrock Knowledge Bases chunk sizes to 256 to 512 tokens, limit retrieved chunks to the minimum needed, and add re-ranking to maximize relevance.
- **Alarm on context
utilization:** Build Amazon CloudWatch dashboards for context window utilization and set alarms for sessions exceeding 80% utilization.
- **Correlate utilization with task
success:** Use CloudWatch Logs Insights to correlate context utilization with task success rates, validating that compression strategies reduce cost without degrading reasoning quality.
Resources
Related best practices:
- [AGENTCOST02-BP02
Cost optimize token consumption through efficient prompt engineering](agentcost02-bp02.html)
- [AGENTCOST02-BP03
Use intelligent caching to reduce redundant model invocations](agentcost02-bp03.html)
- [AGENTCOST03-BP01 Design
cost-effective retrieval systems with tiered memory](agentcost03-bp01.html)
- [AGENTCOST03-BP03
Implement cost-optimized state persistence and lifecycle management](agentcost03-bp03.html)
Related documents:
- [Amazon
Bedrock AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)
- [Amazon
Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html)
- [Economics
for agentic AI on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-economics/index.html)
Related videos:
- AWS 2025 - AgentCore Deep Dive: Memory
- [AWS 2025 - AgentCore Observability: Monitor and Debug with
OpenTelemetry](https://www.youtube.com/watch?v=wWQgawUPr1k)
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Memory tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/04-AgentCore-memory)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost03-bp02.html
---
AGENTCOST03-BP03 Implement cost-optimized state persistence and lifecycle management
Agent state grows quickly when every reasoning step triggers a checkpoint, and it stays forever when no lifecycle policy removes it. Saving state at meaningful decision points, tiering by access pattern, and automating archival keeps recoverability without paying for a growing backlog of stale sessions.
Desired outcome:
- You checkpoint at meaningful decision points rather than after
every reasoning step.
- You have session state tiered by access pattern, with
high-performance storage reserved for active work.
- You have automated lifecycle policies that archive or purge
stale context.
- You track storage cost per agent and session, with alarms for
unexpected growth.
Common anti-patterns:
- Checkpointing after every reasoning step with synchronous writes
when asynchronous checkpoints at meaningful decision points would suffice.
- Keeping all session state on high-performance storage regardless
of activity level, paying unnecessary costs for inactive or archived sessions.
- Allowing agent memory to accumulate indefinitely without
archival or deletion, producing unbounded storage growth.
- Storing agent state uncompressed when compression could reduce
storage costs proportionally.
- Deploying state persistence without cost monitoring, hiding
high-cost patterns and optimization opportunities.
Benefits of establishing this best practice:
- Automated lifecycle management helps prevent unbounded storage
growth without manual intervention across thousands of sessions.
- Managed memory separates durable learning from ephemeral state,
keeping knowledge that improves agent performance while cleaning up temporary artifacts.
- Session timeout configuration balances responsiveness with cost
by controlling the compute lifecycle.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
Amazon Bedrock AgentCore Runtime provides a persistent filesystem that handles tiered storage and lifecycle automatically. The filesystem survives session stop and resume cycles for up to 14 days of inactivity before automatic deletion, and the two lifecycle parameters that shape cost are idleRuntimeSessionTimeout (default 15 minutes) and maxLifetime (up to 8 hours). The 15-minute default suits interactive workloads, while longer timeouts reduce session state transitions for batch workloads. Session storage automatically synchronizes filesystem writes to durable storage throughout the session lifecycle, with data flushed during graceful shutdown when sessions stop.
Make a deliberate design choice about checkpointing. For use cases that require explicit checkpoints at application-defined decision points, implement custom checkpoint logic that writes state snapshots to the persistent filesystem. Checkpoint interval is a trade-off between recovery granularity and storage consumption: more frequent checkpoints enable finer-grained recovery but increase storage cost. Some agent frameworks provide built-in checkpoint capabilities using the same filesystem, which avoids reinventing the pattern.
Consider how you accomplish durable learning. Amazon Bedrock AgentCore Memory persists insights across sessions (short-term memory for recent interactions, long-term memory for consolidated learning), which is different from per-session filesystem state. For compliance retention beyond the 14-day Runtime filesystem window, export completed session data to Amazon S3 with Intelligent-Tiering enabled, and configure lifecycle rules for cost-effective long-term storage. Monitor consumption per agent type using Amazon Bedrock AgentCore Observability with custom dimensions, and set Amazon CloudWatch alarms when growth exceeds expected bounds.
Implementation steps
- **Deploy on AgentCore Runtime with
tuned lifecycle parameters:** Use Amazon Bedrock AgentCore Runtime for automatic session lifecycle management, configuring idleRuntimeSessionTimeout and maxLifetime based on workload patterns.
- **Integrate managed memory for durable
learning:** Configure Amazon Bedrock AgentCore Memory short-term memory for recent context and long-term memory for persistent insights, keeping durable learning separate from ephemeral filesystem state.
- **Archive compliance-required sessions
to S3:** Export completed session histories to Amazon S3 Intelligent-Tiering and set lifecycle rules for cost-effective long-term retention.
- **Monitor storage per agent
type:** Configure Amazon Bedrock AgentCore Observability with custom dimensions to track storage cost per agent type, and set Amazon CloudWatch alarms for unexpected storage growth.
Resources
Related best practices:
- [AGENTCOST01-BP01
Use the reflection pattern to design efficient agent reasoning loops](agentcost01-bp01.html)
- [AGENTCOST03-BP01 Design
cost-effective retrieval systems with tiered memory](agentcost03-bp01.html)
- [AGENTCOST03-BP02 Cost
optimize through intelligent compression and pruning of context windows](agentcost03-bp02.html)
- [AGENTCOST05-BP01
Establish agent-level reasoning cost tracking and attribution](agentcost05-bp01.html)
Related documents:
- [Amazon
Bedrock AgentCore Runtime Sessions](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-sessions.html)
- [Amazon
Bedrock AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)
- Amazon S3 Intelligent-Tiering
- [Economics
for agentic AI on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-economics/index.html)
Related videos:
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Runtime advanced concepts](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/01-AgentCore-runtime/03-advanced-concepts)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost03-bp03.html
---
AGENTCOST04
Pillar: Unknown Best Practices: 3
---
AGENTCOST04-BP01 Design cost effective tool selection to minimize unnecessary invocations
Often, the most cost-effective tool call is the one an agent decides not to make because the answer is already in context. Context-first reasoning, cost-ranked selection, and duplicate detection tie tool invocation to the value of the information retrieved.
Desired outcome:
- You have agents checking context and managed memory before
invoking tools.
- You have a cost-ranked selection rubric that points agents to
cheaper alternatives first.
- You batch requests where possible and cache results within
sessions to avoid duplicate calls.
- You monitor per-tool invocation frequency and cache hit rates as
distinct metrics.
Common anti-patterns:
- Invoking tools without checking whether required information
already exists in context or managed memory, adding cost without improving results.
- Creating narrow tool interfaces that return minimal data,
forcing follow-up calls to assemble complete context.
- Implementing retry logic without exponential backoff or
automatic cutoffs, causing retry storms that multiply costs during service degradation.
- Operating without tool invocation metrics, so no one can
identify which tools are most expensive or most frequently called.
Benefits of establishing this best practice:
- Context-first evaluation reduces unnecessary tool invocations
for agents with rich context from prior reasoning steps.
- Cost-ranked tool selection rubrics direct agents to cheaper
alternatives, reserving expensive external APIs for cases where lower-cost options are insufficient.
- Batched tool interfaces and complete result sets reduce per-call
overhead and the need for follow-up invocations.
Level of risk exposed if this best practice is not established: High
Implementation guidance
Tool necessity belongs in the agent's reasoning prompt, not as an afterthought in monitoring. The system prompt should instruct the model to assess whether the answer can be derived from information already in context, from conversation history stored in Amazon Bedrock AgentCore Memory, or from prior tool results within the same reasoning cycle, before selecting a tool. Pair this with a cost-ranked selection rubric that places cheaper alternatives first: if a local computation or a cached result produces the same answer as an external API call, the agent should take the cheaper path.
Tool interface design matters as much as agent instructions. Narrow interfaces that return minimal data force agents to make follow-up calls to assemble the context they need, which inflates per-reasoning-cycle tool cost. Amazon Bedrock AgentCore Gateway provides MCP-based tool discovery with composition features that combine multiple APIs into single endpoints, reducing invocation overhead. Design tool interfaces to accept batch inputs and return complete result sets so a single call does the work of many.
Consider how you implement duplicate detection. Agents often invoke the same tool with identical parameters across reasoning iterations, especially when revisiting a branch. Implement a session-scoped tool result cache in your action group Lambda functions or AgentCore Gateway MCP servers so the agent doesn't re-invoke the same tool with the same parameters. Store results in AgentCore Memory's short-term memory so the agent's reasoning prompt can reveal prior results before deciding to make another call.
For enforcement and measurement, Amazon Bedrock AgentCore Policy applies Cedar policies that halt retries when failure rates indicate persistent degradation and cap tool calls per reasoning cycle. Amazon Bedrock AgentCore Observability exposes tool selection patterns, Amazon CloudWatch tracks invocation frequency and deduplication hit rates, and Amazon Bedrock AgentCore Evaluations scores tool selection accuracy so patterns of over-invocation appear as quality data, not just cost data.
Implementation steps
- **Embed tool necessity evaluation in
system prompts:** Direct the model to check context and Amazon Bedrock AgentCore Memory before invoking tools, and include a cost-ranked selection rubric that places cheaper alternatives first.
- **Redesign tool interfaces for
batching:** Expose tools through Amazon Bedrock AgentCore Gateway with batch inputs and complete result sets so one call carries the payload that previously required several.
- **Cache tool results within
sessions:** Implement session-scoped caches in action group Lambda functions or Gateway MCP servers to deduplicate identical tool calls, storing results in AgentCore Memory so the agent can surface them before the next call.
- **Apply automatic cutoffs through
policy:** Configure Amazon Bedrock AgentCore Policy Cedar policies that cap tool calls per reasoning cycle and halt retries on persistent failures.
- **Monitor tool selection
patterns:** Use Amazon Bedrock AgentCore Observability to surface tool selection patterns and create Amazon CloudWatch metrics for tool invocation frequency and deduplication hit rates.
- **Score tool selection
accuracy:** Use Amazon Bedrock AgentCore Evaluations to periodically score tool selection accuracy, flagging patterns where agents choose expensive tools when cheaper alternatives would suffice.
Resources
Related best practices:
- [AGENTCOST01-BP01
Use the reflection pattern to design efficient agent reasoning loops](agentcost01-bp01.html)
- [AGENTCOST02-BP02
Cost optimize token consumption through efficient prompt engineering](agentcost02-bp02.html)
- [AGENTCOST04-BP02 Cost
optimize tool serving through serverless and resource sharing](agentcost04-bp02.html)
- [AGENTCOST04-BP03
Implement intelligent caching and failure handling for tool results](agentcost04-bp03.html)
- [AGENTCOST05-BP01
Establish agent-level reasoning cost tracking and attribution](agentcost05-bp01.html)
Related documents:
- [Amazon
Bedrock AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html)
- [Amazon
Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html)
- [Amazon
Bedrock AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)
- [Guidance
for Cost Analysis and Optimization with Amazon Bedrock Agents](https://aws.amazon.com/solutions/guidance/cost-analysis-and-optimization-with-amazon-bedrock-agents/)
Related videos:
- AWS 2025 - AgentCore Deep Dive: Gateway
- [AWS re:Invent 2024 - Scale agent tools with AgentCore Gateway
(AIM3313)](https://www.youtube.com/watch?v=DlIHB8i6uyE)
- [Integrating
MCP Tools with Strands Agents](https://www.youtube.com/watch?v=bHSbjCZZFjE)
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Gateway tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/02-AgentCore-gateway)
Related workshops:
- [Diving
Deep into Bedrock AgentCore - Gateway](https://catalog.workshops.aws/agentcore-deep-dive/en-US/30-agentcore-gateway)
Related tools:
- [Strands
Agents MCP Tools](https://strandsagents.com/docs/user-guide/concepts/tools/mcp-tools/)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost04-bp01.html
---
AGENTCOST04-BP02 Cost optimize tool serving through serverless and resource sharing
Tool infrastructure that runs constantly to serve unpredictable agent traffic carries the highest idle cost in an agent stack. Serverless tool serving with shared infrastructure across agents aligns spend with actual invocations and removes the fixed overhead of per-agent dedicated instances.
Desired outcome:
- You have tool-serving infrastructure that scales dynamically
with agent usage and charges only for actual invocations.
- You share stateless tool services across agents while
maintaining security isolation.
- You use private networking and compact serialization to reduce
data transfer costs on high-frequency tool invocations.
- You track per-agent cost attribution for targeted optimization.
Common anti-patterns:
- Running persistent servers for tool serving that incur charges
during hours or days when no agents invoke tools.
- Creating dedicated tool server instances per agent rather than
shared stateless services, producing dozens of underutilized servers.
- Routing tool invocations through NAT Gateways when agents and
tools live in the same VPC, incurring unnecessary per-GB data processing charges.
Benefits of establishing this best practice:
- Serverless tool serving scales to zero when agents are inactive,
reducing idle costs through consumption-based pricing.
- Shared tool infrastructure spreads fixed hosting overhead across
all agents while maintaining security isolation.
- VPC endpoints and compact serialization reduce data transfer
costs for high-frequency tool invocations.
Level of risk exposed if this best practice is not established: High
Implementation guidance
Agent tool traffic is inherently bursty. An agent fleet is active during business hours, idle overnight, and heavily uneven across agent types. Provisioned tool infrastructure pays for that shape by keeping compute warm through idle hours, which can be a significant hidden cost in agent stacks. Amazon Bedrock AgentCore Gateway provides fully-managed, serverless tool serving that converts APIs and existing services into MCP-compatible tools without infrastructure management. AgentCore Gateway handles authentication, scales automatically, and combines multiple APIs into unified endpoints.
Because tools exposed through AgentCore Gateway are available to all authorized agents, one endpoint can serve an entire fleet rather than one endpoint per agent. Amazon Bedrock AgentCore Identity and Amazon Bedrock AgentCore Policy supply the fine-grained access control that keeps sharing safe.
For tools that need extended execution, Amazon Bedrock AgentCore Runtime supports workloads up to 8 hours with consumption-based pricing calculated at per-second increments. Consumption pricing is the right default for unpredictable tool invocation patterns because it charges only during active processing.
Cold starts are a failure mode worth planning for. A cold tool extends the agent's reasoning cycle and may trigger retries, which can push per-session token costs up on cold paths. Monitor cold start frequency in Amazon CloudWatch and evaluate Lambda SnapStart or scheduled warming when cold starts are material.
Networking and serialization are the foundation of planning for these failure modes. VPC endpoints for private data paths avoid NAT Gateway processing charges for high-frequency tool invocations between agents and tools in the same VPC. Compact JSON (or binary formats where supported) reduces payload sizes on repeated high-frequency calls. Tagging every invocation with agent ID and workflow ID lets Amazon Bedrock AgentCore Observability and AWS Cost Explorer reveal which agents and tools drive the highest spend.
Implementation steps
- **Expose tools through serverless
Gateway:** Deploy agent tools through Amazon Bedrock AgentCore Gateway MCP server capabilities for serverless infrastructure with automatic scaling and shared access across agents.
- **Apply fine-grained access
control:** Configure Amazon Bedrock AgentCore Policy Cedar policies for per-agent tool access, preserving security isolation while sharing infrastructure.
- Attribute cost per agent:
Use Amazon Bedrock AgentCore Observability telemetry tags with agent ID and workflow ID, and generate periodic AWS Cost Explorer reports by agent and tool type.
- **Monitor invocation patterns and cold
starts:** Expose tool invocation patterns through AgentCore Observability, and set Amazon CloudWatch alarms for patterns that exceed expected bounds, including cold start frequency.
Resources
Related best practices:
- [AGENTCOST04-BP01 Design
cost effective tool selection to minimize unnecessary invocations](agentcost04-bp01.html)
- [AGENTCOST04-BP03
Implement intelligent caching and failure handling for tool results](agentcost04-bp03.html)
- [AGENTCOST05-BP01
Establish agent-level reasoning cost tracking and attribution](agentcost05-bp01.html)
Related documents:
- [Amazon
Bedrock AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html)
- [Amazon
Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html)
- [Amazon
Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html)
- [Guidance
for Cost Analysis and Optimization with Amazon Bedrock Agents](https://aws.amazon.com/solutions/guidance/cost-analysis-and-optimization-with-amazon-bedrock-agents/)
Related videos:
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Gateway tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/02-AgentCore-gateway)
Related workshops:
- [Getting
started with Amazon Bedrock AgentCore - Lab 3: Gateway, Identity & Policy](https://catalog.workshops.aws/agentcore-getting-started/en-US/50-add-tool-gateway)
- [Diving
Deep into Bedrock AgentCore - Gateway](https://catalog.workshops.aws/agentcore-deep-dive/en-US/30-agentcore-gateway)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost04-bp02.html
---
AGENTCOST04-BP03 Implement intelligent caching and failure handling for tool results
Tool costs can be unpredictable when agents repeat identical or equivalent calls, and they can spike sharply when retries run unbounded through a service outage. Two-layer caching, schema validation, and automatic cutoffs convert those failure modes into predictable, bounded costs.
Desired outcome:
- You have session-scoped and cross-session semantic caches
reducing redundant tool invocations.
- You validate tool inputs against JSON Schema before invocation
to help prevent wasted calls on malformed requests.
- You have automatic cutoffs that halt retries when failure rates
exceed thresholds, with automatic fallback to alternative tools.
- You track cache hit rates and retry costs as distinct metrics.
Common anti-patterns:
- Not caching frequently used tool results, making repeated
identical calls within the same session that waste compute and external API costs.
- Using only exact-match caching when agents phrase the same
request differently, missing cache hits for semantically identical calls.
- Retrying failed tool invocations indefinitely without automatic
cutoffs, multiplying cost during service degradation without resolving the underlying issue.
- Not validating tool input schemas before invocation, allowing
malformed calls to waste invocation cost without producing usable results.
Benefits of establishing this best practice:
- Two-layer caching reduces redundant tool invocations and
external API charges.
- Automatic cutoffs halt retries when failure rates exceed
thresholds, helping prevent expensive retry storms.
- Event-driven cache invalidation supports aggressive caching of
volatile data by purging stale results promptly when source data changes.
Level of risk exposed if this best practice is not established: High
Implementation guidance
Tool caching has to work at two scopes to cover both obvious and non-obvious repetition. The session-scoped layer works through Amazon Bedrock AgentCore Runtime and catches duplicate calls within a single agent session, which is a common failure mode when agents revisit a reasoning branch. The cross-session layer uses Amazon OpenSearch Service Serverless for semantic caching: generate embeddings of tool parameters and query for similar prior calls above a cosine similarity threshold before invoking the tool. Each cache entry's TTL should be calibrated to the underlying data's volatility. For example, a weather API's freshness requirement is minutes, while a static reference knowledge base tolerates hours or days.
Schema validation can help prevent waste. Agents sometimes generate tool calls with incorrect parameter types, missing required fields, or invalid enum values, and those calls pay tool-serving and external API costs for a response that can't be used. JSON schema validation in the action group Lambda function rejects malformed requests before they reach external APIs and returns a validation error to the agent for correction.
Cache invalidation can help make aggressive caching safer. Event-driven invalidation listens for source-data changes and purges affected cache entries immediately, so volatile data can still be cached without returning stale results. Without event-driven invalidation, teams end up choosing between aggressive TTLs (stale results) or short TTLs (low hit rates), and both options leave cost on the table.
For failure handling, Amazon Bedrock AgentCore Policy Cedar policies enforce automatic cutoffs when failure rates exceed thresholds, halting retry storms during service degradation. Automatic fallback to alternative tools maintains agent functionality during outages, and retry budgets per reasoning session cap total retry attempts using exponential backoff with jitter. Cache and retry telemetry is exposed through Amazon Bedrock AgentCore Observability and Amazon CloudWatch: hit rates per layer, cutoff state transitions, and retry cost as a percentage of total tool cost. For caching that extends beyond tool results into model invocations, see AGENTCOST02-BP03 Use intelligent caching to reduce redundant model invocations.
Implementation steps
- Deploy two-layer caching:
Implement a session-scoped in-process cache on Amazon Bedrock AgentCore Runtime and an Amazon OpenSearch Service Serverless semantic cache for cross-session reuse, with TTLs calibrated per tool (short for volatile data, long for static reference data).
- Deploy semantic caching:
Generate parameter embeddings and query OpenSearch Serverless for similar prior calls above a cosine similarity threshold before invoking the tool.
- Validate tool inputs:
Implement JSON Schema validation in action group Lambda functions to reject malformed requests before they reach external APIs, returning validation errors for the agent to correct.
- **Enforce cutoffs and fallback
tools:** Configure Amazon Bedrock AgentCore Policy Cedar policies for automatic cutoffs, wire automatic fallback to alternative tools when cutoffs activate, and set retry budgets per reasoning session.
- **Monitor cache and retry
metrics:** Create Amazon CloudWatch metrics for cache hit rates, cutoff transitions, and retry costs using Amazon Bedrock AgentCore Observability, with alarms for degraded performance.
Resources
Related best practices:
- [AGENTCOST02-BP03
Use intelligent caching to reduce redundant model invocations](agentcost02-bp03.html)
- [AGENTCOST04-BP01 Design
cost effective tool selection to minimize unnecessary invocations](agentcost04-bp01.html)
- [AGENTCOST04-BP02 Cost
optimize tool serving through serverless and resource sharing](agentcost04-bp02.html)
- [AGENTCOST05-BP01
Establish agent-level reasoning cost tracking and attribution](agentcost05-bp01.html)
Related documents:
- [Amazon
Bedrock AgentCore Policy](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html)
- [Optimize
LLM response costs and latency with effective caching](https://aws.amazon.com/blogs/database/optimize-llm-response-costs-and-latency-with-effective-caching/)
- [Amazon
Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html)
- [Amazon
Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html)
- [Economics
for agentic AI on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-economics/index.html)
Related videos:
Related examples:
- [GitHub:
awslabs/amazon-bedrock-agentcore-samples - Gateway tutorials](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/02-AgentCore-gateway)
Related services:
- [Amazon
Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
Source: https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentcost04-bp03.html
---
Related skills
Azure AiIntegrates Azure AI Content Safety, Document Intelligence, Speech, and Search services into Java-based agents and applications.495k1.4kAzure PrepareGenerate the exact Azure infrastructure files, Dockerfiles, and azure.yaml configuration needed before deploying any new or modernized application.494k1.4kAzure StorageConnect agents and applications to Azure Blob Storage, File Shares, Queues, Tables, and Data Lake without leaving the coding environment.494k1.4kAppinsights InstrumentationAutomatically instrument web applications running on Azure App Service with Application Insights for observability without manual configuration.493k1.4kAzure Resource LookupInstantly list, query, and discover any Azure resources across subscriptions without leaving the agent chat.493k1.4kAzure AigatewayConfigure Azure API Management as a secure, governed gateway for routing traffic to LLMs, MCP servers, and agent tools.493k1.4kFAQ
When should I use wa-review instead of a single-pillar skill?
Use wa-review for a comprehensive all-pillars assessment; use security-assessment, reliability-improvement-plan or the other pillar skills for a single-pillar deep-dive.
Does wa-review cover AI agent workloads?
Yes, it bundles an agentic-AI lens with AGENTSEC, AGENTREL, AGENTPERF, AGENTOPS and AGENTCOST reference material.