תזמור Multi-Agent: חמישה דפוסים, ומתי אחד מנצח

חברה פורטוגלית כותבת לגבי חשבונית FT-2026-0918. האימייל אומר שהמע״מ נראה שגוי, ומצרף את החשבונית: נטו EUR 248.00, מע״מ שנגבה בשיעור 21 %, EUR 52.08, סך הכול EUR 300.08.

העובדות הדרושות לתשובה נמצאות בשלושה מקומות, ורק אחד מהם נמצא באימייל:

מחברים את השלושה והחשבונית שגויה: חל reverse charge, המע״מ היה צריך להיות אפס, ויש להוציא זיכוי על EUR 52.08. מסתכלים רק על החשבונית והיא מושלמת אריתמטית — 248.00 ועוד 52.08 הם 300.08 — וכך גם תגידו.

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

כל מה שלמעלה רץ מול ספק מתוסרט בסגנון של פרק 23, עם כלל אחד בדיוק:

תשובה רשאית להשתמש רק בעובדה שנמצאת ב-prompt שלה.

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

חמשת השמות שלמטה הם של Anthropic, מתוך Building effective agents, ושם אוצר המילים הזה התייצב.¹ אף אחד מחמשת הרעיונות אינו חדש, ולהגיד מי נתן איזה שם — ואיזה רעיון ותיק יותר — הוא חצי מהערך שבידיעתם.

/* 1. Prompt chaining: a fixed pipeline. The control flow is yours. */
export async function chain(steps: Step[], first: string) {
  let carry = first, all = first;
  for (const s of steps) {
    const r = await step(s.role, s.system, s.accumulate ? all : carry);   
    carry = r.text;
    all = `${all}\n${r.text}`;
  }
  return carry;
}

/* 2. Routing: one cheap call picks the branch. The fallback is not a model. */
export async function route<T>(input: string, classify: Classifier,
                               routes: Record<string, Branch<T>>, fallback: Branch<T>) {
  let label: string | undefined;
  try { label = await classify(input); } catch { label = undefined; }
  return ((label && routes[label]) || fallback)(input);                    
}

/* 3. Parallelisation. The pattern IS this line. */
export const parallel = <T>(workers: Branch<T>[], input: string) =>
  Promise.all(workers.map((w) => w(input)));                              

/* 4. Orchestrator-workers: an agent behind a tool. Chapter 18's interface, unchanged. */
export function agentTool(o: WorkerSpec): Tool {
  return {
    name: o.name, description: o.description, readOnly: true,
    parameters: { type: "object", properties: { question: { type: "string" } } },
    async run(args: { question: string }) {
      const child = newRun(o.system, args.question);          // its own window
      await runTracked(child, o.tools, o.usage);              // its own limits
      const conclusion = child.output ?? "no result";
      if (!o.carryFindings) return conclusion;                             
      return `${conclusion}\nFINDINGS ${evidence(child)}`;                 
    },
  };
}

/* 5. Evaluator-optimiser: make, judge, remake. Rounds are calls. */
export async function refine(make: Make, judge: Judge, maxRounds: number) {
  let draft = "", feedback: string | undefined;
  for (let r = 1; r <= maxRounds; r++) {
    draft = (await make(feedback)).text;
    const j = await judge(draft);
    if (j.ok) return { draft, rounds: r };
    feedback = j.note;
  }
  return { draft, rounds: maxRounds };
}

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

Prompt chaining ״מפרק משימה לרצף של צעדים, שבו כל קריאת LLM מעבדת את הפלט של הקודמת״.¹ הרעיון קודם למודלי שפה: זו pipeline, עם עסקת החליפין של pipeline — בהירות תמורת control flow שנקבע לפני שהנתונים מגיעים.

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

--- relay: each step sees only the previous step's output
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 vat_amount=52.08 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=unknown reason=no_invoice_in_context
draft:   "we are looking into invoice FT-2026-0918 and will come back to you."

--- accumulating: each step sees the email and everything produced so far
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=invoice_correct reason=net_248.00_plus_21pct_vat_52.08_equals_300.08
draft:   "we have checked FT-2026-0918 and it is correct... Nothing is owed back."

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

השרשרת המצטברת — השורה בטבלת הפתיחה — עלתה $0.003780, כלומר 95 % יותר עבור ארבע קריאות זהות, כי עכשיו כל צעד נושא את כל מה שהיה לפניו. היא הפיקה את הפלט המסוכן. שוטף, מצטט את האריתמטיקה שלו, נכון בכל מספר שהוא מזכיר, ואומר ללקוח שלא מגיע דבר כאשר מגיעים EUR 52.08.

ההבדל בין השתיים הוא ternary אחד. שרשרת שנושאת פחות מפיקה תשובות שחסרות באופן ברור; שרשרת שנושאת הכול מפיקה תשובות שגויות בביטחון — ורק הסוג השני נשלח.

אף אחד מהם אינו הכשל האמיתי. הכשל האמיתי הוא שה-pipeline החליט, לפני שקרא משהו, שהמשימה הזו היא ארבעה צעדים על תוכן של אימייל. בשום מקום במבנה הזה אין מקום לומר ״מדינת הרישום אינה באימייל הזה; לכו הביאו אותה״. Chaining נכון כשהפירוק ידוע מראש ויציב. כאן זו הייתה השערה, וההשערה נשלחה.

Routing ״מסווג קלט ומפנה אותו למשימת המשך מתמחה״.¹ השם חדש; המנגנון הוא dispatcher, ותיק יותר כמעט מכל דבר אחר בספר הזה. מה שחדש הוא שהמסווג יכול להיות model — וזה מה שגורם לו להיכשל בדרכים ש-switch מעולם לא הכיר.

const answer = await route(email,
  (q) => classifyWithSmallModel(q),          // cheap model, one call
  { billing: billingAgent, tax: taxAgent, dunning: dunningAgent },
  taxAgent,                                  // deterministic, chosen in advance
);

שני דברים לגבי הארגומנט האחרון הזה. זה לא טיפול בשגיאות; זה הדפוס. ל-router מבוסס model יש מצב כשל שאין ל-dispatcher: הוא יכול להחזיר תווית שאינה קיימת, להיתקע בזמן, או — היקר — להחזיר תווית שגויה שנשמעת סבירה בלי שום אות שהיא שגויה. שלושתם חייבים לנחות איפשהו, והאיפשהו לא יכול להיות עוד קריאת model, כי אתם כבר בענף שבו קריאות model נכשלו.

הדבר השני הוא שגם ה-prompt של ה-router אינו בחינם. כדי לבחור model, router צריך קטלוג של models לבחור מתוכו, וכל רשומה בו היא input שה-router משלם עליו לפני שהוא קרא את השאלה של המשתמש. בקצב ה-input שהקורס הזה מתמחר לפיו, קטלוג של כ-3,800 tokens כבר עולה כמו כל ריצת ה-agent בת חמש הקריאות בטבלת הפתיחה. בפועל קריאת ה-routing רצה על model זול, וזו כל הסיבה ש-routing מחזיר את ההשקעה; אבל כדאי לעשות את האריתמטיקה בכיוון הזה במקום להניח. Routing שגוי בדיוק כשהמשימה המנותבת זולה יותר מהחלטת הניתוב.

Anthropic מחלקת את זה לשניים: sectioning — ״פירוק משימה לתת-משימות עצמאיות שרצות במקביל״ — ו-voting — ״הרצת אותה משימה כמה פעמים כדי לקבל outputs מגוונים״.¹ הם חולקים תרשים וכמעט שום דבר אחר.

Sectioning הוא הרווח הזול, והוא השורה מ-patterns.ts: שלושה מומחים — חיוב, מס, מדיניות — כל אחד עם חלון וכלים משלו, על אותו אימייל, וקריאת סינתזה אחת בסוף. אותה עבודה, מסודרת בשתי דרכים:

אותו token אחר token, מהיר פי 1.8. לכן הדפוס זוכה לשם משלו: הוא היחיד מבין החמישה שמשפר משהו בלי לעלות שום דבר. המלכוד הוא שהמקטעים חייבים להיות עצמאיים באמת — תנו למקטע B עובדה שמקטע A מפיק ו-Promise.all מריץ את שניהם מול מצב שעדיין אינו קיים. לולאת for הסתירה את הבאג; השורה האחת חושפת אותו.

Voting הוא חיה אחרת שלובשת את אותה תמונה. להריץ את אותה שאלה k פעמים ולקחת את הרוב הוא self-consistency, שפורסם בידי Wang ואחרים במרץ 2022 כאסטרטגיית decoding, כמעט שלוש שנים לפני שמישהו קרא לו דפוס orchestration. התקציר שלו מדויק לגבי המנגנון — ״קודם דוגם קבוצה מגוונת של נתיבי הסקה במקום לקחת רק את הנתיב החמדני, ואז בוחר את התשובה העקבית ביותר באמצעות marginalizing out של נתיבי ההסקה שנדגמו״ — ולגבי הרווח: +17.9 נקודות ב-GSM8K.²

מכאן נובעים שני דברים שהתמונה מסתירה. ראשית, voting דורש את הדגימה של פרק 17: בטמפרטורה אפס כל k הדגימות הן אותה דגימה, והרוב הוא תשובה אחת ששולמה k פעמים. שנית, זה עובד רק במקום שבו לרוב יש משמעות — בתשובת החשבונית למעלה אין מה לספור, כי חמש טיוטות הן חמישה משפטים שונים. Voting מיועד למשימות עם תשובה קצרה וניתנת להשוואה, שזה בדיוק ה-benchmarks של Wang וכמעט שום דבר ש-agent מול לקוחות עושה.

נמדד כאן על 20 בעיות מילוליות בשלושה צעדים שתשובותיהן מחושבות ולא נשפטות, עם ה-model המקומי של פרק 23 חושב צעד אחר צעד:

פי חמישה קריאות, פי חמישה tokens, בדיוק פי חמישה חשבון, ולא תשובה נכונה נוספת אחת. Voting הוא הימור, לא שיפור, ובריצה הזו הוא הפסיד.

שתי הסתייגויות, לפני שמישהו מצטט זאת כהפרכה של Wang. עשרים ניסויים אינם יכולים להבחין בין 45 % ל-60 % — הרווח הוא ברוחב הטענה, וזו המשמעת של פרק 4 מופנית אל התוצאה שלי. והרווחים שפורסמו מגיעים מ-models גדולים בסדרי גודל, שבהם נתיבי ההסקה המגוונים שעליהם voting עושה marginalize באמת מגוונים. מה שעובר אינו המספר: אלא שהמכפיל מדויק וידוע מראש, בעוד שהרווח לא.

בזרימת העבודה orchestrator-workers ״LLM מרכזי מפרק משימות באופן דינמי, מאציל אותן ל-worker LLMs, ומסנתז את התוצאות שלהם״, וההבדל מ-sectioning הוא ש״תת-המשימות אינן מוגדרות מראש, אלא נקבעות בידי ה-orchestrator״.¹ המקור כאן אינו מודלי שפה כלל: זה master-worker, והגרסה שבה עובדים כותבים ממצאים למרחב משותף שבקר קורא היא ארכיטקטורת blackboard, ממחקר זיהוי דיבור בשנות ה-70. מה שחדש ב-2026 הוא שהבקר הוא model ולכן אפשר להחליט את הפירוק לפי הקלט — הגמישות והעלות במשפט אחד.

זה עלה 12 קריאות model לעומת 5 של agent יחיד, והגיע לאותה הכרעה. ואז הוא עשה משהו ששווה להתבונן בו מקרוב:

orchestrator final: VERDICT=credit_note_due amount=52.08 source=worker_unverified
                  | PO_MISMATCH=yes source=worker_unverified
single agent:       VERDICT=credit_note_due amount=52.08 reason=reverse_charge_should_have_applied
                  | PO_MISMATCH=yes invoice_says=PO-4417 order_says=PO-4471

שניהם נכונים. רק אחד יודע למה. ל-tax worker היו החשבונית, ההזמנה וטבלת המס בחלון שלו, הוא הגיע למסקנה, וגם שם לב — איש לא ביקש — שמספר הזמנת הרכש בחשבונית אינו תואם לזה שבהזמנה. ואז הוא החזיר סיכום. ה-orchestrator יכול לחזור על שתי האמירות ולא לבדוק אף אחת, כי הראיות נשארו בחלון שהוא מעולם לא ראה. זו שאלת הסיום של פרק 24, עם תשובה: ההורה יכול להסתכל על כל מה שהילד בחר לכתוב.

התיקון הוא דגל, ויש לו מחיר:

שנים-עשר אחוז יותר input tokens, 8.3 % יותר כסף, והביטוי source=worker_unverified נעלם מהתשובה. זו העסקה בכל multi-agent system והיא כמעט אף פעם לא נאמרת: החלון הנקי של הילד שווה שיהיה, יכולת הביקורת של ההורה שווה תשלום, ואי אפשר לקבל את שניהם בחינם.

אז מתי orchestrator-workers שגוי? כאן, במשימה הזו. הוא קנה תשובה נכונה ש-agent אחד עם אותם ארבעה כלים גם הגיע אליה, תמורת פי 1.66 עלות ופי 2.3 זמן שעון, והפך את התשובה הזו לקשה יותר להגנה. ההנחיה של Anthropic עצמה אומרת זאת לפני שהדפוסים מתחילים: למצוא ״את הפתרון הפשוט ביותר האפשרי, ולהגדיל מורכבות רק כשצריך״, כי ״agentic systems לעיתים קרובות מחליפים latency ועלות בביצועי משימה טובים יותר״.¹ הטבלאות למעלה הן המשפט הזה עם מספרים מתחתיו.

קריאה אחת מייצרת, אחרת מעריכה, והלולאה חוזרת עד שההערכה עוברת.¹ האבות שפורסמו הם Self-Refine — אותו model כ-״generator, refiner, and feedback provider״, שמדווח על כ-20 נקודות שיפור מוחלט בממוצע על פני שבע משימות³ — ו-Reflexion, ששומרת את הביקורת ב-buffer אפיזודי בין ניסיונות ומדווחת על 91 % pass@1 ב-HumanEval כשה-baseline הגיע ל-80 %.⁴

מודל העלות הוא הפשוט ביותר מבין החמישה: שתי קריאות לסיבוב, ומספר הסיבובים אינו שלכם. שלושה סיבובי refinement על משימה שלקחה קריאה אחת הם שש קריאות, ולכן הרצפה של הדפוס היא 6× והתקרה שלו היא כל cap שתגדירו — מה שהופך את יציאת התקציב של פרק 23 לחובה ולא לסדר אסתטי.

התקרה עדינה יותר, ואפשר למדוד אותה. על אותן 20 בעיות ה-model המקומי ענה נכון על 9. אחר כך הראו לו כל אחת מהתשובות האלה ושאלו אם היא נכונה — בלי לומר לו שהתשובה שלו עצמו, מה שמסיר את הטיית החנופה ומשאיר את שאלת היכולת:

זה שופט טוב יותר מכפי שכותרת הסעיף מרמזת, ולומר זאת זו הנקודה של מדידה במקום קביעה: הוא לא חסם שום דבר נכון ותפס 8 מתוך 11 טעויות. כמסנן, הוא שווה את הקריאות שלו.

ככלל עצירה, שזה מה שלולאת evaluator-optimiser משתמשת בו בפועל, שלושת האישורים האלה הם כל הסיפור: הם מסיימים את הלולאה עם תשובה שגויה ביד, ושום מספר של סיבובים נוספים לעולם לא מגיע אליהם. לולאת refinement אינה יכולה להיות נכונה יותר מהשופט שלה. קניית סיבובים נוספים קונה ניסיונות לטפל בשגיאות שהשופט יכול לראות, במחיר מלא, ושום דבר מול אלה שאינו יכול.

מכאן הכלל: evaluator מרוויח את הקריאות שלו רק כשיש לו משהו שאין ל-generator. קומפיילר, חבילת בדיקות, schema validator, model אחר, אדם. התוצאות של Self-Refine עצמה נמדדות מול העדפת אדם ומדדי משימה, לעולם לא מול דעתו של ה-model על עצמו. אם היתרון היחיד של ה-evaluator שלכם הוא prompt אחר, אתם משלמים כפול על הסכמה. פרק 29 בונה את הגרסה עם יתרון אמיתי: golden set שהתשובות שלו כתובות מראש.

החמישה שלמעלה הם צורות עבור הקוד שלכם. מתחתיהם יושבת משפחה שנייה שלעיתים קרובות רשומה לצידם ולא צריכה להיות: ReAct, Reflexion, plan-and-execute ו-tree of thoughts הן לולאות הסקה, והעלות שלהן היא בבקשות.

פרק 12 עסק בהסקה בתוך ה-model, שעליה אתם משלמים ב-output tokens בקריאה אחת. זה הסוג השני. ההבדל חשוב כשהחשבון מגיע: chain of thought ארוך יותר מייקר קריאה אחת, ולולאת הסקה הופכת משימה אחת לקריאות רבות, שכל אחת מהן שולחת מחדש את כל מה שקדם לה — הריבועיות שפרק 23 מדד בטבלת ההשתוללות שלו.

מאמר tree-of-thoughts מפרסם טבלת עלויות משלו, וזה נדיר מכפי שראוי. ב-Game of 24 עם GPT-4: input/output prompting best-of-100 פתר 33 % ב-$0.13 למקרה, chain of thought best-of-100 פתר 49 % ב-$0.47, ו-tree of thoughts פתר 74 % ב-$0.74, כשהמחברים מציינים שהוא ״could require 5-100 times more generated tokens than CoT״.⁷

כמעט פי שישה ממחיר השיטה הזולה עבור קצת יותר מכפול שיעור הצלחה. האם זו עסקה טובה תלוי במה עולה לכם מקרה שנכשל — השאלה שצריך לשאול לפני שמאמצים כל אחת מהארבע.

הקורס הזה אינו מממש אותן מחדש. לכל הארבע יש מימושי reference של המחברים שלהן, ב-Python, והערך שלהן הוא להיות המקור ולא תרגום: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm ו-AGI-Edgerunners/Plan-and-Solve-Prompting. קראו את ה-prompts במאגרים האלה; ה-prompts הם המאמרים.

עכשיו multi-agent ממש, המקום שבו רוב הבלבול חי. יש שתי דרכים שבהן agent אחד מערב agent אחר, הן אינן וריאנטים, וההבדל הוא מי נשאר אחראי אחר כך.

Agent ככלי. ההורה קורא לו, מקבל תשובה, וממשיך. זה ממשק הכלי של פרק 18 עם agent שלם מאחוריו, וההורה לעולם לא מאבד שליטה. זה מה שה-orchestrator למעלה עושה.

Handoff. ההורה מעביר את השיחה ואינו מקבל אותה בחזרה. המדריך של OpenAI הוא ההצהרה שפורסמה בצורה הברורה ביותר: handoffs הם ״a one way transfer that allow an agent to delegate to another agent... If an agent calls a handoff function, we immediately start execution on that new agent that was handed off to while also transferring the latest conversation state.״⁸

אזהרת אוצר מילים, כי זה מפיל אנשים שוב ושוב: ״handoff״ היא מילה של SDK אחד, לא תקן. זו טרמינולוגיה מ-OpenAI Agents SDK ומהמדריך הזה, שגם קורא לשני הסידורים ״manager״ ו-״decentralized״ ומציין שבדפוס manager ״edges represent tool calls whereas in the decentralized pattern, edges represent handoffs״.⁸ יש כן תקן פתוח במרחב הזה — A2A, בגרסה 1.0.0, תחת זכויות היוצרים של Linux Foundation, עם היסטוריית גרסאות מתועדת ורשימת breaking changes מתועדת, שהעיקרון המוצהר שלו הוא opaque execution: agents ״collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations״.⁹ זה לא handoff, וההשוואה שייכת לפרק 26. מה שחשוב כאן הוא שאחת משתי המילים היא API של ספרייה והשנייה היא specification עם ממשל.

ההבחנה היא מבנה נתונים, לא תרשים:

export type EdgeKind = "tool" | "handoff";
export interface AgentEdge { from: string; to: string; kind: EdgeKind }
export interface AgentGraph { root: string; agents: Record<string, AgentSpec>; edges: AgentEdge[] }

/** One agent may not be both a tool of X and a handoff target of X. */
export function conflicts(g: AgentGraph): AgentEdge[] {
  const seen = new Map<string, EdgeKind>();
  const bad: AgentEdge[] = [];
  for (const e of g.edges) {
    const key = `${e.from}->${e.to}`;
    const other = seen.get(key);
    if (other && other !== e.kind) bad.push(e);                            
    else seen.set(key, e.kind);
  }
  return bad;
}

/** Every agent reachable from the root, and at what depth. */
export function reachable(g: AgentGraph): Map<string, number> {
  const depth = new Map([[g.root, 0]]);
  const queue = [g.root];
  while (queue.length) {
    const id = queue.shift()!;
    for (const e of g.edges.filter((x) => x.from === id)) {
      if (depth.has(e.to)) continue;
      depth.set(e.to, depth.get(id)! + 1);
      queue.push(e.to);
    }
  }
  return depth;
}

עשרים שורות, שני באגים שאחרת הייתם מוצאים בפרודקשן. reachable מוצא את ה-agent שאיש לא יכול להגיע אליו — מוגדר, משולם, לעולם לא נקרא. conflicts מסרב ל-edge שהוא שני הסוגים בבת אחת, מה שנשמע קטנוני עד שקוראים זאת בקול: ההורה גם שומר שליטה וגם מוסר אותה. הריצו את זה על מערכת של חמישה agents עם יתום אחד ו-edge כפול אחד:

reachable: lead@0 billing@1 tax@1 dunning@1
orphans:   ghost
conflicts: lead->tax

עכשיו המדידה שלשמה הסעיף הזה קיים, והיחידה בפרק שנלקחה מול model אמיתי ולא מתוסרט.

לקוח מציין אילוץ בהודעה הראשונה שלו — החשבון שלנו רשום בפורטוגל, לא בספרד; כל דבר שקשור למס חייב להשתמש בפורטוגל — משוחח על משהו אחר, ואז שואל שאלה שהחיוב חייב לענות עליה. המקרה מועבר. עשרים וארבעה ניסויים, מדינה וחברה שונות בכל פעם, ארבעה payloads להעברה, ואז ה-agent המקבל נשאל שאלה אחת: באיזו מדינה רשום החשבון של הלקוח הזה?

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

התמליל המלא הוא 173 tokens ועובד 83 % מהזמן, כשארבעת הכשלונות שלו הם הנושא של פרק 24 ולא של זה. הרשומה ה-typed היא 69 tokens — שבעה יותר מהסיכום — ועובדת בכל פעם, כי האילוץ יושב בשדה בעל שם במקום במשפט.

והסיכום הוא השורה שצריך לבהות בה. הוא נכשל 24 פעמים מתוך 24, והסיבה אינה שהקורא פספס אותו. האילוץ הופיע רק ב-1 מתוך 24 הסיכומים בכלל. ה-agent המקבל לא היה רשלן; הוא קיבל טקסט שלא הכיל את התשובה. סיכום הוא דחיסה שלא אתם כתבתם, שמיוצרת בידי model שאת חלונו אינכם יכולים לראות, וממוטבת להיקרא כמו סיכום — ו-״הלקוח אומר שברשומות שלנו המדינה שגויה״ הוא בדיוק סוג הפסוקית ש-summariser משמיט כרעש פרוצדורלי.

גבול ישר על המספר הזה: ה-summariser הוא model של חצי מיליארד פרמטרים, וגדול יותר היה שומר יותר. מה שאינו משתפר עם הגודל הוא צורת הסיכון — ה-agent השולח מחליט, בכל handoff, בכל ניסוח, באופן בלתי נצפה, אילו עובדות שורדות. הרשומה ה-typed אינה תלויה בשיפוט הזה כלל, ולכן היא מנצחת מכוח הבנייה ולא מכוח אינטליגנציה. כל מה שחייב לשרוד העברה צריך להיות שדה, לא משפט.

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

שלוש עובדות סיום, כולן מהטבלאות למעלה.

multi-agent system מכפילה קריאות, וקריאות הן ריבועיות ב-context. ה-orchestrator עשה 12 קריאות model במקום שבו agent אחד עשה 5, וכל אחת נושאת transcript הולך וגדל משלה — 3,628 input tokens מול 2,697, פער שמתרחב עם אורך המשימה.

כל גבול הוא ערוץ מאבד. שני agents פירושם סיכום אחד. ארבעה agents בשרשרת פירושם שלושה, מורכבים, שכל אחד נכתב בידי model שממטב למשהו שאינו ההחלטה שלכם.

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

כל זה אינו טיעון נגד ה-multi-agent frameworks שפורסמו, ושווה לקרוא אותם כמקורות ראשוניים ולא דרך מדריכים.¹⁰ זה טיעון לכך שה-agent השני צריך להצדיק את מקומו.

לכן, מבחן ולא העדפה. הוסיפו agent שני כשאחד לפחות מאלה נכון: תת-המשימה צריכה חלון נקי שההורה לא חייב לרשת (פרק 24); תת-המשימות באמת עצמאיות וזמן השעון חשוב, שזה ה-1.8× למעלה; תת-המשימה צריכה הרשאות שונות או model אחר, מה שפרק 30 הופך לטיעון אבטחה; או שתת-המשימה בבעלות מישהו אחר, המקום שבו protocol אמיתי מתחיל להיות חשוב. אם התשובה היא ״כדי שלכל agent יהיה prompt ברור יותר״, תנו ל-agent האחד prompt ברור יותר. זה בחינם.

עכשיו אתם יכולים לנקוב בשמות חמשת הדפוסים, לתמחר אותם זה מול זה על משימה אחת, להבדיל orchestrator מ-sectioner ו-tool call מ-handoff, ולהגן על agent יחיד באמצעות טבלה במקום העדפה.

כל סידור כאן חלק נוחות אחת שלא תשרוד מגע עם שום דבר אמיתי: כל הכלים היו שלנו. חשבונית, הזמנה, טבלת מס, העובדים מאחורי ה-orchestrator — אותו repository, אותו deploy, אותם types, אותם אנשים.

עכשיו שימו אחד מהם מעבר לגבול חברה. טבלת המס שייכת לספק חשבונאות, רשומת ההזמנה למערכת מחסן, ואף אחד מהם לא קרא את ממשק Tool שלכם. אתם צריכים דרך עבור model שלא כתבתם לגלות, לתאר ולקרוא ליכולת שמישהו אחר מפעיל — עם authentication (שהוא החצי של פרק 27), versioning, והבטחה ששרת אינו יכול לקרוא את שאר השיחה שלכם. זו בעיית protocol, יש לה specification עם schema נורמטיבי, וכמעט כל מה שמאונדקס עליה מתאר גרסה שכבר לא קיימת.

פרק 26 קורא את ה-specification הזה במקום לסכם אותו, ומתחיל בהקלדת JSON-RPC בטרמינל ביד.

כל עלות וספירת token למעלה הגיעו מהספק המתוסרט שתואר בסעיף השני, על Node 22 מעל loopback interface, בספירה עם encoding של o200k_base ובתמחור לפי התעריפים שפרק 16 קרא ב-6 בספטמבר 2026 — $2.00 למיליון input tokens ו-$12.00 למיליון output. נתוני זמן השעון הם מאותן ריצות כשה-latency של הספק נקבע ל-400 ms לקריאה וכלים ל-50 ms, כך שהם מודדים את הסידור ולא ספק כלשהו. שתי מדידות ה-model האמיתי — טבלת ה-handoff וטבלת ה-voting-and-judging — השתמשו ב-Qwen/Qwen2.5-0.5B-Instruct ב-float32 על ה-CPU מאחורי endpoint באותה צורה, greedy למעט כשמצוינת טמפרטורה, עם רווחים שחושבו בשיטת Wilson מפרק 4. שום בקשה בפרק הזה לא נשלחה ל-endpoint בתשלום, ושום מספר בו לא הוערך.