All nodes/AI/RAG

KB Write

Adds text to the knowledge base: chunking → embedding → vector store. By default creates a document (visible in the KB UI); optionally a raw mode without writing a document record.

KB Write
TextResult
KB

Type in the graph: kb_write

Exec

An error branch can be enabled (expose_error_output) to handle failures on their own path.

Ports can be split into separate execution and data handles.

Try it

Minimal working workflow

Entry
KB Write
Exit
  • Execute + Data
Press “Copy nodes”, open the editor and hit Ctrl+V on the canvas.

Pick your own connection or knowledge base first — the graph carries REPLACE_ME.

When to use it

Use this node when the workflow itself writes into a knowledge base: the outcome of a conversation, a recognised document, a record from a form, a reply from an external system. Uploading files by hand is the Knowledge section of the app; the node does not replace it and does not create a base — the base has to exist and be selected in the field.

How it works

The text is split into chunks, every chunk is embedded and lands in the vector store — exactly what happens to an uploaded file. The Text port carries both the trigger and the content; when only execution arrives there, the text comes from the Text field (a template such as {{ inputs.text }}).

Chunk size and overlap set to 0 mean “take the value from the base”, not “do not split”. The source label is the name the document appears under in the base’s document list.

Metadata is a set of typed key/value pairs; they are attached to every chunk and later work as hard filters during search. Values are rendered as Jinja, so the pair session / {{ variables.sid }} is stored already resolved and matches the same filter on the read side — that is how per-conversation isolation is built.

The output is document_id, chunk_count and kb_id.

Common mistakes

  • Empty text. This is not “wrote nothing, successfully” but a node error: the document the author expects to search later would simply never exist, and the mistake would surface several turns downstream.
  • Expecting deduplication. Every run creates a new document. A node that writes every chat message turns the base into a pile of near-identical chunks within a week.
  • Turning off “Track as document”. The chunks are indexed and will be found, but no document record exists — there is nothing to delete them by from the base’s interface.
  • Expecting the KB port to configure the write. Only the base id is taken from a connected Knowledge Base node; Top K and the threshold belong to search.
  • Adding metadata after the base is filled. Older chunks do not get it, and a filter on the new key cuts off everything written earlier.

Inputs

PortWirePayloadNotes
TexttextExecute + Dataexecute_data

Content to ingest; replaces the Text template when connected

KBkbDatadata

Knowledge Base node config; its kb_id overrides the field here

Outputs

PortWirePayloadNotes
ResultoutputExecute + Dataexecute_dataobject

Configuration

FieldTypeDefaultDescription
Knowledge Basekb_idstring""

Knowledge base the text is written into. A connected Knowledge Base node supplies this value and wins over the field.

overridden by port: kb

Texttext_templatestring{{inputs.text}}

Content to ingest. Supports {{inputs.text}}, {{nodes.x.output.text}}.

supports templates

Source Labelsource_labelstringworkflow

Filename/label shown for the created document.

supports templates

Advanced
Track as documentcreate_document_recordbooleantrue

When enabled, a KB document record is created (visible and deletable in the KB UI). Disable for ephemeral raw-chunk inserts that bypass the document list.

Chunk Size (override)chunk_sizeinteger0

0 = use the KB's configured chunk size.

Chunk Overlap (override)chunk_overlapinteger0

0 = use the KB's configured chunk overlap.

Metadatametadataarray

Typed key/value metadata attached to every chunk; searchable via hard filters.

Shared fields

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

  • expose_error_output — When enabled, show an execution output to connect nodes that run if this step fails.
  • 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.