AI Support Agent for Autonomous Driving Data Pipeline Operations

Mobileye2026
View original source

Mobileye, a leader in autonomous driving technology with 230 million deployed chips, faced a significant support bottleneck where 66% of internal support tickets were routine status inquiries about their Data Collection Processing pipeline, requiring engineers to manually navigate multiple systems with 15 clicks per inquiry. They deployed an AI Support Agent on Amazon Bedrock AgentCore using Anthropic Claude models accessed through their internal LLM Gateway, with real-time data access via Model Context Protocol (MCP) to their on-premises systems. The production deployment achieved a 98% success rate (exceeding the 95% target), reduced response times by 90% from hours to approximately one minute, and automated 66% of total ticket volume, processing over 100 tickets monthly while freeing engineers to focus on complex issues.

Industry

Automotive

Technologies

Overview

Mobileye, the autonomous driving technology pioneer with over 230 million EyeQ system-on-chips deployed across approximately 1,200 vehicle models globally, provides a compelling case study in deploying production-grade AI agents to solve internal operational challenges. The company’s Data Collection Processing pipeline ingests thousands of drive-recording sessions daily, generating a continuous stream of status inquiries from engineers and data teams. These inquiries required manual navigation across multiple backend systems, consuming significant engineering resources and creating bottlenecks in their support operations.

The case study demonstrates how Mobileye successfully transitioned from a proof-of-concept AI agent to a fully operational production system deployed on Amazon Bedrock AgentCore, and ultimately scaled this into an enterprise-wide platform for AI agent deployment. The blog post, published in August 2026, presents this as a success story showcasing AWS’s AgentCore platform, though the specific timeline of the project development and deployment phases is not explicitly detailed.

The Production Problem and Context

The support challenge facing Mobileye was both quantifiable and significant. Approximately 66% of support tickets were routine status inquiries that nevertheless required engineers to perform manual steps across multiple systems. Each inquiry involved identifying sessions, cross-referencing visualization tools, validating outputs, and reviewing logs before composing responses. This process required 15 clicks across multiple backend systems per inquiry and consumed hours of engineering time that could have been directed toward more complex technical challenges.

The scale of the operation is important context: with thousands of drive-recording sessions ingested daily into their Data Collection Processing pipeline, the support burden was substantial and growing. Traditional automation approaches like scripting, static workflows, and rule-based decision trees proved inadequate because they lacked the contextual understanding needed to interpret the variability of real-world support requests. This gap between what rule-based systems could handle and what the actual support workload required became the driving force behind exploring AI agent solutions.

Proof of Concept and Validation

Before committing to full production deployment, Mobileye’s team conducted a proof-of-concept with clearly defined success metrics: 95% accuracy in ticket classification with sub-2-minute response times. This structured approach to validation demonstrates mature LLMOps thinking, establishing measurable targets before investing in production infrastructure.

The proof-of-concept agent utilized Anthropic Claude foundation models, accessed through Mobileye’s internal LLM Gateway. This LLM Gateway is described as providing governed, quota-managed access to foundation models on Amazon Bedrock, suggesting that Mobileye had already established governance infrastructure for LLM access prior to this project. This existing governance layer represents an important LLMOps pattern—establishing centralized access controls and monitoring for LLM usage rather than allowing direct, ungoverned access to foundation models.

The critical technical enabler in the proof-of-concept was the Model Context Protocol (MCP), which gave the agent real-time access to the drive-data processing platform’s APIs. This allowed the agent to query session status, retrieve processing logs, and pull diagnostic information during inference. The implementation of MCP represents a significant LLMOps consideration: rather than relying solely on pre-loaded context or static knowledge, the agent could dynamically access live production data to provide current, accurate responses.

The capabilities demonstrated in the proof-of-concept went beyond simple ticket classification. The agent could handle complex inquiries including confirming completed sessions with access details, surfacing specific errors with debugging recommendations and log links for failures, and guiding users through submission processes for missing requests. The agent achieved all this in under two minutes with no human intervention, validating both the technical approach and the business value proposition.

Production Architecture and Hybrid Design

The production architecture represents a sophisticated hybrid design that bridges on-premises systems with AWS cloud services. This hybrid approach was driven by a fundamental constraint: Mobileye’s internal ticketing system operated on-premises and was inaccessible from AWS. This requirement shaped the entire production architecture and demonstrates real-world LLMOps challenges that go beyond pure cloud-native scenarios.

The on-premises components include a Local Orchestrator that handles ticketing operations locally, extracting new tickets and posting completed responses back into the ticketing system. The internal ticketing system itself serves as both the source of support tickets and the destination for AI-generated responses. Its inaccessibility from AWS was explicitly noted as the primary driver behind the hybrid design choice.

On the AWS cloud side, the core component is AgentCore Runtime, where Mobileye runs their AI Support Agent. The blog post emphasizes that this serverless runtime eliminated all infrastructure management, allowing the team to deploy and iterate without provisioning servers while benefiting from automatic scaling to handle spikes in support volume. The team maintains full flexibility to use any agentic framework, and deployment is simplified to a single API call. However, readers should note that this represents the vendor’s marketing claims about AgentCore’s capabilities—the case study doesn’t provide independent validation or comparative analysis against alternative deployment approaches.

AgentCore Observability provides built-in monitoring capabilities that trace every agent interaction end-to-end, from initial request through MCP tool calls to backend systems to the final response. The system surfaces detailed logs and tracebacks showing how the agent reasoned, what data it retrieved, and where errors occur. This comprehensive observability is positioned as dramatically reducing debugging time and accelerating iteration cycles, representing a key LLMOps capability for production systems.

AWS Secrets Manager handles faceless, secure authentication for the GenAI platform. Teams invoking AI agents never handle credentials directly—secrets required to interact with agents and backend systems are stored, rotated, and retrieved programmatically. This enforces enterprise security standards without adding friction for end users, demonstrating mature secrets management practices essential for production LLM deployments.

Mobileye’s own services play critical roles in the architecture. The Data Pipeline MCP server enables real-time querying of live production data during inference, including driving session warming statuses, request progress, and processing errors. This allows the agent to deliver context-aware responses dynamically. The AI LLM Gateway provides governed, quota-managed access to foundation models on Amazon Bedrock and potentially other LLM providers, suggesting a multi-provider strategy with centralized governance.

Operational Workflow

The automated workflow follows four main steps. The Local Orchestrator extracts new tickets and sends them to the AI Support Agent running on AgentCore Runtime. The AI Support Agent processes each ticket end-to-end, categorizing the inquiry, querying live production systems via the MCP Server for real-time session data, and accessing Claude through the AI LLM Gateway to generate fully formatted responses with links, recommendations, and actionable next steps. The Local Orchestrator receives the completed response and posts it back to the Internal Ticketing System with appropriate comments and labels. Meanwhile, AgentCore Observability captures agent activity including session metrics, latency, token usage, and traces for continuous monitoring and debugging.

This workflow demonstrates several LLMOps best practices: clear separation of concerns between components, automated orchestration of the end-to-end process, real-time data access for current context, and comprehensive observability throughout the pipeline. The architecture maintains security boundaries between on-premises and cloud systems while enabling seamless operational flow.

Production Results and Performance

The production deployment delivered measurable results that met or exceeded initial targets. The overall success rate reached 98%, surpassing the original 95% target established during the proof-of-concept phase. Response time was reduced from hours to approximately one minute, representing a 90% improvement. The system automated 66% of total ticket volume and processed over 100 tickets monthly.

These metrics demonstrate successful production deployment, though several caveats warrant consideration. First, the blog post doesn’t specify the evaluation methodology used to determine the 98% success rate—whether this represents accuracy in classification, user satisfaction, or some other measure. Second, the metrics don’t include failure mode analysis or discussion of the remaining 2% of cases where the agent didn’t succeed. Third, while 100+ tickets monthly represents significant volume, the post doesn’t provide context for seasonal variations, peak loads, or how the system performs under stress conditions.

The strategic benefits extend beyond raw metrics. Support engineers are freed to focus on complex work rather than routine status inquiries, representing a qualitative improvement in resource allocation. The team achieved this without building infrastructure themselves, leveraging AgentCore’s managed capabilities. However, readers should recognize that this framing emphasizes the benefits of the chosen platform rather than providing objective comparison with alternative approaches.

Scaling to Enterprise Platform

Following the success of the AI Support Agent, Mobileye faced a new challenge: most developers across the organization lacked the AWS credentials or infrastructure access to deploy agents on AgentCore independently. This represented a classic LLMOps scaling problem—how to democratize access to AI agent deployment capabilities while maintaining governance, security, and operational standards.

The Mobileye Cloud Infra team built an internal agent deployment platform as a managed service enabling developers to deploy production-grade AI agents without AWS expertise or cloud credentials. The platform follows a structured workflow where teams provide their agent code and specify needed AgentCore capabilities including Memory, Browser Tool, Code Interpreter, Observability, and Gateway. The Cloud Infra team provisions all necessary infrastructure including AWS IAM Roles, Amazon S3 storage, Amazon CloudWatch monitoring, and Amazon Cognito authentication. Developers receive a pre-configured bedrock_agentcore.yaml file that integrates directly into their project, and deployment simplifies to a single command: agentcore deploy.

This internal platform approach represents sophisticated LLMOps thinking about enablement and governance at scale. The provisioned infrastructure aligns with Mobileye’s standards for security, cost governance, and operational excellence. CloudWatch Alarms on code exceptions ensure issues surface immediately. What began as a single proof-of-concept evolved into an enterprise-wide platform where teams can deploy secure, monitored, cost-tracked agents in minutes rather than weeks.

This scaling story demonstrates important LLMOps patterns: creating abstraction layers that hide infrastructure complexity from users, establishing guardrails and standards through platform engineering, enabling self-service while maintaining centralized governance, and leveraging successful pilots as foundations for broader organizational capabilities.

Critical LLMOps Considerations and Balanced Assessment

Several aspects of this case study deserve critical examination from an LLMOps perspective. First, the blog post is published on AWS’s official blog and explicitly positions AgentCore as the enabling platform. While the results appear genuine, readers should recognize the marketing context and evaluate claims accordingly. The case study doesn’t provide comparative analysis showing why AgentCore was superior to alternative approaches like building custom infrastructure, using other managed platforms, or implementing different architectural patterns.

Second, the case study emphasizes the benefits of serverless, managed infrastructure but doesn’t discuss the tradeoffs. Managed platforms can reduce operational burden but may introduce vendor lock-in, limit customization options, constrain deployment flexibility, or increase costs at scale compared to self-managed alternatives. The case study doesn’t address whether Mobileye evaluated these tradeoffs or how they weighed different architectural options.

Third, the monitoring and observability capabilities described are comprehensive, but the case study doesn’t discuss how Mobileye handles prompt engineering, model version management, or evaluation of agent behavior over time. These are critical LLMOps concerns for production systems, particularly as models, data, and use cases evolve. The absence of discussion about continuous evaluation, A/B testing, or systematic prompt improvement suggests either these practices aren’t in place or weren’t considered relevant to highlight in this narrative.

Fourth, the Model Context Protocol implementation appears to be a custom integration with Mobileye’s internal systems. While this demonstrates successful integration of real-time data access, the case study doesn’t discuss how they handle API reliability, data freshness guarantees, error handling when systems are unavailable, or how they ensure the agent degrades gracefully when data sources fail. These operational concerns are critical for production reliability.

Fifth, the use of an internal LLM Gateway for governed access to foundation models represents mature thinking about centralized control, but the case study doesn’t detail what governance policies are enforced, how quota management works in practice, or how the gateway handles model selection, fallback strategies, or cost optimization. Understanding these implementation details would make the case study more valuable for practitioners facing similar challenges.

Finally, the scaling story about building an internal platform is compelling, but the case study doesn’t address how Mobileye handles agent lifecycle management, versioning of deployed agents, testing and validation before production deployment, or coordination when multiple teams’ agents interact with shared resources. These are critical concerns for enterprise-scale AI agent deployment that aren’t addressed in the current narrative.

Despite these gaps and the marketing context, the case study demonstrates several genuine LLMOps achievements: successful transition from proof-of-concept to production with measurable results, effective hybrid architecture bridging on-premises and cloud systems, implementation of comprehensive observability for production AI agents, centralized governance through an LLM Gateway pattern, and scaling from single use case to enterprise platform through internal tooling. These accomplishments represent real progress in operationalizing LLM-based systems, even if the full picture includes complexities not captured in this promotional narrative.

More Like This

Scaling AI Agents in Production: Building and Operating Hundreds of Autonomous Agents

Datadog2026

Datadog shares lessons learned from building over 100 AI agents in production and preparing to scale to thousands more. The company deployed multiple production agents including Bits AI SRE for autonomous alert investigation, Bits AI Dev for code generation and error fixes, and security analysts for automated security investigations. Key challenges addressed include making systems agent-native through API-first design, transitioning from reactive chat interfaces to proactive background agents, implementing comprehensive evaluation systems, maintaining model and framework agnosticism, and establishing robust monitoring for autonomous operations. The case study emphasizes that intelligence is no longer the bottleneck—operational excellence and proper LLMOps practices are now the critical factors for successful agent deployment at scale.

code_generationfraud_detectioncustomer_support+38

Building Production Agentic AI Systems for IT Operations and Support Automation

WEX2025

WEX, a global commerce platform processing over $230 billion in transactions annually, built a production agentic AI system called "Chat GTS" to address their 40,000+ annual IT support requests. The company's Global Technology Services team developed specialized agents using AWS Bedrock and Agent Core Runtime to automate repetitive operational tasks, including network troubleshooting and autonomous EBS volume management. Starting with Q&A capabilities, they evolved into event-driven agents that can autonomously respond to CloudWatch alerts, execute remediation playbooks via SSM documents exposed as MCP tools, and maintain infrastructure drift through automated pull requests. The system went from pilot to production in under 3 months, now serving over 2,000 internal users, with multi-agent architectures handling both user-initiated chat interactions and autonomous incident response workflows.

customer_supportpocrealtime_application+37

Deploying Secure AI Agents in Highly Regulated Financial and Gaming Environments

Sicoob / Holland Casino2025

Two organizations operating in highly regulated industries—Sicoob, a Brazilian cooperative financial institution, and Holland Casino, a government-mandated Dutch gaming operator—share their approaches to deploying generative AI workloads while maintaining strict compliance requirements. Sicoob built a scalable infrastructure using Amazon EKS with GPU instances, leveraging open-source tools like Karpenter, KEDA, vLLM, and Open WebUI to run multiple open-source LLMs (Llama, Mistral, DeepSeek, Granite) for code generation, robotic process automation, investment advisory, and document interaction use cases, achieving cost efficiency through spot instances and auto-scaling. Holland Casino took a different path, using Anthropic's Claude models via Amazon Bedrock and developing lightweight AI agents using the Strands framework, later deploying them through Bedrock Agent Core to provide management stakeholders with self-service access to cost, security, and operational insights. Both organizations emphasized the importance of security, governance, compliance frameworks (including ISO 42001 for AI), and responsible AI practices while demonstrating that regulatory requirements need not inhibit AI adoption when proper architectural patterns and AWS services are employed.

healthcarefraud_detectioncustomer_support+50