Maven Apps: הסוכנים שלכם צריכים מפעילים, לא לוחות מתגים

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

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

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

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

למה אינטגרציות בסיסיות לא מספיקות

שאלו עשרה ספקים מה המשמעות של “משתלב עם Salesforce” במוצר שלהם, ותקבלו עשר תשובות שונות, כי מערכת כמו Salesforce, Zendesk או Front היא אף פעם לא דבר אחד בלבד. היא יכולה להיות:

• מקום שאליו הסוכן צריך לפנות כדי למצוא מידע (מאגר ידע, היסטוריית תיקים)
• מקום שאליו הסוכן צריך לפנות כדי לבצע פעולה (פתיחת פנייה, עדכון רשומה, ביצוע החזר כספי)
• ממשק שבו הסוכן צריך להופיע (co-pilot לסיוע לנציגים בתוך הקונסולה שבה צוות התמיכה שלכם כבר עובד)

“אינטגרציית Salesforce” שמכירה רק מאמרים היא לא אותו מוצר כמו אינטגרציה שיכולה גם לפתוח תיק, והיא לא אותו מוצר כמו אינטגרציה שיכולה לשבת בתוך קונסולת הנציגים כ-co-pilot. לעיתים קרובות כל אלה נארזים תחת מונח שיווקי אחד, ואתם מגלים את הפערים רק במהלך ההטמעה.

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

Maven Apps: יותר מאינטגרציות

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

• אפליקציות ידע קוראות ומאנדקסות תוכן ממערכת חיצונית כדי שהסוכן יוכל לענות על בסיסו: קריאה בלבד, עם ניהול גרסאות ותיוג לפי קהל יעד.
• אפליקציות יכולת מאפשרות לסוכן לבצע בפועל פעולה באותה מערכת: קריאת API אמיתית, המשורשרת לתהליך עבודה רב-שלבי (איתור ההזמנה, בדיקת מדיניות ההחזרות, ביצוע ההחזר הכספי ואישורו מול הלקוח), הכול בתוך שיחה אחת. בעוד שכספומט מריץ עסקה מתוסרטת אחת מתוך תפריט קבוע, אפליקציית יכולת מתנהגת יותר כמו בנקאי אישי: היא מקבלת תוצאה רצויה, לא פריט מתפריט, ועושה מה שנדרש כדי להגיע אליה, כולל טיפול בחריגים.
• אפליקציות ערוץ מציבות את הסוכן היכן שהלקוחות או צוות התמיכה שלכם כבר נמצאים: ווידג'ט מוטמע, שיחת טלפון, תיבת דואר נכנס, או חלונית co-pilot בתוך הקונסולה שבה הנציגים שלכם עובדים כל יום.

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

אין גרסה נפרדת “ברמת Enterprise” של מסגרת הפיתוח שרק המהנדסים שלנו משתמשים בה; App Studio, פלטפורמת המפתחים שלנו לבניית אפליקציות, פועלת על אותה ארכיטקטורה בדיוק. מדובר ב-TypeScript אמיתי, ב-SDK אמיתי (@mavenagi/mavenagi) ובצינור פריסה אמיתי, לא בשפת סקריפטים קניינית שצריך ללמוד רק בשבילנו.

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

איך Apps תוכננו להיות עוצמתיות

אפליקציית Maven היא אפליקציית serverless שרצה בתוך סביבה מאובטחת ומבודדת ומתקשרת עם פלטפורמת Maven באמצעות SDK מוגדר. בפועל:

היא multi-tenant. אפליקציה אחת נבנית פעם אחת ומותקנת פעמים רבות, בארגונים ובסוכנים שונים. כל התקנה מקבלת הקשר משלה (מזהה ארגון, מזהה סוכן ותצורת זמן ריצה משלה), אבל חולקת את אותו קוד בסיס. כלומר, כשאנחנו משיקים שיפור לאפליקציית Salesforce, כל לקוח שמשתמש בה נהנה ממנו, ואף אחד לא תקוע עם גרסה מיושנת, בעבודת יד, של האינטגרציה “שלו”.

היא מבודדת, לא מולבשת מבחוץ. כל אפליקציה רצה כפונקציה עצמאית בסביבה מאובטחת, בנפרד מה-backend המרכזי של Maven ובנפרד מהאפליקציות של לקוחות אחרים. הלוגיקה המותאמת שלכם אף פעם לא רצה בתוך מונולית משותף לצד הלוגיקה של מישהו אחר. החיבורים למערכות הרשומה שלכם יכולים לעבור דרך VPN, VPC peering, OIDC או HTTPS רגיל עם רשימת כתובות IP מורשות, לפי הבחירה שלכם, לא שלנו.

היא מגיבה לאירועים אמיתיים, לא ללוחות זמנים של polling. במקום משימת סנכרון לילית, אפליקציה יכולה לממש event hooks שנקראים טריגרים: נוצרה שיחה, התקבל משוב, מאגר ידע רוענן, והפלטפורמה מודיעה לאפליקציה ברגע שהאירוע מתרחש. זו צורה שונה מכלי האוטומציה שאתם אולי כבר מכירים. טריגר ב-Maven הוא פסיבי: הפלטפורמה עצמה מאזינה לשינויי מצב ודוחפת אותם לכל אפליקציה שהם רלוונטיים לה, בלי צימוד בין האפליקציה שגרמה לאירוע לבין האפליקציה שמגיבה לו. בפועל, אפליקציה למענה בדוא״ל ואפליקציה נפרדת לחלוטין לסנכרון Salesforce יכולות שתיהן להגיב לאותו אירוע “שיחה עודכנה” באופן עצמאי, כל אחת עושה את שלה, בלי שאחת מהן יודעת על קיומה של השנייה.

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

יש לה מחזור חיים אמיתי. כל אפליקציה מממשת סט קטן של lifecycle hooks:

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

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

Apps מול אינטגרציות

אינטגרציה טיפוסית עונה על שאלה צרה אחת, בדרך כלל “האם נתונים יכולים לעבור מ-A ל-B”, ורואה בזה את קו הסיום. אפליקציית Maven נבנתה כדי לענות על שאלה קשה ושימושית יותר: האם סוכן AI יכול לדעת באופן אמין מה נכון במערכות שלכם ברגע זה, והאם אפשר לסמוך עליו שיפעל בשמכם כשצריך?

רוב פלטפורמות ה-Enterprise מציעות גרסה כלשהי של “תבנו בעצמכם אם אין לנו את זה מהקופסה”. מה שהן בדרך כלל לא מספרות לכם הוא שבנייה עצמית פירושה להריץ שרת משלכם, לטפל בהרחבה בעצמכם ולבצע סקירת אבטחה משלכם, על תשתית משלכם. כך פער פשוט בקטלוג המחברים הופך להחלטת גיוס: האם תקבלו תקציב להנדסה ולתשתיות, או שתישארו מוגבלים למה שכבר מוכן מראש? עם Maven Apps, הלקוחות שלנו לא נאלצים לבחור באפשרות הפחות גרועה. אפליקציה מותאמת שאתם או המפתח שלכם בונים רצה על התשתית שלנו, עם אותו ניטור, אותה יכולת הרחבה ואותה רמת אבטחה כמו כל אפליקציה מוכנה בספרייה שלנו. אתם כותבים את הקוד; אנחנו מריצים אותו.

זו גם הסיבה שהארכיטקטורה מתעקשת על דברים ש-webhook פשוט אף פעם לא צריך לדאוג להם:

• תגובות מובנות ומוגבלות בגודלן. כל פעולה שאפליקציה מבצעת מחזירה תגובה ברורה ונתונים מובנים שהסוכן יכול להסיק מהם, ולא גוש נתונים גולמי ובלתי מוגבל שהוא נאלץ לנחש את משמעותו.
• אימות הדדי וחתום. הפלטפורמה חותמת על כל בקשה לאפליקציה כדי שהאפליקציה תוכל לוודא שזו באמת Maven שפונה אליה, והאפליקציה מאמתת את עצמה מול הפלטפורמה עם פרטי הזדהות משלה. אף צד לא נאלץ לסמוך על הרשת בלבד.
• תצורה שמאומתת עוד לפני שהיא מגיעה לסביבת הייצור. מכיוון ש-preInstall רץ לפני שאפליקציה עולה לאוויר, פרטי הזדהות שגויים או הגדרה חסרה נתפסים בזמן ההתקנה, ולא בפעם הראשונה שלקוח מסתמך עליהם.
• תשתית אמיתית מתחת, לא רק קריאה לפונקציה. מכיוון שאפליקציות הן יישומים מלאים, הן יכולות להחזיק מצב אמיתי: מטמון, מונה קצב, מסד נתונים קטן, ולא רק בקשה ותגובה ללא מצב. זה מה שמאפשר, למשל, לעקוב אם שיעור הפתרון בתחום מסוים ירד ביותר מ-10% ב-24 השעות האחרונות ולהזעיק את הצוות שלכם כשזה קורה. קריאת API פשוטה לא יכולה להחזיק זיכרון כזה. יישום אמיתי יכול, בדיוק כמו שמושבת נמלים זוכרת היכן נמצא המזון למרות שאף נמלה בודדת לא זוכרת.
• הרחקת מידע רגיש מהמודל. יש שלבים שלא אמורים לעבור דרך AI בכלל. כשלקוח מוכן לקנות את מה שבעגלה שלו, הסוכן מפעיל את תהליך התשלום של האפליקציה, והאפליקציה אוספת את פרטי התשלום והפרטים האישיים ישירות מהלקוח דרך ממשק מאובטח משלה. הסוכן מתזמר את התהליך, אבל מספרי כרטיסי אשראי ומידע רגיש אחר אף פעם לא נכנסים לשיחה עם ה-AI.
• בסיס קוד אחד, כל הלקוחות, רדיוס פגיעה מבודד. Multi-tenancy פירושו שתיקונים ושיפורים מושקים פעם אחת ומגיעים לכולם, ובידוד פירושו שהלוגיקה המותאמת של לקוח אחד לעולם לא יכולה להשפיע על לקוח אחר.

מה זה אומר עבורכם

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

בנינו את Maven Apps כי אנחנו מאמינים שזה מה ש“אינטגרציה” הייתה אמורה להיות מלכתחילה.