Transforming fleet analytics for Novus Hi-Tech through agentic AI

Fleet analytics sounds straightforward until you have thousands of vehicles streaming dashcam footage, driver alerts, GPS pings, and speed warnings across 10 countries, all at the same time. At that scale, no team can manually triage every drowsiness alert or investigate every over-speeding event before it becomes a real incident. With over 120 enterprise customers relying on their fleet, Novus Hi-Tech needed a system that would act on the data, not only show it. With AI-powered automation, they achieved a 46 percent reduction in road-behavior violations and a 55 percent drop in drowsiness alerts per 1,000 km.

In this post, we walk you through how Novus Hi-Tech, in collaboration with the AWS Prototyping and AI Customer Engineering (PACE) team, designed and implemented an agentic AI solution called FleetGPT. We architected the multi-agent system using Strands Agents SDK and AWS managed AI services, turning IoT data into real-time safety interventions through natural language querying, automated investigation, and AI-powered voice calls to drivers.

For years, extracting value from fleet telemetry required significant manual effort. When a drowsiness alert triggered, operators had to validate video footage, assess severity across multiple signals, contact the driver, and log the outcome. Existing fixed dashboards showed the same views regardless of what teams actually needed to know.

At scale, this model breaks down because one can’t staff enough operators to catch every warning in real time, and manual analysis becomes the bottleneck. The cost of a missed warning could be a preventable accident.

Novus Hi-Tech needed a system that understood the difference between what a fleet manager needs to know, what a customer success analyst is looking for, and what a Command Center operator must act on immediately.

The bottleneck

The friction between question and answer wasn’t uniform. It created different bottlenecks depending on what teams were trying to accomplish.

Every warning that reached the Command Center demanded the same judgment calls. Operators cycled through this decision tree hundreds of times per shift.

On the other hand, fleet managers didn’t need individual event response, but pattern recognition: which drivers are trending toward accidents, which routes carry disproportionate risk, which fleets are drifting on safety compliance.

Both roles shared the same friction: the time between asking a question and getting an answer. Operators spent too long investigating individual events. Fleet managers couldn’t analyze trends fast enough. Neither could move from question to insight without switching tools or waiting on data teams.

Solution overview

FleetGPT replaces fixed dashboards with a natural language interface for dynamic querying, investigation, and insight generation. It surfaces video evidence, driver history, and policy in single interactions. Beyond analytics, FleetGPT automates real-time safety interventions. When a critical event occurs, such as repeated drowsiness, over-speeding, or an SOS trigger, the system initiates a two-way AI-powered voice call in the driver’s native language, with user approval. It tracks acknowledgment and escalates when necessary.

FleetGPT is built with two core capabilities.

1. Analyst: A conversational intelligence layer where operators and fleet managers query the fleet data, retrieve video evidence, and search policy documents through natural language.
2. Intervention engine: An agentic layer that monitors incoming events, evaluates severity, and executes driver interventions with human approval.

Analyst: Natural language intelligence

Novus Hi-Tech’s data landscape included separate systems for telemetry, video, and policy documents. FleetGPT unifies these through a single data layer accessed by an agentic conversational interface.

Data storage and processing layer

Amazon Aurora PostgreSQL manages the structured analytical backbone. It stores per-vehicle daily aggregates covering distance, fuel, safety scores, event counts, and GPS statistics, plus live snapshots of current vehicle status. It’s the primary target for the Text-to-SQL pipeline. A YAML schema file with column aliases, descriptions, and worked examples is injected into every SQL generation prompt. This grounds the large language model (LLM) on the actual schema and reduces hallucination on column names and join paths.

Amazon DynamoDB handles the high-velocity warning event stream. The warning event table uses a composite sort key of warning_code + datetime, enabling efficient range queries by warning type and time window without full table scans. A Global Secondary Index on fleet_id supports fleet-scoped queries without touching data from other tenants. A separate device registry table maps vehicle IDs to country metadata which is the source of truth for language routing in audio alerts.

Amazon Bedrock Knowledge Bases, the fully managed RAG capability, indexes unstructured documents including SOPs, compliance policies, product documentation which are stored in Amazon Simple Storage Service (Amazon S3). The embeddings are generated using Amazon Titan Text Embeddings V2 for storage in Amazon Aurora PostgreSQL with pgvector. This gives operators and fleet managers a single interface for both data questions and policy questions, with no context switching.

Orchestration: Strands Agents

Figure 1: Solution architecture

The system uses a multi-agent architecture built with Strands Agents, where each agent has a distinct role and model assignment based on the complexity of its task.

At the top sits the Supervisor agent, running on Claude Sonnet 4.6 (for model availability by AWS Region, refer to Region availability by models), which handles intent decomposition and multi-step reasoning. It decides what kind of question the user is asking and routes it to the right sub-agent. The Supervisor uses a SummarizingConversationManager from Strands Agents, which preserves the last six messages verbatim while summarizing older turns. This keeps context window usage bounded without losing conversational continuity.

For structured data queries, the Supervisor delegates to a Text-to-SQL sub-agent (also Claude Sonnet 4.6). This agent follows a plan-and-execute approach: it first classifies the query type (vehicle data, driver behavior, or operational metrics), then extracts key entities and maps them to database tables and columns. From there, it generates a query plan outlining the relevant tables and operations, and finally produces and executes the SQL. If an error occurs, the agent retries with the error message, original plan, and failed query included in the prompt for self-correction.

Figure 2: Text-to-SQL sub-agent flow

When a query needs computation beyond SQL (correlation analysis, statistical profiling, trend detection), the Supervisor delegates to a Data Processing sub-agent running on Claude Haiku 3.0 (for model availability by AWS Region, refer to Region availability by models). Rather than pushing complex processing onto the database, this agent generates executable Python, runs it through a Python REPL tool, and returns the shaped results to the orchestrator. Claude Haiku 3.0, a smaller model than Claude Sonnet 4.6, helps keep the inference cost down for this tier of the pipeline.

Each agent has a focused tool surface and scoped system prompt, reducing hallucination and making failures straightforward to isolate.

The agent is hosted on AWS Fargate for Amazon Elastic Container Service (Amazon ECS), which provides a serverless container environment. An Application Load Balancer (ALB) serves as the entry point, routing incoming requests to the ECS-hosted application.

Video evidence retrieval

Video retrieval demonstrates the practical impact of this architecture. Earlier retrieving dashcam footage required operators to know vehicle IDs, navigate a separate system, and apply filters manually.

Operators now retrieve video using natural language, specifying fleet, vehicle, warning type, date range, speed, or city. The agent resolves these parameters into a DynamoDB query using the composite sort key, applies the remaining criteria as in-memory filters, and returns a paginated result set with vehicle ID, timestamp, GPS coordinates, and a streamable video link in a single conversation.

Multi-tenancy and conversation persistence

Multi-tenancy is enforced at the data layer. Every query is scoped to the authenticated user’s authorized fleet IDs, injected into the agent’s context at session initialization. This helps reduce the risk of cross-tenant data access, whether through natural language, prompt injection, or direct tool calls.

Conversation history is stored in DynamoDB with a composite key of user_id + conversation_id + timestamp, to support per-user time-ordered retrieval. At session start, the system also injects live operational context including today’s warning counts, the latest critical events and the currently open video. This gives the agent situational awareness along with the conversation history.

Intervention engine: Automated event response

The intervention agent acts on critical events. When warnings such as drowsiness, dangerous speeding, or SOS arrive, the system evaluates severity and queues interventions for user approval.

Real-time event push through Amazon DynamoDB Streams

ADAS (Advanced Driver Assistance Systems) edge devices send warning events to DynamoDB. Amazon DynamoDB Streams capture these events, which a background worker forwards to the notification API for delivery to the Command Center.

The worker uses exponential backoff on idle periods: if no new events are found, the poll interval doubles up to a maximum of five minutes, then resets to the base interval on the next event. A fallback polling job provides redundancy, scanning a configurable recent time window on a fixed schedule in case the stream worker misses an event.

Two-way AI voice calling

When a safety event needs direct driver contact, the system automatically initiates a fresh conversation session that is pre-configured with the driver’s language. The LLM system prompt, STT/TTS voice model, and language hint are all set at session start. You can refer to Sample Indic Language Voicebot for reference implementation.

The voice calling pipeline operates in real time:

1. Speech-to-Text: The driver’s voice is captured through the in-cabin microphone and transcribed by a high-accuracy multilingual STT (Speech-to-Text) model, with the language hint set at the beginning of the session for accuracy across regional fleets.
2. LLM Processing: Transcriptions are sent to an LLM on Amazon Bedrock that generates contextually appropriate responses in the driver’s native language.
3. Text-to-Speech and delivery: Responses are synthesized using a multilingual TTS (Text-to-Speech) model and streamed to the vehicle’s IVI (In-Vehicle Infotainment) head unit over WebSocket.
4. Interrupt handling: VAD (Voice Activity Detection) monitors for driver speech during system responses, immediately canceling active streams to allow natural conversation flow.

Key design decisions

Building FleetGPT required deliberate choices about frameworks, data stores, and agent architecture. The following sections explain the reasoning behind the decisions that shaped the system.

Why Strands Agents?

Strands Agents was chosen for fine-grained control over tool invocation, conversation lifecycle management, and per-session agent state within a Python-native environment. Capabilities such as summarizing conversation memory, multi-model routing, and caching intermediate tool outputs are easier to implement and tune directly at the SDK level than through higher-level abstraction layers.

DynamoDB

Amazon DynamoDB provides the low-latency reads and stream processing needed for real-time fleet monitoring. The composite sort key design deliberately matches agent query patterns to allow efficient filtering without table scans. A Global Secondary Index on fleet_id helps provide tenant isolation. Amazon DynamoDB Streams trigger the intervention pipeline so the system reacts to critical safety events within seconds.

Amazon Bedrock

Amazon Bedrock provides the foundation model infrastructure for FleetGPT, offering access to multiple models. Amazon Bedrock Knowledge Bases handles the complete RAG pipeline for policy and documentation retrieval, alleviating the need for custom RAG infrastructure while maintaining the security and access controls already established for structured data.

Sub-agent delegation for specialization without coupling

The three-tier data analysis chain exists because each step requires fundamentally different reasoning. Consolidating these responsibilities into a single agent would degrade performance across multiple dimensions.

A monolithic agent must balance competing concerns in its system prompt, reducing effectiveness for each task. It must select from a larger tool inventory, increasing decision complexity and error rates. And when failures occur, diagnosing the root cause becomes significantly harder.

Separating these concerns means each agent can be prompted, tested, and improved independently, with clear failure boundaries at each tier.

Atomic system prompts for maintainability and debugging

System prompts are structured as composable, tagged instruction blocks rather than a monolithic string. Each instruction is a discrete, auditable unit which is tagged by category, named, and independently editable. When two instruction blocks produce conflicting behavior, the tag and block name tell you exactly where to look, without having to reason about the prompt as a whole. This made iterating on specific behaviors fast and safe.

Results

FleetGPT has delivered measurable operational impact across Novus Hi-Tech’s customer base:

1. 46 percent annual reductions in road-behavior violations.
2. Insights from data led to a 3–6 percent increase in fuel efficiency.
3. 55 percent reduction in drowsiness alerts per 1,000 km.

These improvements stem from four key operational transformations:

1. Warning validation time dropped from minutes to seconds: Investigating a single warning previously meant navigating multiple dashboard screens, manually filtering video feeds, cross-referencing driver history in separate tools, and looking up policy documents. Now it’s a single conversational query that surfaces video evidence, driver history, and fleet context together.
2. Real-time alert delivery within seconds: The DynamoDB Streams based pipeline replaced a polling-based system with multi-minute latency. Command Center operators now receive critical warnings within seconds of an event being recorded by an edge device in the field.
3. Self-service analytics for fleet managers: Fleet managers generate driver performance reports, fleet health summaries, and trend analyses without engaging the data team. Questions that once took hours or days are now answered in conversational turns.
4. Improved driver response rates in multilingual fleets: Delivering audio alerts in each driver’s native language has measurably improved acknowledgment rates across regional fleet segments, where a single-language approach previously left a significant portion of drivers underserved.

Conclusion and next steps

FleetGPT demonstrates how agentic AI can transform operational workflows when applied to domain-specific problems. By combining natural language interfaces with automated intervention systems, Novus Hi-Tech moved from reactive dashboard monitoring to proactive, context-aware fleet management.

Looking ahead, Novus Hi-Tech is expanding FleetGPT’s capabilities in three directions:

Amazon Bedrock AgentCore: Host the developed agent on Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model.

Predictive risk scoring: The dataset now carries enough behavioral history to surface vehicles trending toward incidents before they occur. The next capability will score drivers against their own baselines and flag deteriorating patterns proactively.

Embedded chart and visualization generation: Fleet managers think visually. Rather than returning tabular data, the agent will embed generated charts directly in responses for trend queries which will close the gap between insight and presentation without a separate business intelligence tool in the loop.

If you manage real-time operational data across distributed systems, FleetGPT offers a blueprint: start with the questions your teams ask most often, build agents that can answer them reliably, and then extend those agents to act on the answers.

For more information and relevant reads, see the following resources:

• Getting started with Strands Agents
• Text-to-SQL solution powered by Amazon Bedrock
• Sample Indic language voice bot

About the authors