Context Is All You Need: Context Engineering for Agents

This English version was machine-translated from the Chinese original. Technical terms may require verification.

Introduction: from maps to manuals

Yes.From Memory Generation to Memory Governance: A Panorama of Age MemooryIn the same way, I have broken out the three layers of Agent Memoory: L1 full context (knowledge is directly in the current window, supported by long context and KV-cache), L2 external memory (portrait library, file system, external non-parameter memory in knowledge mapping), L3 parameter memory (invisible knowledge of encoded weights).

The main character of the article is L2, which is how long-term memories are formed, organized, updated and invalidated. L1 this part, I left a simple explanation:At the current reasoning, how exactly is the information selected, compressed, isolated and deployed?

This article goes on to say the portal. Memoory, the landscape is more like a map."What are the long-term memories of?";to replace this with a more engineering question: In the real Age Runtime, attention is limited, information is read, how can it be retained, and how can it be left through the current window?

How the tasks, examples and output compacts in a single request are organized, and more basic Prompt and context learning questions can be consulted first" Intense engineering and context learning "I'm sorry. This document continues to be moved down from multiple rounds, long missions and running hours.

Before the text begins

The text will speak from storage structure to running time method. Three things first: which floor is this piece on the whole series, what is the context work here, and why the context should be considered a limited resource that needs to be moved.

Three parts on division of labour: maps, manuals, dismantling

The article and the two articles before and after it are a set but divided between them. The Age Memoory Panorama is a research perspective that discusses how long-term memory can be formed, organized, updated, invalidated and evaluated. This paper is written to discuss how information under the limited attention budget is entered and left through the current window in a runtime; and the products and framework of the Age RunteTardtown, which is common on the market, how these programs are assembled.

This paper will be completed at the project level, with a clear description of the common techniques, but not a product-by-product evaluation. When you read a mechanism, if you want to know how the system works, how the code is written in each line, the answer is in the textdown.

By the language of CoALA (seeFrom the cognitive structure of an intelligent body to the framework of an intelligent bodyEssentially, the discussion here is about engineering management of Working Memoory: what goes in, what stays in, what goes out, what goes back, what goes back when needed, and the collateral constraints and engineering techniques behind these moves. As long as the bottom is still an attention mechanism and limited window, these actions will not be able to be bypassed.

Strictly separate LLM Memoory from Agent Memoory

Before discussing the schedule of running, a common confusion was removed: KV-Cache, RoPE, Attention Variant, Long Context Structure, which LLM Memoory addresses how models have a longer and more effective context window; and Agent Memoury addresses how intelligent bodies accumulate, retrieve, update and forget knowledge across missions. The former is a reasoning infrastructure, while the latter is a system design. The thinking on the two types of problems is very different and the relevant studies are very different.

L1 's physical base is LLM Memoory: how much windows can be placed, how high the prompt cache hits, how expensive the decode is, is determined by the model structure and reasoning infrastructure. Why output token more expensive than input, prefill and decode asymmetrical, KV-Cache how to eat the display and dispatch slots, and how to organize the context to be KV-Cache friendly, I'm here.Why Output Token is more expensive: from KV Cache to Agent Cost ProjectIt's been spoken to alone.

L2 is the subsidiary structure of Agent, but it has to work through L1: any external memory must end up in the context window of reasoning to influence the way forward. So when discussing Argentina Memoory, you can't circumvent the infrastructure constraints of L1. In short, LLM Memoory decides how big and expensive the workstation is; Argentina Context Engineering decides when external information will come in, when to leave, and what to put on the workstation.

Context is limited: Context Rot and Focus Budget

The motivation for Context Engineering is straightforward: context is limited and degradation usually occurs earlier than instinct. Many studies point to the gap between intuition and reality.

Greater windows are not the same as better use. ♪ Back in time ♪ Lost in the Middle There is a re-proven phenomenon in which the model uses information at different locations in the context, where information at the beginning and end is more easily used and where information at the middle is often ignored, even in the context model.

Chroma's Context Rot Eighteen models were measured and the conclusion was quite consistent: performance is degraded with the increase in input length and degradation is uneven and often occurs in unexpected locations. The NIAH test may not accurately reflect the long context of LLM, and the performance may have deteriorated earlier than we thought.

And the counterintuitive is that they find a coherent oriback rather than a disorderly orithack. That is, to make context more appropriate sometimes undermines retrieval performance. There's no simple one here."Fill it up and fall."Thresholds, recall is an already difficult issue to predict.

Anthropic is here. Effective context engineering for AI agents It breaks down into two concepts of resistance: the model benefits from sufficient information and can also be corrupted by the Transformer structure.

Both the company, the notes and the subagent are essentially looking for a smaller and higher set of tokens to maximize the probability of achieving the target.

That is the premise of all the options that follow. The context is corrupt, attention is budgeted, so..."Where's the information?""How?""How do I write it?""When will you be quarantined?"It is not a matter of adding to the costs, but rather of dealing with complex tasks. The structure of memory, retrieval and writing, and some engineering techniques are discussed separately.

Subject Path: First ascertain the memory object and the memory carrier

First read storage. But don't ask who you're using, first ask what the person Agent is reading and writing while running. The Memoory Panorama has explained why different memories fit different carriers: closely related semantic knowledge fit maps, operational experience and specifications fit documents, and factual records fit the relational database. Instead of repeating the selection rationale, this discusses how it is done in engineering and how these carriers together serve the movement of the current window.

It is easy to describe problems as tool selection if we start talking directly from the vector bank, the chart database, the file system. The real concern of Context Engineering is another thing: how information stays out of the window in manageable form and how it can be assembled back into the window with the smallest signal if needed. This section therefore defines the memory object and discusses how it projectes to vector indexes, full text indexes, graphs, files and relational databases.

Memoory Object connects data structures with Metadata

Whether ultimately located in a vector bank, database, chart or file system, the basic unit for reading and writing on the run should not be an unregulated whole piece of text, but a memolly object with metadata. A memory object needs at least these fields:

• type: persona, review, experience, knowledge, rule, etc.
• scopeUser level, session level, project level, global level.
• content: The facts, rules, experience or summary retained.
• source: From which dialogue, which tool to call, which external material.
• timestamp: Writing time and last update time.
• confidenceHow sure is this memory?
• statusThe blog is based on the following: active, stale, conflified, dewed.
• links: It repeats memories, conflicts, inheritances or subside.

The Memoory Panorama lists six questions to answer on the side of writing: what to write, where to write, how to write, how to update, when to fail, when to write. This field table contains these decisions.

status and links The text is in conflict with the semantics of the conflict.timestamp and confidence Expressing time limits and uncertainty. Without these metadata, it is difficult to update the later version, to resolve conflicts, to delete and to roll back.

These fields will also enter the metadata filter in the next chapter and will be used to preserve the program. Read and write two paths here.

After you have identified memory object, then you can see the storage carrier a lot. Relationship databases, vector indexes, full text indexes, diagrams and file systems are not necessarily alternatives to each other, more like different projection of the same memory. The relational database provides operational factual sources that are responsible for preserving the object itself, its rights, status and version; full-text indexes for precise words and numbers; vector indexes for cross-expression recall; maps for relationships and paths; and document systems for readability, editing and recovery.

Do not let the vector bank be the only source of fact. The vector bank can answer what is similar to this query, but it does not know whether the memory is expired, replaced by a new version, belongs to the current user, and can be quoted in the answer. Storage structures need to preserve governance syntax before projecting different search capabilities. The core of the latter is the boundary, whether it is based on SQLite, LanceDB, Postgres, chart databases or file systems.

In particular, systems like LLM Wiki also study knowledge structures and think about how to better store and recall, but not here. They are more like knowledge deposition systems or independent technological experiments, which can be analysed in separate articles. This paper is concerned only with more fundamental engineering issues: how a runtimeme can manage external memory and how to use it selectively in the current window.

Vector Embedded Semantic Search

Vector index is an important projection of memory object and an entry to traditional RAG. But don't think of it as a text that would make AI smart."Semantic Search Box"I'm sorry. When the actual landing is made, the effect is often not dependent on the database name, but rather on a few more simple things: how the document is cut, how the vector is generated, how the index is built, whether the original text and metadata are retained, and whether it will be locked to death in the future when the model is changed and the library is exchanged.

These bottom options are discussed, followed by the three-tier project.

Vector embedded search alerts

Vector embedded search solves a very specific type of problem: mapping query and document clips into the same vector space, and then finding candidates close to semantics with distance or similarity. Natural language rewriting, blurring needs and cross-expression recall are areas where it is good at doing so. The exact matching of the error code, the function name, the contract clause number, the name, the project code, etc., is often missed by dense embeding alone. Then there's the mix, and here's just how the vector bank itself is built.

Chunging is the easiest to underestimate. Fixed length is the most economical, but easily cuts the title, table, code block and paragraph relationships; and is more stable by structure, for example by the Markdown header, paragraph, function, chapter, page or table unit.

Cheunk is too big, vectors become a symmetrical body of words, and really useful sentences are diluted; chunk is too small, and it throws the context, and when recalled, it is filled in by a close section or a parent document. The more stable way is to get small chunks to hit and then use title paths, page numbers, chapters, parent files id to fill in the context. chunk should not be a nudity text, but a search unit with a reference.

Embeding models can't be picked by hand. The generic model can cover many documents, but texts such as codes, medicine, law, internal systems have their own terminological density. The higher the dimension, the better it is, it directly affects storage, memory, index construction and retrieval delays.

More problematic is the governance of the version. The old and new vectors are usually not compared together. At least we'll have to record it. embedding_model、embedding_dim、distance_metric And the index version, otherwise the question of recall will be painful.

Index layers are also trade-offs. Small data volumes can be exact KNN, i.e. all vectors are measured over time, simple, interpretable, and are slow when size comes up. ANN trades speed with approximation. HNSW is usually well recalled, fast search, but it is more sensitive to eat memory, build and parameters; IRF first has a vector sub-bunk, then search in the relevant drum, and memory and speed are more manageable, but needs training or clustering, and recalls more dependent on parameters. There's no magic button here. You're balancing delay, memory, construction costs and recall rates.

Metadata and protocol also need to be retained while writing. The vector bank returns only similarity and does not naturally know which tenant, which project, which version, which page, whether it has been deleted and whether the user has access to it. These information are not structured at the time of writing, and only patches are used to retrieve it. At least keep it. doc_id、chunk_id, title path, source URI, page number or line number, update time, permission label, deleted status and parser version. RAG answers are retroactive, otherwise recall or re-certification is difficult to access.

The evaluation should be done earlier. Don't just look at the demo problem. Prepares a set of real querys, covering semantic rewrite, precise terms, cross-document, no answers, old version, new version, tables and code blocks. See if Recall@k, MRR, citation supports the answer, and whether deletions and privileges are valid. Many of the problems with vector retrieval are not related to the model, but are the document's resolution error, chunk cut, metadata missing, or the evaluation sample is too clean.

3-deposit base I: Local-first: SQLite + FTS5 + sqlite-vec / sqlite-vs / vec1

If the target is local Agent, personal knowledge base, offline tools, or small teams run through traditional RAG, SQLite is a very practical starting point. It does not win by the performance ceiling, but by doing little: document tables, chunk tables, metadata, index status, deletion status, task records can be placed in a local database and distributed with application.

SQLite FTS5 is an official full-text search extension, with bm25() Sorts the function. It is a fitting addition to the short board of dense embedding: precise words, numbering, abnormal code, product name, regime terms.

The vector side has three directions, with different maturity.sqlite-vec It is a third party SQLite vector extension, pure C, less dependent, suitable for local embedding; but it is still pre-v1 and is also called by project documents to accept interface changes sqlite-vss The succcer.sqlite-vss The author has turned his main energies to the path of the earlier based on the Faiss. sqlite-vec, the new item is not suitable for use.

vec1 is an official SQLite new vector extension, and the document already lists the ANN, L2 and COSINE interfaces, and reminds that testing and optimization are not adequate. The direction is of concern, but the first edition is preceded by the validation of language binding, the release of rhythms, platform packing and indexing capabilities.

This route is best used within a small boundary: one bank per user or one bank per project. When searching, you can run FTS5 and vector search in parallel, then simply integrate and rerank at the business level. The border is also narrow. SQLite is not suitable for high-salter, multi-tenant, centralized audit services; vector expansion is evolving; and authority and index consistency are self-regulated. It's the most comfortable location, the local-first infrastructure, not the corporate search platform.

The upgrade signal is also clear: multiple people share, centralized access, back-office index queues, Query audits, cross-project statistics, or local documents are not available for distribution. At this point, we should go to service.

3rd Retrieval Base Two: Light Service: LanceDB

LanceDB can be placed between SQLite and heavy search infrastructure. It can still run locally and can be easily deployed in light, but the path of vector search, full text search, hybrid search, rerank is more direct. The hybrid search in the official document is to merge the candidate for the full-text search and sort the reranking algorithm. This road saves much more than it does from a zero-sum FTS, vector index and integration logic.

I'd rather understand it as a little bit of a search layer service. Original documents, chunk metadata, permissions and task status can still be placed in Postgres or in a business database, LanceDB is focused on searching for indexing. The boundary is thus clearer: the operational facts are located in the business library, the search capability is given to the search component, and the answer generation layer is presented only with a candidate in a uniform format.

But it will not handle authority, audit and mapping for you. Multi-tenant segregation, ACL filtering, de-dispersion, index re-establishment, preferably still controlled by external services. If the team has decided to do in-house knowledge-base services, rather than single-phone tools, LanceDB is a good transition layer: more service-like than a pure SQLite, and less than a large vector database.

The signal of continuing up is data volume, co-dispatch, tenant isolation, SLA, backup restoration, search operation starting to become routine. By then, the Retrieving Layer will no longer be a library, and it will be necessary to consider more specialized vector databases or search platforms.

3rd Retrieval Base: Postgres-centered service: Postgres + pgvector + FTS / ParadeDB

I'll give a serious look at Postgress at the internal service stage. The reason is so simple: many teams are using it to manage users, privileges, document metadata, assignments, audits, versions and deletions. The integration of part of the traditional RAG capacity into the same database ecology is usually more stable than the introduction of additional service packages.

pgvector Bring vector similarity to Postgres, support actual search, and support HNSW, IVFFlat, such index. Postgress, bring your own full text search. tsvector、tsquery, the ranking function handles keyword recall. This allows document fact sources, privileges filters, consistency of services, vector search, full text search to remain within a database and SQL boundary. This is more useful for the internal knowledge base than drawing an additional component.

But Postgress is not a complete search engine. The Postgres FTS experience and the Elasticsearch/OpenSearch type of search platform are not the same; the integration of dense + provisional usually involves writing SQL or business organization; and the extended boundary of the dedicated vector bank is higher when data is particularly large.

If you want to get more close to search engines BM25, faceted search, hybrid search, you can focus on ParadeDB pg_search Route. It's attractive to break the system into several services, while filling some of the short boards of Postgress original searches.

This layer is suitable for small teams to medium-sized internal services, especially for those with experience in Postgress, and for a very sensitive mandate and audit scenario. In the future, Qdrant, Milvus, OpenSearch, Elasticsearch, Neo4j, of course, are available, but that is essentially an area of dedicated search infrastructure or drawing infrastructure that requires more definite scale pressure and transportation inputs. For the modest engineering RAG discussed here, it's enough to eat all three floors first.

These three stories are about how to build the traditional RAG storage and index base. They are not three sets of mutually exclusive programmes, but three phases of the engineering boundary that vary with size: Locally, the search layer is removed when the matter is done lightly, and internal service phases put authority, audit and service consistency back into the stable business database ecology. When the bottom is built, how do you really determine the quality of the current window, such as thinner and denser mix, metadata filter, query rewrite and rerank, to be included in the next chapter?

Image storage: verify the proceeds of the map retrieval before selecting the chart data Library

The difficulty of the figure is not to search, but to turn unstructured text into a chart and how the figure is updated with the new information. Entity relationships are drawn to answer who, to whom, what relationship, when and usually a round of LLM calls. This is a qualitative step to determine whether the map is usable; it is wrong to extract it, and it is only the wrong side to reason for it.

Runs through the time to control the number of jumps and fan out. Multiple connections are the strength of the map, but they run in an unlimited fashion, and hundreds of nodes will soon be drawn into the pool and eventually broken."The smallest high signal set."。

Incremental updating is a problem: physical decomposition, judgment."Wang"and"Manager Wang"Is it the same node; it also addresses the border limitation period and determines whether the old relationship has lapsed.

Phase 1: Validation of the proceeds of the search of the map with LightRAG

So the image storage should be from"Is the relationship question really a search for a map?"Start. You can save simple in SQLite or Postgress at an early stage entity、relation、mention、chunk_link Table, as a projection of the auditable relationship. It can also be a little more temporary, with default storage of JSON, NetworkX, memory maps, LlamaIndex, or light storage of the LightRage Runner Experiment. This is not elegant, but it is sufficient to verify many questions: whether the entity is stable, whether relationships are abstract, whether users are really asking questions about jumps, whether the intention to recall is better than BM25 + dense + rerank.

Lightrag is suitable for the first round of the yield validation. It wraps entities, relationships and chunk search into more direct Graphrag channels and provides local、global、hybrid、naive、mix Such search mode.

The most useful thing here is that it makes you compare quickly."Only traditional chunk vector search"and"And we'll put the structure in the recall."Difference. Like what? naive The RG baseline is a similar tradition.mix The results of the local, global and naive results are combined and are more suitable to see if the map search actually gives the current text an additional signal.

It is also an interesting stand-alone project in itself. If you just run a good RAG MVP as soon as possible, or you want to do some RAG research, it's a good choice.

This is not the time."Accessed to the chart database"For acceptance, it is important to output a replicable set of judgements: which query really needs, which entities and relationships are stable, which multiple jump paths explain the answer, which errors are extracted instead of retrieved. The acceptance is also simple: on relationship, multiple jumps, cross-documentation, does the Graphragm have a steady rise over BM25 + dense + rerank; if it looks good for only a few demo, let it stay in the experiment.

From the perspective of Context Engineering, the value of light-scale mapping search experiments is to teach the system one thing: when should relationships be raised to work Memoory, when only the original chunk is needed. Only this choice is right, and the picture is saving attention from budget, rather than moving more structured noise into windows.

Phase 2: Neo4j as a real mapping infrastructure

If the chart search proved to have a steady gain, the next step would not necessarily be immediately on Neo4j. This type of chart database is meaningful only when the mapping becomes a core asset or it is reused by multiple functions. The core change here is that the figure is no longer just a recall channel for RAG, but a basic type of data that can be accessed, maintained, explained, operated in the system.

Neo4j values in maturity. It has a complete property graph model, Cyber query language, visualization tool, algorithmic ecology and relatively mature dimensional pathways. For long-standing entities such as organizations, people, projects, clients, contracts, systems, risks, processes, Neo4j can upgrade relationships from extraction support to structured assets that can be used by both product and business systems.

It's also approaching the Graphrag. Neo4j supports vector index, which allows the enbeding to be checked for vector similarity on node properties; Neo4j Graphrag Python provides retriever, Text2Cyper, Hybrid Retrieving and LLM combinations for Neo4j. So, Neo4j is not just a map that goes back to the back, but it carries a part of the vector recall, the drawing recall and the Cypher query, and pushes the Graphrag from experimental tools to a more stable service boundary.

But it does weigh. The introduction of Neo4j implies a high cost of transportation by carefully designing the schema, binding, indexing, privileges, backup, migration, incremental synchronization and removal of dissemination. Neo4j's reasonable location is"The mapping has proven to be a long-term asset, so it requires a real mapping infrastructure."I'm sorry. Before that, Lightrag was more like a low-cost probe; Neo4j was the carrier after the validation. FalkorDB, Memgraph, can also be a candidate for the light-chart service outside Neo4j, but it will not be started here.

File system: Directory layout and navigation

The file system is an undervalued memory carrier, but its value is not just a cheap text. For Agen, the file system is more like a memory protocol layer for Age-native: Agen is born read / writeHe's running. glob and grep, and will navigate along the path, directory, filename and Markdown heading.

The path itself can be indexed, and Markdown itself can be a memory format that both people and Agent can read and write. The project focus is not just on content, but on having Agent navigate efficiently without having to pull all of it in the context once and for all.

And that's why many of the real tools are being used to take off Markdown in the warehouse as a context agreement. Claude Code. CLAUDE.md Loading the context of the project, also supporting auto memory; Codex AGENTS.md Do a layer command; Gemini CLI use GEMINI.md。

GitHub Copilot support .github/copilot-instructions.md and path levels; Cursor Rules put the rules In .cursor/rules/*.mdc。

These documents are different, but in abstraction very close: to place stabilization rules, project engagements, catalogue knowledge and work preferences where they can be found when Agent is started or retrieved as needed. Claude's memory tool goes further, making cross-conference memories a read-and-written catalogue of documents that Agent reads back when needed, rather than stuffing all memories with windows in advance.

File-type memories are best layered, not all Markdowns mixed into one pot.

• Stable command level: for example CLAUDE.md、AGENTS.md、GEMINI.md、.github/copilot-instructions.md、.cursor/rules/*.mdc, suitable for project engagement, framework boundaries, test commands, code style and long-term operating rules.
• Evolutionary notes: for example NOTES.md、auto memory、/memories/*, suitable for putting out cross-session knowledge that Agent has deposited from error correction, user preferences, project facts and recurring questions.
• Run-state worklevel: for example todo.mdThe following is a summary of the current mission's objectives, stage status, failure and retrievable references:

The life cycle of these three layers is different. The stabilization directive should be clearly maintained by humans and cannot be adapted by ad hoc conclusions in a single mission; an evolutionary note can be updated by Agent, but requires provenance, time stamp and conflict management; operational working papers are closer to the spill of Working Memory, and can be archived, compressed or discarded after the mission has ended. The hierarchy is meant to prevent temporary scratchpad from being upgraded to a long-term reality and to prevent the memory-sharing norms that Agent automatically writes about.

The file system also has the advantage of being a vector bank that is difficult to replace: it is natural to govern. The file can diff, it can code review, it can roll back, it can be isolated, it can be directly edited by humans. This visibility is important for such memory as rules, experience, operational manuals, project engagements, which require joint maintenance. Blackbox index may be better at retrieving similarity, but it's not very good at explaining."Why does this rule exist, who changed it, when it came into force, can you delete it?"I'm sorry. The file system has returned these problems to at least one mature engineering stream.

But the file system memory does not automatically load all Markdown in the context. A good file system is not a longer program, but a clearer navigation: the entry file is short, the directory is structured, the name is predictable, the text is subject to grep Hit, long document keeps the directory, title path and reference link.

The session starts with a stabilization entrance only and is then carried out by path when details are required; only the filename, line number, URL or summary is kept when not required. This is just-in-time, as is the way to retrieve vectors and to project the L2 memory into the L1 workstation.

Its particular advantage is that humans and Agent can jointly maintain the same text structure, at a much lower cost than the database. Its shortcomings are also evident: it is basically suitable for local Single Agent governance.

Read Path: From external memory to Working Memoory

With storage structures, the next step is to re-take external information back to the current reasoning site. The previous chapter dealt with how external memory was captured as manageable objects and projected into the relationship library, full text index, vector index, chart and file system. Read Path is concerned with the other side: how, when the mission happened, Runtime drew a small amount of evidence from these projections, allowing them to enter Working Memoory with source, permission and version of information to guide real decision-making. Here's the engineering link.

Search is Pipeline, not a search call from Search

From the perspective of Context Engineering, search is not a search API call, but a whole process of Rewrite / Select / Compress. There may be a lot of relevant information in the external memory, but only a few high-level segments are required for the current window.

A slightly more complete read path, probably:

query / task state / scope / ACL / time
  -> query plan
  -> retrievers
  -> hard filter / fusion / dedup / rerank
  -> compression / evidence pack
  -> Working Memory

Each step here follows the previous storage structure.scope、ACL、status、timestamp、links The decision whether the candidate is visible; the full text index, vector index, chart and file system determine whether the candidate is found; the decision is made whether the candidate is able to enter the answer; the version and conflict information determine whether it is marked when entering Working Memory or whether it is screened before entering.

The RAG was first presented with a focus on combining the memory of parameters with the non-parametric memory that can be updated. But the real search boost is more than just..."Vector Library + Generating Model"There is also a need for a pipeline that can be divided, replaced, assessed and governed.

That explains why Red Path will pick up Write Path after. Promotion is simply a temporary projection of external evidence into Work Memoory to serve immediate tasks; it is Persistence that brings back new facts, new rules, new experiences from the current task to long-term memory. Read and write on the metada border with working memory.

Retrieval method: Minimum action unit for Read Path

Before you discuss mixed search, you can make the action cell clear. Many systems appear complex, and the bottom is usually a combination of several capabilities: search by path, search by string, search by word, search by vector, search by structure and search by relationship. Databases and indexing systems are only vehicles of these capabilities, not the capabilities themselves.

File path, directory navigation and grep/glob

The most simple search is navigation. The known filename, directory, extension, module path, configuration name, error information, function name are often more reliable when searching, glob, regex, grep than when searching vectors.

It works in a direct way: it first reduces the search space by path, file type or ignore rule, then matches content with a string or regular expression.ripgrep The value of such tools is not semantic, but certainty and speed. Revert search directory, support regularity, default respect .gitignore, these features are well suited to quickly locate candidates in large code libraries or file trees.

The disadvantages of such searches are also evident: it requires a paper trail. User Ask"Where's the logic of the failed login?"But it's actually called AuthChallenge- I'm not sure. However, once query has an error code, configuration key, interface name, log clip, document title, certainty search should normally precede semantic search.

Especially Coding Age, a elegant set of Embeding schemes is not necessarily valuable, and multiple rounds of glob/grep based on a little initial information tend to be misdirected. And that's what Claude Code has been doing, with tailored training, to solve very complex code tasks.

Backward Index, Keyword Matching BM25

Grep is file-by-file scanning. The full text search system builds a reverse index in advance: map token to a document or chunk that has appeared. When searching, you do not have to re-screw all text, but rather you can find a candidate from the wordlist and sort it in relation to it.

BM25 is the most common sorting method on this route and the technology that has been used in traditional search engines for many years. It roughly combines three types of signals: the query word appears in the document much less often, the word itself is not common throughout the text, and the length of the document does not allow longn to be taken advantage of naturally. Terminology, numbering, anomaly code, person name, interface name, regime clause, product code, these queries BM25 are often better used by dense embeding.

So SQLite FTS5 (SQLite Exchange - Full-Text Search), Postgres Full Text Search, OpenSearch, ElasticSearch) still has an important system. Even if the system already has a vector bank, keyword retrieval should not be considered an old-age technology. For Aget, BM25 is a low-cost, high-explainable, easy-to-compose filter candidate generator.

n-gram with sparse n-gram

n-gram search is between grep and full text search. It does not understand semantics, nor does it necessarily divide words by natural language, but tears the text into continuous character segments. Trigram is a character clip of 3 lengths. The advantage of doing so is that it is suitable for substring matching, vague spelling, similar strings and regular cutters. As for sparse n-gram, it's just the abandonment of less differentiated segments, which makes the search more efficient.

Postgres pg_trgm A typical example: it supports similar matching of text with a trigram similarity, or can speed up the query by using GiST or GIN index. Trigram is often more appropriate than full symmetry for such issues as product spelling instability, file name search, short string matching, and log-snipe positioning.

Cursor's last regex search can also be understood in this family. It accelerates the big warehouse regex search for the Agent tool: sifts out a large number of impossible files with indexing methods like sparse n-gram, and then matches the candidate with precise regularity. It's not a substitute for grep, it's just that precision tools are still called by Agent HF in a large code library. The project is based on a series of projects that are being developed and are working with Cursor's proud code vector-syntax database.

Vector semantics Retrieving

Vector-based search solves cross-expression recall. It usually encodes Query and document chunk into the same vector space, then uses cosine, dot regulation or L2 distance to find the nearest neighbor. User says"Client refund process", Document Writing"Sales refunds SOP"As long as the embedding space learns a similar semantic, it can be recalled.

Dense Passage Retrieval is the classic node of this route. It encodes open-area questions and questions and passages into dense vectors, and then recalls candidates with vector similarity. Engineering, small size, exact KNN, all vectors count back to similarity; size requires ANN (approximately closest) to exchange speed.

HNSW, IVF, and PQ are the three most central algorithms to solve this problem. HNSW (Hilarchical Navigable Small World) Near-Nearth Neighborhood Search based on multi-layer structure. There are very high search speeds and high recall rates, which are accompanied by very high memory consumption for storage of map structures. The IFF (Inverted File Index) is the classic way to use a barrel and then a group violence index. PQ (Product Quantification) is the only method of compromising compression, reducing costs by lowering dimensions, but with severe loss of precision, generally combined with IVF. Faiss (Facebook AI Similarity Search) is an open source for organizing these algorithms at an effective top level.

With the spread of RAG structures, developers tend to “reducing new components”, so traditional relationship databases embrace vector capacity through plugins. This is very appropriate for scenarios that need to be in a single database to ensure both ACID services and vector retrieval. Pgvector (PostgreSQL Exchange) and sqlite-vec (SQLite Exchange) are the classic extensions. As for the need for larger-scale services, Elasticsearch / OpenSearch / Redis, a framework for mixed search in origin, is a choice that is worth choosing and their focus is slightly different.

The vector search is wrong."Semantics Close"Consider it"The answer is correct."I'm sorry. It is very good at rewriting natural languages, blurring issues, cross-linguistic or cross-expression recall, but it is not natural to be reliable for errors, functional names, contract numbers, short query, rare entities. It returns a similar candidate, not a proven evidence. Vector retrieval is therefore best seen as a candidate generator, not a final answer selector.

LSP and Code Index

Code is not normal text. Functions, classes, interfaces, references, definitions, types, call relationships, modular boundaries are originally structured information. If you cut the code into chunk and do embeding, you lose a lot of what the compiler and the language server already know.

LSP's worth obviously here. The Language Server Protocol standardized language skills for completion, jump definition, search for references, document symbols, workspaces, diagnostics, etc., so that editors and tools can be reused on language servers. For Agen, LSP search answers where the symbol is defined, where it is quoted, what structured entities are in the current document, and not which text appears to be more similar.

If there's a sign relationship like LSP, AST, then why not?

Path to Figure Search and Relationship

The chart search is about entities and relationships. It is not about whether a chunk is similar, but about how the entity connects: which team a person belongs to, which service the system relies on, which customer the contract is with, which components the failure affects, and which document a concept appears in different names.

Graphrag is not a map database. The database is a carrier and the real search modules include physical neighbourhood, relationship path, multiple jumps, community summaries, Text-to-Cypher, template queries, etc. LightRAG is a relatively lightweight and suitable technology selection. And of course we can also choose the algorithm for our own database, and then think about how to organize ourselves (Llamainindex is a very common tool). However, the search of the maps is not necessarily valuable and probably expensive, and it is suggested that the maps be compared with the BM25, dense, reranker in the same set. Only if there are stable returns on relationship, multiple jumps, cross-documentary issues, the mapping is upgraded to infrastructure.

Search from one-way to mixed search with Agenic RAG

The smallest of these units is understood and the engineering system is much clearer. The combination of search is to allow different searchers to do their own good and then merge at the unified candidate level. As all the acceleration algorithms mature, running all the strategies over is not that expensive, but how to aggregate them, bringing information to Agent rather than noise.

The most likely underestimation in mixed search is hard-file. Permissions, tenants, projects, time, deleted status, version status, should not be given to reranker, but should be effective as a hard constraint before and after recall, and we should use them with metada. In the business knowledge base, the disclosure of an unauthorized file is much more serious than the recall of a chunk.

After the candidate merges, you usually have to dedup, fusion and rerank. Dedup addresses the problem of a chunk recalled by multiple paths, and the same paragraph is repeated in different versions. Fusion addresses the incomparable scores of different searchers. RRF is well suited to this stage because it integrates by ranking, without BM25 fractions, vector similarities, and chart path fractions at the same scale. The various databases, the hybrid search documents, deal essentially with such sort of thin, dense and sorted integration problems. While data sources are becoming more and more abundant, existing integration modalities are often less adequate and it is important to design suitable integration programmes that combine the needs of the project itself.

Rerank is the other floor. The first phase of the recall was intended to be more broad, so it was broader; the second phase of the rerank was designed to be more gradual and more gradual. The previous reranker was often a neuronet model, usually more accurate than bi-encoder, but more costly. And now it's common to have a LLM just as Reranker, after all, token is getting cheaper, training for what.

And then, the other way, is Agenic RAG. Traditional RAG is a retrieving-the-generate; Agenic RAG turns search into multiple-wheeling actions: planning, searching, reading, identifying gaps, rewriting queries, retrieving, cross-referencing evidence and generating answers. It uses more test-time compute for retrieving coverage, multiple jumps and self-checking. In other words, it's also a search side of a test-time scaling.

Agenic RAG is a rather interesting topic, from a sexual certainty to a multi-wheeled Agent Action. Rect is undoubtedly his opening act, the interlocking of Thinking and Acting, and feedback guides the next round of action. IRCOT and Search-o1 have extended the same idea to the search field. FLARE predicts what is missing from what is being generated and then initiates the search. Self-research and reflection of the results of their search are similar ideas, but the “research and reflection” is put into the training phase rather than relying on an externally inspired approach. Retrieves from a pre-step to a self-repeated cycle in the Agenic RAG. From the point of view of the Feedback message, it was absolutely the right choice.

Two questions to be careful about in engineering. First, the Agenic RAG is not free of charge, it increases delays, costs and uncertainty. Second, multiple rounds of search do not amount to a much larger amount of content being inserted into the window. Each round should produce better candidates, narrower scopes or clearer gaps; failing that, it should be just increasing noise.

After Agenic RAG: Re-entering the structure

Agenic RAG addresses “when, what, how to move on after you have retrieved”, but it does not automatically solve another old problem: the document is not a bunch of chunks. If the bottom is still flat, Agent will simply search for it at higher cost, and may still leave out evidence of a concentration, continuity and hierarchy in long files. Many answers are not randomly scattered over the whole text, but organized along the title level, paragraph order and local narratives. Readers usually read the document first in the directory, title and subsection position before going into a continuous section; RAG, if you guess key words over and over again, is easily missing the requirement in the same section that is not explicitly stated by query.

RAPTOR is an early route to this structure for obvious search. It cuts the original text into a leaf node and then returns to embedding, grouping, summary, and constructs a tree from local fragments to high-level abstract; it can be searched on the trees, layer by layer, or then spread the whole tree node and search together in different abstract layers. The advantage of doing so is that the system is not only getting the most similar short chunk, but also retrieving thematic, cross-sectioned nodes that fit the issues that require global understanding and multi-step integration. The RAPTOR tree is, however, a structure generated by reprocessing, not the original structure of the document; the fusion and summary rewrite information, which may compress details or even introduce a slight illusion. In other words, it uses the structure, but it comes from the model ' s reorganisation of the document.

DeepRead is closer to returning the original structure of the document to Agent. It treats the headings and paragraphs as first-class entities: the headings constitute the global navigation skeleton, with a sub-heading collection, the number of direct paragraphs and the number of tokens, which are the only light-weight skeletons entering the system hint; the paragraphs serve as basic search and reading units, avoiding the slip-through of the answers. There are only two tools to run:Retrieve Receives a query string, returns the paragraph coordinates after the paragraph semantic search and expands them appropriately by the context window, giving Agent a preview of the position;ReadSection returns the original text in the range of doc id, section id and paragraphs. This way, Agent can locate first, read in the order in which the area is determined, rather than re-search the keywords in long files.

The two jobs were taken together, which meant that there was an important route after Argentina RAG: It is not just for the model to search for more rounds, but to restore the search object from a flat text block to a document with a location, hierarchy, reading order. RAPTOR has demonstrated that multilayer abstract structures can enhance long files QA, but also suggests that rewrite tree structures can pose information damage risks; DeepRead uses the original headline and paragraph order more conservatively to transform the structure into the Agent navigation interface.Better than RAG, and often more expensive than RAG, which is the direct result of Agenic Search.; but when search begins to combine intent to understand, structure navigation and continuous reading, it also changes to some extent the search itself.

Project Enhancement: Make search more like Runtime decision-making

With basic searchers and mixed layers, the real impact on the quality of the system is often engineering enhancement. They don't necessarily look like the main contribution in the papers, but they're pretty much in the production system.

The first is information needs judgement. Agent will first determine the type of question that the current question belongs to: precise positioning, semantic exploration, structured inquiry, multi-jumping relationships, prescription versions, code symbols, no answer judgement. Different information needs should be pursued along different routes. Question"Wrong code, E1027. What is it?"BM25 and grep should be out before vector; ask"Is there a similar client refund policy?"♪ Time, dense is more valuable; ask ♪"Who does this function affect?"When LSP and AST are more important.

That's the value of the router. It's got..."What kind of searcher should we use?"The decision-making process is becoming a runtime. The LlamaIndex Router Retriever tool offers a concrete realization: let LLM select one or more retrievers according to Qurey. A more mature system can also use rules, taxonomy, query logs and failed samples to train the exit strategy instead of LLM Router.

The second is query rewrite. User input is usually not a good search statement. The user is a job, and the index contains document clips, code symbols, rule entries, physical relationships and historical records. There's a natural syntax difference in the middle. Many times, Query rewrite is not a change, but a change: to break a problem into multiple search sub-issues, to expand the different narratives, to extract key entities, to generate structured filter, and then send it to different retriever. There are few studies on query rewrite (uninterested, much less non-existent), and RAG-Fusion/HyDE/Self-Retriev may be used as a reference.

The third is index-side recalm environment. As we said in the previous section, chunk is too small to throw in the context, chunk is too big to dilute semantics. Many of the enhancements are actually working on this. Anthropic Conterent Retrieval is a good example of a project: before writing an index, create a chunk-specific context for each chunk, and use this context with the original chunk for embedding and BM25. In turn, Jina's Late Chunging produces contact details on long text, then chunk embedding, and chunk embedding keeps more context-based information. The same idea is shared by the Parent documentation retrieving, and the sense window retrieving: small particles are in the hit, large particles are in the backfilling. Use a small chunk to be sensitive to recall, before entering Work Memoory, and then bring back the parent's paragraph, the adjacent sentence, the title path or the page number.

Fourth is the problem. The search result should not be in the context as it is, but should be organized into a copy. A good video pack includes at least: extracts directly related to the current target, required parent context, source URI, title path, page number or line number, version and time, confidence, conflict or expired mark, permissions and citation status. The current round is also available for information and future decision-making by the Agenic RAG. So he can move.

Value of standard candidate and LlamaIndex

Multi-road search is best managed without placing the operational layer directly dependent on the return value of a database or framework. BM25, dense, graph, LSP, file navigation should be organized as a candidate. You can call it. RetrievalResult：

{
  "query_id": "q_20260611_001",
  "retriever": "grep|bm25|dense|lsp|graph|file",
  "doc_id": "doc_123",
  "chunk_id": "chunk_456",
  "source_uri": "file://policy/leave_policy.pdf#page=3",
  "title_path": ["人事制度", "休假政策", "年假"],
  "text": "召回文本...",
  "snippet": "高亮片段...",
  "score": 0.83,
  "rank": 4,
  "metadata": {
    "tenant_id": "tenant_a",
    "acl_tags": ["hr", "cn-office"],
    "status": "active",
    "version": "v3"
  },
  "provenance": {
    "indexed_at": "2026-06-11T10:00:00+08:00",
    "source_updated_at": "2026-06-10T18:00:00+08:00",
    "parser": "docling|ragflow|custom"
  }
}

The object is not in JSON format itself, but in boundaries. The searcher is responsible for the identification of candidates, the formation layer is responsible for filtering, integrating, re-engineering, re-regulating and compressing, and the generation layer receives only evidence of the origin and governance information. Later, the Chroma is replaced by LanceDB, LanceDB is replaced by Qdrant, Lightrag is replaced by Neo4j Graphrag, or grep is replaced by a faster sparse n-gram search, and introducing the middle layer to reduce the future-oriented coupling of the entire system is necessary.

The value of LlamaIndex can also be understood here. It is not necessarily the only framework for the final production system, but it has shaped many of the search-formulation abstract products: I'm not sure if you're going to be able to do anything, but I'm going to be able to do it. Read its design, help us put RAG from"Call a vector bank"Raise to"Organize a set of read path reusable components"I'm sorry. Of course, the framework is only a tool for organizing the system, and it should not be allowed to replace our understanding of the system and our demands on it.

Write Path: From running time events to re-establishing knowledge assets

If you search the answer,"What should be brought in?"The answer to the question is,"How the current events and the new information became credible memories"I'm sorry. The latter are often more difficult, as miswritten memories can continuously contaminate the results in the future.

Write from the project should not be understood once. add_memory Call, and should not be understood as putting text append into a vector library. More precisely, it is: first to determine who is the source of the facts and which are only projection; then to submit a change in the source to an auditable status; and finally to allow for the projection of vector indexes, BM25, diagrams, summary documents to be updated or rebuilt. The projection is intended to enhance the recall and organizational capacity of read path, but should not be a separate function of real memory.

In other words, the heart of Write Path is not"Save new information."Rather, it is a question of how a new message can change the current interpretation of the system: whether it is new to the world, a new version of the old facts, a preference for conditionality, evidence of conflict, short-term events, or simply not a long-term memory.

Writing what: Promotion and Persistence are not equivalent concepts

Entering the work memory content does not necessarily deserve to be written in the long-term memory. Promotion is the temporary bringing of external information into the current window to service the immediate task; persistence is the writing back of new facts, rules or experiences that arise from running. The former can be relatively radical, with the largest amount of contamination of the current wheel; the latter must be conservative, as errors can contaminate many future searches.

This distinction avoids a common error: as long as a certain element is right for the current mission, it is deposited into a long-term memory. Much of the information is only local, temporary and context-related and should be withdrawn as the mandate ends. What really suits the piustence is the stable preference, the clarity of facts, the transferable experience, the rules that are activated repeatedly, or the new constraints that the user has corrected at its own initiative. The goal of Persistence is not to remember more, but to make the future Read Path read only interpretable, rollable, invalid information.

When to write: Run-time memory writing and knowledge-base writing

When I was discussing Write Path, the easiest thing to mix was actually two completely different types of writing.

One is the running-time user memory: the user corrects the system in a conversation, the tool is called to expose a transferable experience, a project agreement is repeatedly triggered, or the user clearly gives preference and identity facts. Its trigger point is an event, focusing on the determination of whether the information is stable, useful across the mission, and whether it should be updated.

Another category is knowledge base / RAG writing: connector to new document, Wiki page changed, code repository has new committee, business database exports a record, system files are changed. Its trigger is source change, which focuses not on the LLM automatically remembering, but on the re-defining, regularizing, cutting chunk, calculating haw, updating metada and updating search scenarios.

Dimensions	Run-time	Knowledge base / RAG writing
Input Source	Dialogue, tool calls, user error correction, environment feedback	Documents, Wiki, codes, worksheets, business library, web access
Trigger Method	Event trigger: preference emerged, error corrected, experience transferable, rules activated repeatedly	Source changes: Update of files, Connector Sync, Time Update, CDC, Manual Release
Factual sources	mory object, user profile, rule file, audit log	Document story, object storage, business library snapshot, Git/Wiki history
Writing Object	persona、rule、experience、semantic fact、episodic summary	document、chunk、metadata、source hash、index manifest
Update Policy	Conservative writing, request confirmation or mark low confidence if necessary	Defaults can be rebuilt; incremental updating is optimized under pressure of scale and freshness

Both types of writing are called Write, but the risk pattern is different. The risk of doing so is to entrench temporary situations, hallucinations, user jokes or one-off failures into long-term prejudices. The risk of writing in the knowledge base is that old chunk, old vector, old graphics and old abstracts are left in the projection, allowing the system to see the latest facts. If we are building an Agent on a user side, then most often we run to remember preferences, and if we're building services, then the stability and correctness of the knowledge base is often at the core.

Write Pipeline: One abstract, two paths to realization

A manageable writing path can be shared in the same abstract, but it is best to break it down to two paths:

runtime memory:
  event
    -> memory proposal
    -> gate
    -> normalize
    -> align
    -> commit
    -> project
    -> verify

KB / RAG ingestion:
  source change
    -> parse / chunk / hash
    -> staging index
    -> evaluate
    -> publish manifest
    -> retire old index

Run it with a Mr. Remand. memory proposalI'm sorry. The proposal is written in the candidacy, not the memory that has fallen. It must at least take the candidate, source, scope, type, confidence, TTL or validity, pilvacy/ACL, ideatency key and the event that triggered it. This allows the system to distinguish between a clear and stable preference of users and a model that guesses from a conversation.

gate I decided to write it. Here, stability, reuse value, boundaries of authority and reliability of sources are checked. Users who proactively correct, change external factual sources, fail to reset tools are usually more worthy of writing than models themselves. Many systems drag writing to the end of the session and summarize it in a uniform manner, but this will confuse many of the fine-specimetric evidence. It is more stable to create a profile by event, and then to be garte to decide whether to submit, downgrade to an episodic submary or to remain in the current task log.

normalize The candidates are converted to stable schema: time, entity, project, user, source URI, version, permission, evidence clips. For the knowledge base, this step also includes the resolution of documents, the retention of title paths and page numbers, the generation of chunk, calculation of source Hash, records of parser version and embedding model version.

commit It's the real writing. It should write the audit log, not just the vector bank. I need to stay. active、stale、conflicted、deleted State of the Union, record supersedes / superseded_by, if necessary valid_at、invalid_at、observed_at、source_updated_at、committed_at and index_versionI'm sorry. Write more like a small-state submission, not a value given to global variables.

project Reloading projection. Semantic knowledge is regenerated, terms and numbers are indexed to the full text, entity relationship updates are displayed by side, file-type memory updates catalogues or abstracts are created, and Wiki pages are re-enabled. Projection can be a different step, but must be traceable; otherwise read path will recall old vectors, old keywords or a relationship that has lapsed.

verify is the regression check after writing. Whether the new document can be recalled, whether the old version is downgraded, whether the transfer to all search channels is deleted, whether the permission filter is still valid and whether the reference can be traced to the original source. Even the user side runtime should not leave the verification responsibility to the user; at least provide writing diff, source link, undoing access and memory review to keep autowriting visible.

The knowledge base is written more like a data dissemination process than a single memory submission. The LlamaIndex document management page doc_id and Hash to determine whether the document is changing, to avoid writing and to make document-level operations of update / delete. The new index is also commonly published on the project by stating index, offline evaluation, index rotation and blue-green switch. It's not fancy, but it's putting"What exactly did the knowledge base publish this time?"Turns into a verifiable state.

The hardest part is to write about the old world.

align It's the easiest to underestimate in Write Path. The new knowledge is not automatically the cover of old knowledge."Users like lattes."and"Users have recently started to stop coffee."It's not a simple question of double choice. The system needs to know the time relationship between the two memories, the conditions of application and the state of conflict. Think of it as a memory."Best Scanning of the Current"Go overwrite, the time dimension is erased.

There are at least three types of issues here.

The first category is time change. The old facts may not be wrong, but they may be valid. Users used to work in Shanghai and moved to Hangzhou."Shanghai"Removed from history, and marked the time period in which it was established. Zep / Graphiti, a sort of digital graph that puts fact value and policy in the center of the system to make it answerable."What's true now?""What was real?"instead of retaining only the last written result.

The second category is the contradiction of facts. If the old and new facts cannot be established at the same time, then we should enter. conflicted、superseded Or to be confirmed, not forced integration. MemConflic, which is a kind of evaluation that singles out memory conflect, is also the reason why it is really hard to remember more than to write a contradiction when new evidence comes.

The third category is the application of conditions. Prejudice, rules and experience are rarely global truths."Use pnpm for this item"、"The user likes to answer briefly."、"This client doesn't accept Friday release."There may be scope, time and scene limits. Without condition fields, memory becomes biased when running.

So... align Not just a duplicate check and similar memory merge. It is about physical decomposition, conflict detection, subsede judgement, narrow conditions, alignment of time and oblivion transmission. Mem0, this kind of memory product makes a visible API, essentially a product of the product, and LangMem makes memory operation tables"Enter the review and current memory state, and generate updated memory state", which also indicates that writing is not a single point inserted, but a rewrite and consolidation of existing status.

Because we need to. align If only action space is append and overwrite, the system will soon mix historical facts, current facts, conflicting facts and provisional conclusions. A more stable approach is to make the writing action visible.

• ADD: Add a new one that is free from direct conflict.
• UPDATE: Updates the field in the same fact or profile.
• SUPERSEDENew memory replaces old memory, but retains the historical identity of old memory.
• CONFLICT: Old and new messages contradict each other, marking conflicts first rather than merging.
• ARCHIVE: Old memory is no longer implicitly recalled, but still subject to audit and recovery.
• DELETE: Delete completely because of error, privacy, permission or user request.
• NOOP: information is too temporary, too uncertain or has an equivalent memory, not written.
• ASK_USER: User confirmation is required if evidence is insufficient to influence long-term behaviour.

The meaning of this set of actions is not to complicate the schema, but to allow the system to acknowledge that there are multiple endings. The most dangerous state of the long-term memory system is that all new information is packaged."Update successfully"。

Time fields should also serve this action space.valid_at / invalid_at (a) When the expression of facts is established or invalidated in the world;observed_at / source_updated_at The question of when the source has mentioned or updated this matter is addressed.committed_at When does the system write it in memory? The first two are world time, the latter are system time. Combining them makes it difficult for the system to explain why an old memory is still being recalled or why new information does not immediately cover old information.

The index is Projection: Why often does engineering re-establish knowledge? Library

This is why the knowledge base in real engineering often does not grow intelligently, but rather is constantly rebuilt, re-established, or blue-greened. Sounds stupid, but it's more verifiable.

The real difficulty of incremental updating is not to insert a new chunk, but to deal with a whole chain: whether the old chunk has staved, whether to delete it to the vector index, FTS and the chart, whether the old chunk can coexist with the new chunk, whether the embedding model can be compared with the old chunk, and whether the entity extracts the old graph is credible after the change of the model. As long as these issues are not demonstrably modelled, incrementality will turn the knowledge base into a layer of historical remnant.

So small, local, personal knowledge base, small team PoC, default full-scale reconstruction or catalogue/document collection reconstruction of the zoning is often more rational. Re-decognize, re-create, re-ebeding, rerun BM25 / graph attachment, and replace the old version with a new index version. The old index is not deleted, and the flow is then checked; the problem is rolled back. This is easier to locate than the constant patching on the old index.

Incremental updates are suitable for another category: data are too large to fully reconstruct; freshness requires too high to wait for the next batch; source systems provide reliable change streams; systems already have doc id, source Hash, delete tombstone, index version and protection tag monitoring. Graphiti selects real-time incremental maps that are suitable for the conversation and continuous change in the currents of events. The incrementality is valuable, but not the goal that all systems should pursue at the outset.

The mapping should be particularly careful. Automatic increment mapping is easily transformed into a zoomor for an erroneous relationship when the chart search proceeds have not yet been validated. Physical breakdown, extraction of relationships, temporal validity of margins, lapse of old relationships are all more difficult than normal chunk upsert. In many cases, the image is used as a re-established program, generated and evaluated offline in fixed language, more stable than a continuous re-drawing of the map during running.

Writing assessment: not just retrofitting

Finally, Write Path's assessment cannot be just about whether it's possible to recall it in the future. The L1-L6 framework in the Memoory Panorama, where more engineering is possible.

Write correctness to read write precisionThe number of candidates who are included is truly stable, useful and reliable. Updates the correctness of the conflict by looking at whether the old and new facts are being matched, whether there is a duplication of the existing facts, and whether the conflict has been forcibly merged. Projection quality looks at projection lag, stale recall rate, delete conditioner: how long after submission is read, whether the old version is still being recalled, and whether the deletion is being sent to all indexes.

The governance capacity is also based on rollback access, audit communications, communication communications and personal communication. These evaluations have started to remove memory habitat to the operational layers of extration,updating, QA; LongMemeva updates, time reasoning and pullovers of knowledge from the long-term session; MemoryAgentBench further emphasizes accurate retrievation, test-time learning, long-range unzzing and self-active forgetting; MemConflect separates conflict memories. The right direction is to ask not only if the system remembers, but whether it is written correctly, correct, or not, and if it is not deleted in a clean and uncertain manner.

Relief of engineering techniques with inadequate context

The previous chapters address how information is entered into and stored. The harder part of Context Engineering appears in the course of a single mission: what happens when dozens of rounds of missions are run, the context is closing to the window ceiling and the workstation starts to get dirty?

This section only discusses the operational methods. First"Wondering the outer space for LLM to wear a definite shackles."Clearing the border: The article also speaks of subagent, checkpoint, fork, worktree, but the angle is to limit reliability, and to treat them as the original language of the narrow and failed crop radius.

A different angle is how they help manage the context: what leaves, what changes and what separates.

Compression and Context Reset

The most direct approach is compression: to remove the dialogue close to the window ceiling and to restart a new window with a summary.

The main points of practice given by Anthropic are:Retain structured decision-making, unsolved bugs, key realization details, and discard redundant tool outputs; maximize (do not leave out the relevant content) before optimizing (eliminate the redundant).

Claude Code's automatic compact is activated when more than 95% of the context is activated, cleaning up earlier tool outputs, summarizing the dialogue if necessary, and retaining the five recently visited files. One of the lightest forms is tool-result clearing: automatically clears the call and result of old tools in the context when approaching the token ceiling.

Anthropic is here. Release of the contact context It gives a set of numbers: in a 100-wheel web search test, the contact editing alone reduced token consumption by 84%, resulting in 29% performance improvement; the memoory tool was used by 39%.

The risk of compression is also clear: over-compression can lose the critical details that were not seen at the time and later revealed critical details. Contact reset is another way of dealing with it. Compaction is in situ compression, with the same ant running with a summary, and continuity is better; reset gives the next anent a clean context, only a structured handoff handover of essential state. Reset has to pay the handoff cost, but it can cut the impact of dozens of rounds of noise ahead. The choice depends on whether you prefer continuity or whether you need a clean start. Claude defaults on the Runtme to use Compact, but for Dynimic Workflow, your choice is closely related to your mission itself.

Nor is it necessary to clean up the errors immediately, and although attention is not linear, the development consensus still believes that we should consider compression or replacement after the Context window is scarce. Leaves the failed action and corresponding stock track in context because the model will implicitly update its belief when it sees failure, thereby avoiding the same error. In a sense, the ability to recover wrong is one of the clear indicators of the behaviour of angétics.

Externalized: Move memory outside the window

The other path is not to hold the information in the window and externalize it to the file system. Manus is here. Context Engineering for AI Agents It calls the file system"End context": Large, natural and durable, and Agent can also operate directly.

Compression is best recoverable. You can drop the main text of the web page but leave a URL; you can omit the document contents but keep the path. And it can be pulled back when it's needed, avoiding irreversible losses from the operation. Structuralized Notes for Anthropic (writing) NOTES.mdMaintenance to-do.mdThis is also the idea of putting memories outside windows, reading them back when needed and keeping the cross-conference alive.

The long-cycle mission also has a stand-alone issue: the drift of targets. Manus observed a typical task that averaged ~50 calls for tools. The first target will start to lose its focus. This is what Lost-in-the-Middle is doing in the context of the event. I'm going to go outside and do one at this time.todo.md, rewritten every step of the process, pushing the current target to the end of the context, where the model is most focused. This is also one of the ideas of externalization.

Separatist: Subagent and Checkpoint / Fork

The last category is isolation. Rather than press in one context, the task should be cut apart.

Subagent's engineering value is not just speed, but more importantly context isolation. Sub angent can burn tens of thousands of tokens for the purpose of exploring, but only a compressed summary of 1000-2000 token (the number of Anthropic) can be returned to the main angent. Lord agent therefore kept clean, detailed search and exploration were blocked out.

Claude Code. subagent Gives each sub angent a separate context window, custom system programt, restricted tool set, and independent permissions. A read-only reviewer subagent without the Edit tool does not allow changes to the file to be simply a hint, but an action space limit.

And the isolation is accompanied by the state management language. Claude Code. checkpointing Automatically snapshot file status, inter-session duration, 30-day cleanup for each user programpt, supporting five rewinds (restoration code/ resumption dialogue / both/ from a point summary/ abstract to a point).

The session itself is local JSONL (see how Claude Code works）。--continue / --resume The news is available at the end of the same session.--fork-session / /branch The first of these is the following:

From the context management point of view, these original language offers the ability to replace and forklift: to save a part of the context outside the window, to replace it when needed, or to restart from a clean branch.

The border is again: subagent isolation, tool-call isolation, solstion isolation as a reliable system of original language, as it was in the chapter on sexual shackles. This is only their context management perspective, which is to consider subagent as Isolate Original. As for the choice of the MAS, the Single Agent or the Dynamic WorkFlow, it's already in the Agent structure selection itself, and I put it in theThe cognitive part. "MAS or Single Agent and Dynamic Workflow" SectionIt's in there.

Concluding remarks: Write / Security / Compress / Isolate

These techniques seem to be scattered, but Lang Chain is in Context Engineering for Agents It gives a good classification framework and gives them four kinds of action:

• Write (Write out): Save information outside windows, such as scratchpad, externalized notes, inter-conference memories.
• Select (select): Pull relevant information into windows, such as retrieval,CLAUDE.md Such rule documents, recall of memory.
• Compress (concentrated): Only tokens required for mission assignment, such as commanding, summary, trimming.
• Isolate (separation): Split the context into different anent or environment, such as subagent, sandbox.

In contrast, compression is Compress, externalized is Write, search is Select, isolation is Isolate.

Context Engineering is not a single-point technique that needs to be combined to organize these actions.

Drew Breunig also summarized four common context failure patterns: popsoning (the illusion enters the context and is repeatedly quoted), distribution (the context is more than the model's own capacity), confusion (the non-content interference response), and clash (the contradictory part of the context). These pits are basically a response to a failure of action by write, self, compress, isolate.

"How do you assess a Context system that's not doing well?"I gave a framework for L1-L6 in the Memoory Panorama: writing correctness, updating correctness, calling timeliness, behaviour consistency, migration control, uncertainty management. Don't repeat it here. And how the real runtime puts together the storage, retrieval, writing, isolation actions, leaving them to the teardown section.

Context Engineering does not focus on long windows or stacking a vector bank. More practical criteria are whether the system can explain what information is in the current context, what is compressed or replaced, what is isolated in sub-agents, what is written into long-term memory, and why these decisions are made. The window will continue to be limited and attention will remain on the budget. As long as this premise remains unchanged, the context is used as a limited resource to move it, and this is a basic capability for the Agent project.

References

• Anthropic, Effective context engineering for AI agents
• Anthropic / Claude, Managing context on the Claude Developer Platform
• Anthropic Docs, Claude Code Memory、Memory tool
• Manus, Context Engineering for AI Agents: Lessons from Building Manus
• Chroma, Context Rot: How Increasing Input Tokens Impacts LLM Performance
• LangChain, Context Engineering for Agents
• LangChain Docs, Memory overview、Long-term memory
• LangMem, Conceptual Guide
• OpenAI Help Center, Memory FAQ
• OpenAI Codex, Custom instructions with AGENTS.md
• GitHub Docs, Custom instructions for GitHub Copilot
• Gemini CLI, Provide context with GEMINI.md files、Memory Tool
• Cursor Docs, Rules；Cursor, SemSearch、Fast Regex Search
• Lost in the Middle: How Language Models Use Long Contexts
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Retrieval-Augmented Generation for Large Language Models: A Survey
• ripgrep, ripgrep
• Stephen Robertson and Hugo Zaragoza, The Probabilistic Relevance Framework: BM25 and Beyond
• SQLite, FTS5、vec1
• Alex Garcia, sqlite-vec、sqlite-vss
• PostgreSQL Docs, Full Text Search、pg_trgm
• Microsoft, Language Server Protocol
• Tree-sitter, Tree-sitter
• Dense Passage Retrieval for Open-Domain Question Answering
• Billion-scale similarity search with GPUs
• pgvector, pgvector
• LanceDB, Hybrid Search；Qdrant, Hybrid Queries；Weaviate, Hybrid Search；Elasticsearch, Reciprocal rank fusion
• Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods
• Passage Re-ranking with BERT；Document Ranking with a Pretrained Sequence-to-Sequence Model；BAAI, BGE Reranker
• ParadeDB, ParadeDB / pg_search
• ReAct: Synergizing Reasoning and Acting in Language Models；Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions
• Forward-Looking Active REtrieval augmented generation；Self-RAG；Corrective Retrieval Augmented Generation
• RAG-Fusion；Precise Zero-Shot Dense Retrieval without Relevance Labels；Query Rewriting for Retrieval-Augmented Large Language Models
• Anthropic, Introducing Contextual Retrieval；Jina AI, Late Chunking；LangChain, Parent Document Retriever；LlamaIndex, Sentence Window Retrieval
• DeepRead: Document Structure-Aware Reasoning to Enhance Agentic Search；RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval
• From Local to Global: A Graph RAG Approach to Query-Focused Summarization
• LightRAG, LightRAG
• SPLADE v2；ColBERT
• LlamaIndex, Router Retriever、Reciprocal Rerank Fusion、PropertyGraphIndex、Response Synthesizers、Node Postprocessors、Document Management Pipeline
• Microsoft GraphRAG, CLI；Indexing Overview
• Mem0, Docs、Quickstart、GitHub
• Zep / Graphiti, Graphiti docs、GitHub、Zep: A Temporal Knowledge Graph Architecture for Agent Memory
• Letta, Memory、Context hierarchy
• Andrej Karpathy, LLM Wiki
• HaluMem；LongMemEval；MemoryAgentBench；MemConflict
• A-MEM: Agentic Memory for LLM Agents；MemoryBank: Enhancing Large Language Models with Long-Term Memory
• Neo4j, Vector Indexes；Neo4j GraphRAG Python
• Anthropic Docs, Subagents、Checkpointing、How Claude Code works
• From Memory Generation to Memory Governance: A Panorama of Age Memoory
• From the cognitive structure of an intelligent body to the framework of an intelligent body
• "The outer project of putting a certain shackles on LLM: From Claude Code, Agent Harness"
• Why Output Token is more expensive: from KV Cache to Agent Cost Project
• Open Age Runtime: How memory, context and isolation fit in a real system