LLM Custom

Description

Use LLM Custom when you need to extract several fields from the current conversation in one call. It is best for small, flat groups of related values, such as contact details or claim details. Use LLM Data instead when you only need one value.

Manual Inputs

Name	Data Type	Required	Description
Reasoning	string	No	LLM reasoning effort (`low`, `medium`, `high`). Defaults to `low`
Transcript	string	No	How much conversation history to read. Defaults to `Full`
System Prompt	string	No	Instruction that applies to every field
Schema JSON	json	Yes	The flat fields the tool should return
Response Map	object	No	Where to write each extracted field

Reasoning

How hard the model works to interpret the information.

low — fields are directly stated
medium — the caller may imply values or answer in a messy way
high — fields need careful normalization, or there are competing details (can be slower)

Transcript

How much conversation history the tool reads: Full, or the last 2, 4, 6, 8, or 10 messages.

Use Last 2 / Last 4 when fields should come from the caller’s latest answer.
Use Last 6 / Last 10 when values may be spread across a short exchange.
Use Full when earlier context matters — avoid it for simple extraction, since older details can confuse the result.

System Prompt

Optional instruction that applies to every field. Appended before the transcript and schema.

Only extract values explicitly stated by the customer. Do not infer missing contact details.
Return null for fields the caller did not provide.
Normalize dates to YYYY-MM-DD when possible.
Prefer the customer's latest correction if they changed an earlier answer.

Don’t repeat every field description here — put field-specific rules in the schema.

Schema JSON

One parent JSON object. Each key is a flat output field. Each value must include type and description.

{
  "first_name": {
    "type": ["string", "null"],
    "description": "Customer first name"
  },
  "email": {
    "type": ["string", "null"],
    "description": "Customer email address"
  },
  "claim_number": {
    "type": ["string", "null"],
    "description": "Insurance claim number. Exclude policy numbers."
  }
}

Supported field types:

Type	Meaning
`string`	Text
`number`	Decimal number
`integer`	Whole number
`boolean`	True or false
`array`	A list — include an `items` definition for the item type
`null`	Usually combined with another type when a field may be missing

Use nullable fields (["string", "null"]) when the customer might not provide a value. Keep the schema flat. Do not nest objects — use field names like customer_email instead of customer.email. Do not include wrapper fields such as schema, required, or additionalProperties; the tool adds those internally.

Response Map

Optional. Maps each destination variable to the field name returned by the schema. The left side is the destination variable; the right side is the extracted field name.

{{contact.email}}        -> email
{{custom.claim_number}}  -> claim_number

Use a blank field name on the right to write the whole extracted object into one variable.

Manual Outputs

Name	Data Type	Description
result	bool	`true` if the LLM returned schema-valid JSON and configured writes succeeded

Conditions

Success (true)

The LLM returned valid JSON matching the schema. If a Response Map is configured, fields are written to their destinations.

Failure (false)

The schema was invalid, the transcript was empty, or extraction failed.

Variables this tool writes

LLM Custom has no namespace of its own. It writes only the destination variables you list in the Response Map, and only on success — when the model returns schema-valid JSON. On failure (an invalid schema, an empty transcript, or an LLM timeout) nothing is written and each mapped variable keeps whatever value it already held. Because the destinations are yours, the Type of each is whatever you declared for the matching field in the Schema JSON, and the value is whatever the model extracted. The worked example below maps a four-field schema (first_name, email, claim_number, incident_date) into two namespaces:

Response Map:
  {{contact.first_name}}   -> first_name
  {{contact.email}}        -> email
  {{custom.claim_number}}  -> claim_number
  {{custom.incident_date}} -> incident_date

Variable	Type	Written	Example
`{{contact.first_name}}`	string	On success	`Jane`
`{{contact.email}}`	string	On success	`jane.citizen@example.com`
`{{custom.claim_number}}`	string	On success	`CLM-88231`
`{{custom.incident_date}}`	string	On success	`2026-03-12`

A field the model cannot fill comes back null (when you mark it nullable in the schema) and is written as an empty value — the step still succeeds. Leave the field name on the right of a Response Map row blank to write the whole extracted object into a single variable instead. Map into any declared variable — a custom scratch variable such as {{custom.claim_number}}, or a global such as {{contact.email}}. For the full set of namespaces you can target, see Variables.

Example Usage

Contact details:

Reasoning: low
Transcript: Last 6
System Prompt: Only extract values explicitly stated by the customer. Return null for missing fields.
Schema fields: first_name, last_name, email
Response Map:
  {{contact.first_name}} -> first_name
  {{contact.last_name}}  -> last_name
  {{contact.email}}      -> email

Claim details:

Reasoning: medium
Transcript: Full
System Prompt: Prefer the customer's latest correction.
Schema fields: claim_number, incident_date, incident_location
Response Map:
  {{custom.claim_number}}     -> claim_number
  {{custom.incident_date}}    -> incident_date
  {{custom.incident_location}} -> incident_location

Common Issues

Schema fails validation — check that every field has both type and description.
Unsupported type error — use string, number, integer, boolean, array, or null.
Array fields fail — add an items definition describing the list item type.
Nested objects fail — flatten the schema into top-level fields.
Wrong value is written — check the Response Map field name on the right side.
Noisy extraction — reduce Transcript and make field descriptions more specific.

Next Steps

LLM Data — Extract a single typed value
LLM Tools overview — When extraction passes vs fails
Variables — See all available variables

Get Started & Build

Calls, Contacts & Batches

Numbers & Routing

Tools, Automations & Integrations

Account, Billing & Security

Description

Manual Inputs

Reasoning

Transcript

System Prompt

Schema JSON

Response Map

Manual Outputs

Conditions

Success (true)

Failure (false)

Variables this tool writes

Example Usage

Common Issues

Next Steps

​Description

​Manual Inputs

​Reasoning

​Transcript

​System Prompt

​Schema JSON

​Response Map

​Manual Outputs

​Conditions

​Success (true)

​Failure (false)

​Variables this tool writes

​Example Usage

​Common Issues

​Next Steps

Description

Manual Inputs

Reasoning

Transcript

System Prompt

Schema JSON

Response Map

Manual Outputs

Conditions

Success (true)

Failure (false)

Variables this tool writes

Example Usage

Common Issues

Next Steps