{"guides":[{"id":"29d7b0c5-18c1-43a2-9060-dc3b3608198b","unique_id":"agent-design-context-pruning-guide-mar2026","title":"Context Pruning and Retrieval Subagents","title_he":"גיזום קונטקסט וסוכני Retrieval","summary":"How to design agent systems that do not just remember more, but bring in the right evidence and discard the wrong context at the right time.","summary_he":"איך לתכנן מערכות סוכנים שלא רק זוכרות יותר, אלא יודעות להביא את ה-evidence הנכון ולזרוק את הקונטקסט הלא נכון בזמן הנכון.","long_content":"## The problem\n\nMost people treat context like a sacred pile: once information is retrieved or remembered, they keep feeding more and more of it back into the model. That creates noise, redundancy, distraction, and context rot.\n\nThe better question is not: *How do I store more?*\nIt is: *How do I bring in only what still deserves to be active right now?*\n\n## The key shift\n\nA strong agent system does not just remember. It also knows what **not** to bring into the active context window.\n\n## Why retrieval should be a separate role\n\nIn many systems, one agent tries to:\n- search\n- retrieve\n- filter\n- reason\n- answer\n\nThat often creates overload. A healthier architecture is:\n\n**retrieval/search subagent → evidence set → reasoning/generation agent**\n\nThis separates:\n- finding evidence\n- evaluating relevance\n- generating the response\n\n## What a retrieval subagent should do\n\nA retrieval subagent should:\n- decompose the search problem\n- gather candidate evidence\n- remove duplicates\n- discard stale or weakly relevant items\n- preserve only the most useful evidence for the next stage\n\nIt should usually **not** be the final answering agent.\n\n## Context pruning rules\n\nGood pruning heuristics include:\n- drop duplicates\n- drop stale evidence unless historically important\n- keep items that satisfy the current goal, not just the broad topic\n- separate background context from active evidence\n- prefer source-backed material over inferred summaries\n- keep a record of what was pruned, even if it is not passed forward\n\n## Three memory tiers\n\n### Tier A — Active context\nWhat the model needs right now.\n\n### Tier B — Retrievable working memory\nMaterial that can be brought in if needed.\n\n### Tier C — Archival memory\nStored history that should not enter active context without a strong reason.\n\nThe mistake is to treat all three as if they belong in the prompt at once.\n\n## What not to confuse\n\n### Pruning is not forgetting\nRemoving something from active context is not the same as deleting it forever.\n\n### Summarization is not always enough\nSummaries can help, but they can also hide important evidence. Sometimes the system needs selective retention, not compression.\n\n## Implications for personal agent systems\n\nIf you are building agents for yourself, friends, or family:\n- do not keep pushing entire histories into the prompt\n- retrieve based on current relevance\n- keep active context small and high-signal\n- separate personal memory from current evidence\n\n## Implications for CoachOS\n\nCoachOS especially should avoid raw memory dumps.\n\nIt needs a retrieval layer that can tell the difference between:\n- what matters to this coaching moment\n- what is useful background\n- what is just archived history\n\nOtherwise, continuity becomes noise instead of insight.\n\n## Practical recommendation\n\nWhen designing an agent system, add a retrieval layer or subagent when:\n- the task depends on lots of history\n- the question is multi-hop\n- there are many possible sources\n- wrong context can distract the model\n\nA good system is not the one with the biggest memory pile.\nIt is the one that can surface the right evidence cleanly.","slug":"agent-design-context-pruning-and-retrieval-subagents","curation_note":"למה זה חשוב: הרבה מערכות סוכנים נופלות לא כי חסר להן מידע, אלא כי הן מביאות יותר מדי מידע לא נכון. החלק הזה מלמד איך לחשוב על retrieval, pruning ו-active context בצורה בריאה.","tool_name":"LLMs","feature_name":"Agent Design","difficulty_level":"בינוני","topics":["Agents","Retrieval","Context Engineering","CoachOS"],"url":"https://www.trychroma.com/research/context-1","sources":[{"url":"https://www.trychroma.com/research/context-1","name":"Chroma Context-1"},{"url":"https://www.anthropic.com/engineering/multi-agent-research-system","name":"Anthropic Multi-Agent Research System"}],"language":"עברית","created_at":"2026-03-27T21:44:30.084336+00:00","updated_at":"2026-03-27T21:44:30.084336+00:00","section":"context_engineering","section_order":12,"section_title":"Context Engineering","section_title_he":"הנדסת קונטקסט","long_content_he":"## הבעיה\n\nהרבה אנשים מתייחסים לקונטקסט כמו לערימה קדושה: ברגע שמשהו נשלף או נשמר, ממשיכים להזין אותו שוב ושוב למודל. זה יוצר רעש, כפילויות, הסחות דעת ו-context rot.\n\nהשאלה הטובה יותר היא לא: *איך לשמור יותר?*\nאלא: *איך להביא פנימה רק את מה שעדיין באמת ראוי להיות פעיל עכשיו?*\n\n## שינוי המודל המנטלי\n\nמערכת סוכנים טובה לא רק זוכרת. היא גם יודעת מה **לא** להכניס לחלון הקונטקסט הפעיל.\n\n## למה retrieval צריך להיות תפקיד נפרד\n\nבהרבה מערכות, אותו סוכן מנסה גם:\n- לחפש\n- לשלוף\n- לסנן\n- לחשוב\n- לענות\n\nוזה יוצר עומס. ארכיטקטורה בריאה יותר היא:\n\n**retrieval/search subagent → evidence set → reasoning/generation agent**\n\nכך מפרידים בין:\n- מציאת evidence\n- הערכת רלוונטיות\n- יצירת התשובה\n\n## מה סוכן retrieval צריך לעשות\n\nסוכן retrieval טוב צריך:\n- לפרק את בעיית החיפוש\n- לאסוף candidate evidence\n- להסיר כפילויות\n- לזרוק פריטים ישנים או חלשים ברלוונטיות\n- לשמור רק את ה-evidence הכי שימושי לשלב הבא\n\nברוב המקרים הוא **לא** צריך להיות הסוכן שעונה סופית.\n\n## כללי גיזום קונטקסט\n\nheuristics טובים כוללים:\n- להסיר כפילויות\n- להסיר evidence ישן, אלא אם הוא חשוב היסטורית\n- לשמור פריטים שמשרתים את המטרה הנוכחית, לא רק את הנושא הרחב\n- להפריד בין background context ל-active evidence\n- להעדיף חומרים עם מקור על פני summaries מוסקים\n- לשמור רישום של מה נגזם, גם אם הוא לא עובר הלאה\n\n## שלוש שכבות זיכרון\n\n### Tier A — Active context\nמה שהמודל צריך עכשיו.\n\n### Tier B — Retrievable working memory\nחומר שאפשר להביא אם צריך.\n\n### Tier C — Archival memory\nהיסטוריה שמורה שלא אמורה להיכנס לקונטקסט הפעיל בלי סיבה חזקה.\n\nהטעות היא להתייחס לכל שלוש השכבות כאילו הן אמורות לשבת יחד באותו prompt.\n\n## מה לא לבלבל\n\n### Pruning זה לא forgetting\nלהוציא משהו מהקונטקסט הפעיל זה לא למחוק אותו לנצח.\n\n### Summarization לא תמיד מספיק\nסיכומים יכולים לעזור, אבל הם גם עלולים להסתיר evidence חשוב. לפעמים צריך selective retention, לא compression.\n\n## השלכות על מערכות סוכנים אישיות\n\nאם בונים סוכנים לעצמך, לחברים או למשפחה:\n- לא דוחפים את כל ההיסטוריה לתוך ה-prompt\n- שולפים לפי רלוונטיות נוכחית\n- שומרים את הקונטקסט הפעיל קטן ועשיר באות\n- מפרידים בין personal memory לבין current evidence\n\n## השלכות על CoachOS\n\nCoachOS במיוחד צריך להימנע מ-raw memory dumps.\n\nהוא צריך שכבת retrieval שמסוגלת להבדיל בין:\n- מה חשוב לרגע האימוני הזה\n- מה useful background\n- מה רק היסטוריה ארכיונית\n\nאחרת continuity הופך מרווח לתובנה לרעש שמבלבל.\n\n## המלצה פרקטית\n\nכשמתכננים מערכת סוכנים, כדאי להוסיף retrieval layer או subagent כאשר:\n- המשימה תלויה בהרבה היסטוריה\n- השאלה היא multi-hop\n- יש הרבה מקורות אפשריים\n- קונטקסט לא נכון יכול להסיח את המודל\n\nמערכת טובה היא לא זאת עם ערימת הזיכרון הכי גדולה.\nהיא זאת שיודעת להציף evidence נכון בצורה נקייה."}],"total":1,"limit":null,"offset":0,"next_cursor":null}