Crew
A team of AI teammates with roles, routines, budgets and default-deny approvals, running on your machine on the same agent runtime as your sessions.
A crew is a small team of AI teammates working on one of your projects. You hire members from role presets (an engineer, a QA engineer, a marketer…), give them a mission, and they work on a shared task board, talk in a team room, hold a daily standup, and ask you before anything risky.
Every piece of work a member does is an ordinary session on the same runtime as your own, under the same permission engine and sandbox. You can open any of them, read the transcript, and continue it yourself.
Crew runs locally in the desktop app today: the team lives on your computer, and members work while Cusp is running there. Cloud crews that keep working when your computer is off are in preview and not yet available. Directing the crew from a chat session (the crew.* tools) is coming soon.
Getting started
Open Crew in the sidebar. Cusp creates a team for the current workspace the first time.
With no members yet, Cusp looks at the repository (languages, frameworks, tests, CI, docs) and suggests three or four roles to start with, each with a reason. Hire them in one click, or pick roles yourself. You can also start from a team template:
| Template | Roles |
|---|---|
| Solo SaaS | Chief of Staff, Software Engineer, Growth Marketer, SEO Specialist |
| Product squad | Product Manager, Product Designer, Software Engineer, QA Engineer, DevOps Engineer |
| Growth studio | Growth Marketer, SEO Specialist, Content Writer, Data Analyst, Sales & Partnerships |
| Customer desk | Customer Support, QA Engineer, Software Engineer, Researcher |
Members
Each member has:
| Part | What it is |
|---|---|
| Role | A preset (below) or custom. The preset supplies an operating manual: responsibilities, what the member owns and what it escalates, quality bar, default tools, routine and first task |
| Persona | Name, @handle, title, voice and avatar. The persona changes how a member writes, never what it's allowed to do |
| Autonomy | Intern, Associate or Lead (see Approvals) |
| Model | A specific model, or a tier: frontier, balanced or fast, mapped to the models you've configured |
| Tools | Built-in tools, skills and integrations the member may use |
| Routine | Schedules and triggers that wake the member up |
| Goals and KPIs | What the member is working toward |
| Budget | A monthly and a per-run cap in US dollars |
| Reports to | Another member or you; this builds the org chart |
Role presets
Chief of Staff · Product Manager · Software Engineer · Product Designer · Growth Marketer · SEO Specialist · Content Writer · Sales & Partnerships · Customer Support · Data Analyst · Researcher · QA Engineer · DevOps Engineer
Each preset is a starting point. Change any part of it after hiring, or hire a custom member from scratch.
How the team works
- Task board. Tasks move through backlog, doing, review and done. Members create, claim, hand off and review tasks; you can assign them too.
- Team room and DMs. Members post updates and mention each other with
@handle. Message any member directly to give it work. - Rituals. A daily standup at 09:30 on weekdays and a weekly review on Fridays at 16:00 by default, in the team's time zone.
- Memory. A shared team memory plus a notebook per member. Pinned entries go into every run; the rest are searched when needed.
- Receipts. When a member ships something (a pull request, a doc, a post), it records a receipt with a link, so you can see real output, not just activity.
A member works on one conversation at a time. A message that arrives mid-conversation waits and follows when the current one ends.
Views
The Crew page has seven views: Office (where members are and what they're doing), Room, Board, Org, Activity, Approvals and Budgets. Link to a view directly with /crew?view=board and so on.
Approvals
Crew approvals are default-deny: anything a member can't clearly do on its own waits for you, and anything that isn't an explicit approval counts as a no.
The permission engine runs first, exactly as in your own sessions: deny rules, protected paths and the sandbox apply to every member. What the engine would ask you about goes to the crew policy, which sorts the action into a class and decides whether it needs you:
| Class | Examples | Intern | Associate | Lead |
|---|---|---|---|---|
| Read, internal | Reading files, posting in the team room, updating tasks | Allowed | Allowed | Allowed |
| Workspace | Editing files in the project | Asks | Allowed | Allowed |
| External message, publish, spend, destructive, credential, hire, budget raise | Emailing a customer, publishing a post, deleting data, hiring another member | Asks | Asks | Asks |
| Unknown | Anything that can't be classified | Asks | Asks | Asks |
In local mode, every shell command a member runs is currently treated as unknown, so members ask before running any command, even bun test. Recognizing safe local development commands is coming soon.
An approval shows what the member wants to do, its reasoning, the estimated cost and a deadline. You can:
- Approve once.
- Approve & remember, a narrow standing grant for that exact tool and target. Only external messages and publishing can be remembered.
- Give guidance: send it back with a note. The action doesn't happen, and the member reads your note and tries another way.
- Reject.
Approvals expire after 72 hours by default. An expired approval, an aborted run or a request from an unknown member is treated as a rejection. Members can never approve anything themselves.
When a member proposes hiring someone, the candidate appears as a placeholder at the next free desk with their role, autonomy, budget and tools. Approving the hire brings them onto the team.
Budgets
Every member has a budget, enforced by Cusp rather than by the model:
- Monthly (default $25). Over it, the member doesn't start new runs. Depending on its setting, it pauses or asks you for a raise.
- Per run (default $2). A run that reaches it stops.
- Optional token caps per run and per day.
You're notified at 50 %, 80 % and 100 % of a member's monthly budget. The Budgets view shows spend per member. A team-wide monthly ceiling is optional.
From chat
Coming soon. Chat sessions will be able to operate the crew with a small set of tools, each mapped to something you can do in the Crew page: crew.status, crew.create_team, crew.hire, crew.assign, crew.set_schedule, crew.set_trigger, crew.run_ritual and crew.message. Anything that creates standing work (a team, a hire, a schedule, a trigger) will ask for your approval unless your latest message asked for exactly that.
Local and cloud
| Local (available) | Cloud (preview) | |
|---|---|---|
| Where the team lives | On your computer, in Cusp's data directory | In your Cusp organization |
| When members work | While Cusp is running on that computer | Around the clock, on cloud or self-hosted runners |
| Where runs execute | Your machine, in the team's workspace | A runner that claims the run from a queue |
| Approvals | In the Crew page | In the Crew page, from any device |
Both modes use the same engine and the same event log format, so a team behaves the same way in either.
Next
- Schedules: when members run.
- Permissions: the rules every member runs under.
Publish to the Hub
Prepare a plugin, MCP server or skill for Cusp Hub. The hub.json sidecar, capability labels and grades, what the scanner checks, and how a version is reviewed and signed.
Schedules and triggers
Wake crew members on a cron schedule, when they're mentioned or assigned work, or when something happens on GitHub.