תזמור רב-מערכתי עם שיקולי שיפוט

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

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

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

כיצד Triggerfish פותרת את זה

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

שלבים דטרמיניסטיים לעבודה דטרמיניסטית

כאשר לשלב בתהליך עבודה יש קלט ידוע ופלט ידוע, הוא רץ כקריאת HTTP סטנדרטית, פקודת shell, או קריאת כלי MCP. ללא מעורבות LLM, ללא עונש זמן אחזור, ללא עלות הסקה. מנוע תהליכי העבודה תומך ב-call: http עבור REST APIs, ב-call: triggerfish:mcp עבור כל שרת MCP מחובר, וב-run: shell עבור כלי שורת פקודה. שלבים אלה מבוצעים בדיוק כמו אוטומציה מסורתית, כי לעבודה צפויה, אוטומציה מסורתית היא הגישה הנכונה.

תת-סוכני LLM לשיקולי שיפוט

כאשר שלב בתהליך עבודה דורש הסקה הקשרית, המנוע יוצר מפגש תת-סוכן LLM אמיתי באמצעות call: triggerfish:llm. זה אינו חילופי prompt/תגובה בודדים. לתת-הסוכן יש גישה לכל כלי רשום ב-Triggerfish, כולל חיפוש אינטרנט, זיכרון, אוטומציה של דפדפן, וכל האינטגרציות המחוברות. הוא יכול לקרוא מסמכים, לשאול מסדי נתונים, להשוות רשומות, ולקבל החלטה בהתבסס על כל מה שהוא מוצא.

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

הסתעפות מותנית מבוססת הקשר אמיתי

ה-DSL של תהליך העבודה תומך בבלוקים switch לניתוב מותנה, לולאות for לעיבוד אצווה, ופעולות set לעדכון מצב תהליך העבודה. בשילוב עם שלבי תת-סוכן LLM שיכולים להעריך תנאים מורכבים, משמעות הדבר היא שתהליך העבודה יכול להתפצל בהתבסס על הקשר עסקי אמיתי ולא רק על ערכי שדות.

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

ריפוי עצמי כאשר מערכות משתנות

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

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

אבטחה לכל אורך השרשרת

כל שלב בתהליך עבודה של Triggerfish עובר דרך אותם hooks אכיפת מדיניות כמו כל קריאת כלי ישירה. PRE_TOOL_CALL מאמת הרשאות ובודק מגבלות קצב לפני ביצוע. POST_TOOL_RESPONSE מסווג את הנתונים שהוחזרו ומעדכן את ה-taint של המפגש. PRE_OUTPUT מבטיח שדבר לא יצא מהמערכת ברמת סיווג גבוהה יותר ממה שהיעד מתיר.

משמעות הדבר היא שתהליך עבודה שקורא מ-CRM שלכם (CONFIDENTIAL), מעבד את הנתונים דרך LLM, ושולח סיכום ל-Slack לא מדליף בטעות פרטים סודיים לערוץ ציבורי. כלל מניעת הכתיבה-כלפי-מטה לוכד זאת ב-hook של PRE_OUTPUT, ללא קשר לכמה שלבים ביניים עברו הנתונים. הסיווג נוסע עם הנתונים לכל אורך תהליך העבודה.

הגדרת תהליך העבודה עצמה יכולה לקבוע classification_ceiling שמונע מתהליך העבודה לגעת בנתונים מעל רמה מוגדרת. תהליך עבודה של סיכום שבועי מסווג ב-INTERNAL לא יכול לגשת לנתוני CONFIDENTIAL אפילו אם יש לו את אישורי הגישה לכך. התקרה מאכופת בקוד, לא בתקווה שה-LLM יכבד הוראת prompt.

טריגרים של Cron ו-Webhook

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

אירועי Webhook נושאים רמת סיווג משלהם. webhook של GitHub עבור מאגר פרטי מסווג אוטומטית ב-CONFIDENTIAL בהתבסס על מיפויי סיווג הדומיין בתצורת האבטחה. תהליך העבודה יורש את הסיווג הזה וכל האכיפה המורדת חלה.

איך זה נראה בפועל

חברה בינונית המפעילה רכש לתשלום על פני NetSuite, Coupa, DocuSign ו-Slack מגדירה תהליך עבודה של Triggerfish שמטפל במחזור המלא. שלבים דטרמיניסטיים מטפלים בקריאות API ליצירת הזמנות רכש, ניתוב אישורים, והתאמת חשבוניות. שלבי תת-סוכן LLM מטפלים בחריגים: חשבוניות עם פריטי שורה שאינם תואמים את הזמנת הרכש, ספקים שהגישו תיעוד בפורמט בלתי צפוי, בקשות אישור הדורשות הקשר לגבי היסטוריית המבקש.

תהליך העבודה רץ על מופע Triggerfish מתארח עצמית. אין נתונים שיוצאים מהתשתית של החברה. מערכת הסיווג מבטיחה שנתונים פיננסיים מ-NetSuite נשארים ב-CONFIDENTIAL ולא יכולים להישלח לערוץ Slack המסווג ב-INTERNAL. מסלול הביקורת לוכד כל החלטה שתת-סוכן ה-LLM קיבל, כל כלי שהוא קרא לו, וכל נתון שהוא ניגש אליו, מאוחסן עם מעקב מלא אחר השושלת לסקירת ציות.

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