הערות שטח

תשלומים אג׳נטיים תחת מדיניות אנושית

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

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

מצב הכשל ברור, וזו בדיוק הנקודה

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

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

המדיניות היא המוצר, לא הפרומפט

מודל ההכלה הוא מדיניות שהפלטפורמה אוכפת לפני שהכסף זז, לא אחרי שהסוכן החליט. כל סוכן מקבל תקרה לעסקה ומגבלה יומית — €150.00 לתשלום, €500.00 ליום במדיניות הדמו שלנו — ומעליהן תקרה חודשית של €6,000.00. אלה חומות קשיחות שהפלטפורמה בודקת, לא הבטחות שהסוכן מקיים. כשבוט הנסיעות בדמו ניסה להזמין צ'רטר ב-€640.00, התשלום נדחה במקום: חריגה מהתקרה, לפני שסנט אחד זז. סוכן שמתנהג למופת בכל יום עדיין לא יכול לחרוג ממה שהחודש מאפשר.

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

השאלה אינה אם סוכן AI יוציא כסף. השאלה היא מי כתב את הכללים שלפיהם הוא מוציא — והתשובה צריכה להיות תמיד אדם, מראש, בכתב.
— Protocore · הנדסת Agents

אדם מעל הקו

יש החלטות גדולות מדי מכדי להשאיר אותן לקופסה. לכן המדיניות כוללת סף: סכום מוגדר שמעליו אדם חייב לאשר לפני שהתשלום עובר. בדמו הקו עומד על €100.00. כשסוכן התפעול סימן את חשבונית #088 של Nord Logistics — €120.00, בנוחות בתוך התקציב היומי שלו של €500.00 אך מעל קו האישור — הוא לא שילם. הוא עצר, הציג את ההצעה בפני אדם וחיכה. תשובה בשורה אחת אישרה אותה; התשלום הוסדר באסמכתה 9F21-0716 ונרשם ביומן הביקורת ב-09:41. מתחת לקו הסוכן פועל לבד; מעליו, אדם עונה קודם.

האישור אינו תיבת סימון שמתאדה. הוא מתעד מי אישר, באיזה מכשיר, באיזו שעה, עם חתימה מצורפת — אושר באפליקציה, מפתח טלפון, 09:41:12. כשמישהו שואל אחר כך למה תשלום בוצע, התשובה היא אדם בשם וחותמת זמן, לא כתיפיים.

מתג חירום ויומן שאי אפשר לערוך בשקט

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

השני הוא יומן ביקורת append-only. כל החלטה נרשמת: מה ניסה הסוכן, אילו בדיקות מדיניות עברו או נכשלו, מי אישר מה, ועד לרוטציית מפתחות. רשומה אחת משחזרת תשלום שלם — ההחלטה DEC-4471 מציגה את הבקשה, כל בדיקת מדיניות עם תוצאתה (allowlist עבר, תקרה עברה, סף הוביל להסלמה), את חתימת האדם, ואת הסכום שנסלק עם המסילה והאסמכתה. כל רשומה נושאת את ה-hash שלה, את ה-hash של הרשומה הקודמת ואת מיקומה בשרשרת — #4,471 בדמו — ולכן עריכת שדה כלשהו שוברת כל רשומה שאחריה. היומן מיוצא כ-JSON, כולל ה-hash: הוא שלכם למסור למבקר, לא שלנו לשמור.

סליקה משעממת, חדשנות באישור התשלום

קל להתפתות ולהפוך תשלומים אג'נטיים לחדשים לגמרי, מהיסוד — מסילה חדשה, אמצעי תשלום חדש, דרך חדשה להעביר כסף. כדאי להתאפק. החידוש האמיתי הוא באימות ההרשאה: איך סוכן מוכיח שמותר לו לשלם, לפי המדיניות של מי, ובאיזה אישור. ברגע שתשלום עבר את השער הזה, עליו להיסלק על מסילות שהן משעממות כבר שנים. בדמו, הצעה מאושרת על €120.00 הופכת להעברת אשראי רגילה של SEPA — שנסלקת ב-SEPA Instant דקות אחרי האישור — ואי אפשר להבדיל בינה לבין תשלום שביצע אדם. הבנק לא יודע, ולא אכפת לו, שסוכן הוא שהתחיל אותה.

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

נוף הפרוטוקולים עוד לא התייצב — כדאי לבנות לפי זה

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

בפועל זה אומר משטח אינטגרציה קטן ומשעמם. סוכנים מתחברים דרך MCP בכתובת mcp.protocore.io/agents; כל framework שמדבר את הפרוטוקול יכול להחזיק ארנק. הממשק צר במכוון — להציע תשלום, לקבל החלטה — כי הלוגיקה המעניינת חיה בפלטפורמה ולא ב-prompt. כשהתעשייה תכריע איך סוכנים מוכיחים את עצמם מול סוחרים, החזית תשתנה והקירות שמאחוריה יישארו בדיוק במקומם.

איפה זה ממוקם

תשלומים אג'נטיים אינם הימור על כך שתוכנה אוטונומית צריכה להוציא כסף ללא גבול. ההפך הוא הנכון: זה הימור על כך שתוכנה כן תוציא כסף, ולכן מוטב שהמגבלות יהיו אמיתיות, חיצוניות וקריאות. תקציבים ו-allowlists משרטטים את הקופסה, סף מנתב את ההחלטות הגדולות לאדם, kill-switch עוצר הכול, ויומן append-only מאפשר לשחזר כל תשלום בדיעבד. דף המוצר ב-/products/agents עובר על כל המעגל בנתוני הדמו ששימשו כאן — יוצרים סוכן, מגדירים לו מדיניות, צופים בתשלום שעולה לאישור ונסלק — ו-/products/pay הוא הליבה שעליה התשלומים האלה רצים. האוטונומיה אמיתית; וכך גם הרצועה, ואדם מחזיק בה.

יש מערכת לבנות?

ספרו לנו מהי הבעיה. נחזור עם ארכיטקטורה ותוכנית.