A2A
यह क्यों मायने रखता है
गहन अध्ययन
A2A जिस problem को address करता है वह सीधे कही जा सकती है: organizations अधिक agents deploy करती हैं तो उन्हें एक-दूसरे को work सौंपना होता है, और अभी हर pair को bespoke integration चाहिए। A2A उस handoff का common pattern define करता है। एक agent client की तरह task formulate करता है; दूसरा remote agent की तरह उसे execute करता है। दोनों ordinary web infrastructure — wire format के रूप में JSON-RPC 2.0 वाला HTTP और live updates के लिए Server-Sent Events — पर context, instructions तथा results exchange करते हैं, इसलिए adoption को new transport layer या shared runtime नहीं चाहिए। महत्वपूर्ण रूप से agents एक-दूसरे के लिए opaque रहते हैं: वे memory, weights या internal reasoning share करके नहीं बल्कि declared capabilities तथा task state से coordinate करते हैं।
Agent Cards और Capability Discovery
A2A में discovery agent card से काम करती है: छोटा JSON document, जिसे आम तौर पर agent के domain पर /.well-known/agent.json जैसे well-known path पर publish किया जाता है, और जो बताता है कि agent को कौन operate करता है, वह कौन-सी skills देता है, कौन-से input तथा output formats accept करता है और उसे कैसी authentication चाहिए। Client agent real work भेजने से पहले card fetch करता है, ताकि programmatically या LLM planner से तय कर सके कि यह remote agent job का candidate भी है या नहीं। व्यवहार में cards दो तरीकों से सामने आते हैं: directly, जब workflow partner agent का URL पहले जानता है, या curated registries से जिन्हें enterprise अपने approved एजेंट के लिए maintain करता है। Card model A2A को messaging convention से actual discovery layer बनाता है और यह उसी तरह है जैसे Autonomous Agent किसी दूसरे resource के बारे में reason करता है: description पढ़ें, goal से match करें, फिर act करें।
Tasks, Messages और Artifacts
A2A में work की unit task है और उसका explicit lifecycle है: submitted, working, input-required, completed, failed या canceled। Task के भीतर दोनों agents messages exchange करते हैं, और हर message raw text के बजाय parts से बना होता है — natural language के लिए text part, binary content के लिए file part या forms तथा price quotes जैसे structured JSON payloads के लिए data part। यह part model महत्वपूर्ण है क्योंकि real business workflows structured data पर चलते हैं, और A2A agents को हर चीज़ chat prose में डालने के बजाय स्ट्रक्चर्ड आउटपुट पर negotiate करने देता है। Task finish होने पर results artifacts के रूप में deliver होते हैं: named outputs, जो फिर parts से बने हैं और जिन्हें client agent स्वयं consume या बड़े एजेंटिक वर्कफ़्लो के next step को pass कर सकता है।
Long-running work में lifecycle states अपना मूल्य दिखाती हैं। Minutes या hours लेने वाला task Server-Sent Events पर client को progress events stream कर सकता है, या client connection open न रख सके तो webhook पर push notifications से updates deliver कर सकता है, जिससे disconnected consumers के लिए भी स्ट्रीमिंग viable रहती है। Input-required state subtle है: यह remote agent को task के बीच pause करके clarifying question पूछने देती है, और इसी तरह agents के बीच multi-turn negotiation task abstraction तोड़े बिना होती है।
A2A, MCP की जगह नहीं लेता
A2A के बारे में सबसे आम गलतफ़हमी है कि यह MCP से compete करता है। ऐसा नहीं है — दोनों protocols अलग layers पर operate करते हैं। MCP standardize करता है कि single agent tools तथा data sources से कैसे connect करता है: function call करना, resource पढ़ना या query चलाना। A2A standardize करता है कि दो independent agents कैसे coordinate करते हैं, जहाँ एक ऐसे peer को task delegate करता है जो पूरी तरह अलग team, vendor या trust domain का हो सकता है। Short form में MCP vertical interface, agent से tool, है जबकि A2A horizontal, agent से agent, है।
Realistic production setup same call chain में दोनों इस्तेमाल करता है। Orchestrator agent टूल यूज़ के लिए MCP इस्तेमाल कर सकता है — CRM, search index या code repository hit करना — और फिर A2A से specialist agent subcontract कर सकता है, जैसे legal department का contract-review agent, जो internally स्वयं MCP तथा Function Calling पर निर्भर हो। कोई protocol तय नहीं करता कि दूसरे agent के भीतर क्या होता है, और वह opacity deliberate design choice है: इससे organizations prompts, memory या proprietary reasoning expose किए बिना collaborate कर सकती हैं।
Governance, Ecosystem और खुले सवाल
Google ने A2A को 2025 में reference SDKs के साथ open specification के रूप में release किया, launch पर 50 से अधिक technology partners के support के साथ, जिनमें enterprise software vendors, LangChain जैसे frameworks और consultancies थे। फिर उसने project को Linux Foundation को donate कर दिया ताकि कोई single vendor उसके evolution को control न करे। यह governance move adoption के लिए महत्वपूर्ण है: protocols plumbing तभी बनते हैं जब competitors इस डर के बिना implement कर सकें कि rules उनके नीचे बदल जाएँगे। Specification, SDKs और sample agents सभी public हैं, तथा design नई चीज़ें invent करने के बजाय existing web standards जानबूझकर reuse करता है।
आगे की hard problems message formats से कम और trust से अधिक जुड़ी हैं। Agent card बताता है कि agent को कौन-सी authentication चाहिए, लेकिन protocol में कुछ नहीं बताता कि card पर विश्वास करना चाहिए या नहीं, जिससे cross-organization A2A traffic integration जितना ही AI सुरक्षा question बनता है। Prompt Injection concrete risk है: malicious या compromised remote agent task results में hostile instructions embed कर सकता है जिन्हें client agent का model आज्ञाकारी ढंग से पढ़ेगा। आज A2A पर Multi-Agent Systems बनाती teams आम तौर पर discovery को curated registries तक restrict करके, artifacts को model तक पहुँचने से पहले validate करके और हर remote agent को default रूप से untrusted मानकर इसका सामना करती हैं।