Raising Machines in the Deep

A support vessel idling in bad weather costs exactly as much as one hauling a robot up and down all day. Deep-sea operations are priced around this fact, in a unit built for it: the "full vessel day." Once a mothership is out at sea, the meter runs whether the robot is working, waiting out weather, or sitting broken — the ship, the crew, and the entire support system burn money continuously, and quite literally.

According to Offshore Engineer, citing market data from Fearnley Offshore Supply, deepwater vessels fitted with large active heave-compensated cranes were renting for $60,000 to $80,000 a day in the first half of 2025. A single operation running several weeks can rack up rental costs alone into seven figures.

Pricing a robot is a manufacturing question. Counting how many vessel-days a task requires is a question of opportunity cost — one that folds in the ship, the crew, mobilization and demobilization, weather delays, engineering support, specialized tooling, every redeployment. The robot itself is expensive, but getting it to the site and keeping it there until the job is actually done costs far more than the hardware ever will.

An ordinary product, once designed, moves to production, delivery, use. An autonomous system that is still growing up needs something else entirely: a repeating loop of modify, test, fail, analyze, modify again. On land, that loop moves fast — a software change gets tested the same day, a control parameter gets re-verified within hours. At sea, every link in that chain drags in a ship, a crew, a weather window, a schedule. Budgets are finite, so the expensive thing gets done less often — and the cost compounds as it goes: development stretches out, failures surface later than they should, and the feedback loop after every fix slows to a crawl.

Anyone who has raised a child knows money and resources are rarely the limiting factor. What matters more than a financial safety net is something closer to standing encouragement — permission to try boldly, to experiment, to know that failing doesn't mean it's over. Raising something built of silicon isn't so different. For an autonomous system still learning, still needing to mature quickly into something reliable, hardware and compute matter — but what's scarcer, and more valuable, is the chance to go back into the real world and try again after a failure.

Underwater is about the worst place to offer that chance. Communication bandwidth is limited, and optical conditions are easily disrupted by turbidity, distance, and light. GPS doesn't work underwater at all, so precise positioning has to rely on other methods — methods that are themselves vulnerable to acoustic propagation, visibility, and ambient conditions. That's already a serious constraint for tasks built around observation. For an intervention task — a robotic arm approaching, aligning, applying force, turning a valve — every one of those constraints gets amplified.

Which raises a puzzle. If trial and error underwater is this expensive, how did observation-based autonomy manage to advance as far as it has, seemingly around this very bottleneck? The answer may come down to how much amplification a task can absorb — and that depends on how much the task depends on real, in-the-moment experience. That's the second variable.

Point an AUV down a pre-set survey line and it can gather data across a wide area with barely any human supervision. That's what "looking" means in deep-sea work. Ask it to reach out, align an end-effector against a target, apply the right amount of force, and keep adjusting once contact has been made, and the job changes entirely. It's no longer enough to know what's in front of the robot; it has to know what happens if it turns this, and what happens if turning it goes wrong.

The gap between looking and touching is partly a matter of control complexity. But underneath that, it comes down to how much each task depends on real-world experience gathered in the moment.

An inspection run can be brought home intact. The footage is saved, reviewed later, fed into training data, revisited as many times as needed. An intervention task doesn't get that luxury. Force feedback and trajectory logs can still be analyzed onshore after the fact, but the decision that actually mattered — how much to adjust, how to avoid damaging the target — had to be made in the instant of contact itself, not afterward.

That instant is crowded: seabed sediment, current, positioning drift, a target that may be moving, the friction and resistance that only appear once contact is made. All of it pulls the outcome away from what was planned. Real environments are very good at exposing the gap between expectation and reality — and for tasks involving physical contact, part of that gap hides entirely inside conditions that can't be reproduced anywhere else. This is why intervention depends, in a way observation never has to, on a cycle of trying again that runs as continuously as breathing.

"Smarter machines should perform better. If they aren't performing better, they must not be smart enough yet." It's a reasonable-sounding chain of logic. Set aside, for a moment, the usual outside factors — organizational maturity, supply chains, regulation, insurance costs — and look only at the engineering and the conditions under which it gets tested. Even then, the logic admits at least two different explanations.

The first puts the pressure squarely on the machine: it simply isn't good enough yet. Perhaps its perception, planning, control, or the hardware doing the actual work still can't reliably carry out this kind of intervention. If that's the real problem, the fix is more of the same — better perception, better planning, better control, better hardware. Call this the intelligence bottleneck. By "intelligence" here, we don't mean any single AI model, but the entire system of capabilities that autonomous intervention actually requires.

The cost breakdown in the previous section points toward a second explanation. Maybe the machine hasn't failed because it's incapable — maybe it has simply never had enough chances to discover what it doesn't know. The states, geometries, and contact conditions a deep-sea intervention might encounter combine into more possibilities than any development program can cover, many of them rare and strange. And as the earlier analysis showed, the expense of trial and error at sea becomes the expense of iteration itself: failures surface later than they should, the same conditions are hard to recreate on demand, and it's harder to confirm whether a fix actually worked. Call this the validation bottleneck.

The two explanations aren't mutually exclusive, but they pull engineering effort in different directions. If more perception, control, or hardware capability keeps producing steady gains in the field, that's evidence for the first. If the same conditions can be reproduced and tested more often, and failure rates and the need for human intervention fall as a result, the weight shifts to the second.

Go back through a batch of real underwater intervention records, and the first question worth asking isn't whether validation was insufficient. It's simpler than that: what actually happened, step by step, in the moment things went wrong. Did the robot misread its target? Did localization or state estimation drift off course? Was the motion plan itself flawed, or did control lose stability the instant contact was made? Was the end-effector simply not strong enough for the job? Some failures, meanwhile, only ever show up under a substrate, a geometry, a posture, or a contact condition that had rarely — if ever — been tested before.

Separating these causes as cleanly as possible is the necessary first step. "The machine got it wrong" isn't an explanation; it's just a restatement of the problem.

The evidence that actually distinguishes an intelligence bottleneck from a validation bottleneck only shows up once the original conditions can be recreated: the same difficult situation, tested and modified and tested again, and watched to see whether the same category of failure declines. The distinction here is subtle but it matters. "It failed because this had never been tested before" is a guess. "Coverage was thin, targeted testing was added, and the same failures kept dropping" is evidence. Run the reverse case — a condition tested repeatedly with no decline in failure — and "insufficient validation" stops being a credible explanation; the weight shifts back to the machine itself.

Reality rarely offers this cleanly. Machine capability keeps improving at the same time validation conditions do, and a single failure usually tangles perception, control, and environmental uncertainty together — a pure experimental condition is hard to find, and engineering budgets can't wait around for attribution to resolve itself. Rather than chasing a clean answer to "which bottleneck is it," the more useful question is which variable, changed, most reliably changes what happens in the field.

Answering that question has one hard precondition: the failure has to survive. What did the robot see at the time? How did it judge its own position and state? What action did it take, what happened after contact, and can the deviation be reproduced under similar conditions again? A log can preserve the outcome without preserving the conditions that produced it — and a failure that can only be described, never reliably reproduced, is no better than a guess when it comes to explaining it. Before anyone can find out whether validation is really the bottleneck, the conditions for validation have to get better first — good enough that failing and trying again stops being rare.

The actual job keeps changing. Today it's inspecting a cable, tomorrow approaching a structure, the day after maybe grasping, docking, or turning a valve. But the seabed, the current, the turbidity, the structures and the contact conditions don't disappear just because one task ends — they're still there for the next one. Moving part of the validation process onshore is one way to make use of that fact. Call it environment reconstruction.

Where a log preserves outcomes and pass/fail results, environment reconstruction preserves something closer to the full set of conditions present at the moment a task happened — an instant sliced out of the whole world, everything in it intact.

Take an example: on a clear day, a robot fails a docking attempt on the seafloor. A slight incline near the interface, a soft patch of sediment, and the specific angle of approach combine to shift the robot's body out of position, just enough that the end-effector never quite aligns. The log makes it home. The moment doesn't. Even a fast fix to the control strategy can't be confirmed as working — not until the same geometry and the same contact conditions exist again, and by then they're long gone. But if that incline, that sediment, that approach angle could all be recreated, the robot could return to the same hard moment as many times as it needed to — varying the incline, the substrate, the posture, the approach path one at a time — and watch exactly where the error shows up, and where it stops.

Reconstructed this way, a failure becomes something that can be taken apart and put back together — a cross-section of space and time, reusable on demand. The old chain — design, build, go to sea, try, fail, revise, go to sea again — can be pried open partway: reproduce it onshore, revise it onshore, verify it onshore, and carry only the handful of genuinely unresolved questions back out to sea for final confirmation. Over a long enough timescale, this amounts to an internalization of validation — moving part of the learning, failing, and correcting that once could only happen inside an expensive offshore cycle into the ordinary rhythm of onshore development.

Technology won't stop advancing, and machines will keep getting smarter. But every gain in capability adds new complexity to the system around it, and that new complexity has a way of quietly absorbing the value the capability just created — leaving the field with something that feels smart but doesn't quite work, isn't quite usable. It's in that gap, repeated often enough, that the nerve to keep building things gets worn down. What Sunnta is trying to do is shorten that gap: let some of the failure-finding, reproduction, and validation that used to be locked inside an expensive offshore cycle happen sooner, and more cheaply, onshore — make the complexity legible, and give the people doing this work enough runway to still be standing on the day "smart" finally becomes "usable."

Moving a failure from the sea onto land doesn't automatically solve anything. The first question is whether the reconstructed world is actually the one shaping the robot's behavior — resembling it isn't the same as matching it. Even granting a faithful reconstruction, the second question follows close behind: does a result that holds onshore still hold once the robot is back at sea? Different sea areas, different seasons, and local conditions all still reshape underwater perception and interaction, so a stable, measurable link has to be built between onshore performance and performance in the actual water.

And a third question, easy to skip past: even once validation increases, does the improvement in field performance actually come from the validation? Repeated testing can expose a failure earlier than it would otherwise appear, but it doesn't, on its own, make a sensor, a positioning system, a control loop, or an actuator better — running the same test more times doesn't improve the hardware underneath it.

Whether internalizing validation can genuinely fix the "smart but unusable" problem rests on all three of these holding up: fidelity, transferability, and a real causal link between more testing and better outcomes.

The gap between what a machine can do in a lab and what it can reliably deliver in the field isn't unique to the deep sea — the same gap shows up on land too. What's specific to the deep sea is only the price of crossing it, pushed up to a level that's impossible to ignore. That's reason enough to ask the question again: how much of this gap is really about the machine not being smart enough yet?

Bringing that price down is half a matter of machines continuing to improve, and half a matter of the environment — that same instant sliced out of the whole world, discussed in the last few sections. Environment, most of the time, means whatever the robot has to passively adapt to: the current is there, the seabed is there, the structures and obstacles are there, and the robot's job is to sense them, understand them, and get the work done. But once an environment can be recorded, preserved, and called back up on demand, it stops being just a place the robot adapts to and starts entering the development process itself — early enough that failures can be reproduced, options compared, fixes tested again and again before anything goes back in the water. Algorithms, sensors, control, and hardware still decide what a machine is capable of. Environment decides what path those capabilities have to travel down before they turn into something that actually works in the field.

Go back, one more time, to the robot vacuum this piece opened with. It can now clean an ordinary home fairly reliably — and that's not just down to better sensors, better localization, better control, more compute, better mechanics happening all at once. It's down to something else: it learned to build a map of the house. That map gives all those other capabilities somewhere stable to stand, a place where getting something wrong is cheap to try again. Home is its workplace, and also a world it gets to redo, at almost no cost, as many times as it needs. This is exactly the kind of world deep-sea autonomy still needs someone to raise it in.

Once an environment can be represented, and a live data connection kept running between the virtual version and the real system, it can enter the ordinary loop of testing and validating algorithms. At that point, environment stops being just a setting and starts being infrastructure — a quiet, structural form of support.

Set against the long arc of machine autonomy, everything above is a glimpse through a keyhole — every technical field is, in its own way, an exception to whatever rule seems to apply. Maybe one day, someone will simply hit retry, and failure in the deep mountains, the deep sea, even deep space, will stop being something that has to be endured. By then, how capable the machine is won't be the thing that matters most.