שיעור אחת נקודה שלוש — Make.com מתקדם: Routers, Iterators, Error Handling ו-AI Agents.

שלום וברוכים הבאים. אני שמח שאתם איתי בשיעור הזה, כי זה השיעור שבו Make.com עובר מכלי נחמד לפלטפורמת פרודקשן אמיתית.

בשיעור הקודם בנינו את הבסיס — Scenarios, Modules, Connections, Data Mapping, ו-Maia AI Builder. כבר יש לכם Webhook שמושך לקוחות ל-Google Sheets ושולח מיילים. זה היה המבנה הבסיסי.

היום נעלה רמה. נלמד את הכלים שהופכים Scenario פשוט לאוטומציה שרצה בלי השגחה בסביבת פרודקשן אמיתית. Routers שמסתעפים לנתיבים שונים. Iterators שמעבדים רשימות. Error Handling שמטפל בכשלות בצורה חכמה. ו-AI Agent Node — הכלי שהופך Make לפלטפורמת בניית AI Agents.

בסוף השיעור הזה — לפני שנגיע ל-n8n — יהיה לכם הבנה מלאה של מה Make יכול לעשות. ותוכלו לבנות כל אוטומציה מורכבת שלקוח יבקש.

[מעבר שקף]

ארבעת נושאי הליבה של היום:

הראשון — Router. זה Module שמסתעף לכמה נתיבים לפי תנאים. כשליד מגיע מהאתר, אם הוא מתל אביב — נתיב אחד. אם מחיפה — נתיב שני. אם VIP — נתיב שלישי. הכל בתוך אותו Scenario.

השני — Iterator ו-Aggregator. עיבוד רשימות. קיבלתם מייל עם חמישה קבצים מצורפים? Iterator פיצל אותם לחמישה Bundles, כל אחד מטופל בנפרד. Aggregator אסף אותם חזרה לBundle אחד. זה הכלי לעבודה עם כמויות.

השלישי — Error Handling מלא. מה קורה כשמשהו נשבר בפרודקשן. יש שישה מצבים שונים — Break, Ignore, Retry, Resume, Rollback, ו-Error Route. כל אחד מתאים לסיטואציה שונה.

הרביעי — AI Agent Node. Module מיוחד שמכניס מוח לתוך ה-Scenario. הוא יכול לקרוא תוכן, להבין הקשר, לקבל החלטות, ולהפעיל כלים בהתאם.

[מעבר שקף]

נתחיל עם Router. עד עכשיו כל ה-Scenarios שבנינו היו ישרים — Module אחרי Module בשורה. אבל החיים לא ישרים.

Router הוא Module מיוחד שמקבל Bundle ומפנה אותו לאחד מכמה נתיבים, על פי תנאים. זה כמו תפריט בטלפון — "לשירות לקוחות לחצו אחת, לתמיכה טכנית לחצו שתיים".

מתי צריך Router? יש כמה תרחישים קלאסיים. סיווג לקוחות — ליד חדש שמגיע מישראל יקבל WhatsApp, ליד מחו"ל יקבל מייל באנגלית. ניתוב לפי מוצר — הזמנה נכנסת למוצר א' הולכת לספק א', הזמנה למוצר ב' הולכת לספק ב'. טיפול שונה לפי סטטוס — לקוח קיים מקבל עדכון ב-CRM, לקוח חדש מקבל יצירת ריישומה חדשה במערכת. ופעולות מקביליות — אותה הזמנה מעדכנת גם Google Sheets, גם Slack, גם Monday — בו זמנית.

מה ההבדל בין Router לבין Filter רגיל? Filter הוא בינארי — Bundle עובר או לא עובר. שחור או לבן. Router הוא צבעוני — Bundle יכול ללכת לנתיב אחד, לשני, או לשניהם יחד אם הוא עומד בכמה תנאים.

[מעבר שקף]

ה-Router ב-Make נראה כמו עיגול עם כמה זרועות. כל זרוע היא Route.

לכל Route יש שלושה חלקים. Filter — התנאי. Bundle שעומד בתנאי ירוץ בנתיב הזה. Sequence of Modules — שרשרת ה-Modules שרצים בנתיב הזה. ו-Fallback Route — נתיב ברירת מחדל שרץ אם Bundle לא עמד באף תנאי אחר.

ישנם כמה כללים חשובים. Make בודק את ה-Routes מלמעלה למטה. Bundle שעומד בתנאי של Route הראשון וגם השני — ירוץ בשניהם. זה מאפשר פעולות מקביליות על אותו Bundle. Bundle שלא עומד בשום תנאי — ירוץ רק ב-Fallback Route.

וכאן טיפ קריטי לפרודקשן: תמיד הוסיפו Fallback Route. Bundle שלא עומד בשום תנאי ואין Fallback — נעלם בשקט בלי שום התרעה. זו באג קלאסית שגורמת לאבדן נתונים.

[מעבר שקף]

עכשיו בונים ביחד. ניקח את ה-Scenario מהשיעור הקודם — Webhook אחר Google Sheets אחר Gmail — ונוסיף Router שמפצל לפי סוג הפנייה.

התרחיש: לקוח ממלא טופס עם שדה "נושא הפנייה". אם תמיכה טכנית — שלח Slack לצוות הפיתוח. אם הצעת מחיר — שלח Gmail למנהל מכירות. אם אחר — שמור ב-Google Sheets בלבד.

שלב ראשון — הוספת Router. לחצו על הפלוס אחרי ה-Module של Google Sheets. חפשו "Router" ולחצו. מופיע Router עם שתי זרועות ריקות.

שלב שני — Route הראשון לתמיכה טכנית. לחצו על הפלוס בזרוע הראשונה. הוסיפו Slack ואחר כך Send a Message. חברו ל-Slack והגדירו Channel. עכשיו לחצו על הקו שמחבר בין ה-Router ל-Module של Slack. הוסיפו פילטר: שדה נושא, תנאי מכיל, ערך "תמיכה".

שלב שלישי — Route השני להצעת מחיר. לחצו על הפלוס בזרוע השנייה. הוסיפו Gmail ואחר כך Send an Email. הגדירו To לכתובת מנהל מכירות. פילטר: נושא מכיל "מחיר".

שלב רביעי — Fallback Route. לחצו ימין על ה-Router ובחרו Add route. אל תוסיפו פילטר לזרוע הזו — זו תהיה ברירת המחדל לכל שאר המקרים.

שלב חמישי — בדיקה. שלחו שלושה Webhooks שונים: אחד עם נושא "תמיכה", אחד עם "מחיר", ואחד עם "אחר". ב-Run Once תראו מספרים ירוקים שונים מופיעים על Modules שונים בזרועות שונות.

[מעבר שקף]

נעבור לנושא השני — Iterators ו-Aggregators.

Make עובד עם Bundles — יחידות נתונים. ברוב המקרים, כל Bundle הוא פריט אחד. אבל מה קורה כשיש לנו רשימה של פריטים בתוך Bundle אחד?

תחשבו על זה: מישהו שלח לנו CSV עם מאתיים לקוחות. או API של Trello החזיר לנו JSON עם חמישה עשר קלפים. כרגע כל זה הוא Bundle אחד עם מערך בתוכו.

Iterator פוצל את המערך. כל פריט ברשימה הופך ל-Bundle נפרד.

לפני Iterator: Bundle אחד עם חמישה עשר פריטים.
אחרי Iterator: חמישה עשר Bundles בנפרד.

מה זה נותן לנו? כל Bundle מעובד בנפרד על ידי ה-Modules שאחרי ה-Iterator. כך אפשר לשלוח מייל ייחודי לכל לקוח, לעדכן שורה ייחודית לכל רשומה, לקרוא API לכל פריט בנפרד.

איך מוסיפים Iterator? לחצו על פלוס ואחר כך חפשו "Iterator" — זה Module מובנה. בחרו את שדה המערך שרוצים לפצל.

שימו לב לנושא ה-Credits. כל Bundle שנוצר מה-Iterator ירוץ דרך כל ה-Modules שאחריו. מאה פריטים שווים למאה Credits לכל Module. זה חשוב לניהול תקציב.

[מעבר שקף]

ועכשיו Aggregators — ה"הפוך מ-Iterator". הוא אוסף כמה Bundles ומאחד אותם.

יש ארבעה סוגים עיקריים.

Array Aggregator מרכז את כל ה-Bundles לתוך מערך אחד. שימושי כשצריך להעביר רשימה ל-API שמצפה לקבל JSON Array.

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

Numeric Aggregator מבצע חישובים: סכום, ממוצע, מינימום, מקסימום, ספירה. שימושי לדוחות מספריים.

Table Aggregator יוצר טבלת CSV מכל ה-Bundles. מאפשר לייצא נתונים לגיליון אלקטרוני.

דוגמה מהחיים: Iterator שפוצל חמישים הזמנות מ-WooCommerce. כל הזמנה עברה עיבוד — חישוב מע"מ, בדיקת מלאי. Numeric Aggregator חיבר את כל סכומי ההזמנות. Gmail שלח דוח יומי: "סה"כ הכנסות היום: שנים עשר אלף וארבע מאות שקל".

[מעבר שקף]

בונים ביחד: ניקח שורות מ-Google Sheets, נעבד כל אחת בנפרד, ונשלח דוח מרוכז.

התרחיש: גיליון "הזמנות" עם עמודות שם, מוצר, מחיר. נרצה לשלוח מייל יומי עם רשימה מסוכמת.

שלב ראשון: Trigger — Google Sheets — Get Rows לקריאת כל השורות.
שלב שני: Iterator — שדה Rows. עכשיו כל שורה היא Bundle נפרד.
שלב שלישי: Tools — Set Variable. שמרו "שם: נושא, מחיר: מספר". כאן אפשר גם לעשות חישובים.
שלב רביעי: Text Aggregator — צברו את כל הטקסטים, מופרדים בירידת שורה.
שלב חמישי: Gmail — Send Email. כתבו בContent את ה-Aggregated Text.

הריצו. תראו שה-Text Aggregator יסכם הכל ל-Bundle אחד שנשלח כמייל. תחשבו כמה Credits חסכנו — במקום לשלוח מייל לכל שורה בנפרד, שלחנו מייל אחד עם הכל.

[מעבר שקף]

עכשיו מגיעים לחלק הכי חשוב בשיעור הזה, ואחד הכי חשובים בכל הקורס — Error Handling.

בפיתוח, הכלל הוא: "כל מה שיכול להישבר — ישבר". ב-Make זה עוד יותר נכון, כי Scenario תלוי ב-APIs חיצוניים. ה-API של Gmail יכול לקרוס. הרשת יכולה להיות לא יציבה. מישהו יכול לשנות מבנה של Spreadsheet. קוד ה-Webhook יכול לשלוח פורמט שגוי. Token של Connection יכול לפוג.

בלי Error Handling — ה-Scenario פשוט נשבר. נתון אבד. לקוח לא קיבל מייל. תשלום לא עבר.

עם Error Handling טוב — ה-Scenario מזהה את הבעיה, מטפל בה בצורה ייעודית, ומודיע לכם שמשהו קרה.

הכלל של פרודקשן: כל Scenario שנכנס לפרודקשן חייב Error Handler לפחות על ה-Module הקריטי ביותר. זה לא אופציונלי — זה חלק מה-Professional Delivery.

[מעבר שקף]

ל-Make יש שישה מצבים לטיפול בשגיאות. כל אחד מתאים לסיטואציה שונה.

Break הוא ברירת המחדל. Module נכשל — הכל עוצר, Scenario מסומן כ-Error ב-History. ה-Bundle נשמר בתור ה-"Incomplete Executions" — אפשר לנסות שוב ידנית מאוחר יותר. מתאים כשאי אפשר להמשיך בלי ה-Output של ה-Module הזה.

Ignore — Module נכשל וה-Scenario ממשיך כאילו כלום לא קרה. ה-Module שנכשל מחזיר Bundle ריק. מתאים רק כשה-Module לא קריטי. שימו לב — עלול לגרום לנתונים אבודים בשקט.

Retry — Make ינסה שוב עד עשר פעמים, עם רווחי זמן שגדלים אוטומטית. מתאים לשגיאות זמניות כמו "שרת עמוס" או "Timeout" או Rate Limit.

Resume — Module נכשל וה-Scenario ממשיך, אבל ה-Output של ה-Module הנכשל מוחלף בערך שאתם מגדירים. מתאים כשאתם יודעים מה ערך ברירת המחדל הנכון.

Rollback — Module נכשל ו-Make מנסה לבטל את כל הפעולות שכבר בוצעו בהרצה הזו. עובד רק עם מספר Modules שתומכים ב-Rollback. מתאים לפעולות שחייבות להיות "הכל או כלום".

Error Handler Route — הגישה המקצועית. יוצרים נתיב ייעודי לטיפול בשגיאות — בדיוק כמו try/catch בקוד. זה מה שתבנו בדמו.

[מעבר שקף]

עכשיו בונים Error Handler אמיתי. זה מה שנראה בכל Scenario שנבנה לפרודקשן.

התרחיש: Scenario שמשלח חשבונית ל-Gmail. אם Gmail נכשל — אנחנו לא רוצים לאבד את הנתון. רוצים לשמור ב-Google Sheets ולקבל התרעה.

שלב ראשון — הוסיפו Error Handler. לחצו ימין על Module Gmail ובחרו "Add error handler". נפתח תפריט. בחרו "Break" — ואז תוכלו להוסיף Module לנתיב השגיאה.

בנתיב השגיאה — לחצו פלוס. הוסיפו Google Sheets ואחר כך Add a Row בגיליון "שגיאות": שמרו את שם הלקוח, המייל, ומה הייתה השגיאה בשדה error.message. הוסיפו גם Gmail ואחר כך Send Email אל עצמכם עם נושא "שגיאה! לא שלחנו חשבונית ל-שם הלקוח".

בנתיב השגיאה יש לכם גישה לשדות מיוחדים: error.message שמכיל את הודעת השגיאה, error.type שמכיל את סוג השגיאה, ו-error.statusCode שמכיל את קוד HTTP אם רלוונטי.

שלב שני — סמלצו שגיאה. שנו את ה-Connection של Gmail לחשבון שאינו קיים. הריצו. Gmail ינסה ויכשל, ה-Error Handler יתפוס, שורה תישמר ב-Sheets, ומייל התרעה יגיע.

ואחרי הבדיקה — שחזרו את ה-Connection הנכון!

[מעבר שקף]

Data Stores — זיכרון בין הרצות.

כל הרצה של Scenario היא עצמאית. בין הרצות — Make לא זוכר כלום. כל הרצה מתחילה מאפס. Data Store הוא הפתרון. מסד נתונים Key-Value פשוט שחי בתוך Make ונגיש לכל Scenarios בחשבון.

יש ארבעה שימושים עיקריים. Deduplication — מניעת עיבוד כפול. לפני שמעבדים ליד, בודקים ב-Data Store אם כבר עיבדנו את האימייל הזה. ניהול מצב — שמירת סטטוס של תהליך, לדוגמה "הזמנה חמשת אלפים — סטטוס: נשלחה חשבונית". מונים — ספירת כמה פניות הגיעו היום, ואם יותר מעשר — שלח התרעה. Cache — שמירת תוצאה של API call יקר, במקום לקרוא פעמיים.

יוצרים Data Store מה-Dashboard תחת Data Stores ואחר כך Create a new data store. מגדירים שם ו-Structure — השדות שרוצים. כל שורה היא Record.

לעבודה עם Data Store יש Modules ייעודיים: Add or Replace a record, Search records לפי ערך, Get a record לפי מפתח, Delete a record, וה-Check existence of a record שהוא הכי שימושי ל-Deduplication.

שימו לב למגבלות. בתוכנית Core יש מגבלת גודל על כל Data Store. לנתונים גדולים יותר — השתמשו ב-Google Sheets כ-Database.

[מעבר שקף]

ועכשיו לחלק שאני הכי אוהב — AI Agent Node.

עד עכשיו כל ה-Modules שלמדנו הם דטרמינסטיים — פעולה ברורה, תוצאה ברורה. Google Sheets קורא שורה ומחזיר שורה. Gmail שולח מייל. פשוט וצפוי.

AI Agent Node הוא אחר לגמרי. זה Module שמכניס מוח לתוך ה-Scenario. הוא יכול לקרוא תוכן, להבין הקשר, לקבל החלטות, ולפעול.

מה הוא יכול לעשות? לקרוא מייל ולאמר "זו תלונה, זו שאלה, זה ליד חם". לכתוב תשובות מותאמות אישית לכל לקוח. להחליט איזה Tool להפעיל — בדיוק כמו שאנחנו כאן מחליטים איזה כלי להשתמש. ולנהל שיחה ולשאול שאלות הבהרה.

Make השיקו את גרסת הדור הבא של AI Agents באוקטובר שתיים אלפים ועשרים וחמש, ישירות בתוך ה-Canvas. עכשיו אפשר לראות בדיוק מה ה-Agent מחשב ואיזה Tools הוא מפעיל.

מודלים נתמכים: OpenAI עם GPT-4o, Anthropic עם Claude Sonnet ארבע נקודה שש ו-Claude Opus ארבע נקודה שש, וגוגל עם Gemini שתיים נקודה חמש Pro. אפשר גם לחבר endpoints אחרים שתואמים ל-OpenAI.

הכוח האמיתי הוא ה-Tools. כל Module ב-Scenario יכול לשמש כ-Tool של ה-Agent. ה-Agent קורא לו כשהוא צריך.

[מעבר שקף]

בונים Scenario עם AI Agent שמסווג פניות ומגיב אוטומטית.

התרחיש: מייל חדש מגיע ל-Gmail. AI Agent קורא אותו, מחליט אם זו תלונה, שאלה, או ליד חם, וכותב תשובה מתאימה.

שלב ראשון — Trigger. Gmail ואחר כך Watch Emails.

שלב שני — AI Agent Node. לחצו פלוס וחפשו "AI Agent". בחרו. בהגדרות בחרו מודל — Claude Sonnet ארבע נקודה שש מומלץ. בפעם הראשונה תצטרכו להכניס Anthropic API Key. כתבו System Prompt: "אתה עוזר תמיכת לקוחות. קרא את המייל המצורף. סווג אותו לאחת מהקטגוריות: תלונה, שאלה, ליד חם, או אחר. כתוב תשובה קצרה ומקצועית בעברית." מפו את שם הנושא ותוכן המייל מה-Trigger כ-User Message.

שלב שלישי — הוסיפו Tools. בחלק ה-Tools של ה-Agent הוסיפו שלושה Tools: Tool לתשובה לתלונה שהוא Gmail ואחר כך Send Email, Tool לתשובה לשאלה שהוא Gmail נוסף, ו-Tool ליצירת ליד שהוא Google Sheets ואחר כך Add Row בגיליון "לידים".

ה-Agent יחליט בעצמו איזה Tool להפעיל לפי הסיווג שלו.

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

שלב חמישי — ה-Reasoning Panel. לחצו על ה-Run, לחצו על ה-Agent Module, ותראו את לשונית Reasoning. כאן תוכלו לראות בזמן אמת מה ה-Agent "חשב" לפני שהחליט — איזה Tools הוא שקל, ולמה בחר את זה שבחר. זה כלי שקיפות שלא קיים ב-APIs רגילים.

[מעבר שקף]

תכונה מתקדמת אחת נוספת — A2A, שנקרא Agent to Agent, בפועל Scenario שקורא ל-Scenario אחר.

A2A הוא פרוטוקול פתוח שגוגל פיתחו באפריל שתיים אלפים ועשרים וחמש ותרמו ל-Linux Foundation. הוא מאפשר ל-Agents שבנויים על פלטפורמות שונות לתקשר זה עם זה.

מתי שימושי? כשיש לכם Scenario מורכב שאתם רוצים להפעיל ממספר מקומות שונים. כשסוכן AI צריך להחליט מתי לקרוא לתהליך מסוים. ובניית מערכת מודולרית — Scenario "ניהול לקוח" קורא ל-Scenario "שליחת חשבונית" ול-Scenario "עדכון CRM".

שתי גישות מעשיות ב-Make. גישה ראשונה דרך Webhook: ב-Scenario היעד הגדירו Webhook כ-Trigger. ב-Scenario המקור הוסיפו HTTP Module שמבצע POST ל-URL של ה-Webhook. הנתונים עוברים כ-JSON Body.

גישה שנייה דרך Scenarios Module: ב-Make יש Module ייעודי "Scenarios ואחר כך Run a Scenario". זה API ישיר שמפעיל Scenario אחר ויכול לחכות לתוצאה.

כשיש לכם AI Agent Node, ה-Agent עצמו יכול להחליט מתי לקרוא ל-Tool שהוא HTTP Module — שבפועל מפעיל Scenario שני. כך בונים מערכות Multi-Agent ב-Make.

[מעבר שקף]

לפני שנסכם, כמה כללי ברזל לפרודקשן.

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

Error Handling חובה: כל Module שמבצע פעולה קריטית — שליחת כסף, יצירת חשבונית, שליחת מייל ל-VIP — חייב Error Handler.

Logging: הוסיפו Module של Google Sheets שרושם כל הרצה. תאריך, Input, Output, Status. ה-Log הזה יציל אתכם כשלקוח יאמר "לא קיבלתי את המייל".

Deduplication: בכל Scenario שמבוסס על Watch, הוסיפו Data Store לבדיקת כפולות. מניעת עיבוד כפול חוסך Credits ומונע מצבים מביכים עם לקוחות.

Testing Environment: עבדו תמיד עם Google Sheets נפרד וכתובת מייל נפרדת לטסטים. לא תאמינו כמה אנשים שלחו מיילים לא מאושרים ללקוחות VIP בגלל טסטים.

Monitoring: הגדירו Email Notifications ב-Scenario Settings לכל כשלון. Make יש Slack Integration שיכולה להודיע ישירות לערוץ הצוות.

[מעבר שקף]

נסכם את השיעור עם תרחיש שמשלב הכל: Router, Error Handling, Data Store, ו-AI Agent.

התרחיש: מערכת ניהול פניות לקוחות. לקוח ממלא טופס באתר. Webhook מקבל את הנתונים. Data Store בודק אם כבר עיבדנו את האימייל הזה — אם כן, עוצרים. אם לא, AI Agent מסווג את הפנייה. Router מסתעף לשלושה נתיבים: תלונה הולכת ל-Gmail לתמיכה ו-Sheets לתיעוד, ליד חם הולך ל-Gmail למכירות, ל-CRM, ול-Slack Alert, שאלה הולכת ל-Gmail עם תשובה אוטומטית. על ה-AI Agent יש Error Handler שמתעד כל כשלון ב-Sheets ושולח התרעה.

כל מרכיב שלמדנו היום מופיע כאן. זה ה-Scenario שתוכלו לבנות ולמכור ללקוח קמעונאי תמורת שלושה עד שבעה אלף שקל.

[מעבר שקף]

נדבר על תמחור וניהול Credits. Make עברו בקיץ שתיים אלפים ועשרים וחמש ממערכת Operations למערכת Credits. רוב הפעולות עולות Credit אחד. פעולות מתקדמות כמו AI Modules עשויות לעלות יותר.

תרחיש ריאלי עם מאה פניות לקוחות ביום: Webhook Trigger — מאה Credits. Data Store Check — מאה Credits. AI Agent Node — מאה Credits. Router — מאה Credits. Gmail — מאה Credits. Sheets Log — מאה Credits. סה"כ: שש מאות Credits ביום, שזה שמונה עשר אלף Credits בחודש.

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

לתמחור עם לקוחות: בניית Scenario — חד פעמי, בין אלפיים לעשרת אלפים שקל לפי מורכבות. תחזוקה חודשית ומנוי Make — בין מאתיים לאלף שקל לחודש תלוי בנפח. תמיד כללו את עלות ה-Credits בהצעת המחיר לפי מספר הפניות שהלקוח צופה.

[מעבר שקף]

מה למדנו היום?

Router — מסתעף לנתיבים שונים. Bundle אחד יכול ללכת לכמה נתיבים בו זמנית. תמיד הוסיפו Fallback Route.

Iterator ו-Aggregator — פיצול רשימות לבנדלים בודדים, ועיבוד מרוכז בחזרה. ארבעה סוגי Aggregator לצרכים שונים.

Error Handling — שישה מצבים. Break, Ignore, Retry, Resume, Rollback, ו-Error Route. לפרודקשן — תמיד Error Route.

Data Store — זיכרון בין הרצות. Deduplication, ניהול מצב, מונים, Cache.

AI Agent Node — מוח בתוך ה-Scenario. קורא תוכן, מחליט, קורא Tools. עם Reasoning Panel לשקיפות מלאה.

זה הבסיס המלא ל-Make.com. בשיעור הבא, שיעור אחת נקודה ארבע, עוברים ל-n8n — הכלי הקוד-פתוח. תראו את ההבדלים בין שתי הפלטפורמות, מתי להמליץ על כל אחת, ואיך לבנות Workflows מורכבים עם n8n.

תודה על תשומת הלב. נתראה בשיעור הבא.
