The car that drives itself is an irresistible photograph. The car that can reproduce a software fault, document what happened, and behave the same way on a Tuesday in February is rather less photogenic. Yet that second car is the one an engineer can debug and a manufacturer can sell. Apex.AI has built a business in the unglamorous interval between the two.
- Apex.AI builds software frameworks and data transport for vehicles and other intelligent machines.
- Its ROS-compatible stack aims to make prototypes predictable, integrable, and safety-ready.
- The customers are OEMs, suppliers, and teams building ADAS, autonomous machinery, robotics, and related systems.
- The company’s latest work points toward series production: diagnostics, access controls, deployment targets, and repeatable evidence.
Founded in Palo Alto in 2017 by Jan Becker and Dejan Pangercic, Apex.AI began with a familiar engineering bargain. The open-source Robot Operating System ecosystem makes it much easier to create robotics software. But a fast prototype is not a certified automotive component. A production team also needs controlled timing, fault handling, documented interfaces, and evidence that the software behaves as claimed. Those demands are expensive, tedious, and absolutely central to the product.
The first thing to fail is repeatability
Imagine an autonomous vehicle that hesitates at a crossing. Its engineers have the sensor recording, the code, and a test rig. They run the scene again. This time the vehicle does something slightly different. A message arrived in another order; a thread woke a little later. Which result should they investigate? Apex.AI has described this nondeterminism as a recurring customer problem in autonomous-driving validation. Without a reliable replay, every rare failure becomes an argument with a ghost.
That is why Apex.AI talks about deterministic execution, recording, replay, and bounded communication. The point is not to make driving software glamorous. It is to make an observed fault observable again, so a test can lead to a fix and a fix can lead to evidence. The same principle applies to a tractor navigating a field or a robot moving near a person.
A stack, not a magic trick
The naming requires a little patience. Apex.Grace is the developer-facing framework and SDK, built for ROS-compatible application development and certified to ISO 26262 ASIL D. Apex.Ida handles high-performance communication and data transport. Together, the company presents them as Apex.OS, a software framework that sits above an operating system. Apex.Alan, introduced in 2025, addresses the development environment around the code: build systems, CI/CD, variants, traceability, and training.
The layers under a software-defined machine
Apex.Alan supports builds, tests, variants, and traceability across development and deployment.
This position in the stack is its distinction. A team can use open-source ROS 2 and do the production hardening itself. It can build custom middleware. It can adopt established automotive frameworks. Apex.AI’s proposition is to buy a reusable, safety-oriented base, keep familiar development habits, and spend the team’s scarce time on the vehicle’s own behavior. Its QNX integration makes the boundary plain: QNX supplies a real-time operating system; Apex.OS supplies framework, execution, and communication services above it.
The customers changed the map
At first, the company spoke chiefly to autonomous vehicles. By the time it announced its $56.5 million Series B in 2021, Becker said customers were using the software for ADAS, vehicle gateways, in-cabin sensing, and powertrains as well. Cars gave way to trucks and tractors. That is a useful correction to the usual autonomy story: the biggest early market for autonomous-system infrastructure may be systems that do not drive themselves.
Agricultural machinery makes the point neatly. Apex.AI has named AGCO and Krone & Lemken in work to integrate Grace and Ida. A tractor has different terrain and different jobs from a passenger car, yet it still has sensors, controllers, long product lives, legacy protocols, and a safety case to make. The reuse lies in the plumbing; the application remains the customer’s own.
The capital tells part of the cost story. That Series B included ZF, Continental, AGCO, Jaguar Land Rover’s InMotion Ventures, Airbus Ventures, Toyota Ventures, and others; the company now reports more than $75 million raised. Public pricing for the software is not posted. For a customer, the relevant comparison is the engineering bill for building, validating, integrating, and maintaining the same foundation internally. A certified component can shorten that work, though it does not certify the entire finished vehicle.
The factory is the final exam
Recent announcements are less about a self-driving spectacle than about production intent. In January 2026, HL Klemove selected Apex.AI as middleware partner for planned next-generation ADAS controllers. LG Electronics made a strategic investment in 2025, then announced a joint high-performance computer prototype combining ADAS and cockpit functions. Apex.AI and QNX announced validated compatibility to help move AI and robotic workloads onto a deterministic real-time base. These are collaborations and planned programs, not proof that every announced system has reached mass production.
The company’s Apex.OS 26-08 release reads like an engineer’s shopping list: more vehicle diagnostic services, process-level communication permissions, Renesas and Bosch Rexroth targets, recording improvements, faster QNX startup, and even protection against the 2038 timestamp problem. Each item sounds small until it breaks in a production fleet. A showroom demo only has to run once. A vehicle program has to run across variants, factories, repairs, updates, and years.
Apex.Alan extends that logic into the software factory. Its package of development-environment services uses familiar tools such as Bazel alongside the company’s own work on configuration, traceability, and deployment. This is an enterprise business: software products plus integration, training, and engineering services for organizations with complicated fleets and audit trails. The buyer is usually a software leader or supplier, not a driver choosing a dashboard app.
There is a practical lesson here for any team making software for the physical world. Begin by asking whether a failure can be reproduced. Then ask whether every deployed binary can be tied to its requirements, tests, configuration, and hardware. Only after those answers are satisfactory should the demo video carry much weight. Apex.AI’s pitch works best where software must live for years, cross many machines, and survive scrutiny. A small experimental robot may find the machinery excessive. A production vehicle cannot afford to discover its need for that machinery after launch.