אתמול אחר הצהריים, מהנדס בצוות שלנו צפה ב-Anthropic מציגים את מערך GTM הפנימי שלהם על במת SaaStr, צילם את השקופית, ושאל את Zero שאלה אחת: איזה מהכלים האלו חסרים לנו? שש שעות ותשע עשרה דקות לאחר מכן, Snowflake היה פעיל בפרודקשן לכל לקוח Zero. זו הייתה האינטגרציה ה-180 ששחררנו בשנה אחת, ויותר ויותר, האדם שכותב את הבאה כבר אינו מהנדס כלל. הנה המסגרת, והמיומנות הפנימית שמעליה, שמאפשרות זאת.
מה שאף אחד לא מספר על פלטפורמות סוכנים
מודל שפה גדול הוא מוח בצנצנת. לבדו, הוא יכול לכתוב לך שיר על מחסן הנתונים שלך, אבל הוא לא באמת יכול לפתוח אותו. מה שהופך צ'אטבוט לסוכן, מה שהצוות שלך באמת משלם עליו, הוא האם הסוכן מסוגל להיכנס לכלים שבהם אתה כבר משתמש ולבצע בהם עבודה.
אנחנו קוראים ליכולת הזו שכבת המחברים. אחרי שנה של בניית Zero, אנחנו מאמינים שזו החוליה החשובה ביותר בתשתית של מוצר סוכנים. אז בנינו אחת משלנו. חשוב מכך, בנינו סביב זה תהליך עבודה שמאפשר לכל אחד בצוות לכתוב מחבר.
למה לא MCP. למה לא Zapier.
שתי השאלות עלו אלינו מוקדם. שתיהן טובות למה שהן. אף אחת מהן לא התאימה לנו.
MCP הוא פרוטוקול, לא מוצר. מבריק עבור יוצרי כלים שרוצים שהשירות שלהם יהיה נגיש על ידי כל מודל שפה. אבל שרתי MCP, כפי שהם נפרסים כיום, מוסרים למודל רשימת כלים וסומכים עליו שיקרא להם בבטחה. אין כספת הרשאות לכל ארגון, אין חומת אש שמגבילה אילו נקודות קצה ניתן לגשת אליהן, אין יומן ביקורת שמקשר קריאה חזרה לאדם שאישר אותה. עבור מוצר שבו סוכן אחד עשוי לגעת ב-Stripe של לקוח ואחר עשוי לנסח מייל ב-Gmail של המנכ"ל, "לסמוך על המודל" זה לא מודל אבטחה.
פלטפורמות אינטגרציה בסגנון Zapier פותרות בעיה אחרת: הן מחברות טריגרים דטרמיניסטיים לפעולות דטרמיניסטיות. סוכנים לא עובדים כך. סוכן מחליט, תוך כדי מחשבה, שהשלב הבא הוא לשאול את Snowflake ואז לפתוח טיקט ב-Linear. הוא צריך הרשאה, לקוח HTTP מוגדר, ויומן ביקורת – עכשיו, לא כמתכון מוכן מראש.
אז בנינו את הדבר המשעמם: רישום של אינטגרציות, כאשר כל ערך כולל מטא-דאטה של הרשאות, מיפוי סביבות שמזריק סודות לסביבת הסנדבוקס, חומת אש של מארחים מותרים, ומטפל קטן ל-OAuth או מאפייני טוקן. זו התשתית.
אבל התשתית היא לא החלק המעניין בסיפור. החלק המעניין הוא מה שקרה מעליה.
המיומנות שהפכה כל אחד למחבר אינטגרציה
כלי SaaS חדש נכנס לרשימת האינטגרציות שלנו בערך פעמיים ביום. חלקם מגיעים מבקשות לקוחות. חלקם מחבר צוות ששם לב ש-Zero לא מסוגל לעשות משהו שהוא צריך. חלקם משיחה עסקית שבה מערך הכלים של לקוח פוטנציאלי כולל כלי שעדיין לא פגשנו.
אם כל אחד מאלה היה צריך לעבור דרך תור של מהנדס, היינו משחררים אחד בשבוע. אנחנו משחררים אחד ביום.
הסיבה היא כלי פנימי שאנחנו קוראים לו מיומנות כתיבת מחברים. זו מיומנות Zero, באותו פורמט שאנחנו מספקים ללקוחות, אבל מכוונת פנימה לקוד שלנו. כשכל אחד בצוות אומר "אני רוצה להוסיף את מחבר Notion", Zero מדריך אותו בתהליך:
- מתחילים מתרחיש המשתמש. מה המשתמש באמת רוצה לעשות עם הכלי הזה? "לשאול מסד נתונים", "ליצור עמוד", "לחפש ברחבי סביבת העבודה". המיומנות מתעקשת על סיפור משתמש קונקרטי לפני שנוגעים בקובץ כלשהו. מטרת המחבר היא לאפשר יכולת לסוכן, לא לעטוף API שלם.
- מזהים את סוג ההרשאה. OAuth, טוקן API, או שניהם. המיומנות יודעת מה כל סוג דורש: ב-OAuth, ממשק הסכמה וניתוב מחדש; בטוקן API, הזרקת סוד לכל ארגון והיכן המשתמש משיג את הטוקן. הכותב בוחר את הסוג המתאים לכלי; כל השאר נגזר מכך.
- ממפים נקודות קצה לתרחיש. לא "לעטוף את כל ה-REST API". רק את מספר נקודות הקצה שמספקות את סיפור המשתמש. מחבר עם שלוש נקודות קצה נבחרות היטב עדיף על כזה עם ארבעים שהסוכן אף פעם לא משתמש בהן.
- מייצרים את שלד שנים-עשר הקבצים. ערך ברישום, מטפל, תבנית חומת אש, אייקון פלטפורמה, קוד הזרקת סביבה, המיומנות שמלמדת את Zero להשתמש במחבר. המיומנות כותבת את השלד; הכותב כותב את הכוונה.
- פותחים את שני ה-PRs. אחד למסגרת המחברים, אחד לספריית המיומנויות. שניהם נבדקים על ידי מהנדס, אך הבדיקה עוסקת בנכונות, לא בלימוד הכותב איך המסגרת עובדת.
מה שפעם דרש ידע מוסדי (איזה סוג הרשאה, אילו נקודות קצה, אילו שנים-עשר קבצים ב-אילו שני ריפוזיטוריים, איך תבנית חומת האש משתלבת עם תת-דומיין דינמי) נמצא כעת במיומנות עצמה. הכותב מביא את ההבנה למשתמש. המיומנות מביאה את התבנית.
כך מעצב, מוביל BD או מנהל מוצר מוציאים מחבר לאור. הם יודעים מה המשתמש רוצה. המיומנות יודעת את כל השאר.
מקרה בוחן: Snowflake, אתמול
אתמול Anthropic הציגו את מערך GTM הפנימי שלהם על במת SaaStr: Salesforce כמערכת עיקרית, Clay להעשרה, LeanData לניתוב, Gong לשיחות, Jira לטיקטים, Intercom (Fin) לתמיכה, Ironclad לחוזים, Snowflake כמחסן נתונים. [קישור להרצאה]
אחד המהנדסים שלנו צילם את השקופית והכניס אותה ל-Zero עם שאלה אחת: "לאיזה מהכלים האלו חסר לנו מחבר?"
הנה ציר הזמן האמיתי שהתרחש. כל הזמנים לפי PDT.
16:59. צילום המסך מתקבל. Zero משווה אותו מול קטלוג המחברים: 7 מתוך 10 כבר קיימים (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). שלושה חסרים (Clay, LeanData, Snowflake), ו-Snowflake מסומן כחשוב ביותר, כי מחסן נתונים הוא הבסיס של מערך ה-GTM. התשובה מתקבלת ב-17:00.
17:01. המשך: "איזה מהכלים האלו אפשר לבנות כמחבר api-token?" Zero שולף את מסמכי ההרשאות: ל-Clay יש מפתח API אישי, Snowflake השיק לאחרונה Programmatic Access Tokens, LeanData הוא OAuth בלבד ותלוי ב-Salesforce. ההחלטה ב-17:02: קודם Snowflake (הכי חשוב, הרשאה נקייה), אחר כך Clay.
17:04. המהנדס אומר "להתחיל". מיומנות כתיבת המחברים לוקחת את זה. עד 17:07 היא מסמנת את Clay כלא רלוונטי (השטח הציבורי היחיד הוא webhook לכל טבלה, אין מחבר אמיתי לבנות) ומאשרת את מבנה Snowflake: סוד SNOWFLAKE_PAT + משתנה SNOWFLAKE_ACCOUNT, הרשאת bearer מול ה-REST API וה-SQL API v2 של Snowflake, תבנית חומת אש עם תת-דומיין דינמי בדומה ל-Zendesk.
17:35. שני ה-PRs נפתחים באותה דקה:
vm0-skills#176: המיומנות לסוכן. איך לכתוב SQL ל-Snowflake, לעצב תוצאות, לנסות שוב בשגיאות חולפות.vm0#13356: המחבר עצמו. ערך ברישום, מטפל PAT, יוצר חומת אש, אייקון פלטפורמה, קוד הזרקת סביבה.
18:22. PR של המיומנות מתמזג.
18:42. PR של המחבר מתמזג.
18:52. PR של ההפצה נפתח אוטומטית.
23:18. [email protected] ושאר רכבת ההפצה עולים לפרודקשן. Snowflake פעיל לכל ארגון.
שש שעות ותשע עשרה דקות מ"צילום מסך של מערך Anthropic" ל"Zero יכול לשאול את המחסן שלך". מהנדס אחד. שיחה אחת. אפס העברות ל"צוות מחברים".
הקצב כאן לא בגלל שהמהנדס מהיר. זה בגלל ש-מיומנות כתיבת המחברים נשאה את החלקים שפעם דרשו ידע מוסדי: איזה סוג הרשאה לבחור, אילו נקודות קצה מתאימות לתרחיש המשתמש, אילו שנים-עשר קבצים צריכים לנחות באילו שני ריפוזיטוריים, איך תבנית חומת האש משתלבת עם תת-דומיין דינמי. הכותב כתב את הכוונה. המיומנות כתבה את התבנית. הפרודקשן עשה את השאר.
זה מה שהמסגרת נותנת לנו. לא רק מהירות (למרות שהמהירות אמיתית), אלא מי יכול לקחת את העבודה. מחבר Snowflake נכתב במקרה על ידי מהנדס. הוא לא היה חייב להיות כזה.
למה api-token הוא אזרח שווה ערך
הערת שוליים שכדאי להדגיש, כי זו בחירה עיצובית מכוונת שהפתיעה אנשים.
רוב פלטפורמות הסוכנים מתייחסות ל-OAuth כהרשאה העיקרית ול-api-token כגיבוי לכלים ישנים. אצלנו ההפך. טוקני API הם אזרחים שווי ערך במודל המחברים שלנו, עם אותו ממשק הסכמה, אותה כספת לכל ארגון, אותו יומן ביקורת, אותה אכיפת חומת אש.
יש לכך שתי סיבות.
הראשונה היא ש-הרשאת api-token מאפשרת זמן קצר יותר לשימוש ראשון. Snowflake השיקו לאחרונה Programmatic Access Tokens בדיוק מהסיבה הזו: הרשאות ארוכות טווח, ניתנות להגדרה ולביטול, שלא דורשות תהליך OAuth. משתמש עם PAT יכול להיות פרודוקטיבי ב-Zero בפחות מדקה. תהליך OAuth, אפילו נקי, לוקח יותר זמן ודורש יותר מהמשתמש.
השנייה היא ש-OAuth לא תמיד זמין. יש כלים ארגוניים שפשוט לא מספקים אותו, או שהוא קיים רק בגרסת Enterprise. התייחסות ל-api-token כעמית (ולא כגיבוי) מאפשרת לנו לתמוך בכלים האלו כראוי במקום להשאיר אותם ב"בקרוב".
מחבר Snowflake ששוחרר אתמול הוא api-token. מחבר Gmail שמביא שרשורי מיילים של לקוחות הוא OAuth. שניהם עוברים באותה מסגרת, אותה מיומנות, אותה בדיקה. הכותב בוחר את הסוג המתאים לכלי, והמסגרת הופכת כל אחד מהם לזול לבנייה.
מה האינטגרציה ה-180 פותחת בפועל
המספר עצמו לא העיקר. העיקר הוא ש-בצפיפות הזו, הסוכן מפסיק להיות כלי שאתה מזמן והופך לסביבה שאתה חי בה.
כש-Zero מחובר ל-CRM שלך וגם למחסן הנתונים וגם לאינבוקס התמיכה וגם לכלי העיצוב וגם לריפו שלך, הוא מסוגל לעשות דברים ששום סוכן בודד לא יכול. הוא יכול לשלוף שאילתת Snowflake, להשוות אותה לטיקטים פתוחים ב-Linear, ולפרסם סיכום בערוץ Slack שבו צוות הצלחת הלקוחות נמצא. הוא יכול לקרוא שיחת Gong, למצוא את הפיצ'ר שהלקוח ביקש, לבדוק אם הוא ברודמפ, ולנסח את המייל המשך – הכל במהלך אחד.
כל מחבר חדש לא מוסיף ערך ליניארית. הוא מוסיף ערך קומבינטורית. המחבר ה-180 שווה יותר מהראשון, כי הוא משתלב עם ה-179 שבאו לפניו.
זו ההימור מאחורי המסגרת. וההימור מאחורי המיומנות הוא ש-הקצב שבו הערך מצטבר תלוי בכמה אנשים בצוות שלך יכולים להוסיף למחסן.
מה הלאה
אנחנו עובדים על פתיחת מיומנות כתיבת המחברים ללקוחות. אם אתה מריץ את Zero בצוות שלך ויש כלי פנימי שאתה צריך לו אינטגרציה (מערכת חיוב, מחסן נתונים, פאנל ניהול פנימי), אותו תהליך עבודה ששחרר את Snowflake אתמול יהיה התהליך שבו תשחרר את שלך. אותה תבנית, אותו מודל הרשאות, אותה חומת אש, אותו יומן ביקורת. כותב אחר.
אם זה מעניין אותך, נשמח לדבר.
