Tutorial 1. Your first chatbot
Let us build a bot that answers like a person and remembers the previous turns. Four nodes and ten minutes.
What you end up with: a link you can open in another browser and talk to the bot — exactly as your visitor will.
- Execute + Data
- LLM
- Memory
- Execute + Data + Streaming
Building it
-
In Workflows press New Workflow, give it a name and create it. The editor opens with an empty canvas: the graph boundaries do not appear on their own, you place them.
-
Drag Entry and Exit onto the canvas from the palette on the left — they live under
Input / Output, groupBoundaries. Entry is where the user’s message arrives; Exit is what goes back as the answer. -
Drag in AI Agent (section
AI, groupAgents) and connect it: Entry’s output → the agent’s input, the agent’s output → Exit. -
Add an LLM node and run a wire from it to the agent’s
LLMport. Pick a model in its settings. -
Add Window Memory and attach it to the
Memoryport. It keeps the recent messages of the session and injects them into every request — without it the bot forgets the previous turn. -
Open the agent’s settings (select the node and press the pencil on its toolbar) and write a system prompt: who it is, what it talks about, what it does not do. That is the only place the bot’s character is set.
-
Press Validate, then Save.
Why the model hangs off the side instead of sitting in the chain
This is the first thing that surprises people. LLM and Window Memory are not steps — they are configuration: they have no execution input and never sit in the run queue. The agent pulls them in itself, at the moment it needs them, which is why one LLM node can serve several consumers at once.
The wires differ too: Entry to the agent is execute_data (a run and a value in one edge),
while LLM and memory arrive over link_llm and link_memory, which do not affect
execution order at all. All ten kinds are on the Wires page.
Testing
The Test tab is a real run: the same credits, the same model calls. Send two messages in a row and check that the second answer takes the first into account — that is what tests the memory.
The tab’s canvas shows which node is running; clicking a node opens its input and output. If there is no answer, this is where to look, not in the code.
Publishing
The Deploy tab → the Public chat channel → switch it on and press Deploy version 1. The link appears after the first deploy — until then the panel says so.
Open the link in another browser: you will see exactly what a user sees. Anyone holding that link can write to the bot, and those runs are billed to the workspace owner — treat it as a publication, not as a secret.
If it did not work
| What you see | Why | What to do |
|---|---|---|
| The deploy button is disabled and says «Up to date» | There is nothing to publish: the channel is off, or the graph was not saved after an edit | Switch the channel on and press Save in the toolbar |
| Editing the prompt changed nothing | The test runs the saved version | Save, then send the message again |
| The bot does not remember the previous turn | Memory is not attached, or attached to the wrong port | Check that the wire goes into the agent's Memory port |
| The answer arrives all at once, not word by word | Streaming is switched off on the edge into Exit | Click the edge and enable its streaming channel |
| The run is rejected | Out of credits or the workspace budget is spent; less often — other runs are already going and the concurrent-run limit is reached | Settings → Usage: check the balance. If it is the concurrency limit, wait for the running ones to finish |
The problems panel in the editor shows codes like graph.*, wire.*, exec.* — they are
explained in Graph validation codes. If a node behaved unexpectedly,
its input and output are visible under Executions.