Your platform. More possibilities.

What we want to discuss

• Available SDKs, APIs, and approved integration interfaces.
• Access to test hardware and technical documentation.
• Operating constraints, safety responsibilities, and validation requirements.
• Commercial permissions, support ownership, and a possible route to distribution.

How collaboration would work

No manufacturer partnerships or supported models are currently announced. This invitation does not imply endorsement by any robot maker.

Before sharing sensitive material

Start with a non-confidential overview. Do not include proprietary source code, credentials, personal records, or restricted technical information. Confidential exchanges require an appropriate agreement and channel.

The position robot makers are in

Building a capable robot and building the software that makes it useful are different businesses with different economics, and most hardware companies are now being asked to do both. Customers increasingly do not want a machine; they want a task completed. The distance between those two things is software, and it is expensive software that does not benefit from hardware margins.

Vertically integrating it has a further cost. Every manufacturer that builds its own capability layer is solving the same perception, manipulation, evaluation and deployment problems as every other manufacturer, in private, and none of that effort compounds across the industry. Meanwhile the customer ends up with a fleet that cannot be operated as one thing.

What hardware-open means here

Hardware-open means the software layer is not a strategy to commoditise your platform or to put a layer between you and your customer. A capability should be able to run on your robot because your robot is good at the job, and the differentiation you have invested in should remain visible rather than be abstracted into sameness.

In practice that means integrating against the interfaces you already expose and support, respecting the operating constraints you publish, and leaving safety authority where it belongs: with the machine and the party responsible for it.

What a first integration would look like

The scope we think is worth attempting is deliberately narrow: one supported robot, one valuable workflow. Narrow enough that it can be validated properly and that failure teaches something specific, rather than producing a demo that proves nothing.

• A workflow your customers already ask about, with a measurable baseline.
• A single robot model and a single firmware or software revision.
• A defined operating envelope, agreed in advance, with explicit conditions for refusing to act.
• Acceptance criteria written before the work starts.
• A named owner on each side.

What we would need to discuss

• Integration surface. Available software development kits, application programming interfaces and approved integration interfaces, and which of them are supported versus tolerated.
• Test hardware. Access to a representative unit and to technical documentation, because integration written against documentation alone does not survive contact with a real machine.
• Operating constraints. Rated envelopes, duty cycles, thermal and power limits, and the conditions under which the platform expects software to stand down.
• Safety responsibilities. Where the manufacturer's safety authority begins and ends, which interlocks are non-negotiable, and what a third party is permitted to influence.
• Validation requirements. What you would require to consider an integration validated on your platform, and who performs that validation.
• Support ownership. Who a customer calls when the task fails, and how a fault is triaged between hardware and capability.
• Commercial permissions. What is permitted regarding distribution, branding, resale and reference, and what a route to market would look like if the first integration worked.

What we would not ask for

Not exclusivity, not access to proprietary firmware or source, not control of your customer relationship, and not that you bypass or weaken a safety system. If an integration requires any of those, it is the wrong integration.

Stated plainly

No manufacturer partnership exists. No robot model is supported. No integration has been built, tested or validated, and nothing on this website should be read as endorsement by any robot maker or as a claim that a particular platform works with anything we have made. This page is an invitation to a technical conversation, nothing more.

Before sharing sensitive material

Start with a non-confidential overview. Do not include proprietary source code, credentials, unreleased roadmap detail, customer records or restricted technical information in a first message. The inquiry builder on this site produces a draft in your own browser and is not a confidential channel. A confidential exchange requires an appropriate agreement and an appropriate channel, agreed first.

If you are being asked to support an integration, this is what the other side needs from you: the integration requirements checklist.