Workspaces & participants

A workspace is the second conversation shape in Frontier, next to tasks. Where a task is one prompt routed to whichever agent scores highest, a workspace is one repository, one long-lived thread, and the agents you invite into it — each with a name, a role, and an @handle. You address them explicitly; nothing is routed on your behalf.

Create a workspace

1. Point it at a repository

   Open Workspaces in the dock, choose ＋, and give the workspace a name and a folder. Every participant works in that folder.

2. Add participants

   Each participant has a display name, a unique @handle, a free-text role such as "Backend reviewer" or "Docs", the agent it runs on, an optional model for that agent, an avatar colour, and its capabilities. You are in the roster too, as @you.

3. Talk to them

   Type in the composer and press @ to autocomplete a handle. Only the participants you mention run — the rest of the roster just watches the thread.

Mentions are the only way work starts

• No mention, no run. The message is logged and nobody is spawned.
• Every mentioned participant starts at once, and each sees the same thread up to your message — never each other's replies. Their answers land in the thread as they finish.
• Mentions inside code are examples, not addresses. A handle in a fenced or inline code span never dispatches anyone.
• An agent's own @mention starts nothing. It renders as a chip. Agent-to-agent conversation needs a turn budget and a stop condition, so it is deliberately not shipped.
• An unreachable handle is answered, not ignored. A participant that is disabled, whose agent is turned off, whose CLI is not detected, or that is cooling down after a usage limit produces a system message in the thread naming the reason.

Capabilities and review branches

A participant marked edit-files runs in its own git worktree off HEAD on a branch named frontier/ws-<workspace>/<seq>-<handle>, commits its changes there, and the worktree is torn down. The reply carries a branch chip that opens the branch straight in the Review screen, where you can diff, merge, or delete it under the same safety rules as delegated and benched work. Participants without the capability run in the workspace folder itself.

If an isolated branch genuinely cannot be created, the turn fails rather than quietly writing to your working tree — the interface promised isolation, so a silent fallback would be a broken promise. Retrying a reply gets its own branch, so the original stays intact for comparison.

What each participant is told

Every turn is built a fresh prompt — no CLI session is resumed, because a private session would diverge from the shared thread the moment another participant speaks. The prompt contains:

• Your Frontier memory block, as persistent context.
• The workspace name, repository path, and the full roster with each participant's role.
• The thread up to your message, attributed as [@handle · role], trimmed from the oldest end against a token budget — your triggering message is always kept, and an omission is marked.
• A closing instruction: you are @handle, reply in your own voice, answer only what you were asked because others were addressed separately, and don't roleplay as anyone else.

Your Context & Tools profile and enabled skills apply to workspace turns exactly as they do to tasks, resolved against the workspace folder. Per-participant MCP servers and skill sets are not supported.

Running, cancelling, retrying

Workspace turns share the same per-provider concurrency limits as tasks — a workspace turn and a task compete for one slot rather than each getting a private pool. A turn whose agent is busy waits for a slot instead of failing. Each reply streams live with its model badge, tool-call activity, and the files it touched, and can be cancelled while it runs or retried afterwards. A retry appends a new turn; the failed or cancelled original stays visible.

Deliberately not in this version

The full reasoning, including the alternatives that were rejected, is recorded in ADR 0001.