Building AI-augmented B-pillar DFMEA on AWS: Architecture, multi-agent orchestration, and implementation

In a recent post, we explored why manual B-pillar design failure mode and effects analysis (DFMEA) is failing at scale, routinely missing 40–60% of potential failure modes, and how engineering ontologies enable AI to reason about failure mechanisms rather than merely pattern match against historical text. We established that the ontology is the differentiator; it captures causal chains linking materials, processes, failure mechanisms, and effects, elevating AI beyond sophisticated search capabilities to genuine engineering reasoning.

In this post, we deliver the implementation blueprint. We walk through the complete reference architecture built on Amazon Web Services (AWS), break down the layer service topology, detail the multi-agent orchestration pattern using Amazon Bedrock AgentCore and the Strands Agents SDK.

This post is written for machine learning (ML) engineers, solutions architects, and automotive engineering leaders who are ready to learn implementation. By the end, you’ll have a deployable architecture, working code patterns, and a clear path to your first AI-augmented DFMEA pilot.

Prerequisites

To implement AI-augmented DFMEA as described in this post, you’ll need:

• An active AWS account with access to Amazon Bedrock foundation models
• An Amazon Neptune cluster (engine version 1.3.0 or later) for the ontology knowledge graph
• Basic familiarity with the AIAG & VDA FMEA Handbook and Risk Priority Number (RPN) scoring methodology
• Component design data such as geometry or functional specifications, material certifications, and interface definitions
• (Optional) Historical DFMEA records, warranty claims, crash simulation results, or field failure data for knowledge base enrichment
• AWS Identity and Access Management (IAM) permissions configured for Amazon Bedrock, Amazon Simple Storage Service (Amazon S3), AWS Lambda, Amazon DynamoDB, Neptune, AWS Step Functions, and Amazon OpenSearch Serverless

Ontology foundation: Why structure matters

The ontology is the backbone of every AI-augmented DFMEA. Without it, a foundation model (FM) is pattern-matching against unstructured text, capable of generating plausible-sounding failure modes but unable to reason why a specific material-process combination produces a specific failure mechanism. With a curated ontology, the system understands that a 22MnB5 boron steel hat section subjected to austenitization at 920° C has fundamentally different failure paths than a conventional high-strength low-alloy (HSLA) stamping because the ontology encodes the causal chain from austenitization through hydrogen absorption to delayed fracture at the heat-affected zone.

For a B-pillar with more than 37 interfaces (including roof rail welds, rocker panel joints, seat belt anchors, and door hinge reinforcements), the ontology ensures that no material-process-environment interaction is overlooked. It maps every relationship in a structured graph that agents can traverse programmatically and not search heuristically.

The architecture has four layers that work together: a graph schema on Neptune and three write triggers. The knowledge graph stores entity classes connected by relationship types. The key insight is that traversability agents can reach any failure mechanism from a component in only two or three hops. Each function of a component is subject to failure modes driven by underlying effects.

The following figure shows how the DFMEA ontology is modeled in Neptune and how new knowledge is written into it. The top panel is the graph schema, with the entity types and the relationships an agent traverses to reach a failure mechanism.

The bottom panel shows the three event-driven pathways through which ontology data is loaded, curated, and imported, plus the write pipeline that carries each change into the graph. The ontology is a living knowledge base, updated through these three distinct triggers:

1. Seed load – A data scientist authors the initial ontology as JSON-LD, converts it to N-Quads, and bulk loads it into Neptune. An OntologyUpdated event fires using Amazon EventBridge, triggering downstream cache rebuilds.
2. Amazon Augmented AI (A2I) approved curation – During ongoing DFMEA operations, data scientists propose new terms or relationships. These flow through Amazon DynamoDB to Amazon Simple Notification Service (Amazon SNS) to a Step Functions waitForTaskToken gate through the React portal with Amazon Simple Email Service (Amazon SES) email notifications for human-in-the-loop (HITL) approval. Approved changes are applied using SPARQL UPDATE to Neptune with automatic version bumping, versioned snapshots stored in Amazon S3, and an immutable ledger entry in DynamoDB.
3. Authoritative imports (quarterly) – Standards bodies release updated failure taxonomies, such as Automotive Industry Action Group (AIAG) and German Association of the Automotive Industry (VDA) time to live (TTL) files and International Organization for Standardization (ISO) catalogs. An ingestion pipeline will build and validate these imports, perform Interface Risk Index (IRI) reconciliation to prevent duplicates, and merge new knowledge into the existing graph.

Figure 1: Ontology implementation architecture

The following screenshot shows version-pinning and agent query patterns. The top panel explains version-pinning, which is how agents read the ontology safely while it keeps changing. Every analysis is pinned to a fixed ontology version so reads stay deterministic and auditable while writes continue in the background. The bottom panel shows the seven SPARQL query stages an agent executes against the version-pinned Neptune reader endpoint, with example queries for term resolution, failure-mode discovery, and IRI deduplication.

Figure 2: Version-pinning and agent query patterns

The read pattern: Version-pinned queries

Every DFMEA review session pins to a specific ontology version at start so that interim updates never corrupt in-progress analyses. Agents query the Neptune reader endpoint through Amazon Bedrock AgentCore Gateway at each pipeline stage, as outlined in the following table.

This intentionally asynchronous design with EventBridge triggered cache rebuilds, version-pinned reviews, and explicit latency budgets per query type maintains the ontology as both a continuously improving knowledge base and an auditable foundation for every AI-generated DFMEA.

Solution architecture: End-to-end flow

The system is organized into six distinct layers, each with clear service boundaries and failure of isolation. The following walkthrough traces a single DFMEA review from the browser to the final PDF, calling out the AWS services at every layer.

Frontend and authentication layer

This layer authenticates the reviewer and starts the workflow. Amazon S3 and Amazon CloudFront with origin access control (OAC) serve the React web app privately over HTTPS. Amazon Cognito authenticates users through the human user pool and issues JSON Web Tokens (JWTs). Amazon API Gateway (REST) routes requests while AWS WAF filters traffic. Lambda (dfmeaapi function) invokes StartExecution to launch the pipeline.

AWS Step Functions layer

The Step Functions state machine coordinates every stage and enforces human approval at each gate:

1. The intake stage normalizes the input, and the extraction stage pulls structured data from uploaded documents.
2. An ML prescreen runs a fast statistical pass using a random forest model for severity scoring, an isolation forest for anomaly detection, and a label encoder for failure-mode categorization.
3. Four specialist agents (failure mode, structural, regulatory, and additional-schema) perform AI-driven analysis.
4. The analyst agent synthesizes the findings into a PDF report.
5. Four HITL gates pause execution for human signoff, with Amazon SNS notifications at each checkpoint.

Asynchronous ingestion layer

This event-driven path intakes and processes documents:

1. Documents upload directly to an S3 bucket through a presigned URL.
2. EventBridge fires an object-created event that triggers a separate Step Functions ingestion flow.
3. Amazon Textract runs asynchronous optical character recognition (OCR) to extract text.
4. Results are written to DynamoDB for downstream consumption.

Real-time WebSocket layer

This layer gives the reviewer a live view of pipeline progress instead of polling:

1. The browser holds an open WebSocket connection through API Gateway.
2. A Lambda function tracks active connection IDs in a DynamoDB WebSocket connections table.
3. As the pipeline advances or gates change, updates are pushed down the socket in real time.

Amazon Bedrock AgentCore layer

This is the AI reasoning layer where findings are generated and synthesized:

1. Four specialist Amazon Bedrock AgentCore Runtime instances (failure mode, structural, regulatory, and other) invoke Amazon Bedrock foundation models (such as Claude by Anthropic) to generate findings.
2. Each agent grounds its answers by retrieving context through the Model Context Protocol (MCP), which connects to the DFMEA tool suite backed by DynamoDB, Amazon Bedrock Knowledge Bases, Neptune, and Amazon S3.
3. Machine-to-machine authentication is handled through AWS Secrets Manager, which issues tokens from the Amazon Cognito machine-to-machine token service.
4. A separate analyst Runtime instance maintains conversational context in Amazon Bedrock AgentCore Memory, enabling synthesis across multiple specialist outputs.

Data and security layer

This layer stores all data securely and supplies the knowledge that the agents reason over:

1. AWS Key Management Service (AWS KMS) encrypts all data at rest.
2. DynamoDB stores review status, gate decisions, WebSocket connections, and agent findings with risk scores.
3. S3 domain buckets hold processed documents and reports.
4. A Lambda search-indexer function feeds OpenSearch Serverless, which backs the Amazon Bedrock knowledge base that agents query.
5. Neptune stores ontology relationships, queried through SPARQL.

The following diagram illustrates the solution architecture.

Figure 3: AWS architecture for the agentic DFMEA review system

Multi-agent architecture detail

The DFMEA analyst agent serves as the single point of coordination. It receives the component package, decomposes the analysis into subtasks, delegates to specialists, synthesizes their findings, resolves contradictions, and produces the final ranked output. It operates through the Agents as Tools pattern in the Strands Agents SDK. Each specialist is registered as a callable tool that the analyst agent invokes with structured inputs and that can receive structured outputs.

The system uses two complementary communication patterns:

• Asynchronous (Amazon SQS agent-to-agent queue) – Specialists deposit intermediate work products (such as partial failure mode lists or interface analyses) into the Agent2Agent (A2A) queue. The analyst polls and aggregates. This enables true parallel execution for all four specialists to work simultaneously at S4 without blocking each other.
• Synchronous (MCP HTTP API) – For real-time tool calls (such as for ontology queries or knowledge base retrieval), agents invoke tools using the MCP over HTTP through API Gateway.

The ontology thread

Visualized as the green horizontal line in the architecture diagram, the ontology thread enforces semantic coherence across agents. Before any finding advances to the next stage, it must pass ontology validation:

1. Every failure mode must resolve to a valid IRI in the ontology graph.
2. Every causal chain (from process to mechanism to effect) must have a traversable path in Neptune.
3. Conflicting assertions from different agents are flagged for the analyst agent to resolve using ontology precedence rules.

HITL gates: Four checkpoints

The HITL gates act as four checkpoints. Ontology changes are triggered by any proposed new entity or relation and are approved by a data scientist. Low-confidence findings in which agent confidence drops below 0.6 must be approved by a domain engineer. When two specialists contradict on severity or mechanism, a DFMEA analyst and a human must resolve the disagreement. And final approval in the form of a complete DFMEA report ready for release must be given by the lead engineer. Each gate emits an auditable record for the decision, timestamp, rationale, and any overrides stored immutably in the Amazon S3 audit package.

Benefits for engineering organizations

By implementing this solution, engineering organizations can gain several benefits, including completeness, speed, and consistency.

Ontology traversal systematically explores paths that human memory overlooks, providing a more complete failure mode coverage – surfacing failure modes, causes, and effects that manual reviews routinely miss. Automation means teams can get results in hours instead of weeks, enabling DFMEA at the pace of agile development cycles.

Because the same component analyzed twice produces the same results (deterministic ontology paths), organizations can be confident in those results. Institutional knowledge is preserved because engineering expertise is encoded in the ontology, not lost when engineers move on. The solution enables cross-program learning because failures discovered on one vehicle program automatically inform all future analyses.

Failure modes trace back to an ontology path, source document, or historical precedent, providing traceability that matters for audits, regulatory compliance (such as ISO 26262 and IATF 16949), and root-cause investigations. Every finding is defensible and evidence-backed rather than asserted. DFMEAs update automatically when the ontology evolves or new data arrives, providing living documentation that organizations can rely on as continuously up-to-date. The solution is scalable. You can run parallel DFMEAs across an entire vehicle Bill-of-Materials (BOM) without proportional headcount increases.

Conclusion

In this post, we introduced how you can reimagine B-pillar DFMEA analysis on AWS by combining a serverless ingestion pipeline with a conversational AI agent, with both coordinated through a shared data layer (on Amazon DynamoDB and Amazon Bedrock Knowledge Bases) without direct coupling. We explained how the architecture follows two guiding principles: decoupled flows, in which chat and ingest operate independently, and cheap-before-expensive solutions in which classical ML prescreens deterministic questions in milliseconds before engaging large language model (LLM) reasoning.

We also provided an overview of the architecture lanes from edge security (using AWS WAF and Amazon Cognito) through the Step Functions pipeline, the ML prescreen layer (isolation forest, random forest, named entity recognition (NER) with nightly retraining by Amazon SageMaker), and the observability and governance layers that provide production readiness. The architecture uses five agents in total: an interactive chat agent, an orchestrator, and three specialist gaps, anomalies, and patterns (GAP) [JD1] detection agents keeping each agent’s scope narrow for accuracy and enabling parallel execution.

We take this architecture from diagram to deployment with a step-by-step implementation guide, including infrastructure as code (IaC) templates and agent configuration, that ingests a sample B-pillar DFMEA workbook and answers gap-analysis questions in natural language. As the system runs, it enriches the knowledge graph; each human review refines its calibration, and each new material or process broadens the coverage of future analyses. The result isn’t a one-time deployment but an engineering asset that improves use.

To get started, find the sample code and a demonstration of the solution in the accompanying Github repository.