Skip to content
Loom

Core concepts

Loom is an agent-first developer environment built on real terminals. Two ideas explain everything else; get these and the rest of the docs read as consequences.

Panes are byte-opaque

Section titled “Panes are byte-opaque”

Every pane is a real PTY. Loom forwards the bytes between the terminal and the program running in it, and the engine never parses that output as a signal. What a program prints is between it and whoever is reading — Loom doesn’t scrape the screen to decide what to do next.

This is the deliberate constraint that keeps Loom honest: it can’t quietly react to text on a screen, so coordination has to be explicit.

Coordination runs the other way — an inbound control bus

Section titled “Coordination runs the other way — an inbound control bus”

Because Loom won’t read your screen, cooperation flows inbound: a process running inside a pane drives the rest of the environment by asking for what it needs, over a control bus exposed on a unix socket ($LOOM_SOCK). The bus has two faces over the exact same operations:

  • The loom CLI — shell out from inside any pane. Always available.
  • The loom mcp tools — the same operations as model-native tools, for agents that speak MCP.

So an agent (or you) can list panes, send a peer a task, spawn a helper, fan a prompt to a whole workspace, or flag itself blocked — all as explicit requests, never as inferences from output.

The operator is first-class — human or agent

Section titled “The operator is first-class — human or agent”

A terminal multiplexer treats agents as second-class guests. Loom inverts that: the operator — whether a person or an agent — is the first-class citizen, and the whole environment (every pane, the Fleet panel, the task board) is addressable. That’s what “agent-first” means in practice.

One binary, three faces

Section titled “One binary, three faces”

The single loom binary routes on its first argument: launch the GUI, run a loom control command (loom list, loom send, …), or start the loom mcp server. The CLI and MCP faces return before any GUI setup, so invoking loom inside a pane is cheap.

Panes are addressed by name

Section titled “Panes are addressed by name”

Every pane has a stable routing handle — a pool name like Cleo or Faye — that you target with the bus: loom send Faye …, loom focus Cleo. Get handles from loom list. (A pane’s display title tracks its working directory, so it changes as you cd; the routing handle stays put and is shown as a watermark.) You can also address panes by role — loom send role:reviewer … — once you’ve tagged them (see Coordinating a fleet).

What every pane gets

Section titled “What every pane gets”

When Loom launches a pane, it injects environment into the pane’s child process and prepends the CLI directory to PATH:

Variable What it is
LOOM_SOCK The control-bus socket the loom CLI talks to.
LOOM_PANE This pane’s own display name — the default target for attention and status.
LOOM_BIN Path to the Loom binary / CLI.

Outside Loom these are unset, and the loom CLI is an inert no-op by design — the same CLI and shell hooks can be installed globally and stay silent when you’re not in a pane. To check whether you’re inside Loom, test $LOOM_PANE.

Where to go next

Section titled “Where to go next”