Shared Agent Memory for Teams: Workspaces and Scoped Tokens

A shared API key gives every teammate's agent the same access and none of the boundaries. This guide sets up shared agent memory the other way around: workspaces for projects, one ak_ key per agent, and scoped at_ tokens for CI.

Why shared agent memory beats a shared API key

Coding agents start every session with an empty context window. The conventions your team already settled — staging-first deploys, migration ordering, the service nobody deploys on a Friday — live in individual chat histories, not in a place the next session can read. For one developer, that is friction; why coding agents forget conventions covers what a memory layer changes for a single workflow.

On a team, the problem compounds. Every new engineer re-explains the same decisions. Two agents working in the same repository can disagree about the test command because each learned a different convention. The fix most teams reach for first — one shared API key, every agent pointed at one account — trades a context problem for an access problem. Rotating that key means touching every laptop and every CI job. A throwaway sandbox project writes into the same namespace as production. A contractor's agent gets access to everything because there is no smaller unit to hand out.

Shared agent memory needs boundaries instead of a shared credential. Three layers do the work: a workspace that groups projects, a per-project key for each agent, and a scoped auth token for automation. What belongs in memory matters as much as who can reach it: preferences like "pnpm, not npm", decisions with a reason, and constraints such as a required staging header. Temporary debugging state and secrets do not belong there.

Workspaces group projects under one account

A workspace is the top-level container for a team's work. You create projects inside it, and each project holds its own memories. The management plane at https://memory-api.audaxic.com creates and rotates projects and keys; the dashboard exposes the same operations in a browser, which is usually how a new project gets set up. Dashboard sessions use a Clerk session JWT and stay in the browser, so there is nothing to install and nothing to share.

Keep the grouping boring and predictable. One workspace per team or product area, then one project per repository, service, or agent workflow:

• platform workspace — checkout-service, billing-worker, infra-scripts
• web workspace — marketing-site, design-system

Projects are unlimited on every plan, Hobby through Enterprise, so there is no cost reason to cram unrelated work into a single project. When the payments service and the marketing site share one project, every retrieval pulls from both; splitting them costs nothing and removes a class of confusing results.

Workspaces shipped alongside auth tokens, and the release post explains the model. If your team currently runs every agent against one personal key, move those projects into a workspace first: every other control hangs off that boundary.

Give each agent a per-project key

Project keys use the ak_ prefix and authenticate against the data plane at https://api.memory.audaxic.com. A key belongs to one project, so an agent working in checkout-service touches only that project's memories. Claude Code, Codex, and OpenCode can all use the same project's memory when they work on the same repository — that is the shared part — while each agent keeps its own credential.

Issue one key per agent per project instead of copying a single key across the team. When a laptop is lost or an engineer leaves, rotate only the keys that machine held; every other agent keeps running. The install commands are one line each:

npx @audaxic/memory-claude install
npx @audaxic/memory-codex install
npm install -g @audaxic/memory-opencode

The API is mem0-like, with POST /add, POST /search, GET /list, PUT /update, and DELETE /delete/{memory_id}. GET /list is paginated with limit and offset, which is how you check what a project actually holds. The quickstart has the request formats for each endpoint.

Agents that connect over MCP instead of a plugin use https://memory-mcp.audaxic.com/mcp over Streamable HTTP with a Bearer ak_... key. That is the supported path for Claude Desktop, Cursor, Windsurf, and any MCP-compatible client. Cursor connects through MCP only; there is no Cursor plugin. Point two machines at the same project key and they read and write the same memories with no files to sync.

Pin the API version in automation with the date-based X-Api-Version header. The current version is 2026-09-25, so a script written today fails loudly rather than silently if the API moves underneath it.

Scoped auth tokens for CI and automation

Project keys move memories; they do not manage the account. Anything that creates or rotates projects and keys goes through the management plane with an at_ auth token, and tokens carry explicit scopes: projects:read, projects:write, keys:read, keys:write. A CI job that only reads project metadata gets projects:read and nothing else.

Management create operations are limited to 100 per hour per IP. Responses carry RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, and RateLimit-Policy headers, so provisioning scripts can read their budget and back off before hitting the wall. Failed authentication on the data plane is guarded separately: 100 failed attempts per 4 hours per IP, and a 429 response includes Retry-After. The auth token docs list every scope and which operations it unlocks.

A practical split: give CI a token with keys:read and keys:write so scheduled rotation can cut a compromised project key without a human in the loop, and give a read-only reporting job projects:read alone. Neither job needs a data-plane key unless it also reads or writes memories. Scopes are the difference between "CI can rotate one project's keys" and "CI can do anything the workspace can."

Onboard a teammate in three steps

1. Create the project inside the team workspace in the dashboard, or through the management plane if you provision projects programmatically.
2. Issue a project key for that project.
3. Have your teammate install the plugin for their agent and connect the key.

Then verify recall instead of assuming it. Ask the agent something only a previous session would know: the test command, a naming rule, a constraint like never pushing directly to main. If the answer is right, memory is wired up correctly. If it is not, check that the key belongs to the project you think it does — a key for the wrong project makes memory look empty. GET /list confirms what a project holds before you start debugging retrieval.

To make shared agent memory useful on day one instead of after a month of sessions, import the history that predates the setup. The importer covers past Claude Code, Codex, and OpenCode conversations and keeps their original timestamps:

npm install -g @audaxic/memory-import

Run the import before an onboarding session, so the new teammate's agent starts with the same context as everyone else's. Importing past conversations covers the details.

What stays isolated, and what it costs

Isolation starts at the organization: data is isolated per organization with namespace-scoped vector search, customer data is never used to train models, and servers run in the US and EU. Inside the organization, the project is the practical boundary — an agent using the checkout project's key works in that project's memory only.

Graph memory is included on every plan, Hobby through Enterprise. Pricing is flat monthly, which matters when a small team's usage is uneven across weeks:

Two counting rules decide which tier a team actually needs. An add request counts per memory extracted from a message batch, so one /add call that extracts five memories counts as five adds. Retrieval is tiered: the first 10 memories in a search count as one request, and each additional 10 counts as one more, so a 25-memory search counts as three requests. Saving small, atomic facts spends fewer adds than storing paragraphs, and tight searches spend fewer retrieves.

Hobby includes 10,000 adds and 1,000 retrieves per month at $0 and does not require a credit card, enough to prove the workflow before a team-wide rollout. Enterprise adds on-premise deployment available on request; every other plan is fully managed with nothing to run.

FAQ

Written by Efe — Sep 25, 2026 · More articles · X @AudaxicTech