Real2Sim2Real is a term from robotics and embodied AI. It describes a loop: capture the real world, rebuild it in simulation, train there, deploy back into the real world, then feed what reality teaches you back into the simulation.
I came across it in a Chinese tech article about a visit to Chongqing, where Qiteng Robotics and its listed parent, Shengtong Energy, use it to deploy inspection robots into LNG and chemical plants. Their answer to a hard robotics problem was not a better robot. It was a better loop between the robot and the place it works. To me, that is exactly the problem enterprise IT now has with AI agents.
The robot problem in one minute
The article opens with Moravec’s paradox: what humans find hard, like calculus, is easy for machines, while what we do without thinking, like walking on muddy ground, is very hard for robots. Industrial sites make it worse, because every plant is a one-off. Tanks sit in different places, one site is full of pipes and stairs, and the same gauge looks different across hardware versions.
A person adjusts in half a day. A traditional inspection robot starts from zero: engineers spend about a week on site remapping and teaching it, and close to six months when things go wrong. Experience from the last plant barely transfers, so “sell ten robots, send ten teams”. And in a plant full of hydrogen and chlorine, you can’t learn by failing.
How the loop works
- Real to Sim: capture, don’t draw. The platform, Yuanyu Zhixun (元域智巡), builds the twin from real scans using techniques such as 3D Gaussian Splatting. An AI model then finds the gauges and valves and plans the route, stops and camera angles before the robot even arrives.
- Fail where failure is free. In a module called Sim Studio, robots rehearse thousands of fire, fog and leak scenarios that nobody would ever stage in a real plant. According to the article, a few days of virtual training is worth months on site.
- Sim back to Real, and back again. Every surprise on site flows back. When glare stops a robot reading a gauge, it finds a better camera pose and saves it for every robot after it. When a reflective floor throws off its positioning, the twin is patched and the routes change.
That feedback arrow is the whole point. Older industrial twins stopped at delivery and quietly drifted out of date. This one keeps learning the particular plant it serves.
Every IT estate is a one-off too
Replace “LNG plant” with “enterprise IT estate” and almost every sentence above still holds.
Two organisations can run the same ServiceNow instance, the same AWS landing zone and the same SAP version. Underneath, their estates are completely different: different integrations, different tech debt, different naming conventions, and undocumented workarounds that one senior engineer knows about.
Anyone who has run a service transition knows the feeling. Every new customer is a new plant. You rediscover the environment through knowledge transfer workshops, spreadsheets and interviews, and little of what you learned at the last customer carries over.
The row that matters most is the hand-drawn model. Most of our “twins” in IT are drawn, not captured. The CMDB shows what someone entered. The architecture diagram shows what was designed. Staging looks like production until the day it doesn’t. Like the old hand-modelled factories, they look right and often aren’t usable for real decisions.
Applying the loop to five IT scenarios
The value isn’t in having a twin. It’s in running all three steps, every time.
- Change management
Today, a change advisory board approves a change based on a risk score, a template and the requester’s confidence. Real2Sim2Real changes the question from “does this look safe?” to “what happened when we ran it?” - Major incidents
Runbooks are usually tested for the first time during a real outage, at 3am. Instead, replay past incidents in the twin and combine them: a region down, plus an expired certificate, plus the on-call engineer unreachable. Like the fire and fog in Sim Studio, you can’t safely stage that in production, but you can run it every night in simulation. After each real incident, the post-incident review updates the twin, not just a PDF on SharePoint. - Service transition
This is the closest match to the robot problem. Instead of six weeks of knowledge transfer workshops rebuilding the picture from people’s memories, start by capturing the estate from telemetry, traces and configs. Then use workshops to fill the gaps the scan can’t see, the way the robot only adjusts on site where glare got in the way. - Cloud migration
Most migration plans are built on what the CMDB says. A captured twin is built on what the traffic shows. The gap between the two is where cutover weekends go wrong: the forgotten batch job, the hard-coded IP address, the integration nobody owned. Rehearse the cutover in the twin first, then let every migration wave feed corrections back for the next one. - Monitoring and observability
The glare-on-a-gauge example maps directly here. When an alert is noisy or a signal is missing, today the fix lives in one engineer’s head or in a ticket. In the loop, the fix is written back once (a new threshold, a better signal, a change in the dependency map) and every future check uses it.
Where this matters most: AI agents
One detail in the article deserves more attention. The robots are controlled through a “dual-brain agent” with a vision-language-action (VLA) model. An operator types something like “go to tank area 3 and check the valves and gauges”, as if sending a chat message. A platform brain breaks down the goal; a body brain looks at the path and carries it out.
That is an agentic AI architecture, and it maps neatly onto IT operations. But notice what the robot never does: it never improvises its first attempt in the hazardous plant. It rehearses in the twin first.
Many AI agent pilots in IT skip that step today. The agent reads the incident, decides, and acts on production. A Real2Sim2Real version looks more like this:
This pairs well with the calibrated confidence idea from my article on System One’s Innovation. The twin gives the agent evidence before it acts; the real result shows whether that evidence was right. Over time, you learn which actions are safe to automate and which still need a human, based on track record rather than gut feel.
It also gives governance something concrete. “The agent was tested” stops being a claim in a design document. It becomes a record: which scenarios it ran, what it predicted, what happened, and what the twin learned.
Twin-correct is not production-correct
A change that passes every simulation is twin-correct. That doesn’t make it production-correct.
The twin is only as good as its last feedback. If nothing has flowed back from production for three months, you are rehearsing against an estate that no longer exists. That is exactly the trap the old hand-modelled factory twins fell into. So the loop needs its own controls:
- Freshness: how long since each part of the twin was refreshed from real data?
- Drift: how often does reality disagree with the twin’s prediction, and is that number going down?
- Ownership: who owns the twin? If the answer is “the CMDB team”, it will go stale the same way the CMDB does.
- Automatic write-back: corrections must flow back as part of the work, like the robot saving its best pose. If feedback depends on someone writing a post-incident report, it won’t happen consistently.
“No surprises in simulation” is a test result. “No surprises in production” is the outcome. The loop is what closes the distance between them.
The bigger idea: from a gate to a loop
To me, the most important idea isn’t the robot or the 3D reconstruction. As the article itself points out, 3D capture, simulation, data feedback and large models are not new on their own. What’s new is joining them into one loop that keeps improving itself.
For years, IT has treated testing as a gate: build, test, deploy. Once something passed, the test environment had done its job. Real2Sim2Real proposes a different pattern: real, sim, real, sim, continuously. The model of the environment is never finished. It is a living system that production keeps correcting.
Once you think that way, the question changes. It is no longer “do we have a digital twin?” Most organisations have some version of one. The question is “how fast does production correct it?” For enterprise automation, and especially for governed agentic AI, that is the question worth asking.