---
summary: What ScaiCrew is and the problem it solves.
title: Overview
path: overview
status: published
---

# ScaiCrew

ScaiCrew lets a non-technical person **describe a job in plain language and get a crew member**:
an AI worker that is compiled into a [ScaiCore](/docs/scaicrew/architecture) program and run on sovereign
infrastructure, watched from a single mission-control view called **the Bridge**.

ScaiCrew is deliberately **not new infrastructure**. It is a thin control-plane and experience
layer over a fleet of pre-existing ScaiLabs services (inference, secrets, identity, sandboxing,
HITL, cost). The only genuinely new pieces are the crew-member object model, the conversational
authoring flow, the trigger/schedule surface, and the Bridge.

## A crew member, end to end

1. **Author** — describe the job conversationally (or from a template). ScaiCrew turns the whole
   conversation into a *crew-member version* draft.
2. **Publish** — the draft is compiled to a deterministic ScaiCore program, the member is given its
   own [identity](/docs/scaicrew/authentication/identities), and the version becomes active.
3. **Run** — a manual action, a [schedule, a webhook, or a handoff](/docs/scaicrew/triggers) invokes the member
   *as its own identity*. Steps stream to the [Bridge](/docs/scaicrew/the-bridge) live.
4. **Approve** — when the member is about to do something with external effect, it pauses for a
   human [approval](/docs/scaicrew/approvals); a decision resumes or stops the run.

## What's built today

The backend control plane is implemented through the run vertical, the v1 trigger set, the
conversational authoring orchestrator, the Bridge read models, and real ScaiKey **OIDC login**. The
Bridge frontend (SolidJS) covers Build (authoring) and Bridge (operations). See each section for
exactly what is live versus deferred — this documentation only describes what is implemented and
verified.