Short answer: Use Engram as durable coding memory via hooks or provider callbacks—not optional tool calls—so assistants recall architecture choices and conventions across sessions.
Coding assistants forget almost everything when a session ends. Local instruction files hold stable preferences; chat history holds the current thread; neither captures last month’s rejected approach or stack conventions that only live in a teammate’s head. You can drop in a Claude Code plugin, wire Hermes Agent as a memory provider, or call the Engram SDK from an IDE sidecar. Prefer hooks over optional tool calls so memory attaches without asking the model to remember. Prefer async writes over blocking waits; prefer the Coding Assistant template for coding-shaped topics. Scopes and search properties keep personal tone separate from shared architecture notes and filter memories to the current repo. Before each prompt search; after each exchange add and move on—wait only when debugging extraction.
Coding assistants and developer tools forget almost everything the moment a session ends. Local instruction files hold stable preferences. Chat history holds the current thread. Neither captures the reasoning behind last month’s architecture choice, the rejected approach that looked tempting again today, or the stack conventions that only live in a teammate’s head. Weaviate Engram closes that gap as durable memory for coding workflows. You can drop in a Claude Code plugin that recalls and stores through hooks, wire Hermes Agent as a memory provider, or call the Engram SDK from your own IDE sidecar. This chapter covers why file memory alone is not enough, how the Coding Assistant template shapes extraction, why hooks beat optional tool calls, how custom tools should search and add memories without blocking the session, and how scopes keep personal style separate from shared project decisions.
The goal is the same across every path. The assistant should start warm. It should remember what matters. It should stay out of the way while you keep typing.
Why do coding assistants still start cold after so many sessions?
A typical developer tool already has some memory. Project rules files describe how to format diffs. A short personal notes file lists languages and tone preferences. Those files are always loaded. They are fast. They are also tiny. They are good for conclusions that rarely change. They are poor for the story behind those conclusions.
Decision archaeology is the common failure. You ask the assistant why the team abandoned a caching layer three weeks ago. Without durable memory, it reconstructs a plausible story from the repo. Sometimes that story is wrong. Sometimes it invents a ticket URL to fill a hole. Engram’s internal coding-assistant evaluations showed the same pattern. Sessions with grounded recall avoided fabrications that cold sessions invented. The difference was not more tokens. It was memories that still held the reasoning chain.
That raises a practical question. If the assistant can call a memory tool, why not just tell it to search? Early integrations that left recall to the model often saw the model skip the tool. Forward-looking prompts such as “help me plan the next refactor” biased the agent toward moving ahead. Instructions in a rules file were not enough. Memory for coding tools has to be infrastructure, not an optional courtesy the model may ignore.
How do Engram plugins attach memory without asking the model to remember?
The Claude Code path is the clearest example of infrastructure-first memory. You create an Engram project and choose the Coding Assistant template. That template seeds topics aimed at coding sessions, such as personal user knowledge and tech-stack facts. You export an Engram API key in your shell profile. Inside a Claude Code session you add the Weaviate marketplace and install the engram plugin. On the next prompt, hooks begin recalling relevant memories before answers and storing completed turns afterward.
Those hooks matter more than the install commands. Recall runs before the model sees the turn. Capture runs after the turn completes. Memory is best-effort and never blocks the session. That design comes from hard lessons. Blocking on pipeline completion made sessions feel slow. Asking the model to decide when to save meant quiet gaps when a session ended early. Fire-and-forget writes into Engram’s async pipeline keep the editor responsive while extraction and reconciliation finish in the background.
Hermes Agent follows a related pattern through the hermes-weaviate-engram provider. Setup stores the API key and points Hermes at Engram as the memory backend. The provider can auto-recall into the system prompt and auto-capture completed turns. It can also expose search, store, and fetch tools when the agent needs explicit control. Plugin paths differ in surface area. They share the same Engram project, topics, and scopes underneath.
Once a plugin is working, the next question is usually customization. Teams want memories filtered to the current repo. They want personal tone preferences isolated from shared architecture notes. Engram scopes and search properties handle that. Global config can live in a home directory. Per-directory config can commit team defaults into a project. Search can narrow by codebase so recall for one service does not drown in memories from another.
What does a custom coding tool look like when you call Engram yourself?
Not every workflow is a hosted plugin. Many teams wrap their own CLI, editor extension, or agent loop. The Engram Python SDK is the same surface those plugins use. Before each prompt you search. After each exchange you add the conversation turn and move on. You do not wait for the run unless you are debugging extraction.
Imagine a small sidecar for a cartography team’s tiling CLI. Developers ask it about projection choices, tile-cache defaults, and past incidents. The sidecar scopes memories to the engineer and to the active plotter desk so personal habits never leak across desks.
import os
from engram import EngramClient
from engram.types import HybridRetrieval
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
engineer = "maya.okoye"
desk = "cartography-plotter-6"
# Before the model answers: inject grounded repo memory.
hits = client.memories.search(
query="Why did we reject Web Mercator tiles for the harbor layers?",
user_id=engineer,
group="default",
retrieval_config=HybridRetrieval(limit=5),
properties={"codebase": desk},
)
memory_block = "\n".join(f"- {m.content}" for m in hits)
# After the turn: fire-and-forget capture. Do not block the CLI.
turn = [
{
"role": "user",
"content": (
"For cartography-plotter-6, keep harbor tiles in equal-area "
"projection. We rejected Web Mercator last quarter because "
"shoreline area distortion broke flood overlays."
),
},
{
"role": "assistant",
"content": (
"Understood. I will treat equal-area as the default for harbor "
"layers on cartography-plotter-6 and avoid reopening Mercator."
),
},
]
run = client.memories.add(
turn,
user_id=engineer,
group="default",
properties={"codebase": desk},
)
print(run.run_id, run.status)
The search call uses hybrid retrieval so projection jargon and semantic phrasing both have a chance to match. The add call returns a run immediately. The Coding Assistant template’s topics decide which facts become durable memories. A tech-stack topic might keep the equal-area default. A user-knowledge topic might keep Maya’s preference for short diffs. Reconciliation later merges duplicates if the same decision appears again next week.
If you need to confirm extraction while building the sidecar, call client.runs.wait on that run_id in a debug path only. Production coding tools should treat memory writes as eventually consistent. The latest messages are already in context. Cross-session value arrives on the next cold start, not on the next keystroke.
How should teams separate personal habits from shared project memory?
Plugins and custom tools both inherit Engram’s scoping model. User-scoped topics never mix one engineer’s private preferences into another engineer’s session. Project-wide topics can hold decisions that should travel with the repo. Property scopes such as codebase or session_id add soft isolation so you can search narrowly by default and widen when you need cross-repo archaeology.
This boundary is where many coding integrations go wrong. A personal dislike of verbose comments should not become team law. A signed architecture decision about projections should not hide in one person’s private notes file. Engram lets those live in different topics and scopes inside one project. The Claude Code plugin can infer identity from git email and narrow search by repo name. Your custom tool can pass the same ideas explicitly, as the cartography sidecar does with user_id and properties.
Stable facts can still live in local instruction files. Engram is not a replacement for a short always-on checklist. It is the layer for everything that checklist cannot hold: rejected alternatives, evolving rationale, and cross-session context that would blow a line budget. File memory stays small and permanent. Engram stays searchable and topic-shaped.
Integrating Engram into coding assistants is therefore less about a single install command and more about choosing the right attachment point. Prefer hooks or provider callbacks over optional tool calls. Prefer async writes over blocking waits. Prefer the Coding Assistant template when you want coding-shaped magnets without designing topics from scratch. Prefer explicit scopes when more than one person shares a memory project. Our next chapter, How should you design memory architecture for customer support agents?, leaves the IDE and asks how the same Engram primitives should shape memory for support agents that must recall customers, policies, and prior tickets under much stricter isolation rules.