> ## Documentation Index
> Fetch the complete documentation index at: https://docs.promptjuggler.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Memory & Threads

> Conversational memory, channels, thread forking, and agentic communication patterns.

Prompts in PromptJuggler can maintain conversational context across multiple runs using threads. A thread is a sequence of messages – the conversation history that gives a model context about what came before.

## 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 called `intake`, 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