The hardest problem in multi-agent teams is scoping

The hardest problem in a team that runs several agents is scoping: deciding who may touch what, on whose behalf, with what budget, and with what record. Model quality stopped being the blocker a while ago. The blocker is that an agent is a process, and a bare process has either every credential on the machine or none.

Why does scoping get hard past one person?

One person with one agent can get by on pasted tokens. The token is theirs, the laptop is theirs, the consequences are theirs. The moment a second person and a second agent arrive, every question splits. Whose Slack does the bot post from? Can the intern's Codex read the finance Notion? Who pays for the research agent's web searches? When something goes wrong at 2 a.m., which record says what happened and under which name?

The usual answers are per-client config files, a shared service account whose password lives in a wiki, and a hope that nobody pastes a production token into the wrong agent. Each of those works for exactly one laptop. None of them scale to a team, because they all put scope in the wrong place: in the agent, in the client, or in a person's head.

What is the unit of ownership?

An operating system makes two commitments. It owns the resources, and it mediates every privileged operation. Programs do not manage the hardware; they make system calls. Our founders wrote that agents deserve the same contract in a letter from our founders, and scoping is where the contract gets concrete.

On CoreSpeed the unit of ownership is the organization. Grants to apps, memory, budgets, the approval policy and the audit trail live in the org, not in any one agent and not in any one client. An agent signs in and asks for an action. The org decides whether that caller, with that credential, may perform that action through that account, and writes down what happened. Replace the agent and the scope stays. Replace the client and the scope stays.

Each of the four scoping questions then has one home:

Who is acting?

Every request resolves to one principal in one organization. There are two kinds. A member is a person, reached through browser sign-in, a session JWT or an sk-cs- key that acts as that person. An agent is the org's own principal kind, with an id of its own and an sk-csa- key. Any member can create one and becomes its owner.

Ownership is accountability, not permission. The owner answers for the agent and may suspend or retire it. The agent inherits neither the owner's connections nor the owner's role. That split is the whole point: you can give a bot a name and a person who answers for it without giving it that person's reach. The header is the same for all four credentials:

{ "headers": { "Authorization": "Bearer sk-csa-..." } }

Which credential sits behind that header decides everything that follows. The authentication page lists the four and what each reaches.

On whose behalf?

Every connection is private, visible only to the member who connected it and their clients, or shared with the whole organization. Any member can connect either kind. A member's agents reach both; an agent principal reaches shared connections only, never a member's private ones. Where a vendor can install CoreSpeed's app as its own actor, as with a Slack workspace bot or Linear's app under the alias corespeed-bot, the connection is an organization integration that only an org admin makes, and actions through it are attributed to the app.

Memory follows the same line. Each write is scope: "private" by default or scope: "shared" on request. The caller's identity comes from the credential, never from the request body, and the boundary is enforced in the database by row-level security rather than only in application code. A teammate's agent cannot read your private memory by naming your user id.

With what budget, under which rules, with what record?

Budget has two boundaries. The org wallet stops every metered call past its threshold, and a monthly cap on an API key stops that one key. Caps are checked at the request boundary, so they bound what starts.

Rules have a ceiling. An org admin writes the approval policy in plain English. A member may add text that makes things stricter for their own calls, never looser. Reads are never gated; writes are judged; the actions the policy names pause for a person, and on the default Balanced setting an ordinary unmentioned write runs. The gate sits in front of the tools, so one rulebook covers every agent and every client on the team, for calls made through CoreSpeed. The approvals page has the verdicts and defaults.

Record is one trail. Every call lands in Dashboard → Activity with its actor, its outcome and, when a charge exists, the charge the ledger recorded. API-key activity is attributed through the key's owning identity, so a bot's work shows up under the bot, and the bot's owner is one lookup away. Members see their own actions; admins see the org.

With scope in the org, adding an agent becomes a scoping decision instead of a credential hunt: create the identity, mint a key with a cap, decide which shared connections it may use, and let the policy and the trail do the rest. Removing one is a suspend or a retire. Changing a person's reach is a connection shared or made private. None of it touches a client config, and none of it depends on a person remembering where a token went.

FAQ

Is an agent key just a service account? It is closer to a named process with an owner. It has its own identity and attribution, reaches shared connections only, and can be suspended without touching its keys.

Can a member widen their own permissions by adding policy text? No. Member text can only make things stricter for that member's own calls. The org policy is the ceiling.

Does the org see calls my agent makes through other MCP servers? No. The policy, the budget and the trail cover calls made through CoreSpeed only.

Where does scope live if I switch from Claude Code to Codex? In the organization. Connections, memory, caps and policy are the same for both clients because neither one owns them.