LLM-Generated Fields

Most fields in a subtask or review node can be set to be populated by an LLM instead of by a contributor.

What this is

An LLM field is a normal form field whose data source is "LLM". The platform sends a prompt to a model and stores the response as the field's value. Title, type, validation, permissions, and visibility work the same as any other field — only the source of the value changes.

For contributor-input-driven judgements on a submitted value, see Evaluations instead.

Setting up an LLM field

In the Form Builder, select a field on a subtask or review node, click Data Source, and choose LLM. The field then exposes Prompt, Model, Temp, Tools, and a context summary.

Supported field types

The Data Source → LLM option is available on most value-producing field types:

• Short Text, Long Text, Numeric, Boolean, Datetime, Code — full LLM generation supported.
• Select, Rating, Ranking, Pairwise — also support full LLM generation of the field's value (the LLM picks the option, rating, ordering, or winner). In addition, parts of their configuration can be LLM-generated independently: a Select's options list can be generated (LLM options), and a Rating's labels can be generated (LLM labels).
• Criteria — uses a different LLM path. Criteria fields are not set via the Data Source → LLM menu; instead, individual criterion types (e.g. llm_judge, programmatic) make the criterion LLM-backed. See Evaluations.

Prompt

The Prompt popover has two tabs: User prompt (task-specific instruction) and System prompt (optional instructions appended to the platform default — the default is always sent).

For a comprehensive guide to prompt sources, context mechanisms, placeholder mapping, and how configuration differs across model response fields, inline evaluations, and criteria, see Prompt Configuration.

User prompt sources

Inline prompts can be promoted with Save to library.

System prompt sources

The System prompt tab shows the platform default (read-only) and three append options:

• Default only — nothing appended.
• Append custom instructions — inline text.
• From prompt library — a versioned System-role prompt.

Variables (template mode)

In Use custom prompt, enable template mode to insert field chips via {{ or Insert Field. The picker scope is:

• Current node — non-hidden fields that appear before this field in the node's field list.
• Upstream nodes — non-hidden fields on any ancestor Subtask or Review node (walking parent edges, excluding fail/reject edges).

Downstream/unrelated nodes, dataset columns, and task metadata are not available. Chips render purple in the editor; typing {{foo}} as plain text does not resolve — you must insert a chip.

See the Prompt Library variables section for reuse across workflows.

JSON output instructions

When template mode is on, the popover exposes an Append JSON output instructions checkbox. Enable it only for models that do not support structured output natively — it injects a JSON schema and formatting hint at the end of the prompt.

Model and temperature

Model and temperature default at the node level (Property Inspector → LLM Generation Settings) and can be overridden per field via the field's Model / Temp chips. Inherited chips show Model: Node / Temp: Node.

• Model — any model in the Model Registry (platform or org custom). Or choose Use model from dataset to read the per-task slug from a CSV column.
• Temperature — node default, per-field overridable.

Model from dataset — column naming

Both can be active together; the field column overrides the node column for that field.

Trigger timing (when generation runs)

The trigger is derived automatically from the prompt's context — you do not set it directly. Three modes:

The trigger is recalculated whenever the prompt's context changes (chips, upstream topology, same-node input dependencies). For batched groups, the group's shared trigger is recomputed from the shared context.

Contributor UI difference: on-demand fields show an inline Generate / Regenerate button (one per batched group). Immediate and on-activation fields show a Regenerate card above the form — one per batch, or a single card covering the whole node when batching is off. Values are already present when the task opens.

Tool calling

If the model supports tool use and your org has an active Tool Endpoint, the LLM can call tools (MCP or HTTP) during generation. Configured at the node level (Tool Calling in LLM Generation Settings); per-field modes:

• Use node settings — inherit (default).
• Custom — field-specific endpoint list.
• Disabled — no tools even if the node allows them.

The tool loop runs model → tool call → result → model …, capped by Max Rounds (1–20, default 5) at node or field level. A binding's own max_tool_rounds, if higher than the field/node cap, raises the effective cap for that generation. After the last tool-bearing round, the model gets one final tools-disabled structured-output call.

See Tool calling and bindings.

Generation behavior

Once triggered:

1. The prompt is resolved (platform-default system prompt + your system prompt + user prompt with chips substituted).
2. A job is queued; the field is marked generating.
3. If tools are enabled, the tool loop runs (up to Max Rounds, then one final tool-less round).
4. The response is stored as the field's value along with metadata (model, token counts, latency, cost), visible in the Data Explorer LLM details panel and aggregated on LLM Analytics. See LLM Logs.
5. The contributor sees the value on next open — or immediately after clicking Generate on an on-demand field.

Contributor interaction

LLM-generated values are read-only for contributors, rendered as a disabled input or read-only display with an optional LLM details panel. To change a value, contributors Regenerate (when allowed by the node).

• On-demand fields — show a Generate button until the contributor fills the required same-node inputs and clicks it.
• Rating with LLM-generated labels — labels are generated; the contributor still picks the rating.
• Completed / historical task view — entire form is read-only regardless of field settings.

Regeneration

Configured at the node level in LLM Generation Settings:

• Allow regeneration — when off, contributors cannot regenerate.
• Max retries — per-counter cap. Separate counters apply to: whole-node regenerations, each batched group, and each on-demand field (after its first free generation). All compare against the same Max retries value.

How contributors regenerate:

• Immediate / on-activation — one Regenerate card per batch above the form; re-runs every field in that batch.
• On-demand — each field or batched group has its own Generate / Regenerate button.
• Failed generations — card switches to Retry styling and still counts against the cap.

The platform does not re-run LLM fields automatically when upstream values change mid-task. Beyond initial generation and contributor regeneration, fields are cleared and re-generated in these cases:

• Review rejection / rework — on-activation LLM fields on the rejected node (and intermediate nodes reset during rework) are cleared and regenerate on reactivation.
• Workflow migration — edits affecting running tasks re-queue LLM-only nodes that need refreshing.
• Admin regeneration — org admins and project owners can regenerate a node's LLM fields from the admin task view, bypassing the retry cap and Allow regeneration toggle, even on failed or completed nodes.

Grouped LLM fields (batching)

Multiple LLM fields in the same field group can generate together in a single model call. In the Form Builder, put them in a group (Add Group) and flip Batch LLM fields on the group header. The switch only appears when the group has two or more LLM fields.

When batched, the group header exposes shared Context, Model, Temp, Tools, and System chips that override each member's individual settings. The Regenerate card treats the batch as one unit. Use batching to save tokens and keep outputs consistent when fields share context.

Verifying it worked

• Open a task and confirm the field has a value (or a Generate button for on-demand fields).
• In Data Explorer, expand the LLM details panel on the field for prompt, response, model, tokens, cost, and tool calls. For pipeline-wide aggregates use the LLM Analytics tab. See LLM Logs.
• In the Form Builder, check Prompt, Model, Temp, and context summary chips on the field. The node's Preview tab (Property Inspector) resolves template variables to current values without calling the LLM.

Common mistakes

• System prompt is additive, not a replacement. The platform default is always sent first.
• Plain {{foo}} text doesn't resolve. In template mode, insert chips via the picker.
• On-demand fields don't run automatically. Any same-node human-input reference makes the field on-demand.
• Contributors can't edit generated values. Add a separate human-input field, or rely on regeneration.
• Hard-coded field-level models drift from node defaults. Prefer node-level defaults; override per field only when needed.
• Library prompts reused across workflows need chips re-inserted — chips are workflow-bound.
• Low Max retries can strand contributors mid-iteration.
• Batch LLM fields toggle is hidden for groups with fewer than two LLM fields.

Example

Auto-summarize a support ticket in a subtask node:

1. Add a Long Text field Summary, set Data Source → LLM.

2. Prompt → Use custom prompt, template mode on, insert the ticket_body upstream chip:

   Summarize the following support ticket in 2–3 sentences. Highlight the user's core problem and any errors they mention.
   
   Ticket:
   [ticket_body chip]

3. Leave Model as Node; set the node model in LLM Generation Settings.

4. Trigger is derived as On activation (prompt only references an upstream field), so the summary is ready when the contributor opens the task.

5. Enable Allow regeneration with Max retries = 2 on the node.