Shared Coding Conventions Your Agents Actually Reuse

Your agents re-argue the same conventions every session because the rulings live in old chats and tool-specific configs. Store shared coding conventions once as project memories — rule, scope, example, exception — and every agent on the repo recalls them instead.

Why conventions die when they live in tool configs

Your team already agreed on the basics. The repo uses pnpm, not npm. Tests run with pnpm test --filter checkout-service. Migrations run after the backfill, never before. Every engineer on the project knows these rules.

The next agent session does not. It opens with an empty context window and the files in front of it, nothing else. Anything you settled last week lives in a closed chat, a tool-specific config, a pinned thread, or one engineer's notes. None of those travel with the task when you switch tools or open a fresh terminal.

That is why the same arguments repeat. One session standardizes on npm because the model default points there. The next asks which test command covers the checkout service. A third reorders a migration the team fixed in March.

The pattern matches why coding agents forget conventions: a conversation holds context only for its own lifetime. Compaction rewrites that context to fit the window and drops details. /clear discards it outright. A new terminal, a new branch session, or a different agent starts from zero.

Tool switching makes the loss permanent. The history that taught Claude Code your formatter stays in that tool's session. When you continue the same task in Codex or OpenCode, the second agent cannot see the first agent's chat. If you never wrote the convention to a place both agents read, the second agent re-argues it from defaults.

Local config files do not solve the team case either. They cover one checkout on one machine and drift between clones. A config states a setting. A convention memory states the rule plus where it applies, what good looks like, and which exception the team already approved.

Shared coding conventions as project memories

Shared coding conventions work when they live in one project memory that every agent on the repo can retrieve. You store each ruling once, with the project key for that repo, and every agent that holds the key reads the same set of facts at session start.

The scoping is simple. Create one project per repository and use ak_ project keys on the data plane at https://api.memory.audaxic.com. Claude Code, Codex, and OpenCode each hold a credential, but they point at the same project when they work on the same repo. MCP clients join the same project with the same key over Streamable HTTP. One memory per project means switching agents never resets context.

The API is mem0-like, with five data-plane operations: 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 mechanism here is retrieval, not config sync: no files are copied between tools, and no tool needs to understand another tool's settings format.

Setup follows the same path your team already uses for shared team memory. Install the plugin for the agent in front of you:

npx @audaxic/memory-claude install

The Claude plugin docs cover the connect step and session behavior. Repeat for the other CLIs against the same project key. From that point on, a convention saved in one session is searchable in the next, regardless of which agent saved it.

Isolation holds while sharing stays simple. 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. Inside the organization, the project is the boundary: an agent holding the checkout-service key sees checkout-service conventions and nothing else.

The four-part template: rule, scope, example, exception

A convention memory needs four fields to be reusable. Rule states what to do. Scope states where it applies. Example shows what good looks like. Exception records the approved deviation so the next agent does not treat it as a violation.

Write one memory per ruling. A bundled paragraph that mixes package manager, formatter, and branch policy retrieves badly: a search for formatter returns the whole bundle and forces the agent to split it. Atomic facts retrieve cleanly, and you correct one ruling without rewriting three.

Here is what a stored convention looks like as an /add 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" \
  -d '{
    "messages": [
      {"role": "user", "content": "Project convention: use pnpm, not npm, in checkout-service and billing-worker. Example: pnpm install --frozen-lockfile. Exception: legacy marketing-site stays on npm until Q4 migration because its lockfile has not been converted."}
    ]
  }'

Pin the date-based X-Api-Version header in every script. The current version is 2026-09-25, so automation fails loudly instead of drifting silently when the API moves. The add API docs show the full request shape and how a message batch splits into stored facts.

Keep the rule sentence tight enough to quote in a review comment. If the agent cannot paste the rule into a PR reply without editing it, the rule is too long.

The exception field prevents false violations. The team requires staging-first deploys because a direct production push skipped the contract check. The exception: hotfixes to the status page may deploy directly with two approvals. Without that note, every hotfix triggers a false violation.

Write conventions for recall, not for reading

A human reads a style guide top to bottom. An agent retrieves with a query, so write shared coding conventions for the query the next session will type. Include the keywords that session will use: package names, file paths, command names, and error strings.

Name the thing the way the codebase names it. Write checkout-service migration ordering rather than database best practice. A search for checkout-service test command should hit the memory on the first try.

Add a one-line reason to every rule. The team uses pnpm --frozen-lockfile in CI because an unfrozen install drifted across two runners in February. Migrations run after the backfill because the March deploy broke checkout for an hour. A bare rule gets re-litigated every month; a rule with a cause sticks because the agent can cite it in the reply instead of asking whether it still applies.

Separate stable rules from provisional notes. A stable rule covers every session until someone changes it: formatter, package manager, branch policy. A provisional note covers one migration or upgrade window, and it should say so in the text: applies to the Postgres 16 upgrade branch only, remove after merge.

Avoid storing what the repo already holds. File contents, full diffs, generated lockfiles, and credentials do not belong in memory. Store the pointer and the judgment: which command to run, which order is safe, which header is required. An add request counts per memory extracted from a message batch, so one /add call that extracts five memories counts as five adds. Short, atomic conventions keep both retrieval and accounting predictable.

Verify a fresh session applies the convention

Saving a convention is half the job. The other half is confirming a fresh session retrieves it and acts on it. Run the check in a new session, not the one that saved the fact, so the test proves retrieval rather than recency.

Start with a direct search. Query with the terms the next engineer would type, then confirm the ruling comes back:

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" \
  -d '{
    "query": "checkout-service package manager pnpm test command"
  }'

The search API docs describe query shape and how result ranking treats keywords. If the convention does not surface in the top results, add the missing keyword to the memory with PUT /update rather than saving a duplicate. Two competing memories for the same rule force every future search to return both and make the agent guess.

Then check behavior, not just retrieval. Ask the agent to run the stored command or to review a small diff that violates the rule. A good response cites the memory: it runs pnpm test --filter checkout-service without asking, or it flags the npm install in the diff and quotes the exception for the legacy site. The same setup lets your code review agent enforce the same conventions without repeating settled comments.

Audit the project listing when verification fails twice. Call GET /list with a small limit and an offset walk to see what the project actually holds. The usual causes are concrete: the memory landed in the wrong project, or two memories contradict each other and the agent picked the stale one.

Test the exception path too. Give the agent a case the exception covers, such as a change inside the legacy site that still uses npm, and confirm it does not flag it. Teams lose trust in convention checks faster from false positives than from misses.

Change a ruling once and every agent sees it

Conventions change. The formatter gains a plugin, the test command moves packages, the deploy freeze lifts. With one shared project memory, you update the ruling in one place and every agent reads the new version next session.

Use PUT /update when the fact still applies but the detail moved: new test filter, new backoff interval, new required header. Use DELETE /delete/{memory_id} when the rule no longer applies: freeze lifted, flaky test fixed at the source, provisional upgrade note merged. Do not add a second memory that contradicts the first. Contradicting duplicates are the fastest way to make agents hedge instead of act.

This is where updating shared coding conventions once pays off. The engineer who learns the new test command writes it back at the end of the session, and the teammate who opens the repo tomorrow in a different agent retrieves the corrected fact with no handoff message. Retrieval is tiered — the first 10 memories count as one request and each additional 10 as one more — so narrow searches stay cheap as history grows.

Schedule a short audit matching PR volume. Pull the first page of GET /list, scan for duplicates and expired exceptions, then merge or remove. Graph memory is included on all plans from Hobby through Enterprise with flat monthly pricing and no per-token fees, so upkeep changes retrieval volume, not the billing model.

End each session with the same habit: if a ruling changed, update it before you close the terminal. The next session — yours, a teammate's, or a different agent on the same key — starts informed instead of re-arguing what this session already settled.

FAQ

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