01
One intelligence in charge
Crew owns the conversation, identity, memory, permissions, and orchestration while the CLI models underneath remain replaceable workers.
Product architecture case study · 2026
Crew Desktop
Why we built a command center for a fleet of local and remote agents.
Agents became capable of doing real work in parallel. The missing layer was a place to manage them: where they run, what they know, who is listening, what they are allowed to do, and how their work moves forward.
Agent operationsLocal + remote workersSpatial workspaceDurable memory
The design problem: a workforce of agents without a shared operating environment.
The reason Crew exists
The bottleneck moved from model capability to human coordination.
Teams stopped using AI only to autocomplete and started using it to do the work: one agent writing a migration, another chasing a flaky test, and a third drafting release notes. The work became parallel before the tools for managing it did.
Without a shared command center, the operator is forced to juggle terminal tabs, copy context between agents, remember what is running on which machine, and reconstruct the state of a project after a session ends.
The product thesis
A workforce needs a workplace: one durable layer for direction, memory, visibility, and control across every agent.
What Crew changes
From operating terminals to managing a workforce.
Crew gives the operator one persistent relationship while keeping the workers replaceable. It turns a collection of capable but disconnected processes into a coordinated system.
02
A room for every project
Canvases preserve working directories, agent windows, artifacts, layouts, and project context so parallel work stays spatially legible.
03
Memory that survives
A durable ledger and linked wiki carry forward decisions, findings, approvals, and provenance instead of resetting at the end of a session.
04
Control at the action layer
Permissions, budgets, schedules, approvals, and audit trails travel with the work across local and remote workers.
The operating model
Crew leads. Agents execute. The operator decides.
Unaddressed goals go to Crew by default. Crew can answer, use a tool, delegate to the right worker, or ask for approval. When judgment or precision matters, the operator can address any live terminal directly.
Crew-led mode
Set the goal, then manage by exception.
Crew selects a worker by capability, cost, privacy, and location; normalizes the result into one reply; and applies memory, permissions, budgets, and approval rules automatically.
Direct agent mode
Keep byte-for-byte control when you need it.
Click any window, address an agent by name, or pin a direct target. Crew makes who is listening visible without rewriting, delaying, or pretending to undo a raw terminal command.
Every input surface shows whether Crew, a named agent, or a shell is listening before the operator sends it.
Local and remote by design
Where an agent runs becomes an implementation detail.
A local PTY, a Mac Studio, a GPU box, a VPS, or Crew Cloud can all appear as the same kind of worker in the desktop. The workspace stays constant while compute moves to wherever the job requires it.
Local agents
Real terminals, not simulations.
Any installed CLI can run as a genuine subprocess on a real PTY, with its native stream, colors, cursor behavior, and permission mode intact.
Remote workers
The same desktop, more compute.
Persistent tmux and node-pty sessions, outbound secure connections, and a token-gated tunnel let workers survive disconnects without exposing inbound ports.
Shared governance
One ceiling for every machine.
Tenant, workspace, runtime, permission level, cost, time, iterations, and parallel-worker limits bound every task before it starts.
Architecture as a product decision
Every surface feeds one Crew Runtime.
Voice, canvases, gateways, local agents, remote workers, memory, scheduling, permissions, and budgets are coordinated through one persistent runtime. That shared layer is what makes a fleet operable.
The architecture closes the loop between operator surfaces, the Crew Runtime, and local or remote workers.
The workspace remembers
A fleet is only useful when its learning compounds.
Individual agents are brilliant and amnesiac. Crew captures working, procedural, semantic, and episodic memory at the right scope, records the decisions that produced it, and feeds verified findings into the next worker’s context.
What changed for the operator
The result is not another agent. It is a better operating model for agents.
Before CrewWith Crew
Terminal tabs and alt-tab coordination.Canvases, focus rails, and live status make the fleet visible in one glance.
Context is copied manually and disappears with the session.Durable memory, a ledger, and a linked wiki carry learning forward.
The operator must choose the next worker every time.Crew routes by capability, cost, privacy, and location, with direct mode always available.
Local and remote execution are separate workflows.Workers appear in the same desktop and follow the same governance ceiling.
The next operating layer
Chat gave us a coworker. A workforce needs a place to work.
Crew Desktop is our answer to the coordination problem: one command center for directing, remembering, governing, and scaling a fleet of agents wherever they run.