NVIDIA FOX Blueprint: A Factory Manager Agent That Traces Defects to Their Cause

NVIDIA has published the Factory Operations Blueprint, called FOX, a reference design for a "factory manager agent" that investigates production problems across existing factory systems. In NVIDIA's technical post (November 4, 2026), the worked example follows one suspected solder defect on a circuit-board line from an inspection alert to a root-cause report, with a human in the loop at the risky steps. FOX is a blueprint, not a finished product: access is by early-access request, and the robot handling step is demonstrated only in simulation.

If you build agents, the interesting part is not the factory. It is the shape: one long-running manager with persistent memory, several narrow specialists, a sandbox that enforces policy, and explicit rules for when a person must approve. That pattern applies well beyond electronics.

TL;DR: what NVIDIA announced

Why factories need an agent at all

NVIDIA opens with a number from a Siemens report: unplanned downtime costs an average large plant in the surveyed sectors $253 million per year. The company's argument is that the data to respond to a problem usually exists, but gathering evidence across systems, consulting specialists and coordinating the next step takes people a long time.

A defect on a circuit board is a good example. The fault may show up at one station while the cause sits several steps earlier. Someone has to pull the board's history, the machine readings it saw, the manuals and the earlier incidents, and then decide. FOX tries to automate that evidence-gathering, not the final judgment.

How FOX is built

NVIDIA Factory Operations Blueprint architecture with a factory manager agent connected to data, models, skills and equipment over MCP Image: NVIDIA

NVIDIA describes three core components of the Factory Manager Agent, built with its NVIDIA Agent Toolkit:

• The LLM. It interprets tasks, connects data across factory systems, plans, and assesses results. NVIDIA says developers can choose a frontier model such as GPT-6 Astra or an open model such as Nemotron, depending on deployment requirements.
• The agent harness. NemoClaw is the default, with support for alternatives. It connects the manager to tools, skills, persistent memory and specialist agents, and runs background tasks and scheduled jobs so the manager stays available to the operator.
• NVIDIA OpenShell. It 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. We covered the runtime-control idea in our OpenShell and Sentry agent safety post.

Below the manager sit the specialists. Each has its own instructions, context, skills and tools, and returns findings to the manager. Equipment connects through Model Context Protocol (MCP) servers and APIs, plus ROS 2 and Isaac Sim for robot interfaces. If MCP is new to you, start with our MCP explainer.

What you build and what NVIDIA supplies

NVIDIA's own table splits the work. The blueprint supplies patterns; you supply the plant-specific parts.

The last column matters. "Output validation" and "handling policies" are left to the developer, which is where most production risk lives.

The worked example: one solder defect, end to end

The reference example is a surface-mount technology (SMT) line that builds printed circuit boards. NVIDIA lists eight stations: solder paste printer, pick-and-place, reflow oven, automated optical inspection (AOI) with in-circuit test, board integration, a manual standard-operating-procedure station, functional test, and packaging. NVIDIA notes this example is separate from the Siemens production-planning implementation.

Step 1: the AOI alert

The AOI station is exposed through an MCP server or API. For a flagged board, the manager retrieves the board identifier, the affected component and the inspection image, then asks for a second assessment. The board identifier is the join key: adapters preserve identifiers, timestamps, units and source references so agents can pull the board's history and the machine conditions it met.

Step 2: the Visual Inspection Agent

This specialist gets 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. NVIDIA says it uses in-context learning, so the model works from the examples and instructions at inference time without a separate fine-tuning step.

The specialist returns findings, evidence and any uncertainty. Three outcomes are possible. An acceptable variation returns evidence supporting continued production under factory policy. A confirmed defect moves on to handling and investigation. An inconclusive result goes to human review.

Step 3: the Fleet Management Agent

For a confirmed defect, the manager asks this specialist to move the board to rework. NVIDIA is explicit about the limit: the reference workflow shows the transport only in a digital twin built with Isaac Sim and ROS 2. A physical deployment needs factory-specific integrations for robot handling and autonomous mobile robot transport. The specialist checks permissions and capabilities and verifies completion before reporting back. NVIDIA recommends that initial deployments require operator approval before handling, and that operators repair and retest the board before packaging.

An approved stack of documents with a green stamp, standing for operator review before an agent acts

That approval gate is the safety design in miniature. The agent proposes, a person approves, and OpenShell policy limits what the agent can touch even if it is wrong.

Step 4: the Root Cause Analysis Agent

Root cause analysis PDF report from the factory manager agent blueprint showing evidence and a likely solder defect cause Image: NVIDIA

The root-cause specialist uses the board identifier and processing history to fetch inspection findings, placement records, electrical test results and machine measurements. A failed functional test can also trigger it, even when optical inspection saw nothing.

For a suspected solder defect, the board's reflow entry and exit times pick out the oven readings to examine. Kumo Anomaly analyzes those readings for unusual patterns. The agent then compares them with other production runs, inspection results and machine manuals to judge whether oven conditions contributed.

Elasticsearch stores production evidence, versioned manuals and prior investigations. NVIDIA says historical findings can guide the search, but the agent retrieves current procedures and records to support its conclusion. The output is a PDF with source records, suspect measurements, the likely cause and recommended corrective action, addressed to the line manager for review.

Note the wording: "likely cause" and "for review". The blueprint produces a hypothesis with evidence, not a verdict.

The Siemens numbers, and how far to trust them

NVIDIA ties the blueprint to the Siemens Electronics Factory in Erlangen, which it says produces more than a thousand products a year with frequent changeovers. Two figures appear in the post:

• For rush orders, agents built with FOX and powered by Nemotron run simulations through Siemens Intelligence Center X, balancing costs, existing orders, supply levels and line setups. NVIDIA says the end-to-end system can enable cost savings of up to 20%.
• For new product designs, Siemens combines its product lifecycle management software and Process Preparation X with NVIDIA Cosmos and Omniverse to generate a virtual prototype and synthetic training data. NVIDIA says this virtual production preparation can reduce time to market by up to 40%.

Both are "up to" figures, published by NVIDIA in its own post, with no baseline, sample size or independent audit. Treat them as vendor-reported ceilings. NVIDIA also says the production-planning example was shown at GTC 2026 Berlin and is separate from the SMT walkthrough, so the SMT demo carries no savings claim at all.

Privacy: the on-premises option

FOX can run on an NVIDIA DGX Station with the agent environment, models and data stores hosted locally. NVIDIA states a fully on-premises deployment requires every model and service endpoint to remain inside the factory network, which keeps production records, images, prompts and investigation results local. If you point the manager at an externally hosted model, NVIDIA says you must assess what data is sent there.

That caveat is easy to miss. The headline architecture lets you choose a frontier model, but the privacy promise only holds for local endpoints.

How this fits the wider agent trend

FOX follows a pattern we have seen in NVIDIA's recent agent work. The company has been publishing the pieces separately: sandboxed execution in OpenShell, evaluation loops in NeMo Compass and the NemoClaw blueprint, and verifier-driven tuning in NeMo Gym with Siemens EDA. FOX assembles them into a domain blueprint. Skills guide data onboarding, agent configuration and DGX Station deployment, which is the same idea described in our agent skills guide.

The physical-AI angle also connects to robot evaluation work such as RoboColosseum's 5,699 real-robot comparisons: simulation demos and real deployments are different claims, and FOX is clear that its robot step is the former.

There is a security side too. Factory control systems are already a target for AI-assisted attacks, as CISA warned in its alert on AI-generated exploits aimed at Siemens S7 PLCs. An agent that can read MES and ERP data and ask robots to move boards widens the attack surface. If you evaluate a blueprint like this, run it against policy checks first; AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions.

What to do if you build industrial agents

1. Start with read-only. Connect the AOI and history sources first. Let the agent write reports before it triggers any action.
2. Define the review gate in policy, not in the prompt. NVIDIA puts permitted actions and operator review into OpenShell policy. A prompt instruction is weaker than a sandbox rule.
3. Map identifiers early. The whole example depends on a board identifier that links stations. Mismatched timestamps or units will silently break root-cause matching.
4. Validate specialist output. NVIDIA lists output validation as your job. Compare the agent's reports against past human investigations before trusting them.
5. Decide your model boundary. If data must stay on site, use local endpoints for every model, not just the manager.
6. Test in simulation, then pilot with approval on every physical action. NVIDIA's own advice for early deployments.

What is still unknown

• Pricing and availability. NVIDIA points to an early-access request; the post gives no price, release date or support terms.
• Accuracy. The post gives no defect-detection accuracy, false-positive rate or root-cause hit rate for the SMT example.
• Independent results. The two Siemens figures come from NVIDIA's account. There is no third-party benchmark.
• Physical robot handling. Shown only in a digital twin.

For readers tracking how much to trust vendor agent demos, the pattern is the same as in other releases: check which parts were run for real, which were simulated, and who measured the result.

Details reflect NVIDIA's November 4, 2026 post and may change as the blueprint moves out of early access.

Related reading

• NVIDIA Open Agent Safety Platform: OpenShell and Sentry
• NVIDIA NeMo Compass and the NemoClaw blueprint
• NeMo Gym and Siemens EDA: 55% to 95%
• What is MCP? Model Context Protocol guide
• What are agent skills? Complete guide
• CISA warning on AI-generated Siemens S7 PLC exploits
• RoboColosseum real-robot comparisons
• NVIDIA: Add runtime controls to AI agents with OpenShell