Autonomy is not one market
Ground vehicles, aerial platforms, maritime systems, industrial robots, and surgical systems all get called autonomy. The underlying physics, constraints, regulatory environments, and talent requirements are different enough that treating them as one category makes the landscape harder to read, not easier.
Autonomy is a useful category for venture capital. It is a less useful category for understanding where specific technical work is happening and what it actually demands.
The deployment environment shapes everything
A system operating in a structured warehouse has different sensing requirements, update cycles, failure modes, and certification paths than one operating in a contested outdoor environment. Both might be called autonomous. They are not the same engineering problem.
The certification path alone changes the shape of the team. An autonomous system for commercial logistics moves through a different regulatory process than one designed for unstructured outdoor terrain or an airborne platform in controlled airspace. Getting that wrong early is not just a compliance problem. It determines which engineers you need, how long the development arc is, and what counts as a meaningful test result.
Talent requirements follow domain constraints
A team building maritime autonomy needs people who understand sensor fusion in salt-water environments, RF behavior at sea, and the regulatory landscape for unmanned surface vessels. That is a different profile than a team building warehouse robotics or airborne platforms.
When companies source from the wrong domain, the failure is usually not visible at the interview stage. It shows up six months in, when the engineering assumptions turn out not to hold in the actual deployment environment. The candidate knew autonomy. They did not know this kind of autonomy. That distinction matters more than most job descriptions acknowledge.