ज़िशान अली खान द्वारा अंग्रेजी में लिखा गया; यह एक मशीन अनुवाद है। AI किसी भी भाषा से तेज़ चलता है, इसलिए कुछ तकनीकी शब्द जानबूझकर अंग्रेजी में रहते हैं, और बिंदीदार अंडरलाइन वाले शब्द होवर या टैप करने पर मूल दिखाते हैं। मूल पढ़ें →

फील्ड गाइड A2A

A2A: एजेंट-से-एजेंट, बिल्डरों के लिए एक फील्ड गाइड

विभिन्न वेंडरों, टीमों और ट्रस्ट ज़ोन के एजेंट वास्तव में एक-दूसरे से कैसे बात करते हैं, और इसे ऑडिट करने योग्य कैसे रखें

4 मार्च 2026 · 22 min · अपडेट किया गया 11 जुलाई 2026 · रॉ .md

2026 की शुरुआत तक मैंने गिनना बंद कर दिया था कि कितने एंटरप्राइज़ आर्किटेक्चर रिव्यू एक ही डायग्राम से शुरू होते थे। CRM वेंडर के एजेंट के लिए एक बॉक्स। दस्तावेज़-प्रोसेसिंग वेंडर के एजेंट के लिए एक बॉक्स। आंतरिक डेटा-साइंस टीम के एजेंट के लिए एक बॉक्स, जिसे उन्होंने LangGraph पर बनाया था और जिस पर उन्हें बहुत गर्व था। और फिर बॉक्स के बीच तीरों का एक सेट, जो, जब आप पूछते हैं कि वे किस प्रोटोकॉल का प्रतिनिधित्व करते हैं, तो पता चलता है कि इसका मतलब है “एक REST एंडपॉइंट जिसे कोई बाद में लिखेगा।”

हर वेंडर अब एक एजेंट शिप करता है। वह हिस्सा हो चुका है, और यह उलटने वाला नहीं है। मैं फील्ड में, ज्यादातर बैंकों और बीमाकर्ताओं में, दूसरी-क्रम की समस्या देखता हूँ: इनमें से कोई भी एजेंट एक-दूसरे से बात नहीं कर सकता। बॉक्स के हर जोड़े को अनुकूलित ग्लू की आवश्यकता होती है, और ग्लू का हर टुकड़ा उस टीम के स्वामित्व में होता है जिसने बातचीत हारी। हैंडऑफ़ तदर्थ प्रॉम्प्ट और JSON पेलोड एक साथ जोड़े गए होते हैं, जिनका कोई वर्ज़न नहीं होता और न ही ऑडिट किया जाता है। जब कोई परीक्षक पूछता है “किस एजेंट ने यह तय किया, किस इनपुट के आधार पर,” तो कोई भी लॉग से उत्तर नहीं दे सकता। यह AI की समस्या नहीं है। यह एक एकीकरण समस्या है जो AI का वेश धारण किए हुए है, और हमने पहले भी एकीकरण समस्याओं को हल किया है। हम उन्हें प्रोटोकॉल से हल करते हैं।

A2A (Agent2Agent) वह प्रोटोकॉल है जो इस लेयर के लिए उभरा है। मैंने जॉयस जॉनसन के साथ Camunda ब्लॉग के लिए इस पर दो-भाग की श्रृंखला सह-लिखी है, जिसमें निर्णय ढाँचा और एक पूर्ण गिरवी ऋण निर्माण शामिल है, और मैंने अब इन विचारों पर दो बार मल्टी-एजेंट गिरवी ऋण सिस्टम बनाए हैं: एक बार एक ऑर्केस्ट्रेटेड Camunda डेमो के रूप में, और एक बार वास्तविक Agent Cards और JSON-RPC कॉन्ट्रैक्ट्स के साथ एक स्टैंडअलोन Gemini 3 हैकाथॉन प्रोजेक्ट के रूप में। यह गाइड इसका सार है: A2A वास्तव में क्या निर्दिष्ट करता है, यह MCP, AG-UI, और AP2 के सापेक्ष कहाँ बैठता है, मैं जिन दो ऑर्केस्ट्रेशन पैटर्न का उपयोग करता हूँ, डेटा-गोपनीयता सीम जिसे यह संभव बनाता है, और खतरा मॉडल जिसे कोई भी लॉन्च स्लाइड पर नहीं रखता।

मल्टी-एजेंट AI समस्या होने से पहले एक एकीकरण समस्या है

यहाँ वह दावा है जिसका मैं उन लोगों से भरे कमरों में बचाव करता रहता हूँ जो मॉडल के बारे में बात करना चाहते हैं: एक एंटरप्राइज़ में मल्टी-एजेंट सिस्टम का मुश्किल हिस्सा एजेंट इंटेलिजेंस नहीं है। यह है कि विभिन्न टीमें एजेंटों, बड़े भाषा मॉडल, और डेटा स्रोतों का स्वामित्व रखती हैं, और उन टीमों के अलग-अलग रिलीज़ चक्र, अलग-अलग सुरक्षा स्थितियाँ, और “पूरा” होने की अलग-अलग परिभाषाएँ होती हैं।

एक मानक के बिना, आपको N एजेंट और N×(N-1) तक पॉइंट-टू-पॉइंट एकीकरण मिलते हैं, प्रत्येक अपने स्वयं के पेलोड आकार, रीट्राय सिमेंटिक्स, और विफलता व्यवहार के साथ। मैंने SOA युग में और फिर माइक्रोसर्विसेज युग में यह फिल्म देखी है। कथानक कभी नहीं बदलता। जो एकीकरण “अस्थायी” थे वे भार-वहन करने वाले बन जाते हैं। जिस टीम ने ग्लू लिखा था, उसे पुनर्गठित किया जाता है। दो साल बाद एक घटना समीक्षा में पता चलता है कि क्रेडिट-निर्णय लेने वाला एजेंट उन प्रॉम्प्ट को प्राप्त कर रहा था जिन्हें एक सेवा में स्ट्रिंग कंकेटिनेशन द्वारा इकट्ठा किया गया था जिसका कोई मालिक नहीं है।

विनियमित उद्योगों में दांव अधिक होते हैं क्योंकि हैंडऑफ़ स्वयं अनुपालन सतह होते हैं। एक गिरवी ऋण निर्णय जो चार एजेंटों के माध्यम से प्रवाहित होता है, उसे हर हॉप का पुनर्निर्माण योग्य रिकॉर्ड चाहिए: क्या भेजा गया था, क्या वापस आया, किस एजेंट के किस वर्ज़न ने इसे उत्पन्न किया। तदर्थ एकीकरण उस रिकॉर्ड को महंगा या असंभव बनाता है। एक प्रोटोकॉल इसे काम करने का एक उप-उत्पाद बनाता है।

A2A क्या है

A2A एजेंटों के लिए एक ओपन प्रोटोकॉल है जो प्रक्रिया, टीम, और संगठनात्मक सीमाओं के पार एक-दूसरे को खोजते हैं, संदेशों का आदान-प्रदान करते हैं, और कार्यों को निष्पादित करते हैं। Google ने इसे अप्रैल 2025 में दर्जनों लॉन्च पार्टनर के साथ घोषित किया और जून 2025 में इसे Linux Foundation को दान कर दिया, जहाँ यह अब एक तटस्थ ओपन-सोर्स प्रोजेक्ट के रूप में रहता है। विनिर्देश 2026 में 1.0 तक पहुँच गया।

तथ्य विवरण
उत्पत्ति Google द्वारा अप्रैल 2025 में घोषित; जून 2025 में Linux Foundation को दान किया गया
शासन Linux Foundation (A2A प्रोजेक्ट, GitHub पर a2aproject)
वर्तमान विनिर्देश 1.0 (पहले के डिप्लॉय किए गए वर्ज़न: 0.2, 0.3; फील्ड में भिन्नता की अपेक्षा करें)
परिवहन HTTP(S) पर JSON-RPC 2.0; gRPC और HTTP+JSON/REST बाइंडिंग विनिर्देश के जीवनकाल में बाद में जोड़े गए
खोज Agent Card: /.well-known/agent-card.json पर परोसा गया JSON मेटाडेटा
कार्य की इकाई कार्य, एक परिभाषित जीवनचक्र और अद्वितीय ID के साथ
परिणाम आर्टिफैक्ट्स (संरचित आउटपुट), संवादात्मक संदेशों से भिन्न
स्ट्रीमिंग HTTP बाइंडिंग पर Server-Sent Events; gRPC पर सर्वर स्ट्रीमिंग
लंबे समय तक चलने वाला कार्य क्लाइंट वेबहुक पर पुश नोटिफिकेशन, साथ ही फिर से कनेक्ट करने के लिए रीसब्सक्राइब
प्रमाणीकरण Agent Card में घोषित: API कुंजी, HTTP Basic/Bearer, OAuth 2.0, OpenID Connect, म्यूचुअल TLS

दो डिज़ाइन विकल्प बाकी सभी से अधिक महत्वपूर्ण हैं। पहला, A2A इरादे से अपारदर्शी है: एजेंट अपनी आंतरिक स्थिति, मॉडल वेट, या उपकरणों को एक-दूसरे के सामने उजागर नहीं करते हैं। वे क्षमताओं को उजागर करते हैं और परिणामों का आदान-प्रदान करते हैं। वह अपारदर्शिता ही है जो एक वेंडर द्वारा बनाए गए एजेंट को, एक मॉडल पर जिसे आप नियंत्रित नहीं करते हैं, आपकी प्रक्रिया में भाग लेने देती है, बिना आपको उसके आंतरिक भागों पर भरोसा करने की आवश्यकता के, केवल उसके कॉन्ट्रैक्ट पर। दूसरा, A2A चैट-उन्मुख के बजाय कार्य-उन्मुख है। प्रोटोकॉल का मुख्य ऑब्जेक्ट एक जीवनचक्र वाला कार्य है, न कि एक संदेश थ्रेड। यह एकल विकल्प ही है जो इसे एंटरप्राइज़ कार्य के लिए उपयोगी बनाता है, क्योंकि एंटरप्राइज़ कार्य एक बातचीत नहीं है। यह एक स्थिति, एक मालिक, और एक समय-सीमा के साथ कार्य की एक इकाई है।

प्रोटोकॉल स्टैक: A2A, MCP, AG-UI, AP2

सबसे उपयोगी फ्रेमिंग जो मुझे मिली है, और जिसे मैं व्हाइटबोर्ड पर बनाता रहता हूँ, वह एक स्टैक है। प्रत्येक प्रोटोकॉल एक अलग प्रश्न का उत्तर देता है, और वे प्रतिस्पर्धा करने के बजाय संयोजित होते हैं।

प्रोटोकॉल लेयर यह किस प्रश्न का उत्तर देता है मोटा-मोटा सादृश्य
MCP एजेंट-से-टूल एक एजेंट टूल को कैसे कॉल करता है और डेटा स्रोतों तक कैसे पहुँचता है? क्षमताओं के लिए USB-C
A2A एजेंट-से-एजेंट पीयर एजेंट एक-दूसरे को कैसे खोजते हैं और कार्यों को कैसे सौंपते हैं? सेवाओं के बीच HTTP
AG-UI एजेंट-से-उपयोगकर्ता एक एजेंट ह्यूमन-फेसिंग इंटरफ़ेस में स्थिति को कैसे स्ट्रीम करता है? फ्रंट एंड के लिए WebSocket
AP2 एजेंट-से-व्यापारी एक एजेंट भुगतान प्राधिकरण को कैसे साबित करता है और लेनदेन कैसे करता है? नीचे की लेयर पर चलने वाले हस्ताक्षरित मैंडेट

स्टैक के माध्यम से एक ठोस पास: एक उपयोगकर्ता एक ब्रोकर एजेंट से गिरवी ऋण अनुशंसा मांगता है (AG-UI इंटरैक्शन को UI में ले जाता है)। ब्रोकर जोखिम विश्लेषण को एक अंडरराइटर एजेंट को सौंपता है (A2A)। अंडरराइटर एक आंतरिक दस्तावेज़ स्टोर से आवेदक की फ़ाइल खींचता है (MCP)। यदि फ्लो एजेंट द्वारा उपयोगकर्ता की ओर से क्रेडिट रिपोर्ट के लिए भुगतान करने में समाप्त होता, तो भुगतान प्राधिकरण AP2 मैंडेट के रूप में यात्रा करता। चार प्रोटोकॉल, चार सीमाएँ, एक प्रक्रिया।

स्टैक फ्रेमिंग का व्यावहारिक परिणाम वास्तुशिल्प अनुशासन है। जब कोई आंतरिक डेटाबेस को “एक एजेंट” के रूप में उजागर करने का प्रस्ताव करता है, तो स्टैक आपको यह कहने के लिए शब्दावली देता है: वह एक टूल है, उसे MCP के पीछे रखें। जब कोई दो वेंडर एजेंटों को एक कस्टम वेबहुक के साथ जोड़ने का प्रस्ताव करता है, तो स्टैक कहता है: वह एक पीयर डेलिगेशन है, A2A का उपयोग करें और कार्य जीवनचक्र मुफ्त में प्राप्त करें। मैंने AP2 फील्ड गाइड में भुगतान लेयर पर एक अलग गहन विश्लेषण लिखा है; यह गाइड एजेंट-से-एजेंट सीम पर केंद्रित है।

महत्वपूर्ण यांत्रिकी

विनिर्देश लंबा है। व्यवहार में चार टुकड़े अधिकांश काम करते हैं।

Agent Cards: एक कॉन्ट्रैक्ट के रूप में खोज

एक Agent Card एक JSON दस्तावेज़ है, जो https://{host}/.well-known/agent-card.json पर परोसा जाता है, जो वर्णन करता है कि एक एजेंट क्या है, वह क्या कर सकता है, और उससे सुरक्षित रूप से कैसे बात करनी है। यह OpenAPI दस्तावेज़ का A2A समकक्ष है, सिवाय इसके कि यह एंडपॉइंट और स्कीमा के बजाय क्षमताओं और कौशलों का वर्णन करता है।

{
  "name": "Underwriter Agent",
  "description": "Analyzes applicant risk from income, debts, and credit score",
  "url": "https://agents.example.com/underwriter",
  "version": "1.4.0",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "securitySchemes": { "oauth": { "type": "oauth2" } },
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "risk-analysis",
      "name": "Mortgage risk analysis",
      "description": "Produces a structured risk assessment for a loan applicant",
      "tags": ["underwriting", "risk"]
    }
  ]
}

मेरे हैकाथॉन बिल्ड में, पूरे सिस्टम के लिए स्मोक टेस्ट सचमुच curl http://localhost:4001/.well-known/agent-card.json | jq '.name' है। यदि कार्ड हल हो जाता है, तो एजेंट खोज योग्य है; बाकी सब उस पर आधारित है। कार्ड एजेंट की प्रमाणीकरण आवश्यकताओं को भी घोषित करता है और क्या यह स्ट्रीमिंग और पुश नोटिफिकेशन का समर्थन करता है, जिसे क्लाइंट को उन पर भरोसा करने से पहले जांचना चाहिए। वर्तमान विनिर्देश हस्ताक्षरित कार्ड (कार्ड सामग्री पर एक JWS हस्ताक्षर) का समर्थन करता है ताकि एक क्लाइंट सत्यापित कर सके कि कार्ड किसने जारी किया है। उसका उपयोग करें। मैं खतरा मॉडल में वापस आऊँगा कि क्यों।

कार्य जीवनचक्र

A2A में हर डेलिगेशन एक ID और एक स्टेट मशीन वाला एक कार्य है। परिभाषित स्थितियाँ, उनके JSON रूपों में:

स्थिति अर्थ टर्मिनल?
submitted स्वीकृत, अभी तक शुरू नहीं हुआ नहीं
working सक्रिय रूप से संसाधित हो रहा है नहीं
input-required विराम पर, क्लाइंट द्वारा अधिक इनपुट प्रदान करने की प्रतीक्षा में नहीं (बाधित)
auth-required विराम पर, अतिरिक्त प्राधिकरण की प्रतीक्षा में नहीं (बाधित)
completed सफलतापूर्वक समाप्त, आर्टिफैक्ट्स उपलब्ध हाँ
failed एक त्रुटि के साथ समाप्त हाँ
canceled पूरा होने से पहले रद्द किया गया हाँ
rejected एजेंट ने कार्य अस्वीकार कर दिया हाँ

दो स्थितियाँ ध्यान देने योग्य हैं क्योंकि वे उद्यम की वास्तविकता को एन्कोड करती हैं जिसे चैट-आकार के प्रोटोकॉल अनदेखा करते हैं। input-required का अर्थ है कि एक कार्य बीच में रुक सकता है और अधिक जानकारी मांग सकता है, जो इस तरह है कि एक रिमोट अंडरराइटिंग एजेंट पूरे कार्य को विफल किए बिना एक गुम दस्तावेज़ मांगता है। rejected का अर्थ है कि एक एजेंट उस काम को अस्वीकार कर सकता है जिसके लिए वह योग्य या अधिकृत नहीं है, जो नीति प्रवर्तन के लिए प्रोटोकॉल-स्तर का हुक है। जो क्लाइंट दोनों स्थितियों को नहीं संभालता है उसने A2A लागू नहीं किया है; उसने डेमो लागू किया है।

संदेश, भाग, आर्टिफैक्ट्स

एक कार्य के भीतर संचार संदेशों का उपयोग करता है (भूमिका: उपयोगकर्ता या एजेंट), और प्रत्येक संदेश में भाग होते हैं: टेक्स्ट, रॉ बाइट्स, एक फ़ाइल संदर्भ, या मनमाना संरचित डेटा। परिणाम आर्टिफैक्ट्स के रूप में वापस आते हैं, जो भागों से भी बने होते हैं लेकिन बातचीत से भिन्न होते हैं। यह अलगाव तब तक नौकरशाही लगता है जब तक आप कुछ वास्तविक नहीं बनाते। बातचीत वह है कि एजेंटों ने कैसे बातचीत की; आर्टिफैक्ट्स वह हैं जिन पर आप कार्य करते हैं और जिनका आप ऑडिट करते हैं। गिरवी ऋण सिस्टम में, अंडरराइटर का आर्टिफैक्ट एक संरचित जोखिम मूल्यांकन है। डाउनस्ट्रीम चरण आर्टिफैक्ट का उपभोग करते हैं, न कि उस बकवास का जिसने इसे उत्पन्न किया।

स्ट्रीमिंग और लंबे समय तक चलने वाले कार्य

इंटरैक्टिव कार्य के लिए, HTTP बाइंडिंग Server-Sent Events पर TaskStatusUpdateEvent और TaskArtifactUpdateEvent ऑब्जेक्ट को स्ट्रीम करता है (JSON-RPC बाइंडिंग में, message/stream)। यही एक लाइव प्रगति UI को चलाता है: मेरे गिरवी ऋण डेमो की एनिमेटेड अंडरराइटिंग चेकलिस्ट सीधे स्ट्रीम किए गए स्टेटस अपडेट से रेंडर की जाती है।

उद्यमों के लिए अधिक महत्वपूर्ण हिस्सा लंबे समय तक चलने वाला मामला है। एक बैंक में वास्तविक कार्य एक HTTP कनेक्शन में समाप्त नहीं होते हैं। अपने ग्राहक को जानें (KYC) जांच में कई दिन लग सकते हैं। एक संपत्ति मूल्यांकन में एक इंसान का घर तक गाड़ी चलाना शामिल होता है। A2A इसे पुश नोटिफिकेशन के साथ संभालता है: क्लाइंट एक वेबहुक रजिस्टर करता है, कार्य की प्रगति के साथ सर्वर उस पर स्थिति और आर्टिफैक्ट इवेंट POST करता है, और फिर से कनेक्ट करने वाला क्लाइंट ID द्वारा एक कार्य को फिर से सब्सक्राइब कर सकता है। किसी भी कनेक्शन को खुला रखने की आवश्यकता नहीं है, और न ही किसी भी पक्ष को लगातार चलने की आवश्यकता है।

लेकिन ध्यान दें कि प्रोटोकॉल यहाँ क्या नहीं करता है: यह आपके लिए कुछ भी याद नहीं रखता है। यदि आपका क्लाइंट प्रोसेस तीन दिवसीय कार्य के दूसरे दिन क्रैश हो जाता है, तो A2A खुशी-खुशी एक वेबहुक को पूर्णता इवेंट वितरित करेगा जिसे अब यह नहीं पता कि उसे इसकी परवाह क्यों है। क्लाइंट साइड पर टिकाऊ स्थिति आपकी समस्या है, और ठीक वही समस्या है जिसके लिए वर्कफ़्लो इंजन बनाए गए थे। यह तकनीकी कारण है कि ऑर्केस्ट्रेशन का प्रश्न आगे आता है।

ऑर्केस्ट्रेशन बनाम स्वार्म

A2A एजेंटों को एक सिस्टम में जोड़ने के दो तरीके हैं, और यह विकल्प इस गाइड में किसी भी अन्य से अधिक महत्वपूर्ण है।

स्वार्म मॉडल में, एजेंट एक-दूसरे को पीयर-टू-पीयर सौंपते हैं। ब्रोकर अंडरराइटर को कॉल करता है, अंडरराइटर अपने आप एक दस्तावेज़ एजेंट को कॉल करने का फैसला करता है, दस्तावेज़ एजेंट कुछ और कॉल करता है। कंट्रोल फ्लो उभरता है। ऑर्केस्ट्रेशन मॉडल में, एक प्रोसेस इंजन फ्लो का मालिक होता है और A2A एजेंटों को चरणों के रूप में कॉल करता है। इंजन तय करता है कि क्या चलता है, किस क्रम में, किस टाइमआउट के साथ; एजेंट हर चरण के अंदर सोचते हैं। मेरा एक-लाइन वर्ज़न, और वह पैटर्न जिसे मैंने Camunda श्रृंखला में प्रदर्शित किया: प्रक्रिया ऑर्केस्ट्रेटर है।

ऑर्केस्ट्रेशन बनाम स्वार्म: एक प्रोसेस इंजन तीन A2A एजेंटों को ऑडिट किए गए चरणों के रूप में कॉल कर रहा है, उसके बगल में उलझे हुए तीरों और कोई स्पष्ट ऑडिट मालिक के बिना एक पीयर-टू-पीयर स्वार्म।

दो-भाग की ब्लॉग श्रृंखला में हमने इसे एक निर्णय अनुमानी में तोड़ा जिसे मैं अभी भी शब्दशः उपयोग करता हूँ। यदि किसी दिए गए चरण में प्रश्न यह है कि “इस एजेंट को अभी कॉल करें, X मिनट तक प्रतीक्षा करें, Y बार रीट्राय करें, और विफलता पर एस्केलेट करें,” तो वह चरण A2A को एक सर्विस टास्क के रूप में इनवोक करने के साथ एक नियतात्मक प्रक्रिया फ्लो में आता है। यदि प्रश्न यह है कि “मुझे किस एजेंट को कॉल करना चाहिए, और हमें आगे क्या करना चाहिए,” तो वह चरण एक AI एजेंट सब-प्रोसेस के अंदर आता है जहाँ A2A कई उपकरणों में से एक है और एजेंट रनटाइम पर चुनता है। Camunda बिल्ड में ये सचमुच दो कनेक्टर मोड हैं (स्टैंडअलोन बनाम एजेंट टूल), लेकिन पैटर्न इंजन-अज्ञेयवादी है: Temporal पर यह एक गतिविधि बनाम एक LLM प्लानर द्वारा संचालित एक चाइल्ड वर्कफ़्लो है; LangGraph पर यह एक निश्चित एज बनाम एक राउटर नोड है। पहले पैटर्न, फिर उत्पाद।

दोनों पैटर्न पूरक हैं, प्रतिस्पर्धी नहीं। मेरे कार्यरत सिस्टम दोनों का उपयोग करते हैं: महत्वपूर्ण पथ के लिए एक नियतात्मक बैकबोन, खोजपूर्ण पॉकेट्स के अंदर एजेंट-संचालित टूल चयन।

जिस पर मैं, दृढ़ता से, विनियमित सेटिंग्स में शुद्ध स्वार्म पर आपत्ति करता हूँ। हर गंभीर समीक्षा में तीन विफलता मोड सामने आते हैं:

ऑडिटेबिलिटी। एक स्वार्म में, “किस एजेंट ने यह तय किया, किस इनपुट के आधार पर” का पुनर्निर्माण करने का मतलब है विभिन्न टीमों, या विभिन्न कंपनियों के स्वामित्व वाली सेवाओं में लॉग को सहसंबंधित करना। एक ऑर्केस्ट्रेटेड फ्लो में, हर A2A कॉल एक प्रोसेस इंस्टेंस में एक चरण है: इनपुट, आउटपुट, टाइमिंग, और रीट्राय निर्माण द्वारा प्रोसेस स्थिति के रूप रूप में रिकॉर्ड किए जाते हैं। जब मैंने गिरवी ऋण डेमो बनाया, तो हर मध्यवर्ती एजेंट परिणाम एक नामित प्रोसेस वेरिएबल में आया जिसे एक ऑपरेटर जांच सकता था। वह अतिरिक्त काम नहीं था। वह आर्किटेक्चर से निकला।

एटॉमिक कैंसिलेशन। एक ग्राहक अपना आवेदन वापस लेता है। एक ऑर्केस्ट्रेटेड फ्लो में, आप प्रोसेस इंस्टेंस को रद्द करते हैं और इंजन इन-फ्लाइट A2A कार्यों को रद्द करता है (प्रोटोकॉल आपको tasks/cancel देता है; इंजन आपको इसे कॉल करने के लिए कोई देता है)। एक स्वार्म में, रद्दीकरण एक अफवाह है जो सर्वोत्तम-प्रयास गति से एजेंटों के माध्यम से फैलती है जो इसे मान सकते हैं या नहीं भी मान सकते हैं। अब कल्पना करें कि रद्द किया जा रहा कार्य “क्रेडिट आवेदन जमा करें” है।

घटना की जांच। जब एक ऑर्केस्ट्रेटेड फ्लो टूटता है, तो घटना का एक पता होता है: प्रोसेस इंस्टेंस, चरण, टाइमस्टैम्प, पेलोड। जब एक स्वार्म टूटता है, तो जांच का पहला सप्ताह यह स्थापित करना होता है कि क्या हुआ, और एजेंटों के अपने कथात्मक लॉग सबूत नहीं हैं, वे गवाही हैं।

समीक्षा टिप्पणी: यदि आपके मल्टी-एजेंट आर्किटेक्चर में कोई एक जगह नहीं है जहाँ कोई यह उत्तर दे सके कि “इस ग्राहक के अनुरोध की वर्तमान स्थिति क्या है,” तो आपने एक सिस्टम नहीं बनाया है। आपने API कुंजियों के साथ एक ग्रुप चैट बनाया है।

इनमें से किसी के लिए भी विशेष रूप से Camunda की आवश्यकता नहीं है। इसके लिए यह आवश्यक है कि कुछ टिकाऊ और जांच योग्य फ्लो का मालिक हो। Camunda वह जगह है जहाँ मैं बनाता हूँ क्योंकि यह मेरा दिन का काम है और क्योंकि BPMN ऑडिटरों को एक आरेख देता है जिसे वे पढ़ सकते हैं, लेकिन यह तर्क टिकाऊ स्थिति, टाइमर, और रद्दीकरण सिमेंटिक्स वाले किसी भी इंजन के लिए मान्य है।

एक कार्यरत पैटर्न: गिरवी ऋण कंसीयर्ज

मैंने अब इस सिस्टम को दो बार बनाया है, इसलिए मैं सामान्यीकृत आकार का वर्णन करूँगा और इस बारे में ईमानदार रहूँगा कि प्रत्येक बिल्ड ने क्या साबित किया और उसने क्या नकली बनाया।

पात्र, चार एजेंट और एक सीमा:

  • ब्रोकर एजेंट। सामने का दरवाजा। आवेदक का अनुरोध प्राप्त करता है, तय करता है कि किन विशेषज्ञों को शामिल करना है, और अंतिम अनुशंसा को इकट्ठा करता है। Camunda बिल्ड में यह A2A क्लाइंट, DMN निर्णय तालिकाओं, एक वेक्टर स्टोर, और अपने टूलबॉक्स में एक CRM लुकअप के साथ एक AI एजेंट सब-प्रोसेस है। हैकाथॉन बिल्ड में यह एक स्टैंडअलोन ऑर्केस्ट्रेटर सेवा है।
  • अंडरराइटर एजेंट (रिमोट)। आय, ऋण, और क्रेडिट स्कोर पर Gemini-संचालित जोखिम विश्लेषण। हैकाथॉन बिल्ड में, यह एजेंट Files API के माध्यम से संदर्भ में एक पूरी गिरवी ऋण विनियमन गाइड (लगभग 85k टोकन Fannie Mae Selling Guide के) लोड करता है और अपने आउटपुट में विशिष्ट विनियमन कोड, उदाहरण के लिए B3-6-02, का हवाला देता है। यह रिमोट है और ऐसा ही होना चाहिए: यह पूरी तरह से उस डेटा से काम करता है जिसे आवेदक ने ठीक इसी उद्देश्य के लिए जमा करना चुना, और यह सबसे मजबूत उपलब्ध मॉडल से लाभ उठाता है।
  • मार्केट-रिसर्च एजेंट (स्थानीय)। एक जोखिम प्रोफ़ाइल के लिए लागू दरें ढूंढता है। जानबूझकर ट्रस्ट बाउंड्री के अंदर होस्ट किया गया। अगले खंड में क्यों, इस पर अधिक।
  • जज एजेंट। ब्रोकर के इकट्ठे आउटपुट का मूल्यांकन करता है और उसके आत्मविश्वास को स्कोर करता है। थ्रेशोल्ड से ऊपर, प्रक्रिया स्वचालित रूप से आगे बढ़ती है। इसके नीचे, प्रक्रिया पूर्ण संदर्भ संलग्न के साथ एक ह्यूमन-रिव्यू कार्य पर रूट होती है। हैकाथॉन वेरिएंट में यह भूमिका एक विरोधी QA एजेंट की है जो गणित (ऋण-से-आय गणना, ऋण-से-मूल्य अनुपात) की जांच करता है और उपयोगकर्ता द्वारा उन्हें देखने से पहले भ्रमित विनियमन उद्धरणों को अस्वीकार करता है, विफल आउटपुट को सुधार के लिए स्वायत्त रूप से वापस भेजता है।

जज वह हिस्सा है जिसे लोग कम आंकते हैं। एक आत्मविश्वास-गेटेड ह्यूमन फॉलबैक “मॉडल कभी-कभी गलत होता है” को एक आपत्ति से एक डिज़ाइन किए गए पथ में परिवर्तित करता है। थ्रेशोल्ड एक व्यावसायिक निर्णय है जिसे आप प्रति जोखिम वर्ग ट्यून कर सकते हैं, और ह्यूमन रिव्यू कार्य एक SLA के साथ एक फर्स्ट-क्लास प्रोसेस स्टेप है, न कि पहली घटना के बाद जोड़ा गया एक अपवाद हैंडलर।

डेमो और प्रोडक्शन के बीच के अंतर के बारे में ईमानदारी:

मेरे डेमो में प्रोडक्शन में
आवेदक द्वारा दर्ज किया गया क्रेडिट डेटा सहमति ट्रैकिंग के साथ क्रेडिट ब्यूरो एकीकरण
हर चीज के लिए एक जज थ्रेशोल्ड उत्पाद और जोखिम वर्ग के अनुसार थ्रेशोल्ड, जोखिम के स्वामित्व में, समय-समय पर समीक्षा की जाती है।
हार्डकोडेड कार्ड URL द्वारा खोजे गए एजेंट हस्ताक्षर सत्यापन और अनुमति सूची के साथ एक कार्ड रजिस्ट्री
हैप्पी-पाथ रद्दीकरण साइड इफेक्ट वाले हर चरण के लिए मुआवजा तर्क
चारों एजेंटों का स्वामित्व एक टीम के पास चार मालिक, चार रिलीज़ चक्र, हर कार्ड पर कॉन्ट्रैक्ट टेस्ट।

अंतिम पंक्ति वह है जो सब कुछ बदल देती है। एक मालिक के साथ, A2A एक अच्छा आंतरिक कन्वेंशन है। चार मालिकों के साथ, यह आपके और इस गाइड के शीर्ष से N×(N-1) ग्लू समस्या के बीच खड़ी एकमात्र चीज है।

डेटा-गोपनीयता सीमा पैटर्न

स्थानीय-संवेदनशील / रिमोट-सार्वजनिक

यह गिरवी ऋण निर्माण का पैटर्न है जो सबसे दूर तक सामान्यीकृत होता है, और जिसे मैं बैंकों के लिए सबसे अधिक बार स्केच करता हूँ।

अपने एजेंटों को डेटा संवेदनशीलता के आधार पर विभाजित करें, न कि फ़ंक्शन के आधार पर। संवेदनशील डेटा (उधारकर्ता PII, खाता इतिहास, नियामक निवास प्रतिबंधों वाला कुछ भी) को छूने वाले एजेंट स्थानीय रूप से, आपकी ट्रस्ट बाउंड्री के अंदर, आपके द्वारा होस्ट किए गए मॉडल पर या आपके द्वारा नियंत्रित कॉन्ट्रैक्ट पर चलते हैं। सार्वजनिक डेटा (बाजार दरें, संपत्ति तुलनात्मक, नियामक ग्रंथ) पर काम करने वाले एजेंट सबसे मजबूत उपलब्ध फ्रंटियर मॉडल पर दूरस्थ रूप से चल सकते हैं। A2A दोनों ज़ोन के बीच की सीम है।

डेटा-गोपनीयता सीमा पैटर्न: ट्रस्ट बाउंड्री के अंदर एक स्थानीय रूप से होस्ट किया गया एजेंट और संवेदनशील डेटा स्टोर, बाहर सबसे अच्छे फ्रंटियर मॉडल पर एक रिमोट विशेषज्ञ एजेंट, और सीमा पार करने वाली एक A2A सीम जो कार्य और निष्कर्ष ले जाती है, कभी भी रॉ रिकॉर्ड नहीं।

प्रोटोकॉल इस सीम को इस तरह से साफ बनाता है जिस तरह से तदर्थ एकीकरण नहीं करता। Agent Card डेटा को उजागर किए बिना क्षमता का विज्ञापन करता है: रिमोट ब्रोकर जानता है कि स्थानीय मार्केट-रिसर्च एजेंट मौजूद है और वह क्या कौशल प्रदान करता है, लेकिन हर वास्तविक आदान-प्रदान एक स्पष्ट, लॉग किया गया A2A कार्य है जिसके संदेश भागों को आप नियंत्रित करते हैं। संवेदनशील फ़ील्ड आउटबाउंड भागों में कभी नहीं दिखाई देते हैं, और क्योंकि सभी क्रॉस-बाउंड्री ट्रैफिक एक प्रोटोकॉल के माध्यम से प्रवाहित होता है, आप इसे एक एग्रेस गेटवे के साथ लागू कर सकते हैं जो एक दर्जन अनुकूलित एकीकरणों का ऑडिट करने के बजाय एक ही चोक पॉइंट पर A2A पेलोड का निरीक्षण करता है।

गिरवी ऋण सिस्टम में: अंडरराइटर एजेंट (रिमोट, Gemini) उन वित्तीय विवरणों को देखता है जिन्हें आवेदक ने ठीक इसी उद्देश्य के लिए जमा किया था। मार्केट-रिसर्च एजेंट (स्थानीय) सीमा के अंदर अपनी पुनर्प्राप्ति करता है और अपने आर्टिफैक्ट्स में दरें लौटाता है, न कि ग्राहक संदर्भ। जज दोनों आउटपुट देखता है लेकिन स्थानीय रूप से चलता है। पैटर्न में कुछ भी विदेशी नहीं है। यह नेटवर्क सेगमेंटेशन है, एजेंटों पर लागू, A2A के साथ सीमा पर रूट करने योग्य प्रोटोकॉल के रूप में। यह परिचितता एक विशेषता है: आपकी सुरक्षा टीम पहले से ही इस डिज़ाइन की समीक्षा करना जानती है।

खतरा मॉडल: मुश्किल हिस्से

A2A आपको एक कॉन्ट्रैक्ट सतह देता है। कॉन्ट्रैक्ट सतहों पर हमला होता है। ये वे पांच मुद्दे हैं जिन्हें मैं हर डिज़ाइन समीक्षा में उठाता हूँ, मोटे तौर पर इस क्रम में कि वे आपको कितनी जल्दी नुकसान पहुँचाएँगे।

Agent Card स्पूफिंग

कार्ड एक ज्ञात URL पर एक JSON फ़ाइल है। कुछ भी जो JSON परोस सकता है, वह आपका अंडरराइटर होने का दावा कर सकता है। TLS चैनल की सुरक्षा करता है, दावे की नहीं: एक समझौता किया गया DNS एंट्री, एक हाईजैक किया गया सबडोमेन, या एक दुर्भावनापूर्ण आंतरिक सेवा एक एजेंट के लिए एक पूरी तरह से अच्छी तरह से बना कार्ड प्रस्तुत कर सकता है जिसे वह संचालित नहीं करता है, और आपका ब्रोकर खुशी-खुशी उसे ऋण आवेदन भेजेगा। शमन, गंभीरता के बढ़ते क्रम में: खोज का आँख बंद करके पालन करने के बजाय कार्ड URL पिन करें; आपके द्वारा विश्वसनीय जारीकर्ताओं के खिलाफ कार्ड हस्ताक्षरों (विनिर्देश JWS-हस्ताक्षरित कार्ड का समर्थन करता है) को सत्यापित करें; और एक आंतरिक कार्ड रजिस्ट्री चलाएँ जो एक अनुमति सूची के रूप में कार्य करती है, ताकि “खोज योग्य” और “कॉल करने योग्य” अलग-अलग विशेषाधिकार हों। एक नए Agent Card को वैसे ही मानें जैसे आप एक नई अपस्ट्रीम निर्भरता को मानते हैं, क्योंकि यह वही है।

क्षमता बहाव

कार्ड वर्ज़न 1.4.0 कहता है और एक जोखिम-विश्लेषण कौशल का विज्ञापन करता है। छह सप्ताह बाद उसके पीछे की टीम मॉडल को बदल देती है, सिस्टम प्रॉम्प्ट को फिर से लिखती है, और समान कार्ड टेक्स्ट और भौतिक रूप से भिन्न व्यवहार के साथ वर्ज़न 1.4.1 शिप करती है। प्रोटोकॉल में कुछ भी इसे नहीं पकड़ता है; A2A द्वारा लागू किया गया कॉन्ट्रैक्ट संरचनात्मक है, व्यवहारिक नहीं। शमन वही है जिसका हम किसी भी सेवा निर्भरता के लिए उपयोग करते हैं, गैर-नियतात्मकता के लिए अनुकूलित: कॉन्ट्रैक्ट टेस्ट जो एक शेड्यूल पर लाइव एजेंट के खिलाफ गोल्डन टास्क चलाते हैं और आर्टिफैक्ट्स में वितरण बदलाव पर अलर्ट करते हैं, न कि केवल स्कीमा ब्रेक पर। यदि आप एक एजेंट का उपभोग करते हैं जिसके आप मालिक नहीं हैं, तो आपको उसके लिए एक मूल्यांकन सूट की आवश्यकता है। मैंने पर्याप्त मॉडल स्वैप को मापा है ताकि यह स्पष्ट रूप से कहा जा सके: वही कार्ड, वही स्कीमा, अलग मॉडल एक अलग एजेंट है।

वर्ज़न तिरछापन

विनिर्देश तेजी से आगे बढ़ा: लगभग एक साल के भीतर 0.2 से 0.3 से 1.0 तक, और परिवर्तन कॉस्मेटिक नहीं थे। परिवहन बाइंडिंग जोड़े गए, और यहां तक कि ज्ञात खोज पथ रास्ते में बदल गया (शुरुआती कार्यान्वयन agent.json परोसते थे, वर्तमान विनिर्देश agent-card.json कहता है)। एक मल्टी-मालिक डिप्लॉयमेंट में आपके पास एक साथ विभिन्न विनिर्देश वर्ज़न पर एजेंट होंगे, इसकी गारंटी है। हर कार्य लॉग में प्रोटोकॉल वर्ज़न रिकॉर्ड करें, वर्ज़न नेगोशिएशन पथ का स्पष्ट रूप से परीक्षण करें, और यह न मानें कि इकोसिस्टम के SDKs एज केस को समान रूप से व्याख्या करते हैं, क्योंकि वे ऐसा नहीं करते हैं।

संगठनात्मक सीमाओं के पार अवलोकनशीलता

आपकी सीमा के अंदर, आप सब कुछ ट्रेस कर सकते हैं। जिस क्षण एक कार्य एक पार्टनर के एजेंट तक पहुँचता है, आपका ट्रेस उनके सामने के दरवाजे पर समाप्त हो जाता है। A2A आपको सहसंबंधित करने के लिए कार्य ID और संदर्भ ID देता है, लेकिन सहसंबंध तभी काम करता है जब दोनों पक्ष रिकॉर्ड रखते और साझा करते हैं। यह एक कॉन्ट्रैक्ट बातचीत है, कोड की समस्या नहीं: लाइव होने से पहले ट्रेस ID प्रसार, लॉग प्रतिधारण, और एक्सेस पर सहमत हों, क्योंकि एक घटना के दौरान इस पर बातचीत करना दयनीय है। मेरी डिफ़ॉल्ट स्थिति यह है कि ग्राहक परिणाम का मालिक पक्ष हर क्रॉस-बाउंड्री कार्य का एक आधिकारिक रिकॉर्ड रखता है: अनुरोध, प्रतिक्रिया, समय, और कार्ड वर्ज़न। ऑर्केस्ट्रेशन इसे लगभग मुफ्त बनाता है; एक स्वार्म इसे एक प्रोजेक्ट बनाता है।

SLA का मालिक कौन है

एक पार्टनर एजेंट के खिलाफ एक A2A कार्य में एक टाइमआउट होता है जिसे आप सेट करते हैं और एक पूर्णता समय होता है जिसे वे नियंत्रित करते हैं। जब अंडरराइटर एजेंट चालीस सेकंड से चार सौ सेकंड तक धीमा हो जाता है, तो यह किसकी घटना है? प्रोटोकॉल आपको नहीं बताएगा। ऑपरेटिंग एग्रीमेंट में संख्याएँ डालें (प्रति कौशल प्रतिक्रिया-समय प्रतिशत, थ्रूपुट, नियोजित रखरखाव विंडो) और अपने पक्ष को यांत्रिक रूप से लागू करें: प्रति चरण टाइमआउट बजट, पोलिंग पर टाइमर-आधारित बैकऑफ़, एक अधिकतम रीट्राय गणना, और जब रीट्राय समाप्त हो जाते हैं तो एक परिभाषित एस्केलेशन पथ। नियतात्मक पैटर्न में, वह सब प्रोसेस मॉडल में रहता है जहाँ ऑपरेशंस इसे देख सकते हैं। यदि आपका एकमात्र SLA प्रवर्तन यह उम्मीद है कि रिमोट एजेंट तेज है, तो स्वार्म पहले ही जीत चुका है और आप पहले ही हार चुके हैं।

समीक्षा टिप्पणी: इन पांचों में से हर एक एक तकनीकी सतह वाली संगठनात्मक समस्या है। प्रोटोकॉल आपको सतह देता है। यह आपके लिए गवर्नेंस मीटिंग में शामिल नहीं हो सकता।

A2A क्या हल नहीं करता है

एक आर्किटेक्चर बोर्ड के साथ विश्वसनीयता खोने का सबसे तेज़ तरीका एक प्रोटोकॉल को बढ़ा-चढ़ाकर पेश करना है। यहाँ इसकी ईमानदार सीमा है।

सिमेंटिक्स। A2A गारंटी देता है कि एक संदेश वैध संरचना के साथ आता है। यह गारंटी नहीं देता कि दो एजेंट income से एक ही बात का मतलब निकालते हैं। सकल या शुद्ध? वार्षिक या मासिक? घरेलू या व्यक्तिगत? दो विनिर्देश-अनुरूप एजेंट दोषरहित JSON का आदान-प्रदान कर सकते हैं और एक गलत निर्णय उत्पन्न कर सकते हैं। आपको अभी भी साझा शब्दावली की आवश्यकता है, और विनियमित डोमेन में आपको उन्हें लिखित रूप में चाहिए। प्रोटोकॉल एकीकरण समस्या को एक स्तर ऊपर ले जाता है; यह उसे भंग नहीं करता है।

ट्रस्ट। हस्ताक्षरित कार्ड आपको बताते हैं कि किसने एक क्षमता दावा प्रकाशित किया है। वे आपको यह नहीं बताते कि एजेंट सक्षम है या नहीं, क्या उसका प्रशिक्षण डेटा उपयुक्त था, या क्या उसका ऑपरेटर अगली तिमाही में भी मौजूद रहेगा। एजेंटों के लिए प्रतिष्ठा, प्रमाणन, और जवाबदेही खुली समस्याएँ हैं। आज वे कंपनियों के बीच कॉन्ट्रैक्ट्स द्वारा हल किए जाते हैं, हमेशा की तरह।

भुगतान। A2A कार्य को स्थानांतरित करता है, पैसे को नहीं। जब एक एजेंट को यह साबित करने की आवश्यकता होती है कि वह उपयोगकर्ता की ओर से खर्च करने के लिए अधिकृत है, तो वह अलग क्रिप्टोग्राफिक आवश्यकताओं वाली एक अलग समस्या है, और AP2 इसी के लिए मौजूद है। मैंने AP2 फील्ड गाइड में इसे अलग से लिखा है।

मॉडल गुणवत्ता। मध्यम एजेंटों की एक पूरी तरह से ऑर्केस्ट्रेटेड पाइपलाइन ऑडिट करने योग्य मध्यमता उत्पन्न करती है। प्रोटोकॉल लेयर विफलताओं को दृश्यमान और जिम्मेदार बनाती है, जो बहुत मायने रखता है, लेकिन जज-एजेंट पैटर्न और ईमानदार मूल्यांकन ही आउटपुट को विश्वसनीय बनाते हैं। दोनों के लिए बजट रखें।

लंबे समय तक चलने वाली स्थिति। प्रोटोकॉल परिभाषित करता है कि एक बहु-दिवसीय कार्य कैसे संचार करता है। यह आपकी कहानी के पक्ष को बनाए नहीं रखता है। कुछ टिकाऊ को यह याद रखना होगा कि आपने कार्य क्यों शुरू किया, उस पर क्या निर्भर करता है, और जब वह पूरा होता है या विफल होता है तो क्या करना है। एक वर्कफ़्लो इंजन लाएँ, या गलती से एक बनाने के लिए तैयार रहें।

एक-पैराग्राफ वर्ज़न

हर वेंडर एक एजेंट शिप करता है, इसलिए एंटरप्राइज़ मल्टी-एजेंट समस्या AI समस्या होने से पहले एक एकीकरण समस्या है, और एकीकरण समस्याओं को प्रोटोकॉल से हल किया जाता है। A2A (Google, अप्रैल 2025; Linux Foundation, जून 2025; विनिर्देश अब 1.0 पर) स्टैक की एजेंट-से-एजेंट लेयर है, साथ ही टूल के लिए MCP, इंटरफेस के लिए AG-UI, और भुगतान के लिए AP2 भी है: एजेंट /.well-known/agent-card.json पर हस्ताक्षरित Agent Cards प्रकाशित करते हैं, एक परिभाषित जीवनचक्र (submitted से completed, failed, canceled, या rejected, विराम के लिए input-required और auth-required के साथ) के माध्यम से कार्यों का आदान-प्रदान करते हैं, SSE पर प्रगति स्ट्रीम करते हैं, और वेबहुक के माध्यम से कई दिनों तक चलने वाले काम को संभालते हैं। उन एजेंटों को पीयर-टू-पीयर स्वार्म के बजाय एक टिकाऊ ऑर्केस्ट्रेटर के साथ जोड़ें, क्योंकि ऑडिटेबिलिटी, एटॉमिक कैंसिलेशन, और घटना की जांच ही वह है जिसके लिए विनियमित उद्योग वास्तव में भुगतान करते हैं; एजेंटों को डेटा-गोपनीयता सीमा के पार विभाजित करें (संवेदनशील डेटा स्थानीय, सार्वजनिक डेटा रिमोट, A2A सीम के रूप में); आत्मविश्वास-स्कोर वाले जज के साथ स्वायत्त आउटपुट को गेट करें जो ह्यूमन रिव्यू पर वापस आता है; और इस बात को स्पष्ट रूप से समझें कि प्रोटोकॉल आपको क्या हल करने के लिए छोड़ता है: साझा सिमेंटिक्स, एजेंट ट्रस्ट, संगठनात्मक सीमाओं के पार SLA, और वह टिकाऊ स्थिति जो याद रखती है कि तीन दिवसीय कार्य क्यों शुरू किया गया था।

संदर्भ

कार्य का अनुसरण करें

एक न्यूज़लेटर आ रहा है। तब तक, नए गाइड और एपिसोड पहले LinkedIn पर और RSS फ़ीड में प्रकाशित होंगे।

LinkedIn पर फॉलो करें rss
> esc