Workstreams

A workstream takes on work that would keep a team busy for days or weeks: a framework migration, a feature that spans several services, a backlog of bugs. You describe the goal to an orchestrator. It breaks the goal into areas, puts an agent on each one, and keeps them coordinated while they work in parallel. The work comes back as pull requests for you to review.

You start and steer workstreams in the Factory App.

How a workstream is organized

Orchestrator

The lead session you talk to. It plans the work, delegates it to agents, keeps them coordinated, and asks you when a decision is yours.

Agents

Droid sessions the orchestrator starts. Each owns one piece of the work, reports back to the orchestrator, and can open pull requests. You can open any agent and talk to it directly.

Machines

Where the orchestrator and agents run: a fresh cloud computer from an environment, a Droid Computer (a managed cloud computer or your own computer connected through Remote Control), or this computer.

Shared folder

Documents the orchestrator and every agent read and write, on every machine they run on, such as plans, notes, findings, and deliverables. You browse it and add files in the Files tab.

Pull requests

Pull requests the orchestrator and agents open or work on, with their CI status. You review them in the PRs tab.

When to use a workstream

Use a workstream when the work is too big for one session: it spans hours or days, touches several areas that can move in parallel, or needs ongoing coordination. A workstream keeps going as you add work, so you can hand the orchestrator new tasks instead of starting over.

For quick, one-off work, start a regular session. Workstreams use more tokens than a single session, so save them for large work.

If you're choosing between a workstream and Factory Missions: Missions plan features and milestones up front and run them from Mission Control. A workstream starts with a conversation, and the orchestrator delegates as the work unfolds.

How it works

1. 1
   Start a workstream

   Click New Workstream in the sidebar, name it after the goal, and choose the machine the orchestrator runs on.

2. 2
   Tell the orchestrator the goal

   The orchestrator waits for your first message. Describe what you want, the constraints that matter, and what done looks like.

3. 3
   The orchestrator delegates

   It starts agents for each area of the work, on the machines you allow, and tells each one what to do and where to put its results.

4. 4
   Agents work and report back

   Agents report progress, blockers, and finished work to the orchestrator. When an agent needs your input, it shows up under Waiting on you in the Agents tab.

5. 5
   Review the results

   Review pull requests in the PRs tab and documents in the Files tab. Keep giving the orchestrator new work in the same workstream, or set up an automation for work that repeats.

Your configuration carries over

Agents are regular Droid sessions, so they use the same models, skills, MCP servers, hooks, and AGENTS.md files as any other session on the machine they run on. The orchestrator and agents start with your default autonomy level, capped by your organization's policy.