Agentic Operating: איך מתפעלים עם agents, בלי לקנות מערכת הפעלה

“agentic operating system” זה לא מערכת הפעלה, וזה גם לא מוצר. זה runbook שנתתם למודל להריץ, עם זיכרון בצד והרשאות מוגדרות. כל השאר שיווק.

ובכל זאת השם נדבק. ב-28 באוקטובר OpenAI פרסמו case study על Legora, סטארטאפ משטוקהולם שקם ב-2023. המנכ“ל, מקס יונסטרנד, קורא למוצר שלו “the agentic operating system for legal work”. שבעה חודשים לפני כן, ב-29 במרץ, פריאנק מלוויה כתב במדיום על Agentic OS לפלטפורמות דאטה. ב-C3 קוראים בערך ככה לשכבת ה-orchestration שלהם. שלושה דברים שונים לגמרי, ואותו שם.

רגע, אז מה כן משותף להם? דרך עבודה. ה-agents עושים את הצעדים, אתם מגדירים את הגבולות, ומישהו בודק מה יצא. והמספר הכי מעניין בכתבה על Legora בכלל לא קשור לעורכי דין. הוא על צוות ה-engineering שלהם: מ-bug report לתיקון עובד “בערך בחמש דקות”, כש-coding agents סורקים מיליוני שורות לוגים ובודקים כמה הסברים במקביל.

מה זה agentic AI כבר הסבירו AWS ו-Aerospike, ואנדרו נג דחף את המילה עוד ב-2024. על זה אני מדלג. הנה איך מתחילים לתפעל ככה בפועל: לולאה אחת, צעד אחרי צעד.

01 · בוחרים לולאה אחת, לא תהליך שלם

טעות שראיתי בכמה צוותים: “נעביר את ה-on-call ל-agents”. זו לא לולאה, זו משאלה.

לולאה טובה חוזרת כמה פעמים בשבוע, יש לה טריגר ברור וסוף שאפשר לבדוק. ב-Legora זה bug report → fix. אצל פריאנק זה שינוי schema בטבלה אחת, ומה צריך להשתנות בעקבותיו ב-pipelines וב-dashboards. אצלכם זה יכול להיות CI אדום על main, או alert שצריך triage.

מה עושים: כותבים שורה אחת, עם טריגר, סוף ומי מאשר.

טריגר: issue חדש ב-Sentry עם environment=production. סוף: PR עם טסט שנכשל לפני התיקון ועובר אחריו. מאשר: מי שב-on-call.

מה רואים: baseline. תוציאו מה-Jira את 10 הבאגים האחרונים מ-prod ותחשבו חציון בין created ל-resolved. בלי המספר הזה אין לכם מול מה להשוות בצעד 06.

02 · כותבים חוזה: מה ה-agent רואה ובמה הוא נוגע

ביולי 2025 agent של Replit מחק את ה-database של production אצל ג’ייסון למקין מ-SaaStr, באמצע code freeze מוצהר. אחר כך הוא כתב שהוא נכנס לפאניקה. כולם צחקו על הניסוח. אבל הבעיה לא הייתה המודל. הבעיה הייתה שהיו לו הרשאות כתיבה ל-prod.

הכלל: קריאה רחבה, כתיבה צרה. לוגים, ה-repo, replica לקריאה בלבד: כן. credentials של prod, kubectl delete, push: לא. בקלוד קוד זה קובץ אחד ב-repo:

{
  "permissions": {
    "allow": [
      "Read(./logs/**)",
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(git push:*)",
      "Bash(kubectl delete:*)",
      "Bash(rm -rf:*)"
    ]
  }
}

deny גובר על allow, אז מתחילים לכתוב מה-deny. מה שלא ברשימה, בסשן אינטראקטיבי קלוד שואל לפני, וב-claude -p זה פשוט נחסם. תריצו /permissions בתוך סשן ותוודאו שהכללים נטענו. ואת ה-push? אתם עושים, בצעד 05.

03 · מוציאים את הזיכרון מהשיחה

פריאנק ניסח את זה הכי טוב: רוב המערכות מחזיקות context דרך היסטוריית השיחה, וזה עובד לצ’אט אבל לא לתשתית. לפתרון שלו הוא קורא Agentic Brain, זיכרון קבוע על שינויים קודמים, תלויות ופעולות שכבר נעשו.

לא צריך בשביל זה מוצר. צריך קובץ. כל ריצה של הלולאה קוראת אותו בהתחלה ומוסיפה רשומה בסוף:

## 2026-11-02 · Sentry PROJ-4812 · TypeError in checkout
- נבדק: cache-miss (נשלל: הבאג חוזר גם עם cache מלא)
- נבדק: race-condition (אושר: שתי בקשות על אותו cart)
- תוקן: PR #1931, טסט test_concurrent_cart
- לא לנסות שוב: להגדיל timeout. לא קשור.

ותפתחו שיחה חדשה לכל ריצה. שיחה ארוכה עולה יותר בכל הודעה וגם עונה פחות טוב. בגדול, זה ההבדל בין agent שצובר ניסיון לבין agent שמתברבר באותה השערה בפעם הרביעית.

04 · מריצים כמה השערות במקביל

זה הצעד שבאמת שונה מאיך שעבדנו עד עכשיו. ה-CTO של Legora, ג’ייקוב לאוריצן:

“We can explore 20 solutions at the same time and, within days, pick the one we know will be the best.”

הוא מדבר על פיתוח פיצ’רים, אבל זה עובד בדיוק אותו דבר בתקלות. במקום שלושה מהנדסים שבודקים שלוש סיבות אפשריות במשך שעות, יש שלושה agents, כל אחד עם השערה אחת. הטריק הטכני הוא git worktree, כדי שלא ידרכו אחד לשני על הקבצים:

#!/usr/bin/env bash
BUG="$1"
for h in cache-miss race-condition bad-migration; do
  git worktree add "../fix-$h" -b "fix/$h"
  ( cd "../fix-$h" && claude -p "Bug: $BUG. Hypothesis: $h.
    Read OPS_LOG.md first. Prove or disprove it from ./logs.
    If proven: write a failing test, then the fix.
    First line of FINDINGS.md: VERDICT: PROVEN or VERDICT: DISPROVEN." \
    > "../fix-$h.log" 2>&1 ) &
done
wait
grep -l "^VERDICT: PROVEN" ../fix-*/FINDINGS.md

מה רואים: שלושה קבצי FINDINGS.md. בדרך כלל שניים שוללים ואחד מאשר, ולפעמים אף אחד, שזה גם מידע. שלוש ריצות שורפות פי 3 טוקנים. מול שלושה מהנדסים לכמה שעות, זה עדיין די משתלם. אחר כך git worktree remove על כל מה שנשלל.

05 · שער אימות לפני שמשהו מתקרב ל-prod

agent שכתב תיקון עוד לא תיקן כלום. השער אצלי פשוט: טסט שנכשל על main ועובר על הענף. אם ה-agent לא הצליח לכתוב טסט שנכשל, הוא לא הבין את הבאג, ולא משנה כמה יפה התיקון נראה.

בפועל ב-GitHub: Settings → Branches → branch protection על main, עם Require a pull request before merging, Required approvals = 1, ו-Require status checks to pass. את ה-push אתם עושים, רק מהענף שעבר: git push -u origin fix/race-condition && gh pr create --fill. CI רץ, בן אדם לוחץ merge. עם ה-deny מצעד 02, ל-agent אין איך לעקוף את זה גם אם ממש ירצה.

06 · מודדים זמן, לא תחושה

אחרי שבועיים חוזרים ל-baseline מצעד 01. אותו חישוב בדיוק: חציון מ-created ל-resolved, רק על באגים שעברו בלולאה. ועוד שני מספרים: כמה PRs של agents נכנסו בלי שינוי ידני, וכמה פעמים השער מצעד 05 עצר משהו. אם השער אף פעם לא עוצר כלום, כנראה שהוא לא בודק כלום.

הסתייגות: אני לא קונה את החמש דקות כיעד. זה case study שספק המודל כתב על לקוח שלו, ובטקסט המקורי כתוב sometimes, והמילה הזאת מסתירה הרבה. תמדדו את החציון שלכם מול החציון שלכם. זה המספר היחיד שמעניין.

כלל אצבע שלי: אם אחרי שבועיים פחות מחצי מה-PRs נכנסים בלי תיקון ידני, הלולאה לא בנויה נכון. ובדרך כלל חסר context, לא מודל. תוסיפו ל-OPS_LOG ול-allow לפני שאתם מחליפים לאופוס.

מה לקחת

• לולאה אחת עם טריגר וסוף, ומספר baseline לפני שמתחילים.
• deny לפני allow. קריאה רחבה, כתיבה צרה, ואת ה-push עושים אתם.
• זיכרון בקובץ, שיחה חדשה לכל ריצה.
• אין PR בלי טסט שנכשל לפני ועובר אחרי.