Actors in the Value Chain#

This section explains our perspective and relationship with different actors of the robotics ecosystem. This is based on the current market dynamics and these relationships will evolve as the market for general-purpose robots develop.

1. End-Users / Robot Managers#

The end-users are our main customers and our relationship with them is direct and fundamental. In the legacy model, with robots performing purpose built automation as “tools”, changing a robot’s behavior requires manufacturer intervention or expensive consultants. This situation is intractable when we consider a robot as a general-purpose “platform”, that can potentially be deployed in many different applications.

Our approach is to commoditize that automation logic. We treat the end-user as the owner of the automation, not just a passive operator. By providing a high-level Python API and pre-built Recipes, we enable users to modify workflows in minutes. This creates a powerful feedback loop for us: the end-users tell us which real-world complexities (building structures, detection targets, human interaction etc.) are actually breaking their workflows, and we build EMOS primitives that solve these specific edge cases natively. We aim to make this experience completely frictionless as explained in the EMOS roadmap.

It is important to understand that currently, the end-user market for autonomous general-purpose robots is mostly theoretical (outside of research institutes, field usage (if any) is teleoperated). We see ourselves as one of the players who will develop this market in the future. We believe, automation demand will come from companies and use-cases which were not considered to be automatable (see case study below). End-users would require plenty of hand holding (and dragging by the feet, if necessary) at the start. This includes rapid user-feedback/development cycles to improve their experience. Because despite clear economic incentives, the middle tier “robot manager” capacity would take some time to develop; this makes customer service paramount, as well as generally approaching end-users by “doing things that do not scale”.

Case Study ESA Security Solutions, Greece#

ESA Security Solutions, a premier private security provider with over 4,500 employees, represents the leading edge of the transition from “manned guarding” to “robotic security.” By purchasing an EMOS Expert license for their DeepRobotics Lite3 LiDAR robot, they moved beyond the limitations of purpose-built single-function hardware. This was our first sale and was executed through InMotion Robotic (see case study below).

As a service provider, ESA manages a diverse portfolio of deployment scenarios, ranging from parking enforcement and perimeter fence integrity to guest reception and building lock-up inspections. In a traditional robotics model, each of these tasks would require a separate software project, custom-tuned for every new client site. With EMOS, ESA’s own team, including one Python developer, now builds these automation behaviors as modular Recipes (Apps).

Their first production recipe will focus on an automated parking lot inspection: the robot follows a pre-recorded path to verify that vehicles are correctly positioned in designated spots. As deployments scale, they intend to build a fleet with Lite3 and M20 models.

This sale provided us with critical strategic insight: even when higher management is technically sophisticated (ESA’s C-level leadership are all engineers), there is a significant initial inertia in getting started with robotic platforms. Hand-holding at the start is a necessity, not an option. In follow up, we significantly lowered the barrier to entry by:

  • Simplifying Spatial Mapping: We added map and path-recording workflows directly into EMOS, allowing non-technical users to record a static environment and a desired patrol route simply by walking the robot through a new space.

  • Active Control Surfaces: We enriched our interaction frontend web-components to move beyond passive data viewing. The frontend web-components real-time provide task control and visual feedback that is easily embedded into their existing third-party security management systems.

The aim of EMOS is to empower ESA to own their logic and to prove that with the right orchestration layer, “robot manager” capacity can be built from within organizations that were traditionally out of scope for automation, before general-purpose robots came along. Even so, a lot more work needs to be done to make this technology transition seamless.

Case Study Skysmart Robotics, France#

Skysmart Robotics is a French security provider operating 40+ sites across the country. Unlike ESA, which purchased robots for its own patrols, Skysmart is building a rental offering: they deploy EMOS-powered quadrupeds at their end-clients’ sites and operate the patrol as a managed service. This turns the robot into a delivered capability rather than a capital asset the client has to own.

Their first cohort has 3 end-clients already lined up for deployment, covering industrial perimeter monitoring and after-hours patrol replacement. Integration between EMOS and Skysmart’s operations is currently in progress on the DeepRobotics quadruped hardware.

The joint commercial plan targets two sector expos in October–November 2026 as the public launch of the offering, with paying deployments starting Q1 2027. Skysmart uses EMOS on a per-unit licensing basis structured to support their rental economics.

For us, this deal opens the “service-operator” path alongside the “end-user” path proven with ESA: two distinct customer profiles that both need EMOS as the substrate, and cover different segments of the market with different sales dynamics.

Additional Enterprise Pipeline#

  • A security operator in Spain is evaluating EMOS-powered quadrupeds for solar farm surveillance and olive-grove monitoring. Early discussions.

  • Initial talks are underway with Amazon and Michelin on operational robotics use cases in their respective operations.

2. Distributors and Integrators#

Distributors and integrators own the last mile of the sales pipeline. While for traditional robots (tools), integrators acted as middle-men who can often provide value-addition through custom (mostly front-end) software, EMOS shifts their role toward high-value solution architecture.

For general-purpose robots, their role is currently limited to that of a distributor. For now, these distributors are the primary sales channel for both the OEMs and us. We approach these actors as Value-Added Resellers of the EMOS platform. Since EMOS is bundled on the robot, the distributors can sell its professional licenses as a necessary value-added offering that makes the robot ready for ”second development”. They can also earn distributor commission on allied services and recurring support contracts done through them.

If a distributor wants to work as a solution integrator, EMOS acts as their SDK for the physical world. Instead of resource-intensive custom development, they can focus 100% of their effort on enterprise integration; connecting robot triggers to ERPs, BMSs etc. EMOS reduces their engineering cost and allows smaller teams to move significantly faster at deploying solutions, which in turn accelerates our deployment footprint. I.e, we expect this role to get thinner with time.

Case Study InMotion Robotic GMBH#

InMotion Robotic acts as the Master Distributor for DeepRobotics in Europe. They represent the ideal profile of our Value-Added Reseller partner, i.e. a company with hardware logistics capabilities with a need to make the robot hardware ready for actual utility.

While InMotion handles import, certification, and hardware maintenance, selling bare-metal robots to non-technical end-users (like security firms or industrial inspection clients) can require long sales cycles for establishing actual utility. We have structured a formal distribution agreement that operationalize the EMOS value add:

  • Ready-to-Deploy Bundle: EMOS is pre-installed on all M20 and Lite3 units shipped by InMotion in the European market. Instead of selling the robot and the software as separate line items, InMotion presents the robot as an EMOS-Powered solution in their marketing materials and Spec Sheets. This lowers the cognitive load for the buyer, who sees a complete functional system.

  • Margin-Driven Sales: We applied the Value-Based Pricing model defined in our Pricing Agreement with InMotion. By offering a 25% distributor margin on software licenses, we incentivize the upselling of Pro and Enterprise licenses on every hardware unit.

  • Support demarcation: We have clearly delineated responsibility. InMotion handles the physical hardware warranty and Level 1 setup. We handle Level 2 & 3 software support and recipe logic.

Through InMotion, we have secured a direct sales channel to the European market. While most people still struggle to articulate the requirement for a high-level automation development layer (its all very new after all and all they have seen till now are flimsy SDKs and shoddy documentation from OEMs), from all the feedback gathered from other distributors, the need for EMOS is quite clear.

Similar formal arrangements with the following distributors are in the pipeline:

  • Generation Robots: Distributors for Booster Robotics and sub-distributor for DeepRobotics.

  • Innov8: Master distributors for Unitree.

3. OEMs (Hardware manufacturers)#

The hardware landscape of general-purpose robots has recently undergone a massive structural shift. It is shifting from a vertical integration legacy model (e.g., Boston Dynamics) to commoditized, cost-leading manufacturing. The old approach, where the manufacturer built everything from the robot chassis to the high-level perception logic, while necessary at the research stage, resulted in a closed ecosystem with a price tag that is prohibitive for most real-world commercial use-cases.

Today, hardware commoditization is well underway. Chinese manufacturers, particularly the aggressive cost-leading players like Unitree, DeepRobotics and a plethora of others have utilized public policy subsidies to scale up manufacturing and distribution. Their software focus thus far has remained the difficult problem of locomotion control, the fundamental ability to keep a humanoid or quadruped balanced on uneven terrain. As for the rest, they typically ship these machines with barebones software: a motion controller, basic teleoperation, and a proprietary SDK that merely exposes the robot’s raw interfaces in standard middleware.

For these manufacturers, expanding into high-level software orchestration is a structural hurdle. They do not want to be caught in a talent war they cannot afford and without a standardized runtime, these OEMs inevitably fall into a consulting trap, where their limited software resources are squandered on one-off custom requirements rather than building a scalable platform. This creates a permanent software bottleneck, expecting the customer to manually patch together a working system from a fragmented collection of open-source and custom components to achieve high-level tasks like autonomous navigation or semantic understanding. This “patchwork” approach is impractical, expensive, and remains the primary barrier to serious adoption.

There is also the non-trivial pressure of regional compliance. In Europe, for example, we see a clear and growing mandate for European-made software to satisfy stringent security and sovereign data standards. From our experience these constraints are well understood by most players and as the inevitable consolidation happens for subsidy inflated production, these constraints would become more pronounced.

Our strategy with OEMs is one of Incentivized Standardization. We believe manufacturers should focus on their core competency: the physical machine and its locomotive stability. With a single EMOS Hardware Abstraction Layer (HAL) Plugin (developed using their SDK), an OEM instantly unlocks the entire EMOS ecosystem for their hardware.

We transform the OEM’s capital-heavy machine into a liquid platform asset. This ensures that their unit is ready for what they like to call second-development, out of the box, allowing any EMOS Recipe written by an end-user or integrator to run on their specific chassis without custom code.

Case Study DeepRobotics - Hangzhou Yunshenchu Technology Co., Ltd#

DeepRobotics is a tier-one player in the Chinese robotics landscape and the one of the first companies in China to achieve mass production of industrial-grade quadruped robots. They are our oldest hardware partner, having signed a comprehensive Software Service Agreement in 2024. This relationship has been foundational in proving EMOS capabilities on general-purpose hardware.

Demo Videos

Check out some of our software deployment demos recorded at Deep Robotics HQ in Hangzhou, China: Conversation Agent Demo, Human-aware navigation and target following Demo

While our distributor partnerships (like InMotion) focus on bundling, our ultimate goal with an OEM of this caliber is Factory Integration, shipping EMOS as the default OS on the robot right out of the box. However, achieving this within large hardware-centric organizations presents specific challenges. DeepRobotics, like many in its cohort, has established massive capacity driven by industrial subsidies and a focus on hardware durability and locomotive control. Consequently, their internal structure is often siloed; product teams are heavily incentivized to ship new hardware (SKUs), often viewing third-party software as a secondary concern or a loss of control.

Our strategy here is to leverage the internal pressure from their own sales divisions. While product managers may be protective of their roadmaps, the frontline sales teams acutely feel the pain of lost deals when customers realize the basic nature of the default SDK (they try their best to offload this pain to their distributors). By demonstrating to the sales leadership that EMOS converts hardware interest into signed contracts, we are gradually aligning their internal incentives to accept EMOS not as a competitor to their internal software capacity, but as the necessary utilization layer, beyond their specialization, that in the end helps moves inventory.

Humanoid OEM Channel#

While DeepRobotics anchors our quadruped channel, we are replicating the same engagement model on the humanoid side. Active MoU discussions are underway with:

  • RealMan Robotics (Beijing): Original manufacturer of ultra-lightweight robotic arms and leader-follower teleoperation sets, operating large data-collection centres that feed their in-house manipulation-model pipeline. Beyond a standard OEM engagement, we are jointly scoping a model + deployment loop: RealMan’s baseline manipulation models are deployed at end-client sites via EMOS, EMOS captures use-case-specific data during operation, and that data is returned to RealMan for last-mile fine-tuning of the models. This gives RealMan a distributed data pipeline for their ML models, and gives end-clients continuously improving manipulation performance in their specific environment.

  • Booster Robotics (Beijing): A humanoid robotics startup focused on full-size and educational humanoid platforms, including the Booster T1 and K1 robots. Their systems are primarily targeted at research, education, and developer communities.

  • High Torque Robotics: Known for high-density joint actuators and modular humanoid platforms, including the Mini Pi+ desktop humanoid. Their robots target research, education, and rapid prototyping of high-payload humanoid systems.

  • Leju Robotics (Shenzhen): Humanoid manufacturer of the Kuavo family of full-size humanoid platforms. Harbin Institute of Technology (HIT) spin-off with a ROS-native engineering culture.

4. Allied Actors#

Beyond the direct value chain, we interact with a specialized group of allied actors whose innovations are utilized and amplified in EMOS.

Middleware Ecosystem#

EMOS primitives are built on the industry standard, ROS2, ensuring compatibility with the vast existing ecosystem of drivers and tools. We actively participate in the Open Robotics (OSRF) community to maintain this alignment. However, we are not dogmatic about the underlying transport layer. To prepare for a future demanding higher memory safety and concurrency, compatibility with community efforts like ROSZ (a Rust-based, ROS2-compliant middleware) is in our pipeline.

Model Inference Providers#

The ML graph infrastructure in EMOS (primarily part of EmbodiedAgents) is agnostic to the source of intelligence. It bundles light footprint local models for certain components and supports OpenAI-compatible Cloud APIs as well as local inference engines like Ollama and vLLM. Crucially, we are bridging the gap between research-focused policy learning and its utility on actual robots. We have collaborated with HuggingFace LeRobot team to integrate state-of-the-art policy models from LeRobot. The latest version of EmbodiedAgents includes an async action-chunking client that treats LeRobot as a remotely deployed Policy Server. This allows LeRobot models to drive ROS2 compatible manipulators, a pipeline that was previously disjointed.

Data Collection and Management#

A general-purpose agent generates a massive volume of raw sensor data, most of which is redundant. To scale, one requires a way to surgically extract high-value signal from the noise to refine ML models, validate system behaviors and satisfy compliance requirements. We have established a partnership with Heex Technologies, an emerging leader in robotics data management. By integrating their event-triggered extraction platform with EMOS, we enable users to automate event-driven data collection, without the overhead of bulk logging. This data can be visualized and manipulated on the partners platform. This allows EMOS end-users to maintain high-fidelity feedback loops, ensuring that every real-world encounter directly contributes to the continuous improvement of the automation Recipe.

Simulation Developers#

We are working with robotics simulators (Webots, IsaacSim) and asset providers like Lightwheel. Our specific focus here is different from the Sim-to-Real RL training crowd. We view the simulator as a Recipe Validator. The goal is to verify the logic of an entire automation Recipe in a digital twin before physical execution. This is a highly non-trivial problem for realistic, unstructured environments, and we aim to co-develop workflows with these partners to make Digital Twin verification a standard CI/CD step for physical automation.

Compute Hardware (NPU/GPU Vendors)#

Because EMOS (specifically our navigation stack, Kompass) is built on GPGPU primitives, we have a symbiotic relationship with silicon providers. Our goal is to maximize the utilization of edge-compute hardware not just for ML workloads, but navigation as well. While NVIDIA Jetson is the current dominant platform, we see a multi-provider future. We are actively collaborating with AMD to optimize for their upcoming Strix Halo platform and with Rockchip for cost-sensitive deployments, ensuring EMOS remains performant regardless of the underlying silicon. Similar collaborations are in the pipeline with BlackSesame Technologies and Chengdu Aplux Intelligence. See benchmarking results for Kompass on different platforms here.