Apptronik / Jabil
Field experience can make the next deployment easier without making the robot company more profitable. Apptronik and Jabil provide a live test of that distinction.
In February 2025, Jabil and Apptronik announced a partnership to manufacture Apollo and test it in Jabil’s own operations. The factory building the robot could also become a place to use and validate it. The following year, Google DeepMind published research applying the same AI model to different robot configurations. [1] [2]
Read together, the announcements raise a strategic question. If operating experience improves a robot, how much of that improvement strengthens the robot company? Value may also accumulate in a model used across multiple machines, a manufacturer’s process knowledge or a customer’s way of organizing work.
Banseog’s hypothesis is that Apptronik’s competitive position should be assessed along two dimensions: its ability to reduce the cost of moving into the next site, and its ability to retain the resulting savings as business profit. A large dataset or an impressive partner does not establish either. The meaning of the partnership will depend on the results that follow.
Partnership announcements and robot demonstrations can look like steps along one path. Their meaning depends on what is actually being tested.
Scroll the table horizontally to read all columns.
| Public material | Setting and platform | What the activity establishes |
|---|---|---|
| Jabil, February 2025 | Jabil manufacturing sites; Apollo, without a specified generation | Plans for production collaboration and pilots validating manufacturing and logistics tasks before customer deployment |
| Apptronik, June 2026 | Robot Park and customer or partner sites; Apollo 2 | Data collection and training through teleoperation and autonomous execution, linked by the company to development of the next commercial product, Apollo 3 |
| DeepMind, July 2026 | Research evaluation; Apollo 2 and Franka Duo with different hand configurations | Task performance using the same model checkpoint across configurations |
The first row does not establish current commercial performance at a particular factory. The second concerns a research and training platform. The third is not a test of customer-site profitability. These sources also do not establish the terms under which data from Jabil pilots might move to Robot Park or DeepMind. [3] [4] [5]
This distinction separates two transfers: from one product generation to the next, as learning on Apollo 2 informs Apollo 3, and from one site to another, as an improvement developed for one customer is used elsewhere.
Frequent human intervention on a research platform is not itself a commercial failure if the purpose is to create useful training data. Conversely, a new action demonstrated in research does not establish that a commercial product can repeat it at the required quality and cost.
Apptronik’s technical background includes actuator and control work on Valkyrie. Its Apollo 2 presentation now includes Artemis, which coordinates perception, planning and control, and Fleet Connect, which manages robot operations, deployment and data. Control was part of its earlier work, so this list does not establish a late transition from hardware into software. [6] [7]
A more specific clue is the parallel use of wheeled and bipedal configurations. Apptronik describes the wheeled version as designed around existing industrial mobile-robot safety standards and customer environments, while the bipedal version develops adaptability and walking reliability in more complex settings. These are design intentions, not evidence of completed certification. [8]
We read this as a choice to test core technologies under different deployment conditions. Gathering data on a flat factory floor and testing environments that require walking may involve different engineering challenges and yield different information.
Having both configurations does not prove effective reuse. We must ask whether adaptations remain separate, or whether a manipulation problem solved on one configuration also helps the other. Improving customer access and broadening learning can be simultaneous aims.
The Jabil partnership could bring production and operating experience closer together. If recurring mechanical failures in use lead to changes in design and manufacturing, later robots may become more reliable. If a picking failure is solved through a control-policy or model update, that improvement may transfer to other robots without changing how their bodies are manufactured. These are hypotheses derived from the partnership structure.
Separating the paths makes progress easier to judge. Lower assembly time and higher shipments are manufacturing outcomes. Less time and engineering effort to implement another customer’s task are deployment outcomes. One does not automatically establish the other.
Deployment could also become easier without a direct manufacturing-to-field-learning loop. Common hardware, standardized tasks or better external models may produce the improvement. Conversely, a tight connection between manufacturing and field work may still leave substantial customization if customer environments and quality requirements differ greatly.
Jabil’s production scale is therefore an insufficient measure of Apptronik’s ability to repeat deployments. The question is which problems the arrangement actually helps solve faster.
DeepMind’s use of the same checkpoint across configurations is concrete evidence that reuse can occur at the model layer, not only through a robot company’s field operations. It does not mean that Apptronik’s data was transferred to another company. The composition and rights of undisclosed training data cannot be inferred from the result.
More general external models could benefit Apptronik by reducing the tasks it must develop again. At the same time, if similar improvements become available across other robot configurations, the actions a model can perform may offer a weaker basis for differentiation. Access terms and performance differences still require separate examination.
Apptronik could create value beyond the model: combining the body and controls to meet customer quality standards, diagnosing failures and maintaining reliable work after changes. Artemis and Fleet Connect point toward such responsibilities. Their published functions do not establish that Apptronik is already earning a profit from them.
An integrator using external models and manufacturers can create substantial value. The relevant questions are whom customers trust to deliver an outcome, whom they pay, and what it costs that company to carry the responsibility.
Learning from deployments and Apptronik’s economic results may advance together—or diverge. These are possible business states, not classifications of current performance. Different task and customer groups could occupy different positions at the same time.
Scroll the table horizontally to read all columns.
| Apptronik retains limited profit relative to the value saved | Apptronik earns a profit after support, warranty and other costs | |
|---|---|---|
| Low reuse across subsequent sites | Each customer may require substantial development without adequate compensation | Customers may pay enough for a viable specialist customization business |
| High reuse across subsequent sites | Deployment becomes easier, but pricing pressure or partner costs limit profit | A business based on repeated delivery of a common product or integrated service may become viable |
This is a stricter test than “owning data is an advantage.” Greater reuse may mainly fund lower customer prices or partner fees. Extensive customization can still be profitable if customers pay enough and scope and responsibilities are controlled.
Failure conditions and evaluation records can influence both dimensions. Having many such records does not establish a superior business model. They must be usable elsewhere, legally reusable and capable of improving performance that customers recognize.
Public sources establish the direction of the partnerships and research applying a model across robot configurations. They do not adequately disclose customer-level support costs, reuse rights, pricing or warranty burdens. A structure for improving the technology is visible; whether it yields repeatable earnings for Apptronik remains an open question.
Kitting—assembling specified parts and quantities into a set—offers a concrete test because Jabil’s announcement names it among the pilot tasks. The following is an evaluation example, not a report of measured customer results.
First align the part types and shapes, variation in bins and layouts, travel distances, required throughput and quality criteria. Compare robots of the same generation and configuration, while recording model versions, site modifications and software changes. Where conditions cannot be matched, disclose the differences and narrow the conclusion.
Keep four sets of outcomes separate:
If labor burden is reported per kit, counting only successful execution time is misleading. Divide all labor time allocated to the operation by the number of kits meeting the quality standard. Record pre-acceptance development and site-modification costs separately. If no conforming output is produced, report the hours and failures rather than constructing a ratio. Lower labor burden also does not establish lower total cost once equipment and computation are included.
Research on Apollo 2 requires a different test: does the experience improve performance under conditions not used in training, or only fine-tune one site? For Apollo 3, ask whether the improvement survives the change in body and controls, then reduces customer-acceptance and operating burdens. Combining the generations into one cost curve would confuse learning investment with commercial operation.
Our first signal would be a decline in the additional work repeatedly required to move a similar task into another site. If a solution travels and development and intervention fall under comparable conditions, the hypothesis of accumulating common capabilities becomes stronger.
Attribution matters. If the external model, hardware and task environment all change at once, their effects must be separated. Where possible, compare Apptronik’s field improvements using the same model version, or isolate a model change on a common evaluation task. Without such comparisons, the result belongs to the combined system, not solely to Apptronik.
If a commercial product with substantial deployment experience still needs extensive redevelopment for each similar task and total support burdens do not fall, the repeat-deployment hypothesis weakens. If technical reuse improves but manufacturing, model, support and warranty costs for the relevant task or customer group persistently exceed associated revenue, the link between reuse and profit must be reconsidered. Insufficient public information is different from evidence of poor performance.
This perspective changes how the next customer is evaluated. Beyond customer numbers and expected shipments, ask whether the problem recurs elsewhere, whether its solution can be reused and how costs and revenue change in subsequent deliveries.
The Apptronik–Jabil partnership invites scrutiny of the whole path: experience transferring to another product and site, validation against customer requirements, and enough retained profit to keep supplying the work.
How much does learning at the first site reduce the burden at the next—and who continues to capture that value? Tracking both questions helps distinguish progress in robotics from competitive strength in a robotics company.
Independent analysis based on public information reviewed on October 3, 2026. It was not commissioned by Apptronik or Jabil. The scenarios and comparison criteria are Banseog’s analysis, not findings about undisclosed operating profitability or contractual rights.
![Banseog[strategy]](/assets/brand/banseog-strategy.svg){kind=small}