> ## Documentation Index
> Fetch the complete documentation index at: https://innateinc-theo-docs-skills-authoring-api.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy and iterate

> Download your trained model, run it on the robot, and improve it when it misbehaves.

Once a training run is marked **Done**, the model is ready to download to your robot and use as a skill.

## Download the model

When a run completes, the trained checkpoint is downloaded to the robot and activated.

<Tabs>
  <Tab title="Phone app">
    A completed run appears in the **Completed** tab (or shows a download button in the **Runs** tab).

    <Steps>
      <Step title="Open the completed run">
        Navigate to the skill page and open the **Completed** tab. Find the run you want to deploy.
      </Step>

      <Step title="Tap Download">
        Tap the download button on the run card. The app downloads the trained checkpoint and dataset statistics file to the robot.
      </Step>

      <Step title="Wait for activation">
        A progress bar shows the download and verification stages. When it completes, the model is automatically activated — the skill's `metadata.json` is updated with the checkpoint path.
      </Step>
    </Steps>
  </Tab>

  <Tab title="Web app">
    The web app has no manual download step — it relies on **auto-download** (below). Watch the run reach **Done** on the **Training** page; when the robot is on and connected, the checkpoint downloads and activates on its own.
  </Tab>
</Tabs>

The robot's brain reloads automatically after activation. Your skill is now live.

<Info>
  Auto-download is also enabled. If the robot is on and connected when a training run finishes, the model downloads and activates without any manual action.
</Info>

<Note>
  When a model downloads, the robot pre-builds an optimized **TensorRT** engine for it, so policies run fast on-device with temporal ensembling for smoother motion. This happens automatically — there's nothing to configure.
</Note>

## Run the skill from the app

The simplest way to test a trained skill is to trigger it directly, with no agent involved — from the web app's **Teleop** page or the phone app's **Manual Control**. Both list only activated (non-training) skills; see [Manual Triggering](/software/skills/manual-triggering) for each surface.

On selecting the skill and pressing play, the robot moves the arm to the learned start pose and begins running the policy at 25 Hz, reading cameras and streaming arm and base commands in real time. Stopping halts it immediately.

## Run the skill from code

Trained skills are available to agents and code-defined skills just like any other skill. The catalog generates a typed reference for each one, so you import and list it exactly like a code skill:

```innatepy theme={"languages":{"custom":["/languages/python-typed.json"]}}
from innate import Agent, SkillRef
from innate_skills.navigate_to_position import NavigateToPosition
from innate_skills.pick_up_cup import PickUpCup   # your trained skill

class TidyUpAgent(Agent):
    @property
    def id(self) -> str:
        return "tidy_up"

    @property
    def display_name(self) -> str:
        return "Tidy Up"

    def get_skills(self) -> list[SkillRef]:
        return [PickUpCup, NavigateToPosition]

    def get_prompt(self) -> str:
        return """You are a tidying robot. Use pick_up_cup to grab cups
        you see, then navigate to the kitchen to put them away."""
```

The Innate agent calls your trained skill the same way it calls any other skill — the execution pipeline handles loading the checkpoint, running inference, and sending commands to the hardware.

## What happens during execution

When the skill runs, the BehaviorServer loads the checkpoint, moves the arm to the learned start pose, then enters a **25 Hz inference loop**: it reads both cameras and the joint state, runs the policy, and streams arm and base commands until the task completes. The step-by-step breakdown lives in [Policy-Defined Skills](/software/skills/policy-defined-skills#execution-flow).

## Multiple training runs

You can train multiple runs with different hyperparameters for the same skill. Each run produces an independent checkpoint stored in its own subdirectory. When you download and activate a run, it becomes the active checkpoint for that skill.

To switch between runs, download a different completed run — activation overwrites the checkpoint path in `metadata.json`.

## Iterating on a skill

Training a policy is rarely one-and-done. Make the **first test easy**: reproduce the scene you recorded in — same robot placement, object positions, and lighting — and watch a full run without intervening. If the policy fails on its own training distribution, something is wrong upstream, not in your setup.

### Common failure modes

| Symptom                                 | Likely cause                                             | Fix                                                                  |
| --------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------------------- |
| Robot doesn't move or barely moves      | Too few episodes, or episodes have inconsistent starts   | Record more episodes with consistent start poses                     |
| Arm overshoots the target               | Jerky demonstrations or high variance in approach angles | Re-record smoother demonstrations; try a larger chunk size           |
| Robot starts well but drifts            | Not enough variation in demonstrations                   | Add more episodes with slight object position changes                |
| Works on first run, fails on repeat     | Object or robot position shifted                         | Record with more position variation; aim for 2–5 cm spread           |
| Gripper doesn't close at the right time | Inconsistent grasp timing across episodes                | Focus on consistent timing when closing the gripper                  |
| Robot ignores the object entirely       | Lighting or background changed significantly             | Record in the current conditions, or control lighting more carefully |

### How to improve a policy

* **Add more data** — the most reliable fix. 20–30 episodes covering the specific failure case, then sync and retrain; new episodes are added to the existing dataset, so you never start over.
* **Tune hyperparameters** — if the behavior is qualitatively close but not quite right, [when to change the defaults](/training/train-act-policy#when-to-change-the-defaults) maps each symptom to the right knob.
* **Improve demonstration quality** — replay your episodes and replace the weak ones: hesitations and course corrections, runs much longer or shorter than average, and start poses that don't match the rest.

### Scaling up

Once the policy works in the original setup, introduce variation gradually — move the object a few centimeters, swap in the same object in a different color, adjust the lighting modestly. When it breaks, record 10–20 more episodes under the new conditions and retrain. Each round makes the policy more robust.

<Tip>
  Invest in data variety and you'll spend less time debugging — see [how many episodes you need](/training/data-collection#tips-for-high-quality-data) for concrete numbers.
</Tip>