キャディ株式会社の技術ブログ

全234件

2026/06/25

AI Memory for Engineers: Choosing the right level before you build

Introduction Every AI session starts blank. You open a new chat, and you're back at square one: your preferred approach to error handling, the architectural constraint you settled on three weeks ago, the trade-off you already reasoned through and documented. None of it is there. So you explain it again. And again tomorrow. This is the baseline problem, and most engineers solve it eventually. But how they solve it is where things go sideways. The first failure mode is overreaching. Someone reads about vector databases, knowledge graphs, or shared memory layers and jumps straight to building that. Five hours of setup, a new dependency in the stack, and three weeks of maintenance later, they realize they just needed to paste some instructions into a config file. The problem was simple. The solution was not. That mismatch costs real time. The second failure mode runs in the opposite direction. A team builds a production agent system and stitches together memory as an afterthought: some context stuffed into a prompt, a few hardcoded facts, no real persistence strategy. It works at first. Five months later, the system needs to track state across users, or share knowledge between agents, or handle ten times the volume. Fixing it now means redesigning the memory layer from scratch, around code that was never built to accommodate it. Both failures have the same root: choosing a memory approach without a clear model of what "memory" actually means across different complexity levels. This blog is a map. It covers five levels of AI memory, from the session context that every tool ships by default up to memory-as-a-service infrastructure for multi-agent platforms. Higher level does not mean better. It means more capable in specific ways, and more complex to build and operate. The goal is to match the level to the actual continuity need, not to the most interesting solution in the space. Two groups of engineers will find this useful: Track A is engineers customizing a personal AI coding assistant: tuning Claude Code, Cursor, or similar tools to maintain context about their projects, preferences, and workflows across sessions. Track B is engineers designing memory for a production agent system: something customer-facing, multi-user, or running autonomously at scale. The five levels apply equally to both. Where the right stopping point differs between tracks, the post calls it out explicitly. What this article means by memory Memory is one of those terms that sounds obvious until you try to define it. Depending on who you ask, "AI memory" might mean conversation history, vector databases, user profiles, knowledge graphs, long-term storage, learned behaviors, agent state, or all of the above. Different tools and frameworks use the same word to describe very different things. For the purposes of this article, memory means information that survives beyond the immediate interaction and can influence future interactions. That includes things like: Past conversations and decisions User preferences and project context Facts extracted from interactions Documentation, notes, and research Entities, relationships, and historical changes In other words, memory is about preserving and retrieving information over time. There is another category worth mentioning: procedural memory. Procedural memory is memory about how to do things rather than what is true. Examples include deployment playbooks, investigation workflows, tool usage patterns, reusable execution plans, and strategies that improve through repeated use. Many modern agent systems rely heavily on this kind of memory. The reason procedural memory does not appear as its own level in this framework is that it cuts across several levels rather than fitting neatly into one of them. A deployment playbook might start life as a simple instruction file, evolve through observations gathered from previous executions, and eventually become part of a structured knowledge resource. The same procedural knowledge can exist in multiple forms depending on how mature the system becomes. This article therefore focuses primarily on information memory: conversations, facts, knowledge, decisions, entities, and relationships. Not because procedural memory is less important, but because it follows a different set of design concerns and would deserve its own discussion. With that scope established, we can look at the dimensions that distinguish one memory system from another. Memory has three dimensions Before we walk through the five levels, it helps to understand what makes them different from each other. The levels aren't a ranking. They're positions on a map, and the map has three axes. Depth The first is depth: how rich and structured is the thing being stored? At the shallow end, you have raw conversation (the literal back-and-forth that happened in a session). Move further along and you get extracted facts and summaries, where some processing has already been done to make the content useful. At the deep end sit interconnected knowledge graphs, where entities, relationships, and temporal changes are all modeled explicitly. Higher depth means more work was done to make stored information usable, and more complexity to build and maintain. It's not automatically better. A summary is faster to retrieve and cheaper to store than a graph traversal, and for many use cases that's exactly the right trade. Persistence The second dimension is persistence: how long does stored memory survive? Some systems hold context only for the duration of the current session. Close the window and it's gone. Others persist across sessions within a project, so you can pick up a conversation thread days later. The most durable approaches store memory permanently, independently of any session or tool: the information outlives whatever generated it. Scope The third is scope: who can access what's stored? At one end, memory is personal and sometimes locked to a single tool (only you, only in this editor). Some systems share memory across a team, so knowledge one person captured becomes available to everyone. At the widest scope, memory is exposed via an open protocol so any compliant AI tool can read from and write to the same store, regardless of vendor. The important thing is that these three dimensions are independent of each other. A system can have high depth but be session-only: a sophisticated knowledge graph that evaporates when the process exits. Another can be permanent but strictly personal, surviving indefinitely while staying locked to one user and one tool. Depth doesn't imply persistence, and persistence doesn't imply scope. The levels we're about to cover are anchors at specific positions on this three-dimensional map, not rungs on a ladder where the goal is to climb as high as possible. Memory level positioning Level Depth Persistence Scope L1: Session Minimal Session Personal L2: Instruction Low Permanent (manual) Personal → Team L3: Episodic Medium Project / Long-term Personal L4: Semantic High Permanent Personal → Team L5: Infrastructure High Permanent Team / Platform A note on levels versus architectures Before continuing, it's worth clarifying something that often causes confusion when people discuss AI memory. The five levels are not a strict hierarchy where each level replaces the previous one. They describe different combinations of memory representation, persistence, and deployment scope. The lower levels primarily differ in what is remembered: L1 stores recent context. L2 stores instructions and preferences. L3 stores experiences and interactions. L4 stores synthesized knowledge. L5 is slightly different. It does not describe a new form of memory so much as a new ownership model for memory. The memory becomes infrastructure that can be shared across tools, agents, and users. This means the levels are not mutually exclusive. An L5 memory platform might expose simple L3-style conversation summaries, a compiled knowledge base from L4, a knowledge graph, or all three simultaneously. Think of L3 and L4 as describing the shape of memory. Think of L5 as describing where that memory lives and who can access it. L1 and L2: The foundations L1: Session memory Every AI tool ships with some form of memory out of the box. Conversation history, project workspaces, the sliding context window keeping your recent messages available: it's all there without any configuration. This is L1. It solves exactly one problem well: continuity within a single session. Ask a follow-up, reference something you said ten minutes ago, iterate on a design: it all works. Zero setup, zero maintenance. The wall appears the moment you close the conversation. Start a new session the next day and everything is gone: no memory of the architecture decision you landed on yesterday, no awareness of the other three projects you're juggling, no accumulated sense of how you prefer to work. The slate is blank. For Track A , L1 is fine for one-off tasks and exploratory sessions where continuity genuinely doesn't matter. The mistake is staying here for work that spans days or weeks and then wondering why the AI keeps asking questions you've already answered. For Track B , L1 is always present as the foundation and is rarely sufficient on its own once continuity matters. Every agent system starts here. Most production systems eventually need more than this. Tools at this level (as of mid-2026) See the tools reference table at the end of this article for a fuller view. L2: Instruction memory The first meaningful upgrade is also the simplest: you write things down and make sure the AI reads them at the start of every session. This is L2. System prompts, rules files, project context documents, conventions lists: anything structured that loads automatically when a conversation begins. Some tools support hooks that inject these files without you thinking about it. Others require pasting them in or configuring a project workspace. The mechanism varies; the idea is the same. What L2 actually solves is the re-explanation tax. Every engineer who uses AI tools regularly has felt it: the first ten minutes of a session spent re-establishing who you are, what project you're on, how you name things, what you've already tried. L2 eliminates most of that. Write your preferences once, point the tool at them, and the next session starts with that context already in place. It scales to teams in a way that surprises people. A shared conventions file checked into a repository means everyone's AI assistant follows the same patterns (consistent naming, consistent code style, consistent architectural constraints) without anyone having to configure their tool individually. The file becomes a single source of truth that both humans and AI tools read. The appeal of L2 is that it asks almost nothing from you technically. No infrastructure, no databases, no vector embeddings, no background processes. Just files and text, working with mechanisms every AI tool already supports. For most engineers, this is where 80% of the "my AI doesn't know me" friction disappears. An important pattern appears once teams start using L2 and L3 together. Most decisions begin life as history. A discussion happens, alternatives are evaluated, a tradeoff is accepted, and a conclusion is reached. Initially that information belongs in L3 because it reflects something that happened. Over time, some of those decisions stop being history and become policy. "We chose SQS instead of Kafka" eventually becomes "Use SQS for asynchronous processing." At that point the information has effectively been promoted from L3 into L2. Healthy memory systems tend to do this continuously. Episodic memory captures what happened. Stable learnings are promoted into instructions. This keeps the memory layer compact while ensuring important decisions become durable guidance rather than forgotten conversations. The limitation is just as simple to understand: the instructions are static. They reflect what should happen, not what did happen. If the project evolves and nobody updates the file, the AI keeps following outdated rules. If a key decision was made in a session yesterday, it doesn't automatically appear in the rules tomorrow. L2 captures intent; it doesn't capture history. The moment you need the AI to remember what actually occurred across sessions, you've outgrown L2 and are looking at the next level. For Track A , this is the first upgrade almost every engineer should make. A project context file and a personal preferences file together cover the majority of continuity friction with minimal ongoing effort. For Track B , L2 is present in almost every production system, whether explicitly recognized or not. Every agent needs a system prompt defining its behavior, persona, and constraints. It's always present, even in the most sophisticated systems: other levels build on top of it, not in place of it. Tools at this level (as of mid-2026) See the tools reference table at the end of this article for a fuller view. L3: Episodic memory The problem that L2 doesn't solve is accumulation. You can write excellent instructions for how the AI should behave, but it still has no idea what you actually worked on last week. You re-explain the same project context. You re-share the same decisions. After a few months of this, the appeal of "the AI remembers what we've discussed" starts to feel less like a feature and more like a basic expectation. L3 is where that expectation gets met. The core pattern is simple: at session end, a background process captures what happened, processes and stores the content, and on the next session automatically injects whatever past context seems most relevant. No manual maintenance. The AI just gradually accumulates working knowledge of your projects, preferences, and decisions over time. The appeal is real. After a few weeks, the AI starts referencing things without being prompted: the architectural decision you made last Tuesday, the library you ruled out and why, the naming convention your team settled on. That kind of continuity changes how the tool feels to work with. The lossy versus lossless spectrum Before picking a tool at this level, there is one distinction worth understanding clearly: what gets stored, and what gets thrown away. On the lossy end, when a session ends an LLM reads the conversation and extracts key facts, decisions, and preferences into a compact summary. The raw transcript is discarded. This approach is token-efficient and scales well over months, since the stored memory stays compact regardless of how many sessions accumulate. The tradeoff is that you lose the ability to reconstruct what was actually said. You get a distilled view of the past, not the past itself. This works well for long-running projects where accumulated context matters more than exact recall. On the lossless end, the raw conversation is preserved and a searchable index is built on top. Full-text search, vector embeddings, or both. This enables exact retrieval: you can find a specific exchange from five weeks ago, reconstruct the reasoning behind a decision, or debug why an agent behaved a certain way. The cost is higher storage and more infrastructure. It suits audit trails and situations where "what was actually said" carries weight. Most mature tools today sit somewhere between these extremes. They may store verbatim content but surface LLM-generated summaries as the primary retrieval interface. When you are evaluating a tool here, it is worth checking both sides separately: what gets stored (the raw conversation, a summary, structured facts) and what gets surfaced at retrieval time (matched chunks, a synthesized answer, a flat list of facts). Those are often different things, and the gap between them is where retrieval quality problems tend to hide. How retrieval typically works At session end, the background process captures the conversation and splits it into chunks. Each chunk is converted into a vector embedding and written to a store. At the next session start, the current context (what you just typed, the project you opened) is used to query the store, and the top-matching chunks are injected into the context window automatically. Some tools add keyword search or hybrid retrieval on top for better precision when semantic similarity alone isn't enough. The quality of this whole pipeline depends heavily on chunking strategy and retrieval tuning, which is why two tools using the same underlying model can feel very different in practice. Where this level breaks L3 is primarily personal and local. Most tools at this level store memory for one user, on one machine, for one AI tool. Sharing that accumulated context across teammates, or making it accessible from a different AI tool, requires moving to L5. This is a meaningful constraint if you are thinking about team-level continuity. Language support is also worth checking before committing. Much of the tooling here was built with English-first assumptions, and retrieval quality for Japanese content varies considerably between tools. For Track A engineers, this is the main upgrade worth making. Once the setup is done it runs in the background. The value accumulates gradually and quietly, which means you probably won't notice it working until you realize you stopped explaining yourself so much. For Track B , this level maps to what agent frameworks call episodic memory: the record of what an agent has done in past interactions. The lossy-versus-lossless decision has clearer stakes here. A user-facing agent that makes specific commitments ("I'll follow up by Friday," "we agreed to disable that feature") may need accurate recall of those commitments, which pushes toward the lossless end. Getting this wrong in a production system tends to surface in support tickets rather than evaluation runs. Tools at this level (as of mid-2026) See the tools reference table at the end of this article for a fuller view. L4: Semantic memory Everything below this level is about remembering. L4 is about compiling. The levels before it capture what happened: which files were read, what preferences were stated, which decisions were logged. Useful, but passive. L4 takes raw material and builds something from it: a structured, interconnected knowledge resource that gets more valuable the longer you use it. The goal shifts from "remember this conversation" to "build something I can reason over." There are two distinct architectural models at this level. They solve different problems, require different infrastructure, and represent genuinely different design choices rather than variations on the same idea. The compilation model Think of this as an AI-maintained encyclopedia. Raw source material (research papers, documentation, articles, internal notes) arrives in an immutable input layer. An LLM reads that material and writes structured articles: encyclopedia-style entries with cross-references, organized by concept, updated as new sources arrive. The knowledge resource is the compiled output, not the raw sources themselves. The contrast with standard retrieval-augmented generation is worth being precise about. In a typical RAG setup, you embed raw documents and retrieve chunks at query time. The retrieved knowledge does not accumulate into a maintained representation. Every query starts from the underlying source documents, even if the retrieval layer itself becomes richer over time. In the compilation model, synthesis happens upfront. Articles build on each other, contradictions get flagged, and the index evolves as the domain does. The trade-off is scale. A flat index works well up to a few hundred articles, where the full index still fits in a context window and the LLM can check for gaps and overlap. Beyond that, hybrid retrieval becomes necessary, and the operational complexity grows with it. But for sustained research within a bounded domain, this model performs in a way raw retrieval simply cannot. This is the right choice for engineers doing months of sustained research in a specific technical area: a new language runtime, a framework you're adopting, a domain like security or distributed consensus where foundational concepts keep resurfacing. If you find yourself re-establishing the same background context you've already read through and summarized, L4 with a compilation model is the upgrade you're looking for. The graph model Where the compilation model produces readable articles, the graph model produces a knowledge graph: entities (people, products, decisions, concepts) and the relationships between them, with temporal indexing on every fact. The distinctive capability is temporal reasoning and multi-hop queries. Every fact in the graph carries a validity period. When something changes, the old fact is marked as superseded rather than deleted. This means you can ask "what was the customer's infrastructure configuration at the end of Q3?" and get the right answer, even if that configuration has since changed significantly. You can also traverse relationships across entity types: "which users are affected by this architectural decision?" or "what decisions did this team make during the incident period?" This requires a graph database backend, which adds real operational overhead compared to the compilation model. There is also a latency characteristic that matters for system design: entity extraction and relationship building happen in background processing, so newly ingested information is not immediately queryable. Write-then-read consistency is not a given. This is an architectural tradeoff, not a bug, but teams need to design around it explicitly. The graph model is the right foundation for agent platforms that need to track evolving entities across time: customer accounts, organizational structure, system configurations, incident timelines. Any use case where "what was true at time T" is a real query belongs here. On retrieval at this level Both models benefit from hybrid retrieval, combining semantic vector search, keyword matching (BM25), and graph traversal. Community benchmarks consistently show hybrid approaches outperforming any single method at scale, and the gap widens as the knowledge base grows. This is an implementation choice within L4 rather than a reason to prefer one model over the other. For Track A engineers: L4 is worth the investment when you are doing sustained research in a specific technical domain over weeks or months. Most people do not need it, and adding it prematurely just creates maintenance overhead. The signal that you are ready for it is noticing you keep re-reading the same foundational material because you cannot trust your notes to reflect the current state of your understanding. For Track B teams: this is the knowledge retrieval layer of any serious agent platform. The compilation versus graph decision is an early architectural choice with long-term consequences, because retrofitting temporal and relational reasoning onto a compilation-based system later is painful. Compilation is simpler to operate and the right default when relationship traversal is not a core requirement. Graph unlocks capabilities that are genuinely difficult to approximate otherwise. Tools at this level (as of mid-2026) See the tools reference table at the end of this article for a fuller view. L5: Memory infrastructure At this level, memory stops being a feature of a specific AI tool and becomes infrastructure. A dedicated memory store is exposed via an API or open protocol, and any compliant client can read from and write to it. The AI assistant no longer owns the memory; the memory layer does. This shift in ownership matters more than it might initially seem. At lower levels, memory follows the tool. If you switch tools, you start over. At L5, memory is independent of any tool. What one AI learned in one session, a different AI can access in the next. What one agent discovered about a user, another agent serving that same user already knows. The memory layer becomes the stable part of the system, and the AI tools sitting on top become interchangeable. The open standard increasingly used for this is MCP (Model Context Protocol), which defines a common interface for connecting AI clients to external services. A memory store exposed over MCP can in principle be queried by any MCP-compatible client, which gives you real portability between tools. Two variants worth distinguishing The first is shared personal memory: one person, multiple AI tools, one central store. Set up a database, expose it over MCP, and any AI client you use can contribute to and draw from the same pool of context. Your preferences, project history, past decisions: accessible regardless of which tool you open that day. If you use Claude Code for implementation, Cursor for exploratory edits, and a chat interface for design conversations, they all draw from the same memory. This is still relatively rare in personal setups, mostly because the setup cost is non-trivial and the benefits only become visible once you actually use multiple tools regularly. The second is shared platform memory: multiple users, multiple agents, one central layer with per-user isolation. This is the architecture for a production multi-user system. Memory is namespaced by user ID or organization ID. Each agent retrieves the right user's context at the start of an interaction and writes new context at the end. The memory store becomes a service with the same operational expectations as any other stateful service in your stack. Concerns that appear only at this level Several problems don't exist at lower levels and become real the moment memory moves to a network service. Latency is the first one to check. At lower levels, memory retrieval is local. At L5 it's a network call, and memory retrieval involves both a query embedding step and a vector search, which takes time. As of writing, some memory systems have retrieval latency in the tens of seconds at the 95th percentile under load. Putting that on the synchronous path of a user-facing agent produces visible delays that users notice immediately. Verify latency characteristics before committing to a system, and where possible design retrieval to run asynchronously or speculatively before it's needed. Multi-tenancy isolation is the application's responsibility, not the memory store's. The standard pattern is to namespace every memory entry by user ID or organization ID and enforce that boundary on every read and write at the application layer. This sounds simple and is worth getting exactly right. A failure here doesn't just produce wrong answers; it exposes one user's context to another, which is a trust failure that tends to get noticed. Data residency and ownership become real operational questions. Running an L5 memory layer means operating a database containing user context: where it lives, who has access to it, what happens when a user deletes their account, how long data is retained and why. These questions have answers at smaller scale too, but at platform scale they need written policies and enforcement. Self-hosted deployments give full control at the cost of operational burden. Managed cloud services trade that control for simplicity. Neither choice is wrong; it's worth making it explicitly rather than by default. Cost compounds at scale. Storage, embedding computation, and retrieval operations all carry per-operation costs that are easy to ignore during development and harder to ignore once real users arrive. Where it breaks The hardest memory bugs in AI systems tend to live here. Stale memory that contradicts current reality, with no clear way for the agent to know which source to trust. Contradictory facts written by different agents into the same store, with no reconciliation. Isolation failures that are silent until they cause a visible problem. None of these are unsolvable, but they require deliberate design rather than optimism. L5 is also real infrastructure with real overhead. For personal use, the setup cost rarely justifies the benefit unless you genuinely use multiple AI tools and want one shared context layer across all of them. Most individual continuity needs are covered by L3 at a fraction of the complexity. For Track A , this is probably not where to invest time right now. If you use only one AI tool, or your tools don't yet support MCP-based memory retrieval, the abstraction adds cost without benefit. It's worth keeping an eye on as tooling matures. For Track B , this is where a new architectural conversation begins: memory is no longer just something agents consume, but infrastructure that other systems depend on. The decisions made here (what protocol to use, what database to run, how to handle isolation, how to manage retrieval latency) shape everything built on top. The mistake to avoid is designing agents first and memory last. Memory architecture is a prerequisite, not an afterthought, and retrofitting it into a system that wasn't designed for it is significantly harder than getting it right from the start. Tools at this level (as of mid-2026) See the tools reference table at the end of this article for a fuller view. How to pick your level Routing guide The framework is best thought of as a map rather than a maturity ladder. L1-L4 describe different forms of memory. L5 describes when memory becomes shared infrastructure Personal use (Track A) Start at L2. A well-written system prompt and a project instructions file cover most of the friction engineers describe as "the AI doesn't know me" or "I have to re-explain my setup every time." Most people underestimate how far this gets them before anything more complex is needed. Add L3 or L4 when losing context across sessions becomes genuinely painful: re-explaining a decision you made last week, re-establishing which branch of a design you landed on, re-orienting the AI to where you left off on a project. That's the signal. Not "this might be useful someday" but "this is costing me real time right now." Consider L4 if you're doing sustained research in a specific domain over months and you want knowledge to accumulate and stay findable rather than scattering across session summaries. Not every engineer reaches this point, and that's fine. L5 is rarely worth the setup cost for personal use. The main case where it makes sense is if you actively use multiple AI tools and want one shared context layer across all of them. If you use one tool consistently, L3 handles continuity at much lower complexity. Agent platforms and production systems (Track B) L2 is mandatory. Every agent needs a system prompt, behavioral guardrails, and clear instructions about what it should and shouldn't do. Treating this as optional produces agents that behave inconsistently under novel inputs. L3 gives agents memory of past interactions. The lossy vs lossless choice matters more here than in personal use: too much context and you hit cost and latency ceilings; too little and the agent feels stateless in ways users notice. Getting that balance right requires profiling real usage, not guessing at design time. L4 is where agents go from retrieving chunks of text to reasoning over structured knowledge. The compilation model and the graph model serve genuinely different use cases, and the architectural consequences of that choice compound over time. It's worth thinking through carefully before committing. If L5 is likely to be part of the future architecture, it is worth recognizing that early. Retrofitting shared memory infrastructure into an established platform is usually more expensive than planning for it upfront. Quick routing "I just want it to remember my preferences": L2 "I want it to remember what we worked on last week": L3 "I want to stop re-explaining domain background": L4, compilation model "I need it to track how something changed over time": L4, graph model "Multiple agents or users need shared context": L5 Choosing the right level solves the architectural question of where memory should live and how it should be represented. In practice, however, selecting a level is only part of the challenge. As memory systems become more capable and accumulate more information, a different set of concerns begins to dominate: memory quality, lifecycle management, governance, and trust. Cross-cutting concerns The levels in this framework describe where memory lives, how long it survives, how structured it becomes, and how broadly it is shared. Some challenges, however, appear regardless of which level you choose or combine. In practice, these concerns often have a larger impact on system quality than the choice of storage technology or retrieval algorithm. They emerge as soon as a system starts remembering information, and they become more important as memory accumulates over time. Memory consolidation: how information moves between levels The framework can make the levels appear static. Real memory systems are usually not. Information tends to move between levels as its importance becomes clearer. A conversation starts as an interaction. Parts of it may later be summarized. Important facts may be extracted from those summaries. Over time, stable facts may become structured knowledge, and repeated lessons may eventually become instructions or policies. Conversation → Summary → Fact → Knowledge → Instruction This process is often called memory consolidation . Human memory behaves similarly. Individual experiences become generalized knowledge. Repeated observations become habits and rules. Most long-term knowledge does not enter memory in its final form; it evolves through successive stages of refinement. Modern agent systems increasingly follow the same pattern. An agent may initially record every interaction, but storing everything forever is rarely useful. As memory grows, systems need mechanisms that transform information into more compact, durable, and reusable forms. The goal is not simply to remember more. The goal is to remember the right things. The challenge is deciding what deserves promotion. Promote information too aggressively and important nuance disappears. Promote too little and memory grows without bound, making retrieval slower, more expensive, and less reliable. As memory systems mature, consolidation often becomes more important than storage. The question shifts from: How do we remember more? to: How do we remember what matters? Memory quality becomes the real problem Most discussions about memory focus on storage and retrieval. Which vector database should you use? How should chunks be split? What embedding model performs best? Those questions matter, but they are rarely the first thing that breaks. The moment a system begins writing memory automatically, a different problem appears: memory quality. The agent may misunderstand a conversation and extract an incorrect fact. A user may change their mind while an outdated preference remains stored. Two agents may write contradictory information about the same entity. A hallucinated conclusion may be captured and later retrieved as if it were established truth. The risk exists at every level beyond simple instructions, but the consequences become more severe as memory becomes more structured and more widely shared. At L3, an incorrect memory may simply cause a future conversation to start from the wrong assumption. At L4, that same incorrect memory may become part of a structured knowledge resource, influencing future reasoning and synthesis. At L5, the problem expands further. Incorrect or contradictory memories can propagate across multiple agents, tools, or users, turning a local mistake into a system-wide one. This is sometimes described as memory poisoning, but the underlying issue is broader: a memory system is only as trustworthy as the process that decides what enters it, and what stays in. As systems mature, questions like these become increasingly important: Who is allowed to write memory? Can memories be edited or deleted? How are contradictory memories reconciled? Should memories expire automatically? How much confidence should be attached to a stored fact? Should users be able to inspect and correct their own memory? The retrieval pipeline matters. The quality of what enters the pipeline often matters more. What the levels don't capture The framework is useful for making architectural decisions. It's less useful for a few problems that cut across levels. Self-improving agents (systems that rewrite their own behavioral instructions based on experience, blurring the boundary between L2 and L3) are a real design pattern that doesn't fit cleanly into any single level. The tooling around this is still maturing. It's worth following, but not worth building on top of today unless you have a specific reason to. Team memory governance is a policy problem, not a technology problem. Once memory is shared at L5, questions emerge that no level framework answers: who owns a memory entry, who can delete it, what happens when someone leaves the team, how long things are retained and under what legal obligations. The levels tell you what to build. They don't tell you how to govern it. The ecosystem moves faster than the framework does. Specific tools and platforms will look different in a year. The architectural decision (which level) is more durable than the implementation choice (which specific tool). When something changes in the ecosystem, revisit the tools. Revisit the framework only if the underlying problem has actually changed. Closing The most expensive mistake in building AI-assisted systems isn't picking the wrong tool. It's picking the wrong level and spending months building on top of it. If you're customizing a personal setup, starting low is genuinely the right call. The path from L2 to L3 is easy, and the friction tells you when you're ready to move up. If you're building a production agent system, the advice is different. You can implement incrementally — you don't need everything on day one — but you should think about your target level upfront. L5 shapes the entire memory architecture. Discovering mid-build that you need multi-tenancy or cross-tool access isn't an upgrade; it's a redesign. Know where you're heading before writing the first agent, even if you build toward it gradually. Tools reference Examples as of mid-2026. This space moves fast — treat this as a starting point for evaluation, not a definitive list. Many of the tools listed below span multiple layers and do not fit cleanly into a single category. Their placement in this table is intended to be indicative of their primary focus, not a definitive classification. Level Example tools Pattern they represent Watch out for L1: Session memory Claude Projects, ChatGPT, Gemini Workspace, Cursor, GitHub Copilot Platform-native session memory, no additional setup Memory resets at conversation end; nothing persists across sessions L2: Instruction memory CLAUDE.md / system prompts (any tool), Claude Code memory hooks, Cursor .cursorrules, GitHub Copilot instructions Structured instructions loaded at session start — human-written, static Instructions go stale if not maintained as the project evolves; doesn't capture what happened, only what should happen L3: Episodic memory Mem0, MemSearch, MemPalace, Hermes Agent, claude-mem Automatic session capture with retrieval injection — lossy (summaries) to lossless (verbatim + index) spectrum Language bias: many tools have English-first retrieval quality; verify before committing for non-English content L4: Semantic memory Compilation : LLM Wiki (Karpathy pattern), ktundwal/librarian Graph : Zep / Graphiti, Cognee, LangMem, Hindsight (local) Compilation model compiles raw sources into a maintained encyclopedia; graph model extracts entities and relationships with temporal indexing Compilation: scale ceiling around 200-500 docs before hybrid retrieval is needed. Graph: write-then-read latency due to background processing. LangMem: 59s p95 search latency — background use only L5: Memory infrastructure OpenBrain, AWS AgentCore Memory, Google Memory Bank, Any of the L3/L4 solution you would self-host and share or go with their cloud offer if any Memory as infrastructure exposed via MCP or REST — persists across tools and users Retrieval latency is now a network call (verify p95 before using on sync path); multi-tenancy isolation is the application's responsibility; data residency requires explicit policy decisions

キャディ株式会社 の技術ブログ

コンテンツ

キャディ株式会社の技術ブログ