{"guides":[{"id":"85468616-a1ee-419a-9441-68432a240c1c","unique_id":"agent-design-evolving-systems-guide-mar2026","title":"Evolving Agent Systems","title_he":"מערכות סוכנים מתפתחות","summary":"How to design agent systems that improve over time without leaking private context: capability promotion, skill evolution, and safe sharing boundaries.","summary_he":"איך לתכנן מערכות סוכנים שמשתפרות לאורך זמן בלי לדלוף מידע פרטי: קידום יכולות, אבולוציית skills וגבולות שיתוף בטוחים.","long_content":"## Why evolving systems matter\n\nMost agents can execute tasks, but they do not reliably improve. They forget successful procedures, repeat failed explorations, and accumulate prompt sprawl instead of reusable capability.\n\nThe key design principle is:\n\n> Do not share memory. Share capability.\n\n## The difference between memory and capability\n\n### Memory\nOften private, person-bound, project-bound, and sensitive.\nExamples:\n- user preferences\n- client notes\n- family context\n- internal strategy\n- private decisions\n\n### Capability\nCan often be abstracted, versioned, tested, and shared.\nExamples:\n- research workflow patterns\n- fallback logic\n- validation checklists\n- task decomposition templates\n- code review procedures\n\n## The five-layer architecture\n\n### 1. Core capability layer\nBroadly reusable skills and quality patterns.\n\n### 2. Domain skill layer\nWorkflows tied to specific tools or domains such as Claude Code, OpenClaw, Monday, Supabase, or CoachOS.\n\n### 3. Persona/user/client layer\nPrivate memory and sensitive context.\n\n### 4. Evolution layer\nTracks repeated failures, successful workflows, skill candidates, and version changes.\n\n### 5. Promotion gate\nDecides whether something stays local, becomes a domain skill, or is promoted into a broadly shared capability.\n\n## Capability promotion pipeline\n\n1. One-off success → keep local\n2. Repeated pattern → note, checklist, or template\n3. Skill candidate → define scope, inputs, outputs, risks\n4. Review → check privacy, reliability, and assumptions\n5. Promote → core, domain-specific, or local-only\n\n## Safe sharing vs unsafe sharing\n\n### Usually safe to share\n- procedures\n- validation logic\n- fallback patterns\n- formatting rules\n- orchestration templates\n\n### Usually unsafe to share raw\n- personal memory\n- client details\n- family notes\n- secrets\n- private strategy context\n\n### Borderline zone\nSuccessful patterns discovered in private work may become shareable **after abstraction**.\n\n## Why self-evolution is risky without gates\n\nAuto-improvement sounds good, but without review it can create:\n- drift\n- hidden regressions\n- privacy leakage\n- overfitting to one case\n- skill rot disguised as optimization\n\nThat is why evolving systems need:\n- versioning\n- rollback\n- metrics\n- provenance\n- promotion review\n\n## Implications for personal agents\n\nFor yourself, friends, or family:\n- share reusable procedures\n- keep memory scoped\n- do not clone personal memory into every new agent\n- build starter templates and improve them over time\n\n## Implications for CoachOS\n\nCoachOS can benefit from evolving systems, but only if it follows a stricter rule:\n\n> Share patterns, never raw people.\n\nReusable coaching patterns may be abstracted and improved. Raw personal context should not be shared across users.\n\n## Practical recommendation\n\nIf you want an agent system that gets better over time:\n- build a shared skill library\n- track repeated failures\n- define skill candidates\n- promote carefully\n- separate private memory from reusable capability\n\nThat is how you create an agent system that learns without becoming messy, unsafe, or leaky.","slug":"agent-design-evolving-systems","curation_note":"למה זה חשוב: הרבה אנשים בונים סוכנים שיודעים לבצע, אבל לא מערכות שיודעות להשתפר. החלק הזה מסביר איך לגרום למערכת ללמוד לאורך זמן בלי לשתף זיכרון פרטי ובלי לאבד שליטה.","tool_name":"LLMs","feature_name":"Agent Design","difficulty_level":"בינוני","topics":["Agents","Skill Evolution","Architecture","Privacy","CoachOS"],"url":"https://github.com/HKUDS/OpenSpace","sources":[{"url":"https://github.com/HKUDS/OpenSpace","name":"OpenSpace GitHub"},{"url":"https://code.claude.com/docs/en/skills","name":"Anthropic Claude Code — Skills"},{"url":"https://code.claude.com/docs/en/sub-agents","name":"Anthropic Claude Code — Create custom subagents"}],"language":"עברית","created_at":"2026-03-26T17:15:39.241298+00:00","updated_at":"2026-03-26T17:15:39.241298+00:00","section":"architecture_patterns","section_order":6,"section_title":"Evolving Systems","section_title_he":"מערכות מתפתחות","long_content_he":"## למה מערכות מתפתחות חשובות\n\nרוב הסוכנים יודעים לבצע משימות, אבל הם לא באמת משתפרים לאורך זמן. הם שוכחים פרוצדורות שהצליחו, חוזרים על כשלונות, וצוברים prompt sprawl במקום capability שאפשר למחזר.\n\nעקרון התכנון המרכזי הוא:\n\n> לא לשתף זיכרון. לשתף יכולת.\n\n## ההבדל בין זיכרון ליכולת\n\n### זיכרון\nלרוב פרטי, קשור לאדם או לפרויקט, ולעיתים רגיש.\nדוגמאות:\n- העדפות משתמש\n- notes על לקוח\n- הקשר משפחתי\n- אסטרטגיה פנימית\n- החלטות פרטיות\n\n### יכולת\nאפשר לעיתים קרובות לאבסטרקט, לגרס, לבדוק ולשתף.\nדוגמאות:\n- דפוסי workflow למחקר\n- fallback logic\n- checklists לאימות\n- תבניות לפירוק משימות\n- פרוצדורות code review\n\n## ארכיטקטורת חמש השכבות\n\n### 1. שכבת core capability\nskills ודפוסי איכות שאפשר למחזר לרוחב.\n\n### 2. שכבת domain skills\nworkflows שקשורים לכלים או תחומים ספציפיים כמו Claude Code, OpenClaw, Monday, Supabase או CoachOS.\n\n### 3. שכבת persona/user/client\nזיכרון פרטי והקשר רגיש.\n\n### 4. שכבת evolution\nעוקבת אחרי כשלונות חוזרים, workflows מוצלחים, skill candidates ושינויי גרסאות.\n\n### 5. שכבת promotion gate\nמחליטה אם משהו נשאר לוקאלי, הופך ל-domain skill או מקודם ליכולת משותפת רחבה.\n\n## pipeline לקידום capability\n\n1. הצלחה חד-פעמית → נשאר לוקאלי\n2. דפוס חוזר → note, checklist או template\n3. skill candidate → מגדירים scope, inputs, outputs וסיכונים\n4. review → בודקים פרטיות, אמינות והנחות יסוד\n5. promotion → ל-core, domain-specific או local-only\n\n## מה בטוח לשתף ומה לא\n\n### בדרך כלל בטוח לשתף\n- פרוצדורות\n- לוגיקות אימות\n- fallback patterns\n- כללי formatting\n- orchestration templates\n\n### בדרך כלל לא בטוח לשתף raw\n- זיכרון אישי\n- פרטי לקוח\n- notes משפחתיים\n- secrets\n- הקשר אסטרטגי פרטי\n\n### אזור ביניים\nדפוסים מוצלחים שהתגלו בעבודה פרטית עשויים להפוך לשיתופיים **רק אחרי abstraction**.\n\n## למה self-evolution מסוכן בלי שערים\n\nAuto-improvement נשמע טוב, אבל בלי review הוא עלול ליצור:\n- drift\n- regression חבוי\n- דליפת פרטיות\n- overfitting למקרה אחד\n- skill rot שמתחזה לאופטימיזציה\n\nלכן מערכות מתפתחות צריכות:\n- versioning\n- rollback\n- metrics\n- provenance\n- promotion review\n\n## השלכות על סוכנים אישיים\n\nלעצמך, לחברים או למשפחה:\n- משתפים פרוצדורות שאפשר למחזר\n- שומרים זיכרון ב-scope מוגבל\n- לא משכפלים personal memory לכל סוכן חדש\n- בונים starter templates ומשפרים אותם לאורך זמן\n\n## השלכות על CoachOS\n\nCoachOS יכול להרוויח ממערכות מתפתחות, אבל רק אם הוא עומד בכלל קשיח יותר:\n\n> שתף patterns, אף פעם לא raw people.\n\nדפוסי coaching שניתנים לאבסטרקציה אפשר לשפר ולמחזר. הקשר אישי גולמי לא צריך לעבור בין משתמשים.\n\n## המלצה פרקטית\n\nאם אתה רוצה מערכת סוכנים שמשתפרת עם הזמן:\n- בנה shared skill library\n- תעד כשלונות חוזרים\n- הגדר skill candidates\n- קדם בזהירות\n- הפרד בין private memory ל-reusable capability\n\nככה בונים מערכת סוכנים שלומדת בלי להפוך למבולגנת, מסוכנת או דולפת."}],"total":1,"limit":null,"offset":0,"next_cursor":null}