אנשי כספים בעמותות שואלים ב־Teams או ב־Microsoft 365 Copilot: ”כמה הוצאנו ברבעון שעבר?”, ”למי יש כרטיסים?”, ”תכתוב עדכון לתורמים על Q1”. הסוכן שולף את נתוני הכרטיסים של הארגון עצמו, עושה את החשבון בקוד, וכותב טבלה או מייל של שלוש פסקאות לתורמים, רק על בסיס המספרים האלה.
מספרים שמסומנים ”הערכה” הם הערכות הנדסיות שצריך לאמת מול המשתמשים. כל השאר נספרו מהקוד ומקבצי הפריסה.
עמותות שמנהלות את הוצאות התוכניות שלהן בכרטיסים נטענים חייבות לתורמים דין וחשבון על לאן הלך הכסף. כדי להפיק אותו היה צריך לייצא עסקאות, לשייך כל אחת לקטגוריה, לסכם, ואז לכתוב טקסט שתורם שמבין במספרים יסמוך עליו.
ספקית הכרטיסים רצתה שזה יהיה זמין איפה שהצוות כבר עובד, ב־Teams וב־Copilot, בלי שהיא תחזיק הרשאה משותפת לחשבון של כל לקוח, ובלי שמודל שפה ”יעריך” אפילו מספר אחד.
התרשים רחב מהמסך: החליקו הצידה לצפייה בכולו →
המודל מקבל אגרגציות ורשימת עסקאות שטוחה, אף פעם לא payload גולמי לסכם בעצמו, ומונחה לא להמציא או להעריך מספר. טווח תאריכים ריק מקבל תשובה מהקוד בלי לקרוא למודל בכלל.
סכומים, סיכומים לפי קטגוריה, רכישות מובילות וספירת ”ללא תג” מחושבים ב־TypeScript ונמסרים למודל כנתונים. מייל לתורמים יכול לטעות בטון, אבל לא במספרים. המחיר: סוגי ניתוח חדשים דורשים קוד, לא רק שינוי פרומפט.
אין הרשאת שירות משותפת לחשבונות הלקוחות. הטוקן מוזן בשדה מוסתר ומאומת לפני השימוש, כך שטוקן שגוי נכשל בחיבור ולא באמצע שאלה. המחיר: בפיילוט הטוקן נשמר בזיכרון השרת, והעברה לאחסון מאובטח היא המשימה הראשונה לפרודקשן.
ה־REST API היה מוכן. שרת ה־MCP של הספקית היה הכיוון האסטרטגי. שני המסלולים יושבים מאחורי אותן פונקציות, והגדרה אחת בוחרת ביניהם. המחיר: שני מבני תשובה לנרמל.
”רשימה” מקבלת טבלת markdown ממוינת לפי תאריך. ”סיכום” או ”עדכון לתורמים” מקבלים בדיוק שלוש פסקאות בלי בולטים, מוכנות להדבקה במייל. שאלות עובדתיות מקבלות תשובה פשוטה אחת.
רוב הבעיות הופיעו רק בתוך Teams ו־Copilot, לא בבדיקות מקומיות. מבחר:
Copilot ו־Teams שולחים פעילויות invoke לצד הודעות. בלי handler, ה־adapter החזיר 501 Not Implemented, ו־Copilot התייחס לסוכן כפגום.
תשובת invokeResponse מפורשת עם 200 לפעילויות invoke, אישור שקט לאירועים, ו־error handler שאף פעם לא זורק בפניות שאינן הודעה.
שרת ה־MCP רץ מאחורי load balancer. כל קריאה אחרי initialize נחתה על instance אחר ואיבדה את ה־session.
שומרים כל Set-Cookie (כולל עוגיית ה־affinity) ושולחים אותם בחזרה בכל קריאה. מפענחים גם frames של SSE (”data:”) וגם תשובות JSON רגילות.
שם הכלי של העסקאות עוד לא היה סגור בצד השרת, ושם שגוי חזר כשגיאת כלי ולא כחריגה.
fallback מסודר על ארבעה שמות אפשריים, שעוצר בהצלחה הראשונה ומחזיר רשימה ריקה אם אין, כך שסיכום אף פעם לא קורס.
לחלק מהעסקאות לא היה תג, והסכומים לפי קטגוריה לא התיישבו בשקט עם הסכום הכולל.
הוצאה בלי תג נופלת לקטגוריה של הפלטפורמה ואז לשם בית העסק, והספירה עוברת למודל כאזהרה שהוא חייב לציין.
אם משאירים את זה למודל, תקופה לא מוגדרת הופכת לניחוש שמוצג כעובדה.
מנתח דטרמיניסטי לתקופות נפוצות. אם ההודעה לא מציינת תקופה, הסוכן שואל שאלת הבהרה במקום לקרוא ל־API.
שאלות המשך לא היו מובנות בלי הפנייה הקודמת.
המסווג כותב מחדש כל הודעה כך שתעמוד בפני עצמה, על בסיס 10 הפניות האחרונות, לפני הניתוב.
הדגמה להמחשה עם סכומים ובתי עסק סינתטיים. אין בה נתוני לקוח או קוד. כל תרחיש מציג מה הסוכן עושה לפני שהוא עונה.
| מדד | לפני | אחרי | מקור |
|---|---|---|---|
| עדכון הוצאות לתורמים | ייצוא, תיוג, סיכום וכתיבה, ≈60 דק׳ | שאלה אחת, פחות מדקה | הערכה |
| סבבי בקשות לסיכום | 3 ברצף | 1 במקביל | נגזר |
| טיפול ב־invoke של Copilot | 501, הסוכן סומן כתקול | 200, מאושר | קוד |
| מספרים שהמודל מחשב | אפשרי | 0, הכל בקוד | קוד |
| זיהוי הרשאה שגויה | באמצע שאלה | בחיבור, עם הודעה מה לעשות | קוד |
| סבבי פריסה עד חבילה עובדת | — | 7 ב־3 ימים | קבצי פריסה |
מקור: קוד = בריפו; קבצי פריסה = חותמות הזמן של חבילות הפריסה; נגזר = נובע מהקוד; הערכה = לאימות מול משתמשים.
שיחת אבחון חינם · 30 דקות · ללא התחייבות
כתבו בכמה שורות: איזה תהליך או מערכת, מה כואב היום (זמן, טעויות, עלויות או פיילוט AI שנתקע) ומי עובד עם זה. אחרי שיחה קצרה מקבלים תוך כ־3 ימים תוכנית כתובה והצעת מחיר סגורה.
נפתח מייל מוכן מראש · מענה תוך יום עסקים
ה־AI קורא. הקוד סופר.
כל הפרויקטים