Ready-made templates
A template here is a complete workflow: nodes, wires and part of the settings that you can drop into your account in two clicks and then edit as your own. There are ten of them, and all of them are built around chat.
All ten import and run on the free plan: no template requires a paid tier, none uses your own model keys and none contains nodes unavailable on free. The plan limits still apply — five workflows in total, one published at a time, and on the free plan an imported bot can only be published to the public web chat; Telegram, webhooks and schedules live on the paid plan.
The full table is in “Plan limits”.
Three ways to get a ready-made graph
-
The create-workflow dialog. Section Workflows, button New Workflow; below the name field there is a divider or start from a template and a list of templates. Clicking a row creates the workflow immediately and opens it in the editor. If the name field is filled in, your name is used, otherwise the template’s name; the description is copied from its short summary.
-
“Copy nodes” on the examples pages and on node pages in the reference. The button puts the graph into the system clipboard inside a service envelope; then press Ctrl+V right on the canvas of an open workflow. The editor renumbers the ids of the pasted nodes, and a pasted Entry does not create a second entry point — it is mapped onto the existing one, and everything that came from it arrives there (two entries in a graph is a hard validation error). This is a convenient way to add a piece to a graph you have already started instead of starting from scratch.
-
“Open in Flow” on the example pages — a link of the form
/import?template=<slug>. It creates a workflow from the template in your current workspace and opens the editor right away. A guest following such a link lands on the sign-in page first and is returned to it after logging in.
Importing is an ordinary workflow creation, so it obeys the same limits: the workflow count quota and the plan’s node allow-list are checked on the server. If the quota is exhausted, the import fails exactly the same way the “create” button would.
What you will have to configure
No template sets a model
In all nine templates that contain an LLM node, its configuration is empty. This is deliberate: the list of available models depends on the plan and on which keys are connected, so a model hard-wired into a template simply would not exist for some readers, and the import would fail before the editor even opened.
Neither validation nor the run complains about it. The “Model” field has a default — the first model of the catalog — so an imported template starts on exactly that one, graph validation (Validate) stays silent and the report comes back empty. Picking a model yourself is still worth it — not because you would otherwise get an error, but because the catalog default may not be what this workflow needs: a different price, a different quality, a different language. It takes ten seconds: open the LLM node and pick a model from the catalog. How the settings dialog opens is described in “Node configuration”.
REPLACE_WITH_YOUR_KB_ID in two templates
In rag-kb and support-rag-agent the Knowledge base node has the kb_id field filled
with the literal REPLACE_WITH_YOUR_KB_ID. The field is not empty, so the validator considers
the knowledge source specified and stays silent too.
And the run does not fail — which is worse than failing. Search honestly reports that the
base was not found: a string like Knowledge base 'REPLACE_WITH_YOUR_KB_ID' not found travels
down the graph as context. In rag-kb you see it directly in the answer. In
support-rag-agent only the model sees it: the agent gets that string instead of documents and
answers based on it — politely, confidently and wrongly. Meanwhile the run counts as successful
and is billed in full.
The fix: create a knowledge base (see “Knowledge bases and RAG”) and select it in the Knowledge base node instead of the literal.
Ten templates
| Template | What it does | What to configure after importing |
|---|---|---|
| Simple LLM chat | Entry → agent → answer. The skeleton of any chatbot. | Model; system prompt (empty) |
| RAG over a knowledge base | Finds fragments in documents and returns them as the answer. No model in the graph. | Your own knowledge base instead of REPLACE_WITH_YOUR_KB_ID |
| Support bot (RAG + agent) | Searches the base, then the agent answers from what was found. | Knowledge base, model, system prompt |
| Agent with web search | An agent with an internet search tool — for fresh facts. | Model; optionally the number of results |
| Chat with conversation memory | The agent remembers the latest turns of the session. | Model; memory window size (10 by default) |
| Structured data extraction | Turns free-form text into JSON following a given schema. | Model; the field schema for your task |
| Agent answer through a template | The agent's answer goes through a Jinja template — one consistent answer format. | Model; the template text |
| FAQ bot | Answers frequent questions; a draft prompt is already written. | Model; the prompt for your product |
| Text summarizer | Compresses long text into a short summary. | Model; summary format and length in the prompt |
| Translator | Translates incoming text into the given language. | Model; the default language in the prompt |
Four chat starters on one skeleton
Simple LLM chat, FAQ bot, Text summarizer and Translator are the same graph of
four nodes: Entry → AI Agent →
Exit, plus LLM connected to the agent by
the link_llm configuration wire. They differ only in the agent’s system prompt: in
“Simple LLM chat” it is empty, in the other three it is written for the task (the FAQ bot’s
prompt even says “tune this for your product”).
- Execute + Data
- LLM
The practical takeaway: if you need a “bot about X”, take any of the four and rewrite the prompt — the difference between them is entirely in the text. Why the model attaches from the side rather than in the chain is explained in “Wires”.
Chat with conversation memory
The same skeleton plus Window memory on the agent’s
Memory port. Memory keeps the latest messages (ten by default) within the thread and mixes
them into every request; without it the bot does not remember the previous turn. To configure:
the model and, optionally, the window size. What exactly counts as a “session” is covered in
“State”.
RAG over a knowledge base
The only template with no model at all: Entry →
RAG query → Exit, with
Knowledge base connected to the search by a data wire and setting
its parameters (five fragments by default, relevance threshold 0). What travels to the user is
the found text itself, without a model retelling it. This is useful as a search-quality
check: if the right paragraphs are not found here, adding an agent on top will not save them.
To configure: the knowledge base, then top_k and the threshold.
Support bot (RAG + agent)
The full chain: Entry → RAG query → AI Agent → Exit, where Knowledge base feeds the search and LLM feeds the agent. The user’s question goes into search, the found context arrives at the agent’s input, and the agent formulates the answer. The agent’s system prompt is empty — that is the first thing worth writing: what the bot must not do, and what to do when the context comes back empty.
- Execute + Data
- Data
- LLM
Agent with web search
The chat starter skeleton plus Web search plugged into the
agent’s Extensions port as a tool. The agent decides on its own whether search is needed and
calls it. Search goes through DuckDuckGo, no separate key is required; the node settings hold
the number of results (five by default). This is not the same as paid web search through the
model provider — the difference is covered in “Web search”. To
configure: the model.
Structured data extraction
Entry → Structured output LLM → Exit; the
model is attached to the node by the same link_llm. The template already contains a sample
schema of three fields — name, email, summary, one of which is required (summary). The
output is JSON following that schema rather than text, so it is convenient to route onward into
a database, an email or a CRM. To configure: the model and the schema for your own fields.
Agent answer through a template
Entry → AI Agent → Template → Exit. The template
contains {{ nodes.agent.output }} wrapped in a heading, i.e. the agent’s answer is inserted
into a fixed shape — that is how you get a consistent answer format (signature, disclaimer,
markup). The nodes.agent reference points at the agent node’s id; when you rename an id
right in the editor, references in templates are rewritten automatically, but when assembling
a graph by hand you have to watch for this yourself. The syntax is in
“Templates”. To configure: the model and the template text.
Small things that come up in practice
- Nodes in templates are labelled in Russian (
Вход,Агент,Ответ) — these are labels inside the graph, not interface elements, and the interface language does not affect them. You can rename a node by double-clicking its header. - A template is a copy, not a link. After importing, the workflow is yours: edits to the template on the platform side do not reach you, and your edits break nothing.
- Importing does not publish. A workflow created from a template is a draft; to make it usable you have to save and publish it on the Deploy tab (see “Publishing” and “Web chat”).
- Be careful with the graph boundaries. One Entry and at least one Exit is a hard requirement; details in “Entry and exit”.