Amazon Bedrock AgentCore is AWS’s managed runtime for multi-agent systems. OPLOG, a fulfillment company processing millions of items monthly, deployed three specialized agents to handle sales pipeline management, data quality enforcement, and prospect research. The implementation used Strands Agents SDK, Claude Sonnet, and Bedrock Knowledge Bases for RAG. The results were concrete: 35% reduction in sales cycles, 91% improvement in CRM data completeness, and 98% reduction in manual research time.
The interesting part is not the business metrics. It’s what the deployment model reveals about how managed platforms handle agent lifecycle, inter-agent communication, and the boundary between SDK-defined agents and runtime orchestration.
The Three-Agent Architecture
OPLOG’s system splits business intelligence work across three agents:
Sales Pipeline Agent: Monitors HubSpot CRM, identifies stalled deals, analyzes conversation history from Microsoft Teams, and suggests next actions. This agent handles temporal reasoning (when did the last touchpoint happen?) and context synthesis (what was discussed?).
Data Quality Agent: Scans CRM records for missing fields, validates data completeness, and flags inconsistencies. This is the enforcer. It runs scheduled audits and pushes corrections back to HubSpot.
Prospect Research Agent: Takes a company name or domain, searches external sources, retrieves relevant context from Knowledge Bases, and assembles a research brief. This agent is the heavy RAG user.
Each agent has distinct tool access patterns. The Sales Pipeline Agent needs read access to CRM and Teams APIs. The Data Quality Agent needs write access to CRM. The Prospect Research Agent needs internet search and Knowledge Base queries but no write permissions to production systems.
SDK to Runtime: What Strands Compiles To
Strands Agents SDK is a Python abstraction layer that defines agents, tools, and workflows. When you deploy to AgentCore, the SDK compiles your agent definitions into Bedrock’s native agent format. This is not a simple JSON export. The SDK handles:
- Tool schema translation from Python type hints to Bedrock’s OpenAPI-style function definitions
- State management configuration (how long does an agent remember context?)
- Routing rules (which agent handles which input patterns?)
- Error handling and retry policies
The compilation step is where you lose visibility. Strands SDK gives you a clean Python interface. AgentCore gives you a managed runtime. The gap between them is where debugging gets hard. You cannot inspect the intermediate representation. You cannot see how AgentCore interprets your tool definitions. You trust the SDK to generate correct Bedrock configurations.
This is the trade-off of managed platforms. You get deployment simplicity and operational offload. You lose the ability to inspect and modify the runtime behavior directly.
Agent Isolation and Execution Contexts
AgentCore runs multiple agents in the same Bedrock environment. Each agent gets its own execution context, but they share the underlying infrastructure. The isolation model is logical, not physical. Agents do not run in separate containers or VMs. They run as distinct state machines within Bedrock’s orchestration layer.
State isolation happens at the session level. Each agent maintains its own conversation history, tool call results, and intermediate reasoning steps. When the Sales Pipeline Agent calls a tool, the result is stored in that agent’s session. The Data Quality Agent cannot see it unless you explicitly pass data between agents.
Inter-agent communication is not built in. If you want agents to coordinate, you have two options:
- Shared data layer: Agents write results to a common database (DynamoDB, S3, RDS). Other agents poll or subscribe to changes.
- Orchestrator pattern: A parent workflow (Step Functions, Lambda) invokes agents in sequence and passes outputs as inputs.
OPLOG’s implementation uses the orchestrator pattern. A Step Functions workflow triggers the Data Quality Agent first, then the Sales Pipeline Agent, then the Prospect Research Agent. Each agent runs independently. The workflow handles sequencing and error recovery.
Tool Call Routing and Knowledge Base Integration
AgentCore routes tool calls through Bedrock’s action groups. When an agent decides to call a tool, it generates a structured request. Bedrock validates the request against the tool schema, invokes the backing Lambda function or API Gateway endpoint, and returns the result to the agent.
For Knowledge Bases, the routing is simpler. Agents call a built-in retrieval action. Bedrock queries the Knowledge Base (which is backed by OpenSearch Serverless or Amazon Aurora), retrieves relevant documents, and injects them into the agent’s context window. The agent does not see the retrieval mechanics. It just gets text chunks.
The Prospect Research Agent uses this pattern heavily. It takes a company name, queries the Knowledge Base for internal documents (past proposals, contracts, meeting notes), and combines that with external search results. The Knowledge Base acts as long-term memory. The agent’s session context is short-term memory.
Tool call latency matters. Each tool invocation adds round-trip time. If an agent needs to call five tools sequentially, you pay five round trips. AgentCore does not batch tool calls automatically. You can optimize by designing tools that return richer payloads (one call instead of three), but that increases tool complexity.
Observability Gaps in Managed Runtimes
AgentCore exposes basic observability through CloudWatch Logs and X-Ray traces. You can see:
- Agent invocation timestamps
- Tool call requests and responses
- LLM token usage
- Error messages and stack traces
You cannot see:
- Intermediate reasoning steps (the agent’s internal monologue before deciding to call a tool)
- Prompt templates used by AgentCore (these are managed by AWS)
- Exact retrieval queries sent to Knowledge Bases
- Why an agent chose one tool over another when multiple tools match the input
This is the observability boundary of managed platforms. You get operational metrics. You do not get introspection into the agent’s decision-making process. If an agent makes a bad tool choice, you can see the tool call. You cannot see why the agent thought that tool was appropriate.
For debugging, you rely on:
- CloudWatch Logs for tool call sequences
- X-Ray traces for latency analysis
- Manual testing with known inputs to verify behavior
OPLOG’s team built custom dashboards that aggregate CloudWatch metrics and visualize agent activity over time. This helps identify patterns (the Data Quality Agent runs every hour, the Sales Pipeline Agent runs on-demand), but it does not help debug individual agent decisions.
Deployment Shape and Versioning
AgentCore agents are versioned resources. Each deployment creates a new agent version. You can:
- Deploy a new version without affecting the current version
- Route traffic to specific versions using aliases
- Roll back by switching the alias to a previous version
This is standard infrastructure-as-code deployment. The interesting part is how versioning interacts with state. If you deploy a new version of the Sales Pipeline Agent with updated tool definitions, existing sessions continue using the old version until they complete. New sessions use the new version. This prevents mid-conversation disruption but complicates rollout validation.
OPLOG uses a blue-green deployment pattern:
- Deploy new agent version to AgentCore
- Create a new alias pointing to the new version
- Run integration tests against the new alias
- Switch production traffic to the new alias
- Monitor for errors
- Roll back if needed by switching the alias back
This works for stateless agents. For stateful agents (those that maintain long-running conversations), you need a migration strategy. AgentCore does not provide built-in state migration. You handle it in your application layer.
Security Boundaries and IAM Integration
Each agent runs with an IAM execution role. The role defines what the agent can access: which Lambda functions it can invoke, which Knowledge Bases it can query, which APIs it can call. This is standard AWS IAM.
The security boundary is at the tool level. If you give an agent a tool that writes to a database, the agent can write to that database. There is no additional sandboxing. The agent’s LLM can generate arbitrary tool calls within the schema you defined. If the schema allows deletion, the agent can delete records.
OPLOG mitigated this by:
- Giving the Data Quality Agent write access only to specific CRM fields (not full record deletion)
- Requiring human approval for high-risk actions (the Sales Pipeline Agent suggests actions but does not execute them)
- Logging all tool calls to an audit trail (S3 bucket with versioning enabled)
The Prospect Research Agent has no write access to production systems. It only reads from Knowledge Bases and external APIs. This limits the blast radius if the agent misbehaves.
Failure Modes and Error Handling
AgentCore agents fail in predictable ways:
Tool call timeout: The backing Lambda or API does not respond within the configured timeout. AgentCore retries up to three times, then returns an error to the agent. The agent can handle the error (try a different tool, ask for clarification) or fail the session.
Invalid tool call: The agent generates a tool call that does not match the schema. AgentCore rejects it and asks the agent to try again. This happens when the LLM hallucinates parameter names or types.
Knowledge Base retrieval failure: The Knowledge Base is unavailable or returns no results. The agent proceeds without the retrieved context. This degrades output quality but does not crash the session.
LLM rate limit: Claude Sonnet has per-account rate limits. If OPLOG’s agents hit the limit, AgentCore queues requests and retries with exponential backoff. This adds latency but prevents hard failures.
OPLOG’s error handling strategy:
- Wrap high-risk tool calls in try-except blocks at the SDK level
- Configure aggressive timeouts (5 seconds for most tools, 30 seconds for external APIs)
- Implement circuit breakers for external dependencies (if HubSpot API fails three times in a row, stop calling it for 5 minutes)
- Send error notifications to Slack for manual intervention
Trade-offs: Managed vs. Self-Hosted
| Dimension | AgentCore (Managed) | Self-Hosted (LangGraph, CrewAI) |
|---|---|---|
| Deployment speed | Minutes (SDK compile + deploy) | Hours (container build, orchestration setup) |
| Observability depth | CloudWatch + X-Ray (surface-level) | Full control (custom logging, tracing, introspection) |
| Cost predictability | Pay-per-invocation + token usage | Fixed infrastructure cost (EC2, ECS) |
| Agent isolation | Logical (shared runtime) | Physical (separate containers) |
| Versioning | Built-in aliases and rollback | Manual (CI/CD pipelines) |
| Debugging complexity | High (opaque runtime) | Medium (you control the stack) |
| Scaling | Automatic (AWS handles it) | Manual (you configure autoscaling) |
AgentCore optimizes for operational simplicity. You do not manage servers, orchestration, or scaling. You pay for that with reduced visibility and control.
Self-hosted frameworks give you full control. You can inspect every step of agent execution, customize the orchestration logic, and optimize for your specific workload. You pay for that with operational overhead.
Technical Verdict
Use AgentCore when:
- You need fast deployment and do not want to manage infrastructure
- Your agents have well-defined tool schemas and predictable execution patterns
- You trust AWS to handle scaling, retries, and operational concerns
- Your observability needs are met by CloudWatch and X-Ray
- You are already using Bedrock for LLM inference and Knowledge Bases for RAG
Avoid AgentCore when:
- You need deep introspection into agent reasoning (why did it choose this tool?)
- Your agents require custom orchestration logic (conditional branching, complex state machines)
- You need physical isolation between agents (compliance, security)
- You want to optimize costs by running agents on reserved capacity
- You need to support LLMs outside the Bedrock ecosystem
OPLOG’s use case fits AgentCore well. The agents have clear responsibilities, the tool schemas are stable, and the team values deployment speed over deep observability. For teams building experimental multi-agent systems or those requiring fine-grained control, self-hosted frameworks remain the better choice.