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

---
title: Shape a custom task inside a released workflow
description: >-
  Shape a task with declared parameters, a narrowed output schema and a
  bounded instruction set. You cannot supply arbitrary tools, stages,
  executables, network calls or a model choice.
route: /docs/compute/workflows/custom-tasks
page_id: docs-compute-workflows-custom-tasks
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Compute customers whose task does not match a workflow exactly
voice: D
reader_question: How much can I customize a workflow, and where does customization stop?
primary_action: Compile the task, then quote it
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-workflows-custom-tasks-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## Start from the closest released workflow

Customization happens inside a released workflow, never outside one. So the first decision is which workflow you are shaping.

Pick the one whose declared output is closest to what you need. If two are close, pick the one whose bounds already fit your largest item.

## What you can shape

Five parts of your request are yours to set, and each is validated against what the workflow declares:

- `parameters` — the typed knobs, filled from your data.
- `output` — the schema you want back, narrowed from the declared one.
- `quality` — the preset that decides how much checking runs.
- `policy` — the profile that carries your team's defaults.
- `limits` — your `deadline` and your `maximum_price`.

Bounded instructions live inside `parameters`, in the fields the workflow declares for them. They shape work the workflow already does.

## What is not available

The boundary matters more than the flexibility, so it is stated plainly. None of the following can be supplied, and asking for one returns a refusal rather than an approximation:

- Arbitrary tools. Only registered primitives run.
- Arbitrary stages. You cannot assemble your own stage graph.
- Executables or scripts. Nothing you upload is run as code.
- Network effects. No fetching a URL, calling your API, or writing anywhere except a registered destination.
- Model selection. You do not choose or change the model, and no workflow changes it to make something fit.
- Billing branches. There is no conditional path that prices one outcome differently from another.

This is why a custom task stays predictable. Everything that could run is registered before you ask for it.

## Compile before you quote

Compiling checks your shaped task against the declarations, locally, before anything is priced.

```bash
lithi workflow compile
lithi pack compile
```

Fix what compilation rejects first. A request that will not compile will not quote.

## What success looks like

Your compiled task names one released workflow, a parameter set the schema accepts, and an output schema no wider than the declared one.

Your quote then repeats the bounds and the maximum charge. Approval remains a separate act you take after reading it.

## If your task still does not fit

You get a typed refusal with a safe reason and a next action, not a best-effort attempt at something adjacent.

Three responses usually work. Narrow the task until it fits one workflow. Split it into two runs against two released workflows and join the results yourself. Or change the input so the released workflow can accept it.

If none of those work, the primitive you need is not registered yet, and no amount of instruction text will substitute for it.

To bound what comes back, see [narrowing an output schema](/docs/compute/workflows/output-schemas). To supply your own definition of good, see [building a rubric](/docs/compute/workflows/rubrics).