AgentCore offers an enterprise-level infrastructure and operational framework for scalable AI agent deployment and management, though it comes with some minor complexities.
<div class="media-with-label__label">
Credit: Jeff Holcombe / Shutterstock </div>
</figure>
</div>
</div>
</div>
</div> Amazon Bedrock assists in developing and scaling generative AI applications, but it’s Amazon Bedrock AgentCore that delivers the robust infrastructure and operational support necessary for deploying and managing AI agents at scale. AgentCore is designed to be model-, framework-, and integration-agnostic, though its initial command-line interface (CLI) predominantly supports leading options in these categories.
The CLI can create agents utilizing models from Amazon Bedrock, Anthropic, Google Gemini, and OpenAI. It supports frameworks such as Strands, LangGraph, Microsoft Autogen, OpenAI Agents SDK, Google Agent Development Kit, and CrewAI, and integrates with Amazon AgentCore Memory, AgentCore Observability, and AgentCore Gateway. It’s worth noting that several of these technologies are offered by AWS competitors.
Key services provided by AgentCore encompass a runtime environment, both short-term and long-term memory, a gateway, identity management, a secure sandboxed code interpreter, a cloud-hosted browser, observability tools, an evaluation service, and an agent-external policy enforcement mechanism. These will be elaborated upon further down.
AgentCore faces competition from other cloud platforms that offer comparable enterprise-grade hosting, security, and governance solutions for agents within their own ecosystems. These competitors include:
- Google Cloud Agent SDK (ADK): This SDK, built on Vertex AI, provides robust integration with Gemini models.
- Azure AI Foundry Agents: An ideal choice for organizations deeply integrated into the Microsoft ecosystem and leveraging Azure OpenAI Service.
- Databricks Agent Bricks: This data-focused option enables the creation of agents directly from enterprise data using the Unity Catalog.
Other platforms that compete with, and occasionally collaborate with, AgentCore are the OpenAI Agents SDK, LangChain/LangGraph, CrewAI, and SmythOS.
An illustrative overview chart of Amazon Bedrock AgentCore.
Amazon Web Services
The streamlined AgentCore quick start CLI workflow, detailing the three essential steps: agent creation, deployment, and invocation.
Amazon Web Services
Exploring AgentCore’s Fundamental Services
AgentCore’s primary services encompass a runtime environment, short-term and long-term memory solutions, a gateway, identity management, a secure code interpreter sandbox, a cloud-based browser, comprehensive observability, an evaluation service, and an external policy enforcement mechanism. Developers can selectively leverage these services to facilitate their agent development.
The AgentCore Runtime delivers a secure, serverless environment for deploying and scaling dynamic AI agents and their associated tools. It features rapid cold starts for immediate interactions, extended support for asynchronous agents, robust session isolation, integrated identity features, and capabilities for handling multi-modal and multi-agent workloads. This runtime is designed to integrate seamlessly with both custom and open-source frameworks, along with any foundation model, whether hosted within or external to Amazon Bedrock.
AgentCore Memory empowers the creation of context-aware agents, offering granular control over what an agent retains and learns. It supports both short-term memory for ongoing multi-turn dialogues and long-term memory that endures across different sessions. This service also allows for sharing memory stores among agents and facilitates learning from accumulated experiences. It is compatible with frameworks like LangGraph, LangChain, Strands, and LlamaIndex.
The AgentCore Gateway provides a secure mechanism to transform various APIs, Lambda functions, and existing services into tools compatible with the Model Context Protocol (MCP). Furthermore, it can establish connections with pre-existing MCP servers, exposing them to AI agents via gateway endpoints with minimal code.
AgentCore Identity delivers a secure and scalable service for managing agent identities, access, and authentication. It seamlessly integrates with existing identity and credential providers, negating the requirement for user migration or the re-architecture of authentication workflows.
The AgentCore Code Interpreter offers an isolated sandbox where agents can execute code, thereby improving their precision and capabilities. It supports Python, JavaScript, and TypeScript, with a default execution time of 15 minutes, extendable to up to eight hours. It’s recommended to keep code snippets brief and task-specific. Development can be done using the Strands Agents SDK (Python or TypeScript) or the bedrock_agentcore SDK or Boto3 (both Python). The underlying session isolation for both the code interpreter and browser is powered by Firecracker microVMs.
The AgentCore Browser functions as a remote browser, operating within a distinct environment, separate from the local machine. This feature is crucial for agent development, enabling AI agents to interact with the web much like human users. It facilitates agents and models in navigating websites, completing forms, clicking interactive elements, and processing dynamic content, all while offering a live monitoring view for potential intervention. AgentCore Browser is compatible with Nova Act, Strands, and Playwright for automating web interactions.
AgentCore Observability provides a consolidated interface for tracing, debugging, and monitoring agent performance in live production environments. It offers granular visualizations of every stage within an agent’s workflow, allowing users to scrutinize execution paths, review intermediate outputs, and pinpoint performance bottlenecks or failures. This service integrates seamlessly with any observability stack compatible with the OpenTelemetry (OTEL) format.
AgentCore Evaluations offers a service for automated, consistent, and data-driven assessment of agents. It quantifies the effectiveness of your agents and tools in executing tasks, managing complex edge cases, and ensuring reliable output across various inputs and operational contexts.
AgentCore Policy is a feature designed to provide deterministic control, ensuring that agents adhere to established boundaries and business rules without compromising performance. Rules can be authored using natural language or Cedar, AWS’s open-source policy language. This policy mechanism operates externally to the agents, preventing models from circumventing defined constraints.
Practical Applications of AgentCore
Amazon Bedrock AgentCore facilitates the deployment of AI agents that are scalable, reliable, and secure. Its primary use cases fall into three categories: agents, MCP servers, and agent platforms.
For agents, developers can create AI applications capable of reasoning, utilizing tools, and maintaining conversational context. These applications are suitable for various domains, such as customer support, workflow automation, data analysis, or coding assistance. AgentCore ensures that these agents operate serverlessly, with isolated sessions, durable memory, and integrated observability features.
AgentCore aids in transforming existing APIs, databases, and services into tools consumable by MCP-compatible agents. This involves deploying a gateway to encapsulate your Lambda functions or OpenAPI specifications, thereby exposing your backend to agents without requiring extensive code modifications.
Lastly, AgentCore enables the creation of robust agent platforms, allowing developers or customers to deploy agents with sanctioned tools, shared memory stores, and governed access to enterprise services. Standard AgentCore services can be leveraged to incorporate observability, authentication, and compliance functionalities.
Illustrative Customer Support Agent Scenario
I was encouraged by the AgentCore team to explore the Customer Support Agent demo (architecture diagram shown below). Despite appearing to be a standard AWS setup involving numerous services, I decided to proceed, having encountered more complex configurations in the past.
An architectural overview of the Amazon Bedrock AgentCore Demo for a Customer Support Agent. This demonstration illustrates the process of deploying an agent, authenticating users, invoking agent functions, and implementing an AgentCore Policy for real-time refund limit enforcement. It mirrors the core functionality of the CLI-based Get Started with Amazon Bedrock AgentCore Demo but offers enhanced documentation and the opportunity to review the code beforehand.
Amazon Web Services
After nearly a week, and once several reported bugs and obstacles were resolved, I successfully concluded the demonstration. The subsequent terminal logs detail the process, beginning with the deployment script. For brevity, the AWS command-line login, which involves a web-based authentication redirect to establish local session credentials, has been omitted.
martinheller@Mac customer-support-agent-with-agentcore % scripts/deploy.sh ==> Pre-flight checks Verifying Bedrock model access (global.anthropic.claude-sonnet-4-5-20250929-v1:0)... WARNING: Could not invoke Bedrock model (global.anthropic.claude-sonnet-4-5-20250929-v1:0). Possible reasons:1. Anthropic first-time usage form not completed. Complete it in the Bedrock console Playground by selecting any Anthropic Claude model. Details: https://aws.amazon.com/blogs/security/simplified-amazon-bedrock-model-access/ 2. Your current IAM identity lacks bedrock:InvokeModel permission. Note: the deployed agent uses its own execution role, so this may not be a problem. Verify after deployment with: uv run agentcore invoke The deploy will continue. All checks passed.==> Installing Python dependencies (uv sync)
Resolved 110 packages in 14ms
Audited 103 packages in 11ms==> Installing CDK dependencies (npm install)
up to date, audited 337 packages in 901ms
37 packages are looking for funding
runnpm fundfor details3 vulnerabilities (1 moderate, 2 high)
To address all issues, run:
npm audit fixRun
npm auditfor details.==> Bootstrapping CDK (if needed)
> cdk@0.1.0 cdk
> cdk bootstrap⏳ Bootstrapping environment aws://577405208411/us-east-2...
Trusted accounts for deployment: (none)
Trusted accounts for lookup: (none)
Using default execution policy of 'arn:aws:iam::aws:policy/AdministratorAccess'. Pass '--cloudformation-execution-policies' to customize.
✅ Environment aws://577405208411/us-east-2 bootstrapped (no changes).NOTICES (What's this? https://github.com/aws/aws-cdk/wiki/CLI-Notices)
37013 (cli) cdk watch triggers deployment unexpectedly or not at all
Overview: Do not use 'cdk watch' with this version of the cdk cli. Upgrade to ^2.1106.0. Affected versions: cli: >=2.1103.0 <2.1106.0 More information at: https://github.com/aws/aws-cdk/issues/3701334892 CDK CLI collects telemetry data on command usage starting at version 2.1100.0 (unless opted out)
Overview: We do not collect customer content and we anonymize the telemetry we do collect. See the attached issue for more information on what data is collected, why, and how to opt-out. Telemetry will NOT be collected for any CDK CLI version prior to version 2.1100.0 - regardless of opt-in/out. You can also view the telemetry we collect by logging it to a local file, by adding `--telemetry-file=my/local/file` to any `cdk` command. Affected versions: cli: >=2.1100.0 <2.1106.1 More information at: https://github.com/aws/aws-cdk/issues/34892If you don’t want to see a notice anymore, use "cdk acknowledge <id>". For example, "cdk acknowledge 37013".
==> Deploying all stacks
> cdk@0.1.0 cdk:deploy:ci
> cdk deploy --all --require-approval never --outputs-file /Volumes/Glauce/repos/amazon-bedrock-agentcore-samples/05-blueprints/customer-support-agent-with-agentcore/cdk-outputs.json✨ Synthesis time: 2.29s
supportAgentDemo-DockerImageStack: start: Building supportAgentDemo-DockerImageStack Template
supportAgentDemo-DockerImageStack: success: Built supportAgentDemo-DockerImageStack Template
supportAgentDemo-DockerImageStack: start: Building supportAgentDemo-AppImage
supportAgentDemo-DockerImageStack: start: Publishing supportAgentDemo-DockerImageStack Template (current_account-current_region-f5e9391a)
supportAgentDemo-DockerImageStack: success: Published supportAgentDemo-DockerImageStack Template (current_account-current_region-f5e9391a)0 building with "desktop-linux" instance using docker driver
1 [internal] load build definition from Dockerfile
1 transferring dockerfile: 795B done
1 DONE 0.0s
2 [internal] load metadata for ghcr.io/astral-sh/uv:python3.13-bookworm-slim
2 DONE 3.6s
3 [internal] load .dockerignore
3 transferring context: 814B done
3 DONE 0.0s
4 [1/7] FROM ghcr.io/astral-sh/uv:python3.13-bookworm-slim@sha256:531f855bda2c73cd6ef67d56b733b357cea384185b3022bd09f05e002cd144ca
4 DONE 0.0s
5 [internal] load build context
5 transferring context: 1.87MB 0.0s done
5 DONE 0.0s
6 [5/7] RUN uv pip install aws-opentelemetry-distro==0.12.2
6 CACHED
7 [4/7] RUN uv pip install -r pyproject.toml
7 CACHED
8 [2/7] WORKDIR /app
8 CACHED
9 [3/7] COPY pyproject.toml pyproject.toml
9 CACHED
10 [6/7] RUN useradd -m -u 1000 bedrock_agentcore
10 CACHED
11 [7/7] COPY . .
11 DONE 0.0s
12 exporting to image
12 exporting layers done
12 writing image sha256:103477e07cdce77a6d41dc7f875d781cb408dc59556cdf205c5dddeed5cc50d0 done
12 naming to docker.io/library/cdkasset-9d592d01e5467aa35239774fad1da2f13bc79a6fdfad62b7b89146b9d8f12462 done
12 DONE 0.0s
View build details: docker-desktop://dashboard/build/desktop-linux/desktop-linux/jogcv8dnbz67ymx5fi5dnrfbt
supportAgentDemo-DockerImageStack: success: Built supportAgentDemo-AppImage
supportAgentDemo-DockerImageStack: start: Publishing supportAgentDemo-AppImage (current_account-current_region-eadbec27)
supportAgentDemo-AgentCoreStack: start: Building supportAgentDemo-AgentCoreStack Template
supportAgentDemo-AgentCoreStack: success: Built supportAgentDemo-AgentCoreStack Template
The push refers to repository [577405208411.dkr.ecr.us-east-2.amazonaws.com/cdk-hnb659fds-container-assets-577405208411-us-east-2]
f75c8a00d29b: Preparing
e9cefea56108: Preparing
6ad1a9eaa547: Preparing
2c4f33ca63a0: Preparing
bd07e5776977: Preparing
65d80ab29699: Preparing
d700e87997ad: Preparing
b27347ec89d2: Preparing
733eb94a487b: Preparing
dac1af1d7cd9: Preparing
bd390c400455: Preparing
d700e87997ad: Waiting
b27347ec89d2: Waiting
733eb94a487b: Waiting
dac1af1d7cd9: Waiting
bd390c400455: Waiting
65d80ab29699: Waiting
e9cefea56108: Layer already exists
6ad1a9eaa547: Layer already exists
2c4f33ca63a0: Layer already exists
bd07e5776977: Layer already exists
65d80ab29699: Layer already exists
d700e87997ad: Layer already exists
733eb94a487b: Layer already exists
b27347ec89d2: Layer already exists
dac1af1d7cd9: Layer already exists
bd390c400455: Layer already exists
f75c8a00d29b: Pushed
9d592d01e5467aa35239774fad1da2f13bc79a6fdfad62b7b89146b9d8f12462: digest: sha256:455ae21c8896a1df8558466d99b87e0f038e79b5baaf00514f810f95183562d0 size: 2627
supportAgentDemo-DockerImageStack: success: Published supportAgentDemo-AppImage (current_account-current_region-eadbec27)
supportAgentDemo-DockerImageStack
supportAgentDemo-DockerImageStack: deploying... [1/2]
supportAgentDemo-DockerImageStack: creating CloudFormation changeset...✅ supportAgentDemo-DockerImageStack
✨ Deployment time: 13.06s
Outputs:
supportAgentDemo-DockerImageStack.ImageUri = 577405208411.dkr.ecr.us-east-2.amazonaws.com/cdk-hnb659fds-container-assets-577405208411-us-east-2:9d592d01e5467aa35239774fad1da2f13bc79a6fdfad62b7b89146b9d8f12462
Stack ARN:
arn:aws:cloudformation:us-east-2:577405208411:stack/supportAgentDemo-DockerImageStack/6d08ccf0-1664-11f1-8de3-0a00ca3e2d9f✨ Total time: 15.35s
supportAgentDemo-AgentCoreStack: start: Publishing supportAgentDemo-AgentCoreStack Template (current_account-current_region-8aa3c459)
supportAgentDemo-AgentCoreStack: success: Published supportAgentDemo-AgentCoreStack Template (current_account-current_region-8aa3c459)✅ supportAgentDemo-AgentCoreStack
✨ Deployment time: 39.12s
Outputs:
supportAgentDemo-AgentCoreStack.AccountId = 577405208411
supportAgentDemo-AgentCoreStack.AuthorizerDiscoveryUrl = https://cognito-idp.us-east-2.amazonaws.com/us-east-2_NaZm7AOfz/.well-known/openid-configuration
supportAgentDemo-AgentCoreStack.ClientId = 7nvmhkv45gh933mircjoji1gfe
supportAgentDemo-AgentCoreStack.CognitoDomain = supportagentdemo-577405208411-us-east-2.auth.us-east-2.amazoncognito.com
supportAgentDemo-AgentCoreStack.GatewayId = supportagentdemo-gateway-7d3m0sdfzy
supportAgentDemo-AgentCoreStack.GatewayUrl = https://supportagentdemo-gateway-7d3m0sdfzy.gateway.bedrock-agentcore.us-east-2.amazonaws.com/mcp
supportAgentDemo-AgentCoreStack.MemoryArn = arn:aws:bedrock-agentcore:us-east-2:577405208411:memory/supportAgentDemo_Memory_v2-bLfMFAGQmp
supportAgentDemo-AgentCoreStack.MemoryId = supportAgentDemo_Memory_v2-bLfMFAGQmp
supportAgentDemo-AgentCoreStack.Region = us-east-2
supportAgentDemo-AgentCoreStack.RuntimeArn = arn:aws:bedrock-agentcore:us-east-2:577405208411:runtime/supportAgentDemo_Agent-U90VrdH6Rf
supportAgentDemo-AgentCoreStack.RuntimeId = supportAgentDemo_Agent-U90VrdH6Rf
supportAgentDemo-AgentCoreStack.RuntimeName = supportAgentDemo_Agent
supportAgentDemo-AgentCoreStack.UserPoolId = us-east-2_NaZm7AOfz
Stack ARN:
arn:aws:cloudformation:us-east-2:577405208411:stack/supportAgentDemo-AgentCoreStack/74e9b510-1664-11f1-8ec7-0606ac99759d✨ Total time: 41.4s
NOTICES (What's this? https://github.com/aws/aws-cdk/wiki/CLI-Notices)
37013 (cli) cdk watch triggers deployment unexpectedly or not at all
Overview: Do not use 'cdk watch' with this version of the cdk cli. Upgrade to ^2.1106.0. Affected versions: cli: >=2.1103.0 <2.1106.0 More information at: https://github.com/aws/aws-cdk/issues/3701334892 CDK CLI collects telemetry data on command usage starting at version 2.1100.0 (unless opted out)
Overview: We do not collect customer content and we anonymize the telemetry we do collect. See the attached issue for more information on what data is collected, why, and how to opt-out. Telemetry will NOT be collected for any CDK CLI version prior to version 2.1100.0 - regardless of opt-in/out. You can also view the telemetry we collect by logging it to a local file, by adding `--telemetry-file=my/local/file` to any `cdk` command. Affected versions: cli: >=2.1100.0 <2.1106.1 More information at: https://github.com/aws/aws-cdk/issues/34892If you don’t want to see a notice anymore, use "cdk acknowledge <id>". For example, "cdk acknowledge 37013".
CDK outputs written to /Volumes/Glauce/repos/amazon-bedrock-agentcore-samples/05-blueprints/customer-support-agent-with-agentcore/cdk-outputs.json==> Generating .bedrock_agentcore.yaml
Generated /Volumes/Glauce/repos/amazon-bedrock-agentcore-samples/05-blueprints/customer-support-agent-with-agentcore/.bedrock_agentcore.yaml============================================================
Deployment complete!Next steps:
Check agent status:
uv run agentcore statusCreate a Cognito user:
uv run scripts/cognito-user.py --createLog in and set your bearer token:
eval $(uv run scripts/cognito-user.py --login --export)Invoke the agent:
uv run agentcore invoke '{"prompt": "Who am I?"}'To tear down all resources later:
scripts/teardown.sh
During deployment, several warnings appeared. It became apparent that certain pre-flight checks were unreliable; even after resolving an identified issue, the script would re-flag it in subsequent runs.
It’s important to note that the setup script established a Docker pod on my local machine and registered it with AWS’s directory. Re-running the script generated new Docker images, necessitating manual deletion of the older versions.
I’ve omitted the agent status script (step 1 mentioned earlier). Initially, it lacked the required
uv runprefix, preventing theagentcorecommand, resident within a Python environment, from being recognized. After rectifying this, it still produced false negatives during initial attempts until AWS engineers resolved a parsing issue, after which it functioned correctly.
Similarly, the user creation script also requires the uv run prefix:
martinheller@Mac customer-support-agent-with-agentcore % uv run scripts/cognito-user.py --create
Choose a demo user:
- john@example.com (John Doe)
- jane@example.com (Jane Smith)
Enter 1 or 2: 1
Password requirements:
- At least 8 characters
- At least one uppercase letter (A-Z)
- At least one lowercase letter (a-z)
- At least one number (0-9)
- At least one special character (e.g. !@#$%^&*)
Password:
User already exists: john@example.com
Password set for: john@example.com
Added to group: standard
User ready. Login with:
eval $(uv run scripts/cognito-user.py --login --export)
The Cognito user must correspond to an entry in a pre-existing demo user database, hence the limited selection of two options.
martinheller@Mac customer-support-agent-with-agentcore % eval $(uv run scripts/cognito-user.py --login --export)
Opening browser for authentication...
Waiting for callback...
Login successful. BEDROCK_AGENTCORE_BEARER_TOKEN is now set.
The Cognito login process obtains the OAuth bearer token essential for the remainder of the session; this token expires after one hour, a detail I discovered firsthand. It’s necessary to log into both AWS and Cognito. AWS clarifies that this dual authentication is intentionally designed to safeguard the integrity of agents developed. Cognito verifies the user’s identity (via the one-hour OAuth bearer token), while AWS confirms the service boundary.
martinheller@Mac customer-support-agent-with-agentcore % uv run agentcore invoke '{"prompt": "Who am I?"}'
Using bearer token for OAuth authentication
Using JWT authentication
I'll look up your account information using your email address.Hello! You are **John Doe** (Customer ID: CUST-001). Your account is registered with the email john@example.com, and you've been a member since June 1, 2023. How can I help you today?
╭──────────────────────────────────────────────────────── supportAgentDemo_Agent ────────────────────────────────────────────────────────╮
│ Session: 74d74b58-aa7d-4b8b-9515-e0931743ce1d │
│ ARN: arn:aws:bedrock-agentcore:us-east-2:577405208411:runtime/supportAgentDemo_Agent-U90VrdH6Rf │
│ Logs: aws logs tail /aws/bedrock-agentcore/runtimes/supportAgentDemo_Agent-U90VrdH6Rf-DEFAULT --log-stream-name-prefix │
│ "2026/03/02/[runtime-logs]" --follow │
│ aws logs tail /aws/bedrock-agentcore/runtimes/supportAgentDemo_Agent-U90VrdH6Rf-DEFAULT --log-stream-name-prefix │
│ "2026/03/02/[runtime-logs]" --since 1h │
│ GenAI Dashboard: https://console.aws.amazon.com/cloudwatch/home?region=us-east-2#gen-ai-observability/agent-core │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
This particular interaction successfully leveraged the Claude model. Should an error occur at this stage, it likely indicates a lack of Anthropic permission or insufficient Bedrock Claude quota. Obtaining a quota typically involves submitting an AWS form and awaiting approval for a few days. The subsequent query, requesting an order list, similarly routes through the model.
martinheller@Mac customer-support-agent-with-agentcore % uv run agentcore invoke '{"prompt": "Show me my recent orders"}'
Using bearer token for OAuth authentication
Using JWT authentication
I'll look up your recent orders for you.Now let me get the full details for each of these orders to show you what items were in them.Here are your recent orders:
1. Order ORD-12430 - Ordered Feb 5, 2025 | Delivered Feb 10, 2025
- 4K Monitor (1x) - $399.00
- Total: $399.00 | Status: ✓ Delivered
2. Order ORD-12420 - Ordered Feb 1, 2025 | Delivered Feb 4, 2025
- Phone Case (1x) - $29.99
- Total: $29.99 | Status: ✓ Delivered
3. Order ORD-12410 - Ordered Jan 25, 2025 | Delivered Jan 29, 2025
- Mechanical Keyboard (1x) - $149.99
- Total: $149.99 | Status: ✓ Delivered
4. Order ORD-12400 - Ordered Jan 20, 2025 | Delivered Jan 23, 2025
- USB-C Charging Cable (2x) - $12.99 each
- Total: $25.98 | Status: ✓ Delivered
5. Order ORD-12345 - Ordered Jan 15, 2025 | Delivered Jan 20, 2025
- Wireless Headphones (1x) - $79.99
- Total: $79.99 | Status: ✓ Delivered
6. Order ORD-12300 - Ordered Jan 2, 2025 | Delivered Jan 8, 2025
- Running Shoes (1x) - $249.00
- Total: $249.00 | Status: ✓ Delivered
All of your recent orders have been delivered successfully! Is there anything specific you'd like to know about any of these orders?
╭──────────────────────────────────────────────────────── supportAgentDemo_Agent ────────────────────────────────────────────────────────╮
│ Session: 74d74b58-aa7d-4b8b-9515-e0931743ce1d │
│ ARN: arn:aws:bedrock-agentcore:us-east-2:577405208411:runtime/supportAgentDemo_Agent-U90VrdH6Rf │
│ Logs: aws logs tail /aws/bedrock-agentcore/runtimes/supportAgentDemo_Agent-U90VrdH6Rf-DEFAULT --log-stream-name-prefix │
│ "2026/03/02/[runtime-logs]" --follow │
│ aws logs tail /aws/bedrock-agentcore/runtimes/supportAgentDemo_Agent-U90VrdH6Rf-DEFAULT --log-stream-name-prefix │
│ "2026/03/02/[runtime-logs]" --since 1h │
│ GenAI Dashboard: https://console.aws.amazon.com/cloudwatch/home?region=us-east-2#gen-ai-observability/agent-core │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
The following query illustrates how to request a refund from the customer support agent. As this pertains to a low-value item, it is expected to be processed without complications.
martinheller@Mac customer-support-agent-with-agentcore % uv run agentcore invoke '{"prompt": "I need a refund for order ORD-12420. The phone case was damaged."}'
Using bearer token for OAuth authentication
Using JWT authentication
I'll process a refund for your damaged phone case from order ORD-12420.Perfect! Your refund has been processed successfully.
Refund Details:
- Refund ID: REF-DC32B
- Order: ORD-12420 (Phone Case)
- Amount: $29.99
- Reason: Damaged item
- Status: Processed
You should receive the refund in your original payment method within 3-5 business days.
I'm sorry to hear the phone case arrived damaged. Is there anything else I can help you with today?
╭──────────────────────────────────────────────────────── supportAgentDemo_Agent ────────────────────────────────────────────────────────╮
│ Session: 74d74b58-aa7d-4b8b-9515-e0931743ce1d │
│ ARN: arn:aws:bedrock-agentcore:us-east-2:577405208411:runtime/supportAgentDemo_Agent-U90VrdH6Rf │
│ Logs: aws logs tail /aws/bedrock-agentcore/runtimes/supportAgentDemo_Agent-U90VrdH6Rf-DEFAULT --log-stream-name-prefix │
│ "2026/03/02/[runtime-logs]" --follow │
│ aws logs tail /aws/bedrock-agentcore/runtimes/supportAgentDemo_Agent-U90VrdH6Rf-DEFAULT --log-stream-name-prefix │
│ "2026/03/02/[runtime-logs]" --since 1h │
│ GenAI Dashboard: https://console.aws.amazon.com/cloudwatch/home?region=us-east-2#gen-ai-observability/agent-core │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
Conversely, this subsequent refund request ideally ought to be either declined outright or escalated to a human customer support agent for review and authorization.
martinheller@Mac customer-support-agent-with-agentcore % uv run agentcore invoke '{"prompt": "I need a refund of $399 for order ORD-12430. The monitor has dead pixels."}'
Using bearer token for OAuth authentication
Using JWT authentication
I'll process a refund for your 4K Monitor from order ORD-12430 due to the dead pixels.Your refund has been successfully processed!
Refund Details:
- Refund ID: REF-5DEA4
- Order: ORD-12430 (4K Monitor)
- Amount: $399.00
- Reason: Damaged item (dead pixels)
- Status: Processed
You should receive the refund to your original payment method within 3-5 business days.
I'm sorry the monitor had dead pixels. If you'd like to order a replacement, please let me know and I can assist you with that. Is there anything else I can help you with?
╭──────────────────────────────────────────────────────── supportAgentDemo_Agent ────────────────────────────────────────────────────────╮
│ Session: 74d74b58-aa7d-4b8b-9515-e0931743ce1d │
│ ARN: arn:aws:bedrock-agentcore:us-east-2:577405208411:runtime/supportAgentDemo_Agent-U90VrdH6Rf │
│ Logs: aws logs tail /aws/bedrock-agentcore/runtimes/supportAgentDemo_Agent-U90VrdH6Rf-DEFAULT --log-stream-name-prefix │
│ "2026/03/02/[runtime-logs]" --follow │
│ aws logs tail /aws/bedrock-agentcore/runtimes/supportAgentDemo_Agent-U90VrdH6Rf-DEFAULT --log-stream-name-prefix │
│ "2026/03/02/[runtime-logs]" --since 1h │
│ GenAI Dashboard: https://console.aws.amazon.com/cloudwatch/home?region=us-east-2#gen-ai-observability/agent-core │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
However, the refund was processed. The intended solution for this behavior (a feature of the demo, not a defect) involves implementing additional policies.
Displayed here is the policy designed to prevent the model from processing refunds exceeding $100. The English prompt on the left was used to generate the Cedar policy shown on the right.
Amazon Web Services
Upon activating the policy, I re-attempted the request, and it was subsequently denied.
martinheller@Mac customer-support-agent-with-agentcore % uv run agentcore invoke '{"prompt": "I need a full refund for order ORD-12300. The shoes dont fit."}'
Using bearer token for OAuth authentication
Using JWT authentication
I'll process a refund for your Running Shoes from order ORD-12300.I'm unable to process this refund request. The system has denied the refund with the following message:
"Tool call not allowed due to policy enforcement [No policy applies to the request (denied by default).]"
This appears to be a policy restriction. Given that order ORD-12300 was delivered on January 8, 2025 (over a month ago), it may be outside the refund window for non-defective items or there may be specific policies regarding fit-related returns.
I recommend:
- Checking our return policy for the timeframe allowed for returns
- Contacting our returns department directly for assistance with this older order
- Inquiring about exchange options if available
I apologize for the inconvenience. Is there anything else I can help you with today?
╭──────────────────────────────────────────────────────── supportAgentDemo_Agent ────────────────────────────────────────────────────────╮
│ Session: 74d74b58-aa7d-4b8b-9515-e0931743ce1d │
│ ARN: arn:aws:bedrock-agentcore:us-east-2:577405208411:runtime/supportAgentDemo_Agent-U90VrdH6Rf │
│ Logs: aws logs tail /aws/bedrock-agentcore/runtimes/supportAgentDemo_Agent-U90VrdH6Rf-DEFAULT --log-stream-name-prefix │
│ "2026/03/02/[runtime-logs]" --follow │
│ aws logs tail /aws/bedrock-agentcore/runtimes/supportAgentDemo_Agent-U90VrdH6Rf-DEFAULT --log-stream-name-prefix │
│ "2026/03/02/[runtime-logs]" --since 1h │
│ GenAI Dashboard: https://console.aws.amazon.com/cloudwatch/home?region=us-east-2#gen-ai-observability/agent-core │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
While the externally enforced policy functioned as intended, the model seemed perplexed by the denial. True to its nature, Claude fabricated reasons and offered three unrelated suggestions. One might expect the model to be aware of active policies, but external policy application prevents malicious prompts from coercing the model into authorizing substantial refunds. A secure method to address this informational gap, however, remains beyond my current scope.
Incidentally, despite numerous attempts, the cumulative AWS charges incurred from running this demo amounted to a mere $0.35.
Establishing a Robust Agent Foundation
Amazon Bedrock AgentCore represents a commendable effort to construct an enterprise-grade infrastructure and operational layer for scalable AI agent deployment and management. The core services appear robust. Although the demonstration I undertook revealed several bugs and documentation inaccuracies, these were promptly reported and swiftly addressed by AWS engineers.
My primary reservation remains regarding the policy module’s interaction with the model. Ideally, a mechanism should exist to communicate the specific reason for an action’s denial back to the model, preventing it from fabricating explanations. The implementation of such a solution within the current architecture is unclear to me.
Pricing Structure
Pricing varies based on usage. Refer to https://aws.amazon.com/bedrock/agentcore/pricing/ and navigate to the pricing table and examples for detailed information.
Supported Platforms
Server-side: AWS. Client-side: Compatible with macOS, Linux, and Windows operating systems.
Advantages
- Comprehensive suite of pertinent service modules
- Abundant and varied examples
Disadvantages
- Documentation can be complex and confusing due to numerous options
- The provided samples appear to be in an early, testing phase
