Threads & Branching

Every conversation in Reliant is organized into threads. Understanding threads helps you work with sub-agents, branch conversations, and switch between different approaches.

What is a Thread?

A thread is a sequence of messages—user inputs, AI responses, and tool results. When you start a chat, Reliant creates a root thread for your conversation.

When workflows spawn sub-agents or run child workflows, each can get its own thread. This keeps conversations isolated: a research agent’s internal dialogue doesn’t clutter your main conversation.

Thread Modes

Workflows configure how they interact with threads using three modes:

inherit (default): Use the parent’s thread. Messages appear in the same conversation. This is how most single-agent interactions work.

new(): Create a fresh, empty thread. The sub-workflow starts with no conversation history. Useful for spawned agents that should work independently.

fork: Copy the parent’s messages into a new thread. The sub-workflow sees the conversation history but writes to its own thread. Changes don’t affect the parent.

These modes are configured in workflow YAML:

- id: researcher
  workflow: builtin://agent
  thread:
    mode: new()
    inject:
      role: user
      content: "Research the authentication patterns in this codebase"

Branching Conversations

Branching lets you explore alternatives without losing your original conversation. When you branch from a message, Reliant creates a new chat that inherits all messages up to that point.

How to branch:

Find the message you want to branch from
Click the branch icon (or use the context menu)
A new chat opens with the conversation history up to that message

Key behaviors:

The branched chat becomes a new main conversation
You can send new messages to continue from the branch point
The original conversation remains unchanged
Branches are listed in the chat sidebar

Switching Workflows After Branching

After branching, you can switch to a different workflow before sending your first message. This is useful when you want to:

Try a different approach to the same problem
Use a specialized workflow (like TDD or code review) on existing context
Experiment with different presets

Important: You can only change the workflow before the first message is sent. Once you send a message, the workflow is locked for that chat.

To switch workflows after branching:

Branch from the desired message
In the new chat, select a different workflow from the workflow selector
Send your first message to start the new workflow

Thread Ownership

Within a workflow, threads have clear ownership rules:

Each thread has an owner step—the step that creates it via new() or fork
Multiple steps can write to a thread (add messages)
A thread has a last writer—the step whose write is final before the thread closes

These rules are determined at workflow parse time through static analysis. They ensure that:

Threads close predictably (after the last writer completes)
Parallel execution doesn’t create race conditions
Sub-workflows know when their parent thread is still active

Viewing Thread History

The chat interface shows messages from your main thread. To see messages from sub-agent threads:

Expand the tool call that spawned the sub-agent
The sub-agent’s response includes its full conversation

For multi-agent workflows with many threads, the workflow’s final output typically synthesizes results from all threads into a coherent response.