Teams & Workspaces

FreeRide works for a team the same way it works for you alone — except the brain is shared. This page explains the model, the flows, and the rules. Five minutes and you'll know everything.

The mental model

A workspace is the room. Projects are things in the room. Everyone in the room sees everything in it.

That's the whole model. There are no per-project permissions, no access requests, no "share this with…" dialogs. If you're in the workspace, you — and your AI agent — see every project in it: every decision, doc, session, and idea. That's deliberate: the value of a shared brain is that nothing is hidden by default. A new teammate's agent is productive on day one because it already knows every decision the team ever made.

Anything you want to keep to yourself simply stays a personal project — projects outside the workspace are visible only to you.

Two ways to start

Team-first (most companies): On the All projects page, hit New workspace, name it after your team or company ("Acme Engineering" — not after a single project), and invite people right away. Projects come after — create them directly into the workspace, or members bring their own.

Solo-first (how most people arrive): You've been using FreeRide alone and want to share a project. Open the project's Team page, create a workspace, and the project moves in. Inviting a teammate to the workspace gives them that project — and everything else you add later.

Invites — how joining works

An admin invites by email, choosing a role (member or admin).
No email is sent. The invite appears the moment that person signs in to freeride.dev with the invited address — as a banner on their projects page with one button: Join workspace.
Joining is instant: the workspace's projects appear in their list. If a project's repo already has the .freeride.json file the owner committed, a teammate installs the FreeRide plugin, pulls the repo, and signs in the first time their agent connects. No setup needed. Linking a new repo of their own works the same as solo: /freeride:setup once. (Repos on the older CLI setup carry a committed .mcp.json instead, which works the same way.)
Pending invites show in the roster with an "Invited" tag; admins can revoke them anytime.
You can see who's actually set up: the workspace roster marks each member as connected once their agent's first session lands. Until then, a member browsing the dashboard sees a quiet banner pointing at the setup.

Roles — who can do what

There are exactly two roles. We kept it simple on purpose.

	Member	Admin
See and work on every workspace project (agent included)	✅	✅
Create projects in the workspace, or move their own in	✅	✅
Capture decisions, docs, ideas — the daily work	✅	✅
Invite people, revoke invites, remove members, change roles	—	✅
Rename or delete the workspace	—	✅
Delete or rename a project	only their own	✅ any
Leave the workspace	✅	✅ (unless they're the last admin)

Two rules behind the table:

Creating and editing are open; deleting is not. Anyone can add to the shared brain and agents routinely update each other's docs — that's the point. But deleting a decision, doc, or idea is limited to the person who created it, the project's owner, or an admin.
A workspace can never lose its last admin. Promote someone else before stepping down or leaving.

There's no read-only "viewer" role or external "guest" access yet — if your team needs one, tell us.

What your agent does differently on a team project

Nothing changes in how you work — your agent picks up team awareness automatically:

It knows who's around. "Maria's agent was active on Authentication 12 minutes ago" — only shown when genuinely recent, never as stale noise.
It catches you up. Starting a session after time away, your agent gets exactly what teammates did since your last session — completions and decisions, with names.
It welcomes newcomers. A member's first session on a shared project is framed as an introduction: here's what this team has built and decided — read before changing things.
It avoids collisions. When your agent starts work on a feature a teammate touched minutes ago, it's told — as awareness, never a lock. Nobody is ever blocked.
Everything is signed. Decisions, docs, and ideas show who made them — in the dashboard and in what agents read. Context, not surveillance.

Solo projects are completely unaffected: if a project has one person, none of this appears.

Ideas, assignment, and what's yours

Ideas on a team project work like a shared pool with personal queues on top:

Ideas are born unassigned. Captured mid-session by any agent, they land in the team pool, visible to everyone.
Assignment is always explicit. Hand an idea to someone from the idea's panel in the dashboard, or tell your agent — "assign this to Maria", "put that on my plate". Agents never assign on their own, and never guess.
Assignment overrides authorship. An idea you captured but handed to a teammate leaves your queue and enters theirs. It stays visible to the whole room — the agenda is shared; the queue is personal.
Your agent knows what's yours. At session start, items assigned to you (or captured by you and not assigned away) come first — the same order the dashboard shows you.

Common questions

Can I be in more than one workspace? Yes — your client's workspace, your own lab, and personal projects all coexist under one account. The projects page shows each as its own section.

Can a project be in two workspaces? No. A project lives in exactly one room (or none — personal). If two groups need it, they belong in one workspace.

Can I move a project back out of a workspace? Not from the UI yet — contact us. Moving in always asks for confirmation, because it makes the project visible to the whole room.

Do ideas replace our ticket tool (Linear, Jira)? No — they sit underneath it. Ideas are thoughts your agents catch the moment they happen, mid-session, so they don't die as TODO comments and Slack messages-to-self. Tickets are work you've committed to schedule. The split: features organize what the team knows, ideas catch what the team must not forget, your ticket tool tracks what you've committed to. An idea that matures becomes a ticket — or just gets done next session. (Small teams often find ideas + priorities are all the process they need.) Deliberately, ideas have no due dates and never will — an idea with a deadline is a task, and we un-tasked.

Why are a teammate's open ideas useful to me? They're transferable intent. Covering for someone? Their open ideas on the project are the handover document — not what they did (completions show that), but what they meant to do next.

Who pays? Team billing is per-seat and coming; early teams ride free while we build with them.

What does my team NOT see? Your personal projects, your account details, and anything in other workspaces. Membership shares project knowledge — nothing else.

Under the hood

For the curious (none of this is needed to use teams):

Access is enforced in the database (Postgres row-level security), not in the app — workspace membership grants project visibility at the lowest layer, and agents inherit it because they authenticate as their human (OAuth). There is no separate agent identity or permission system.
Team features activate per-project when a second active member exists; a workspace of one behaves exactly like solo — nothing team-related appears anywhere.
Presence is derived from recent agent activity (≈30-minute window, aggregated per person), not from open sessions — sessions can idle for hours and would be misleading.
Deletion rules live in the database too: content is removable by its author, the project owner, or a workspace admin; project delete/rename by owner or admin.

Quickstart → — install the plugin and link a repo
Dashboard Guide → — where the team's work surfaces
How It Works → — the session flow underneath it all