Shape a custom task inside a released workflow

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.

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. To supply your own definition of good, see building a rubric.