Skip to main content

What would I use Crewship for?

The useful question is not whether an agent can do a task once. It is whether the task has a repeatable trigger, a bounded workspace, an observable result, and a clear owner for exceptions.

Continuous dependency upgrades

Problem: upgrades are easy to postpone, but a backlog of small changes becomes a risky batch. Crew actually does: a maintenance agent reads the repository’s lockfiles and contribution rules, changes one dependency band at a time, runs the project’s checks, and leaves a bounded issue when a major version needs a human decision. A routine provides the recurring trigger; the issue and Journal provide the handoff. Cost: model calls plus the crew container for each bounded run, with repository CI and human review still required. Start with: routine scheduling and crewship routine list using the routine CLI reference.

Incident triage

Problem: the first responder needs a timeline, related issues, and a safe next action before changing production. Crew actually does: a lead assigns a triage agent to collect the incident’s issue, recent Journal events, deploy identifiers, and known runbooks; the agent produces a hypothesis with evidence and opens a waitpoint before any destructive action. Cost: one or more model runs per incident and operator review time; the result is an evidence pack, not an incident command system or an automatic production fix. Start with: crewship journal --crew docs-lab --lines 20 and Harbormaster approvals.

PR review that actually runs the code

Problem: a static review can miss a failing test or a changed contract. Crew actually does: a review agent checks the diff, runs the relevant suite in its crew workspace, compares the result with the task’s acceptance criteria, and reports file/line findings with the command that reproduced them. Cost: model tokens and crew/CI time; it complements required human review and branch protection rather than replacing either. Start with: crewship ask --agent writer "Create /crew/shared/hello.txt containing exactly: hello from Crewship" as the harness-verified task shape, then adapt the prompt to the pull request using the good review examples.

Secret-aware integration work

Problem: an agent needs an API or Git credential, but copying it into a prompt or repository creates an avoidable exposure. Crew actually does: an operator creates a named credential, binds it to the agent’s environment slot, and lets the sidecar deliver it only while the run needs it; Keeper can turn an unusual request into a human escalation. The agent receives a capability, not the stored value through the CLI listing. Cost: credential-provider setup, model-run cost, and possible approval latency; Crewship does not remove provider quotas or your data-classification obligations. Start with: crewship credential create --name demo-token --type API_KEY --value local-demo-value and crewship credential assign demo-token writer --env-var-name DEMO_TOKEN, then read Credentials.

Recurring data or content normalization

Problem: the same deterministic cleanup must happen on a schedule, but exceptions still need a trace. Crew actually does: a routine runs a script or agent step against a bounded input, writes the result to crew-shared storage, and leaves run status and step events in the Journal; a later run can use durable state instead of pretending every run is the first. Cost: scheduled model or script execution and storage. If the transform has no judgment or exception handling, a plain data pipeline is cheaper and clearer. Start with: routine scripts and schedules and crewship routine list.

Repository onboarding and documentation

Problem: a new codebase has useful conventions scattered across files and history. Crew actually does: one agent inventories entry points and tests, a lead challenges unsupported assumptions, and the crew stores a reviewed brief in shared memory before turning unknowns into issues. Cost: an initial exploration run, container time, and review time; memory is a working context, not authoritative source documentation. Start with: crewship crew create --name "Docs Lab" --slug docs-lab, crewship agent create --name "Writer" --slug writer --crew docs-lab --role AGENT --memory, and First projects.

Human-gated change workflows

Problem: an automated workflow should prepare a change but pause before a destructive or externally visible step. Crew actually does: an agent prepares the diff or action plan, the routine enters a durable waitpoint with its run context, and Harbormaster records approve, reject, or timeout before the run resumes or stops. Cost: the run plus operator decision time; if every step needs a person, a conventional ticket workflow may be simpler. Start with: the waitpoint API and orchestration guide. The common shape is bounded work plus a durable handoff. If the result cannot be checked, the exception cannot be owned, or the required capability cannot be scoped to a crew, choose a simpler tool or read When not to use Crewship.