> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thinkplatform.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Choose User guide for browser tasks, Developers for CLI, SDK and external agents, and Administration for organization management.
> Confirm identity and organization/project context before operations. Documentation access does not grant ThinkPlatform permissions.
> Review side effects, verify changes with a read, and do not blindly retry an operation with an uncertain outcome.
> Use documented UI steps for the web app and documented public CLI or SDK interfaces for automation. Follow each page’s prerequisites and authentication requirements.

# Run work and inspect its outcome

> Keep Flow runs, Agent tasks, and MLOps jobs distinct while checking status and results.

Complete [authentication](https://docs.thinkplatform.ai/cli/get-started/authentication.md) and [context selection](https://docs.thinkplatform.ai/cli/guides/context.md) first. These examples use your active profile and saved project context. Confirm the destination before starting work:

```bash theme={"system"}
tp context show
```

Choose commands according to the resource you are operating on:

| Resource | Start or submit | Inspect |
| - | - | - |
| Flow | `flows run FLOW_ID` | Inspect the run response and follow the instructions for that execution mode |
| Agent task | Prepare a runtime or create a task, then `tasks post-message TASK_ID` | `tasks get`, `status`, and `messages` |
| MLOps job | A workload-specific submission command | `mlops jobs get`, `wait`, `logs`, and `metrics` |

A Flow ID, task ID, and MLOps job ID identify different resources. A Flow run does not necessarily create an MLOps job. Do not pass an arbitrary returned `id` into another command group.

## Run an existing Flow

Discover the Flow and inspect its `id`, `mode`, `device`, and `input_schema`:

```bash theme={"system"}
tp flows list
```

This command returns the project's Flow array and has no list limit option. Read only the fields needed for your chosen Flow. Prepare `./flow-input.json` as a JSON object matching that Flow's input schema. Use `{}` only when the Flow accepts no required inputs. Replace `FLOW_ID_FROM_LIST` below with the exact selected ID:

```bash theme={"system"}
tp flows run 'FLOW_ID_FROM_LIST' \
  --input @./flow-input.json
```

The command submits to the Flow runs endpoint and prints the returned JSON object. Inspect it before selecting any ID, status, result, or follow-up URL: the CLI does not impose a single response schema or automatically wait for completion. There is no universal Flow results or logs command in this command group. Follow the instructions for checking progress and retrieving results for that Flow's execution mode. If the response identifies a separate MLOps job, use that confirmed job ID with the job commands below.

`--device` overrides the device for an IoT-backed run. The current `flows run --dry-run` request preview shows a different endpoint from the actual run submission, so it is not an authoritative preview of the executed request. Confirm the selected Flow and inputs before invoking a run.

## Send work to an Agent task

Find the Agent in your saved project context:

```bash theme={"system"}
tp agents list
tp tasks list
```

Inspect IDs and names before selecting an Agent. Agent and task lists support `--offset` for subsequent slices. Use an existing task when continuing its conversation. For a new chat runtime, replace example Agent ID `27` with the selected Agent's ID:

```bash theme={"system"}
tp tasks prepare-runtime --agent-id 27 --private
```

Inspect the response's `task_id`, `thread_id`, `status`, and `reused`. This operation can reuse a runtime. Use its numeric `task_id` for `tasks` commands; the thread ID is a different identifier. Alternatively, `tasks create --agent-id 27 --title "Review the sample"` creates a task record and returns its `id`. Creating a record or preparing a runtime alone does not demonstrate that your requested work completed.

Replace example task ID `83` with the returned task ID. Review the prompt preview, then submit:

```bash theme={"system"}
tp tasks post-message 83 \
  --prompt 'Summarize the sample data available to this task.' --dry-run

tp tasks post-message 83 \
  --prompt 'Summarize the sample data available to this task.'

tp tasks status 83
tp tasks get 83
tp tasks messages 83 --summary
```

Inspect the returned status fields for completion, errors, or a request for user input. A successful `post-message` request confirms acceptance of that request, not successful completion of the task. `messages --summary` reports message counts and sizes without message content, but still fetches the messages.

For a bounded read of recent checkpoint content, use the `thread_id` returned by runtime preparation or task details:

```bash theme={"system"}
tp agents tasks checkpoints 'THREAD_ID_FROM_RESULT' \
  --limit 20 --direction newest
```

Inspect `messages` and `returned` in the checkpoint page; a recent slice is not the complete conversation. If you need the task messages response, use:

```bash theme={"system"}
tp tasks messages 83
```

That command has no message-limit option. The CLI has no generic task wait command; space out status checks and impose a deadline in your own automation.

## Follow an MLOps job

For one training submission, find a registered dataset and a supported architecture in your saved project context:

```bash theme={"system"}
tp mlops data list
tp mlops data versions 'DATASET_NAME_FROM_LIST'
tp mlops hyperparameters architectures
tp mlops hyperparameters get 'ARCHITECTURE_FROM_LIST'
```

Replace the quoted names with discovered values. Read the architecture's schema and prepare `./hyperparameters.json` as a matching JSON object. Choose the intended output model name. The architecture list and schema reads have no local limit option. Check compatibility with the dataset before submitting; training can allocate compute.

Review the request, then submit it once:

```bash theme={"system"}
tp mlops train submit \
  --model-name 'CHOSEN_OUTPUT_MODEL_NAME' \
  --architecture-name 'ARCHITECTURE_FROM_LIST' \
  --dataset-name 'DATASET_NAME_FROM_LIST' \
  --dataset-version 'VERSION_FROM_DATASET_VERSIONS' \
  --hyperparameters @./hyperparameters.json --dry-run

tp mlops train submit \
  --model-name 'CHOSEN_OUTPUT_MODEL_NAME' \
  --architecture-name 'ARCHITECTURE_FROM_LIST' \
  --dataset-name 'DATASET_NAME_FROM_LIST' \
  --dataset-version 'VERSION_FROM_DATASET_VERSIONS' \
  --hyperparameters @./hyperparameters.json
```

Inspect the full submission response. Copy its actual `job_id` into the commands below, after confirming it identifies the submitted MLOps job. The response comes from the server without a fixed client model; if no usable `job_id` is present, inspect the response and job inventory before continuing. Do not substitute a model ID, a Flow run ID, or a guessed job name.

To find an existing job or reconcile a submission:

```bash theme={"system"}
tp mlops jobs list
```

Inspect the returned collection before extracting an ID. Local `--name`, `--status`, `--limit`, and `--offset` shape the fetched job collection; they do not guarantee backend pagination. Replace `JOB_ID_FROM_RESULT` with the exact job ID:

```bash theme={"system"}
tp mlops jobs get 'JOB_ID_FROM_RESULT'
tp mlops jobs wait 'JOB_ID_FROM_RESULT' \
  --interval-seconds 10 --timeout-seconds 600
tp mlops jobs logs 'JOB_ID_FROM_RESULT' --tail 50
tp mlops jobs metrics 'JOB_ID_FROM_RESULT'
```

`wait` returns `job_id`, `status`, `terminal`, polling details, and the last `job`. It exits `0` for a recognized successful terminal state and `1` for a recognized failure or a polling timeout. A timeout result has `timed_out: true` and `terminal: false`; it stops waiting and does not cancel the job. Unknown statuses continue polling until the deadline. `watch` provides the same bounded polling with progress output when JSON mode is off.

`logs --tail 50` trims the fetched logs locally. Use `--contains` to filter or `--output ./job.log` to save them. `stream-logs` waits for the backend stream to finish and has no command-level duration limit, so prefer fetched logs for bounded inspection. Metrics and job details are separate from application result artifacts: inspect the actual returned metadata and use the workload's documented artifact retrieval workflow. Do not assume a generic `results` command exists.

If a run submission, runtime preparation, or message post times out, the server may already have accepted it. Reconcile task lists, messages, job inventories, and any returned identifiers before retrying. Do not automatically repeat mutations: duplicate runs or prompts can create duplicate work. See [scripting and output](https://docs.thinkplatform.ai/cli/guides/automation.md) for exit status and partial-output handling, and [troubleshooting](https://docs.thinkplatform.ai/cli/guides/troubleshooting.md) for recovery checks.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.