Documentation sections

Work

Give your AI a reusable way of working

A Crew is a convention layer your AI uses: roles, routines, skills, and shared memory that shape its work. It is not a fleet of autonomous workers running continuously on its own.

Last reviewed July 14, 2026

In the app Work → Crews

Problems this solves

Start with the recurring problem, then use this feature when its boundary matches the outcome you need.

Problem

Stop re-explaining a recurring AI-assisted process

Every renewal review, incident triage, or research cycle starts with a long prompt describing roles, procedures, and boundaries.

How this helps

Package those roles, routines, skills, and shared memory into a Crew that an authorized AI can load and follow consistently.

Problem

Make multi-role handoffs consistent

Research, analysis, review, and drafting need different perspectives, but responsibilities and handoffs drift between sessions.

How this helps

Define named Crew roles and reusable routines so the AI can apply the same operating model while a person reviews the result.

Problem

Run a specialized tool with scoped configuration

A reusable analysis or generation script needs Crew-specific inputs and durable supporting instructions.

How this helps

Attach a skill to the appropriate role or Crew, bind Crew Variables, and run or develop it through the hosted tools or CLI.

Crew definitions are AI-authored.

The app lists Crews and displays their definition, but it does not provide a direct editor for roles, routines, or shared memory. Ask an authorized AI client to create or change those parts. The app does provide direct controls for Crew Variables.

Create a Crew

  1. Connect your AI with Work Build and approve Crews access.
  2. Describe the business job, the roles involved, and the boundary of the Crew.
  3. Ask the AI to propose the roles and routines before it creates them.
  4. Review the created Crew under Work → Crews and ask the AI to correct unclear responsibilities.

Crew authoring uses the same hosted https://app.solidactions.com/mcp endpoint as the other workspace AI surfaces. No Crew-specific local MCP installation is required.

A useful creation request is specific about the operating model:

Create a customer-renewal crew for this workspace. Propose the roles first.
It should prepare account context, identify renewal risk, draft next actions,
and keep a concise shared memory. Do not contact customers.

Decide what belongs in a Crew

Roles
Named responsibilities and the perspective each participant should bring.
Routines
Repeatable procedures for common jobs and handoffs.
Skills
Reusable instructions and supporting references for specialized work.
Shared memory
Context the roles need to coordinate consistently.

Use a Doc for general knowledge that many workflows or people should read. Use a Crew when the value comes from a repeatable team convention around that knowledge.

Configure Crew Variables

Select Variables from the Crew list or detail page. Each variable injected into a skill run can use a Crew-local value or reference a workspace Variable. Local values support production, staging, and dev resolution and may be masked as secrets.

  1. Choose Add variable and enter the uppercase variable key.
  2. Select a workspace global or a local value.
  3. For a local value, configure environment inheritance and mark secrets.
  4. Reveal only when necessary and remove bindings that the Crew no longer uses.

Run Crew skills

A role-scoped skill belongs to one role; a shared skill can be reused across roles and needs an explicit Crew when it should receive that Crew's variables. Connected AI clients can run skills through the hosted Crews tools. The CLI provides a separate local development and smoke-test path:

solidactions skill exec q-tool --target host --crew acme -- node scripts/q.js
solidactions skill pull q-tool ./q-tool
solidactions skill dev ./q-tool --crew acme -- node scripts/q.js
solidactions skill push ./q-tool
solidactions skill exec q-tool --target sandbox -- node scripts/q.js

skill exec runs the server-stored skill; skill dev runs the local working copy. The managed sandbox is Node 24 with Node, sh, and bash—do not assume Python or a native build toolchain is available. See the installed solidactions-crew-skills skill for the complete edit loop.

Keep outputs and state durable

Sandbox disk is scratch space and is deleted after extended idle time, a clear, or publish. Import human-facing outputs into workspace Docs, keep reusable binary references with the skill, and declare Crew- or workspace-scoped storage for machine state that must survive sandbox replacement. Persistent storage supports whole-file reads and writes, not append, in-place edits, or SQLite.

Publish and recover changes

Crew, role, and skill edits create revisions. Review the latest revision before promoting a snapshot, because a snapshot changes what other agents load; publishing a Crew also bakes its skill dependencies into the runtime image. Version history supports compare and additive rollback without erasing prior revisions. Crew entities and skill files are soft-deleted and may be restorable through authorized Crews tools until they are purged.

Change a Crew

Ask the AI to explain the current definition, name the requested change, and preserve everything outside that scope. Then inspect the Crew body in the app. This review loop is especially important when changing shared memory or a routine used by more than one role.

Permissions and sharing

Work Read views Crews in the app. Work Use can authorize the Crews MCP area and run permitted operations. Work Build is required to create or change Crew definitions and to manage Crew Variables. Crews are shared only with workspace members; there is no public or guest Crew link. Treat secret reveal as an exceptional Build-level action, and use API keys with the env:reveal ability only when a local run truly needs plaintext.

Do not confuse Crews with workflows

A Crew guides AI-assisted work. A workflow project deploys code that runs on a webhook, schedule, API call, or another workflow even when the AI client is offline. Use both when an AI-guided process should also hand a deterministic job to deployed automation.

Next: track durable outcomes on Pegboards.