How Friday works

When you type a prompt, three things run on different timescales: Dispatch talks to you, threads edit code, and a merge queue stitches their work back into your branch. This page walks the path from keystroke to PR.

The shape

You type a prompt
   ↓
Dispatch decides what to do:
   ├── reply directly (if it's a question)
   ├── spawn a Thread (if there's editing to do)
   └── call a Subagent (for a focused investigation)

When a Thread finishes:
   AcceptThread → merge queue → cherry-pick onto your branch

You only ever talk to Dispatch. There's exactly one Dispatch per session. Threads do the editing; you can have as many as you have parallel work. Subagents are one-shot helpers that report back into the conversation that called them.

See Dispatch, threads, and subagents for the full breakdown.

A turn, step by step

You press Enter. Here's what runs.

  1. Your message lands. If Dispatch is busy, the message goes to the queue and runs after the current turn finishes. Otherwise it goes straight into Dispatch's context.
  2. The agent loop starts. Friday adds your message to the conversation, builds the system prompt, and asks the LLM to respond.
  3. The LLM picks tools or replies. The response is either text or a list of tool calls (read a file, run bash, spawn a thread, and so on).
  4. Tools run in parallel. Multiple tool calls in one response execute concurrently. Their outputs go back into the conversation as tool_result blocks.
  5. The loop continues until the LLM stops calling tools. That's a natural stop. The loop also stops if a tool returns end-of-turn, which happens when you cancel or when a thread calls AcceptThread.
  6. Post-loop hooks fire. If self-review is on and the turn made code changes, Friday runs the code-review subagent on the diff. If a dispatched thread reports task complete, Friday auto-accepts and queues its branch for merge.

This loop is the same shape for Dispatch, threads, and subagents. The differences are which tools are available and which post-hooks fire.

Threads and worktrees

In GIT mode, every thread runs in its own git worktree on its own branch:

Branch: friday/thread/<thread-id>
Path:   ~/.friday/workspaces/<session>/threads/<thread-id>/worktree/

Threads don't see each other's changes. They don't see your uncommitted changes either. They start from your current branch (your "feature branch"), make commits, and call AcceptThread when done.

In Cowboy mode there's no isolation: all threads share Dispatch's directory. That's faster to set up but loses parallelism. See GIT mode and Cowboy mode.

The merge queue

When a thread calls AcceptThread, its branch goes into a FIFO queue. A background merge worker:

  1. Checks out your current branch.
  2. Cherry-picks the thread's commits.
  3. On success: deletes the thread's branch and worktree, marks it MERGED.
  4. On conflict: aborts the cherry-pick, sends the thread back to RUNNING, and shows a conflict summary in the thread's pane. You continue the thread to resolve.
  5. On a dirty current branch: same fallback. Friday won't overwrite your in-flight edits.

The queue persists to disk at ~/.friday/workspaces/<session>/merge_queue.json, so a restart mid-merge won't drop work.

What Friday does on your behalf

Behaviors that aren't obvious from the surface:

  • Tool calls in one LLM response run concurrently.
  • Older turns are summarized once context grows past ~80K tokens.
  • For Claude drivers past 700K tokens, the next call upgrades to Opus.
  • The code reviewer always runs on the opposite provider from the driver.
  • For dispatched threads that report task complete, Friday tells the thread to call AcceptThread automatically. Whether the thread reaches task complete on its own depends on Working Style: Collaborative workers are told to ask questions first; Supervised and Autonomous workers are told to keep going. Once AcceptThread runs, whether you see a "Ready to accept" prompt is a separate gate, also driven by Working Style.
  • MCP tool schemas only appear in the LLM's tools list after the agent calls MCPLookup for that server. Compression resets discovery; the agent has to look up again.
  • For multi-step prompts, agents often call the Plan tool on their own. In Collaborative mode the runner then injects a "confirm before implementing" prompt; in Autonomous mode the plan goes straight to execution.

What Dispatch does not do

Dispatch can't Write or Edit files. Editing is a thread capability. If you ask Dispatch to fix a bug in auth.py, what happens depends on the prompt:

  • A small, single-file change: Dispatch may spawn a thread.
  • A read-only investigation: Dispatch answers directly using Read, Grep, Glob, and the file-search subagent.
  • Anything multi-step: plan first (Supervised mode or Plan tool), then dispatch.

This split is the central design choice. Dispatch stays in conversation; the thread focuses on one task.

Read next