Naming who does the work

Name an engine with @

Type @ in the Build home composer to address a connected engine:

@claude build the backend while @codex builds the UI

Naming two or more engines opens a plan before anything is created. Naming one engine simply runs that Task on that engine.

Only engines connected on this computer can be addressed. An unrecognised name stays ordinary text, so an email address, a pinned package version, or a Git reference is never mistaken for an instruction.

One plan, separate Tasks

Each addressed engine becomes its own Task, grouped under one mission. Every Task keeps its own engine, model, worktree, rounds, Changes, and review — there is no shared session and no merged output. You review each one independently, and accepting or discarding one never touches the others.

Nothing is created until you confirm the plan. Before that you can rename a Task, change its engine, pick its model and effort, remove it, or add another one for a specific piece of work.

Scope decides what runs at the same time

Each Task in the plan has a scope: the folders it is expected to write to.

• Give a Task an exact scope and Iterel can prove it does not overlap its siblings, so they run at the same time.
• Leave the scope empty and Iterel cannot prove that, so the Task waits its turn instead.

Declaring scope is what buys parallel work. Iterel fills in a starting guess where it can, and editing it to match reality is the single most useful edit you can make to a plan.

Scope is also learned. After a round finishes, Iterel folds in the files it actually changed — and the exported functions, API routes, and database tables inside them — so the next decision is made against what the Task really touches rather than what it predicted. See Parallel work for the levels Iterel compares.

You can also choose that a Task runs after another one. Iterel will not accept an arrangement where two Tasks end up waiting on each other.

Hand a Task to another engine

Address a different engine in a Task's follow-up message to move that round:

@codex take it from here

The Task keeps everything: its conversation, its prior Changes, and any unfinished plan from the last run. The incoming engine continues from that history rather than starting over, so switching engines mid-Task costs no context.

Naming an engine that is not connected leaves the round where it is. Naming two engines is a plan, not a handover, so the round does not move.

Assign work to a teammate

You can name a person the same way you name an engine:

@codex build the checkout screen while @jon reviews the copy

That creates a Task assigned to them. Iterel never runs it — it is theirs to do — so it has no engine and no Run action. It sits on the Board like any other Task, shows who owns it, and counts toward the mission when it is done. Other Tasks can depend on it, so work can genuinely wait on a person rather than only on an engine.

People appear in the @ menu for cloud projects where they are a member who can be given work. Someone with view-only access is shown but cannot be assigned. Local-only projects have no members, so the menu lists engines alone.

Questions reach the person who owns the Task

When an engine pauses to ask something, the question goes to the Task's assignee — not to whoever happened to start the run. They get it in Iterel, by email, and in Slack where that is connected, and can answer from a browser or phone. If the assignee has left the project, the question falls back to whoever started the run, so it never reaches nobody.

What Tasks share with each other

When one Task settles something the others need — an interface, a name, a decision that changes their surface — it can pass that along instead of letting the others guess.

You see every one of these in the mission's history. Notes written by an engine are labelled as unreviewed reports: they are that engine's account of its own work, not an approved decision, and they never change what another Task was asked to do. Your instructions always take precedence.

Reading a mission

A mission running several Tasks shows both what is happening and what happened.

What is happening lists every Task with what it is doing right now — working, ready to review, failed, or waiting — and names what a waiting Task is waiting on. Anything needing your answer is listed first, together with how many other Tasks are held up behind it.

What happened keeps the record for anyone who was not watching: what each Task shared with the others, when a finished Task unblocked the next, and the accepted work totalled per engine.

Availability

Addressing engines is available on every plan. Your engines run on your own machine using your own subscriptions, so naming two of them costs nothing extra. Everything that keeps parallel Tasks from interfering with each other applies on every plan too.

Remote control is the paid capability here: starting and steering rounds, answering questions, running checks, and reviewing from a browser or phone while your own machine does the work. Following along, reviewing, and commenting stay free.