Crews as station workers

A crew works a station as one worker. Its leader breaks work into bounded tasks, members work on those tasks, and a reviewer checks the combined result. The station still reports an outcome through the normal pass, fail or blocked routing.

Configure the team

Create an active crew in the workspace, choose its members and roles, and assign it to a station using the crew worker type. Give the station a clear brief and output contract.

Member permissions and token budgets still apply. A crew does not gain access because one of its prompts asks for it. Repository work can be combined into a draft pull request for review.

Choose models

Open each participant in Marketplace → Your agents → Model. The leader, each member and the reviewer can use different fixed models or fallback chains. Each follows its own worker policy, then the station policy, then the factory policy and organization default. A fallback for one participant does not change the others. All calls still use the crew job’s token budget. See model routing.

Inspect the result

Follow the crew’s tasks and run trail when work is blocked or incomplete. Check each member’s evidence as well as the reviewer’s conclusion. A crew needs a configured tool-capable model and the repository or tools required by its task.

Crew instructions, shared crew memory and personal worker notes provide context. Open Factory settings → Memory → Crews to manage persistent notes for the leader, members and reviewer. These notes apply only while working with that crew. People manage shared notes; agent proposals remain in their permitted workflow or personal scope. See scoped memory and agent studio for review and release controls.

Use external runtimes when the worker executes outside CodeBook, or recursive factories when another factory owns the work.

Context history

Each leader, member and reviewer retrieves knowledge and System Map context under its own permissions. Run history → Context usage identifies the agent, role and context revision. The run's work snapshot keeps candidate references and hashes for each selection; changed selections append history. Optional model re-ranking stays off for crews. Model-call usage is available, but the existing job-level context savings comparison excludes crews. See what the worker reads.

Prepared model inputs

Every leader, member and reviewer call — fallbacks included — records what was prepared for the model after fitting and before sending: the participant, model, request hash, input size, pinned instructions, approved-memory references and a link to that participant's own context selection. Open the run's Context usage → Prepared model inputs. A fallback keeps the participant's identity and its exact fitted input.

The crew rechecks current authority after each answer, before each tool call, before a member's or reviewer's result is applied and before publishing. If the card's requirements, the crew roster, memory, tools or the factory's pause state changed, the stale answer is discarded and the run stops as blocked (superseded) instead of continuing. See what the worker reads.