Introducing Helix Workspaces: Shared Context, Clear Ownership

Helix Workspaces give a team one permissioned place for its repository graphs, Ask history, Pulse insights, review reports, and saved evidence. Team and Scale customers can invite members by email, switch between workspaces, and remove access without mixing one organization's engineering context with another.

Engineering intelligence becomes more valuable when the people making a decision can inspect the same evidence. Workspaces turn that shared context into a product boundary rather than a collection of screenshots and copied links.

One graph context for the team

Every indexed repository belongs to the active workspace. The same boundary applies to saved Ask Helix conversations, Pulse digests, evidence, and review reports. When a member switches workspaces, Helix switches the context behind every product surface.

That keeps a personal exploration separate from a customer's repository and keeps two company workspaces from sharing results accidentally.

Minimal roles, explicit control

We intentionally started with two roles:

• Owner manages invitations, membership, workspace settings, and billing-sensitive actions.
• Member uses the workspace's graphs, evidence, Pulse, Ask Helix, and Review.

The role model is small enough to understand at a glance. Owners can add or edit access in Settings → Workspace access or use the member control beside the workspace switcher in the navigation.

Branded email invitations

An owner enters an email address and Helix sends a branded invitation linked to that workspace. The recipient joins by signing in with the invited email address, preventing an invitation from being claimed by a different account.

Delivery state stays visible as queued, sent, or failed. A failed email can be resent without losing the pending invitation. Owners can also cancel an invitation before it is accepted.

Removing a member

Owners can remove a member from Workspace access. Removal revokes that person's membership in the selected workspace; it does not delete the person's account or affect their access to other workspaces.

Helix protects the ownership boundary as well: a member cannot remove other members or perform owner-only settings actions.

Why shared context matters

Consider a pull request that crosses a sensitive ownership boundary. A reviewer can open the same report, follow the cited paths and pull requests, and ask a follow-up question against the same graph. The engineering manager sees the related bus-factor signal in Pulse. The evidence survives the meeting and remains available to the next person.

That is a stronger collaboration model than sending an AI answer with no source context.

Available on Team and Scale

Shared workspaces and member invitations are available on Team and Scale plans. Explorer remains a personal workspace for evaluating Helix on a repository. See plans and limits, or open Helix and use the workspace menu to manage access.

This release lays the foundation for collaborative engineering intelligence while keeping the first version focused: shared evidence, clear roles, and controlled membership.