Fixed Response Agent
The Fixed Response Agent returns a response you configure, with no LLM call. The response is a template, so it can carry values taken from the agent's inputs. Use it when a workflow needs to emit fixed or lightly parameterised content without paying for or waiting on a model completion.
The Fixed Response Agent belongs to the Generation group in the agent library. It is its own agent type (fixed_response), not a Custom agent, and there is no custom agent ID to pin. Add it from the agent library like any other agent.
Because there is no model call, the agent is instantaneous, deterministic, and reports no token usage.
When to use it
- Return a canned message or boilerplate response without invoking a model.
- Feed a fixed block of configuration, such as a set of JSON expression templates, into a downstream agent.
- Emit one of several canned replies chosen by an upstream value, without a model deciding the wording.
- Stand in as a deterministic placeholder while you build out the rest of a workflow.
Configuration
The response is configured on the agent, in type_config. It is not an input. The agent has two modes and they are mutually exclusive: setting fields from both is rejected.
Template mode
One template, interpolated against the agent's inputs. Reference an input with {{name}}.
{
"type_config": {
"template": "Hello {{name}}, your order status is {{status}}."
}
}
Lookup mode
A map of canned responses, chosen by the value of one input. Every value in the map, and default_template, interpolate the same way as template mode.
| Field | Required | Purpose |
|---|---|---|
response_map | Yes | Maps a value to the response template to return for it. |
lookup_key | Yes | The name of the input whose value selects an entry from response_map. |
default_template | No | Returned when the looked-up value matches no entry. |
trigger_key | No | The name of an input that gates the lookup. When set, the lookup runs only if that input's value appears in trigger_values. |
trigger_values | With trigger_key | The values of trigger_key that allow the lookup to run. |
{
"type_config": {
"lookup_key": "next_step",
"response_map": {
"AWAITING_DOCS": "Thanks {{name}}. Please upload your proof of address.",
"APPROVED": "Good news {{name}}, your application is approved."
},
"default_template": "Thanks {{name}}, we are still reviewing your application."
}
}
Gating with trigger_key. When trigger_key is set and its current value is not in trigger_values, the lookup is skipped and the upstream response is passed through unchanged. This suits a chat workflow that should only emit its canonical response on the final turn.
Inputs
The agent has no fixed input keys. Bind whatever the templates reference: an input per {{name}} placeholder, plus the lookup_key and trigger_key inputs in lookup mode. An input named state_updates is forwarded to the output untouched.
Output
{
"response": "Hello Alice, your order status is shipped.",
"state_updates": {}
}
| Field | Purpose |
|---|---|
response | The interpolated response string. |
state_updates | The state_updates input, passed through from upstream unchanged. |
A downstream agent reads the text via {{<node_id>.output.response}}.
What's next
- Custom Agent — generate a response with a model instead of returning a configured one.
- Intent Classifier Agent — a common upstream source of the value that drives lookup mode.
- Agent Reference overview — the agent-type model, catalog, and shared execution engine.