Memory modes
Each prompt has a memory setting that controls how it interacts with thread history:| Mode | Reads | Writes | What it’s for |
|---|---|---|---|
| Stateless | – | – | One-shot tasks. Classify this text, extract these fields, translate this paragraph. No memory needed, no memory kept. |
| Read-only | ✓ | – | A prompt that needs context but shouldn’t alter the conversation record. A summariser that reads the full thread and produces a digest without adding to it. |
| Read-write | ✓ | ✓ | The standard conversational mode. A chatbot that sees what came before and adds its response to the history. |
| Write-only | – | ✓ | A prompt that contributes context for others without being influenced by prior history. A weather-fetching prompt that writes current conditions into the thread so downstream prompts can reference them. |
Threads
A thread is created when you trigger a run (prompt or workflow) and is returned in the response. Pass the same thread ID back on subsequent runs to continue the conversation. In the UI, this works through the Continue and New Run buttons at the bottom right of the run form. Continue appends to the current thread; New Run starts fresh. Threads are flexible – from the API, you can pass the same thread ID to different prompts or workflows, and the later ones will see the earlier ones’ memory.Forking
You can fork a thread at any point in its history. Load an existing thread – even one from production – pick a message, and re-run from that point with a different prompt revision or different inputs. The original thread stays untouched; the fork creates a new branch. This is invaluable for prompt iteration: take a real conversation that went wrong, fork it at the critical moment, and test whether your revised prompt would have handled it better.Channels
Channels are separate memory lanes within a thread. When a prompt node runs inside a workflow, you can assign it to a specific channel. Prompts on the same channel share history; prompts on different channels are isolated. This enables agentic patterns: one prompt gathers user requirements on a channel calledintake, another researches options on research, a third synthesises everything on summary. Each sees only its own conversation, but the workflow orchestrates them into a coherent result.
Channels also work when using a prompt as a tool call from another prompt – the parent prompt sets the channel, orchestrating which conversations its tool-prompts participate in.
Channels can be set in three places:
- Workflow editor – on a prompt node’s configuration
- Prompt tool calls – set by the parent prompt
- API – fully custom channel assignment per run