Here is a Tuesday morning for a D2C ops coordinator at a $5M natural skincare brand. A customer escalates: they believe a product they received contains an allergen their order notes said to avoid. The coordinator opens Shopify to pull the order. Then a second tab for Odoo to check which lot number shipped. Then a PDF that might be the product spec sheet — except the Notion link is broken. Then a WhatsApp thread with the warehouse manager to ask which batch ran that week. Then the FSSAI compliance folder in Google Drive, which has three versions of the label document and no clear indication of which is current. Eleven minutes later, she has enough to draft a response. Forty escalations per day. That is over seven hours of tab-switching before she touches anything else.
Rocket Close — the title agency inside Rocket Companies — had the same structural problem at scale. Title examiners were researching state-specific requirements across fragmented internal systems, regulatory databases, and years of institutional knowledge. Their answer was Supercharger: an agentic AI built on AWS Strands Agents, Bedrock Knowledge Bases, and MCP tools that collapses multi-source research into a single natural language query. The result: 30% reduction in contact center volume, 3x query response latency improvement. The architecture they used translates directly to D2C operations — at a fraction of the infrastructure complexity. What the reference article doesn't cover is the step that actually blocks D2C teams from building it: the knowledge curation pre-work. Rocket Close had a production-grade title requirements database. D2C brands have a Notion page that was last updated eight months ago.
Running a D2C ops team that's drowning in tab-switching? Book a 30-min audit — Dhwani joins every call, we map your escalation types against the knowledge agent pattern and tell you what's buildable in your current stack. Written brief inside a week. No SDR layer.
What Strands Agents Is and Why It Matters for AWS-Native D2C Teams
Strands Agents is AWS's open-source Python framework for building production Bedrock agents. Where LangChain is a general-purpose abstraction layer that can route to any provider, Strands is designed specifically around the Bedrock API surface: model invocations, Knowledge Base retrieval, and MCP tool definitions are first-class constructs rather than adapters.
For D2C brands already running on AWS, that specificity has two practical consequences. First, no third-party SDK sits between your agent and Bedrock — Strands calls the Bedrock API directly, which means authorization, retry behavior, and streaming are AWS-managed and AWS-supported. When something breaks at 2am, the failure surface is smaller. Second, MCP tools defined in Strands compose naturally with Bedrock Knowledge Base retrieval inside a single agent reasoning pass. The agent can query your curated compliance document knowledge base and call your Shopify API to look up a specific order in the same response — without custom orchestration glue between the retrieval step and the API call step.
Rocket Close's architecture: WebSocket connection from the browser UI → JWT token validation → Strands Agent invocation → Knowledge Base retrieval + MCP tool selection → Atlas Web API for property data → synthesized response streamed back. The D2C equivalent replaces the WebSocket UI with a Slack bot, the Atlas Web API with Shopify and Odoo, and the state title requirements database with a curated D2C operations knowledge base. The agent framework and the Bedrock integration are identical.
The Eight-Source Problem in D2C Operations Research
The title examination problem Rocket Close solved has a specific shape: a knowledge worker needs to answer a question that requires combining information from multiple sources, each maintained separately, with no single system that has it all. D2C operations has the same shape.
A typical escalation at a $5M D2C brand touches some combination of these eight sources:
Shopify — order status, line items, lot number if tagged at fulfillment, return/exchange history. Almost always the first tab, but the answer rarely lives here alone.
Odoo — inventory lot tracking, RMA records, purchase order details for the specific batch, product variant specifications. Shopify shows what shipped; Odoo shows where it came from.
Carrier portal — tracking events, proof of delivery, declared weight, exception codes. Separate login for each carrier, and D2C brands at $3-8M GMV typically use 2-4 carriers depending on region and product category.
Product spec sheets — ingredient lists, allergen declarations, shelf life, storage requirements, country-of-origin. Usually a PDF in a folder that someone on the product team maintains, updated whenever the formulation changes, filed under a naming convention only they remember.
Compliance documents — FSSAI license details, FDA labeling requirements, Prop 65 applicability for California shipments, import/export restrictions for international orders. These change periodically and the ops coordinator is often the last to know.
Brand policy docs — return windows, exchange eligibility, warranty terms, edge-case handling. Usually a Notion page or a Google Doc that the founding team wrote once and hasn't been updated since a major policy change.
WhatsApp or Slack threads with the warehouse — batch issues, substitution decisions, holds on specific lots, verbal policy exceptions the ops lead made last month. Impossible to search, zero discoverability for new hires.
Email or ticket history — what was said to this customer before, what exceptions were made, whether the account has been flagged for abuse. Spread across Zendesk, Gmail, and Shopify customer notes.
An ops coordinator pulling information from all eight for a single escalation is not being inefficient. The information genuinely does not exist in one place. The Strands Agent build changes that by putting a single query interface over all eight sources simultaneously.
Curating the Knowledge Base Before the Agent Can Help
The Rocket Close article moves quickly past the step that most D2C teams hit as a hard blocker: building the knowledge base the agent queries. Rocket Close had a dedicated internal database of state-specific title requirements — structured, maintained, and queryable. That database is the foundation the entire Supercharger system rests on. Without it, the agent has no authoritative source to retrieve from.
For D2C operations, the knowledge base has four tiers with very different curation effort:
Tier 1: Static regulatory documents. FDA labeling guidance, FSSAI compliance PDFs, Prop 65 substance lists, carrier SLA documents, return policy terms from major platforms. These are stable (updated quarterly at most), exist as files, and ingest directly into Bedrock Knowledge Bases via S3. Curation effort: 2-3 days to collect, standardize filenames, and upload. These are the highest-value documents per curation hour because the agent can retrieve exact regulatory language rather than paraphrasing from memory.
Tier 2: Living operational documents. Your return policy, exchange rules, brand-side warranty terms, SKU-level shipping restrictions. These change when policy changes. A Lambda function synced to your Notion workspace can export updated pages to S3 weekly, triggering a Bedrock Knowledge Base sync. Curation effort: initial structure (1-2 days) + ongoing maintenance (30 minutes per policy change to ensure the Notion page is updated promptly).
Tier 3: Transaction data via MCP tools. Order status, inventory levels, lot tracking, RMA records, customer history. This tier requires zero curation because the data is already structured in Shopify and Odoo. MCP tool definitions wrap the Shopify Admin API and the Odoo XMLRPC or REST API, and the agent calls them at query time. The agent looks up live data, not cached snapshots — so the answer reflects the actual current state of the order or inventory record.
Tier 4: Institutional knowledge. The policy exceptions that exist only in the ops lead's head, the verbal agreements the warehouse made with a 3PL, the escalation handling the founding team decided informally during BFCM. This is the hardest tier and also the most common source of wrong agent answers if not addressed. The practical approach: before building, spend two weeks logging the most common escalation types and writing one-paragraph answers to each. Those 30 to 50 paragraphs, formatted as question-answer pairs and loaded as KB documents, become the highest-return knowledge assets the agent will ever have.
Not sure what's in each tier for your brand? Book 30 minutes with Dhwani — we run a knowledge audit as part of every ops agent engagement: what exists, where it lives, what needs to be written before the build starts. Written brief inside a week.
The D2C Ops Agent Architecture
The full D2C build has five components, all on AWS:
Bedrock Knowledge Base. An S3 bucket structured into prefix folders by knowledge tier: /regulatory/ for compliance PDFs, /policy/ for brand policy exports, /products/ for spec sheets. Bedrock's managed embedding and retrieval handles chunking and vector indexing automatically. No vector database to provision or maintain. A weekly Lambda job syncs Notion page exports into /policy/ and triggers a Knowledge Base sync job.
MCP tools for live data. Two Lambda functions: one wrapping the Shopify Admin GraphQL API (order lookup by order number or customer email, return status, line item details), one wrapping the Odoo API (inventory lot query, RMA record lookup, product variant specs). These are registered as MCP tool definitions in the Strands Agent configuration. The agent calls whichever tools are relevant to the query.
Strands Agent on Bedrock. A Python Lambda function running the Strands Agent with access to both the Knowledge Base retriever and the MCP tool definitions. The agent receives the ops coordinator's natural language query, decides whether to retrieve from the KB (regulatory/policy questions), call MCP tools (order/inventory questions), or both (product + order combined queries), and synthesizes a response with source citations.
Slack bot interface. An API Gateway WebSocket endpoint connected to the Strands Agent Lambda. Ops coordinators send a message to a dedicated Slack channel — "What allergens does [SKU] declare, and is this customer's [order number] still within return window?" — and the agent's response streams back within the thread. No new UI to learn, no additional login.
Bedrock Guardrails. A guardrail configuration that restricts responses to the knowledge scope — regulatory compliance, brand policy, and product information. Off-topic queries (personal questions, requests outside the ops domain) are blocked before they reach the model. This matches Rocket Close's security enforcement layer and prevents the agent from producing responses on topics it has no authoritative knowledge of, which matters particularly for compliance-sensitive product categories like beauty and food.
This build sits on our standard AI agent infrastructure for D2C brands. Total build time: 6 to 8 weeks, including the Notion sync Lambda, MCP tool definitions, and Slack integration. Tier 4 knowledge structuring runs in parallel with the build and is typically the pace-setting task.
Where the Rocket Close Architecture Simplifies for D2C
Rocket Close's implementation used Kubernetes for the WebSocket tier — an appropriate choice for a $billion company with the engineering team to operate it. For D2C at $3-10M GMV, that tier is Lambda + API Gateway WebSocket. No container orchestration, no cluster to manage, and the per-invocation cost model matches D2C query volumes better than a persistent compute allocation.
Their Atlas Web API is Rocket Companies' proprietary property and title database — a custom system built over years. For D2C, the equivalent data layer (Shopify + Odoo) comes with documented APIs, active developer communities, and existing MCP server implementations. The integration work is weeks, not years.
Rocket Close also had a dedicated engineering team and the backing of a Fortune 500 parent company for initial development. The D2C translation doesn't require that. The agentic reasoning, Knowledge Base retrieval, and MCP tool composition are all Bedrock-managed — the custom engineering work is the Lambda wrappers around your existing APIs and the Slack bot integration. That scope is achievable for a D2C brand working with an AWS partner, without a full-time AI engineering hire.
The part that doesn't simplify: knowledge curation. Rocket Close's dedicated title requirements database is the result of sustained investment in structured knowledge. D2C brands that skip this step build agents that confidently produce wrong answers from incomplete information. The order of operations is: curate first, build second. We covered a similar pattern with the agentic triage build — the agent quality ceiling is set by the quality of the inputs, not the sophistication of the framework.
Frequently Asked Questions
Does the knowledge base need to be fully documented before building the agent?
No — but the agent's answer quality is directly proportional to what has been curated. The practical approach is to start with knowledge that already exists as files: carrier SLA PDFs, FDA or FSSAI compliance documents, product spec sheets. These go into Bedrock Knowledge Bases immediately. For living policy documents, a Notion-to-S3 sync Lambda ingests updated pages weekly. Transaction data comes through MCP tools calling Shopify and Odoo APIs directly — no curation needed since it is already structured. The hardest tier is institutional knowledge. Before building, spend two weeks logging the most common escalation types and writing one-paragraph answers. Those 30 to 50 Q&A pairs become the highest-return KB documents the agent will have, because they directly address the exact queries ops coordinators ask every day.
How is this different from a Slack bot connected to a general-purpose AI model?
A general-purpose AI Slack bot has access to its training data and whatever context you put in the system prompt. It cannot look up a specific order in Shopify, check current lot inventory in Odoo, or retrieve the exact text of your carrier's SLA document. A Strands Agent on Bedrock with MCP tools can do all three in a single query: retrieve the relevant policy text from the Knowledge Base, call the Shopify MCP tool to pull the customer's order status, call the Odoo MCP tool to check inventory availability, and synthesize into one response. The answer is grounded in your live operational data. Bedrock Guardrails also enforces a response boundary — the agent only answers within the configured knowledge scope, which prevents confident but inaccurate responses on compliance-sensitive topics where a wrong answer creates a customer and regulatory problem.
At what escalation volume does this build make financial sense?
At 20 or more research-heavy escalations per day averaging 6 or more minutes of source-switching, the math is favorable. Twenty escalations at 6 minutes is 2 hours of coordinator time daily — roughly 40 hours per month. At a fully-loaded ops coordinator cost of $3,000 to $4,000 per month, the agent recovers build cost within 3 to 4 months even if it handles only 60% of escalations without human escalation. Below 20 escalations per day, a well-structured Notion wiki with good internal search often covers the gap at lower cost and lower complexity. The more important threshold is repetition rate: if 70% or more of your escalations are asking questions of the same shape — order status plus policy lookup plus product detail — the agent has a high answer hit rate. If most escalations require judgment calls and contextual nuance that are not documented anywhere, the hit rate drops and human escalation rates stay high regardless of the framework used.
Founder and CEO of Braincuber. Has scoped and shipped 500+ Odoo, AI, and cloud projects for US mid-market and global brands. Takes every founder call personally — no SDR layer between buyers and the people building the system.