In automotive software, costly problems often are not the ones that violate a coding rule or fail a compiler check. They are the ones that pass linters, traceability gates, static analyzers, and still surface as problem reports when components interact on real hardware for the first time.

In a previous blog post, we described how AUMOVIO built an AI-powered engineering assistant on Amazon Bedrock that generates automotive-grade embedded code. That system accelerates development. However, generating code is only half the challenge. The other half is catching the problems that pass every check and only surface when components meet the target hardware. Hence, AUMOVIO and AWS partnered again to develop the problem finder, a multi-agent system that transforms patterns from historical problem reports into structured detection templates and applies them systematically across entire codebases, catching the kind of issues that typically surface only during physical vehicle integration.

Together, the engineering assistant and the problem finder form a closed loop: one accelerates development within known standards, the other systematically detects problems that traditional static tools and standard validators typically miss.

Challenge

Building the software stack for a modern vehicle is challenging on multiple levels. Technically, it requires integrating several Electronic Control Units (ECUs) such as High-Performance Computers, Zonal Control Units, etc. from different suppliers, each with their own codebases and communication protocols. Organizationally, these suppliers often integrate their components for the first time on the Original Equipment Manufacturer (OEM)’s physical test vehicle. This is where emerging problems can become expensive. In fact, inconsistencies between specifications and implementation that surface during OEM integration are among the most expensive to resolve. In automotive software development, the cost of fixing an issue rises sharply the later it is discovered. Therefore, detecting problems earlier in the development cycle is crucial with respect to cost and quality.

Traditional tools such as compilers, static analyzers, and standards validators catch a wide range of issues, but they verify against predefined rules and expected behaviors. Integration and system tests go further, verifying cross-component interactions, but only for scenarios that were anticipated at test-design time. Issues whose specific manifestation was not predicted from individual component specifications remain undetected until hardware integration. The reason is that compilers and static analyzers operate on individual files or modules to verify syntax or type safety, but do not reason about the semantic intent behind, for example, a signal mapping. While dynamic testing can catch more potential issues, the detection typically happens only late in the development cycle when components are already integrated.

This motivated AUMOVIO to build the problem finder. It combines cross-component specifications, AUTomotive Open System ARchitecture (AUTOSAR) configurations, and implementation code in a single analysis context. This allows the finder to detect semantic inconsistencies that traditionally surface only during OEM integration testing – well before code reaches the test vehicle.

The Problem Finder

Problem Templates

At the heart of the problem finder is a library of problem templates. These are structured documents describing common categories of software issues. Each template guides the AI agent on how to identify them. AUMOVIO developed templates covering the most frequent issue categories, as shown in two examples below:

Table 1: Example of problem categories

Building these templates is where AUMOVIO’s automotive expertise becomes tangible: each template is grounded in years of project history using historical problem report data, lessons learned across ECU generations and platforms, and the knowledge of senior engineers who have debugged the issue categories across multiple vehicle programs. Importantly, templates are not static artifacts. There is a dedicated feedback loop that keeps them alive. More specifically, automotive experts review findings in the field, annotate false positives and missed issues, and feed this signal back into the templates. The template follows a consistent structure designed to guide the AI agent through a systematic investigation presented below:

1. Detection Patterns and Indicators

Templates provide the agent with concrete patterns to look for in code. For example, the value mapping inversion template (PT-011) instructs the agent to watch for counterintuitive boolean logic, magic values with hidden semantics, and naming contradictions, for instance a variable named “enabled” that is assigned a value meaning “disabled.”

2. Phased Analysis Instructions

Each template guides the agent through four analysis phases:

• Phase 1: Discover/Identify Requirements: Determine expected behavior from specifications and architecture documents
• Phase 2: Verify Implementation: Check whether the code matches the identified requirements
• Phase 3: Analyze Observed Behavior: Understand actual system behavior from logs, traces, and test results
• Phase 4: Identify Root Cause: Determine the exact cause of the software problem.

Each phase specifies what files the agent needs to load, what to investigate next, and what patterns to look for, preventing the agent from aimlessly reading code and instead focusing its reasoning on productive analysis paths.

3. Decision Criteria and Confidence Levels

Templates define explicit criteria for when to report an issue and at what confidence level (high, medium, low), along with the specific conditions that must be met for each level.

4. Worked Example Reasoning

Each template includes a complete case study based on a real-world AUMOVIO example showing the analysis chain from discovery to root cause.

Multi-agent Architecture

Figure 1: Problem finder architecture

The problem finder is built using the open-source Strands Agents SDK, powered by foundation models on Amazon Bedrock and running on Amazon Bedrock AgentCore. The multi-agent architecture is depicted in Figure 1. The solution supports two access patterns:

• User Interface (UI)-based access: User A interacts through a web application served through Amazon CloudFront, with Amazon Cognito handling authentication
• Programmatic access: User B invokes the agents directly via software development kit (SDK), suitable for scheduled analysis runs or continuous integration/continuous delivery (CI/CD) pipeline integration

Regardless of the entry point, all requests reach Bedrock AgentCore, the central runtime orchestrating the multi-agent workflows, backed by Bedrock as the large language model (LLM) engine for reasoning over code, architecture, and documentation. The supporting infrastructure consists of:

• Amazon Elastic Container Service (ECS) hosts the backend services, sitting behind an Application Load Balancer on the UI path
• Amazon Simple Storage Service (Amazon S3) (Frontend Files) stores and serves the static web application assets
• Amazon S3 (File Operation Tools) stores input artifacts and generated analysis reports
• AWS Lambda triggered automatically by S3 events to redeploy the frontend whenever new reports or updates are generated

Figure 2: Automotive agents overview

The multi-agent system separates concerns between orchestration and analysis. It is made up of two agents with distinct roles as shown in Figure 2.

Orchestrator agent manages the analysis workflow end-to-end: it resolves which projects and problem templates to analyze, partitions work across multiple parallel Analysis Agent invocations, tracks progress and synthesizes individual findings into a consolidated report. For a full analysis run, this means coordinating dozens of template-project combinations while managing dependencies between related templates.

Analysis agent instances each perform a focused investigation against a single problem template. For each assigned task, the agent:

• Loads the relevant problem template from Amazon S3
• Builds a function index of the target codebase – mapping C/C++ functions, AUTOSAR-generated interfaces, and configuration entry points to their file locations
• Retrieves the project structure, including code files, XML configurations, and requirements documents
• Systematically scans relevant files following the template’s phased analysis instructions
• Creates structured problem reports for each identified issue

For large automotive codebases, the analysis agent employs targeted reading strategies: files exceeding 500 lines are accessed only via specific line ranges or search patterns, and the agent maintains a map of examined files to avoid redundant reads. Both agents leverage Amazon Bedrock’s extended thinking capability, which allocates a dedicated reasoning budget before generating responses. The Analysis agent reasons through cross-references between AUTOSAR XML configurations, C implementation files, and requirements documents to evaluate whether observed code patterns match the template’s detection criteria before committing to a finding. This deliberate reasoning step is what separates the problem finder from pattern-matching tools that flag syntactic issues without understanding semantic intent.

Operating Modes

The problem finder supports two operating modes — Full Analysis and Delta Analysis. Both use the same problem templates and analysis logic but differ in scope and resource utilization. The table below describes the differences in more detail:

Table 2: Operating modes overview

Using the Problem Finder

Figure 3: Problem finder UI homepage

The problem finder provides a web interface with two main functions (see Figure 3): code scanning and issue tracking. Users can launch analysis runs with configurable settings, manage and filter findings, and view a dashboard with current metrics such as the number of projects, files analyzed, and issues found.

The scan interface allows project selection and analysis configuration. In this example, a development project with 209 files is selected for analysis in diff mode. The agent prompt specifies the analysis scope, focusing on specific automotive software concerns like communication signal routing or diagnostic service response. Users can edit the prompt before initiating the scan. During analysis, the agent’s reasoning and progress are streamed back in real-time, and users can send follow-up prompts within the same session to ask clarifying questions or steer the analysis deeper into specific areas.

In Figure 4, you can see an example scan call conducted from the UI on a sample project:

Figure 4: Example software scan animation

As described before, the problem finder is also accessible programmatically via SDK calls, making it suitable for automation pipelines. The example demonstrates invoking the same analysis shown in the UI example, using boto3 wrapped in an invoke agent function. The prompt structure mirrors the UI configuration for consistency across interfaces.

prompt = """Analyze these projects: **project_2_diff**
Focus on finding these problem types:
**Communication Signal Routing, Diagnostic Service Response, E2E Protection Failure** with diff mode"""

response_text = invoke_agent(agent_arn="ARN of the deployed Amazon Bedrock AgentCore agent",prompt=prompt,region=region)

Report Output

At AUMOVIO, software issues are tracked as Jira tickets following a standardized structure. The problem finder generates its reports in the same format: title, priority, severity, affected files, expected vs. observed behavior, root cause analysis, and remediation suggestions. You can see the generated ticket example in Figure 5, showing the Issue Tracker UI overview interaction on an example project.

Figure 5: Example issue dashboard animation

Because the AI-generated reports match the structure of human-written tickets, they integrate directly into AUMOVIO’s existing workflow without requiring any additional tooling.

Human-in-the-loop for continuous improvement

Figure 6: Human-in-the-loop continuous improvement

Problem templates are not static. In fact, they improve through a human-in-the-loop feedback cycle. After the agent produces findings, a domain expert reviews the results to assess accuracy: are the identified problems real, or are they false positives? Based on this review, the expert refines the template, adjusting detection criteria, adding exclusion rules, or sharpening the problem definition. The updated template is then used in the next analysis run, producing progressively more precise results with each iteration.

Evaluation

To evaluate the problem finder under real conditions, AUMOVIO ran the system on a production automotive component, a security- and safety-relevant subsystem, that had already passed traditional tooling and review cycles. In a single scan, the problem finder surfaced more than 30 high-priority findings across six distinct categories. Importantly, all these new findings were net-new and had not previously been detected by static analysis tools or earlier review cycles.

In AUMOVIO’s project history, issues of this nature typically surface only in late-stage car integration testing, where the cost to resolve them is far more expensive than during development. The ability to detect them during routine code review underlines the problem finder’s core value proposition.

Each finding is reviewed by an automotive domain expert who classifies it on a four-point validation scale (invalid, medium, high, critical). Table 3 shows three representative templates from AUMOVIO’s broader library, spanning the range of outcomes.

Table 3: Validation results for three example templates.

The Communication Signal Routing result demonstrates the importance and power of the human-in-the-loop for continuous improvement. Expert annotations such as “different addresses” or “feature not required in final scope” are written back into the template definition, sharpening the detection criteria for the next analysis run. Templates that consistently produce invalid findings are refined or retired entirely.

Delta analysis proved particularly valuable in CI contexts where the system detected several critical findings on the modified code within minutes – short enough to run on every pull request. AUMOVIO recommends full analysis before major architectural milestones and delta analysis for continuous integration and routine pull-request review. The expansion of the template library continues, driven directly by the findings and expert feedback from ongoing scans.

Conclusion

The problem finder changes how AUMOVIO can manage software quality at scale. Static analysis catches only syntax-level issues, and manual reviews depend on who is available. Instead, AUMOVIO distills patterns from historical problem reports, captures the reasoning of its most experienced engineers in reusable problem templates, and runs those templates across entire codebases using multi-agent AI on Amazon Bedrock. On a real production component, it found issues that would normally appear only during late-stage vehicle integration with domain experts confirming they were relevant. Every run adds more findings and expert feedback, so the templates as well as the solution’s ability for accurate detection keep improving.

The problem finder also pairs with AUMOVIO’s engineering assistant. An issue detected by the problem finder can go straight to the assistant for code-change proposals, closing the loop from detection to resolution.

For further guidance, visit the AWS for Automotive page, explore the Strands Agents SDK on GitHub, learn more about AUMOVIO’s innovation journey on AWS, visit AUMOVIO on AWS: Case Studies, Videos, Innovator Stories, or reach out to your AWS account team.