From data overload to actionable insights: How Verizon Connect scaled agentic AI to 100,000 users

URL 源: https://aws.amazon.com/blogs/machine-learning/from-data-overload-to-actionable-insights-how-verizon-connect-scaled-agentic-ai-to-100000-users/

发布时间: 2026-05-27T12:01:06-08:00

Markdown 内容: _特别感谢 Verizon Connect 团队，他们一直在努力推进该项目：Matteo Simoncini、Luca Bravi、Alberto Rossettini、Martin Villarruel、Ceyhun Unlu、Adriel Zuquini 和 Andrea Benericetti._

今天的车队管理者面临着一个巨大的挑战：将数据过载转化为可操作的见解。当你管理成千上万辆车辆时，每辆每天生成数百个数据点，手动分析识别关键模式几乎是不可能的。Verizon Connect 是一家全球车队管理系统提供商，通过其 Reveal 平台为世界各地的企业提供服务，他们在大规模运营中遇到了同样的问题。

拥有超过 120 万活跃车辆订阅，每天产生超过 5 亿个数据点，覆盖 8 万个独特的数据指标，车队管理者淹没在这种数据中，并被迫在分散的纸质日志和反应式电子表格中寻找异常。庞大的数据量使得在这些问题变成昂贵的问题之前识别新兴的安全问题、维护需求或运营效率变得不可能。而不是构建另一个静态仪表板或基于规则的自动化系统，只能捕获预定义的模式，Verizon Connect 选择了代理 AI 来取代那种手动猜测的工作，用集中式的智能解决方案来替代。代理 AI 动态地调查新模式，提出后续问题，并根据发现的内容调整其分析，使其非常适合车队操作的不可预测性。

在这篇文章中，我们将展示 Verizon Connect 如何构建并扩展了一个代理 AI 解决方案，将令人望而却步的车队数据转化为每日为 100,000 名用户提供清晰、可操作的见解。我们将带你了解架构决策、实施挑战以及可以指导你自己的数据到见解转变的可衡量结果。

构建可扩展的架构

该解决方案在处理大量数据的同时保持成本效益。下图描述了核心组件。在本节的后面部分，我们将在“总体架构”部分详细讨论各个组件并将其连接起来。

__

图 1 - 高层次解决方案架构

组件的高层次描述和逻辑流程如下：

1. 调度开始——每日触发器启动工作流，激活分析层中的异常检测模块。
2. 数据摄取——该模块从原始数据存储中拉取结构化信息。这是计算密集型工作的发生地。
3. 目标输出——与其让大型语言模型（LLM）“在针堆中找针”，此模块识别特定的异常并将它们写入专用的异常表。通过将数值分析卸载到专门的代码中，我们避免了 LLM 在原始表格数据中面临的规模和准确性问题。
4. AI 代理激活——当异常准备就绪后，管理者触发 AI 代理。为了提高性能，多个代理可以并行运行，每个专注于不同的客户或数据段。
5. 推理与上下文——AI 代理协调最终分析。它查询异常以获取“是什么”并参考原始数据以获取“为什么”，使用 LLM 将这些输入综合成连贯的故事。
6. 观察交付——最终推理作为生成的洞察存储，然后通过 Reveal 应用程序向终端用户交付。

解决方案的组件

异常检测

AI 工程中的一个常见陷阱是让 LLM 对大规模原始表格数据进行数值分析。正如 AWS 建议指南 所指出的，LLM 在处理复杂表格结构和大规模数值提取方面可能会遇到困难。为此，我们使用 AWS Step Functions 和 AWS Lambda 构建了一个无服务器统计模型（见图 4）。该模型对结构化数据执行计算密集型的异常检测工作。它识别“是什么”异常，因此 AI 代理可以专注于“为什么”发生以及如何解决它。

AI 代理

我们选择 Strands Agents，这是一个开源 SDK，用于构建和执行 AI 代理，在无服务器的 AWS Lambda 环境中运行。这种部署模式可以根据您的需求水平扩展。AI 代理通过动态推理循环自主确定必要的调查路径，而不是遵循固定的步骤。从以下描述可以看出，AI 代理是无状态的，所需的洞察生成上下文在分析时会重新获取。

AI 代理使用特定工具：

• 从 Amazon 简单存储服务 (Amazon S3) 获取预先计算的异常。
• 使用 Amazon Aurora 查询原始数据的附加上下文，使用 Amazon DynamoDB 查询历史洞察。
• 将最终洞察写回 Amazon S3。
• 在 Amazon DynamoDB 中跟踪任务请求状态。

双阶段代理架构

洞察生成采用双阶段方法，每个阶段都以不同的方式利用 LLM 的推理能力：

Stage 1: Summary generation (anomaly aggregation & prioritization) In this first stage, the agent receives a set of raw anomalies detected across the fleet. Rather than processing each anomaly individually, the LLM autonomously decides how to aggregate them into coherent insight candidates. It can group anomalies by:

• Common root causes (such as multiple vehicles showing the same behavior pattern)
• Temporal correlation (events concentrated on specific dates)
• Categorical similarity (related safety or efficiency metrics)

Both the grouping logic and the selection criteria are entirely at the LLM’s discretion. The system doesn’t impose fixed rules on how anomalies should be combined. After aggregation, the agent assigns a relevance score to each candidate’s insight based on factors such as severity, recurrence, fleet-wide impact, and actionability. From these scored candidates, the agent selects the top four most relevant insights to proceed to detailed generation. With this approach prioritization adapts to the specific context of each user’s fleet, rather than relying on static business rules that might miss emerging patterns.

Stage 2: Detailed generation (agentic tool-based Investigation) The second stage is where the agentic nature of the system becomes critical. For each summary insight, a separate agent instance is spawned with access to data retrieval tools. The agent autonomously decides which tools to call, in what sequence, and how many times—iterating until it has gathered sufficient evidence to produce a data-backed insight. Now that the agent execution is explained, let’s examine why an agentic approach is essential for this use case. Fleet management involves countless variables and unpredictable scenarios that require dynamic investigation rather than predetermined logic, creating two fundamental limitations:

• Finite pattern coverage: Code can only detect patterns that were explicitly programmed. Edge cases, novel correlations, or unexpected data distributions go unnoticed.
• Rigid investigation flows: A script follows predetermined steps regardless of what the data reveals mid-analysis.

In contrast, the AI agent can discover patterns of any nature, including edge cases that weren’t anticipated during development. If the data suggests an unexpected correlation (such as harsh braking events correlating with specific time-of-day patterns, or a vehicle’s behavior changing after a particular date), the agent can pivot its investigation strategy in real time, making additional tool calls to explore these emergent hypotheses. This flexibility is particularly valuable in fleet management, where:

• Driver behavior varies unpredictably
• External factors (weather, traffic, road conditions) create non-obvious correlations
• Fleet composition and usage patterns evolve over time
• New anomaly types might emerge that weren’t present in historical data

Example of flow orchestration

• Initial discovery: The agent identifies a summary insight reporting a 30 percent increase in harsh braking events across the entire fleet.
• Establishing a baseline: It autonomously decides to pull the fleet-wide historical average for the last 30 days to confirm if this spike is a true anomaly or just a typical seasonal trend.
• Pattern recognition: Upon seeing that the spike is concentrated on specific dates, the agent shifts its focus to a daily breakdown. It discovers that most of these safety events occurred on the same two days.
• Targeted drill-down: Based on those dates, the agent identifies that vehicles 1015, 1142, and 1032 were responsible for nearly 70 percent of the events.
• Comparative analysis: It then makes a final, targeted request to compare the historical performance of Vehicle 1015 against its current behavior to see if the driver’s profile has fundamentally changed.
• Synthesis: Only after “connecting these dots” does the agent terminate the loop and generate a final, data-backed insight that highlights the specific drivers and dates involved.

Large language model

To optimize price-performance, we first used the high-tier Claude 4.5 Sonnet to validate logic and insight quality. Post-validation, we transitioned to the more cost-efficient Claude 4.5 Haiku for our production use case. Further price-performance optimization led us to Amazon Nova 2 Lite, a lightning-fast multimodal model, which delivers comparable insight quality while reducing input token costs by 70 percent compared to Claude 4.5 Haiku. This substantial saving is critical since the workload is dominated by input tokens (telematics data, anomalies, context). The efficiency of Nova 2 Lite enables Verizon Connect to deliver AI insights more cost-effectively to its entire user base. Quality was maintained via an automated testing suite and a gold-standard dataset, ensuring a battle-tested solution upon full release. LLMs are hosted at scale in Amazon Bedrock, a fully managed service with comprehensive generative AI capability, security, privacy, and responsible AI features.

Daily trigger management and concurrency

To provide insights ready at the start of their business day to the 100,000 users, we use Amazon Simple Queue Service (Amazon SQS) to manage execution. By controlling the maximum concurrency of the SQS-to-Lambda trigger, we can:

• Smooth out spikes in API demand
• Stay within Amazon Bedrock quotas: Tokens Per Minute (TPM) and Requests Per Minute (RPM)
• Provide reliable delivery without over-provisioning resources

To illustrate, consider a scenario delivering insights for customers across the entire United States. The target delivery of insights is 8:00 AM ET, based on data generated up to Midnight PT the previous day. Given the three-hour time zone difference, the end-to-end process must be completed within a five-hour window. Allocating one hour for anomaly detection leaves a four-hour window for the AI Agent and LLM to generate insights. At a rate of 1,500 RPM (adjustable), the insight generation phase will take approximately 1.25 hours, well within our operational requirements.

_![Image 2](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/13/ML-20194-image2.jpeg)_

Figure 2 – Maximum Concurrency SQS-to-Lambda Details

## Generated Insights

The insights the agent generates are ready for the Reveal application to consume. Upon login, new insights appear in a dedicated panel on the live map, Reveal’s most visited page, so that every user sees relevant insights immediately. Each insight is clickable, leading to a detailed page with the full analysis.

![Image 3](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/13/ML-20194-image3.png)

Figure 3 – Reveal’s most visited page includes links to Operational Insights results.

## Overall Architecture

The overall architecture brings together these four components: Anomaly detection, parallelization of requests, insights generation engine, and storage of generated insights for consumption by the Reveal application.

![Image 4](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/13/ML-20194-image4.jpeg)

Figure 4 – Overall Architecture

To understand how these components work together, consider the following workflow: An insights request is triggered, including the list of customer IDs for which insights must be calculated. The statistical model performs anomaly detection and stores results in Amazon S3.

1.   N parallel requests are triggered as described earlier.
2.   N agents analyze data, create insights, and save them to Amazon S3. In this phase, agents invoke Amazon Bedrock APIs to reach the selected model.
3.   The Reveal application can access the insights stored in Amazon S3.

## The Result: Actionable Intelligence

The Operational Insights feature was rolled out to [Verizon Connects users in November 2025](https://www.verizonconnect.com/solutions/operational-insights/), and has served fleet managers with clear, natural language narratives like the following:

*   Safety Pattern Detection: "Your fleet saw a 100% increase in harsh braking this week. Interestingly, this coincides with a reduction in harsh acceleration, suggesting driver fatigue or increased congestion."
*   Operational Efficiency: "Vehicle #90000 is idling for 50% of its engine-on time, significantly above your fleet average. This represents unnecessary fuel cost."
*   Fleet Performance: "Daily mileage is down 59%, but speeding events are up 54%. This suggests vehicles are traveling shorter distances at higher speeds—consider route optimization."

## Conclusion and Looking Ahead

In this post, we showed how Verizon Connect built a scalable Agentic AI solution on AWS that transforms raw IoT telematics data into actionable fleet insights for over 100,000 users. The architecture combines Amazon Bedrock, Strands Agents, AWS Step Functions, Amazon SQS, and a multi-tier data layer to deliver reliable, cost-efficient insights at scale.

As the AI landscape evolves, we plan to migrate from AWS Lambda-based agent deployment to [Amazon Bedrock AgentCore Runtime](https://aws.amazon.com/bedrock/agentcore/) to further streamline our AWS Lambda execution and use [Model Context Protocol (MCP)](https://docs.aws.amazon.com/prescriptive-guidance/latest/mcp-strategies/introduction.html) for faster tool integration.

To implement an agentic AI solution effectively, begin with a small-scale pilot to validate a basic use case and establish cost-efficiency. After the initial value is proven, expand the system by integrating automated workflows and data-driven personalization. The final stage involves transitioning to a full enterprise deployment that supports advanced orchestration and real-time processing across the entire organization. Start building today:

*   Start with the foundations: Amazon Bedrock for managed AI services and AWS Lambda for serverless agent hosting
*   Add orchestration: AWS Step Functions for workflow management and Amazon SQS for scalable queueing
*   Store and retrieve data: Amazon S3 for object storage, Amazon Aurora for structured data, and Amazon DynamoDB for fast lookups
*   Explore agent frameworks: [Strands Agents documentation](https://strandsagents.com/docs/user-guide/quickstart/overview/) for open-source agent development

* * *

## About the Authors