A Practical Architecture for Sharing One Local Memory Across Multiple AI Coding Tools

1. The Problem: What Gets Locked Down Is Not the Tools, but the Memory

The developer toolchain is moving from a “single assistant” model to a “multiple assistants coexist” model, and the reasons are very practical:

• Different models have different strengths and weaknesses in code understanding, long-document reasoning, and refactoring planning.
• Platform availability, quotas, and cost structures fluctuate over time.
• The stability of any single account or service is uncertain.

As a result, a “main tool + backup tool” setup has become a common default.

The real pain is not installing two tools. The real pain is the broken experience when switching between them. The same requirements, the same rationale for a technical decision, and the three approaches that were already ruled out last week often have to be explained again from scratch.

Information in an AI conversation can usually be divided into three categories:

• Noise: intermediate inferences and rejected guesses during exploration;
• Facts: requirement constraints, interface contracts, environment differences, and problems already encountered;
• Decisions: why option A was chosen over option B, and what trade-offs were involved.

The tool itself has no motivation to distinguish these three types. It usually only retains the raw conversation. When a conversation is cleared, compressed, or unavailable because an account or service is temporarily inaccessible, the latter two categories of information disappear together.

The cost is repeated explanation, backtracking on decisions, and redoing work.

This leads to the first judgment: what we need is not a “longer context window,” but a layer of memory decoupled from the tools. Memory must be an asset that is portable, searchable, and versionable. The tools are only consumers of that asset.

2. Why Static Configuration Files Solve Only Half the Problem

Most intelligent coding tools support placing a context description file in the project root directory and automatically loading it when a session starts. This is the correct first step: stabilize facts that do not change often.

Examples include:

• directory conventions;
• technology stack and versions;
• build and test commands;
• code style rules;
• explicit prohibited actions.

This kind of information changes on a monthly or even longer cycle. Once written down, the benefit is immediate.

However, its boundary is also clear: a static file answers “what the project is,” but not “what happened during this period of work.” And it is often the second question that determines whether a previously agreed decision still holds today.

Using a fixed-format daily report to fill this gap usually fails within one or two weeks, for three reasons:

1. Frequency mismatch: the events worth recording happen randomly, but a daily report requires daily output.
2. Upfront cost: even when there is nothing worth recording, someone still has to write something.
3. Poor delayed recall: details from three days ago may already be forgotten, so the result is often empty generalities.

The correct pattern is event-driven:

• Do not prescribe a fixed frequency.
• Only prescribe a trigger condition.
• When a person judges that “this event may be useful in the future,” record it immediately.
• Let the agent handle the actual execution.

3. Overall Structure: Three-Layer Memory

knowledge-base/
├── memory/
│   ├── context.md                # Shared background (single source of truth)
│   ├── daily-log/
│   │   ├── INDEX.md              # Index layer: monthly aggregated entry summaries
│   │   ├── 2026-08-27.md         # Event layer: daily shards
│   │   └── archive/              # Archive: expired months
├── views/
│   ├── assistant-a.md            # Load entry for Tool A (pointers only)
│   └── assistant-b.md            # Load entry for Tool B (pointers only)
└── sync-context.sh               # Generate tool views from the shared context

The three layers have separate responsibilities. The idea is similar to the simplest database design principle: schema, tables, and indexes each handle one job.

Layer	Content	Change frequency	Size
Static background layer	Project facts, conventions, constraints	Monthly	Small; can be loaded in full
Event log layer	Decisions, agreements, known pitfalls	Daily	Large; load on demand
Index layer	Date + one-line summary + keywords	Synced with events	Medium; can be loaded in full or only the most recent N entries

4. Mechanism 1: Single Source of Truth + Multiple Views

Different tools often use different filenames for automatically loaded context. This difference is unavoidable.

The important engineering rule is: do not maintain two copies of the main content. Instead, let each entry file become a pointer.

# views/assistant-a.md
The project background and collaboration conventions are maintained in memory/context.md. Please read that file in full first.
For historical decisions and known pitfalls, see memory/daily-log/INDEX.md.

A small script or symbolic link can be used to generate or link memory/context.md into each tool entry file. The key point is that the direction must be one-way:

• The main content is modified only in one place.
• All other locations are derived copies.

This avoids the common problem of updating Tool A but forgetting to update Tool B.

5. Mechanism 2: Turn Note-Taking into a Skill

The trigger contract is simple:

• A person says “record a note.”
• The agent handles the full execution.
• The person only makes the cheapest and most important judgment: whether this item is worth recording.

skill: record-note
trigger: user message contains an intent such as "record a note" / "note this" / "save for later"
steps:
  step1  time  = read the system current time (strictly no model inference or recall of the date)
  step2  topic = extract the event topic and generate a title in the form "HH:MM | topic"
  step3  entry = fill in the fields according to the entry template
  step4  write = append to daily-log/{YYYY-MM-DD}.md (append only, never overwrite)
  step5  index = append one summary line and keywords to daily-log/INDEX.md
failure handling: if any step fails, abort and report the reason; partial writes are not allowed

Three engineering details are easy to overlook:

• Time must come from the system clock. Letting the model infer “what date is today” is a high-risk hallucination point. It can write an entry into the wrong date shard and destroy the reliability of retrieval.
• Writes must be append-only. A log is a timeline, and rewriting it breaks history. In concurrent scenarios, such as two tools recording at the same time, use simple locking or re-read the file before writing.
• Content append and index write must be completed as a pair. If you only append content without updating the index, you create a black hole: the information exists, but it cannot be found.

6. Entry Template: Readable, Searchable, and Parseable

## 14:37 | Plan alignment
- Background: This week's goal is to deliver an initial version of capability X, involving modules A and B.
- Decision: Freeze the interface fields first, then develop in parallel; do not introduce an asynchronous queue yet; use synchronous calls as a temporary bridge.
- Trade-off: Sacrifice short-term extensibility to get something verifiable within two weeks.
- To-do: 1) Write the API documentation 2) Stress-test a single module 3) Review next Wednesday
- Impact: Module A owner; integration testing timeline
Keywords: plan alignment / interface freeze / technology selection / milestone

The value of field-based entries is twofold:

• The model does not need to read the full text. It can grab the Decision and To-do fields and rebuild enough context.
• The keyword line at the end serves full-text search. It determines whether the entry can be found in 30 seconds three months later.

7. Two-Level Retrieval: First Locate the Date, Then Locate the Paragraph

memory/daily-log/2026-08/
2026-08-27 | Interface fields frozen; parallel development starts        [interface freeze, milestone]
2026-08-25 | Dropped message queue; synchronous calls used as a bridge  [technology selection, queue]
2026-08-21 | Intermittent build failure traced to dirty cache           [build, cache, debugging]

The retrieval path is fixed:

keyword → hit the index line → get the date → open the daily shard → locate the paragraph.

Why use two levels instead of one?

• A second-level search has higher precision but higher scanning cost.
• A first-level search has lower precision but extremely low scanning cost.
• Combining them gives both speed and accuracy.

There are also three constraints:

• When a month has too many entries, archive by month. Keep the summary in the index and move the body into archive/.
• Set a maximum length for each index line. Truncate it if necessary.
• INDEX.md is the best file to feed in full to a new tool because it is short enough.

8. How to Inject Context When Switching Tools

The first prompt in a new session should not be small talk. It should be a reusable injection template:

Please read the following in order:
1) memory/context.md          — project static background (full)
2) memory/daily-log/INDEX.md  — index for the last 30 days (full)
3) daily shards matching the keywords of the current task (on demand)
After reading, confirm that you have grasped:
- technology-stack constraints;
- frozen decisions;
- outstanding to-dos.
Do not repeat this content. Start working directly.

The principle of loading order is: spend the context budget where information density is highest.

• Static background: small and not time-sensitive; load it in full.
• Index: a global view; load it in full.
• Daily shard body: load it only when keywords hit it, to avoid filling the window with unrelated noise.

9. Reliability, Security, and Evolution

• Plain text + version control: store all memory as plain text and put it under version control. Any accidental modification or deletion can be rolled back. This is much safer than burying key decisions inside the conversation history of one tool.

• Time consistency: inconsistent clocks across multiple machines can cause shard disorder. Use system time as the standard and keep the full date in each entry rather than relative expressions.

• Redaction: do not put secrets, tokens, intranet addresses, or real user data in the logs. Store credentials in a dedicated secret-management mechanism. The log should only record “which credential was referenced.”

• Collaboration and reuse: the background layer and index layer are suitable for sharing with a project repository. The event layer can be selectively separated before sharing.

• Scaling: when log volume and retrieval needs exceed the capability of local files, move to a centralized design:

  • object storage for raw text;
  • a logging service for structured fields and retrieval;
  • a permission system to control visibility.

  On Baidu AI Cloud, these generic capabilities can be combined into a team-level memory base. The upper-level recording skill and injection template do not need to change. This is exactly the benefit of layered design.

10. Common Pitfalls

1. Treating the log as the source of truth. Code, requirement documents, and test cases are the source of truth. The log only records “what we thought at the time and why we decided it that way.”

2. Recording too much. Do not record intermediate reasoning or rejected guesses. Prefer fewer, more accurate entries. Otherwise, noise will reduce the retrieval hit rate.

3. Writing without reviewing. Spend ten minutes a month scanning the index. Delete expired entries and merge duplicates. A memory base needs pruning.

4. Pursuing full automation. Fully automatic recording will fill the system with low-value entries. Keep the human judgment of value. It has the lowest cost and the highest return.

11. Implementation Checklist

1. Create memory/context.md and write down the technology stack, directory structure, build and test methods, and prohibited actions.
2. Create pointer-only view entries for each tool, and use a script to keep them in sync.
3. Define the entry template and keyword conventions.
4. Turn the recording action into a skill:
   • get system time;
   • extract topic;
   • append the daily shard;
   • write back to the index.
5. Write the injection prompt template for switching tools, and fix the loading order.
6. Put the entire directory under version control and configure regular backups.
7. Review the index once a month, then archive and clean up.

Conclusion: The friction cost of switching tools does not depend mainly on whether the tools are compatible. It depends on where the memory is stored. If memory becomes a plain-text asset in the project, the tool becomes just a replaceable interface. This is the most economical way to handle account risk, cost fluctuation, and model iteration.