Skip to content
Convoy
Contact
A hand-drawn industrial humanoid robot with a simple visor and mechanical joints packing a parcel in a warehouse.

Deployment infrastructure for physical AI

Deploy AI models
to real robots.

Convoy is building the runtime and release workflow that connects trained models to robot sensors, compute, and controllers, starting with learned manipulation.

Discuss your deploymentExplore the workflowOpen demo
In developmentFrom trained policy to physical actionPackage Qualify Release

The gap

A trained model is not a robot deployment.

A model can learn a task without carrying everything a robot needs to perform it. When the model changes, those assumptions change with it.

  1. Inputs

    Images, sensor data, and robot state prepared the way the model expects.

  2. Actions

    Model outputs translated into the units, coordinates, and commands the controller understands.

  3. Execution

    The runtime, dependencies, hardware settings, and timing required by the deployment.

  4. Release evidence

    A record of the configuration, conditions, and checks used to evaluate the system.

The robot-policy release

A trained model, delivered by your team, enters the robot-policy release. The release is the dashed boundary Convoy is building: release identity, model assets, input and action processing, runtime, target configuration, and evaluation evidence. The release hands processed actions to the robot and its existing controller and safety system, which remain outside Convoy.

Trained modelyour team
into the release
Robot-policy release
  • Release identity
  • Model assets
  • Input / action processing
  • Runtime
  • Target configuration
  • Evaluation evidence
deployed to
Robot controlleroutside Convoy
Conceptual architecture: a robot-policy release brings together the model, input and action processing, runtime, target configuration, and evaluation evidence.
See release details

Examples of what each part of a release covers. Names are conceptual, not a schema.

Release identity
name · configuration · evidence reference
Model assetsthe trained policy
  • policy weights
  • preprocessing spec
  • action space
Input / action processinghow signals are shaped
  • sensor alignment
  • normalisation
  • command translation
Runtimewhat executes it
  • inference loop
  • dependencies
  • timing budget
Target configurationwhere it runs
  • robot configuration
  • compute placement
  • controller interface
Evaluation evidencewhy it may be released
  • task criteria
  • runtime criteria
  • tested configuration
  • conditions and results

How it works

Package. Qualify. Release.

One release identity carries the model, processing, runtime, target configuration, and evidence through every step.

  1. Package

    Bring the model, input and action processing, runtime dependencies, and target configuration together as one identified release.

    What goes in and out of Package
    In
    • Model revision and assets
    • Input and action processing definitions
    • Runtime dependencies
    • Target configuration
    Out
    • One identified release

  2. Qualify

    Check that release against defined task and runtime criteria, and keep the conditions and results attached to it.

    What goes in and out of Qualify
    In
    • The identified release
    • Defined task and runtime criteria
    • Recorded test conditions
    Out
    • Evaluation evidence attached to that release

  3. Release

    Carry the identified configuration into deployment, with a clear basis for observing behavior and managing the next change.

    What goes in and out of Release
    In
    • The qualified release
    • Activation preconditions for the target
    Out
    • A deployed, identified configuration
    • A basis for observation and the next revision

Runtime

Designed around your robot’s execution path.

From an observation to a controller command, the details matter.

Sensors → Input processing → Model → Action processing → Robot controller

Sensors, then Input processing, then Model, then Action processing, then Robot controller. Convoy runtime boundary: Input processing, Model, Action processing. Outside Convoy: Sensors and Robot controller.

Sensorscameras · joints · force
on the robot
Convoy runtime boundary
Input processingalign · normalise
placement varies
Modellearned policy
placement varies
Action processingtranslate · limit
near the controller
Robot controllercontroller · safety system
on the robot
new observations / robot state
Convoy’s intended runtime covers input processing, the model, and action processing; your controller and safety systems stay outside it. Where each step runs depends on the task’s compute, timing, and failure requirements.
  • Execution
  • Release · configuration · evidence
  • Configuration-dependent placement
Where does inference run?

Robot-local, site-local, and cloud execution differ in compute, timing, and failure behavior, so placement is part of a defined deployment configuration rather than an assumption.

  • Robot-local computeonboard the machine
  • Site-local computeon the same network as the robot
  • Cloud computeremote, with the network in the loop

Each path is chosen against the task’s measured requirements. Workloads do not migrate between them on their own.

What makes a release repeatable?

The model, processing, dependencies, and target settings need an identifiable configuration. Reproducing that configuration does not guarantee identical behavior in a changing physical environment.

Explore the release boundary

What one identified release keeps together.

Release contents · conceptual categoriesnot a schema
release identity
release
name and configuration reference
model assets
policy
artifact and preprocessing specification
action_space
units, coordinates, and command form
input and action processing
inputs
sensor set and alignment
limits
command bounds and translation
runtime and target
runtime
dependencies and timing budget
target
robot configuration and compute placement
evaluation evidence
criteria
task and runtime criteria
results
conditions and results for the tested configuration
Category names are illustrative. They show what a release carries, not an API, schema, or command.

A policy here means a trained model that maps observations to actions. One release ties each of these together so a change in any of them is visible.

Design partnership

Start with one deployment.

We’re speaking with robotics teams working on learned manipulation: picking, packing, sorting, assembly, and related tasks. Each potential partnership starts with a defined model, robot configuration, and deployment goal.

Discuss your deployment

A good fit usually has

  • A trained policy

    a model that already performs the task in some setting

  • A defined robot setup

    the arm, sensors, compute, and controller you deploy to

  • A concrete deployment problem

    the part that is getting in the way today

FAQ

Questions about Convoy

What can I use today?

The Jetson demo lets you chat with a model on a physical device and inspect its telemetry, received usage, and inference traces. Demo credentials are supplied by the operator. The broader robot deployment workflow remains in development; design partnerships start with a defined model, robot configuration, and scope.

Will it work with any model or robot?

One text-inference configuration has physical verification: Qwen2.5-1.5B-Instruct Q4_K_M on our Jetson Orin Nano. This does not establish support for arbitrary models or robot motion. Each deployment still needs a defined processing pipeline, runtime, hardware, and controller configuration.

Does Convoy replace the robot’s controller or safety system?

No. Those responsibilities need explicit interfaces and boundaries. Release evaluation is not a substitute for the robot’s safety system or a safety certification.

Does inference have to run in the cloud?

No. The appropriate placement depends on the target system and task. We are not promising automatic movement between edge and cloud.

Does Convoy train the model?

Our initial focus is deployment: the execution pipeline and release workflow around a trained policy.

Is Convoy a robot manufacturer?

No. Convoy is building software infrastructure for deploying learned models onto robots.

Contact

Tell us about your next robot deployment.

Share your model, robot configuration, and the deployment challenge you’re working through.

Email us about your deploymentOpens your email app with the subject filled in.

Email

founders@deployconvoy.com

Helpful to include

  • Model: what it does and its interfaces
  • Robot configuration: arm, sensors, compute, controller
  • Deployment challenge: what blocks the next release

Please do not include proprietary model files, credentials, or sensitive operational data.