Agent Memory Onboarding: Set Up a New Repo on Day One

Agent memory onboarding takes one session: create a project for the repo, connect your agents, import history, and seed the conventions new sessions need. Do it on day one and your agents stop relearning the codebase.

Why a new repo resets your agents

Every new repository starts your agents from zero. The clone has files, but the agent working in it has no record of how you build, test, or deploy that code. Package manager, test command, branch rules, and deploy constraints all live in past chats or in your head.

That blank start costs time on day one and compounds later. The agent guesses npm after the team standardized on pnpm, runs the root test suite instead of pnpm test --filter checkout-service, or opens a pull request straight to main when the repo requires staging-first checks. You correct each guess, the session ends, and the next session guesses again.

The mechanism matches why coding agents forget conventions: conversation context lasts only for its own lifetime. A new terminal, /clear, or compaction ends that lifetime. Anything you explained stays in the closed session unless something outside the conversation stored it.

A repo switch makes the loss total. Even an agent that learned your last project well knows nothing about the new checkout layout, migration ordering, or service boundaries. That reset is what agent memory onboarding prevents: one project memory per repo, filled on day one, read by every later session.

Paste-in prompts do not fix it. Store the facts once in a shared memory layer and each session recalls the slice it needs. Audaxic Memory is one shared memory layer for all your coding agents, with one memory per project so switching agents never resets context.

Step 1: one project and key per repo

Create one project for the new repository before any agent writes code. The project is the isolation boundary: memories stored under the checkout-service project are visible only to agents holding that project's key. Splitting by repo keeps retrieval narrow, so a search for migration ordering does not return rules from an unrelated site.

Projects are unlimited on every plan from Hobby through Enterprise, so no cost reason exists to share one project across repos. Name the project after the repo: checkout-service memory holds checkout-service facts. Shared memory for teams shows the workspace pattern for team setups.

Each project gets its own ak_... project key for the data plane at https://api.memory.audaxic.com. Issue one key per agent per project rather than copying a single key everywhere. When a laptop is replaced or a contributor leaves, you rotate only the affected key and the rest of the team keeps running.

The management plane at https://memory-api.audaxic.com handles project and key operations, and the dashboard exposes the same flow in a browser. Automation that creates projects or rotates keys uses an at_... auth token with explicit scopes such as projects:read, projects:write, keys:read, and keys:write. The auth token docs list which scope each operation needs. Keep the two credentials apart: ak_... keys move memories, at_... tokens manage projects and keys.

Management create operations are limited to 100 per hour per IP, with RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, and RateLimit-Policy headers on responses. Provisioning scripts should read those headers and back off. Failed authentication on the data plane is guarded separately at 100 failed attempts per 4 hours per IP, with Retry-After on 429 responses.

Step 2: connect the agents you use

Connect each agent you use on this repo to the same project key. That shared key is what lets Claude Code, Codex, and OpenCode read and write the same project memory instead of building three private histories.

The plugin installs are one line each:

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

Run the install for each agent that touches the repo, then point each at the new project's ak_... key. Two machines on the same key read and write the same memories with no files to sync. Data is isolated per organization with namespace-scoped vector search, customer data is never used for training, and servers run in the US and EU.

Agents that connect over MCP instead of a plugin join the same memory through the remote server. Point the client at https://memory-mcp.audaxic.com/mcp over Streamable HTTP with the same ak_... Bearer key:

{
  "mcpServers": {
    "audaxic-memory": {
      "url": "https://memory-mcp.audaxic.com/mcp",
      "headers": {
        "Authorization": "Bearer ak_YOUR_PROJECT_KEY"
      }
    }
  }
}

That endpoint serves Claude Desktop, Cursor, Windsurf, and any MCP-compatible client. Cursor connects through MCP only; there is no Cursor plugin. REST and MCP read and write the same project memory, so a fact saved by Claude Code is visible to a Cursor session on the same key. 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. The quickstart has the request format for each endpoint.

Pin the date-based X-Api-Version header in any script you keep in the repo. The current version is 2026-09-25, so automation fails loudly instead of silently changing behavior when the API moves.

Step 3: import past sessions for this repo

If the repo already has history — prior Claude Code, Codex, or OpenCode sessions from a prototype or spike — import it before the first real work session. An empty memory forces the agent to relearn decisions the team already made.

The importer covers past Claude Code, Codex, and OpenCode conversations with correct timestamps:

npm install -g @audaxic/memory-import

Run it scoped to the new project so only this repo's history lands in this repo's memory. Import once per project, then check what arrived with GET /list before inviting the team. Importing into the wrong project is the most common setup mistake: the memories are fine, but the agents look in a different project and see nothing.

What carries over is narrow: decisions with reasons, constraints that still apply, and defect patterns the repo already showed. A March decision that checkout migrations run after the backfill belongs here. A temporary debug port from a spike does not. Importing past conversations walks through the per-tool details.

If there is no prior history, skip the import and seed from scratch in the next step. Do not invent history or copy memories from an unrelated project. Five correct facts beat thirty borrowed facts that trigger wrong suggestions for weeks.

After import, do a ten-minute audit. Pull the first page with limit=20, merge duplicates, and delete anything stale. Import preserves timestamps, so you can tell last week's facts from an early prototype with different tooling.

Step 4: seed conventions in the first session

Open the first work session with one goal: state the conventions out loud so the agent stores them. You know most of them; the agent knows none. Spend twenty minutes dictating and confirming, and every later session inherits the result.

Keep the seed list small and atomic — one fact per memory. Aim for ten to twenty facts across four groups:

State each fact plainly: the repo uses pnpm, tests run with pnpm test --filter checkout-service, never push directly to main, migrations run after the backfill because the March deploy broke. The plugin saves facts as you work and injects relevant memories when later sessions start. Confirm with GET /list that each convention landed as its own entry. Atomic entries update cleanly; bundled paragraphs force a full rewrite when one detail changes.

Include the reason on decisions, not just the rule. Staging-first deploys stick when the memory says direct production pushes skipped the contract check. A bare rule gets re-litigated; a rule with a one-line cause survives.

What you seed defines what the agent injects later. Session start pulls a small slice of relevant memories, not the whole project. Tight facts retrieve cleanly: a search for migration ordering returns that rule, not a bundle covering unrelated topics. One /add call extracting five memories counts as five adds. Repeat this seed for each new repo instead of copying seeds across projects.

Verify agent memory onboarding: prove recall in a fresh session

Verify before you call setup done. Open a fresh session — new terminal, after /clear, or after compaction — and ask something only the project memory could know: the test command for this service, the migration ordering rule, the branch the repo deploys from. If the answer cites the seeded fact, the plugin, key, and project are wired correctly.

If the answer is wrong, check three things in order. First, the key: a wrong-project key makes memory look empty even when the correct project is full. Second, the search: confirm the agent searched before answering. Third, the store: call GET /list with a small limit and confirm the fact exists. Most failures are key mistakes, not retrieval failures.

Make recall part of the repo routine. Search before implementing with the repo name plus the touched area: checkout-service billing-worker retry rules. Store what is new and nothing else: if the session settled a backoff interval, save that one fact. Retrieval is tiered — the first 10 memories count as one request and each additional 10 as one more — so narrow searches spend fewer retrieves.

Set the maintenance habit while the memory is small. Correct with PUT /update when a detail changed; do not add a second memory that contradicts the first. Delete with DELETE /delete/{memory_id} when a rule expired; stale facts hurt more than missing facts. Reserve the full wipe DELETE /delete for a true project restart. Hobby includes 10,000 adds and 1,000 retrieves per month at $0 with no credit card required. Graph memory is included on all plans from Hobby through Enterprise, with flat monthly pricing and no per-token fees.

Close the loop by telling the next teammate the memory exists. Point them at the project key, have them install the same plugin, and have them run the same recall question. When their fresh session answers correctly without a forwarded chat log, the repo is onboarded.

FAQ

Written by Efe — Oct 09, 2026 · More articles · X @AudaxicTech