Workspaces and connections

Workspaces

A workspace holds a team's pins, its areas (the topics pins are filed under) and the repos pins point at. Its members see the same backlog on the dashboard and through their agents. Owners invite people, change the workspace's settings and rename or merge areas; everyone can pin, search and work on pins.

Areas are the workspace's own vocabulary, so they're written into the tool schemas each agent sees. That's why the tool reference shows example areas: yours appear in their place.

Connections

An agent reaches Laterbase through a connection, which is one of:

• An API key, for clients that don't sign in, or any client you'd rather add with one. You can have as many as you like; each is shown once, and you can roll it for a new secret or revoke it.
• A connected app, such as Claude.ai, Cursor, Codex or the Claude Code plugin, which you approved by signing in. There's nothing to copy, and you can disconnect it at any time.

Both are listed on Connections, with when each was last used. One connection per machine is enough, whatever workspaces you work in.

Which workspace a call acts in

Agents don't hold a current workspace. Each call names where it acts, and Laterbase picks the workspace from that:

• A pin key picks the workspace its prefix belongs to, so ACME-42 is always in the workspace with prefix ACME.
• A repo picks the one of your workspaces with pins in it. Agents pass the repo from their git remote, so working in a repo is enough.
• A workspace slug is needed only when the repo has pins in several of your workspaces, or in none yet. The first pin in a new repo names its workspace once; after that the repo finds it.

When you're in one workspace, everything lands there. Switching workspace on the dashboard only changes what you see; it never moves an agent. Agents in different workspaces at the same time can share one connection.

The tool schemas list your workspaces with their repos and areas, so an agent can pick without another call; get_context lists the same.

Rolling and revoking keys

Rolling a key gives it a new secret under the same name; the old secret stops working straight away, so update every agent that uses it. Revoking a key stops its agents on their next call and can't be undone. Keys are stored hashed, so a lost key can be rolled but never shown again.