The physical AI harness
C3D Studio is the agentic harness for real-world automation. It puts inspection cells, handling cells and lab equipment behind typed calls that AI agents can use, and every actuation passes a risk class, a simulation rehearsal, an approval gate and a journal.
typed functions in one toolset
1D, 2D and 3D algorithm functions
device drivers across vendors
MCP tools, each with a risk class
Chapter 1 · The problem
Models now write code, plans and analysis in seconds. On a production cell or a lab bench, that is where the trouble starts. Five gaps sit between a capable model and equipment you could leave it with.
Nothing stands between a model's command and the axis. A plausible move goes straight to the motor, and the only safeguard is a person reading code they did not write.
What is true in the cell, which side is up, what the gripper can carry, which fixture is still full, lives in people's heads. A plan can pass every check, run cleanly and measure the wrong thing.
Drivers, screens, sequence and inspection are integrated per vendor and per project. Algorithms are tuned once on a few parts, drift in the field, and the person who tuned them has moved on.
Each device needs its own top-end workstation, and when one fails that device stops. Results carry no version, no criteria and no approver, so a defect cannot be traced and a run cannot be repeated.
Lab results and field findings stay in files and in people's heads. The next campaign repeats settled questions, and the next team learns the cell again.
A bigger model closes none of these gaps. They are missing parts between the model and the machine, and those parts are what C3D Studio is.
So, why we exist
Models are becoming commodities. What stays scarce is a safe contract that reaches real equipment, the meaning of the cell it acts in, and the record of everything it did. That is what we build.
Where the gap is
Device control and HMI are where the revenue already is. Orchestration and provenance are where nobody is yet. Studio holds all three in one process, and plugs into the rest.
Studio doesn't pick the brain.
It gives the brain eyes, hands and a record.
Chapter 2 · The answer
Answers1 · A wrong call moves real equipment2 · A plausible plan can still be wrong
In this chapter: the two ideas → the harness → the ontology → one real machine, through both
Two ideas
Everything further down builds on these two. The harness decides whether a call may run. The ontology knows what that call means in your cell.
Every device and function sits behind a typed call. Each call has a risk class, is rehearsed in simulation, is approved by a person when it has to be, and is written to a journal.
Answers: may this call run?
An agent can drive real machines without being trusted blindly.
The things in the cell, what each can do, what every action needs and changes, and the rules people carry in their heads, written down as typed data the harness can check.
Answers: does this action make sense, right now?
A wrong action is refused in milliseconds, before a rehearsal, a person or the machine.
Why both The plan asks for a scan of side B. The part is lying side A up.
R-SIDE-UP · side A is up. Nothing ran and nobody was asked. The agent re-plans with a flip.01 · The harness in detail
Stages, robots, cameras, 3D scanners, DIO and PLC links sit behind typed calls. Agents reach them over MCP and use the same calls a person would.
Each of the five risk classes decides which gates a call has to pass before anything moves. Motion limits are validated before a change is committed.
Motion runs in the simulator first. Only a passing rehearsal earns a ticket, and the gate re-derives that ticket instead of taking it on trust.
Decisions that need a person go to the approval window. The handshake fails closed, an agent cannot approve itself, and nothing else stalls while the operator decides.
Every actuation lands in the change journal and the experiment ledger. Any run can be reproduced, halted, or handed over as it stands.
02 · The ontology in detail
A risk class knows how dangerous a call is, not what is true in the cell. A fixture still holding the last part, a forgotten flip, a part heavier than the gripper is rated for: the rehearsal passes, and the mistake shows up on the machine, or never.
Things are typed classes with fields and units: a gripper with its payload, a part with its mass and the side facing up. Actions declare what they need, what they move and what they change, and are frozen by hash once a record exists, so old records keep their meaning.
Before the gate asks anyone, the plan is walked on a copy of the world. The first step that breaks a rule is refused with the rule and the fact. The plan is never quietly repaired; the agent re-plans. A 32-step plan is checked in under 3 ms.
The operator approves steps written as sentences, not joint targets. Each executed step becomes a ledger record and updates the world, so the next plan starts from what is really on the bench.
A hypothesis probed on the real machine and accepted by a person becomes a fact that blocks or relaxes later plans. Domain knowledge stops living in one person’s head: in a pilot, the rules picked the right measuring head 98% of the time against 38% without them.
In practice · XZT scanner
XZT is a tabletop side-head X/Z/T gantry: a 2 kg 3D profile sensor on a tilt head, over a Y stage and a rotary seat. Drives, controller and PC sit in a two-tier rack beside it. One Studio app drives the real machine and its simulated twin through the same calls.
The head moves in X and Z and tilts to face the part's side walls. Every axis carries a motion limit the gate checks before a move is committed.
A Y stage and a rotary seat carry the part through the sensor's line and turn it, so one pass sweeps a face and the next face comes round.
The scan path runs in the twin first: reach, clearance to the frame, cycle time. A passing rehearsal issues the ticket the real move needs.
The operator approves, the real gantry scans, and the point cloud, the measured features and the approval land in the journal together.
Industrial PC · rack
3D sensor · X / Z / T
Y stage · rotary seat
E-stop · keypad
Drives & controller
Chapter 3 · Build
Answers3 · Every cell is built, tuned and fixed by hand
In this chapter: how development runs → a session, end to end → ready-made cells → a 3D algorithm, from goal to the field
How development runs
What the cell proved is where the next iteration starts.
A session, end to end
Point any MCP-capable coding agent at Studio. It gets the functions, devices and tools as typed calls, under a role. Everything it does and asks for shows up in Studio's Agent Workspace, and while it develops, every call goes to the simulated cell.
Write the goal the way you would brief an engineer. The agent turns it into targets it can test, and reads the cell's facts from the ontology: what the gripper can carry, which side is up, which bays exist.
The agent builds the cell in the twin and plans the motion. The ontology refuses a step that makes no sense, the rehearsal catches a collision, and the agent re-plans either way. No hardware has moved.
For the inspection it chains functions that already exist and runs them on recorded scans. Only the one missing block becomes new code, staged in a change set.
The pass criteria are fixed before the first run. The agent tunes the path and the parameters against them, cycle time, repeatability and sorting, over hundreds of simulated cycles. Every run is journalled.
The approval request lands in the Agent Workspace with its evidence attached, and a person holds to approve. The same sequence switches from the twin to the equipment and runs its first parts under supervision. Each result records the version that produced it.
harness role developer · target sim
ontology cell tray-sort · 14 things · 9 rules
Goal → testable targets
Facts from the ontology
twin
✕ preflight · re-planned
✓ rehearsal
Sequence
Against the criteria · 200 cycles
Same sequence, same calls, one target switched. Version v1.3 is stamped on every result in the ledger.
Ready-made cells
You rarely start from a blank page. Each example is a complete app, a state chart, a form and scripts, running in the built-in robot simulator, which handles rigid parts, cloth and liquid. The agent installs one and adapts it to your spec; the same calls then drive the real cell.
An eye-in-hand depth camera tracks each block down to the grasp and sorts it by size.
A 6-axis arm stacks cartons a 3D camera measured on the belt; unstable ones wait in a buffer.
One arm holds the shoe, a 3D scanner measures the sole, a second arm lays the adhesive.
Pipette, develop, read, then plate the strongest positives and count colonies.
96-well dosing, incubation, IC50 fit and a Z′ verdict, end to end.
Stations are read from the scene, so a campaign can search for a faster layout.
A 400 × 300 mm cloth taken by one corner hangs, drags and crumples like the real thing.
174 ml tipped over a beaker lip into a 90 mm cup: 99.7 % landed in it.
Hover a card for the simulator render. Examples use simulator models of commercial robots and sensors; names belong to their owners.
Development automation · harness ontology · a real case
Goal: hole centres you can trust when the rim is damaged.
The harness runs, stages and gates every step; the ontology links goal, code, tests and release. Together they turn a goal into a deployed algorithm without skipping a proof, and keep it right in the field.
The ontology turns the goal into a typed requirement, in µm and the part frame, and its preflight refuses a scan without units or a frame. The harness then runs crop → plane → robust circle fit live on recorded scans. On a damaged rim, a sector of stray points pulls the centre off.
GainNo run is wasted on inputs that were wrong from the start.
Through the harness, the agent reruns the failing scans in the engine and reads the residuals. The robust loss turns stray points down but never drops them. The ontology records that cause as a hypothesis, linked to the runs that show it, before any code changes.
GainThe fix aims at a cause, and the reason stays on record for the next engineer.
Guided sampling with early rejection, and a final refit on inliers only: native C++ in the algorithm plugin. The harness holds it in a change set, so nothing running changes. The ontology refuses a change set that names no requirement.
GainEvery line of new code traces back to the goal it serves.
The harness pins the criteria by hash before the first run and tests old against new on the same data: centre error 68 → 6 µm, radius error 50 → 5 µm, within 2 µm of the production pipeline on a real hole. The ontology links each result to the requirement it supports.
GainThe improvement is measured, not argued, and no one can move the goalposts afterwards.
The ontology marks evidence from the old revision stale, so the harness reruns the regression cases: the rebuilt failure goes from 34 to 8 µm, while line fits and short arcs come out unchanged. Its overfit guard caught a draft that only looked better, a 0.5 µm residual.
GainAn old pass never vouches for new code, and a too-good result is caught before release.
The ontology calls it done only when every required case has passed on this revision. The harness then sends the evidence to a person in the Agent Workspace, hot-reloads the plugin, confirms the runtime loaded it and ships it to every processing node.
GainWhat runs on the line is exactly what was proven, with its version on every result.
After release, a field engineer asks Studio why one cell's centres drift. The harness replays that cell's scans on the version stamped on each result; the ontology shows the evidence behind them and that the cell's calibration changed since. The fix, a calibration revision, passes the same tests and approval as v2.1; v2 stays one step away.
GainField engineers diagnose from the record, not from memory, and every field fix is versioned like the first release.
SpecThe goal becomes a typed requirement: centre and radius error in µm, in the part frame. Before the chain runs, the scan IDs must exist and carry units and a frame, or the call is refused.
HypothesisThe cause is recorded as a hypothesis, linked to the failing runs that support it, before any code changes. A tweak with no hypothesis behind it has nothing to link to.
RevisionThe change set has to name the requirement it implements. One that names none is refused, so no code arrives without a reason on record.
CriteriaThe test case is pinned by hash before the first run. Each run's evidence is linked to the requirement it supports. Moving the goalposts after the fact breaks the hash.
RegressionEvidence measured on the old revision is marked stale by the change. A pass counts only after the regression cases rerun on the new one.
ReleaseDone means every required case passed on this exact revision and the runtime proved it loaded that build. Only then is the approval request sent.
FieldThe links stay live after release. A field engineer's question is answered from them: which version made a result, what evidence it rests on, what changed since. A field fix is a new revision with its own tests, never an untracked edit.
Numbers from internal tests, August 2026, on a small outlier set and one production hole. Geometry exaggerated for clarity. The ontology trace and the field step are illustrated on this case.
Chapter 4 · Run
Answers4 · The line rests on single machines and leaves no record
In this chapter: cluster mode → human oversight → what we never confuse
Cluster mode · reliability and running cost
Each device needs its own high-end workstation for reconstruction, matching and inspection. The line is only as reliable as that one box: when it fails, that device stops, and a spare is expensive and sits idle.
Cluster mode sends the heavy steps to a pool of ordinary PCs on the network. Every device can hand work to every PC: N devices share M PCs, and each side grows on its own. Devices, screens and the gate stay where they are; the PCs only compute. Scripts do not change.
The tasks it held are re-queued to the other PCs. The pool loses a quarter of its capacity, not a device: every cell keeps running, a little slower, and no result is lost.
Plug in a replacement PC. It fetches the current scripts, announces itself and starts taking tasks. No restart and no stop; the per-PC monitor shows it join.
No single machine can stop the line, and maintenance happens while it runs. Commodity PCs replace top-end workstations, there are no idle spares, and capacity is bought one ordinary PC at a time.
Measured figures: internal cluster tests, July 2026. Larger payloads add transfer time. The failure and swap are illustrated.
Oversight
EU AI Act and ISO 10218:2025 ask for human oversight. Studio records it as it runs.
Studio is not a safety PLC. It runs alongside your safety-rated control.
Move the scanner head to X 105 mm, Z 150 mm
→ journaled with who, when and why
Principles behind the record
Chapter 5 · Learn
Answers5 · What one run learns, the next one forgets
In this chapter: lab in the loop → campaigns → two loops, one record
Lab in the loop
Four parts make the loop one you can trust: the harness runs and gates it, the ontology holds what is true in the lab, the simulation rehearses every move, and the algorithms turn raw signals into measurements.
State the goal and the agent proposes the next experiment. The ontology supplies what is already known, facts accepted from earlier runs, so they are not tested again; the algorithms catalogue says what can actually be measured.
HelpsNo experiment repeats a settled question or asks for a quantity nobody can measure.
Unlikean ELN or LIMS, which stores the plan but cannot tell whether it is worth running.
The harness hashes the pass criteria before anything runs; change a tolerance and it becomes a new revision. The ontology walks the plan on a copy of the lab and refuses the first step that breaks a rule: the wrong side up, an occupied fixture, a missing unit.
HelpsA bad plan is refused in milliseconds, before a person or a sample is spent on it.
Unlikea scheduler that runs whatever script it is handed.
Every step that moves equipment runs in simulation first, through the same calls the real cell uses. Only a passing rehearsal earns a ticket, and the harness re-derives that ticket at the gate instead of taking it on trust.
HelpsCollisions, reach and timing problems surface without risking equipment or samples.
Unlikean offline simulator with its own model and code, which proves a copy, not the run.
The harness runs the plan under its risk class, with a person approving what needs one and a halt always within reach. Typed 1D, 2D and 3D algorithms measure in the engine as data arrives, tied to the digests of the source, the input and the artifact.
HelpsMeasurements exist the moment the run ends, and each one says exactly what it was taken on.
Unlikeexporting raw files to a separate analysis script days later.
Results land in the experiment ledger and the harness judges them against the fixed criteria. A finding a person accepts becomes an ontology fact that blocks or relaxes later plans; a weak measurement becomes an improvement case for the algorithms.
HelpsEach loop makes the next one faster and safer, and the lab keeps what it learned.
Unlikeresults kept in files and in people's heads, learned again by the next team.
Closed loop, first class
Goal, parameter space, budget, stop rule. A script, a model or an agent picks the next run.
{
"goal": "hole position error under 20 µm",
"parameterSpace": {
"exposure_ms": [2, 12],
"gain_db": [0, 6]
},
"budget": { "runs": 40, "hours": 6 },
"stop": "3 consecutive passes",
"decide": "agent",
"criteria": "sha256:4be1…c09a"
}Two loops, one record
Every run is typed by the ontology, checked before it moves, and written to the same ledger. Accepted evidence becomes a fact the next plan has to respect.
The guidance agents work from is improved the same way: small models run hidden tasks in a test Studio, a stronger model proposes edits, and an edit is adopted only if it wins on tasks it never saw.
Internal pilots, October and September 2026. Small samples; we publish them as they are.
Chapter 6 · Fit
Fitsany deviceany modelany site
In this chapter: extensible by design → capabilities → use cases
Platform · Extensible by design
The runtime holds the HAL, the script engine, state charts, the gate and the journal. Everything else is a plugin, and every plugin is reached the same way: a typed call with a risk class and a journal entry.
Robots, stages, cameras, 3D scanners, DIO and PLC links load as device drivers behind the HAL's interfaces. Each has a simulated twin, so a cell runs before its hardware arrives.
90+ widgets, from charts and 3D viewers to the robot simulator and lab instruments, drop into forms in the visual designer. The agent wires them to the state chart.
33 modules of 1D, 2D and 3D algorithms: registration, matching, measurement, mesh, segmentation and local perception models. Each function is typed and searchable, so agents compose them.
Build your own device, widget or algorithm against the plugin SDK. User modules live in their own namespace, never collide with official ones, and hot-reload without restarting Studio. Mix any of them in one app.
Capabilities
Stages, robots, cameras, scanners, DIO and PLCs behind one typed surface, each with a simulated twin.
Chain 1,200+ proven functions instead of writing new code. 11× repeatability, by composition alone.
The agent drafts chart, form and script from your spec. A person approves.
40+ robot models, IK, collisions and cycle time. A pass issues the ticket.
Scale out on commodity PCs: 36 of 36 tasks, ~10 ms overhead, lossless failover.
Any model, per role. On-premises, with a data-residency switch.
Local models for segmentation, pose, grasping and anomalies.
Journal, ledger, reproduce tool and a handover package.
Use cases
3D verdicts on mixed-vendor cells, next to your PLC.
Closed-loop campaigns with criteria fixed up front.
One gate in front of every instrument, audited by default.
Experiments that arrive with their record attached.
Chapter 7 · Why C3D Studio
1A wrong call moves real equipment.
Every actuation carries a risk class, a rehearsal in the twin that issues its ticket, a person's approval where one is needed, and a journal entry. An agent cannot approve its own request.
risk class · rehearsal · approval · journal, on every actuation
2A plausible plan can still be wrong.
The ontology walks the plan on a copy of the world and refuses the first step that breaks a rule, before a rehearsal, a person or the machine is spent on it.
< 3 ms for a 32-step plan · right measuring head 98% vs 38%
3Every cell is built, tuned and fixed by hand.
The agent composes proven functions and drivers, proves each step in the twin, and stages only the code that is truly new. In the field, an engineer asks Studio, and the fix ships as a revision with the last one a step away.
2,900+ functions · 50+ drivers with twins · 11× repeatability by composition
4The line rests on single machines and leaves no record.
Any device hands heavy work to any ordinary PC, and a failed one is swapped while the line runs. Every result names its version, its criteria and who approved it.
36 / 36 tasks · ≈9 ms added per task · no result lost on failover
5What one run learns, the next one forgets.
A finding a person accepts becomes an ontology fact later plans must respect. The guidance agents work from improves only when it wins on tasks it never saw.
8 / 9 held-out tasks vs 7 / 9 · −59% Studio calls per task
Parts of this exist elsewhere: a scheduler here, a simulator there, an ELN beside them. Only Studio puts the harness, the ontology, the twin, the algorithms and the record in one process, from the first sentence to the field.
Against a design-time copilot
FAQ
No. You pick the model; we build the contract that lets it move real equipment safely. Perception and judgement run on our own local models.
No. Studio talks to your PLC over S7, OPC UA or Modbus and owns only the agent interface and the record.
Nowhere. Studio runs on-premises, and a data-residency switch refuses any model call that would leave the site.
Talk to sales
Tell us about the equipment, the scale and the timeline, and we'll get back to you.