Shared workspaces for AI agents

A shared workspace for AI agents is a team-scoped environment where the tools, credentials, memory, runs, and policies that agents need are owned once by the workspace instead of being duplicated inside every agent. Harbor is one — a Cloudflare-native MCP control plane where a team installs MCP servers once, issues credentials once, and gets one audit trail across every coding assistant, support bot, or research agent docked to the plane. The rest of this post explains why per-agent toolboxes stop working at team scale and what actually has to live in the workspace instead.

Why per-agent toolboxes break at team scale

A single agent with its own bundle of tools is fine. The breakage starts when a second agent — and then a second person — needs to use the same tools. Credentials get copied into each agent’s config, which means revoking a token now requires finding every place it was pasted. Runs are siloed inside each agent process, so when one agent fails mid-task another agent cannot pick up where it left off and an on-call engineer cannot inspect what actually happened. Memory does not survive a process restart, let alone a handoff between agents. Audit is fragmented across local logs, vendor consoles, and shell history. Compounded across N agents and M tools, the bookkeeping cost grows like the product, not the sum — and most of it is invisible until something breaks or a security review asks who did what.

What lives in the workspace

A shared workspace is the answer to that bookkeeping problem. Five things move out of each agent and into one place the team controls.

Tools / MCP servers

Installed once per workspace, discoverable by every docked agent. The workspace keeps a registry of which MCP servers are enabled, which tools each exposes, and which version is installed. Adding a new tool flips it on for every agent without touching agent configs.

Credentials

Stored centrally as workspace-scoped credential state, with access mediated by the control plane. Agent code receives a tool handle instead of a raw provider token, and the workspace resolves the right credential at call time.

Memory

Workspace-scoped storage that survives across runs and agents. Harbor exposes this through orbit primitives — structured tables, key-value, blob storage, and a cache — so that one agent can write a fact and a different agent can read it tomorrow without a hand-rolled sync.

Runs

Exec paths and runtime tool calls produce traced run records at the workspace level where applicable. The history is shared across agents, not buried in per-agent logs, which is what makes “why did the support bot do that?” an answerable question.

Policies

Role-based access, tool policy, and audit settings are centered on the workspace. New agents inherit workspace policy on dock; departing teammates lose workspace access in one revocation.

Workspace ≠ user account

It is worth being precise about the unit of ownership. Many agent platforms bind tools and OAuth grants to an individual user identity, which works until the team has more than one person. A shared workspace is team-scoped: tenancy belongs to the workspace, not to whichever human happens to be logged in. Agents authenticate as agents, not as a developer who once wired up Slack on their laptop. That distinction is what makes the workspace survive offboarding, lets two teammates dock different agents against the same Linear connection, and gives the security team one tenant boundary to draw policies around instead of a sprawl of personal OAuth catalogues.

How Harbor implements it

Harbor splits the implementation across three product surfaces: a web dashboard (tryharbor.ai) where admins create workspaces, install MCP servers, configure shared OAuth clients, and review runs; a multi-tenant API and runtime on Cloudflare Workers, D1, KV-backed credential storage, and R2 that owns discovery, authorization, sandboxed execution, and audit; and client adapters — including the hrbr CLI and the local MCP stdio adapter — that let any MCP-speaking agent dock to the same workspace. The execution layer runs submitted code in an isolated sandbox and exposes orbit primitives (storage, cache, db, ai, tools, jobs) so agents can persist state, invoke reusable jobs, and call other workspace tools without re-implementing infrastructure. Every layer is workspace-scoped: the same code running for a different workspace sees a different registry, a different secret store, a different run history.

When you don’t need one

A shared workspace is the wrong shape for a single developer wiring one MCP server into one local agent for personal use. Run the MCP server directly, point the agent at it, and skip the platform. The workspace model starts paying for itself when there is more than one agent, more than one human, more than one credential to rotate, or any requirement to audit what happened after the fact. If your situation does not match that — or if you want to see how Harbor stacks up against per-user OAuth catalogues and other agent-tooling vendors — /compare has the breakdown.

If your team has crossed that line — multiple agents, multiple tools, real users, and a need to know what every agent did with every credential — connect a workspace to install your first MCP server and dock an agent against it. The Workspaces doc covers the tenancy model in full, and the Orbit runtime doc enumerates the primitives agents get inside the workspace.