לינדי / Lindy

מה זה לינדי ובמה הוא שונה מאוטומציה?

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

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

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

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

הפיצ'רים המרכזיים של לינדי

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

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

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

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

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

כמה זה עולה?

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

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

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

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

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

לינדי מול מנועי האוטומציה

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

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

מול מערכות אוטומציה בענן, ההבדל הוא בסף הכניסה מול העומק. מערכת האוטומציה Make דורשת ללמוד לבנות תרחיש, ובתמורה נותנת שליטה מלאה בכל שלב. כאן כותבים פסקה ומתחילים לעבוד בעשר דקות. מי שרוצה תוצאה מהירה בלי ללמוד מערכת יעדיף כאן, ומי שבונה תשתית שתרוץ שנתיים יעדיף שם.

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

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

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

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

הפיצ'ר שעושה את ההבדל: שער אישור לפני פעולה

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

# שער אישור בין החלטת הסוכן לבין ביצוע הפעולה
import os
import json
import time
import hmac
import hashlib
from pathlib import Path

QUEUE = Path("agent-queue.json")
SECRET = os.environ["AGENT_WEBHOOK_SECRET"].encode()

# פעולות מדורגות לפי מה שקורה אם הסוכן טעה
RISK = {
    "write_record":     "low",     # אפשר לתקן, אין נזק כלפי חוץ
    "internal_notice":  "low",
    "schedule_meeting": "medium",  # מביך אם שגוי, ניתן לבטל
    "send_client_mail": "high",    # יצא החוצה, אי אפשר להחזיר
    "quote_price":      "high",    # מייצר התחייבות מול הלקוח
}
AUTO_APPROVE = ("low",)

def verify(body, signature):
    # אימות שהבקשה הגיעה מהמערכת ולא ממישהו שניחש את הכתובת
    expected = hmac.new(SECRET, body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, signature)

def load():
    if QUEUE.exists():
        return json.loads(QUEUE.read_text(encoding="utf-8"))
    return {"pending": [], "done": []}

def save(state):
    QUEUE.write_text(json.dumps(state, ensure_ascii=False, indent=2), encoding="utf-8")

# נקודת הקצה שהסוכן קורא לה במקום לבצע את הפעולה בעצמו
def receive(body, signature):
    if not verify(body, signature):
        return {"ok": False, "reason": "bad signature"}
    action = json.loads(body)
    level = RISK.get(action["type"], "high")     # לא מוכר נחשב מסוכן
    state = load()
    record = {
        "id": action["id"], "type": action["type"], "risk": level,
        "payload": action["payload"], "received": int(time.time()),
    }
    if level in AUTO_APPROVE:
        record["status"] = "auto"
        state["done"].append(record)
        execute(record)
    else:
        record["status"] = "waiting"
        state["pending"].append(record)
        notify_human(record)
    save(state)
    return {"ok": True, "status": record["status"]}

def approve(action_id, approver):
    state = load()
    for record in list(state["pending"]):
        if record["id"] == action_id:
            record["status"] = "approved"
            record["approver"] = approver
            state["pending"].remove(record)
            state["done"].append(record)
            execute(record)
            save(state)
            return True
    return False

# פעולה שממתינה יותר מדי זמן אינה רלוונטית. עדיף לבטל מאשר לשלוח באיחור
def expire(max_age=7200):
    state = load()
    now = int(time.time())
    for record in list(state["pending"]):
        if now - record["received"] > max_age:
            record["status"] = "expired"
            state["pending"].remove(record)
            state["done"].append(record)
    save(state)

# שלושה כללים שנשארים באחריות האדם ולא באחריות הסוכן
# שלב 1: כל סוג פעולה חדש נכנס לטבלה במפורש. ברירת המחדל היא סיכון גבוה
# שלב 2: מי שמאשר אינו מי שהגדיר את הסוכן, אחרת אין כאן בקרה אלא טקס
# שלב 3: לעבור על היומן פעם בשבוע ולראות מה אושר. שם מתגלות ההוראות השגויות

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

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

חסרונות שאתם צריכים לדעת

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

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

היתרונות שעושים את לינדי שווה

ומולם, שש סיבות שבגללן עסקים קטנים מצליחים כאן במקום שבו אוטומציה קלאסית נתקעה.

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

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

מתי לבחור לינדי ומתי לבחור אוטומציה קלאסית?

שתי שאלות מכריעות כאן: כמה ודאות המשימה דורשת, וכמה מובנה הקלט שנכנס אליה.

# עץ החלטה בין סוכן לבין אוטומציה מוגדרת
שאלה 1: איך נראה הקלט?
    טופס או שדות קבועים  -->  אוטומציה, אין צורך בשיפוט
    מייל בשפה חופשית     -->  סוכן
    שיחה או הקלטה        -->  סוכן, זו נקודת החוזק

שאלה 2: מה קורה אם המערכת טועה?
    אפשר לתקן בשקט       -->  אפשר להריץ אוטומטית
    מביך מול הלקוח       -->  סוכן עם אישור ידני
    התחייבות או תשלום    -->  אישור חובה, בלי יוצא מן הכלל

שאלה 3: כמה פניות ביום?
    עד 30                -->  החבילה המקצועית
    30 עד 200            -->  לסנן לפני הסוכן, אחרת המכסה תיגמר
    מעל 200              -->  אוטומציה קודם, סוכן רק על החריגים

שאלה 4: מי מתחזק את זה?
    בעל העסק             -->  סוכן, ההגדרה בשפה רגילה
    איש אוטומציה         -->  מנוע אוטומציה, שליטה מלאה
    אין אף אחד           -->  להתחיל מתהליך אחד בלבד

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

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

השורה התחתונה: האם לינדי שווה?

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

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

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

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