Build Features Across Multiple Sessions Without Rework

Real features ship across multiple sessions — across days, compaction, and new terminals. Record decisions, constraints, and next steps as you work, then open each session with recall instead of rework.

Feature work spans sessions; chat history doesn't

A real feature ships in slices. You scope the API on Monday, build the happy path on Tuesday, handle edge cases after review on Thursday, and fix the deploy gotcha the next week. Each slice ends because the day ends, the context fills, or another ticket interrupts.

Each restart costs you the working state you held in chat. The rejected schema, the flag that must stay off in staging, the next file to edit — all of it lived in a conversation you already compacted, cleared, or closed. The code remains, but the reasoning behind the code does not.

Feature work needs a record outside the conversation. One project memory holds decisions, constraints, and next steps where every future session can read them. You write code in the session; you keep the reasoning in memory.

A shared layer matters because you rarely finish in one tool. You may start in Claude Code with npx @audaxic/memory-claude install, continue in Codex with npx @audaxic/memory-codex install, or pick it up in OpenCode after npm install -g @audaxic/memory-opencode. One memory per project means switching agents never resets context. If the repo has no project memory yet, start with the day-one repo setup: one project per repo, connected agents, and verified recall — this playbook builds on it.

What rework looks like without a memory layer

Without that record, every return visit starts with re-discovery. The agent proposes the approach you already rejected because the rejection lived in last week's chat. You re-explain that the billing provider forbids parallel webhooks, that the migration must run after the backfill, that the staging flag stays off until legal signs off.

The second form of rework is quieter. The agent re-derives a constraint by reading the same three files again, runs the same failing command again, and bills the same investigation time again. Nothing looks broken, but the session spends its first hour re-learning what the prior session already proved.

The third form shows up in review. A teammate or a review agent questions a naming choice or a scope cut without knowing you already decided it with a reason. Discussion restarts, the pull request stalls, and you re-argue a decision you already recorded instead of citing it. For why this keeps happening, see context window vs memory layer: a larger window delays the reset but never stores the fact.

Track the pattern for one week and the cost is concrete. Count how many times you paste the same constraint, reject the same suggestion, or search chat history for a decision. Each repeat is a memory that should have lived outside the session.

Record across multiple sessions: decisions, constraints, gotchas

Record as you go across multiple sessions, one fact per memory. You or the plugin saves the fact while the context is fresh. Nothing lands in memory unless one of you saves it — unsaved context from this session is invisible to the next.

Store four kinds of facts for feature work. Decisions capture what you chose and why. Constraints capture what you must respect. Gotchas capture what wasted time. Next steps capture where to resume. Each one is atomic so it retrieves cleanly and updates independently.

Write each fact the way a future session will search for it. Include the service name, the area, and the reason in one line. Use idempotency key is vague and collides with other services. billing-webhook uses Stripe event id as idempotency key because provider retries duplicates matches a query for billing-webhook retry duplicate weeks later.

Save through the plugin or the REST API. The data plane is https://api.memory.audaxic.com with a project key that starts with ak_, and the API is mem0-like with 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 shows request shapes for each call:

curl -X POST https://api.memory.audaxic.com/add \
  -H "Authorization: Bearer ak_YOUR_PROJECT_KEY" \
  -H "X-Api-Version: 2026-09-25" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "messages": [
    {"role": "user", "content": "Decision: billing-webhook uses Stripe event id as idempotency key because provider retries duplicates."},
    {"role": "user", "content": "Constraint: checkout migrations run after the backfill."},
    {"role": "user", "content": "Next: add retry test for webhook handler, then update docs."}
  ]
}
JSON

Leave transcripts, logs, and temporary state out. Full diffs already live in the repo, ports and process IDs die with the session, and wrong guesses have no reuse value. Never store secrets, tokens, or credentials in memory.

Resume cold: the recall-first checklist

Cold starts work when recall comes before code. The agent may be opening the repo days later, after compaction, after /clear, or in a new terminal. The order stays the same: search project memory first, read files second, edit third.

Run this checklist at the start of every feature session:

1. Search the feature area by service plus topic. Query billing-webhook idempotency retry or checkout migration backfill order with a small limit such as 10. The search API docs cover query shape and limits.
2. Pull the next step explicitly. Search next step billing-webhook or call GET /list with limit=20 and scan for the most recent resume note. That note tells you the entry file and the pending test.
3. Confirm decisions before re-litigating them. If the agent proposes a different idempotency key, ask it to cite the stored decision and its reason. A decision with a reason sticks; a bare rule invites a second debate.
4. Record what this session decides before you close it. Add the new decision, update the next-step note, and leave the store cleaner than you found it.

Example recall query:

curl -X POST https://api.memory.audaxic.com/search \
  -H "Authorization: Bearer ak_YOUR_PROJECT_KEY" \
  -H "X-Api-Version: 2026-09-25" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "query": "billing-webhook idempotency retry next step",
  "limit": 10
}
JSON

Pin the date-based X-Api-Version header in every script. The current version is 2026-09-25, so automation fails loudly on version drift instead of changing recall behavior mid-feature.

Verify the loop with a cold test. Open a new session, ask for the constraint only a prior session could know, and confirm the answer cites the stored fact. If recall comes back empty, check the project key first: a wrong-project key makes memory look empty even when the facts exist. Counting stays predictable while you practice: one /add call that extracts five memories counts as five adds, and retrieves are tiered so the first 10 memories count as one request and each additional 10 counts as one more.

Survives compaction, /clear, and new terminals

Feature memory must outlive the three resets that end real sessions. Compaction rewrites the context window to fit, /clear discards the conversation, and a new terminal or a new day starts with no chat history at all. Memories live outside that conversation in project storage, so the reset removes the chat while the facts stay readable.

For the full explanation of the first reset, read fixing Claude Code context compaction rather than working around it with longer prompts. Recall is a lookup against stored facts, not a longer context window. The agent searches the same project key after the reset and gets the same decisions back.

New terminals and new days follow the same path. The agent connects with the same ak_ project key, runs the same search, and resumes from the stored next step. Switching tools mid-feature also works when every agent points at the same project: coding agents write the decision while implementing, and the agent that resumes — Claude Code, Codex, OpenCode, or any MCP-compatible client — reads it back with no copy-paste between tools.

Data stays isolated per organization with namespace-scoped vector search, customer data is never used for training, and servers run in the US and EU. Inside the organization the project is the boundary, so the feature key returns feature facts and nothing else. Projects are unlimited on every plan from Hobby through Enterprise, so one project per repo costs nothing extra and keeps recall precise. Graph memory is included on all plans with flat monthly pricing and no per-token fees.

Weekly hygiene: prune decisions that changed

Feature memory rots when the feature moves. A scope cut expires, a flag flips, a rejected approach becomes viable after a provider change. An agent follows a stale memory with the same confidence as a fresh one, so pruning is part of shipping.

Run a short weekly pass with GET /list. Pull the first page with limit=20 and offset=0, scan for the feature area, and sort each note into keep, correct, or remove. A weekly pass takes minutes and catches the most expensive drift: acting on a decision the team already reversed.

Correct rather than contradict. When the retry interval changes or the migration gains a precondition, update the single memory instead of adding a second note that disagrees with the first. Competing facts split future recall and push the choice onto an agent working without your context.

Delete without hesitation when the fact no longer applies. The staging freeze lifted, the provisional workaround merged, the hotfix exception expired — removal is the fix because stale facts mislead more than missing facts. Reserve the full wipe for a true project restart; selective deletes preserve good rules while removing noise. Close each week by writing the next step fresh, so the next cold start across multiple sessions opens on a current entry point instead of an old plan.

FAQ

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