Scaling AI Agents to Production: A Blueprint for Autonomous Customer Service
cox_automotive · Automotive · 2024 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: Automotive customer service and dealer operations
Cox Automotive needed to move agentic AI from prototypes into production customer-service and dealer workflows under an aggressive five-week deadline, while preserving safety, session isolation, evaluation, cost controls, and trust for autonomous after-hours conversations.
Constraints:
- The product teams had five weeks to launch five agentic products by Labor Day.
- The flagship assistant operates without human oversight in dealership customer conversations.
- Agents need long-running sessions, context, secure tool access, agent-ready tools, observability, and full session isolation.
- Customer-service agents need hard and soft guardrails, not only blocking behavior.
- LLM conversations are probabilistic, so manual review does not scale to tens of thousands of daily transactions.
Architecture
Cox Automotive used Amazon Bedrock AgentCore and the Strands Agent Framework as the foundation for multiple agentic products. The customer-service assistant uses an orchestrator that routes incoming messages to domain sub-agents such as sales and service, gathers their outputs, and continues the conversation. The production blueprint adds AgentCore session isolation, hard and soft guardrails, continuous red teaming, LLM-as-judge evaluation, cost and turn circuit breakers, and dealer handoff when thresholds are crossed.
Diagram confidence: explicit (topology described by the source).
flowchart LR A["Dealership customers"] --> B["Virtual assistant"] B --> C["Orchestrator"] C --> D["Sales sub-agent"] C --> E["Service sub-agent"] F["AgentCore runtime"] --> B B --> G["Guardrail layer"] F --> H["Evaluation framework"] H --> G H --> I["Circuit breakers"] B --> I I --> J["Dealer staff"] J --> A
Components
| Component | Role | Interacts with |
|---|---|---|
Dealership customers |
People sending customer-service, sales, and service messages to dealerships. | Virtual assistant |
Virtual assistant |
Autonomous dealership customer-conversation product built on AgentCore and Strands. | Orchestrator, Guardrail layer, Circuit breakers |
Orchestrator |
Intent-routing layer that delegates work to domain sub-agents and composes responses. | Sales sub-agent, Service sub-agent |
Sales sub-agent |
Domain agent handling sales-related customer conversation tasks. | Orchestrator |
Service sub-agent |
Domain agent handling service-related customer conversation tasks. | Orchestrator |
AgentCore runtime |
Foundation for session isolation, framework portability, memory, identity, gateway tools, observability, browser, and code interpreter capabilities. | Virtual assistant, Evaluation framework |
Guardrail layer |
Hard Bedrock guardrails and soft prompt/workflow guardrails for safe customer-service behavior. | Virtual assistant |
Evaluation framework |
Red-team catalog and LLM-as-judge testing for relevancy, completeness, tone, and worst-case behavior. | Guardrail layer, Circuit breakers |
Circuit breakers |
Cost and turn-count hard limits that stop conversations and hand off to dealerships. | Dealer staff |
Dealer staff |
Humans who decide whether threshold-crossing conversations continue. | Dealership customers |
Data flow
A dealership customer sends a message. The orchestrator classifies intent, routes the request to sales, service, or other sub-agents, gathers their results, crafts a response, and repeats for the conversation length. AgentCore provides isolated sessions and framework portability; guardrails block or redirect unsafe flows; LLM-as-judge test conversations evaluate quality; circuit breakers stop high-cost or high-turn conversations and hand them to the dealership.
3 supporting quotes
Why this architecture
Cox chose AgentCore and Strands to avoid rebuilding runtime, session, identity, tool, and observability infrastructure under a five-week launch constraint. The architecture keeps agentic product teams focused on domain behavior while standardizing safety through red teaming, guardrails, evaluation, circuit breakers, and graceful handoff.
3 supporting quotes
Models used: Amazon Bedrock models · LLM-as-judge · Strands agents · Bedrock AgentCore
Scale
- Cox Automotive reports about 5.1 trillion vehicle insights.“Just as a round number, we get about 5.1 trillion insights about vehicles in the market.”transcript, stated
- Cox sees hundreds of millions of customer interactions.“We see hundreds of millions of customer interactions as people look at vehicles”transcript, stated
- Cox had crossed roughly 150 AI models in production.“We have hundreds of AI models in production. I think 150-something was a threshold we crossed last month.”transcript, stated
- AgentCore supports payloads up to 100 MB and sessions up to eight hours.“It supports multi-modal inputs, up to 100 megabytes of payload, with long running sessions up to eight hours.”transcript, stated
- The five-product push had a five-and-a-half-week deadline.“We had a deadline, Labor Day, which was about five and a half weeks from that point.”transcript, stated
Alternatives considered (roads not taken)
Build the agent runtime infrastructure internally
Rejected because: Cox judged it unnecessary and wasteful for each team to solve runtime, orchestration, tooling, monitoring, and cost problems themselves.
Let each team pick a different framework
Rejected because: Cox wanted to learn one framework and get to market in five weeks rather than spread learning across five frameworks.
Hard blocking guardrails only
Rejected because: Pure blocking creates poor customer experiences in customer service, so Cox added soft guardrails that redirect conversations helpfully.
Manual review of every conversation
Rejected because: Manual review works for dozens or hundreds of conversations but not tens of thousands of daily transactions.
Patterns
multi-agent-orchestration (orchestration)
The customer-service assistant routes each message through an orchestrator to domain sub-agents, then composes their results into a customer response.
safety-policy-enforcement (governance)
Cox uses hard guardrails to block unsafe requests and soft guardrails to redirect risky conversations while preserving customer experience.
eval-driven-development (evaluation)
Cox red-teams before alpha, beta, and production, catalogs exploits, and repeats after code deployments and prompt changes.
llm-as-judge (evaluation)
Cox generates test conversations, runs them through the assistant, and uses another LLM to score correctness dimensions such as relevancy, completeness, and tone.
fallback-degradation (reliability)
Cox adds circuit breakers for P95/P99 cost and turn counts, stopping conversations and handing them to dealer staff when thresholds are crossed.
Tradeoffs
Runtime foundation
Chose Amazon Bedrock AgentCore over building agent runtime infrastructure internally.
Rationale: AgentCore gave product teams runtime, memory, identity, gateway, observability, browser, and code-interpreter foundations under a short launch deadline.
Framework focus
Chose one shared Strands direction for the five teams over letting each team use a different agent framework.
Rationale: A shared framework reduced learning dispersion and helped Cox focus on getting products to market in five weeks.
Safety behavior
Chose hard guardrails plus soft conversational redirection over only blocking unsafe conversations.
Rationale: Customer service often needs helpful escalation or appointment-setting instead of a hard refusal.
Gotchas (what bit them)
Framework churn can derail product teams mid-project.
Root cause: Agent frameworks changed during the build, including guidance shifting from Agent Squad to Strands.
Resolution: AgentCore provided a foundation that let Cox swap frameworks without re-architecting the whole stack.
Blocking-only guardrails damage customer service.
Root cause: Customer-service conversations often need redirection rather than refusal.
Resolution: Cox uses hard guardrails for stops and soft guardrails to nudge conversations toward safe handoff paths.
Red teaming does not prove the assistant works.
Root cause: Red teaming finds breakage, but probabilistic LLMs still need dynamic evaluation for correctness.
Resolution: Cox adds automated LLM-as-judge evaluation after red teaming and guardrails.
Autonomous conversations need hard operating boundaries.
Root cause: LLMs may run unexpectedly long or create excessive cost while no operator is around.
Resolution: Cox sets cost and turn-count circuit breakers and hands off conversations to dealerships.
Evaluation
Cox evaluates agents through red teaming before alpha, beta, and production; exploit catalogs after deployments and prompt changes; LLM-as-judge test conversations; relevancy, completeness, and tone metrics; and circuit-breaker monitoring for cost and conversation turns.
Metrics: Red-team exploit catalog · Relevancy · Completeness · Tone · P95 and P99 cost thresholds · Turn-count threshold such as 20 turns · Conversation handoff rate
3 supporting quotes
Outcomes
- Cox launched three agentic applications into production beta out of a five-product push.
- The customer-conversation assistant is the first planned for full launch.
- Dealers report customers receiving answers during the day and after hours.
- A second beta app helps dealerships price inventory by doing the work instead of nagging users.
- One project was taken back to the drawing board and treated as valuable learning.
Cox reports 5.1 trillion vehicle insights, hundreds of millions of customer interactions, about 150-plus AI models in production, five teams/projects in a five-and-a-half-week push, and AgentCore support for 100 MB payloads and eight-hour sessions.