The NVIDIA Factory Operations Blueprint, called FOX, is a reference design for a "factory manager" agent. The agent sits on top of the systems a plant already runs and hands work off to specialist agents. NVIDIA's Nov. 4 technical blog, written by Samuel Ochoa and Carlos Garcia-Sierra, walks through one surface-mount (SMT) circuit-board line. It follows a single suspected solder defect from an automated optical inspection (AOI) alert to a root-cause report in PDF.
FOX is early-access developer software. Before a plant requests access, the question for operations is whether its MES, ERP, machine and inspection records can be joined tightly enough to give the agents something to reason over. The blog says more about that than the launch coverage did, and it also leaves some gaps.
What is the NVIDIA Factory Operations Blueprint?
In NVIDIA's May 31 announcement at GTC Taipei at COMPUTEX, Esther Lee described FOX as "a reference design for building an autonomous factory manager agent." On a plant floor, that means a coordinating agent that pulls context from existing systems and sends tasks to three specialists described in the Nov. 4 blog:
-
Visual Inspection Agent, which calls NVIDIA Cosmos for a second look at flagged images.
-
Fleet Management Agent, which moves boards. The blog shows it only in a digital twin built with NVIDIA Isaac Sim and ROS 2.
-
Root Cause Analysis Agent, which uses Kumo Anomaly on machine readings and Elasticsearch for evidence retrieval.
The language model underneath can be a frontier model or an open model such as NVIDIA Nemotron. The default agent harness is NemoClaw. NVIDIA OpenShell isolates execution and enforces file, command and network policies.
The release status matters for planning. On May 31, NVIDIA said FOX wasn't available yet and offered a sign-up for notification. The Nov. 4 blog points readers to an NVIDIA early access request page. Infraday reported that early access began Oct. 21 and called FOX "an early-access developer blueprint, not a completed factory deployment product." Budget for it as an integration project with reference code, not as a software purchase.
What data does FOX need connected first?
The blog names four kinds of input. First, existing machine databases, along with "manufacturing execution systems (MES), and enterprise resource planning (ERP) systems through adapters and mappings." Second, manuals and operating procedures. Third, an Elasticsearch store that holds retrieval and investigation context. Fourth, the AOI station, exposed through an MCP server or an API.
The only data discipline the blog spells out is mapping. Developers define "mappings for identifiers, timestamps, units, and source permissions," and adapters "preserve identifiers, timestamps, units, and source references." That's a short list, but it's the hard part of most plant data projects.
The SMT example shows why. After an AOI alert, the manager agent pulls the board ID, the component and the image. The root-cause agent then collects inspection, placement, electrical test and machine data for that same board. If AOI logs a panel serial, the placement machine logs a lot number and the test station logs its own record key, the agent can't follow the board through the line unless someone has built the cross-reference.
A practical readiness test is to pick one board that failed AOI last month and try to pull its full history by hand. That means its AOI image and call, its placement record, its electrical test result and the reflow-oven readings from the minutes it was inside the oven. If an engineer needs three systems, a spreadsheet and a phone call to do it, an agent will hit the same wall. Mismatched clocks between stations and readings logged in different units both break the join.
Does FOX work with historians, PLCs or OPC UA?
The Nov. 4 blog doesn't say. It doesn't mention historians, PLCs, OPC UA, sampling rates, a data model or data-quality standards. That's a gap in the documentation, not evidence about what the software can or can't do. It does mean the integration effort for machine data depends on your plant, and you should scope it before assuming anything.
The only time-series example in the blog is the reflow oven. The root-cause agent selects oven readings using the board's reflow entry and exit times, runs Kumo Anomaly on them and compares the results with other runs and with the equipment manuals. That approach only works if oven data is stored with timestamps that line up with the board's tracked entry and exit events. Plants whose oven data sits in a historian at a coarse interval, or only on the machine's HMI, should expect to build that pipeline themselves.
Can FOX run fully on-premises?
Yes, according to NVIDIA, with conditions. The blog says "FOX can run on an NVIDIA DGX Station with the agent environment, required AI models, and data stores hosted locally." It adds that "a fully on-premises deployment requires every model and service endpoint to remain within the factory network."
That second sentence is the one IT and OT teams should focus on. If the manager agent calls an externally hosted frontier model, the plant has to assess what data goes out with each request. That could include inspection images, part numbers or process readings. The blog gives no GPU counts or detailed hardware specs, so sizing a DGX Station for a given line is still an open question.
Security review will center on OpenShell, which is where file, command and network policies are enforced. Those policies decide what the agents can read, what they can execute and which endpoints they can reach. They should be written by whoever owns the plant network boundary, not left at defaults set by the integration team.
Which agent actions need operator sign-off?
The blog builds in human approval at several points, and they make a good default policy:
-
"Initial deployments should require operator approval before handling," meaning before a robot moves a board.
-
Visual checks that come back inconclusive go to a human. In the example, acceptable variation lets the board continue, a confirmed defect moves it on to rework and root-cause work, and anything uncertain goes to a person.
-
The line manager reviews the root-cause report before any corrective action.
-
Operators repair and retest boards before packaging.
The blog also says factory policies define when operator review is required. That puts the job on the plant. A simple way to start is to sort every action an agent might propose into one of three tiers before writing any code. The worksheet below is our editorial framework, not NVIDIA's.
| Tier | What the agent does | Examples from the SMT flow | Suggested gate |
|---|---|---|---|
| Read-only | Queries records, retrieves images and manuals | Pulling board ID, AOI image, placement and test records, oven readings | Governed by source permissions in the mappings |
| Recommend | Produces a judgment or report a human acts on | Secondary visual assessment; root-cause PDF with suspect measurements and recommended fix | Human review of inconclusive calls; line manager approves before corrective action |
| Actuate | Changes something physical or a system of record | Robot moving a board to rework; any recipe or parameter change | Operator approval on every action in early deployment |
Recipe or parameter changes aren't part of the blog's example. They're on the list because someone will ask for them, and they belong in the actuate tier.
How much weight should the Siemens and Foxconn results carry?
Treat them as vendor-reported potential, not measured outcomes. The Nov. 4 blog describes Siemens' Erlangen electronics plant, which makes more than a thousand products a year. There, FOX and Nemotron agents run rush-order simulations through Siemens Intelligence Center X. NVIDIA writes that "the end-to-end agentic system can enable cost savings of up to 20%" and that virtual production preparation with Siemens PLM, Process Preparation X, Cosmos and Omniverse "can reduce time to market by up to 40%." Neither figure comes with a baseline or a method.
Siemens' Oct. 19 press release describes the same work differently. It says "an AI agent now supports this process" for rush-order planning in Erlangen, and that the approach "can enable cost savings of up to 20 percent." For virtual preparation it uses a different metric: it "can reduce engineering effort by up to 85 percent." The release also says "more than 100 AI algorithms are already in active use." It names the NVIDIA Factory Operations Blueprint but doesn't use the FOX label.
The adopter figures in NVIDIA's May 31 post are company projections or self-reported results. Foxconn, using a multi-agent system called MoMClaw, projects 80% faster root-cause analysis, 15% higher labor productivity and 10% fewer machine failures. Pegatron estimates 15% lower asset-redundancy costs. Advantech projects a 10% energy reduction. DeepHow says its agent can raise first-pass yield by 3%. Spingence reports 99.6% defect recall and a 78% cut in defect escapes at Cooler Master. Wistron is building SMT agents for line analysis, root-cause work and quality control. None of these numbers should go into a capex request as an expected return.
Where does the payback case come from?
It comes from your own downtime and quality-escape costs, not from vendor percentages. The Nov. 4 blog cites a Siemens report estimating that "unplanned downtime costs an average large plant in the surveyed sectors $253 million" a year. That's NVIDIA's citation of a survey of large plants. It isn't a benchmark for a 200-person contract manufacturer.
A more useful exercise is to price one recurring problem, such as a solder defect that takes an engineer two shifts to trace. Our downtime cost calculator separates lost contribution margin from incremental recovery costs like overtime, expedited freight and scrap. If faster root-cause work would only shorten investigations that cost little, the agent project won't pay back no matter what the reference design can do.
Readiness checklist before requesting early access
A mid-market plant can do most of this work without any NVIDIA software, and it improves MES reporting either way.
-
ID mapping. Document how a board, serial or lot ID appears in AOI, placement, electrical test, MES and ERP, and build the cross-reference.
-
Timestamp hygiene. Sync station clocks to a common source and confirm that oven or process readings can be sliced by a part's entry and exit times.
-
Unit consistency. List the units each source uses for temperature, time and measurement, and decide where conversion happens.
-
Source permissions. Decide which systems an agent may read, and which fields are off-limits, before writing adapters.
-
Inspection access. Check whether your AOI vendor exposes an API, or whether you'll need to build an MCP server or an export.
-
Documents. Gather current manuals and SOPs in a searchable form. Outdated procedures will produce outdated recommendations.
-
Approval policy. Fill in the read-only, recommend and actuate worksheet with the people who own the line.
-
Network boundary. Decide whether every model endpoint must stay inside the factory network. If not, define what data may leave.
If the ID cross-reference turns out to be the blocker, the MES evaluation is the bigger decision. Settle it before scoping any agent pilot.
Related reading
-
How the New AI Agents for Manufacturing From Tulip, Siemens and Honeywell Compare
-
How a sole-source rib kit stalled Boeing's 777 Freighter wing line
Sources
-
How NVIDIA Factory Operations Blueprint Coordinates AI Agents to Investigate Production Issues, NVIDIA Technical Blog, Nov. 4, 2026
-
NVIDIA Factory Operations Blueprint Gives Factories a New AI Brain, NVIDIA Blog, May 31, 2026
-
Siemens partners with NVIDIA to advance AI-driven autonomous factories, Siemens press release, Oct. 19, 2026
-
NVIDIA Releases Early-Access Factory Operations Blueprint for Industrial AI Agents, Infraday, Oct. 24, 2026