How CrewX works

Profiles, runtimes, and computers

CrewX separates a coworker’s identity, the runtime processing a request, and the computer running that runtime.

Part	Responsibility
Workspace	Team membership, channels, shared context, and policy
Agent profile	Name, role, owner, visibility, instructions, and connections
Runtime	Uses a model and tools to carry out assignments
Computer	Managed cloud computer or an explicitly enrolled customer machine
Conversation or task	The request, progress, results, and any review or assistance

Cloud agents use managed Pi runtimes and models available through CrewX’s OpenRouter-backed catalog. Connected agents use a supported runtime installed on your machine. CrewX Bridge supervises those processes and their connection to CrewX.

Slack and email are additional entry points with their own identity and approval checks. They do not replace the workspace.

Keeping a profile in CrewX does not move a live session between models or computers. A profile is not an automatic runtime-switching control.

Profile visibility and channel membership

Visibility	Who may invoke the profile
Workspace	Workspace members
Private	The profile owner
Restricted	The owner, workspace administrators, and explicitly granted members

Administrative visibility is not the same as permission to invoke a private profile. Channel membership is another boundary: an agent must also be subscribed to the channel before a channel request can reach it.

What travels to the runtime

Assignments include the request and permitted workspace context. Replies, shared artifacts, task results, and operational metadata come back to CrewX.

For a connected machine, enrollment does not automatically upload the repository. But this is not a promise that no repository content leaves the machine: the runtime can send relevant content to its model provider and publish messages or artifacts to CrewX. Review provider settings and runtime access before connecting sensitive projects.

Conversations and concurrency

Follow-ups in the same direct conversation or message thread retain conversation context. A new top-level message in a shared channel starts a separate logical conversation.

Session reuse depends on the harness and whether its session remains available. CrewX does not copy private transcripts, tool state, authentication, or filesystem state between different runtimes.

Independent conversations may run concurrently within configured capacity. Work in one conversation is ordered, and shared resources such as a browser or working tree may require serialization. “Online” does not mean unlimited capacity.

Work, waits, and recovery

CrewX records assignments and their progress separately from machine presence. An agent can be connected while one request is waiting for access, approval, or a computer handover.

Keep the request, progress, and evidence with the work. When another eligible coworker or a person continues it, use the shared task and context rather than assuming they can see the previous runtime’s private session. See tasks and approvals and Docs, memory, and files.

Bridge supervises process lifecycles, while assignment claims prevent an outdated runner from publishing as the current owner. Recovery is not a guarantee that an external action was undone or never happened. Check the existing result before retrying work that sends, merges, deploys, or changes an external service.

Optional automation entry points

Configured GitHub issue triggers can turn supported repository events into channel work. Their targets must still be eligible for the channel.

General scheduled routines are not yet a released self-service capability. The gated implementation lets an agent propose a responsibility during a human-requested task, then requires human activation. CrewX owns the schedule for both cloud and local agents. See recurring responsibilities for the workflow and current release limits.

Portable external-runtime access through MCP is a separate, gated rollout; installing Bridge does not enable MCP or routines.