# How NVIDIA Factory Operations Blueprint Coordinates AI Agents to Investigate Production Issues
> Source:
> Published: 2026-11-04 17:00:00+00:00
A Siemens report estimates that unplanned downtime costs an average large plant in the surveyed sectors $253 million [per year](https://assets.new.siemens.com/siemens/assets/api/uuid:1b43afb5-2d07-47f7-9eb7-893fe7d0bc59/TCOD-2024_original.pdf#page=3). Whether investigating a failed circuit board or responding to a rush order, factory teams must gather evidence across systems, consult specialists, and coordinate the next step. The data may be available, but turning it into a response takes substantial time and effort.
The NVIDIA Factory Operations Blueprint (FOX) provides a reference architecture for adding a factory manager agent to existing factory systems. Developers connect their existing data and tools, configure specialized agents, and define which decisions require operator review. These agents can monitor operations in real time, identify bottlenecks, investigate the root causes of errors or defects, and orchestrate robot fleets to reduce downtime and improve yield.
Production planning and inspection are two workflows where factory agents can help teams respond to new orders and product designs. At the [Siemens Electronics Factory in Erlangen](https://press.siemens.com/global/en/pressrelease/siemens-partners-nvidia-advance-ai-driven-autonomous-factories), which produces more than a thousand products a year, frequent changeovers for new products or orders make both tasks important. For rush orders, agents built with the FOX Blueprint and powered by NVIDIA Nemotron run simulations through Siemens Intelligence Center X. These simulations balance costs, existing orders, supply levels, and line setups—without requiring a planner to manually query each system. The end-to-end agentic system can enable cost savings of up to 20%. For new product designs, Siemens is [combining](https://news.siemens.com/en-us/siemens-nvidia-pcba-digital-twin-factory/) its product lifecycle management software and Process Preparation X with NVIDIA Cosmos and NVIDIA Omniverse to generate a virtual prototype and synthetic training data. This helps electronics manufacturers prepare and optimize automated optical inspection (AOI) processes before physical production begins. This virtual production preparation can reduce time to market by up to 40%.
The following super AI agent video includes the Siemens production-planning example from NVIDIA GTC 2026 Berlin.
This post presents a FOX reference example for a surface-mount technology (SMT) assembly line for printed circuit board (PCB) production. It explains how a factory manager agent connects factory data and coordinates specialized agents to inspect suspected defects, arrange rework, and investigate likely causes.
## Building a factory agent system with FOX
The Factory Manager Agent coordinates specialized agents and existing equipment using real-time factory data. Developers adapt the agent’s skills, data connections, knowledge, and tools to their production processes so that it can investigate problems and coordinate a response.
| **Component** | **Blueprint capabilities** | **Developer responsibilities** |
|---|---|---|
| Manager agent | Persistent agent environment with skills, tools, memory, and delegation | Task definitions, completion criteria, and application integration |
| Factory knowledge | Data onboarding and retrieval patterns | Mappings for identifiers, timestamps, units, and source permissions |
| Specialist agents | Workflow examples for inspection, root cause analysis, reporting, and fleet management | Factory-specific criteria, additional specialists, and output validation |
| Equipment integration | MCP and API integration patterns; equipment connections through ROS 2 and NVIDIA Isaac Sim | Physical equipment connections and handling policies |
| Deployment | Profiles for services, model endpoints, and optional simulated cells | Resource selection, endpoint configuration, and access boundary checks |
*Table 1. Blueprint capabilities and developer responsibilities for factory agent deployment*
### Factory Manager Agent components
FOX shows how to use the [NVIDIA Agent Toolkit](https://nvidianews.nvidia.com/news/enterprise-software-leaders-build-ai-agents-with-nvidia) to build a long-running Factory Manager Agent from three core components:
- [**LLM**](https://www.nvidia.com/en-us/glossary/large-language-models/)**:** Interprets tasks, connects data across factory systems, develops plans, and assesses results. Developers can choose a frontier model, such as GPT-6 Astra, or an open model, such as[NVIDIA Nemotron,](https://www.nvidia.com/en-us/ai-data-science/foundation-models/nemotron/) depending on deployment requirements.
- **Agent harness:** Connects the manager to tools, skills, persistent memory, and specialist agents. NemoClaw serves as the default harness, with support for alternatives. The harness manages background tasks and scheduled jobs while keeping the manager available to the operator.
- [**NVIDIA OpenShell:**](https://docs.nvidia.com/openshell/latest/about/overview) Isolates the execution environment and enforces access policies for files, commands, and network destinations. Factory policies define permitted actions and when operator review is required.
### Factory data and specialist agents
Developers connect existing machine databases, manufacturing execution systems (MES), and enterprise resource planning (ERP) systems through adapters and mappings. Manuals and operating procedures help the manager interpret the data. An Elasticsearch database stores information for retrieval and retains the investigation context.
The manager delegates focused tasks to LLM-based specialist agents, each with its own instructions, context, skills, and tools. Specialists can call models such as NVIDIA Cosmos for visual inspection and Kumo for time-series anomaly detection, then return findings to guide the manager’s next step. Developers can adapt these roles to their own production processes.
### On-premises deployment
FOX can run on an NVIDIA DGX Station with the agent environment, required AI models, and data stores hosted locally. A fully on-premises deployment requires every model and service endpoint to remain within the factory network. This keeps production records, images, prompts, and investigation results local. Developers using an externally hosted model must assess what data is sent to that endpoint.
The SMT reference example is separate from the Siemens production-planning implementation. It follows an AOI alert through inspection, rework, and root cause analysis; other factory workflows can use the same architecture with different data, specialists, and equipment connections.
## Applying FOX to an SMT assembly line
PCBs are used in many electronic products. SMT has largely automated their assembly, though some steps remain manual. When a defect is detected at one station, the problem may have originated several steps earlier.
An SMT assembly line can include the following stations:
1. Solder paste printer: Applies paste to component pads.
2. Pick-and-place machine: Positions components on the solder paste.
3. Reflow oven: Melts and cools the solder to form mechanical and electrical connections.
4. AOI and in-circuit testing (ICT): Check for visible defects and test electrical characteristics.
5. Board integration: Installs larger components.
6. Standard operating procedure (SOP) station: Handles manual assembly according to standard operating procedures.
7. Functional test: Checks that the board operates as intended.
8. Packaging station: Prepares the board for shipment.
An AOI alert may be a false positive, while a confirmed defect or failed functional test can require rework. For a suspected solder defect, the Factory Manager Agent coordinates a second inspection, arranges handling if needed, and investigates what went wrong.
### Receiving the AOI alert
Developers connect the AOI station through a Model Context Protocol (MCP) server or API that exposes inspection records to the manager’s tools. For the flagged board, the manager retrieves the board identifier, affected component, and inspection image, then requests a secondary assessment.
The board identifier connects this request to records from other stations. Adapters preserve identifiers, timestamps, units, and source references so the agents can retrieve the board’s production history and the machine conditions it encountered.
### Visual Inspection Agent
The Visual Inspection Agent receives the board image, reference examples, and approved criteria for that board design. It calls NVIDIA Cosmos, a world understanding model, to compare the suspected component against the factory handbook. With in-context learning, the model uses these examples and instructions during inference without a separate fine-tuning step.
The specialist returns its findings, supporting evidence, and any uncertainty. If the suspected defect is an acceptable variation, the specialist returns evidence supporting continued production under factory policy. A confirmed defect proceeds to handling and investigation; an inconclusive assessment goes to human review.
### Fleet Management Agent
For a confirmed defect, the manager asks the Fleet Management Agent to move the identified board to rework. The reference workflow demonstrates this transport in a digital twin using NVIDIA Isaac Sim and ROS 2. A physical deployment requires factory-specific equipment integrations for robot handling and autonomous mobile robot (AMR) transport. The specialist checks permissions and capabilities and verifies completion before reporting back. Initial deployments should require operator approval before handling. Operators repair and retest the board before packaging.
### Root Cause Analysis Agent
The Root Cause Analysis Agent uses the board identifier and processing history to retrieve inspection findings, placement records, electrical test results, and machine measurements. A failed functional test can trigger this investigation even when optical inspection finds no visible defect.
For a suspected solder defect, the board’s reflow entry and exit times identify the oven readings to examine. Kumo Anomaly analyzes those readings for unusual patterns. The agent compares these findings with other production runs, inspection results, and machine manuals to investigate whether oven conditions contributed to the defect.
Elasticsearch provides access to production evidence, versioned manuals, and prior investigations. Historical findings can guide the search, but the agent retrieves current procedures and records to support its conclusion. It returns a PDF report with source records, suspect measurements, the likely cause, and recommended corrective action for the line manager to review.
For this SMT line, FOX coordinates inspection, root cause analysis, and fleet management agents through connections to existing databases, factory systems, and machines. Together, they help the operator trace a defect to its likely cause, coordinate rework, and decide how to prevent further failures, reducing manual effort and helping keep production moving.
[Agent skills](https://www.nvidia.com/en-us/glossary/agent-skills/) guide data onboarding, agent configuration, and deployment to an NVIDIA DGX Station. Developers can customize the skills, tools, and specialist agents to support new workflows as factory needs evolve.
## Get started with FOX
NVIDIA FOX helps developers build factory manager agents that connect evidence across systems, investigate issues, and coordinate corrective actions—helping reduce downtime and improve quality while extending existing factory software.
- Request [early access to]() the FOX Blueprint
- Learn more about the [NVIDIA Agent Toolkit](https://docs.nvidia.com/nemo/agent-toolkit/latest/index.html)
- [Build specialized agents with VSS](https://build.nvidia.com/nvidia/video-search-and-summarization)