A welding robot can lay down an extremely repeatable bead while the rest of the workshop still runs in the old way around it. Somebody has to prepare material, decide the order of operations, move heavy parts, rebuild the schedule when a delivery slips and work out what to do when the geometry on the floor differs from the clean version in CAD.
1872 is trying to automate more of that less photogenic work.
The startup opened a factory in Cincinnati's Camp Washington neighbourhood in 2026 after announcing a $15 million seed round.2 Early automation is already in place, according to the launch material, while the company's fuller autonomous-factory vision is targeted for 2027.2
That date matters because it separates the factory that exists from the autonomy that still has to be built.
Low volume breaks the neat production line
An automotive line can justify months of preparation because the same cell may repeat one operation thousands of times. The large frames, skids, enclosures and modular infrastructure targeted by 1872 live in a different economy, with geometry changing from one customer job to the next while quality requirements remain serious.1
This is awkward territory for automation that needs weeks of bespoke programming before every production run. If the integration cost returns with every new product, the robot may be extremely fast during welding and still lose the economic argument before the arc turns on.
The interesting target for 1872 therefore sits between two different orders. Reducing that changeover work is less dramatic than a robot moving at full speed, but it is likely to matter more if automation is supposed to work at low volume.
Software has to turn CAD into a day on the shop floor
1872 describes its pipeline with three verbs: model, orchestrate and execute.1 The first stage ingests CAD files and constraints, while the last sends work towards the machines; the difficult part is the middle, where a product definition has to become a sequence of factory decisions.
Material has to be available or purchased, operations need an order, machines need time slots and large components have to move through the building without blocking everything else. The launch release describes a Factory OS intended to coordinate sourcing, estimates, stock, production planning, machinery, robotics and material movement in the same system.2
To be sure, software here is not replacing one neat job title. It is trying to absorb pieces of coordination that normally live across several people, systems and conversations, which means the quality of the feedback from the floor matters as much as the original plan.
That is where the factory will actually be tested.
The robots are not the newest part of the idea
1872 is using welding systems from Path Robotics.2 Robotic welding itself is hardly new; the company's bet is that planning software, shop-floor operations and fabrication cells can be connected tightly enough to accept a stream of high-mix work without turning every order into another integration project.
On a diagram, that loop looks clean. In a workshop, plates arrive late, parts distort, inspection fails, a joint is difficult to reach and one slow operation can move the rest of the day's schedule.
A software-defined factory becomes useful when those deviations return to the planning system instead of being corrected in a parallel world of conversations and whiteboards. In that sense, “closed loop” is not mainly about sending commands to robots; it is about receiving enough information from the physical process for the next command to improve.1
The 99% figure still belongs to 1872
The company's site publishes three aggressive numbers: 99% first-pass yield, 70% arc-on time and an 85% reduction in welding cost.1
Those are company-reported figures. The public page does not provide enough detail to reconstruct the jobs, time period, product mix or comparison baseline behind them, so treating them as an independent manufacturing benchmark would be unjustified.
The same caution applies to autonomy. The Cincinnati facility exists, robots have been installed and early automation is described as operational, whereas the fuller autonomous vision remains the company's target for 2027.2
That distinction leaves room for a more useful reading than either “the autonomous factory has arrived” or “this is only a robot demo”. There is a real factory and a real software effort, with a substantial amount of integration still ahead of them.
Tacit knowledge is the harder material to digitise
A workshop runs on more than the geometry in its CAD files. Someone knows that one fixture distorts in a particular way, a certain material needs to be ordered early, one sequence creates rework or an inspection is worth doing before three more hours of welding are committed.
1872 talks about replacing manual coordination and “tribal knowledge” with software-defined manufacturing.1 The phrase is ambitious, but it leads to a practical question: which parts of that knowledge can the system actually capture?
If a good decision can be formalised, it can be replayed, measured and improved; if operators know something that the model never sees, the result may simply be a very clean schedule that fails faster.
We should therefore expect human expertise to move rather than vanish. Some of it has to become data, rules, production feedback or exceptions that the system can recognise in time to change the plan.
The real test begins with the second order
The robot already knows how to weld. The revealing moment for 1872 comes when the next assembly looks very different from the previous one.
Can the software absorb another geometry, rebuild the production plan, account for material and hand coherent work to the shop floor without starting another integration project from scratch?
That question sits at the economics of low-volume automation. If 1872 succeeds, the important gain will not be a newly invented welding motion; it will be a reduction in the invisible work required to move from one product to another.
And if it fails, the failure will be informative too. Industrial automation has long been good at repeating a stable task. The stubborn problem is everything that changes around it.