מסרתי ל-Claude Code את הקבלות שקיבלתי ב-SMS משופרסל, והוא בנה מהן את העגלה השבועית שלי אצל סופר אחר: 25 שורות, ₪422.12, פער של פחות מאחוז מול אותו סל לפי מחירי הקבלות שלי. כשהייתי ב-Wonderful עבדתי על כמה פרויקטים של Agentic E-Commerce וחשבתי שהם רעיון גרוע. לאחרונה שיניתי דעה — לא לגבי האייג'נט שבאתר, אלא לגבי מתי הוא שווה משהו.
למה זה נראה לי מטופש
תאגידי קמעונאות גלובליים החליטו בשלב מסוים שהפונקציה של הנציג המעצבן ששואל "אפשר לעזור?" — זה שאנחנו עונים לו על אוטומט "אני רק מסתכל" — ראויה לגרסה וירטואלית באתר.
זה נראה לי חוויית משתמש פחות טובה מפשוט לשוטט באתר, גם כשהאייג'נט מראה תמונות של מוצרים. גם הערכתי שזה יוריד את גודל העגלה הממוצעת: אדם שמדפדף נתקל בדברים שלא חיפש, אדם שמנהל שיחה מקבל בדיוק את מה שביקש.
מה שינה את דעתי
חוויה אייג'נטית מועילה בעיקר כשהיא לא מחליפה את הגלישה, אלא מבטלת אותה — כשהיא משלימה אוטומציה מלאה מצד הלקוח. זה קורה רק במה שאפשר לקרוא לו zero clicks adoption — אימוץ באפס קליקים.
הכלל פשוט: אם אני כיוזר צריך לעבוד בשביל האייג'נט — לא עשינו כלום. הוא צריך לעבוד בשבילי, ופשוט לדעת מה אני צריך.
זה בדרך כלל בלתי אפשרי, כי כדי לדעת מה אני צריך צריך דאטה שאין. אבל לפעמים הדאטה כן קיים. מצרכים לבית הם מקרה קיצון נוח: היסטוריית הרכישות שלי קיימת, והיא קונסיסטנטית להחריד. לא צריך עוד כלום.
וזה גם מסביר למה רוב הקטגוריות לא עומדות בתנאי. ספה או מחשב נייד נקנים פעם בכמה שנים, ההיסטוריה לא אומרת כלום על הפעם הבאה, ובלי היסטוריה האייג'נט חייב לשאול — כלומר להחזיר את העבודה ללקוח. לזהות את הקטגוריות שבהן אפס קליקים אפשרי הוא לדעתי המאמץ המשתלם ביותר כאן, והוא שאלה עסקית, לא טכנית.
מה קרה בפועל
מסרתי ל-Claude Code 73 קישורים לחשבוניות ירוקות שנשלחו אליי ב-SMS. 62 מהם כבר פגו — שופרסל מוחקת את הקישורים אחרי כחצי שנה — ונשארו 11 קבלות בטווח 31/05/2026 עד 22/06/2026. שלושה שבועות, כלומר בערך שלוש קניות קטנות בשבוע.
מזה הוא בנה טבלת מוצרים עם תדירות: בכמה מתוך 11 הקבלות הופיע כל פריט. ביצים ב-6 מ-11, גבינות קשות ב-6 מ-11, טופו ב-3. הוא גם הסיק פרופיל שאף אחד לא הזין לו — צמחוני, כשר, כבד בחלב וביצים. את הצמחונות הוא הסיק פשוט כי בשר, עוף ודגים לא הופיעו באף קבלה; את הכשרות — מהמותגים עצמם, קוטג' מהדרין וקורנפלקס בהשגחת בד"ץ.
אחר כך הוא לקח את הרשימה הזאת לסופרים אונליין כדי להשוות מחיר — השוואה שצריכה להתחשב גם בהנחות שיש לי דרך מועדוני צרכנות בחלק מהחנויות, אבל זה לפוסט אחר. זה שתיעדתי מקצה לקצה הוא ויקטורי, ושם התחילו החלקים המעניינים.
מה שהאתר באמת חושף
ויקטורי אונליין רץ על פלטפורמת white-label בשם ZuZ/Prutah. זה SPA ישן, כתוב ב-AngularJS. חיפוש המוצרים הוא endpoint ציבורי לגמרי, בלי התחברות, ומחזיר לכל מוצר מזהה, שם, מותג, האם הוא נמכר במשקל, כשרות ומחיר בסניף. הכשרות היא שדה, לא ניחוש מהשם.
העגלה, לעומת זאת, דורשת התחברות — טלפון וקוד חד-פעמי, או גוגל/פייסבוק — ואז token לכל קריאה. וכאן החוק שהכי קל להיכשל בו: פריטים במשקל נשלחים בגרמים ולא בקילו, והמחיר ליחידה הוא המחיר לקילו חלקי אלף. פריטים ארוזים נשלחים ביחידות. מי שמפספס את החצי השני של הכלל מחייב את עצמו על שורת בננות במחיר של אלף קילו.
איפה זה נשבר
הקטלוג אינו המלאי שניתן למשלוח. שמונה מתוך 25 השורות הוחלפו: שש כי ה-SKU המדויק לא נשלח לכתובת בתל אביב — פיתה כוסמין הפכה ללחמניות כוסמין, טופו של מותג אחד לטופו של אחר — אחת הוספה מחדש, ואחת הייתה תיקון של הקוקוס.
אחד מאותם שמונה הוא המקרה היחיד שבו הוא לא ניחש. בקבלה הופיע "נוזל אגוזי קוקוס", שיכול להיות משקה קוקוס או חלב קוקוס לבישול. הוא מיפה אותו למשקה וסימן אותו לאישור — וזה נכון: התחליף הראשון היה שגוי, והבחירה הסופית הייתה פחית קוקוס תאילנדי לבישול.
שני הדברים האלה יחד הם בעצם כל הסיפור של האייג'נט שבונה את ההזמנה: הוא לא מחפש מוצר, הוא מכריע בין התאמות. איזה מותג קרוב מספיק, מה עושים כשהפריט לא נשלח לכתובת, ומתי לעצור ולשאול במקום להחליט. זה בדיוק החלק שרשת קמעונאית לא צריכה לבנות במקומי.
התוצאה: 25 פריטים בעגלה, ₪422.12, אחרי ₪41 שירדו במבצעים. אותו סל בשופרסל, לפי מחירי הקבלות, יצא בערך ₪424 — פער של כשני שקלים, פחות מאחוז. עצרתי לפני התשלום; את ההתחברות עשיתי אני, לא הוא.
התוכנית העסקית שהייתה מונחת על שרטוט הארכיטקטורה
בניסיון לחשוב איך עוטפים את המכונה הזאת לפרודקשן, הסתכלתי על שרטוט הארכיטקטורה — וראיתי מתוכו גם את המודל העסקי. הוא היה כתוב שם כל הזמן, בשמות של הקופסאות:
| שלב | מה יש שם |
|---|---|
| קלט | הסופר הנוכחי שלי — אוטומטי, מהיסטוריית הקבלות |
| אייג'נט מחלץ | קורא כל קבלה, מחליט תדירות לכל מוצר |
| מסדי נתונים | מוצרים + תדירות, והיסטוריית הזמנות |
| אייג'נט בונה הזמנה (שבועי) | מחליט בין התאמות מוצר, מחליף פריטים חסרים |
| פלט | הסופר הזול ביותר, עם עגלה מוכנה |
בקלט: הסופר הנוכחי. בפלט: הסופר הזול. זו למעשה מכונה שמקנוורטת צרכן מהסופר הנוכחי שלו לסופר הזול ביותר.
וזה כבר שווה לסופר הזול את המאמץ. ההנחה שלי היא שרכישת לקוח חדש עולה לרשת הרבה יותר מהפער שהיא מוותרת עליו בעגלה אחת; כאן היא מקבלת לקוח שהמכונה עצמה מעבירה אליה, עם עגלה מלאה ביום הראשון. זה גם יכול לשכלל קצת את השוק, ולהחזיר את הכוח אלינו הצרכנים.
מה זה אומר לתאגידים
התאגידים יכולים להסתפק בלבנות MCP, או אפילו רק ממשק API נורמלי. אין צורך באייג'נט משלהם.
שימו לב איפה יושבת האינטליגנציה בתרשים למעלה: בשני האייג'נטים, ושניהם שלי. הרשת לא צריכה להחליט בשבילי בין שתי גבינות ולא לנחש איזה תחליף לשים — היא צריכה לחשוף קטלוג שאפשר לחפש בו ועגלה שאפשר לכתוב אליה. בוויקטורי החיפוש כבר עומד בזה בלי שאיש התכוון; מה שחסר זה שהחלק של העגלה יהיה מתועד ומורשה במקום להיות משהו שמפענחים מהדפדפן.
זה גם ההבדל בין להשקיע בצ'אט על האתר לבין להשקיע בממשק: הצ'אט מתחרה בגלישה של הלקוח, הממשק מתחבר לאייג'נט שלו. לדעתי השני זול יותר לבנות, והוא בוודאי לא מוגבל למי שנכנס לאתר.
מה לוקחים מזה
אני עדיין חושב שאייג'נט מכירות באתר הוא ברוב המקרים חוויה פחות טובה מגלישה. מה שהשתנה אצלי הוא שהבנתי שזאת לא השאלה הנכונה. השאלה היא כמה עבודה הלקוח צריך להשקיע לפני שמשהו קורה — ואם התשובה איננה "אפס", אין שם ערך.
וכדאי להגיד את מצב הפרויקט בכנות: מה שרץ עד היום רץ בעיקר בידיים, מול Claude Code, בכל פעם מחדש. האייג'נט המחלץ והאייג'נט שבונה הזמנה עדיין לא קיימים כרכיבים עצמאיים שרצים לבד כל שבוע. יש הבדל בין להוכיח שמכונה אפשרית לבין להפעיל אותה.
הדפוס הזה חוזר גם בארגונים: הרבה פעמים התוכנית העסקית מונחת על שרטוט הארכיטקטורה ואף אחד לא קרא אותה. ככה נראה התהליך שאני עושה עם ארגונים.