Boltz learns an AI map from achievable outcomes to the designs that deliver them — trained on your engineering evaluators, not a historical corpus. Specify the performance you need; get back a library of diverse, feasible, physics-verified designs.
Traditional engineering makes the problem manageable by freezing an architecture first — then explores and validates designs only within that narrowed space, one at a time.
Each candidate must be configured, tested and validated. When a design fails, the architecture reopens and the work resets. And the full architecture–component space is far too large to explore directly — so the early commitment is a bet made with the least information the project will ever have.
Forward design worked when platforms were stable and requirements moved slowly. Several forces are now compressing more coupled decisions into less time:
Systems integrate more components, more sensing, more software — more decisions that move together.
Additive manufacturing and new materials open design possibilities the old process never had to search.
High-mix demand means every new brief is a new integrated design — on a faster clock.
Inverse design is a learned map from the requirement space — goals, constraints, operating envelope — back to the designs that achieve them.
Engineering practice already knows how to evaluate a design — physics and first-principles rules, reduced-order models, detailed simulation, physical test, expert reasoning. What it rarely has is a direct rule for constructing the right design. And predictive ML alone doesn't fix this: engineering data is sparse, partial and biased — novel designs have no historical examples, failed concepts are rarely retained, and useful data is proprietary or siloed.
When no representative corpus exists, the evaluators themselves become the training signal.
Boltz learns the inverse map from your existing evaluators — physics, rules, constraints, specs, simulations, partial models, expert and lab data, private tools behind APIs. No historical design corpus required.
The generator proposes designs; evaluators score feasibility, performance and coverage of the feature space; the model retrains on that feedback — probing the design space where the map is still uncertain.
Training is a closed loop. The generator proposes candidate designs; the evaluators score them for feasibility, performance and how well the population covers the feature space; the model retrains on that feedback and proposes again. Each pass teaches the generator two things at once: the structure of valid constructions — so it stops producing incompatible or impossible combinations — and where the achievable envelope actually lies, including regions no historical dataset would ever contain. Because the loop probes the design space where the map is still uncertain, exploration is directed, not exhaustive — which is what makes a combinatorial space searchable at all.
The evaluators are yours, not ours. Boltz trains against each customer's trusted evaluation layer — their physics models, design rules, constraints, simulations, catalogs, lab data and private tools — accessed through APIs and connectors. Nothing is replaced or second-guessed: the tools your engineers already trust to judge a design are exactly what teaches the engine. That has two consequences: every generated design has already been scored by your standards before you ever see it, and the trained map inherits the credibility of the evaluation stack behind it.
The result of training is not one optimized design. It is a reusable, target-conditioned generative model of the achievable design space — its feasible envelope, its trade-off frontier, its corners.
Define ranges across performance, cost, resilience, buildability — a region, not a point.
The trained model samples the feasible envelope and trade-off frontier inside your target region.
A set of complete architectures spanning the trade-offs — not a single answer to defend.
Map once, query many. Train per application family, then condition and reuse across briefs, customers, programs and operating envelopes — amortizing design search instead of restarting it.
Starts from computable domain knowledge — not thousands of prior designs.
Rules, physics, simulations, documents, experts, private black boxes, test data.
Learns the structure of valid constructions instead of generating the impossible.
Scores the whole set for coverage, Pareto reach, extrema and diversity — not just each candidate.
Train once; condition and reuse across targets, constraints and programs.
The robotic workcell — not the robot alone — is the deployed product: robots, grippers, fixtures, feeders, vision, safety, layout, task allocation and controls, all coupled. Boltz's beachhead application is inverse design of complete workcells.
The setup: a CNC machine-tending application family. 45 discrete variables spanning architecture, equipment, layout, tooling and flow. Evaluators run on exact geometry: reach at every pose, collision through the modeled machine-door opening, joint and singularity margins, motion timing, catalog costing.
Once trained, the same map returns the best-fit feasible architecture for each objective — without retraining:
| Query | Returned cell | Cost | Cycle | Parts/hr | Floor | Run time |
|---|---|---|---|---|---|---|
| Cheapest cell that does the job | KUKA KR 16 · 1 robot, 1 machine | $105K | 107 s | 34 | 50 m² | 5.9 h |
| Fastest cell, any budget | KUKA KR 16 · 3 robots, 4 machines | $398K | 27 s | 135 | 84 m² | 1.5 h |
| Smallest floor area | UR10e · 1 robot, 2 machines | $171K | 58 s | 62 | 19 m² | 6.5 h |
| Longest unattended running | ABB IRB 4600 · 1 robot, 1 machine | $138K | 107 s | 34 | 73 m² | 11.9 h |
| Fastest cell under $200K | ABB IRB 2600 · 1 robot, 4 machines | $187K | 30 s | 121 | 38 m² | 0.2 h |
| Cheapest at 100+ parts/hour | ABB IRB 2600 · 1 robot, 4 machines | $154K | 33 s | 109 | 38 m² | 3.7 h |
Modeled outputs from physics evaluators on exact geometry — not vendor quotes. Each query returns the best qualifying workcell for that objective from the same trained design map.
One modeled result worth pausing on: a $165K cell beat a $502K cell on cycle time, clearance, reach margin, run time and floor area — both serving three machines. The cheaper cell used one 22 kg-payload robot with a two-sided gripper; the expensive one combined three robots, a 45 kg-payload robot and 3D vision. That is what searching the full coupled space finds, and what committing to an architecture up front does not.
The engine is domain-agnostic — the same generate–evaluate–learn pattern has been applied to spatially varying thermal-hardware geometry, and applies wherever coupled discrete decisions meet computable evaluators: lines and fleets, lab and medical workflows, mission-specific robotic systems, materials and packaging architectures.
Lab and medical robotics is breaking out — medical robot sales rose 91% in 2024, and diagnostic and laboratory-analysis robots grew 610%. Every new protocol is a new integrated design: delicate objects, human proximity and reliability reshape the complete system, not just one instrument.
Same engine, different evaluators: protocol steps, delicate-object handling limits, biosafety and human-proximity rules, instrument specs and uptime targets become the evaluation stack — and the trained map returns complete lab configurations that satisfy them.
Encode an assay or sample-prep protocol as requirements; generate the complete workflow that executes it — steps, allocation to instruments and robots, sequence and scheduling.
Benches, instruments, robot placement and reach, sample routing and human corridors — designed together, sized to the room you actually have.
Arms, grippers, liquid handlers and movers matched to delicate objects, human proximity and the throughput the protocol demands.
Walk-away time, error recovery and redundancy scored across the whole population of designs — so you choose the trade-off, not defend a single guess.
Boltz trains against your trusted evaluation layer — your rules, models, simulations and private tools — and serves the inverse map as a managed service. If your team solves the same class of coupled design problem over and over, that is exactly what the engine amortizes.
Start the conversation