Onboard New Developers Faster with Shared Agent Memory
To onboard new developers faster, connect their agent to the team's shared project memory on day one — so conventions, past decisions, and gotchas are recalled, not re-explained.
On this page
- Why onboarding repeats the same explanations
- Onboard new developers on day one: connect them to project memory
- What their agent can answer without asking anyone
- The first-week loop: new hires write memories back
- Before they ship: audit stale facts with update and delete
- New developer ramp checklist: five pass/fail checks
Why onboarding repeats the same explanations
Every team pays a re-explaining tax when a developer joins. The conventions are settled — package manager, test scope, branch rules, deploy order — but they live in senior engineers' heads and scattered chat logs. The new hire asks, someone answers, the thread scrolls away, and the next hire asks again.
Coding agents make the tax visible. The new teammate's agent starts with an empty context window, so it guesses: the wrong test command, a pull request straight to main, a migration run before the backfill. A senior corrects the agent instead of reviewing the work.
The cause is the one described in why coding agents forget conventions: conversation context ends with the session. A new terminal, /clear, or compaction wipes it. Unless decisions were stored outside the conversation, the new developer's agent cannot see them.
Shared project memory removes the repetition. The team stores each convention once, and every new teammate's agent recalls the same facts from day one. Seniors answer once, in memory, instead of once per hire.
Onboard new developers on day one: connect them to project memory
This post shows how to onboard new developers through shared memory — the human side of onboarding. The repo-side setup — creating the project, connecting plugins, importing history, seeding conventions — is documented in agent memory onboarding for a new repo. Assume that setup exists: one project per repo, already seeded with verified facts. Your job is to connect a person to it.
Day-one connection takes three steps. First, issue the new teammate their own project key for the repo's project. Project keys use the ak_... prefix and authenticate against the data plane at https://api.memory.audaxic.com. Use one key per person per project: a lost laptop means rotating one key while the rest of the team keeps running.
Second, have them install the plugin for their agent and point it at that key:
npx @audaxic/memory-claude install
npx @audaxic/memory-codex install
npm install -g @audaxic/memory-opencode
Agents over MCP join the same memory through https://memory-mcp.audaxic.com/mcp over Streamable HTTP with the same ak_... Bearer key. That covers Claude Desktop, Cursor, Windsurf, and any MCP-compatible client — Cursor connects through MCP only since there is no Cursor plugin. REST and MCP read and write the same project memory, so a fact saved from Claude Code is visible to the new hire's Cursor session.
Third, verify recall before assigning work. Have the new developer open a fresh session and ask something only project memory could know: the scoped test command, the deploy branch, the migration ordering rule. If the answer cites the stored fact, the key, plugin, and project are wired correctly. If not, check the key first — a wrong-project key makes memory look empty.
Confirm holdings with GET /list using a small limit; the quickstart shows the request format. Shared memory for teams documents the workspace pattern behind this flow: projects grouped per team, per-project keys for agents, and at_... auth tokens with scopes such as projects:read and keys:read for the automation that issues keys. The auth token docs list which scope each management operation needs.
Keep the two credentials apart. ak_... keys move memories on the data plane; at_... tokens manage projects and keys on the management plane at https://memory-api.audaxic.com. A new developer needs the first, never the second. Data is isolated per organization with namespace-scoped vector search, never used for training, and served from the US and EU.
What their agent can answer without asking anyone
A seeded project memory answers the questions that otherwise interrupt seniors: tooling, commands, rules, and gotchas. Each memory holds one fact, stated plainly, with a one-line reason where the reason is what makes the rule stick. Use the table as a seeding checklist: any row without a matching memory is a gap to close before the hire's first session.
| Question the new hire would ask | What memory returns | Why it matters week one |
|---|---|---|
| Which package manager and Node version? | pnpm, pinned version, and the install command |
Prevents a broken local setup on day one |
| How do I run the tests for this service? | Scoped command, e.g. tests limited to the touched service | Stops full-suite runs that waste an afternoon |
| Where do pull requests go? | Branch strategy and required checks before merge | Avoids a rejected PR and a rebase lesson |
| What order do migrations run in? | Ordering rule with the incident behind it | Avoids repeating a deploy failure the team already fixed |
| Which files or areas are fragile? | Flaky tests and service-specific constraints | Keeps the first tasks scoped to safe ground |
None of this replaces reading code. It replaces the routine interruptions that block both the new hire and the person they ask. The agent injects relevant memories at session start and searches the rest on demand, so the new developer gets the convention inside the workflow instead of in a wiki page they have not found yet.
Set the week-one rule explicitly: memory answers project facts, not engineering judgment. When the agent returns a convention, the new hire follows it. Design decisions still go to a human — then the answer gets stored so the next hire does not ask again.
The first-week loop: new hires write memories back
New developers are the best auditors a memory has — everything unfamiliar is visible to them. Turn that into a loop: every time the new hire asks a human something memory should have answered, store the answer before the day ends. Within a week, the gaps one hire found become the coverage the next hire inherits.
Give the new teammate write access through their own project key from day one. The plugin saves facts as sessions run, and the API is mem0-like: POST /add to store, POST /search to recall, GET /list paginated with limit and offset to audit, PUT /update to correct, and DELETE /delete/{memory_id} to remove. One /add call that extracts five memories counts as five adds, so store one fact per memory. Atomic entries update cleanly.
Teach two habits. First, search before asking: query memory with the repo name plus the touched area before pinging a channel. Retrieval is tiered — the first 10 memories count as one request, each additional 10 as one more — so narrow queries spend fewer retrieves.
Second, store only what is new: a confirmed backoff interval or flag, with its reason. Debugging state, secrets, and credentials never belong in memory. When in doubt, leave it out and ask.
Review additions once mid-week. Pull GET /list, read the newest entries, and fix phrasing while context is fresh. "Tests are flaky" helps nobody; "billing-worker contract tests flake on retry timing, rerun with the seeded clock" helps the next hire. One review teaches the writing standard faster than any style doc.
Before they ship: audit stale facts with update and delete
Memory goes stale exactly when onboarding works: the team changes a rule while the new hire learns the old one. Before they ship unsupervised work, audit the facts their tasks touched.
Keep the audit scoped. List memories for the areas they worked in and sort each entry: correct, changed, expired. Correct entries need nothing. Changed entries get PUT /update — never a second memory that contradicts the first, or retrieval returns both and the agent guesses. Expired entries get DELETE /delete/{memory_id}. Reserve the full wipe DELETE /delete for a true project restart.
Watch three staleness signals. Duplicates from the first-week loop: the hire saved a fact the team had under different wording — merge into one entry. Prototype leftovers: an imported decision an early spike contradicts — the importer preserves timestamps for Claude Code, Codex, and OpenCode conversations, so check dates when entries disagree. Missing reasons: a rule with no cause gets re-litigated by every hire — add the one-line reason or delete the rule.
Pin the date-based X-Api-Version header in repo onboarding scripts. The current version is 2026-09-25. Management creates are limited to 100 per hour per IP; failed data-plane authentication is guarded at 100 attempts per 4 hours per IP with Retry-After on 429s. Keep provisioning scripts modest and read the rate-limit headers.
New developer ramp checklist: five pass/fail checks
Close onboarding with a checklist the team repeats per hire. Each item has a pass condition, so "ramped" means something checkable. Run it the same way every hire; the answers improve while the bar stays fixed.
- Key issued and connected. The hire holds their own
ak_...key for the repo's project in their agent. Pass: a fresh session answers one seeded question — test command, branch rule, or migration order — with no forwarded chat log. - Recall verified across their tools. If they use two agents, confirm both read the same project memory. Pass: a fact saved in one agent is searchable from the other on the same key.
- First-week loop running. They search memory before asking and store new facts with reasons. Pass: at least five of their first-week entries survive mid-week review without rewrites.
- Touched areas audited. Changed facts updated, expired ones deleted. Pass:
GET /listfor those areas shows no contradicting pairs. - One gap closed for the next hire. They nominate the fact they most wish had existed on day one, stored as one atomic memory with question, answer, and reason.
When all five pass, the hire is onboarded and the memory is stronger than before they arrived. Graph memory is included on all plans from Hobby through Enterprise, and projects are unlimited on every plan, so this loop needs no extra structure per hire. The next developer starts from a fuller memory, so each round helps you onboard new developers faster.
FAQ
How do I onboard new developers onto shared agent memory on day one?
Give them their own ak_... project key for the repo's project and have them install the plugin for their agent, then verify with a question only project memory could answer. If the answer is wrong, check the key first — a wrong-project key makes memory look empty.
Does a new teammate need an auth token to use project memory?
No. New developers need an ak_... project key for the data plane, which reads and writes memories. Auth tokens are management-plane only and are used by automation that creates projects and keys, never by a developer's agent.
How do we fix stale facts the new hire already learned?
Use PUT /update when a detail changed and DELETE /delete/{memory_id} when a rule expired. Never add a second memory that contradicts the first — retrieval returns both and the agent guesses.
Can hires on different agents share one project memory?
Yes. REST and MCP read and write the same project memory, so a fact saved from Claude Code is visible to a Cursor or Windsurf session on the same project key. Cursor connects through MCP only, since there is no Cursor plugin.
Written by Efe — Oct 11, 2026 · More articles · X @AudaxicTech