Agent-to-Agent Marketplace — שוק שבו סוכנים רוכשים שירותים מסוכנים אחרים

מאת צוות מדיה דיל · 12.08.2026 · Agentic Commerce · 5 דק׳

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

סטארטאפ שמפתח סוכן AI לניהול נסיעות עסקיות מגלה שהוא צריך שירות תרגום מסמכים, שירות בדיקת מזג אוויר עתידי, ושירות חישוב מסלול Multi-city אופטימלי — שלושה יכולות שהוא לא רוצה לבנות בעצמו. במקום לפתח כל אחת מהן פנימית — תהליך שהיה לוקח חודשי פיתוח ותחזוקה מתמשכת — הוא "שוכר" אותן משלושה סוכנים אחרים, כל אחד מתמחה בתחומו הצר, משלם להם per-call לפי שימוש בפועל, ומרכיב את התוצאה הסופית ללקוח האנושי בזמן אמת. זהו Agent-to-Agent Marketplace: שוק שבו הצרכן והספק כאחד הם סוכני תוכנה, לא בני אדם וחברות. גוגל כבר הכריזה על A2A (Agent2Agent) כפרוטוקול תקשורת בין סוכנים, ואנתרופיק פרסמה את MCP (Model Context Protocol) לחיבור סוכנים לכלים — ושתי התשתיות האלה יחד יוצרות את התנאים לשוק שירותים בין-סוכני אמיתי, עם היצע, ביקוש, ותמחור דינמי.

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

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

גילוי: איך סוכן בכלל מוצא ספק

הבעיה המרכזית בשוק כזה היא Discovery — איך סוכן קונה יודע בכלל שסוכן ספק מסוים קיים ומתאים לצורך שלו. הפתרון המתפתח הוא רישום מרכזי (registry) של יכולות סוכנים, עם תיאור מובנה של מה כל סוכן יודע לעשות, המחיר שלו, וזמן התגובה הצפוי — דומה במהותו לאופן שבו מרקטפלייסים מסורתיים מארגנים ספקים לפי קטגוריה, כמתואר ב-מדריך אינטגרציית מרקטפלייסים. ההבדל המהותי הוא שכאן החיפוש וההשוואה נעשים לגמרי פרוגרמטית: הסוכן הקונה שולח שאילתת יכולת ("אני צריך תרגום מסמך משפטי מעברית לאנגלית, עד 2 דקות, עד 0.05 דולר"), והרישום מחזיר רשימת מועמדים מדורגים.

תמחור דינמי ומיקרו-עסקאות

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

{
  "capability": "document_translation",
  "provider_agent": "legal-translate.example.ai",
  "price_per_call": 0.04,
  "currency": "USD",
  "avg_latency_ms": 850,
  "reputation_score": 4.7
}

אמון בלי מוניטין אנושי

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

סיכונים: שרשראות תלות ונקודות כשל

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

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

סוכן שקונה שירותים מסוכנים אחרים צריך גם מנגנון פנימי שמונע ממנו "לברוח" מבחינה תקציבית — תרחיש שבו שרשרת קריאות מקוננת גורמת לעלות מצטברת עצומה בלי שאף אחד שם לב בזמן אמת. פתרון נפוץ הוא הגדרת תקרת הוצאה לכל משימה (budget cap) שמועברת יחד עם הבקשה עצמה לאורך כל שרשרת הקריאות, כך שכל סוכן בשרשרת יודע כמה תקציב עוד נותר ומפסיק לקרוא לשירותים נוספים כשהוא מתקרב לגבול. המנגנון הזה קרוב מאוד ברעיון שלו למגבלות שכבר קיימות במנדטים של AP2, המתוארים ב-מדריך AP2, ולא במקרה — שני הפתרונות פותרים את אותה בעיית יסוד: איך נותנים לסוכן חופש פעולה בלי לתת לו סמכות בלתי מוגבלת להוציא כסף.

סיכום: מתי כדאי לבנות סוכן שנמכר לסוכנים אחרים

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

תגיות: Agent Marketplace · A2A · MCP · Agentic Commerce · Micropayments · AI Agents

← חזרה לבלוג · צור קשר