AWS 2026-08-20

How AgentFlo built AI sales agents with Amazon Bedrock AgentCore - Part 1¶

Summary¶

AgentFlo (the agentic-commerce service by Salesflo) runs always-on AI sales, support, and ordering agents across messaging channels like WhatsApp, serving eCommerce merchants managing over $300 billion in annual transacted value across Shopify, WooCommerce, Magento, and SAP. This is Part 1 of a two-part AWS Architecture Blog series structured around five pillars of production-grade AI agents; Part 1 covers Velocity, Standardization, and Scalability (Part 2 covers Trust and Reliability). The architecture is built on Amazon Bedrock AgentCore (Runtime, Gateway, Policy, Observability) orchestrated by the Strands Agents SDK, with a Fargate messaging layer, an Lambda tool/API layer brokered through AgentCore Gateway over MCP, and a data layer of DynamoDB (sessions/carts), Aurora (orders), and an Amazon Bedrock Knowledge Base backed by S3 for RAG.

Architecture overview¶

Request flow:

Customer messages arrive via WhatsApp Graph API or web/mobile channels.
An Application Load Balancer routes into the AWS Fargate messaging layer, which handles authentication, image OCR, speech-to-text / text-to-speech (Opus OGG → MP3 transcription with fuzzy matching for product-name recognition), pre-turn guardrails, and prompt-injection detection. (AWS End User Messaging is named as an alternative channel.)
Validated requests flow into AgentCore Runtime, where the Strands Agents SDK orchestrates an agent that streams model inference to an external LLM.
AgentCore Gateway brokers tool calls (with IAM-based authorization) to a Lambda API layer (Cart, Product, Knowledge Base).
State persists across DynamoDB (session + cart tables), Aurora (order tables), and an Amazon Bedrock Knowledge Base backed by S3.
AgentCore Policy enforces deterministic, Cedar-based access control independent of model reasoning; Bedrock Guardrails can be embedded in Policy to filter prompt attacks, harmful content, and sensitive info on both requests and responses.
AgentCore Observability ingests logs/traces; Amazon Data Firehose captures every interaction into S3 for cost and revenue analytics.

AgentFlo evaluated several hosting options before choosing AgentCore for three capabilities: stateful sessions for long-running commerce conversations, per-session microVM agent runtime (hardware-level tenant isolation), and native MCP integration through the Gateway.

Key takeaways¶

Recipe-based deployment gives velocity. Merchants select from pre-configured recipes (sales agent, restaurant ordering, clinic receptionist, support, B2B reorder, cart recovery), each shipping with persona, language, tone, tool sets, prompt templates, knowledge sources, response packs, and business rules. One selection triggers an automated pipeline: the portal generates a Strands config → GitHub Actions packages the agent (tools, prompts, context) into a container → the container deploys to AgentCore Runtime with the right Gateway policies → the agent is live on WhatsApp within minutes. See recipe-based-agent-deployment. (Source: sources/2026-08-20-aws-how-agentflo-built-ai-sales-agents-with-amazon-bedrock-agentcore)
Strands uses a model-driven architecture. You define tools as Python functions, write a system prompt, and let the model handle orchestration — no rigid workflow graphs or hand-coded state machines. Adding a capability (e.g. loyalty enrollment) is a new tool function + a prompt update, not an orchestration-layer rewrite. See model-driven-agent-architecture.
A single domain-specialized agent beats multi-agent for most interactions. AgentFlo learned that one agent with domain knowledge and a curated tool set, maintaining unified context, converts better than multiple generalists coordinating. Multi-agent remains available for clean handoffs (e.g. sales → support). See single-agent-over-multi-agent.
The Gateway is the integration backbone. Each eCommerce integration (Shopify, WooCommerce, Magento, SAP, payment/shipping/loyalty providers) is defined as an MCP server connector; the Gateway handles discovery, auth, and routing. A single list_tools_sync() call exposes the full tool surface to the agent. OAuth tokens and platform credentials live in the Gateway, not in agent sessions. Onboarding a new service is a connector definition, not a re-architecture. See patterns/central-proxy-choke-point.
Cedar-based Policy is deterministic and reasoning-independent. AgentCore Policy enforces fine-grained, Cedar access rules that define which agent sessions can invoke which tools (e.g. a sales agent cannot call customer-support-only APIs) — enforced regardless of what the model decides.
microVM isolation is the multi-tenancy substrate. Each agent session runs in its own lightweight VM with dedicated CPU, memory, and filesystem, sanitized on termination; one merchant's sessions never interfere with another's. See concepts/micro-vm-isolation.
Everything scales independently and serverlessly. Message ingestion, agent execution, tool execution, state, analytics, and billing each absorb their own spikes; commerce conversations can spike 10–50× during flash sales without pre-provisioning. Tool calls scale separately from agent reasoning, so a burst of cart operations doesn't slow the agent loop.

Operational numbers¶

$300B+ annual transacted value across served merchants (per Salesflo).
~70% industry-wide cart-abandonment rate (the problem being addressed).
10–50× traffic spikes during flash sales / seasonal campaigns.
Stateful sessions up to 8 hours — a morning conversation can continue that evening in the same assisted session.
Two CLI commands (agentcore configure --entrypoint agent.py / agentcore launch) take a local Strands agent to a production endpoint — no Dockerfile, no API routing, no web framework to maintain. BedrockAgentCoreApp wraps the agent in the standard /invocations contract.
Model referenced: us.anthropic.claude-sonnet-5-20260630 (Bedrock model ID in the sample code).

Caveats¶

Vendor/customer architecture post, not an internal retrospective. Numbers like the $300B figure are attributed to Salesflo, not independently measured.
Part 1 of 2. Trust (guardrails for autonomous commercial action, real-time visibility) and Reliability (data foundation) are deferred to Part 2, as are business-results metrics and the roadmap (voice agents, server-side tool execution).
No latency / throughput / cost numbers are disclosed for AgentCore Runtime or Gateway internals — the microVM, scaling, and session-isolation mechanisms are described qualitatively.