Start free

All nodes/Input / Output/Boundaries

Exit

Workflow exit point. Receives the final result and returns it to the user (or as an API response). The optional files input (one or more file references) returns files along with the response: external/webdav links are downloaded into the system store, files already ours are passed through without rewriting, and shown in chat (image/audio/attachment). There must be at least one. Supports response streaming. It has no run output — the scenario ends here.

Exit▶
Message
Files

Type in the graph: exit

Exec

Ports can be split into separate execution and data handles.

Try it

Model answer with a fallback error text

The exit returns the answer to the chat and replaces the platform message when the run fails.

Entry
LLM▦
LLM Response▶
Exit▶
  • Execute + Data
  • LLM
  • Execute + Data + Streaming
Press “Copy nodes”, open the editor and hit Ctrl+V on the canvas.

Runs as pasted

When to use it

The exit is what the scenario returns: a chat reply, the response to an API call, a Telegram message. It is mandatory, and in the overwhelming majority of graphs there is exactly one of them — every branch converges on it instead of carrying its own.

How it works

The value arrives on the end port, and streaming travels the same way, which is why a model’s answer prints in the chat as it is generated. When “Output Expression” is non-empty it replaces the incoming value entirely: useful when the scenario is called over the API and the answer has to be assembled from several nodes ({{ nodes.answer.output }}), harmful when the field was filled in “just in case” — edits upstream then stop affecting the answer.

The files port returns files alongside the answer. It accepts several edges; external links and WebDAV files are downloaded into the workspace file store (where the Files tab shows them), while files already stored there are passed through without copying. In chat they render as an image, a player or an attachment.

“Error message” fires only on an unhandled failure — when the failing node had no on_error branch to take. The template can use {{ error }}, {{ failed_node_id }} and {{ failed_node_type }}; an empty field means the platform’s default message. With several exits, the text is taken from the one that actually ran in this execution.

The node has no execution output: nothing follows an exit.

Common mistakes

  • One exit per parallel branch. Two exits live in the same run are an exec.multi_exit_race error at the run and deploy gate (a warning while you are still editing). Both write the result, the last one in the graph’s node order wins, and in chat only the one that spoke first is shown. Merge the branches into a single exit, through wait_all if they run in parallel. Separate exits are legitimate only for mutually exclusive branches — the arms of one if or switch.
  • An exit reached only by a data edge. It never runs, and the execution ends with an empty result. The validator catches this as graph.exit_no_exec_trigger: an execution edge is required along the whole path from the entry.
  • Expecting a message when there is nothing to say. An empty value on end is not sent to the chat at all — and that is not an error: the run status stays completed.

Inputs

PortWirePayloadNotes
MessageendExecute + Dataexecute_data—

Final value returned to the user. Overridden by the Output Expression field when that is non-empty.

FilesfilesDatadatafile

Files returned alongside the answer.

accepts many edges

Outputs

—

Configuration

FieldTypeDefaultDescription
Error messageerror_textstring""

Text written to the chat when the workflow raises an unhandled exception. Leave empty to use the platform default message.

supports templates

Output Expressionoutput_mappingstring""

Expression producing the final output, e.g. {{nodes.llm_1.output}}. When non-empty it REPLACES whatever arrives on the End port; leave it empty to return the End value as-is.

supports templates

Shared fields

Every node has these three — the platform adds them, not the node author.

  • split_ports_in — Show separate execution and data input handles instead of one combined port.
  • split_ports_out — Show separate execution and data output handles instead of one combined port.

Ready-made examples using this node