One org, many agents: Claude Code, Codex and a bot on one rulebook
How a team keeps each member's own client, shares app connections, runs one approval policy and one ledger, and gives bots an identity of their own.
One organization can serve every agent on a team. Each member keeps the client they prefer, Claude Code, Codex, Cursor or claude.ai, and signs in to the same MCP server. Connections, memory, policy, budgets and the activity trail belong to the organization, so the rules are the same whichever agent makes the call.
Every team member, bot and action in this post is a fictional example. The tool names and codes are real.
slack__post_message · asked by Claude Code, engineergithub__create_pull_request · asked by Nightly job, agent keyHow does each member connect?
A fictional four-person team: two engineers on Claude Code, one on Codex, one product lead on claude.ai. Each adds CoreSpeed at user scope, once per machine. In Claude Code:
claude mcp add corespeed https://api.corespeed.io/mcp --transport http --scope userOn Codex it is codex mcp add corespeed --url https://api.corespeed.io/mcp followed by codex mcp login corespeed. On claude.ai it is a custom connector. The first browser sign-in from any client creates the organization on its first tool call; later members join the same org.
tools/list is caller-specific. Each member sees the tools of the connections they can reach, the built-ins their settings allow, and the org's remote MCP servers. Absence of a tool is a decision, never a bug. The MCP docs cover each client.
What is shared and what stays private?
Every connection is private or shared, and any member can connect either kind. The team shares GitHub, Linear and the team Notion workspace, so every member's agent works in the same repositories, issues and pages. Each member keeps Gmail private. Where the vendor installs CoreSpeed as its own actor, such as the Slack workspace bot or Linear's app under the alias corespeed-bot, an org admin connects it once as an organization integration, and actions through it are attributed to the app.
| Principal | Credential | Reaches | Who decides its cards |
|---|---|---|---|
| Member, browser sign-in | MCP OAuth token | private and shared connections | the member |
| Member, API key | sk-cs- key, acts as the member | private and shared connections | the member who created the key |
| Agent | sk-csa- key | shared connections only | the agent's owner |
Memory follows the same split. A write is scope: "private" by default or scope: "shared" when asked for. Shared memories are read by every agent in the org; the boundary is enforced in Postgres by row-level security.
How does the bot get its own identity?
The team also runs a nightly triage job on their own server. It should not act as any one person, so a member creates an agent at Dashboard → Settings or with manage__agents_create and becomes its owner. Ownership is accountability: the owner answers for the agent and, with org admins, may manage it. The agent inherits neither the owner's connections nor the owner's role.
The owner mints an sk-csa- key for it, with a monthly spend cap in credits. Past the cap, metered calls answer key_spend_limit_exceeded until the month rolls over. The job reads the key from an environment variable, never a config file. It reaches the shared GitHub and Linear connections and nothing private.
If the job misbehaves, suspend the agent: calls answer 403 agent_suspended and the keys stay intact until it is resumed. Retire is terminal: the record survives for attribution and the keys are revoked. The authentication docs list all four credentials.
How does one policy cover all of them?
Smart Approval sits in front of the tools, so one rulebook covers every client and every principal. An org admin writes the policy in plain English, for example "Ask me before anything is posted to a public channel, and never merge a pull request." A member can add their own text, which only makes things stricter for their own calls. Reads are never gated. On the Balanced default, an ordinary write nobody wrote about runs.
When the nightly job tries github__create_pull_request and the policy asks, the card goes to the agent's owner. When an engineer's Claude Code tries slack__post_message to a public channel, the card goes to that engineer. An agent cannot approve its own action. The Approvals docs describe the verdicts.
Who sees what in the trail and ledger?
Dashboard → Activity shows each member their own actions; org admins see the whole org. Activity under an API key is attributed through the key's owning identity, so the nightly job's actions show up under the agent, and an engineer's key under the engineer. A record holds action, actor, outcome (ok, error, held, denied), surface and time, and for a failure the code the agent saw.
Every metered call lands in one organization ledger, itemized. Past the billing threshold, later metered calls answer payment_required before any tool runs; discovery, account reads and key management keep working. Adding credit clears it.
FAQ
Do members have to use the same client? No. Each member uses the client they prefer. The organization is the unit of ownership, and the server is the same for every client.
Can the bot read a member's private Gmail? No. An agent principal reaches shared connections only. A member's private connection is reached by that member and their clients alone.
Who approves the bot's held actions? The agent's owner. An agent cannot approve its own action, and admins can see every card, but seeing is not deciding.
Can a member loosen the org policy for themselves? No. A member's own text can only make things stricter for their own calls. The org policy is the ceiling.