Payment-Enabled Agents: ACP, AP2, x402, اور Production میں MPP

چار protocols پر ایک کریش کورس جو OpenAI Agents SDK سسٹم کو پیسا کھرچ کرنے دیتا ہے: merchants پر, APIs کے مکابلے, انی agents کے ساتھ, کھلی ارتھویوستھا میں۔ ان انجینیروں کے لئے جنہوننے agents بھیج دیا ہے اور اب انہیں بھگتان کرنے کی ضرورت ہے۔

19 اودھارنائیں۔ 5 فیصلہ. 3 چتر. چار سیکھنے والے ٹریک۔ ریڈر ٹریک 2-3 گھنٹے کا شدھ پڑھنے والا ہے: چار-پرت stack, ہر protocol گہرائی میں, composition نیم, کوئی سیٹءاپ نہیں۔ شرءآتی, مدھیورتی اور انت ٹریک agents سے protocols تک وایرنگ کرنے, composition کو ٹکاؤ روپ سے چلانے اور identity, کھرچ اور ووادوں کو پربندھت کرنے میں ہاتھوں-ہاتھ گہرائی بڑھاتے ہیں۔ وے لگبھگ 1 دن, 2-3 دن اور 4-5 دن چلتے ہیں۔ ایماندار انمان: اسے پڑھنے کے لئے 2-3 گھنٹے, stack کو کام کرنے کی آدت بنانے کے لئے ایک ٹیم کو 4-5 دن۔حصہ 5 میں decision lab سے پہلے اپنا ٹریک چنیں۔

یہ ایک وچار ہے جس پر یہ پاٹھیکرم بنایا گیا ہے: چار protocols پرتدوندوی نہیں ہیں۔ وے پرتیں ہیں۔ ادھکانش لیکھ پوچھتے ہیں "ACP یا x402?" یہ سوال ایک غلطی ہے ک یہ protocols کس پرکار کی چیز ہیں۔ 2026 میں ایک واستوک سسٹم شپنگ انمیں سے کئی کا ایک ساتھ استعمال کرتا ہے, کیونک ہر agent-commerce سمسیا کا ایک الگ layer ہل کرتا ہے۔ ایک consumer shopping agent نپٹان میں commerce layer اور card rails پر ACP کا استعمال کرتا ہے۔ ایک API-paying agent دونوں میں x402 کا استعمال کرتا ہے, کیونک machine-to-machine micropayments کے لئے وے دو layers ایک میں ڈھہ جاتے ہیں۔ ایک enterprise procurement agent یہ سابت کرنے کے لئے AP2 mandates کا استعمال کرتا ہے ک مانو نے کھرچ کو ادھکرت کیا ہے, پھر نپٹان میں Stripe MPP۔ آپ استعمال کے ماملے کو پڑھنا اور سہی رچنا تک پہنچنا سیکھینگے۔

ید آپنے انی Agent Factory پاٹھیکرم نہیں لئے ہیں

اس کورس میں کچھ بھائی-بہنوں کے نام شامل ہیں: Build AI Agents کریش کورس (SDK مول باتیں), Production Worker کریش کورس (Inngest کے ساتھ agents کو ستھایی روپ سے چلانا), Eval-Driven Development کریش کورس, اور Choosing Agentic Architectures کریش کورس۔ آپ اسے انکے بنا بھی پڑھ سکتے ہیں۔ چار protocols, layering, SDK code, اور فیصلہ انشاسن سبھی اپنے آپ پر کھڑے ہیں۔ ایک چیز جو مدد کرتی ہے: حصہ 3 code مانتا ہے ک آپ Agent, Runner.run(), اور @function_tool پڑھ سکتے ہیں۔ ید وے نئے ہیں, تو پہلے Build AI Agents کریش کورس یا OpenAI Agents SDK docs پر جائیں, پھر واپس آئیں۔

ید آپ کسی بھن stack پر ہیں تو ہر protocol مانچتر کیا درشاتا ہے?

ید آپ OpenAI Agents SDK پلس Stripe, Coinbase, اور Cloudflare پر نہیں ہیں, تو یہ تالکا ہر حوالہ کاریانوین کو سامانی وکلپوں میں میپ کرتی ہے۔ protocol specs سٹیک-اجنییوادی ہیں; کیول primitive نام بھن ہیں۔

Protocol	بنیادی حوالہ SDK (2026)	سامانی وکلپ	لائسینس/شاسن
ACP (Agentic Commerce Protocol)	Stripe SDK (stripe) پلس OpenAI Agents SDK; PayPal ACP server tools; Worldpay کریڈینشیل	Adyen ACP, Shopify-نیٹو checkout API	Apache 2.0, OpenAI پلس Stripe اور github.com/agentic-commerce-protocol/agentic-commerce-protocol
AP2 (Agent Payments Protocol)	Google ADK پلس Python, TypeScript, Kotlin, Go میں حوالہ کاریانوین	LangGraph پلس کسٹم mandate signing, AutoGen پلس a2a-x402	Apache 2.0, Google پلس github.com/google-agentic-commerce/AP2 پر 60+ حصہیدار
x402	x402-client (Python), @x402/client (JS/TS), Coinbase Developer Platform, Cloudflare withX402Client, AgentPay MCP	پرتیکش EIP-3009 کاریانوین; Lobster.cash; Crossmint agent wallets	Apache 2.0, Coinbase دوارا بنایا, اب Linux Foundation کے x402 پھاؤنڈیشن کے انترگت
MPP (Machine Payments Protocol)	Stripe PaymentIntents پلس MPP ایکسٹینشن; Tempo blockchain SDK	پرتیکش Lightning Network; Tempo دیشی SDK	Apache 2.0, Stripe پلس Tempo; specs پر mpp.dev
A2A (Agent2Agent, layer AP2 وستارت)	Google ADK	کسٹم A2A کاریانوین	Apache 2.0, Google پلس Linux Foundation
MCP (Model Context Protocol, discovery layer)	Anthropic MCP servers اور گراہک; openai-agents MCP سمرتھن	LangChain MCP	MIT, Anthropic

تالکا کا استعمال کرنے کے لئے: جب پاٹھیکرم کہتا ہے "agent کے @function_tool کو Stripe ACP endpoint پر تار دیں" اور آپ Adyen پلس LangGraph پر ہیں, تو اسے "تار سمککش LangGraph" کے روپ میں پڑھیں tool سے Adyen ACP سماپن بند۔" ترک وہی ہے; نام بدل جاتے ہیں. آپکو کیول اس پاٹھیکرم کو پڑھنے کے لئے Stripe stack سیکھنے کی ضرورت نہیں ہے۔ primitives کو میپ کریں, framework کا پالن کریں, اسے اپنے سٹیک پر لاگو کریں۔

شبداولی

📖 اس پاٹھیکرم میں جن شبدوں کا استعمال کیا گیا ہے, انہیں پہلے پڑھیں اور باد میں دیکھیں

چار شیرشک protocols

• ACP (Agentic Commerce Protocol). consumer-shopping protocol, OpenAI اور Stripe دوارا بنایا۔ یہ نینترت کرتا ہے ک ایک agent کسی شخص کی اور سے واستوک merchant پر checkout کو کیسے پورا کرتا ہے۔ پاورس ChatGPT تورت checkout۔ ادھکتر commerce پرت پر رہتا ہے۔ Apache 2.0.
• AP2 (Agent Payments Protocol). authorization protocol, Google دوارا 60+ حصہیداروں کے ساتھ بنایا گیا۔ یہ signed "mandates" کا اتپادن کرتا ہے جو سابت کرتا ہے ک ایک انسان نے agent کو کھرچ کرنے کی انمت دی ہے۔ یہ سویں دھن کو ستھانانترت نہیں کرتا ہے; یہ سابت کرتا ہے ک کھرچ ادھکرت تھا۔ Apache 2.0.
• x402. HTTP-نیٹو settlement protocol, Coinbase دوارا بنایا اور اب Linux پھاؤنڈیشن دوارا شاست ہے۔ یہ اپریکت HTTP 402 "Payment Required" status code کو پنرجیوت کرتا ہے تاک ایک agent ایک API کال کے لئے ایک stablecoin کے ساتھ ایک سے دو سیکنڈ میں بھگتان کر سکے۔ Apache 2.0.
• MPP (Machine Payments Protocol). Stripe اور Tempo کا settlement protocol۔ اسکی چال "session" ہے: agent ایک کھرچ حد کو پورو-انمودت کرتا ہے, پھر اسکے وردھ کئی چھوٹے بھگتان سٹریم کرتا ہے۔ Multi-rail (stablecoin, Lightning, کارڈ)۔ Apache 2.0.

layers (پورے پاٹھیکرم کی ریڑھ)

• Discovery پرت۔ layer جہاں agent پاتا ہے ک وہ کیا کھرید سکتا ہے۔ MCP servers, A2A, agent directories, یا AI shopping ستہوں دوارا اتر دیا گیا۔ سوال: "کیا اپلبدھ ہے?"
• Authorization layer (Identity اور Authorization بھی)۔ layer جو پیسے کے ستھانانترن سے پہلے دو چیجیں سابت کرتا ہے: مانو نے اس کھرچ کی انمت دی, اور agent وہ ہے جو وہ ہونے کا داوا کرتا ہے۔ سوال: "کیا مجھے اسے کھرچ کرنے کی انمت ہے?"
• Commerce پرت۔ layer جو پوری کھریداری چلاتا ہے: cart, checkout, fulfillment, dispute, refund۔ سوال: "سنپورن purchase lifecycle کیا ہے?" سادے API کال کے لئے پوری طرح سے چھوڑ دیا گیا۔
• Settlement پرت۔ layer جہاں پیسا واستو میں ہاتھ بدلتا ہے۔ سوال: "پیسا واستو میں کہاں جاتا ہے?"
• Settlement rail (یا rail)۔ واستوک پائپ جسکے مادھیم سے پیسا یاترا کرتا ہے: کارڈ نیٹورک (Visa/Mastercard Stripe کے مادھیم سے), stablecoins ایک blockchain پر, بینک ہستانترن (ACH/SEPA), یا Lightning۔ "ایک rail چنیں" کا ارتھ ہے "چنیں ک پیسا کیسے چلتا ہے۔"

Authorization primitives

• Mandate (AP2). ایک signed ڈجٹل پرمان ک ایک مانو نے ایک وششٹ پرکار کے کھرچ کو ادھکرت کیا ہے۔ AP2 میں تین ہیں: ارادا, Cart, اور بھگتان (نیچے)۔ وے ملکر ایک شرنکھلا بناتے ہیں جسکا آپ باد میں آڈٹ کر سکتے ہیں۔
• آشی ادھدیش۔ agent شرو ہونے سے پہلے استعمالکرتا دوارا پہلا mandate, signed: کاری کے نیم۔ اداہرن: "120 ڈالر سے کم میں جوتے کھریدیں۔" یہ حد نردھارت کرتا ہے ک agent کو اندر رہنا چاہئے۔
• Cart ادھدیش۔ agent کے باد استعمالکرتا دوارا مدھی mandate, signed نے ایک وششٹ cart بنایا ہے: "ہاں, یہ سٹیک آئٹم اس سٹیک کیمت پر ہیں۔" ان پرواہوں میں استعمال کیا جاتا ہے جہاں کوئی مانو انمودن کے لئے موجود ہوتا ہے۔
• بھگتان ادھدیش۔ بھگتان کے وقت انتم mandate, signed (یا Intent Mandate کے وردھ سوتہ اتپن): "اس سٹیک بھگتان کو اس سٹیک ریل پر ادھکرت کریں۔"
• SPT (Shared Payment Token). ACP کا آدم. payment processor (Stripe) سے ایک بار کا ٹوکن ایک merchant, ایک راش حد اور ایک چھوٹی وقت ونڈو پر لاک ہو جاتا ہے۔ ید $50 کے لئے سویکرت ایک agent $1,000 کھرچ کرنے کا پریاس کرتا ہے, تو SPT وپھل ہو جاتا ہے۔ AP2 بھگتان ادھدیش کا کارڈ-ریل چچیرا بھائی۔
• اسویکاری۔ ایک signed رکارڈ جسے ہستاکشرکرتا باد میں بنانے سے انکار نہیں کر سکتا۔ AP2 mandate شرنکھلا non-repudiable ہے: "میں نے اسے کبھی ادھکرت نہیں کیا" استعمالکرتا کے سویں کے کرپٹوگرافک ہستاکشر کے وردھ نہیں ہے۔

Settlement اور crypto primitives

• stablecoin۔ ایک cryptocurrency ایک ستھر مولی پر آنکا جاتا ہے, آمتور پر ایک US dollar۔ Agents اسکا استعمال کریں تاک بھیجنے اور نپٹان کے بیچ "$0.05 بھگتان" پانچ سینٹ کا رہے۔
• USDC. وششٹ ڈالر-جڑی stablecoin ادھکانش x402 بھگتان کا استعمال کرتے ہیں۔ ایک USDC کا متلب ایک US dollar کے برابر ہے۔ سرکل دوارا جاری کیا گیا.
• HTTP 402 بھگتان آوشیک۔ ایک HTTP status code 1997 سے آرکشت ہے لیکن x402 دوارا اسے پنرجیوت کرنے تک اپریکت تھا۔ server "402" پلس بھگتان ضرورتؤں کا اتر دیتا ہے; client retries signed بھگتان پرمان کے ساتھ سنلگن ہے۔
• EIP-3009 (transferWithAuthorization). Ethereum مانک x402 پر بنایا گیا ہے۔ یہ ایک buyer کو ایک بھگتان off-chain پر ہستاکشر کرنے دیتا ہے جسے کوئی انی شخص on-chain سبمٹ کرتا ہے, اسلئے buyer کبھی بھی gas fees کا بھگتان نہیں کرتا ہے یا سیدھے blockchain کو نہیں چھوتا ہے۔
• Facilitator (x402)۔ ایک ویکلپک ترتیی پکش جو signature کی جانچ کرتا ہے اور merchant کے لئے بھگتان on-chain جما کرتا ہے, اسلئے merchant کو اپنا سویں کا blockchain پلنبنگ چلانے کی ضرورت نہیں ہے۔ Coinbase اور Cloudflare دونوں facilitator چلاتے ہیں۔
• CAIP-2. blockchain کو نام دینے کا ایک مانک تریکا تاک protocol chain-agnostic رہ سکے۔ x402 CAIP-2 پھارم میں چین لکھتا ہے۔
• EIP-155 / chain id۔ Ethereum-شیلی شرنکھلاؤں کے لئے CAIP-2 کے اندر ننبرنگ منصوبہ۔ eip155:8453 کا ارتھ ہے Base شرنکھلا; ننبر chain id ہے. (آپ x402 code میں eip155:8453 دیکھینگے; اسکا متلب صرف "بیس" ہے۔)
• Smart-contract wallet۔ ایک crypto wallet جسکے ویی نیم (پرت-لین-دین حد, دینک حد, پرت-پراپتکرتا حد) code دوارا blockchain پر ہی لاگو کئے جاتے ہیں۔ کیونک شرنکھلا انہیں لاگو کرتی ہے, بھلے ہی agent کا اپنا code کھراب ہو جائے, یہ حدئیں کایم رہتی ہیں۔
• MPP ستر۔ MPP کی signature چال۔ ہر ایک بھگتان کے لئے signing کے بجای, agent ایک کھرچ حد اور ایک وقت حد کے ساتھ ایک "session" کھولتا ہے, پھر اسکے بند ہونے تک کئی چھوٹے میٹر والے بھگتان سٹریم کرتا ہے۔ "agent کے لئے ایک پریپیڈ ٹیب" کے بارے میں سوچیں۔
• Sessions model (MPP). اپروکت پیٹرن کا سامانی نام: ایک حد اور اودھ کو پورو-ادھکرت کریں, پھر اسکے وردھ کئی چھوٹے شلک میٹر کریں۔ بار-بار کال آنے پر ہر micropayment سے سستا۔

Commerce اور دھن اودھارنائیں

• نپٹان۔ وہ کشن جب پیسا واستو میں buyer سے وکریتا کے پاس چلا جاتا ہے۔ settlement سے پہلے سب کچھ صرف کوریوگراپھی ہے; سودا تبھی پورا ہوتا ہے جب settlement پورا ہو جاتا ہے۔
• رکارڈ کا Merchant (MoR)۔ لین-دین کے لئے ویوسای کانونی روپ سے ہک پر ہے: یہ کر, disputes اور گراہک سہایتا کو سنبھالتا ہے۔ ACP میں merchant MoR رہتا ہے۔ سادے machine-to-machine x402 کال میں اکسر کوئی MoR نہیں ہوتا ہے۔
• chargeback۔ جب buyer کا بینک کارڈ سے بھگتان کو الٹ دیتا ہے, آمتور پر کسی وواد کے باد۔ Card rails سمرتھن chargebacks; شدھ x402 نہیں ہے۔ chargebacks کی ضرورت اکسر یہ تی کرتی ہے ک آپ کون سا protocol استعمال کرتے ہیں۔
• وواد۔ ایک buyer کی ایک آروپ کو اوپچارک چنوتی ("میں نے اسے ادھکرت نہیں کیا" / "آئٹم کبھی نہیں آیا")۔ الگ-الگ protocols disputes کو الگ-الگ ہل کرتے ہیں; وہ انتر اکسر protocol چننے پر مجبور کرتا ہے۔
• نشکریتا۔ ایک سنپت جہاں ایک ہی آپریشن کو دو بار کرنے کا پربھاو ایک بار کرنے کے سمان ہی ہوتا ہے۔ یہ ماینے رکھتا ہے کیونک سمان اوینٹ آئیڈی کے ساتھ Stripe retries webhooks; idempotency key کے بنا آپکا code refund یا دو بار چارج ہو سکتا ہے۔

agent stack اور نکٹورتی protocols

• Agent وانجی۔ کوئی بھی لیندین جہاں ایک سوایت AI agent buyer, seller, یا دونوں ہے, اس وقت کوئی مانو کلک کھرید نہیں کرتا ہے۔ "AI-اسسٹیڈ" shopping سے بھن جہاں ایک شخص ابھی بھی بٹن دباتا ہے۔
• OpenAI Agents SDK. Agent, Runner.run(), @function_tool اور guardrail کے ساتھ agent لوپ بنانے کے لئے Python/JavaScript toolkit۔ اس کورس میں یہ "یونورسل client" ہے: ہر بھگتان protocol ایک یا ادھک tools بن جاتا ہے جسے agent کال کر سکتا ہے۔
• MCP (Model Context Protocol). Anthropic کا tools اور agents کے حوالہ کو اجاگر کرنے کے لئے کھلا مانک۔ agent commerce میں یہ اکسر discovery layer: agents MCP server کے مادھیم سے خریدنے یوگی سیوائیں ڈھونڈھتا ہے۔ MIT لائسینس پراپت۔
• A2A (Agent2Agent). Google کا protocol agents کے لئے ایک دوسرے سے بات کرنے اور کھوجنے کے لئے۔ AP2 A2A کے شیرش پر بنایا گیا ہے: ایک mandate ایک A2A سندیش کے روپ میں یاترا کرتا ہے۔ Apache 2.0.
• UCP (Universal Commerce Protocol). Google کا commerce-layer protocol, ACP کا peer ہے, جو Google shopping surfaces (Gemini, Google AI Mode) کے around بنا ہے۔ Commerce layer پر یہ ACP سے compete کرتا ہے۔
• TAP (Trusted Agent Protocol). HTTP request ہیڈر کے اندر agent کے identity کو سابت کرنے کے لئے Visa اور Cloudflare کا protocol۔ یہ ستیاپت کرتا ہے ک agent کون ہے, ن ک اسے کتنا کھرچ کرنے کی انمت ہے, اسلئے یہ آمتور پر اسے بدلنے کے بجای کسی انی پرمانیکرن protocol میں جوڑتا ہے۔
• ERC-8004. agent identity اور پرتشٹھا کے لئے ایک on-chain مانک: agents کی ایک ساروجنک رجسٹری اور انکا لیندین اتہاس, اسلئے بنا کسی پورو سنبندھ والا agent کسی انی پر بھروسا کرنے سے پہلے اسکے ٹریک رکارڈ کی جانچ کر سکتا ہے۔
• tool_input_guardrail. ایک OpenAI Agents SDK guardrail جو tool نشپادت ہونے سے پہلے چلتا ہے اور کال کو اسویکار کر سکتا ہے۔ یہ کسی بھگتان کو ہونے سے پہلے روکنے کا SDK-دیشی تریکا ہے۔ اس پاٹھیکرم کی ریڑھ: یہ سات بھگتان tool میں دکھائی دیتا ہے۔ (اسکے وپریت output_guardrail, جو agent کے انتم اتر پر چلتا ہے, بھگتان روکنے کے لئے بہت دیر ہو چکی ہے۔)

پورواوشیکتائیں

آپکو اس پاٹھیکرم سے ادھکتم لابھ ملیگا ید آپ کے پاس:

1. Build AI Agents کریش کورس, یا سمککش SDK انبھو۔ protocol ایکیکرن SDK code کے روپ میں دکھائے جاتے ہیں, اسلئے آپکو Agent, Runner.run(), اور @function_tool کو آرام سے پڑھنے کی ضرورت ہے۔ Build AI Agents کریش کورس دیکھیں۔
2. Choosing Agentic Architectures کریش کورس, یا سمککش ڈزائن سینس۔ حصہ 5 میں "کون سا composition کس استعمال کے ماملے میں" framework اس پیٹرن-چین انشاسن پر آدھارت ہے۔ Choosing Agentic Architectures کریش کورس دیکھیں۔
3. بنیادی HTTP. Status codes, انرودھ/response چکر, ہیڈر۔ x402 وشیش روپ سے HTTP ستر پر کاری کرتا ہے۔
4. بنیادی بھگتان شبداولی۔ Merchant, settlement, dispute, chargeback۔ پاٹھیکرم agent-وششٹ حصہوں کی ویاکھیا کرتا ہے لیکن یہ مانتا ہے ک آپ جانتے ہیں ک "merchant آف رکارڈ" کیا ہے۔

آپکو blockchain یا smart-contract انبھو کی نہیں ضرورت ہے (پاٹھیکرم پالن کرنے کے لئے پریاپت x402 اور EIP-3009 سکھاتا ہے; کوئی Solidity نہیں), اور آپکو چار protocol میں سے کسی کے ساتھ پورو انبھو کی ضرورت نہیں ہے۔ وے سبھی بنیادی ماخذوں سے سکھائے گئے ہیں۔

چار learning tracks

یہ کورس چار گہرائیوں پر کام کرتا ہے۔حصہ 5 سے پہلے اپنا ٹریک چنیں۔

ٹریک	وقت	آپ کیا کروگے	کے لئے سرووتم
پاٹھک	2-3 گھنٹے	سبھی اودھارناؤں اور فیصلہوں کو پڑھیں; رننگ code چھوڑیں.	انجینیر فیصلہ لے رہے ہیں ک گہرا نویش کرنا ہے یا نہیں۔ PMs اور architects جنہیں وکریتا پرستاووں کا مولیانکن کرنے کے لئے framework کی ضرورت ہے۔
شرءآتی	~1 دن	ریڈر پلس x402 client اداہرن پلس ایک ACP پریکشن لیندین کو Stripe پریکشن موڈ میں چلائیں۔	agent commerce میں نئے انجینیر جو سبسے سرل protocol (x402) اور سبسے ادھک اتپادن کے لئے تییار (ACP) کے ساتھ ویاوہارک وقت چاہتے ہیں۔
مدھیورتی	2-3 دن	شرءآتی پلس ایک agent بنائیں جو ایک پرکار کے لیندین کے لئے ACP اور دوسرے کے لئے x402 کا استعمال کرتا ہے, ساتھ ہی وایر AP2 Intent Mandate چیک کا استعمال کرتا ہے۔	انجینیر ایک واستوک سسٹم کی شپنگ کر رہے ہیں جس میں compose ایکادھک protocol ہیں۔
انت	4-5 دن	انٹرمیڈئیٹ پلس composed سسٹم کو ٹکاؤ روپ سے چلائیں (Inngest envelope), تار spend limits اور مانو-انمودن دوار, trace, لاگت اور dispute metrics کو ماپیں, اور ایک پورن refund چکر کو سنبھالیں۔	production سسٹم کے لئے جمیدار انجینیر واستوک استعمالکرتاؤں کے لئے واستوک دھن لے جا رہے ہیں۔

ایک استعمالی self-check: "میرے من میں جو use case ہے, اسکے لئے value ship کرنے والا سبسے چھوٹا protocol composition کیا ہے?" اگر Part 4 کے باد اسکا جواب نہیں دے پا رہے ہیں, تو Part 4 پھر پڑھیں۔ اگر جواب دے پا رہے ہیں, تو آپکا track بس اس بات کا سوال ہے ک "smallest composition" سے "production-grade composition" تک کتنا آگے جانا چاہتے ہیں۔

چار-پرت stack

یہ وہ آریکھ ہے جس پر باکی سبھی چیزیں ٹکی ہوئی ہیں۔

ہر agent-commerce استعمال کا ماملا سبھی چار layers کو چھوتا ہے, لیکن ہر پر الگ-الگ استعمال کے ماملے compose الگ-الگ protocols ہوتے ہیں۔ ایک consumer shopping agent: discovery کے لئے MCP, authorization کے لئے ایک ACP shared payment token, commerce کے لئے ACP, نپٹان کے لئے card rails۔ ایک API-paying agent: discovery کے لئے ایک agent directory, authorization کے لئے ایک EIP-3009 signature, بلکہل بھی commerce layer نہیں, نپٹان کے لئے x402۔ ایک enterprise procurement agent: ایک A2A نردیشکا, ایک AP2 mandate, ACP یا commerce کے لئے UCP, نپٹان کے لئے Stripe MPP۔ نیم سرل ہے: پرت layer ایک protocol چنیں, اور استعمال کے ماملے کو ہر چین کو اچت ٹھہرانے دیں۔

حصہ 1: agent commerce کو نئے protocols کی ضرورت کیوں ہے

حصہ 1 کو ہلکے سے پڑھ رہے ہیں?

حصہ 1 میں چھہ نام (ACP, AP2, x402, MPP, MCP, A2A) اور تین layers تیج شامل ہیں۔ یہ جانبوجھکر کیا گیا ہے: یہ ہسا بریپھنگ ہے, گہرا گوتا نہیں۔ آپکو کم سے کم یہ رکھنے کی ضرورت ہے: ACP consumer shopping (Stripe پلس OpenAI) ہے, AP2 authorization mandates (Google پلس 60 حصہیدار) ہے۔x402 HTTP (Coinbase) پر per-request stablecoin بھگتان ہے, MPP session-based multi-rail بھگتان (Stripe پلس Tempo) ہے۔MCP اور A2A agents ایک-دوسرے کو ڈھونڈھنے اور بات کرنے کے طریقے ہیں, بھگتان protocol نہیں۔ ناموں کو ڈھیلے ڈھنگ سے پکڑیں. حصہ 2 گہرائی میں ہر پر لوٹتا ہے اور وے دوسرے پاس پر ٹکے رہیں گے۔

تصور 1: وہ دھارنا جو ٹوٹ گئی

ایک پنکت میں: بھگتان پرنالیوں نے مانا ک ایک انسان کھرید پر کلک کر رہا تھا, اور agents نے اس دھارنا کو ایک ساتھ تین تریکوں سے توڑ دیا۔

بھگتان پرنالیاں ایک شانت دھارنا پر بنائی گئی تھیں: ایک انسان کیبورڈ پر ہے, کھرید پر کلک کر رہا ہے۔ ہر سکرین, ہر دھوکھادھڑی جانچ, ہر dispute پرکریا, ہر سائنءاپ پھارم لوگوں کے لئے ڈزائن کیا گیا تھا۔ AI agents اس دھارنا کو ایک ہی وقت میں تین تریکوں سے توڑتا ہے۔

بریک 1: agents میں ایمیل پتے نہیں ہیں۔ Consumer بھگتان پرواہ کے لئے ایک کھاتا چاہئے۔ ایک account ایک ایمیل, ایک فون ننبر, اکسر ایک نام چاہتا ہے۔ ایک سوایت agent میں انمیں سے کچھ بھی نہیں ہے۔ انہیں نکلی بنائیں, اور آپنے ایک ایسی اکائی بنائی ہے جو دھوکھادھڑی کا پتا لگتے ہی KYC وپھل ہو جاتی ہے۔ سائنءاپ پرواہ میں ایک رشتے کے لئے آویدن کرنے والے مانو کو شامل کیا گیا ہے; agent کو کچھ اور چاہئے۔

بریک 2: agents پرت سیکنڈ ہجاروں بار کاری کرتا ہے۔ دھوکھادھڑی کا پتا لگانے کی در, ستھان اور پیٹرن کے آدھار پر اجیب رویہ کو چہنت کرتا ہے۔ ایک agent ایک منٹ میں 1,000 API کال کرنا بلکہل ایک کریڈینشیل-سٹپھنگ ہملے جیسا دکھتا ہے۔ agent کے لئے سامانی بات ایک انسان کے لئے الارم ہے, اور rails کو انسانوں کے لئے ٹیون کیا گیا ہے۔

بریک 3: agents پھون نہیں اٹھا سکتا۔ Dispute رزالیوشن مانتا ہے ک buyer تک پہنچا جا سکتا ہے: "کیا آپنے اسے ادھکرت کیا ہے?" کسی آروپ کو ادھکرت کرنے والا agent اتر نہیں دے سکتا ہے, اور اسکے پیچھے کے شخص کو یہ بھی پتا نہیں ہوگا ک آروپ لگا ہے۔ جب buyer ساپھٹوییر ہو تو Disputes کو ایک الگ model کی ضرورت ہوتی ہے۔

ہر بریک کو protocol ستر پر ٹھیک کرنے کی ضرورت ہے, UI پر پینٹ کے ایک کوٹ کی نہیں:

توڑنا	مانو-ریل سدھار کیا نہیں کر سکتا	agent-ریل پھکس آپکو کیا دیتا ہے
کوئی ایمیل یا account نہیں	agents کو پھرجی اکاؤنٹ بنانے کے لئے بادھی کریں	کرپٹوگرافک identity (TAP, ERC-8004) یا سکوپڈ ٹوکن (ACP SPT, AP2 Mandate)
اچ-آورت رویہ	کسی ہملے کی طرح لگنے والے ٹریفک کو روکیں	HTTP-مول per-request بھگتان (x402) یا pre-authorized sessions (MPP)
disputes کے لئے کوئی فون نہیں	ایمیل disputes agent نہیں پڑھ سکتا	non-repudiable آڈٹ ٹریل کے ساتھ جنادیش-آدھارت authorization (AP2)

"بس پرانے بھگتانوں کو بیہتر agent UX میں لپیٹیں" پتھ پہلے ہی وپھل ہو چکا ہے۔ 2024 اور 2025 میں کئی سٹارٹءاپس نے اسے آزمایا: agents کو بنی-بنائی پہچان کے ساتھ مانو جیسے کھاتے دیں۔ دھوکھادھڑی کا پتا چلنے سے وے پکڑے گئے, chargebacks ڈھیر ہو گئے, merchant رشتے ٹوٹ گئے۔ protocol-ستریی سدھار آوشیک سابت ہئے, ویکلپک نہیں۔ اسیلئے ACP, AP2, x402, اور MPP سبھی ایک ہی بارہ مہینوں کے بھیتر دکھائی دئے۔

اودھارنا 2: ایک protocol کیوں نہیں جیت سکتا

ایک پنکت میں: بریک چار الگ-الگ پددھاریوں کے ساتھ چار الگ-الگ layers پر ہوتے ہیں, اسلئے protocols نے کام کو ایک دوارا پورا نگلنے کے بجای layer دوارا وبھاجت کیا۔

ایک اچت سوال: ید سبھی چار protocols سمان تین بریک کو ٹھیک کرنے کے لئے آئے, تو انمیں سے ایک بھی کیوں نہیں جیتا? اتر سنرچناتمک ہے. بریک الگ-الگ layers پر ہوتے ہیں, اور ایک protocol جسنے ان سبھی کو ٹھیک کرنے کا پریاس کیا ہے, وہ کسی کے بھی اپنانے کے لئے بہت بڑا ہوگا۔

اس بارے میں سوچیں ک ایک ایکیکرت protocol کو کیا نردشٹ کرنا ہوگا:

1. agents اپلبدھ merchants اور سیواؤں کا پتا کیسے لگائیں۔ وہ discovery پرت ہے۔
2. agents کیسے سابت کریں ک وے کون ہیں اور ایک انسان نے کھرچ کو ادھکرت کیا ہے۔ وہ authorization پرت ہے۔
3. agents پوری کھریداری کیسے چلاتا ہے, disputes اور refunds شامل ہیں۔ وہ commerce پرت ہے۔
4. پارٹیوں کے بیچ پیسا واستو میں کیسے چلتا ہے? وہ settlement پرت ہے۔

ہر layer میں پہلے سے ہی مجبوت پدادھکاری ہیں۔ Discovery کھوج انجن اور API سے سنبندھت ہے۔ Identity OAuth اور پرمانپتر پرادھکاریوں سے سنبندھت ہے۔ Commerce Stripe, Adyen اور Shopify سے سنبندھت ہے۔ Settlement Visa, Mastercard, اور ACH, ساتھ ہی نئی crypto ریل سے سنبندھت ہے۔ ایک ایکیکرت protocol کو ہر layer پر ہر پددھاری کو اس پر سہمت ہونے کی ضرورت ہوگی۔ ایسا کبھی نہیں ہونے والا تھا.

اسکے بجای کیا ہءآ ک ہر protocol نے ایک layer کو چنا جہاں اسکے پرائےوجک کے پاس سبسے ادھک لابھ تھا:

Protocol	جہاں اسکے پرائےوجک کا اتولن ہے	layer یہ لیا
ACP	OpenAI shopping چینل (ChatGPT) کا مالک ہے; Stripe merchant ایکیکرن کا مالک ہے	Commerce, مانو-کھریدار-AI پرواہ کے لئے
AP2	Google میں Android wallets اور 60-ساجھیدار گٹھبندھن ہے	Authorization, mandates signed کریڈینشیل کے روپ میں
x402	Coinbase میں stablecoin بنیادی ڈھانچا ہے; Cloudflare میں HTTP کنارا ہے	Settlement, machine-to-machine micropayments کے لئے
MPP	Stripe میں merchant سنبندھ ہیں; Tempo میں blockchain ہے	Settlement, enterprise اور multi-rail پرواہ کے لئے

تو protocols layer کے اندر لڑائی ن کریں; وے ایک کو پربھاشت کرنے کے لئے پرتسپردھا کرتے ہیں۔ settlement پر, x402 اور MPP واستو میں پرتسپردھا کرتے ہیں, اور ادھکانش "x402 بنام MPP" ٹکڑے یاد کرتے ہیں ک یہ ایکماتر ستھان ہے جہاں وے واستو میں اوورلیپ ہوتے ہیں۔ commerce پر, ACP اور UCP پرتسپردھا کرتے ہیں۔ authorization پر, AP2, TAP, اور ERC-8004 پرتسپردھا کرتے ہیں۔

اسسے ہمیں ایک وچار ملتا ہے ک یہ پورا پاٹھیکرم اسی پر آدھارت ہے۔layer کے بھیتر, آپ ایک protocol چنتے ہیں۔ layers میں, آپ کئی compose ہیں۔ چار protocols کے بیچ چین کرنے کے لئے وکلپ نہیں ہیں; وے سٹیک کرنے کے لئے layers ہیں۔ ایک consumer shopping agent نپٹان پر commerce اور card rails پر ACP چلاتا ہے۔ ایک API-paying agent x402 کو settlement پر چلاتا ہے اور commerce کو پوری طرح سے چھوڑ دیتا ہے۔ ایک enterprise agent نپٹان پر AP2 mandates authorization اور MPP پر چلتا ہے۔ حصہ 5 میں decision tree اس layer کو پرت در پرت چلتا ہے۔ اسے تھامے رکھیں: اسکے باد کا ہر انحصہ اسے مانتا ہے۔

تصور 3: OpenAI Agents SDK ساروبھومک client کے روپ میں

ایک پنکت میں: آپ چار protocols چار الگ-الگ تریکوں سے بات نہیں کرتے ہیں; agent کالوں میں سے ہر ایک tool بن جاتا ہے, اور SDK ایکل client ہے جو ان سبھی کو جوڑتا ہے۔

ایک ویاوہارک سوال: چار layers پر چار protocols دئے گئے, ایک agent واستو میں انکا استعمال کیسے کرتا ہے? 2026 میں اتر یہ ہے ک agent کے framework ساروبھومک گراہک بن جاتا ہے۔ ہر protocol ایک SDK یا ایک HTTP endpoint کو اجاگر کرتا ہے, اور framework اسے ایک اپکرن کے روپ میں تار دیتا ہے۔ یہ OpenAI Agents SDK, LangGraph, AutoGen اور CrewAI کے لئے سمان روپ سے ستی ہے۔ ہم پورے وقت OpenAI Agents SDK کا استعمال کریں گے۔

SDK کے لئے, ہر protocol ایکیکرن ایک ہی آکار کا انسرن کرتا ہے: protocol کو ایک یا ادھک @function_tool functions میں لپیٹیں, انہیں Agent کو سونپیں, اور Runner.run کو لوپ چلانے دیں۔

note

نیچے دئے گئے stripe.PaymentTokens.create, X402Client(wallet=...), اور from ap2 import ... کال اداہرناتمک ہیں: وے protocol ایکیکرن کے آکار کو درشاتے ہیں۔ انکے چاروں اور Agent, Runner, اور @function_tool مچان واستوک ہے اور چلتا ہے۔ سٹینڈ-ان کیا ہے, اسکے لئے بلاک کے باد نوٹ دیکھیں۔

from agents import Agent, Runner, function_tool
import stripe  # for ACP/MPP
from x402_client import X402Client  # for x402
from ap2 import IntentMandate, CartMandate  # for AP2
from decimal import Decimal
from .models import PaymentToolResult, X402PaymentResult  # the shared result models

# Each protocol becomes one or more @function_tool decorated functions
@function_tool
async def acp_checkout(merchant_id: str, items: list, max_amount: Decimal) -> PaymentToolResult:
    """Complete an ACP checkout at a merchant with the given items."""
    # Mint a one-time payment token scoped to this merchant, then POST the order
    spt = stripe.PaymentTokens.create(
        amount=int(max_amount * 100),   # cents as int
        currency="usd",
        merchant_id=merchant_id,
        max_uses=1,
    )
    response = await acp_post(merchant_id, items, spt.token)
    return PaymentToolResult(
        status="success" if response.status == "confirmed" else "failed",
        details={"order_id": response.order_id, "merchant_status": response.status},
    )

@function_tool
async def x402_fetch(url: str, max_payment_usdc: Decimal) -> X402PaymentResult:
    """Fetch a URL that may require x402 payment up to max_payment_usdc."""
    client = X402Client(wallet=agent_wallet, max_per_request=max_payment_usdc)
    response = await client.get(url)
    return X402PaymentResult(
        content=response.content,
        amount_paid_usdc=response.amount_paid_usdc,
        tx_hash=response.payment_proof,
    )

# Compose the tools into an agent
shopping_agent = Agent(
    name="ShoppingAgent",
    instructions="Help the user find and purchase items. Use acp_checkout for retail goods, x402_fetch for paid APIs.",
    tools=[acp_checkout, x402_fetch],
    model="gpt-5.5",
)

# Run the agent. The SDK handles tool selection, the loop, and retries.
result = await Runner.run(shopping_agent, "Buy me a red t-shirt under $30")

یہاں کیا چلتا ہے اور کیا سٹینڈ-ان ہے: Agent, Runner.run, اور @function_tool وایرنگ واستوک SDK ہے اور لکھت روپ میں کام کرتی ہے۔ بھگتان گراہک سٹینڈ-ان ہیں۔ stripe.PaymentTokens.create ایک واستوک Stripe کال نہیں ہے (production ACP لائو Stripe ACP endpoints کے مادھیم سے ایکیکرت ہوتا ہے), اور سمردھ X402Client(wallet=..., max_per_request=...) کنسٹرکٹر بھی اداہرناتمک ہے۔ واستوک buyer-side پیکیج x402-client ہے, اور لائو کال کے لئے ایک وت پوشت account اور ایک واستوک 402 endpoint کی ضرورت ہوتی ہے, جو یہ کورس نہیں کرتا ہے۔ حصہ 3 ہر protocol کو ایک چلنے یوگی ماک بیکئینڈ دیتا ہے تاک آپ واستوک دھن کو ستھانانترت کئے بنا ہارنیس کاری کو شرو سے انت تک دیکھ سکیں۔

آکار سبھی چار protocol میں سمان ہے۔ SDK ساروبھومک client ہے; ہر protocol صرف ایک tool ہے, agent اسکے بارے میں بتاتا ہے اور جرورت پڑنے پر کال کرتا ہے۔ بھگتان کے لئے SDK سنرچنا کے تین حصہ ماینے رکھتے ہیں:

1. بھگتان پرناموں کے لئے ایک ٹائپ کیا گیا رٹرن مان۔ جب ایک بھگتان tool returns ایک Pydantic model ہوتا ہے, تو agent کے ریزنر کو سپشٹ پرکار کی جانکاری ملتی ہے ک کیا سپھل ہءآ, کیا وپھل ہءآ اور آگے کیا کرنا ہے۔ حصہ 3 ان ساجھا پرنام models کو ایک بار پربھاشت کرتا ہے۔
2. بھگتان حوالہ کے لئے Runner.run(..., context=...)۔ agent کو اکسر استعمالکرتا کے identity, کھرچ حد اور wallet ہینڈل کی ضرورت ہوتی ہے۔ انہیں نردیشوں میں بیک کرنے کے بجای SDK کے context پیرامیٹر سے گجاریں۔ context پرت-رن اور پرت-استعمالکرتا ہے۔
3. کھرچ حد کے لئے tool_input_guardrail۔ ایک tool input guardrail ہر tool کے نشپادت ہونے سے پہلے چلتا ہے اور کال کو اسویکار کر سکتا ہے۔ یہ کسی بھگتان کو ہونے سے پہلے روکنے کا SDK-مول تریکا ہے, باد میں نہیں۔ تصور 15 پورن تین-ستریی پرورتن پر چلتا ہے۔ agent-ستر output_guardrail اسکا سمادھان نہیں کرتا ہے, کیونک یہ agent کے انتم اتر پر سکری ہوتا ہے, کسی بھی بھگتان کے باد tool پہلے ہی چل چکا ہے۔

حصہ 2: چار layers گہرائی میں

آپ حصہ 1 میں چار layers سے ملے; یہاں ہر ایک کریب ہے۔ ہر layer ایک الگ سوال کا اتر دیتا ہے, اسکا اپنا پرتسپردھی protocols ہوتا ہے, اور ایک فیصلہ کو بادھی کرتا ہے: اس استعمال کے ماملے کے لئے, کون سا protocol اس layer کے لئے سبسے اپیکت ہے? حصہ 3 سے پہلے حصہ 2 پڑھیں۔ یہاں پرت-در-پرت فریمنگ وہ ہے جو حصہ 3 میں protocol وورن کو پرتدوندویوں کی سوچی کی طرح پڑھنے کے بجای سسنگت بناتی ہے۔

تصور 4: Layer 1, Discovery (agents کیسے کھوجیں ک وے کیا کھرید سکتے ہیں)

ایک پنکت میں: Discovery وہ جگہ ہے جہاں agent یہ پتا لگاتا ہے ک خریدنے کے لئے کیا اپلبدھ ہے, اور سہی تنتر اس بات پر منحصر کرتا ہے ک وے سیوائیں واستو میں کہاں رہتی ہیں۔

اسسے پہلے ک agent لیندین کر سکے, اسے یہ پتا لگانا ہوگا ک وہاں کیا ہے۔ ایک shopping agent کو merchants کی ضرورت ہوتی ہے جو اتپاد لے جائے۔ ایک API-paying agent کو یہ جاننا ہوگا ک کون سے endpoints کے پاس data ہے اور انکی کیمت کیا ہے۔ ایک procurement agent کو ایسے آپورتکرتاؤں کی ضرورت ہے جو اسکے انپالن نیموں کو پارت کرتے ہوں۔ Discovery اتر "کیا اپلبدھ ہے?"

2026 میں یہاں چار گنبھیر وکلپ پرتسپردھا کرتے ہیں:

Protocol	یہ کیسے کام کرتا ہے	کے لئے سرووتم
MCP (Anthropic)	Tool server کال کرنے یوگی functions کو اجاگر کرتے ہیں; agent کنیکٹ ہوتا ہے, tools کو سوچیبدھ کرتا ہے, اور انہیں کال کرتا ہے	ڈیولپر دوارا وایرڈ کی گئی وششٹ سیواؤں تک پروگرامیٹک پہنچ; اچ ماترا agent کاری; پرمکھ agent-toolینگ discovery layer
A2A (Google)	Agents وے جو پیشکش کرتے ہیں اسے مانک لپھاپھے میں پرکاشت کریں; انی agents انہیں کھوجیں	بہ-agent پارستھتکی تنتر جہاں agents کو سہکرمی agents کھوجنے کی ضرورت ہے; discovery layer AP2 وستارت ہے
Agent directories (agent.مارکیٹ, lobster.cash, ٹینزرو)	ساروجنک بازاروں کی سوچی سشلک APIs اور سیوائیں; agents query انہیں ایک کیٹلاگ کی طرح	runtime پر ترتیی-پکش سیوائیں کھوجی گئیں; agent commerce کے "ییلو پیج"۔
AI shopping surfaces (ChatGPT Instant Checkout, Google AI موڈ, والمارٹ-ان-چیٹGPT)	Consumer AI اتپاد discovery پلس ACP checkout اتپاد کے ساتھ بنایا	Consumer پرواہت ہوتا ہے جہاں استعمالکرتا AI سے بات کر رہا ہوتا ہے اور یہ اتپادوں کو انلائن پردرشت کرتا ہے

SDK میں MCP کے لئے پرتھم شرینی کا سمرتھن ہے: ایک MCP server کو کچھ پنکتیوں میں ایک agent پر تار دیں اور اسکے سبھی tools agent کے ترک کے لئے اپلبدھ ہو جاتے ہیں۔ گیر-MCP discovery کے لئے, اسے ایک سادھارن @function_tool کے روپ میں لپیٹیں جو queries نردیشکا اور سنرچت لسٹنگ لوٹاتا ہے۔

note

نیچے دی گئی MCPServerStreamableHttp وایرنگ واستوک اور آیات یوگی ہے۔ agent_market_client کال اداہرناتمک ہے: یہ ایک ڈایریکٹری client کے لئے ہے۔ @function_tool اور Agent مچان اصل ہے۔

from agents import Agent, function_tool
from agents.mcp import MCPServerStreamableHttp
from decimal import Decimal

# Wire an MCP discovery server: all its tools become available
research_mcp = MCPServerStreamableHttp(
    name="research-services",
    params={"url": "https://research-services.example.com/mcp"},
)

# Wire a non-MCP directory as a regular tool
@function_tool
async def search_agent_market(query: str, max_price_usdc: Decimal) -> list[dict]:
    """Search Agent.market for x402-paid services matching the query."""
    return await agent_market_client.search(query, max_price_usdc=max_price_usdc)

agent = Agent(
    name="ResearchAgent",
    instructions="Find and use research services. Prefer MCP-discovered tools; fall back to Agent.market for niche needs.",
    mcp_servers=[research_mcp],
    tools=[search_agent_market],
)

یہاں آپ جو چناو کر رہے ہیں وہ "MCP بنام A2A بنام نردیشکائیں" نہیں ہے۔ یہ ہے: میری agent کی سیوائیں واستو میں کہاں رہتی ہیں? اپنے سنگٹھن کے آنترک, MCP کا استعمال کریں۔ ساجھیدار agents کے نیٹورک پر, A2A کا استعمال کریں۔ ترتیی-پکش APIs جسے آپ runtime پر کھوجتے ہیں, نردیشکاؤں کا استعمال کریں۔ Consumer اتپاد, AI shopping ستہ (اور commerce layer پر ACP) کا استعمال کریں۔ یہ پرسپر اننی نہیں ہیں; ایک واستوک agent اکسر کئی کا استعمال کرتا ہے۔

تصور 5: Layer 2, Identity اور Authorization (agent کی انمت ہے)

ایک پنکت میں: Authorization وہ جگہ ہے جہاں agent سابت کرتا ہے ک مانو نے اس کھرچ کی انمت دی ہے اور agent وہ ہے جو وہ ہونے کا داوا کرتا ہے, کسی بھی پیسے کے ستھانانترن سے پہلے۔

اسسے پہلے ک پیسا چل سکے, دو چیجیں سچ ہونی چاہئے: agent وہ ہے جو وہ ہونے کا داوا کرتا ہے, اور مانو اس کھرچ کو ادھکرت کرتا ہے۔ وے الگ-الگ سمادھانوں والی الگ-الگ سمسیائیں ہیں, اور Layer 2 settlement ہونے سے پہلے دونوں کا سمادھان کر دیتا ہے۔ Layer 2 کو چھوڑیں اور آپکو دو ناکامیؤں میں سے ایک ملیگی: دھوکھادھڑی (کسی کا بھی agent کسی کا بھی پیسا کھرچ کر سکتا ہے) یا پکشاگھات (ہر لیندین کی پشٹ کے لئے کلک کرنے کے لئے ایک مانو کی ضرورت ہوتی ہے)۔

یہ 2026 میں سبسے ادھک ووادت layer ہے۔ چار وکلپ, چار درشن:

Protocol	یہ کیسے کام کرتا ہے	سبسے مجبوت جہاں
AP2 Mandates (Google)	Signed کریڈینشیل: Intent Mandate ("120 ڈالر سے کم میں جوتے کھریدیں"), Cart Mandate ("یہ cart, یہ کیمت"), Payment Mandate ("اس rail کو ادھکرت کریں")	آڈٹ-بھاری پرواہ جسکے لئے سہمت کے non-repudiable پرمان کی ضرورت ہوتی ہے; ملٹی-agent پرواہ وہاں ہوتا ہے جہاں merchant نے buyer کا agent پہلے کبھی نہیں دیکھا ہے
ACP SPT (OpenAI پلس Stripe)	Stripe ایک Shared Payment Token کو ایک merchant, راش اور وقت ونڈو تک سیمت کرتا ہے; agent اسے پرستت کرتا ہے; merchant ستیاپت کرتا ہے اور چارج کرتا ہے	Consumer shopping جہاں Stripe پروسیسر ہے اور card rails chargeback انشاسن رکھتا ہے
TAP (Visa پلس Cloudflare)	agent کے identity signature HTTP headers میں سواری کرتا ہے; merchants اسے Visa کی نردیشکا کے وردھ ستیاپت کریں	وشیش روپ سے Identity تصدیق (authorization نہیں); آمتور پر کسی انی پرمانیکرن protocol میں جوڑا جاتا ہے, اکیلے استعمال نہیں کیا جاتا ہے
ERC-8004 پلس on-chain پرتشٹھا	پچھلے سودوں سے پرتشٹھا سکور کے ساتھ, agent پہچان اور لیندین اتہاس کی ایک on-chain رجسٹری	بنا کسی پورو وشواس کے شدھ ملٹی-agent پرواہ; اچ-دانو B2B جہاں پرتشٹھا جانچنے لایک ہے

دو سوالوں Layer 2 کو اتر دینا ہوگا, اور ہر protocol انکا اتر کیسے دیتا ہے:

1. "کیا مانو نے اسے ادھکرت کیا?" AP2 پرتیایوجت کرنے سے پہلے استعمالکرتا signed کے ساتھ اتر دیتا ہے۔ ACP SPT Stripe کے ساتھ اتر دیتا ہے, جو استعمالکرتا دوارا account ستر پر ادھکرت ہونے کے باد ہی بنایا جاتا ہے۔ TAP اسکا اتر نہیں دیتا; یہ کیول پہچان ہے. ERC-8004, signed on-chain لیندین کے ساتھ اتر دیتا ہے۔
2. "کیا agent وہ ہے جو وہ ہونے کا داوا کرتا ہے?" AP2 signing کنجی کے ساتھ اتر دیتا ہے (کیول واستوک agent ہی ہستاکشر کر سکتا ہے)۔ ACP, SPT کے ویاپاری-کشیتر کے ساتھ اتر دیتا ہے (کیول ادھکرت merchant ہی اسے بھنا سکتا ہے)۔ TAP Visa کی نردیشکا لکءاپ کے ساتھ اتر دیتا ہے۔ ERC-8004 on-chain identity رکارڈ کے ساتھ اتر دیتا ہے۔

SDK آپکو دو ایکیکرن بند دیتا ہے: ایک tool input guardrail جو بھگتان tool سے پہلے چلتا ہے, اور run context جو پرت-استعمالکرتا ستھت کو دونوں میں لے جاتا ہے۔

note

نیچے دی گئی guardrail, @function_tool, اور Agent وایرنگ واستوک SDK ہے اور چلتی ہے (وشیشتا پتھ data.context.tool_arguments اور data.context.context کی پشٹ ستھاپت SDK کے وردھ کی گئی ہے)۔ tool کے اندر stripe.PaymentTokens.create کال اداہرناتمک ہے; production ACP لائو Stripe ACP endpoint کا استعمال کرتا ہے۔

from agents import Agent, function_tool, RunContextWrapper
from agents.tool_guardrails import (
    tool_input_guardrail,
    ToolInputGuardrailData,
    ToolGuardrailFunctionOutput,
)
from decimal import Decimal
import json
import stripe

# Pattern 1: a tool input guardrail. Runs BEFORE the payment tool executes.
# This is the SDK-native way to block a payment before it happens.
@tool_input_guardrail
def block_over_user_cap(data: ToolInputGuardrailData) -> ToolGuardrailFunctionOutput:
    """Reject any payment tool call where the request would exceed the user's per-run cap."""
    args = json.loads(data.context.tool_arguments or "{}")          # raw JSON args -> dict
    requested = Decimal(str(args.get("max_amount_usd", 0)))
    ctx = data.context.context                                       # the run context (a dict)
    user_cap = Decimal(str(ctx["user_session"].per_run_spend_cap_usd))
    run_spent = Decimal(str(ctx.get("run_spend_usd", 0)))
    if run_spent + requested > user_cap:
        return ToolGuardrailFunctionOutput.reject_content(
            f"Refusing payment tool: would spend ${run_spent + requested}, exceeds run cap ${user_cap}"
        )
    return ToolGuardrailFunctionOutput.allow()

# Pattern 2: the payment tool itself, guarded at the function-tool level
@function_tool(tool_input_guardrails=[block_over_user_cap])
async def purchase_with_acp(
    ctx: RunContextWrapper,
    merchant_id: str,
    items: list,
    max_amount_usd: Decimal,
) -> PaymentToolResult:
    """Use ACP to buy items from the merchant up to max_amount_usd.
    The guardrail has already verified spend is within bounds before we reach here."""
    user_session = ctx.context["user_session"]
    spt = stripe.PaymentTokens.create(
        amount=int(max_amount_usd * 100),   # Stripe expects cents as int
        currency="usd",
        merchant_id=merchant_id,
        user_session_id=user_session.id,
        max_uses=1,
    )
    response = await acp_post(merchant_id, items, spt.token)
    return PaymentToolResult(
        status="success" if response.status == "confirmed" else "failed",
        details={"order_id": response.order_id, "merchant_status": response.status},
    )

agent = Agent(
    name="ShoppingAgent",
    instructions="Help the user shop. Always verify authorization before any purchase.",
    tools=[purchase_with_acp],
    # No output_guardrails for spend control. Those run on the agent's FINAL output,
    # not on individual tool calls. See Concept 15 for the full three-level enforcement.
)

جو guardrail بھگتان روک دیتا ہے

SDK میں تین guardrail پرکار ہیں اور وے الگ-الگ کشنوں میں پھایر کرتے ہیں۔ input_guardrail پہلے agent کے پرارنبھک انپٹ پر چلتا ہے۔ output_guardrail استعمالکرتا کے لئے انتم agent کے response پر چلتا ہے۔ tool_input_guardrail اور tool_output_guardrail ہر function-tool کال پر, اسکے نشپادت ہونے سے پہلے اور باد میں چلتے ہیں۔ بھگتان سرکشا کے لئے آپکو tool input guardrail کی ضرورت ہے: یہ بھگتان tool چلنے سے پہلے سکری ہو جاتا ہے اور کال کو اسویکار کر سکتا ہے۔ بھگتان روکنے کے لئے ایک output guardrail بہت دیر سے چالو ہوتا ہے; یہ انتم اتر کو ساپھ کرنے کے لئے استعمالی ہے (مان لیجئے, سنویدنشیل data کو سنشودھت کرنا), کسی tool کو اوردھ کرنے کے لئے نہیں۔ تصور 15 اس پر لوٹتی ہے; یہ سبسے آم غلطی ہے۔

یہاں آپ جو چناو کرتے ہیں وہ آپ کے وشواس model پر منحصر کرتا ہے۔ ید استعمالکرتا آپ کے ایپ میں signed ہے اور آپ Stripe کے مادھیم سے SPTs ڈھال سکتے ہیں, تو ACP آپکو سبسے ادھک اتپادن-تییار کہانی دیتا ہے۔ ید آپکو non-repudiable آڈٹ ٹریلس کی ضرورت ہے, جیسا ک ونیمت ادیوگوں میں ہوتا ہے یا B2B procurement, AP2 mandates پھٹ بیٹھتا ہے۔ ید آپکو authorization سے الگ کرپٹوگرافک identity کی ضرورت ہے, تو TAP جوڑیں۔ بنا کسی ساجھا وشواس والی شدھ ملٹی-agent سیٹنگ میں, ERC-8004 اس کمی کو پورا کرتا ہے۔ یہ ونمیی نہیں ہیں.

اودھارنا 6: Layer 3, Commerce (پورن purchase lifecycle)

ایک پنکت میں: Commerce واستوک کھریداری میں وہ سب کچھ ہے جو authorization یا settlement نہیں ہے: cart, آرڈر, fulfillment, dispute, refund, اور ایک سادا API کال اسے پوری طرح سے چھوڑ دیتا ہے۔

Authorization اور settlement ملکر "انمت کے ساتھ پیسے کی آواجاہی" کو کور کرتے ہیں۔ Commerce کھریداری میں باکی سب کچھ شامل کرتا ہے: سنرچت cart, آرڈر پشٹکرن, fulfillment ٹریکنگ, dispute رزالیوشن, refunds, chargebacks, رٹرن۔ یہ layer ہے جو checkout کو دھن ہستانترن سے الگ کرتا ہے۔ ایک سادے machine-to-machine API کال کے لئے commerce layer کی ضرورت نہیں ہے; یہ صرف ایک API کال ہے۔ consumer کھریداری کے لئے سپشٹ روپ سے ایک کی ضرورت ہوتی ہے۔

تین ارتھپورن بھن وکلپ:

Protocol	یہ کیا کرتا ہے	کے لئے سرووتم
ACP (OpenAI پلس Stripe)	ایک سنرچت پرواہ: cart پراروپ, آرڈر پشٹکرن, fulfillment ستھت, dispute وردھ, refund۔ merchant رکارڈ کا merchant بنا ہءآ ہے۔	Consumer shopping: retail مال, سدسیتا, بھوتک پورت۔ پاورس ChatGPT تورت checkout۔
UCP (Google)	ایک سمان جیونچکر, Google کی shopping ستہوں (متھن, Google AI موڈ) اور Google پے کے آسپاس بنایا گیا ہے	Merchants پر Google Shopping; agents Google AI ستہوں پر
ڈایریکٹ API (machine-to-machine)	کوئی commerce protocol بلکہل نہیں, بس ایک HTTP API۔ x402 یا MPP کے مادھیم سے بھگتان۔ کوئی cart نہیں, کوئی disputes نہیں, کوئی refund نہیں۔	API پہنچ, گننا, data فیڈ: کھریداری جہاں کھریدی گئی چیز ایک سٹیٹلیس API response ہے

تو ACP اور UCP پرتسپردھا کرتے ہیں; "پرتیکش API" اس layer کی انپستھت ہے, کوئی تیسرا پرتیوگی نہیں ہے, اور یہ اکسر شونی کے بگل میں کھشی سے بیٹھتا ہے۔ ایک consumer پلیٹفارم ACP یا UCP (یا دونوں, ید یہ ChatGPT اور جیمنی تک پھیلا ہے) چنتا ہے۔ ایک API marketplace اس layer کو بلکہل بھی نہیں چنتا ہے, کیونک اسکی کھریداری کو پربندھت کرنے کے لئے کوئی جیونچکر نہیں ہے۔

ادھکانش انجینیر جس ہسے کو کم آنکتے ہیں وہ ہے refunds اور وواد۔ جو گراہک غلط آکار کی ٹی-شرٹ کا آرڈر دیتا ہے, وہ اسے واپس بھیجنے کی اپیکشا کرتا ہے۔ commerce protocol کو یہ بتانا ہوگا ک واپسی کیسے شرو ہوتی ہے, agent اسکے بارے میں کیسے سنتا ہے, اور refund نپٹان کے مادھیم سے واپس کیسے پرواہت ہوتا ہے۔ merchant کو رکارڈ کے merchant کے روپ میں رکھنے سے ACP کو یہ ادھکار ملتا ہے: موجودا dispute مشینری (Stripe کا chargeback پرواہ, کھدرا وکریتا کی واپسی نیت) بس کام کرتی ہے۔ ڈایریکٹ-API درشٹکون اسے اندیکھا کرنے سے غلط ہو جاتا ہے۔ اکسر کوئی refund پتھ نہیں ہوتا ہے, جو $0.0001 API کال کے لئے ٹھیک ہے اور $500 API کریڈٹ کے لئے غلط ہے۔

Commerce پرواہ کو آمتور پر انکرم میں کام کرنے والے کئی tools کی ضرورت ہوتی ہے:

note

نیچے دئے گئے acp_client کال اداہرناتمک ہیں; وے ACP commerce بیکئینڈ کے لئے کھڑے ہیں۔ Pydantic models, @function_tool, اور Agent وایرنگ اصل ہے۔

from agents import Agent, function_tool
from pydantic import BaseModel
from decimal import Decimal

class CartItem(BaseModel):
    sku: str
    quantity: int
    unit_price: Decimal

class OrderResult(BaseModel):
    order_id: str
    status: str  # "confirmed", "fulfilled", "shipped", "delivered"
    tracking_url: str | None = None
    estimated_arrival: str | None = None

@function_tool
async def acp_create_cart(merchant_id: str, items: list[CartItem]) -> PaymentToolResult:
    """Create a cart at an ACP merchant. Does NOT charge yet."""
    cart = await acp_client.cart.create(merchant_id=merchant_id, items=items)
    return PaymentToolResult(
        status="success",
        details={"cart_id": cart.id, "merchant_id": merchant_id, "item_count": len(items)},
    )

@function_tool
async def acp_checkout(cart_id: str, spt_token: str) -> OrderResult:
    """Complete the checkout for a previously-created cart."""
    return await acp_client.checkout.complete(cart_id=cart_id, spt_token=spt_token)

@function_tool
async def acp_check_order_status(order_id: str) -> OrderResult:
    """Get the current status of an order. The agent calls this to follow up."""
    return await acp_client.order.status(order_id=order_id)

@function_tool
async def acp_initiate_refund(order_id: str, reason: str) -> RefundResult:
    """Start a refund for an order. Returns refund_id for follow-up."""
    response = await acp_client.refund.create(order_id=order_id, reason=reason)
    return RefundResult(
        refund_id=response.refund_id,
        order_id=order_id,
        status=response.status,
        amount_refunded_usd=response.amount_refunded_usd,
    )

shopping_agent = Agent(
    name="ShoppingAgent",
    instructions="Help the user shop. Create the cart first, confirm items with the user, then check out. Handle refund requests with an ACP refund.",
    tools=[acp_create_cart, acp_checkout, acp_check_order_status, acp_initiate_refund],
)

یہاں پوچھنے یوگی سوال یہ ہے ک کیا آپ کے استعمال کے ماملے میں commerce جیونچکر کی ضرورت ہے۔ ید ایسا ہوتا ہے (cart, refund, dispute), ChatGPT پہنچ کے لئے ACP یا Google پہنچ کے لئے UCP چنیں, یا دونوں۔ ید ایسا نہیں ہوتا ہے, تو اس layer کو چھوڑیں اور سیدھے authorization سے نپٹان پر جائیں۔ اسے غلط کرنے کے دو طریقے ہیں: ایک اپبھوکتا-وانجی protocol کو machine-to-machine کال پر مجبور کرنا (بہت ادھک), یا واستوک consumer کھریداری پر commerce کو چھوڑنا اور پھر باد میں بری طرح سے disputes کو پھر سے لاگو کرنا (بہت کم)۔

اودھارنا 7: Layer 4, Settlement (پیسا واستو میں چلتا ہے)

ایک پنکت میں: Settlement وہ جگہ ہے جہاں ڈالر واستو میں ہراست میں بدلاو کرتے ہیں, اور چین جیاداتر لیندین کے ارتھشاستر کے بارے میں ہوتا ہے۔

مولی کو buyer سے وکریتا تک لے جائیں۔ اس layer سے اوپر کی ہر چیز کوریوگراپھی ہے; settlement وہ جگہ ہے جہاں ڈالر (یا stablecoins, یا جو بھی اکائی ہے) واستو میں ہاتھ بدلتے ہیں۔ agent settlement پورا ہونے کے باد ہی لیندین پورا کرتا ہے۔

چار گنبھیر وکلپ, ہر کا اپنا ارتھشاستر اور حدئیں ہیں:

Protocol	یہ کیسے کام کرتا ہے	ارتھشاستر	کے لئے سرووتم
x402	HTTP-مول; EIP-3009 کے ساتھ Base/Solana/EVM, signed پر stablecoin ستھانانترن کے مادھیم سے ویوستھت ہوتا ہے	سب-سینٹ گیس, 1-2 سیکنڈ انتمتا, کوئی protocol شلک نہیں	Machine-to-machine micropayments; اچ-آورت, کم-مولی (API پہنچ, پرت-کال بلنگ)
MPP	Sessions: agent ایک حد اور اودھ کو پورو-ادھکرت کرتا ہے, پھر میٹرڈ بھگتان سٹریم کرتا ہے۔ Multi-rail (stablecoin Tempo پر, Lightning, کارڈ)	card rails پر Stripe شلک; stablecoin پر لگبھگ شونی; سدسیتا-انکول	Enterprise اور multi-rail پرواہ; آورتی سدسیتائیں; ایک envelope میں فئیٹ اور crypto دونوں کی ضرورت والے ماملے
Card rails (Stripe/Adyen/Worldpay)	Visa, Mastercard, ایمیکس Stripe کے مادھیم سے; agent ایک SPT (ACP) یا Payment Mandate (AP2) پرستت کرتا ہے; پروسیسر کارڈ کو چارج کرتا ہے	کارڈ کے لئے لگبھگ 2.9% پلس $0.30; ستھاپت dispute مشینری	Consumer پرواہ; chargeback ایکسپوزر کے ساتھ لیندین; انتراشٹریی کارڈ سویکرت
بینک ستھانانترن / Lightning	ACH, SEPA, بٹکائن Lightning	ACH ~$0.25 نشچت; بجلی اپکیندر; SEPA ~€0.20	اچ-مولی پرواہ جہاں 2.9% کارڈ شلک نکسان پہنچاتا ہے; Lightning کے مادھیم سے حد پار micropayments

settlement کا چناو ادھکتر پیسے کے بارے میں ہے۔ اپ-ڈالر بھگتان x402 پر جاتا ہے, جہاں stablecoin گیس اپ-سینٹ ہے۔ Consumer لگبھگ $1,000 تک کی کھریداری ACP کے مادھیم سے card rails پر جاتی ہے, جہاں chargeback سرکشا 2.9% کے لایک ہے۔ آورتی سدسیتائیں MPP ستروں میں جاتی ہیں۔ بڑے B2B ستھانانترن bank rails یا Lightning پر جاتے ہیں۔ اور اپروکت layers آمتور پر چننے کے لئے بادھی کرتا ہے: ACP پر commerce کا ادھکتر ارتھ card rails پر settlement ہے; discovery پر x402-بھگتان کئے گئے MCP server کا ادھکتر ارتھ نپٹان کے وقت x402 ہوتا ہے۔

ہیڈلائن-ننبر ٹریپ پر نزر رکھیں۔ x402 کے لین-دین کی ماترا یا MPP کی ایکیکرن گننا کا ہوالا دینے والے ٹکڑے گمراہ کر سکتے ہیں۔ سہی سوال یہ نہیں ہے ک "کسکا آیتن سبسے ادھک ہے?" یہ "اس لین-دین کے ارتھشاستر میں کون سا پھٹ بیٹھتا ہے?" card rails پر سیٹل کی گئی $0.001 API کال کی پھیس کال سے ادھک ہے۔ x402 stablecoin پر تی کیا گیا $5,000 procurement chargeback سرکشا کو سماپت کر دیتا ہے جو ایک کارڈ آپکو دیتا ہے۔

Settlement آمتور پر اچ-پرت tool کے سائڈ اپھیکٹ کے روپ میں سکری ہوتا ہے: agent شاید ہی کبھی settle_payment() کو سیدھے کال کرتا ہے; settlement acp_checkout() یا x402_fetch() کے اندر ہوتا ہے۔ لیکن spend limits SDK ستر پر ابھی بھی ماینے رکھتا ہے:

note

نیچے دیا گیا x402_client.get کال اداہرناتمک ہے; اسکا متلب buyer-side x402 فیچ ہے۔ @function_tool وایرنگ اور کھرچ چیک واستوک Python ہیں۔

from agents import function_tool, RunContextWrapper
from decimal import Decimal
from .models import X402PaymentResult, PaymentToolResult

@function_tool
async def x402_fetch(
    ctx: RunContextWrapper,
    url: str,
    max_payment_usdc: Decimal,
) -> X402PaymentResult | PaymentToolResult:
    """Fetch a paid URL via x402. Settlement is automatic if cost <= max_payment_usdc."""
    # Check the SDK-level spend tracker before initiating the request
    spent_so_far = Decimal(str(ctx.context.get("session_x402_spend_usdc", Decimal(0))))
    session_cap = ctx.context["user_session"].x402_session_cap_usdc
    if spent_so_far + max_payment_usdc > session_cap:
        return PaymentToolResult(
            status="rejected",
            error=f"Would exceed session spend cap (already spent ${spent_so_far})",
        )

    # Initiate the x402 flow: the server returns 402, the agent retries with a signed payment
    response = await x402_client.get(url, max_payment_usdc=max_payment_usdc)

    # Update the spend tracker, kept in ctx.context for cross-tool visibility
    ctx.context["session_x402_spend_usdc"] = spent_so_far + response.amount_paid_usdc
    return X402PaymentResult(
        content=response.content,
        amount_paid_usdc=response.amount_paid_usdc,
        tx_hash=response.tx_hash,
    )

ایک بات سپشٹ ہونی چاہئے: if spent_so_far + ... چیک tool باڈی کے اندر ایک ساپھٹ گارڈ ہے, جو تیج, میتریپورن ناکامی کے لئے استعمالی ہے لیکن واستوک سرکشا کے لئے نہیں۔ جو سرکشا واستو میں آپکی سرکشا کرتی ہے وہ agent کے smart-contract wallet ہے۔ بھلے ہی آپنے ان-tool چیک ہٹا دیا ہو, پھر بھی کانسیپٹ 15 سے wallet کیپس on-chain ٹرانسپھر کو اسویکار کر دینگے۔ tool کا چیک UX کے لئے ہے; wallet کیپ سرکشا ہیں۔

یہاں کدم rail کو چننا ہے جو لیندین کے ارتھشاستر سے میل کھاتا ہے, پھر پشٹ کریں ک یہ آپکی commerce پسند کے ساتھ سنگت ہے۔ اپ-ڈالر machine-to-machine x402 پر جاتا ہے۔ Consumer کھریداری ACP کے مادھیم سے card rails پر جاتی ہے۔ Enterprise سدسیتائیں MPP پر جاتی ہیں۔ settlement کو الگ سے ن چنیں; اسے composed سٹیک کے نچلے حصہ کے روپ میں چنیں۔

---

حصہ 3: گہرائی میں چار protocols, OpenAI Agents SDK ایکیکرن کے ساتھ

حصہ 1 اور 2 نے فریمنگ سیٹ کی: چار layers, کئی protocols پرت layer, یونورسل client کے روپ میں SDK۔ حصہ 3 چار شیرشکوں protocols میں سے ہر کو کریب سے دکھاتا ہے۔ ہر کے لئے آپکو وہ ملیگا جو وہ ہے, اسکی کنجی primitives, SDK ایکیکرن code, اور ٹیمیں اسے کیسے تینات اور چلاتی ہیں, اس پر سنکشپت نوٹس۔

انہیں چار سمانانتر گہرے گوتا کے روپ میں پڑھیں۔ ہر protocol کا آکار سمان ہے, اسلئے آپ انکی ساتھ-ساتھ تلنا کر سکتے ہیں۔

اس آریکھ میں پیٹرن میں سے ایک کے مادھیم سے SDK میں ہر protocol اودھارنا 8 سے 11 تاروں تک۔ نیچے تین-ستریی spend-limit stack حصہ 6 میں اودھارنا 15 کا پورواولوکن کرتا ہے۔ پڑھتے وقت اسے اپنی آنکھ کے کونے میں رکھیں: یہ جو سرکشا انشاسن دکھاتا ہے وہ اس code کو ایسی چیز میں بدل دیتا ہے جسے آپ واستو میں تینات کر سکتے ہیں۔

🧰 Pydantic انبندھ layer کے روپ میں: ایک بار پڑھیں, نیچے دئے گئے ہر protocol پر لاگو ہوتا ہے

حصہ 3 میں ہر code نمونا Pydantic models کا استعمال کرتا ہے, ن ک سادے Python نردیشوں کا, protocol payloads, tool returns, FastAPI request اور response باڈی, اور Inngest اوینٹ پیلوڈ۔ یہ وہ ہسا ہے جسے آپ چھوڑ نہیں سکتے۔ یہ وہی ہے جو پورے سسٹم کو ایک ساتھ رکھتا ہے۔

ایک وششٹ agent-وانجی پرواہ میں چار حدئیں پار ہو جاتی ہیں:

1. SDK کا @function_tool, agent کے ریزنر کو ایک مان لوٹاتا ہے۔
2. وہ مان تار کو protocol endpoint (ACP, AP2, x402, MPP) تک پار کرتا ہے۔
3. protocol ایک response لوٹاتا ہے جو پیچھے کی اور جاتا ہے۔
4. کبھی-کبھی webhook باد میں آتا ہے اور FastAPI ہینڈلر میں چلا جاتا ہے۔

ہر حد پر, ایک الکھت آدیش چپچاپ فیلڈ کھو دیتا ہے, جبردستی چھوڑ دیتا ہے, اور غلط آکار بھیج دیتا ہے۔ Pydantic models حد پر سبھی چار پرکار کی ناکامیؤں کو پکڑتا ہے, ان ترٹیوں کے ساتھ جو سٹیک کشیتر کی اور اشارا کرتی ہیں۔

یہاں وہ پیٹرن ہے جو نیچے دی گئی ہر اودھارنا میں دوہرائےا جاتا ہے:

from pydantic import BaseModel, Field
from decimal import Decimal
from typing import Literal
from agents import function_tool, RunContextWrapper

class CartItem(BaseModel):
    sku: str
    quantity: int = Field(ge=1)
    unit_price_usd: Decimal

class CheckoutRequest(BaseModel):
    merchant_id: str
    items: list[CartItem]
    max_total_usd: Decimal = Field(gt=0)

class CheckoutResult(BaseModel):
    order_id: str
    status: Literal["confirmed", "failed", "pending_user_confirmation"]
    total_charged_usd: Decimal
    estimated_delivery: str | None = None

@function_tool
async def acp_checkout(ctx: RunContextWrapper, request: CheckoutRequest) -> CheckoutResult:
    # Pydantic has already validated the request shape before this line runs.
    # Returning a CheckoutResult means the agent's reasoner gets typed feedback.
    ...

اس پیمانے پر اسکے مہتو کے تین ٹھوس کارن:

1. ترککرتا رٹرن پرکار کو پھیڈبیک کے روپ میں استعمال کرتا ہے۔ جب acp_checkout ایک ٹائپ کیا ہءآ CheckoutResult لوٹاتا ہے, تو agent کے اگلے ترک چرن کو ساپھ فیلڈ نام اور پرکار ملتے ہیں, ن ک ایک کٹھور نردیش۔ اپکرن-چین سٹیکتا ماپنیی روپ سے بڑھ جاتی ہے۔
2. FastAPI مول روپ سے Pydantic کا استعمال کرتا ہے۔ Stripe webhooks, AP2 mandate callbacks, اور MPP session ایوینٹ سبھی Pydantic میں ڈسیرئیلائز ہو جاتے ہیں۔ FastAPI ہینڈلر میں models: وہی models agent کے tools رٹرن۔ ایک انبندھ, دو سماپن بند۔
3. Inngest اوینٹ Pydantic پیلوڈ لے جاتے ہیں۔ جب ایک FastAPI webhook handler ایک Inngest اوینٹ پھایر کرتا ہے, تو payload ایک Pydantic model ہے۔ نلنبت step.wait_for_event سیدھے ٹائپ کیا گیا payload پراپت کرتا ہے۔ ورکفلو میں کوئی JSON پارسنگ نہیں۔

پیسے کے لئے دشملو, ہمیشا۔ اس پاٹھیکرم میں ہر مودرک راش Decimal کا استعمال کرتی ہے, کبھی float کا نہیں۔ پیسے پر فلوٹنگ-پائنٹ گنت ان تریکوں سے سٹیکتا کھو دیتا ہے جو ہجاروں micropayments میں مشرت ہوتے ہیں۔ Stripe SDK دونوں کو سویکار کرتا ہے لیکن Decimal میں واپس رپورٹ کرتا ہے۔ x402 راشیاں on-chain پورنانک کے روپ میں آتی ہیں (USDC میں 6 دشملو ستھان ہیں) جنہیں آپ Decimal میں لپیٹتے ہیں۔ پیسا ہر جگہ Decimal رہتا ہے, اسے تار پراروپ میں کرمبدھ نہیں کیا جا رہا ہے۔

ساجھا پرنام model۔ ہر اودھارنا میں پرنام پرکاروں کو پھر سے پربھاشت کرنے کے بجای, پاٹھیکرم ایک بار پرنام models کے ایک چھوٹے سیٹ کو پربھاشت کرتا ہے۔ نیچے دیا گیا ہر code بلاک انہیں نام سے آیات کرتا ہے۔ انہیں اپنے models.py میں رکھیں:

from pydantic import BaseModel, Field
from decimal import Decimal
from typing import Literal
from datetime import datetime

# --- Tool-result models (returned by @function_tool functions) ---

class PaymentToolResult(BaseModel):
    """Generic envelope for any payment-related tool action."""
    status: Literal["success", "failed", "rejected", "pending"]
    error: str | None = None
    details: dict | None = None  # protocol-specific details

class MandateResult(BaseModel):
    """Result of creating an AP2 mandate (Intent / Cart / Payment)."""
    mandate_id: str | None = None
    status: Literal["signed", "declined", "pending", "failed"]
    expires_at: str | None = None  # ISO 8601
    error: str | None = None

class OrderStatusResult(BaseModel):
    """Result of fetching ACP order status."""
    order_id: str
    status: Literal["confirmed", "shipped", "delivered", "cancelled", "refunded", "pending"]
    tracking_url: str | None = None
    estimated_delivery: str | None = None

class RefundResult(BaseModel):
    """Result of initiating an ACP refund."""
    refund_id: str
    order_id: str
    status: Literal["initiated", "processing", "completed", "failed"]
    amount_refunded_usd: Decimal | None = None

class DiscoveryResult(BaseModel):
    """Result of an Agent.market or similar agent-directory search."""
    service_id: str
    name: str
    description: str
    price_per_call_usdc: Decimal
    endpoint_url: str

class X402PaymentResult(BaseModel):
    """Result of an x402-paid fetch."""
    content: str
    amount_paid_usdc: Decimal
    tx_hash: str | None = None

class MPPSessionResult(BaseModel):
    """Result of creating or closing an MPP session."""
    session_id: str
    status: Literal["active", "closed", "expired", "failed"]
    total_charged_usd: Decimal | None = None  # only populated on close
    expires_at: datetime | None = None
    rail_breakdown: dict[str, Decimal] | None = None  # only on close

class MPPMeteredCallResult(BaseModel):
    """Result of a metered call within an active MPP session."""
    session_id: str
    cost_usd: Decimal
    response_payload: dict
    accumulated_session_spend_usd: Decimal

# --- FastAPI handler models (request/response bodies for webhooks/callbacks) ---

class WebhookAck(BaseModel):
    """Generic webhook handler ack."""
    received: bool = True
    event_id: str | None = None

# --- Inngest workflow result models (return types of @inngest_client functions) ---

class WorkflowResult(BaseModel):
    """Generic workflow completion envelope."""
    status: Literal["completed", "abandoned", "failed", "partial"]
    reason: str | None = None
    output: dict | None = None

یہ models حصہ 3 اور حصہ 6 کے مادھیم سے دوہرائے جاتے ہیں۔ نیچے دئے گئے code بلاک انہیں نام سے آیات کرتے ہیں اور انہیں کبھی بھی دوبارا پربھاشت نہیں کرتے ہیں۔ آپ ہر اودھارنا میں آیات پیٹرن کو دوہرائےا ہءآ دیکھینگے; یہ سائڈبار دوہراتا نہیں ہے.

تصور 8: ACP (Agentic Commerce Protocol), consumer-shopping protocol

ایک پنکت میں: ACP اس پرکار ہے ک کیسے ایک agent ایک شخص کی اور سے ایک واستوک merchant پر ایک واستوک checkout کو پورا کرتا ہے, جبک merchant ابھی بھی بکری کے لئے تییار ہے۔

یہ کیا ہے۔ ACP, OpenAI اور Stripe دوارا بنایا ایک کھلا ونردیش ہے, جسے 29 ستنبر, 2025 کو لانچ پارٹنر کے روپ میں Etsy اور Shopify کے ساتھ لانچ کیا گیا تھا۔ 2026 کی شرءآت تک یہ Shopify-ایکیکرت merchants اور کئی بڑے retail برانڈوں کو ChatGPT Instant Checkout کو شکت پردان کرتا ہے۔ Merchant کی گنتی اور برانڈ سوچیاں ماخذ کے انسار الگ-الگ ہوتی ہیں, اسلئے ورتمان اپنانے کے لئے ACP ایکیکرن نردیشکا کے وردھ ستیاپت کریں۔ protocol Apache 2.0 ہے, جو github.com/agentic-commerce-protocol/agentic-commerce-protocol پر ایک تفصیلات سنوردھن پرستاو پرکریا کے مادھیم سے نینترت ہوتا ہے۔ repository spec کو beta کے روپ میں چہنت کرتا ہے, اسلئے پاٹھیکرم کے اداہرنوں اور لائو سپیک کے بیچ انتر کی امید کریں۔

یہ کہاں بیٹھتا ہے۔ ACP جیاداتر Layer 3 (Commerce) پر رہتا ہے اور اپنے ٹوکن تنتر کے مادھیم سے Layer 2 (Authorization) تک پہنچتا ہے۔ اوقتں cart گٹھن, checkout, آرڈر پربندھن, fulfillment ستھت اور refund یانترکی شامل ہیں۔ merchant رکارڈ کا merchant رہتا ہے: chargebacks, رٹرن اور گراہک سیوا سبھی merchant کے موجودا سسٹم کے مادھیم سے پرواہت ہوتی ہے۔ (رکارڈ کا Merchant ویوسای کانونی روپ سے لیندین کے لئے ہک پر ہے۔)

دو primitives جو ماینے رکھتے ہیں۔

1. Shared Payment Token (SPT)۔ payment processor (حوالہ بلڈ میں Stripe) سے ایک بار کا ٹوکن, ایک merchant, ایک راش حد, ایک چھوٹی وقت ونڈو اور آمتور پر ایک ہی استعمال کے لئے لاک کیا جاتا ہے۔ ید $50 کے لئے سویکرت کوئی agent $1,000 کھرچ کرنے کا پریاس کرتا ہے, تو SPT protocol ستر پر وپھل ہو جاتا ہے۔ SPT اس پرکار ہے ک ACP agent کو استعمالکرتا کے ادھکرت دایرے میں رکھتا ہے۔
2. Cart Mandate (AP2 ایکسٹینشن کے مادھیم سے)۔ ACP اترکت آڈٹ کٹھورتا کے لئے AP2 کے ساتھ compose کر سکتا ہے: agent SPT سبمٹ کرنے سے پہلے استعمالکرتا Cart Mandate پر ہستاکشر کرتا ہے۔ یہ ACP میں ویکلپک ہے لیکن ونیمت پرواہ میں آم ہوتا جا رہا ہے۔ (mandate ایک signed پرمان ہے ک ایک مانو نے ایک وششٹ پرکار کے کھرچ کو ادھکرت کیا ہے۔)

OpenAI Agents SDK ایکیکرن۔ ACP, SDK کے لئے سبسے ادھک اتپادن کے لئے تییار protocol ہے, کیونک OpenAI نے اسے سہ-بنایا کیا ہے۔ Stripe Python SDK پلس ایک پتلا ACP client ریپر آپکو پورن ایکیکرن دیتا ہے۔

note

نیچے دئے گئے acp_client کال اور stripe.PaymentTokens.create(...) اداہرناتمک ہیں: وے ACP ایکیکرن کے آکار کو درشاتے ہیں۔ اصل SPT ڈھلائی لائو Stripe ACP endpoints سے ہوتی ہے, stripe.PaymentTokens ودھ سے نہیں۔ agent وایرنگ, guardrail, اور پرنام models واستوک ہیں اور آج بھی چلتے ہیں۔ بلاک کے باد نوٹ دیکھیں.

from agents import Agent, Runner, function_tool, RunContextWrapper
from agents.tool_guardrails import (
    tool_input_guardrail,
    ToolInputGuardrailData,
    ToolGuardrailFunctionOutput,
)
from pydantic import BaseModel
from decimal import Decimal
from typing import Literal
import json
import stripe
import time
from .models import OrderStatusResult, RefundResult

class CartItem(BaseModel):
    sku: str
    name: str
    quantity: int
    unit_price_usd: Decimal

class CheckoutResult(BaseModel):
    order_id: str
    status: Literal["confirmed", "failed", "pending_user_confirmation"]
    total_charged_usd: Decimal
    estimated_delivery: str | None = None

# Tool input guardrail: refuse the checkout if the user can't authorize the spend
@tool_input_guardrail
def verify_user_can_spend(data: ToolInputGuardrailData) -> ToolGuardrailFunctionOutput:
    args = json.loads(data.context.tool_arguments or "{}")
    max_total = Decimal(str(args.get("max_total_usd", 0)))
    merchant_id = args.get("merchant_id", "")
    user_session = data.context.context["user_session"]
    if not user_session.can_spend(max_total, merchant_id):
        return ToolGuardrailFunctionOutput.reject_content(
            f"User cannot authorize ${max_total} at merchant {merchant_id}"
        )
    return ToolGuardrailFunctionOutput.allow()

@function_tool
async def acp_browse_merchant(merchant_id: str, query: str) -> list[dict]:
    """Search a merchant's catalog via their ACP catalog endpoint."""
    response = await acp_client.catalog.search(
        merchant_id=merchant_id,
        query=query,
        limit=20,
    )
    return [item.model_dump() for item in response.items]

@function_tool(tool_input_guardrails=[verify_user_can_spend])
async def acp_create_cart_and_checkout(
    ctx: RunContextWrapper,
    merchant_id: str,
    items: list[CartItem],
    max_total_usd: Decimal,
) -> CheckoutResult:
    """Create a cart at the merchant and complete checkout in one transaction.
    Mints an SPT scoped to max_total_usd; the merchant verifies and charges.
    The verify_user_can_spend guardrail above has already validated authorization."""

    user_session = ctx.context["user_session"]

    # Mint the Shared Payment Token via Stripe (Decimal to cents via quantize)
    cents = int((max_total_usd * 100).quantize(Decimal("1")))
    spt = stripe.PaymentTokens.create(
        amount=cents,
        currency="usd",
        merchant_id=merchant_id,
        user_session_id=user_session.id,
        max_uses=1,
        expires_at=int(time.time()) + 600,  # 10-minute window
    )

    # Submit the cart and SPT to the merchant's ACP endpoint
    result = await acp_client.checkout.complete(
        merchant_id=merchant_id,
        items=[i.model_dump() for i in items],
        spt_token=spt.token,
    )

    # Update the user's spend tracker (Decimal in, Decimal out)
    user_session.record_spend(
        amount_usd=Decimal(str(result.total_charged_usd)),
        merchant_id=merchant_id,
        order_id=result.order_id,
    )

    return CheckoutResult(**result.model_dump())

@function_tool
async def acp_check_order(order_id: str) -> OrderStatusResult:
    """Get the current status of an ACP order (fulfillment, shipping, delivery)."""
    raw = await acp_client.orders.get(order_id=order_id)
    return OrderStatusResult(
        order_id=raw.order_id,
        status=raw.status,
        tracking_url=raw.tracking_url,
        estimated_delivery=raw.estimated_delivery,
    )

@function_tool
async def acp_refund(
    order_id: str,
    reason: str,
    amount_usd: Decimal | None = None,
) -> RefundResult:
    """Start a refund for an ACP order. Returns refund_id for follow-up.
    If amount_usd is None, a full refund is requested."""
    raw = await acp_client.refunds.create(
        order_id=order_id,
        reason=reason,
        amount_usd=amount_usd,
    )
    return RefundResult(
        refund_id=raw.refund_id,
        order_id=order_id,
        status=raw.status,
        amount_refunded_usd=raw.amount_refunded_usd,
    )

shopping_agent = Agent(
    name="ShoppingAgent",
    instructions="""Help the user shop at ACP-enabled merchants. Workflow:
    1. Use acp_browse_merchant to find products matching the user's request
    2. Present the matched items to the user (via reasoning, not a tool)
    3. When the user confirms, use acp_create_cart_and_checkout to complete the purchase
    4. Use acp_check_order to report order status when the user asks
    5. Use acp_refund only when the user explicitly requests a return""",
    tools=[acp_browse_merchant, acp_create_cart_and_checkout, acp_check_order, acp_refund],
    model="gpt-5.5",
)

یہاں واستوک کیا ہے: Agent, Runner, @function_tool, اور tool_input_guardrail مچان, ساتھ ہی ٹائپ کئے گئے پرنام model۔ یہ وہ ہسا ہے جسے آپ ہر protocol کے لئے پن: استعمال کرتے ہیں۔ سٹینڈ-ان کیا ہے: acp_client اور stripe.PaymentTokens.create کال, جو ایسیپی-Stripe بیکئینڈ کا پرتندھتو کرتے ہیں۔ production میں آپ اس بیکئینڈ کو لائو Stripe ACP endpoints کے لئے سویپ کرتے ہیں اور باکی وہیں رہتا ہے۔ یہاں چلانے یوگی ماک کے ساتھ وہی آکرت دی گئی ہے تاک آپ اسے کام کرتے ہئے دیکھ سکیں:

class MockACPClient:
    """Illustrative backend. Real ACP uses live Stripe ACP endpoints, not stripe.PaymentTokens."""
    async def checkout(self, merchant_id: str, amount_usd) -> dict:
        return {"order_id": "ord_mock_1", "status": "confirmed", "total_charged_usd": str(amount_usd)}

acp_client = MockACPClient()   # stands in for the ACP/Stripe backend

مانک ہارنیس (یہاں ایک بار کہا گیا ہے, اگلی تین اودھارناؤں دوارا حوالہت)۔ ACP بنا کسی اترکت حصہ کے سادے کلاؤڈ ہارنیس پر چلتا ہے۔ Stripe SDK FastAPI ہینڈلر کے اندر چلتا ہے; ACP کال آؤٹباؤنڈ ہیں HTTPS; SPTs agent کے رن-سکوپ حوالہ میں رہتے ہیں, RunContextWrapper سے ہوکر گجرتے ہیں۔ ایک نیم: Stripe API کنجیوں کو ایک گپت سٹور (key vault) میں رکھیں, پریاورن چر میں نہیں, اور انہیں Stripe کے شیڈیول پر گھمائیں۔ کسی سینڈباکس کی ضرورت نہیں ہے (ACP بنا code چلتا ہے) اور کسی وشیش بھنڈارن کی ضرورت نہیں ہے (آرڈر Stripe اور merchant کے سسٹم میں بنے رہتے ہیں, آڈٹ کے لئے ویکلپک چھایا رکارڈ کے ساتھ)۔ یہ پرنیوجن بیسلائن AP2, x402 اور MPP کے لئے سمان ہے۔ اگلی تین اودھارنائیں وہی کہتی ہیں جو ہر جوڑتی ہے۔ کلاؤڈ پرنیوجن کو پرنیوجن-agent کریش کورس (پرگت پر) میں شامل کیا گیا ہے۔

اسے ٹکاؤ ڈھنگ سے چلانا (Inngest)۔ ACP لیندین چھوٹے ہوتے ہیں, آمتور پر شرو سے انت تک 5 سے 30 سیکنڈ۔ وے Inngest step.run بلاکوں میں ساپھ-ساپھ پھٹ ہو جاتے ہیں۔ step.wait_for_event primitive اپنا ستھان تب ارجت کرتا ہے جب agent کو استعمالکرتا کو cart نرمان اور checkout (human-in-the-loop پیٹرن) کے بیچ cart کی پشٹ کرنے کے لئے روکنا ہوگا۔ Production Worker کریش کورس اس ستھایتو layer کو گہرائی سے کور کرتا ہے; یہاں آکرت ہے:

import inngest
from datetime import timedelta
from .models import WorkflowResult

@inngest_client.create_function(
    fn_id="shopping-workflow",
    trigger=inngest.TriggerEvent(event="shopping/checkout.requested"),
    concurrency=[inngest.Concurrency(limit=5, key="event.data.user_id")],
)
async def shopping_workflow(ctx: inngest.Context) -> dict:
    # Run the agent to produce the cart proposal
    cart = await ctx.step.run(
        "agent-builds-cart", build_cart_fn, ctx.event.data["user_query"],
    )

    # Wait for the user to confirm the proposed cart (human-in-the-loop)
    confirmation = await ctx.step.wait_for_event(
        "wait-for-user-confirm",
        event="shopping/cart.confirmed",
        if_exp=f"async.data.cart_id == '{cart['cart_id']}'",
        timeout=timedelta(minutes=15),
    )
    if confirmation is None:                 # timeout returns None
        return {"status": "abandoned", "reason": "user did not confirm in time"}

    # The user confirmed; complete checkout with the now-valid SPT
    result = await ctx.step.run("complete-checkout", complete_checkout_fn, cart["cart_id"])
    return {"status": "completed", "output": result}

کچھ وورن جو لوگوں کو آشچریچکت کرتے ہیں: wait_for_event آنے والے payload کو if_exp (ایک چھوٹی ابھشخص) کے ساتھ میل کھاتا ہے, اور پرتیکشت فیلڈ async. اپسرگ کے انترگت رہتے ہیں۔ ایک ٹائمءآؤٹ None لوٹاتا ہے, اسلئے جاری رکھنے سے پہلے اسکی جانچ کر لیں۔

جہاں ٹیموں کو یہ غلطی ملتی ہے۔ وے استعمالکرتا-پشٹ چرن کو چھوڑ دیتے ہیں۔ ACP "استعمالکرتا ہر cart کی پشٹ کرتا ہے" اور "استعمالکرتا pre-authorized اس پرکار کی کھریداری" دونوں کا سمرتھن کرتا ہے۔ ٹیمیں اکسر گت کے لئے دوسرے کو چنتی ہیں, پھر پاتی ہیں ک ایک چھوٹا SPT غلط کانفگریشن agent کو تھوڑا غلط آئٹم خریدنے دیتا ہے اور اسے پنرپراپت کرنے کا کوئی راستا نہیں ہے۔ اتپادن کے پہلے مہینے کے لئے cart کی پشٹ کرنے میں ڈفالٹ۔ اسے کیول ایک بار آرام دیں جب آپ ماپ لیں ک agent کتنی بار cart سہی ہو جاتا ہے۔

کانسیپٹ 8 کی نچلی پنکت: ACP consumer shopping کے لئے OpenAI Agents SDK کے ساتھ اتپادن کے لئے تییار commerce protocol ہے۔ SPT agent کے کھرچ کا دایرا بڑھاتا ہے; merchant رکارڈ کا merchant بنا ہءآ ہے۔ آپ اسے Stripe SDK اور ایک پتلے ACP client پر چار @function_tool functions (براؤز کریں, checkout, ستھت, refund) کے روپ میں ایکیکرت کرتے ہیں۔ Inngest کا step.wait_for_event استعمالکرتا-پشٹ دوار بناتا ہے, اور سادا کلاؤڈ ہارنیس پریاپت ہے۔ جب تک آپ agent کے cart سٹیکتا کو ماپ نہیں لیتے, تب تک cart کی پشٹ کرنا ڈفالٹ ہے۔

اودھارنا 9: AP2 (Agent Payments Protocol), authorization layer

ایک پنکت میں: AP2 signed سبوت پیش کرتا ہے ک ایک انسان نے کھرچ کی انمت دی; یہ پیسے کو سویں ستھانانترت نہیں کرتا ہے, یہ سابت کرتا ہے ک پیسے کو ستھانانترت کرنے کی انمت دی گئی تھی۔

یہ کیا ہے۔ AP2 60+ حصہیداروں کے ساتھ Google کا ایک کھلا ونردیش ہے, جسے ستنبر 2025 میں لانچ کیا گیا (نوینتم version v0.2.0, اپریل 2026)۔ Apache 2.0, github.com/google-agentic-commerce/AP2 پر بنائے رکھا گیا ہے, Python, TypeScript, Kotlin اور Go میں حوالہ کاریانوین کے ساتھ۔ AP2 authorization layer ہے, commerce یا settlement protocol نہیں ہے۔ یہ signed mandates کا اتپادن کرتا ہے جو سابت کرتا ہے ک agent کھرچ کرنے کے لئے ادھکرت ہے, پھر واستوک settlement کو rail میں پھٹ بیٹھتا ہے (کارڈ, بینک, یا a2a-x402 ایکسٹینشن کے مادھیم سے x402) چھوڑ دیتا ہے۔

یہ کہاں بیٹھتا ہے۔ AP2 Layer 2 (Identity اور Authorization) پر رہتا ہے۔ یہ نیچے دو protocols پر بنایا ہوتا ہے: A2A (Agent2Agent, agent-ٹو-agent میسیجنگ کے لئے) اور MCP (tool ایکسپوزر کے لئے)۔ ایک AP2 mandate A2A پر signed کریڈینشیل کے روپ میں یاترا کرتا ہے یا MCP tool کال سے جڑا ہوتا ہے۔

تین primitives جو ماینے رکھتے ہیں, تین mandate پرکار۔

Mandate	جب یہ بنایا گیا ہے	اسسے کیا سدھ ہوتا ہے
Intent Mandate	کاری کے پرارنبھ میں, signed استعمالکرتا دوارا اپنے UI میں	استعمالکرتا نے agent کو نردھارت نیموں (مولی حد, وقت ونڈو, merchants کی انمت) کے بھیتر کاری کرنے کی انمت دی
Cart Mandate	agent کے باد استعمالکرتا دوارا checkout (مانو-ورتمان پرواہ) سے پہلے ایک وششٹ cart, signed بنایا گیا ہے	استعمالکرتا نے اسی سٹیک کیمت پر cart کو منجوری دی
Payment Mandate	بھگتان کے وقت, استعمالکرتا دوارا signed یا Intent Mandate کے وردھ سوتہ جینریٹ کیا گیا	استعمالکرتا نے اس سٹیک بھگتان کو اسی rail پر ادھکرت کیا ہے

آڈٹ ٹریل۔ تین mandates ایک شرنکھلا بناتے ہیں جسے ہستاکشرکرتا باد میں اسویکار نہیں کر سکتا ہے: ارادا ("$120 کے تہت جوتے کھریدیں") Cart ("یہ جوتے $110 میں") کی اور لے جاتا ہے جسسے بھگتان ہوتا ہے ("اس stablecoin wallet کو چارج کریں")۔ ہر mandate اپنے سے پہلے والے کی اور اشارا کرتا ہے۔ ید کسی کدم کو باد میں dispute یا دھوکھادھڑی کے داوے میں چنوتی دی جاتی ہے, تو پوری شرنکھلا آڈٹ یوگی ہے۔ وہ سنپت non-repudiable ہے: "میں نے اسے کبھی ادھکرت نہیں کیا" استعمالکرتا کے سویں کے ہستاکشر کے وردھ نہیں ہے۔ یہی کارن ہے ک AP2 سواستھی دیکھبھال اور وتیی سیواؤں جیسے ونیمت ادیوگوں میں پھٹ بیٹھتا ہے, جہاں "استعمالکرتا نے واستو میں اسے ادھکرت کیا ہے?" کانونی بھار وہن کرتا ہے۔

SDK کے لئے کیا پرورتن۔ AP2 کا OpenAI Agents SDK میں کوئی پرتھم شرینی ستھان نہیں ہے; اسکا حوالہ Google کا Agent ڈیولپمینٹ کٹ کا استعمال کرتا ہے۔ آپ اسے @function_tool functions کے روپ میں وایر کرتے ہیں جو جنادیش بناتا ہے, ہستاکشر کرتا ہے, مانی کرتا ہے اور بھیجتا ہے۔ ہارنیس کانسیپٹ 8 جیسا ہی ہے۔ ایک چیج جو AP2 جوڑتا ہے: ایک signing ستہ جہاں استعمالکرتا واستو میں ہر جنادیش پر ہستاکشر کرتا ہے۔

note

نیچے دئے گئے from ap2 import ... آیات, MandateSigner, اور ap2_x402 کال اداہرناتمک ہیں۔ AP2 کا واستوک Python پیکیج ap2 ہے, mandate models کے انترگت ap2.types.mandate ہے, اور اسکے واستوک فیلڈ یہاں دکھائے گئے سرلیکرت principal_did / agent_did / rules سے بھن ہیں۔ کوئی MandateSigner ورگ نہیں ہے; واستوک signing A2A پر تصدیق یوگی کریڈینشیلس کا استعمال کرتا ہے۔ ادھدیش-شرنکھلا کی اودھارنا واستوک ہے; یہ سٹیک code ایک شکشن سٹینڈ-ان ہے۔ SDK مچان اور ٹائپ کئے گئے پرنام واستوک ہیں۔

from agents import Agent, function_tool, RunContextWrapper
from agents.tool_guardrails import (
    tool_input_guardrail,
    ToolInputGuardrailData,
    ToolGuardrailFunctionOutput,
)
from ap2 import IntentMandate, CartMandate, PaymentMandate, MandateSigner
from pydantic import BaseModel
from decimal import Decimal
from datetime import datetime
from .models import MandateResult, PaymentToolResult

class IntentRules(BaseModel):
    max_total_usd: Decimal
    allowed_merchants: list[str] | None = None
    allowed_categories: list[str] | None = None
    expires_at: str  # ISO 8601 datetime

# Guardrail: refuse any cart that has no preceding Intent Mandate
@tool_input_guardrail
def require_intent_mandate(data: ToolInputGuardrailData) -> ToolGuardrailFunctionOutput:
    intent = data.context.context.get("intent_mandate")
    if not intent:
        return ToolGuardrailFunctionOutput.reject_content(
            "No Intent Mandate found. Create one via ap2_create_intent_mandate first."
        )
    return ToolGuardrailFunctionOutput.allow()

@function_tool
async def ap2_create_intent_mandate(
    ctx: RunContextWrapper,
    task_description: str,
    rules: IntentRules,
) -> MandateResult:
    """Create an Intent Mandate at the start of a purchasing task.
    Needs the user's signature, so call this BEFORE the agent shops."""

    user_session = ctx.context["user_session"]
    mandate = IntentMandate(
        principal_did=user_session.did,  # decentralized identifier
        agent_did=ctx.context["agent_did"],
        task=task_description,
        rules=rules.model_dump(),
        issued_at=datetime.utcnow().isoformat(),
    )

    # Send to the user's signing UI; block until the user signs or rejects
    signed = await user_session.signer.request_signature(
        mandate,
        ui_prompt="Approve this shopping task?",
        timeout_seconds=300,
    )
    if not signed:
        return MandateResult(status="declined", error="User declined to sign Intent Mandate")

    # Store the mandate for later reference by Cart/Payment mandates
    ctx.context["intent_mandate"] = signed
    return MandateResult(mandate_id=signed.id, status="signed", expires_at=rules.expires_at)

@function_tool(tool_input_guardrails=[require_intent_mandate])
async def ap2_create_cart_mandate(
    ctx: RunContextWrapper,
    cart_items: list[dict],
    total_usd: Decimal,
    merchant_id: str,
) -> MandateResult:
    """Create a Cart Mandate that references the current Intent Mandate.
    Needs the user's signature in human-present flows.
    The require_intent_mandate guardrail above has verified an Intent Mandate exists."""

    intent = ctx.context["intent_mandate"]  # guaranteed present by the guardrail

    # Check that the cart fits inside the Intent Mandate's rules
    if total_usd > Decimal(str(intent.rules["max_total_usd"])):
        return MandateResult(
            status="failed",
            error=f"Cart total ${total_usd} exceeds Intent Mandate cap ${intent.rules['max_total_usd']}",
        )

    cart_mandate = CartMandate(
        parent_intent_id=intent.id,
        cart_items=cart_items,
        total_usd=str(total_usd),  # serialize Decimal as a string on the wire
        merchant_id=merchant_id,
        issued_at=datetime.utcnow().isoformat(),
    )

    user_session = ctx.context["user_session"]
    signed = await user_session.signer.request_signature(
        cart_mandate,
        ui_prompt=f"Approve this cart for ${total_usd}?",
        timeout_seconds=300,
    )
    if not signed:
        return MandateResult(status="declined", error="User declined to sign Cart Mandate")

    ctx.context["cart_mandate"] = signed
    return MandateResult(mandate_id=signed.id, status="signed")

@function_tool
async def ap2_settle_via_x402(
    ctx: RunContextWrapper,
    merchant_x402_url: str,
) -> PaymentToolResult:
    """Use the AP2 a2a-x402 extension to settle the current Cart Mandate via an x402 stablecoin payment."""
    cart = ctx.context.get("cart_mandate")
    if not cart:
        return PaymentToolResult(status="failed", error="No Cart Mandate to settle")

    # The a2a-x402 extension generates a Payment Mandate authorizing the x402 transfer
    payment_mandate = await ap2_x402.create_payment_mandate(
        cart_mandate=cart,
        rail="x402",
        chain="eip155:8453",  # Base
        asset="USDC",
    )

    # Dispatch the x402 payment with the Payment Mandate attached as proof
    result = await x402_client.pay(
        url=merchant_x402_url,
        amount_usdc=Decimal(str(cart.total_usd)),
        payment_mandate=payment_mandate,
    )
    return PaymentToolResult(status="success", details=result.model_dump())

procurement_agent = Agent(
    name="ProcurementAgent",
    instructions="""Enterprise procurement workflow:
    1. ALWAYS create an Intent Mandate first via ap2_create_intent_mandate
    2. Search merchants for matching items
    3. Build a cart and create a Cart Mandate via ap2_create_cart_mandate
    4. Settle via x402 (stablecoin) using ap2_settle_via_x402, or via card rails
    5. Record every mandate ID in the procurement system for audit""",
    tools=[ap2_create_intent_mandate, ap2_create_cart_mandate, ap2_settle_via_x402],
    model="gpt-5.5",
)

واستوک کیا ہے: وہی SDK مچان اور کانسیپٹ 8 کے روپ میں ٹائپ کئے گئے پرنام۔ سٹینڈ-ان کیا ہے: ap2 mandate ککشائیں, MandateSigner, اور ap2_x402 ایکسٹینشن۔ mandate شرنکھلا اپنے آپ میں ایک واستوک وچار ہے جسے آپ بنا سکتے ہیں; یہاں سٹیک API کو شکشن کے لئے سرل بنایا گیا ہے۔ یہاں ایک چلنے یوگی ماک ہے تاک پیٹرن نشپادت ہو:

class MockSignedMandate:
    def __init__(self, mid, rules=None): self.id, self.rules = mid, (rules or {})
class MockSigner:
    """Illustrative. Real AP2 signing uses verifiable credentials over A2A; no MandateSigner class exists."""
    async def request_signature(self, mandate, ui_prompt="", timeout_seconds=300):
        return MockSignedMandate(getattr(mandate, "id", "mandate_mock_1"))
ap2_x402 = type("Mock", (), {"create_payment_mandate": staticmethod(lambda **k: MockSignedMandate("pm_mock_1"))})()

یہ ہارنیس میں کیا جوڑتا ہے۔ کانسیپٹ 8 بیسلائن سے پرے دو چیجیں: استعمالکرتا کے لئے mandates (ایک ویب ایپ, ایک موبائل ایپ, یا ادھسوچنا-آدھارت signing tool) پر ہستاکشر کرنے کے لئے ایک signing ستہ, اور signed mandates کے لئے durable سٹوریج یہ آپکی dispute ونڈو تک چلتا ہے (وتیی mandates کے لئے 7-ورشیی پرتدھارن مانک ہے)۔ signing ستہ ACP سے واستوک ڈیلٹا ہے: ACP موجودا لاگن sessions کا پن: استعمال کر سکتا ہے, لیکن AP2 کو ایک سمرپت signature پرواہ کی ضرورت ہے۔

اسے ٹکاؤ ڈھنگ سے چلانا (Inngest)۔ Mandate signing step.wait_for_event کا پاٹھیپستک استعمال ہے۔ agent کے function ایک "signing انرودھت" ایوینٹ سکری کرتا ہے, function نلنبت ہو جاتا ہے, استعمالکرتا UI میں ہستاکشر کرتا ہے جو "signing signed" سکری کرتا ہے اور function پھر سے شرو ہو جاتا ہے۔ پرتیکشا کرتے وقت کوئی بھی گننا نہیں جلتی ہے, جو ماینے رکھتی ہے کیونک enterprise signature میں گھنٹوں لگ سکتے ہیں۔ Production Worker کریش کورس اس resume pattern پر گہرائی سے جاتا ہے۔

جہاں ٹیموں کو یہ غلطی ملتی ہے۔ وے mandate نرمان کو checkout-ٹائم چنتا کے روپ میں مانتے ہیں اور mandate پر ہستاکشر کرتے ہیں جب agent پہلے ہی بہت کام کر چکا ہوتا ہے۔ agent دکانوں سے پہلے, سبسے پہلے Intent Mandate بنائیں۔ یہ ایک سکوپ بیمیل کو جلدی پکڑ لیتا ہے (استعمالکرتا جوتے چاہتا تھا لیکن Intent Mandate کیول کاریالی کی آپورت کی انمت دیتا ہے) اسکے بجای agent نے cart کے نرمان پر گننا کھرچ کرنے کے باد اسے کبھی بھی وت پوشت نہیں کیا جا سکتا ہے۔

اودھارنا 10: x402, HTTP-مول settlement protocol

ایک پنکت میں: x402 پرانے HTTP 402 "Payment Required" ستھت code کو پنرجیوت کرکے, ایک agent کو stablecoin کے ساتھ ایک سے دو سیکنڈ میں API کال کے لئے بھگتان کرنے دیتا ہے۔

یہ کیا ہے۔ x402 نشکری HTTP 402 status code کو APIs اور machine-to-machine وانجی کے لئے ایک کاریشیل payment layer میں بدل دیتا ہے۔ اسے Coinbase (مئی 2025) دوارا بنایا گیا تھا, V2 کو دسنبر 2025 میں لانچ کیا گیا تھا, اور اب اسے Linux Foundation کے x402 پھاؤنڈیشن (اپریل 2026) کے تہت Cloudflare, Stripe کے ساتھ چلایا کیا گیا ہے۔ AWS, Google, اور انی سدسی کے روپ میں۔ Apache 2.0. 2026 کی شرءآت میں, x402 نے بڑھتے facilitator پارستھتکی تنتر کے ساتھ, Base اور Solana پر اب تک 100 ملین سے ادھک بھگتان کی رپورٹ دی ہے; سنکھیائیں تیزی سے آگے بڑھتی ہیں, اسلئے x402.org اور Coinbase کا x402 لانچ پیج پر ورتمان آنکڑوں کو ستیاپت کریں۔

یہ کہاں بیٹھتا ہے۔ machine-to-machine پرواہ کے لئے x402 جیاداتر Layer 4 (Settlement) پر رہتا ہے, لیکن یہ Layer 1 (agent.مارکیٹ اور سمان نردیشکاؤں کے مادھیم سے) اور Layer 3 تک پہنچتا ہے (یہ پورن commerce کے روپ میں کام کرتا ہے) سادے API پہنچ کے لئے layer جہاں کوئی واستوک purchase lifecycle نہیں ہے)۔ شدھ machine-to-machine پرواہ کے لئے, x402 اکسر ایکماتر protocol ہوتا ہے جسکی آپکو ضرورت ہوتی ہے۔

چار primitives جو ماینے رکھتے ہیں۔

1. HTTP 402 ستھت code۔ جب ایک اویتنک client بھگتان کئے گئے سنسادھن کا انرودھ کرتا ہے, تو server بھگتان ضرورتؤں کو لیکر 402 Payment Required پلس ایک header لوٹاتا ہے: منصوبہ (ایک نشچت راش کے لئے exact), نیٹورک (CAIP-2 پھارم میں جیسے eip155:8453, جسکا سیدھا ارتھ ہے "Base"), سنپت (USDC), پراپتکرتا کا پتا, ادھکتم راش اور ایک سماپت۔ (CAIP-2, blockchain کو نام دینے کا ایک مانک تریکا ہے تاک protocol chain-agnostic رہے۔)
2. بھگتان authorization ہیڈر۔ client retries header کے ساتھ signed بھگتان پرادھکرن لے جا رہا ہے۔ signature off-chain سے بنا ہے, اسلئے buyer کوئی گیس بھگتان نہیں کرتا ہے۔
3. EIP-3009 (transferWithAuthorization). Ethereum مانک x402 پر بنایا گیا ہے۔ یہ buyer کو ایک بھگتان off-chain پر ہستاکشر کرنے دیتا ہے جسے کوئی انی شخص on-chain سبمٹ کرتا ہے, اسلئے buyer کبھی بھی blockchain کو سیدھے نہیں چھوتا ہے یا گیس کا بھگتان نہیں کرتا ہے۔
4. سودھاکرتا۔ ایک ویکلپک ترتیی پکش جو signature کی جانچ کرتا ہے اور merchant کے لئے بھگتان on-chain جما کرتا ہے, اسلئے merchant کوئی blockchain پلنبنگ نہیں چلاتا ہے۔ Coinbase اور Cloudflare دونوں facilitator چلاتے ہیں۔

header نامکرن پر ایک نوٹ: ورتمان docs کے وردھ ستیاپت کریں

x402 V1 اور V2 سے گجرا, اور header نام spec versions, facilitators اور SDK میں بھن ہیں۔ Cloudflare کا ورتمان docs 402 response پر PAYMENT-REQUIRED, client کے retry پر PAYMENT-SIGNATURE اور سپھل اتر پر PAYMENT-RESPONSE کا استعمال کریں۔ پہلے کے کچھ اداہرن X-PAYMENT اور X-PAYMENT-PROOF کا استعمال کرتے ہیں۔ پرواہ سمان ہے; کیول تار کے نام بھن ہیں۔ code لکھنے سے پہلے x402.gitbook.io اور اپنے facilitator کے docs کے سامنے سٹیک ناموں کی جانچ کریں۔ نیچے دیا گیا trace ایک نامکرن پرنپرا کو چنے بنا بھومکاؤں (request, ضرورتؤں کے ساتھ 402, signed retry, پرمان کے ساتھ سپھلتا) کا استعمال کرتا ہے۔

ایک ٹریس میں پرواہ.

1. Agent: GET https://api.example.com/data
2. Server: 402 Payment Required
   <payment-required header>: { network: "eip155:8453", asset: USDC,
                                recipient: 0xMerchant..., max_amount: 100000,
                                expiry: 1716304800 }
3. Agent (signs an EIP-3009 authorization off-chain):
   GET https://api.example.com/data
   <payment-signature header>: <base64-encoded signed authorization>
4. Server: 200 OK
   <payment-response header>: <transaction hash>
   { data: ... }

پورے لین-دین میں ایک سے دو سیکنڈ کا وقت لگتا ہے۔ کوئی account creation, کوئی API کنجی, کوئی session, لوپ میں کوئی انسان نہیں۔

SDK کے لئے کیا پرورتن۔ x402 میں چاروں میں سے سبسے سرل کہانی ہے۔ Cloudflare ایک سہایک بھیجتا ہے جو MCP client کو x402 بھگتان کشمتا کے ساتھ لپیٹتا ہے; گیر-MCP استعمال کے لئے, ایک Python buyer-side library پلس نیچے وہت پیٹرن اسے کور کرتا ہے۔ ہارنیس وہی کانسیپٹ 8 بیسلائن ہے۔

note

یہاں دکھایا گیا from x402_client import ... کنسٹرکٹر, from cloudflare_agents import withX402Client آیات, اور response.amount_paid_usdc فیلڈ اداہرناتمک ہیں۔ واستوک buyer-side پیکیج x402-client ہے (from x402_client import X402Client, واستوک کنسٹرکٹر X402Client(account=...), .get(url) ایک httpx.Response لوٹاتا ہے)۔ یہاں دکھایا گیا سمردھ wallet کنسٹرکٹر ایک شکشن سٹینڈ-ان ہے, اور لائو کال کے لئے ایک وت پوشت account اور ایک واستوک 402 endpoint کی ضرورت ہوتی ہے, جو یہ کورس نہیں کرتا ہے۔ Cloudflare کا withX402Client ایک JavaScript سہایک ہے; کوئی Python cloudflare_agents پیکیج نہیں ہے۔ MCP server (MCPServerStreamableHttp) اصل Python ہے; اسے بھگتان کے ساتھ لپیٹنا یہاں اداہرناتمک ہے۔ کوئی واستوک پھنڈ نہیں چلتا.

from agents import Agent, function_tool, RunContextWrapper
from agents.mcp import MCPServerStreamableHttp
from agents.tool_guardrails import (
    tool_input_guardrail,
    ToolInputGuardrailData,
    ToolGuardrailFunctionOutput,
)
from x402_client import X402Client, X402Wallet
from cloudflare_agents import withX402Client
from decimal import Decimal
import json
from .models import DiscoveryResult, X402PaymentResult, PaymentToolResult

# Pattern 1: wrap an MCP server's tools with x402 payment ability
research_mcp = MCPServerStreamableHttp(
    name="research-services",
    params={"url": "https://research-services.example.com/mcp"},
)
research_mcp_with_payments = withX402Client(
    research_mcp,
    wallet=agent_wallet,  # smart-contract wallet the agent controls
    max_per_call_usdc=Decimal("0.10"),
    max_per_session_usdc=Decimal("10.00"),
)

# Pattern 2: direct x402 calls as @function_tool
x402_client = X402Client(wallet=agent_wallet)

# Guardrail: refuse any x402 call that would exceed the session cap
@tool_input_guardrail
def enforce_x402_session_cap(data: ToolInputGuardrailData) -> ToolGuardrailFunctionOutput:
    args = json.loads(data.context.tool_arguments or "{}")
    max_payment = Decimal(str(args.get("max_payment_usdc", 0)))
    ctx = data.context.context
    spent = Decimal(str(ctx.get("session_x402_spend_usdc", 0)))
    cap = Decimal(str(ctx["user_session"].x402_session_cap_usdc))
    if spent + max_payment > cap:
        return ToolGuardrailFunctionOutput.reject_content(
            f"x402 session cap would be exceeded: ${spent} spent + ${max_payment} requested > ${cap}"
        )
    return ToolGuardrailFunctionOutput.allow()

@function_tool(tool_input_guardrails=[enforce_x402_session_cap])
async def x402_fetch(
    ctx: RunContextWrapper,
    url: str,
    max_payment_usdc: Decimal = Decimal("0.10"),
) -> X402PaymentResult | PaymentToolResult:
    """Fetch a URL that may require an x402 payment up to max_payment_usdc.
    Signs the EIP-3009 authorization and retries with the payment-signature header.
    The enforce_x402_session_cap guardrail above has already checked the session bound."""

    try:
        response = await x402_client.get(url, max_payment_usdc=max_payment_usdc)
        # Update the spend tracker for later guardrail checks
        current = Decimal(str(ctx.context.get("session_x402_spend_usdc", 0)))
        ctx.context["session_x402_spend_usdc"] = current + Decimal(str(response.amount_paid_usdc))
        return X402PaymentResult(
            content=response.content,
            amount_paid_usdc=Decimal(str(response.amount_paid_usdc)),
            tx_hash=response.tx_hash,
        )
    except X402PaymentRequired as e:
        return PaymentToolResult(
            status="rejected",
            error=f"Resource requires ${e.required_usdc}, exceeds max ${max_payment_usdc}",
        )

@function_tool
async def x402_search_agent_market(
    query: str,
    max_price_per_call_usdc: Decimal = Decimal("0.05"),
) -> list[DiscoveryResult]:
    """Search Agent.market for x402-paywalled services matching the query."""
    results = await agent_market_client.search(
        query=query,
        max_price_per_call_usdc=max_price_per_call_usdc,
    )
    return [
        DiscoveryResult(
            service_id=r.service_id,
            name=r.name,
            description=r.description,
            price_per_call_usdc=Decimal(str(r.price_per_call_usdc)),
            endpoint_url=r.endpoint_url,
        )
        for r in results
    ]

research_agent = Agent(
    name="ResearchAgent",
    instructions="""Research user queries by paying for data sources via x402.
    Workflow:
    1. Use x402_search_agent_market to find relevant paid services
    2. Use x402_fetch to pull data from selected services (max $0.10 per call)
    3. Synthesize the findings into a final report
    Stay under $10 per research session.""",
    tools=[x402_fetch, x402_search_agent_market],
    mcp_servers=[research_mcp_with_payments],
)

واستوک کیا ہے: SDK مچان, ٹائپ کئے گئے پرنام, اور MCPServerStreamableHttp (MCP server واستوک Python ہے)۔ سٹینڈ-ان کیا ہے: buyer-side x402 client جیسا ک یہاں لکھا گیا ہے, withX402Client ریپر (JavaScript کیول واستوکتا میں), اور agent_market_client۔ یہاں چلنے یوگی ماک ہیں تاک ہارنیس پیٹرن واستوک پھنڈ کے بنا نشپادت ہو:

from decimal import Decimal

class MockX402Response:
    def __init__(self, content, amount, tx):
        self.content, self.amount_paid_usdc, self.tx_hash = content, amount, tx
class MockX402Client:
    """Illustrative. Real buyer-side package: x402-client (X402Client(account=...), .get() -> httpx.Response)."""
    async def get(self, url: str, max_payment_usdc: Decimal = Decimal("0.10")):
        return MockX402Response(content="<paid data>", amount=Decimal("0.02"), tx="0xmocktx")
x402_client = MockX402Client()
agent_wallet = object()   # stands in for the wallet handle

def withX402Client(mcp_server, **kwargs):
    """Illustrative: JavaScript-only in reality. Returns the server unchanged for the Python demo."""
    return mcp_server

یہ ہارنیس میں کیا جوڑتا ہے۔ لگبھگ کچھ بھی نہیں۔ x402 کو کانسیپٹ 8 بیسلائن سے پرے کسی اترکت بنیادی ڈھانچے کی ضرورت نہیں ہے۔ agent کے smart-contract wallet اس شرنکھلا کے ایک پتے پر رہتا ہے جس پر یہ لیندین کرتا ہے (جیاداتر ماملوں میں Base), wallet کی signing کنجی key vault میں بیٹھتی ہے, اور buyer-side library ہینڈل signing اور HTTP پنہ پریاس کریں۔ (ایک smart-contract wallet ایک crypto wallet ہے جسکی کھرچ حد code دوارا blockchain پر ہی لاگو کی جاتی ہے, اسلئے ید agent کے code کھراب ہو جائے تو بھی وے کھرچ کرتے ہیں۔)

اسے ٹکاؤ ڈھنگ سے چلانا (Inngest)۔ x402 کال چھوٹی (ایک سے دو سیکنڈ) اور نشکری ہیں: سمان request اور signature ہمیشا ایک ہی پرنام دیتے ہیں۔ وے step.run بلاکوں میں ساپھ-ستھرے ڈھنگ سے پھٹ ہوتے ہیں, اور یہاں سنسمرن سے لابھ ملتا ہے۔ ید 10 API کالوں میں سے 5 کے لئے بھگتان کرنے کے باد رن کریش ہو جاتا ہے, تو 5 بھگتان کی گئی کالوں کو یاد کیا جاتا ہے اور retry کیول شیش 5 کے لئے بھگتان کرتا ہے۔ اسکے بنا, retry پھر سے سبھی 10 کے لئے بھگتان کریگا۔

wallet کیپ وہ سرکشا ہے جو آپکی سرکشا کرتی ہے

جال x402 کے ساتھ agent کو کریڈٹ کارڈ سونپنے جیسا رویہ کر رہا ہے۔ جو سرکشا واستو میں آپکی سرکشا کرتی ہے وہ wallet کی on-chain کھرچ حد ہے, ن ک per-request max_payment_usdc۔ on-chain حد کو چھوڑیں اور بنا کیپ والے گرم wallet کا استعمال کریں, اور ایک اٹکا ہءآ agent loop اسے ختم کر سکتا ہے۔ on-chain spend limits پرت agent identity, پرت session, اور پرت merchant, تین سوتنتر layers کانفگر کریں, تاک ایک میں بگ wallet کو کھالی ن کرے۔

تصور 11: MPP (Machine Payments Protocol), sessions-based settlement protocol

ایک پنکت میں: MPP agent کو کھرچ حد کے ساتھ ایک پریپیڈ ٹیب کھولنے دیتا ہے, پھر اسکے وردھ کئی rails پر کئی چھوٹے بھگتان سٹریم کرتا ہے جب تک ک یہ ٹیب بند نہیں ہو جاتا۔

یہ کیا ہے۔ MPP کو Stripe اور Tempo دوارا بنایا گیا ہے, مارچ 2026 میں ساروجنک لانچ کی گھوشنا کے ساتھ۔ Tempo ایک پرت-1 blockchain ہے جسے اچ آورت مشین بھگتان کے لئے Stripe اور Paradigm دوارا انکیوبیٹ کیا گیا ہے۔ MPP کو Stripe, Visa, Lightspark (Lightning Network), اور انی پارستھتکی تنتر کھلاڑیوں کے حصہیداروں کے ساتھ لانچ کیا گیا; حصہیدار سوچی بڑھتی ہے, اسلئے ورتمان پرتحصہیوں کے لئے mpp.dev اور Cloudflare کا MPP docs کے وردھ تصدیق کریں۔ Apache 2.0. MPP, Stripe ہے اور x402 کا settlement-layer اتر ہے: اوورلیپنگ استعمال کا ماملا, الگ درشن۔

یہ کہاں بیٹھتا ہے۔ MPP Layer 4 (Settlement) پر رہتا ہے اور machine-to-machine بھگتان کے لئے سیدھے x402 کے ساتھ پرتسپردھا کرتا ہے۔ مکھی انتر: MPP multi-rail ہے اور پرت-چارج اور session-based پرمانیکرن دونوں کا سمرتھن کرتا ہے, جبک x402 کیول stablecoin اور پرت-انرودھ ہے۔

HTTP آکار۔ جہاں x402 402 code اور کسٹم headers کا استعمال کرتا ہے, MPP layers مانک HTTP پرمانیکرن پر بھگتان۔ server ضرورتؤں کے ساتھ WWW-Authenticate: Payment لوٹاتا ہے, client retries Authorization: Payment <signed-payload> کے ساتھ دیتا ہے, اور server settlement پرمان کے ساتھ Payment-Receipt کے ساتھ اتر دیتا ہے۔ یہ MPP کو ایک کسٹم protocol کے بجای ایک پرچت HTTP پرمانیکرن پرواہ جیسا مہسوس کراتا ہے۔

دو ارادے پرکار۔

ارادا	جیونچکر	کے لئے سرووتم
charge	ایک one-off ستھانانترن, ایک راؤنڈ-ٹرپ میں ادھکرت اور ویوستھت	ایکل کھریداری, ایک بار API ایکسیس, جب آپکو multi-rail کی ضرورت ہو تو شخصگت x402 کال کو بدلنا
session	agent ایک حد اور ایک اودھ کو پورو-ادھکرت کرتا ہے, پھر بند ہونے تک میٹر micropayments سٹریم کرتا ہے	اچ آورت micropayments جہاں signing ہر request مہنگا ہے; آورتی سدسیتائیں; "Stripe agents کے لئے سدسیتا" model

x402 کے وردھ ویاپار۔

آیام	x402	MPP
Authorization آورت	پرت request (ہر بار ایک EIP-3009 signature)	پرت charge یا پرت session (ایک پرمانیکرن, کئی میٹرڈ کال)
HTTP آکار	کسٹم 402 پلس بھگتان headers	مانک WWW-Authenticate / Authorization / Payment-Receipt
Rails	کیول Stablecoin (بیس/Solana/EVM پر USDC)	Multi-rail (Tempo stablecoin, Lightning, کارڈ, ACH)
پھیس	شونی protocol شلک پلس سب-سینٹ گیس	Stripe card rails پر پرسنسکرن شلک; Tempo stablecoin پر لگبھگ شونی
آورتی سمرتھن	سیمت (پرت-اودھ signing کی ضرورت)	session ارادے کے مادھیم سے مول نواسی
سبسے اپیکت	One-off API کال, ساروجنک بنیادی ڈھانچا	آورتی سدسیتائیں, enterprise اور Stripe-ایکیکرت merchants, فئیٹ فالبیک کی ضرورت والے پرواہ

SDK کے لئے کیا پرورتن۔ MPP Stripe Python SDK پلس Stripe کی MPP ستہ کے مادھیم سے ایکیکرت ہوتا ہے۔ ایکیکرن session پربندھن پر منحصر ہے۔ ہارنیس وہی کانسیپٹ 8 بیسلائن ہے۔

note

نیچے دئے گئے from stripe.mpp import MPPSession آیات اور stripe.MPPSession کال اداہرناتمک ہیں۔ stripe.MPPSession اور stripe.mpp Stripe Python SDK میں نہیں ہیں; MPP Stripe اور Tempo مانک (mainnet مارچ 18, 2026) ہے, جو Stripe کی MPP ستہ کے مادھیم سے ایکیکرت ہے۔ session اودھارنا (ایک کیپ, سٹریم میٹرڈ کال کو پورو-ادھکرت کریں) واستوک ہے; یہاں سٹیک API ایک شکشن سٹینڈ-ان ہے۔ SDK مچان اور ٹائپ کئے گئے پرنام واستوک ہیں۔

from agents import Agent, function_tool, RunContextWrapper
from agents.tool_guardrails import (
    tool_input_guardrail,
    ToolInputGuardrailData,
    ToolGuardrailFunctionOutput,
)
from decimal import Decimal
import json
import stripe
from stripe.mpp import MPPSession
from .models import MPPSessionResult, MPPMeteredCallResult, PaymentToolResult

@tool_input_guardrail
def verify_mpp_session_authorized(data: ToolInputGuardrailData) -> ToolGuardrailFunctionOutput:
    """Refuse session creation if the user has not pre-authorized this service."""
    args = json.loads(data.context.tool_arguments or "{}")
    service_id = args.get("service_id", "")
    max_total = Decimal(str(args.get("max_total_usd", 0)))
    user_session = data.context.context["user_session"]
    if not user_session.can_authorize_mpp_session(max_total, service_id):
        return ToolGuardrailFunctionOutput.reject_content(
            f"User has not authorized MPP sessions of ${max_total} for service {service_id}"
        )
    return ToolGuardrailFunctionOutput.allow()

@function_tool(tool_input_guardrails=[verify_mpp_session_authorized])
async def mpp_create_session(
    ctx: RunContextWrapper,
    service_id: str,
    max_total_usd: Decimal,
    duration_seconds: int = 3600,
) -> MPPSessionResult:
    """Create an MPP session for one service with a spending cap and duration.
    Returns session_id for the metered calls that follow.
    The verify_mpp_session_authorized guardrail above has already validated consent."""

    user_session = ctx.context["user_session"]
    cents = int((max_total_usd * 100).quantize(Decimal("1")))
    session = stripe.MPPSession.create(
        service_id=service_id,
        max_total_usd=cents,
        duration_seconds=duration_seconds,
        user_session_id=user_session.id,
        # The MPP server picks the rail (stablecoin/Lightning/card) by service preference
    )

    ctx.context.setdefault("mpp_sessions", {})[service_id] = session.id
    return MPPSessionResult(
        session_id=session.id,
        status="active",
        expires_at=session.expires_at,
    )

@function_tool
async def mpp_metered_call(
    ctx: RunContextWrapper,
    service_url: str,
    payload: dict,
    cost_estimate_usd: Decimal,
) -> MPPMeteredCallResult | PaymentToolResult:
    """Make a metered call inside an active MPP session.
    The session's running spend updates automatically; the cap is enforced server-side."""

    service_id = extract_service_id(service_url)
    sessions = ctx.context.get("mpp_sessions", {})
    session_id = sessions.get(service_id)
    if not session_id:
        return PaymentToolResult(
            status="failed",
            error=f"No active MPP session for service {service_id}. Create one first.",
        )

    response = await mpp_client.metered_call(
        url=service_url,
        payload=payload,
        session_id=session_id,
        cost_estimate_usd=cost_estimate_usd,
    )
    return MPPMeteredCallResult(
        session_id=session_id,
        cost_usd=Decimal(str(response.cost_usd)),
        response_payload=response.payload,
        accumulated_session_spend_usd=Decimal(str(response.accumulated_session_spend_usd)),
    )

@function_tool
async def mpp_close_session(ctx: RunContextWrapper, session_id: str) -> MPPSessionResult:
    """Close an MPP session and finalize payment. Returns the total charged and the breakdown by rail."""
    closed = await stripe.MPPSession.close(session_id)
    return MPPSessionResult(
        session_id=session_id,
        status="closed",
        total_charged_usd=Decimal(str(closed.total_charged_usd)),
        rail_breakdown={
            rail: Decimal(str(amount))
            for rail, amount in closed.rail_breakdown.items()
        },
    )

api_consumer_agent = Agent(
    name="APIConsumerAgent",
    instructions="""Consume third-party APIs efficiently using MPP sessions.
    Workflow:
    1. Identify the service to consume
    2. Create an MPP session with mpp_create_session ($X cap, Y seconds duration)
    3. Make metered calls via mpp_metered_call
    4. Close the session with mpp_close_session when done
    Sessions are cheaper than per-request payment for high-frequency calls.""",
    tools=[mpp_create_session, mpp_metered_call, mpp_close_session],
    model="gpt-5.5",
)

واستوک کیا ہے: SDK مچان اور ٹائپ کئے گئے پرنام۔ سٹینڈ-ان کیا ہے: stripe.MPPSession اور mpp_client۔ session جیونچکر ایک واستوک پیٹرن ہے; یہاں سٹیک Stripe API کو شکشن کے لئے سرل بنایا گیا ہے۔ یہاں ایک چلنے یوگی ماک ہے:

from decimal import Decimal

class MockMPPSession:
    @staticmethod
    def create(**kw):
        return type("S", (), {"id": "mpp_sess_1", "expires_at": None})()
    @staticmethod
    async def close(session_id):
        return type("S", (), {"total_charged_usd": Decimal("4.20"),
                              "rail_breakdown": {"stablecoin": Decimal("4.20")}})()
mpp_client = type("Mock", (), {"metered_call": staticmethod(
    lambda **k: type("R", (), {"cost_usd": Decimal("0.05"), "payload": {},
                               "accumulated_session_spend_usd": Decimal("0.05")})())})()

یہ ہارنیس میں کیا جوڑتا ہے۔ ایک کانفگریشن چرن: آپ کے Stripe account کو MPP سکشم کرنے کی ضرورت ہے۔ Tempo blockchain ایکیکرن کو Stripe کا MPP server دوارا نینترت کیا جاتا ہے, اسلئے agent کبھی بھی Tempo کو سیدھے نہیں چھوتا ہے۔ Stripe SDK اور کنجی پربندھن (ACP کے سمان) سے پرے, کچھ بھی اترکت نہیں ہے۔

اسے ٹکاؤ ڈھنگ سے چلانا (Inngest)۔ MPP sessions میپ کو Inngest کے لنبے وقت سے چلنے والے function پیٹرن پر ساپھ-ستھرا بنائیں۔ session جیونچکر (بنائیں, استعمال کریں, بند کریں) step.run بلاکوں کا ایک کرم بن جاتا ہے, جس میں step.sleep وقت-آدھارت سماپت کے لئے اپلبدھ ہے۔ session model اور durable نشپادن compose اچھی طرح سے: دونوں سٹیٹپھل, ملٹی-سٹیپ کاری کے لئے بنائے گئے ہیں۔

جہاں ٹیمیں یہ غلطی کرتی ہیں۔ وے sessions بناتے ہیں جو بہت بڑے یا بہت لنبے ہوتے ہیں۔ ید کچھ بھی غلط ہوتا ہے تو session کیپ آپکی ہان حد ہے۔ "سودھا کے لئے" $1,000 کا session سیٹ آپکو $1,000 کا agent-لوپ-غان-غلط نکسان کا سامنا کراتا ہے۔ واستوک اپیکشت کاری کے لئے سہی آکار sessions: 30-کال کاری کے لئے, 5 منٹ تک چلنے والا $5 session ایک گھنٹے تک چلنے والے $50 session سے ادھک سرکشت ہے۔

---

حصہ 4: Composition نیم, کب کون سا protocols ایک ساتھ استعمال کرنا ہے

حصہ 3 میں ایک بار میں چار protocols چلے۔ اب ہمنے انہیں واپس ایک ساتھ رکھ دیا۔ آپکو حصہ 1 میں یہ وچار ملا: ایک واستوک پرنالی ایک بار میں کئی protocols کا استعمال کرتی ہے, پرت پرت ایک۔ حصہ 4 آپکو نیم دیتا ہے ک کون سا سنیوجن کام کرتا ہے, کون سا وپھل رہتا ہے, اور stack کو کاری کی انمت کے انسار چھوٹا کیسے رکھا جائے۔

تصور 12: نیونتم رویہی agent-بھگتان stack

ایک پنکت میں: سہی stack protocols کا سبسے چھوٹا سیٹ ہے جو ایک استعمال کے ماملے کے لئے مولی بھیجتا ہے, ہر پرت پر سبھی چار protocols کے لئے نہیں۔

اسسے پہلے ک آپ compose کچھ بھی کریں, ایک سوال پوچھیں: سبسے چھوٹا stack کیا ہے جسکا مولی یہاں ہے? اتر لگبھگ کبھی نہیں ہوتا ہے "سبھی چار protocols, ہر پرت۔" ادھکانش production سسٹم پوری طرح سے وایرڈ ایک layer سے شرو ہوتے ہیں اور باکی کو تبھی جوڑتے ہیں جب استعمال کا ماملا اسے مجبور کرتا ہے۔

یہاں ہر سامانی استعمال کے ماملے کے لئے سبسے چھوٹا stack ہے۔ یہ حصہ 5 میں پانچ فیصلہوں کا بھی پورواولوکن کرتا ہے۔

کیس کا پریوگ کریں	Layer 1 (Discovery)	Layer 2 (پرامانک)	Layer 3 (Commerce)	Layer 4 (Settlement)	یہ ایمویپی کیوں ہے?
Consumer shopping (agent ایک شخص کے لئے retail سامان کھریدتا ہے)	AI shopping ستہ, یا merchant کیٹلاگ کے ساتھ MCP server	ACP SPT (یا ونیمت کشیتروں میں ایک AP2 mandate)	ACP	Card rails Stripe کے مادھیم سے	ادھکانش کھریدار chargeback کور چاہتے ہیں۔ ACP پلس Stripe وہ پتھ ہے جو آج جہاج کرتا ہے۔
API-paying agent (agent ترتیی-پکش APIs کو کال کرتا ہے جو چارج کرتا ہے)	MCP server x402 سمرتھن یا agent.مارکیٹ نردیشکا کے ساتھ	EIP-3009 signature (x402 ڈفالٹ)	کوئی نہیں: سیدھا API کال	x402 Base یا Solana پر	machine-to-machine, Layers 2 اور 4 پتن کے لئے۔ کوئی کھرید جیونچکر نہیں ہے.
Enterprise procurement (agent نیموں کے تہت انمودت آپورتکرتاؤں سے کھریدتا ہے)	پارٹنر نیٹورک کے اندر A2A discovery	AP2 Intent Mandate (آڈٹ کے لئے آوشیک)	کیٹلاگ آپورتکرتاؤں کے لئے ACP یا UCP; سیوا کھرید کے لئے سیدھے API	آورتی کے لئے MPP sessions; ACP SPT one-off کے لئے card rails کے مادھیم سے	آڈٹ ٹریل وہ ہسا ہے جسے آپ چھوڑ نہیں سکتے۔ AP2 mandates آوشیک ہیں۔
Multi-agent marketplace (agent انی agents کو کام پر رکھتا ہے)	A2A یا agent directory	AP2 mandate پلس ایک ERC-8004 پرتشٹھا جانچ	کوئی نہیں: پرتیکش agent-سے-agent	x402 (سبسے آم), یا MPP ید Stripe پہلے سے ہی وایرڈ ہے	بھروسا دونوں طرح سے چلتا ہے. ہر پکش کو تصدیق یوگی identity اور بھگتان پرمان کی ضرورت ہے۔

composition نیم۔ استعمال کے ماملے کی مانگ کے انسار ہر layer پر protocol چنیں۔ layers پر protocols ن جوڑیں, استعمال کا ماملا کبھی نہیں چھوتا۔ شدھ API-paying agent کو ACP کی ضرورت نہیں ہے۔ ایک consumer-shopping agent کو $50 کی ٹی-شرٹ پر x402 تک نہیں پہنچنا چاہئے, کیونک کارڈ پر chargeback کور 2.9% شلک کے لایک ہے۔

جال۔ کچھ ٹیمیں "لچیلیپن کے لئے" ACP, AP2, x402, اور MPP کو ایک ساتھ تار کرنے کا پریاس کرتی ہیں۔ آپکو چار بار ایکیکرن ستہ ملتی ہے اور "کون سا protocol کب سکری ہوتا ہے" کا کوئی سپشٹ اتر نہیں ملتا ہے۔ ایک ڈھیر چنیں. اسے بھیج دو۔ دوسرا stack تبھی جوڑیں جب دوسرے استعمال کے ماملے میں اسکی مانگ ہو۔

تصور 13: جب protocols compose layers کے پار ہو اور ایک کے بھیتر پرتسپردھا کریں

ایک پنکت میں: Protocols کو الگ-الگ layers پر ایک ساتھ stack بنایا گیا ہے; protocols ایک ہی layer پر ایک دوسرے کو بدلنے کے لئے بنائے گئے ہیں, اسلئے ایکماتر سوال یہ ہے ک کیا دو protocols ایک ہی پرت پر بیٹھتے ہیں۔

دو protocols دو تریکوں میں سے ایک میں سنبندھت ہیں۔ وے یا تو compose ہیں, کیونک وے الگ-الگ layers پر بیٹھتے ہیں اور stack پر بنائے گئے تھے, یا وے پرتسپردھا کرتے ہیں, کیونک وے ایک ہی layer پر بیٹھتے ہیں اور ستھاناپن کے لئے بنائے گئے تھے۔ ادھکانش واست سنبندھی بھرم دوسرے ماملے کو پہلے کے روپ میں پڑھنے سے اتپن ہوتا ہے۔

layers کے پار, compose پر بنایا:

Composition	Layer میپنگ	یہ کہاں بھیجا جاتا ہے
AP2 + ACP	AP2 پر Layer 2 (آڈٹ-گریڈ آتھ), ACP پر Layer 3 (commerce)	ونیمت فیلڈ جہاں ACP کے سامانی پرواہ کو اترکت آڈٹ کی ضرورت ہوتی ہے
AP2 + x402	AP2 پر Layer 2 (mandate پرامانک), x402 پر Layer 4 پر (stablecoin settlement)	a2a-x402 ایکسٹینشن کے مادھیم سے کرپٹو-دیشی پرواہ جنہیں ابھی بھی آڈٹ کی ضرورت ہے
ACP + x402	ACP Layer 3 پر (commerce), x402 Layer 4 پر machine-to-machine کھرید کے اندر اپ-پرواہ کے لئے	ہائبرڈ پلیٹفارم جہاں consumer کھریداری میں کچھ API کھرچ شامل ہیں
MCP + x402 (withX402Client کے مادھیم سے)	MCP پر Layer 1 (discovery), x402 پر Layer 4 (settlement)	Cloudflare بھگتان کے لئے مانک پیٹرن MCP tools

ایک layer کے بھیتر, پرتسپردھا کے لئے بنایا گیا:

پرتیوگتا	Layer	جب ہر جیتتا ہے
AP2 بنام ACP SPT بنام TAP	Layer 2	آڈٹ-گریڈ پرواہ کے لئے AP2; Stripe-وایرڈ consumer پرواہ کے لئے ACP SPT; کیول پہچان جانچ کے لئے TAP
ACP بنام UCP	Layer 3	ChatGPT پہنچ کے لئے ACP; متھن پہنچ کے لئے UCP; دونوں کراس-صرفیس وکریتاؤں کے لئے
x402 بنام MPP	Layer 4	one-off micropayments اور شدھ stablecoin پرواہ کے لئے x402; sessions, سدسیتا اور multi-rail پرواہ کے لئے MPP

پریکشن۔ جب آپ دو protocols کے بیچ پھنس گئے ہوں, تو ایک بات پوچھیں: کیا وے ایک ہی layer پر ہیں? ید ہاں, تو آپ ایک کو چنتے ہیں, یا آپ الگ-الگ اپ-پرواہوں کے لئے دونوں کا سمرتھن کرنے کے لئے بھگتان کرتے ہیں۔ ید نہیں, تو سنبھوتہ وے compose ہیں, اور سہی ڈزائن اکسر دونوں کا استعمال کرتا ہے۔

ایک کام کیا ہءآ composition: AP2 + x402 سٹیک۔ یہ کرپٹو-نیٹو پیٹرن ہے, جو اب B2B اور agent-ٹو-agent پرواہ میں آم ہے:

Layer 1 (Discovery): A2A directory inside the partner network
Layer 2 (Auth):      AP2 Intent + Cart + Payment Mandates
Layer 3 (Commerce):  Often none (direct service request), or ACP for a catalog
Layer 4 (Settlement): x402 via the a2a-x402 extension

SDK اسینبلی کیول حصہ 3 سے پرت-protocol tools بناتی ہے۔ یہ tools (a2a_discover_partners, ap2_create_intent_mandate, اور باکی) اودھارنا 8 سے 11 میں پربھاشت ہیں; یہاں آپ انہیں کیول ایک agent پر تار دیتے ہیں۔

agent = Agent(
    name="EnterpriseB2BAgent",
    instructions="...",
    tools=[
        # Layer 1: Discovery
        a2a_discover_partners,
        # Layer 2: Authorization
        ap2_create_intent_mandate,
        ap2_create_cart_mandate,
        # Layer 4: Settlement (a2a-x402 composes Layers 2 and 4)
        ap2_settle_via_x402,
    ],
    model="gpt-5.5",
    # No commerce tools: direct B2B procurement.
)

تصور 14: لاگت اور ولنبتا, جو چناو کو بادھی کرتی ہے

ایک پنکت میں: لین-دین کا آکار اور آپ کے دوارا سویکار کیا جانے والا انتجار settlement protocol تی کرتا ہے, کیونک کارڈ شلک چھوٹے بھگتانوں کو کچل دیتا ہے اور دھیمی گت سے checkout تنگ لوپ کو توڑ دیتا ہے۔

ہر composition کی ایک کیمت اور ایک گت ہوتی ہے۔ ACP پلس card rails پر ایک consumer-shopping پرواہ کی لاگت لگبھگ 2.9% + $0.30 پرت لیندین ہے اور شرو سے انت تک 5 سے 30 سیکنڈ لگتے ہیں۔ x402 پر ایک API-paying agent کی لاگت ایک سینٹ سے کم ہے اور اوقتں 1 سے 2 سیکنڈ کا وقت لگتا ہے۔ سہی composition آنشک روپ سے اس بات پر منحصر کرتا ہے ک آپکا استعمال کیس کتنی لاگت اور کتنا انتجار کر سکتا ہے۔

رچنا کے انسار پرت لیندین لاگت۔

Composition	پرت لیندین وششٹ لاگت	وششٹ ولنبتا
ACP + card rails (consumer shopping)	2.9% + $0.30 (Stripe در)	5 سے 30 سیکنڈ
ACP + MPP sessions (سدسیتا)	کارڈ پر 2.9%, یا Tempo stablecoin, پرت session پر لگبھگ 0.5%	پرت میٹر کال 1 سے 3 سیکنڈ
AP2 + x402 (B2B stablecoin)	سب-سینٹ گیس, شونی protocol شلک	2 سے 5 سیکنڈ (mandate signing 1 سے 3 جوڑتا ہے)
کیول x402 (API-paying)	سب-سینٹ گیس, شونی protocol شلک	1 سے 2 سیکنڈ
کیول MPP sessions (آورتی API)	Tempo stablecoin پر شونی کے کریب; کارڈ پر Stripe در	سکری session کے اندر پرت میٹر کال 50 سے 500 ایمئیس

پیسا کیا مجبور کرتا ہے۔ لیندین کے لگبھگ 5% سے ادھک شلک ایک سمسیا ہے۔ $0.05 API کال جس میں کارڈ شلک کے روپ میں 2.9% + $0.30 کا بھگتان کیا جاتا ہے, اسکی لاگت کال کے مولی سے ادھک ہوتی ہے, جو اسکے بجای x402 یا MPP stablecoin کا استعمال کرنے کے لئے ایک سپشٹ سنکیت ہے۔ سمان 2.9% + $0.30 کا بھگتان کرنے والی $50 کی ٹی-شرٹ ٹھیک ہے۔ ڈالر لائن جہاں card rails سمجھ میں آنا بند ہو جاتی ہے, وہ $ 5 سے $ 10 کے آسپاس ہے۔ اسکے نیچے, مشین-بھگتان rails جیت; اسکے اوپر, کارڈ پر chargeback کور آمتور پر شلک کے لایک ہے۔

ولنبتا کیا بادھی کرتی ہے۔ ہر استعمالکرتا-سامنا والے چرن کے لئے 5 سیکنڈ سے ادھک پرتیکشا کرنا ایک سمسیا ہے۔ AP2 mandate signing 1 سے 3 سیکنڈ جوڑ سکتا ہے, اگر یہ مانو signature پر پرتیکشا کرتا ہے تو اسسے بھی ادھک وقت; ACP checkout 5 سے 30 جوڑتا ہے۔ لوپ میں کسی بھی مانو کے ساتھ agent-ٹو-agent پرواہ کے لئے, بجٹ ابھی بھی سکھت ہے, اکسر اپ-سیکینڈ, جو Base پر x402 اور Tempo پر MPP کو ڈفالٹ چین بناتا ہے۔

decision tree, سنپیڑت۔

What is the transaction value?
├── Sub-dollar (per-call API, per-token billing)
│   → x402 only, or MPP sessions
├── $1 to $10 (small, low-stakes buys)
│   → x402 or MPP, with AP2 audit if you need it
├── $10 to $1,000 (consumer purchases)
│   → ACP + card rails (chargeback cover is worth the fee)
└── $1,000+ (B2B, enterprise procurement)
    → AP2 + ACP/UCP + MPP sessions, or bank rails

What is the latency budget?
├── Sub-second (multi-agent loops)
│   → MPP sessions on Tempo, or x402 on Base
├── 1 to 5 seconds (interactive)
│   → x402 or MPP; AP2 only if mandates are pre-signed
└── 5+ seconds (an acceptable user wait)
    → Full ACP checkout works

---

حصہ 5: decision lab, پانچ کاریشیل اداہرن

حصہ 2 سے 4 نے آپکو framework دیا: چار layers, کچھ protocols پرت layer, composition پرتوں میں۔ حصہ 5 پانچ واستوک فیصلہوں پر آدھارت ہے۔ ہر پورن ترک دکھاتا ہے: layers استعمال کا ماملا کیا چھوتا ہے, ہر layer پر کون سا protocol, کیوں, اور agent code کیسا دکھتا ہے۔

ایک استعمال کے ماملے کا پورا سٹیک دیکھنے کے لئے ایک پنکت میں پڑھیں۔ استعمال کے ماملے میں پرورتن ہونے پر ایک layer میں کیا پرورتن ہوتا ہے یہ دیکھنے کے لئے ایک کالم پڑھیں۔ نیچے دئے گئے پانچ فیصلہ پنکتیوں میں وستار سے دئے گئے ہیں۔ پہلے چار میٹرکس کو کور کرتے ہیں; پانچواں انمیں سے ایک کو پوری طرح سے الگ toolچین میں پنرنرمان کرتا ہے تاک یہ سابت ہو سکے ک framework کسی ایک وکریتا سے بندھا نہیں ہے۔

فیصلہ 1: Consumer shopping agent (ChatGPT Instant Checkout پیٹرن)

استعمال کا ماملا۔ آپ ایک agent بنا رہے ہیں جو لوگوں کو والمارٹ, Etsy اور Shopify وکریتاؤں جیسے ACP-سکشم merchants پر کھریداری کرنے میں مدد کرتا ہے۔ استعمالکرتا کہتا ہے ک وے کیا چاہتے ہیں; agent کیٹلاگ کھوجتا ہے, وکلپ دکھاتا ہے, اور پشٹ پر جانچ کرتا ہے۔ سنگل buyer سے سنگل merchant, $5 سے $500 پرت آرڈر, refunds اور chargebacks آوشیک۔

چار پرتوں پر چلنا۔

• layer 1 (Discovery). agent کو کئی ویاپاریوں کے پاس اتپاد ڈھونڈھنے ہونگے۔ آپ ہر merchant کے MCP کیٹلاگ کو ایکیکرت کر سکتے ہیں, یا ChatGPT Shopping ستہ کا استعمال کر سکتے ہیں جو پہلے سے ہی ACP ویاپاریوں کو ایکترت کرتا ہے۔ وکلپ: AI shopping ستہ, کیونک discovery کا کام پہلے ہی ہو چکا ہے اور ایک لاکھ کیٹلاگ کو سویں وایر کرنا رویہی نہیں ہے۔
• پرت 2 (Authorization). استعمالکرتا ستہ میں signed ہے اور ہر کھرید کی پشٹ کرتا ہے, اسلئے authorization سرل ہے۔ وکلپ: ACP SPT, پرت کھریداری Stripe دوارا نردھارت, ایک merchant, ایک راش اور 10 منٹ کی ونڈو تک سیمت۔
• layer 3 (Commerce). پورا جیونچکر ماینے رکھتا ہے: cart, checkout, fulfillment, disputes, refund۔ وکلپ: ACP, protocol بلکہل اسی کے لئے بنایا گیا ہے۔
• layer 4 (Settlement). $5 سے $500 کا مان کارڈ-ریل سویٹ سپاٹ میں سہی بیٹھتا ہے, اور chargeback کور شلک کے لایک ہے۔ وکلپ: card rails Stripe کے مادھیم سے, rail ACP ڈفالٹ روپ سے مانتا ہے۔

کاریانوین۔ یہ تصور 8 کا code ہے; tools کانسیپٹ 8 سے آتا ہے۔

shopping_agent = Agent(
    name="ShoppingAgent",
    instructions="""Help the user shop. Workflow:
    1. Use acp_browse_merchant to find products matching the request
    2. Show matched items; wait for the user to confirm
    3. On confirm, use acp_create_cart_and_checkout to buy
    4. Use acp_check_order for status
    5. Use acp_refund only when the user asks""",
    tools=[acp_browse_merchant, acp_create_cart_and_checkout, acp_check_order, acp_refund],
    model="gpt-5.5",
)

اتپادن میں ناکامی کی سبسے ادھک سنبھاونا ہے۔ Cart بیمیل: agent ایک cart بناتا ہے جو request سے میل نہیں کھاتا ہے ("میں نے لال مانگا, گلابی ملا")۔ ٹھیک کریں: SPT کو ڈھالنے سے پہلے استعمالکرتا کو cart کی پشٹ کرنے, cart-سٹیکتا لاگ کرنے اور سٹیکتا 95% سے کم ہونے پر نردیشوں کو ٹیون کرنے کی ضرورت ہوتی ہے۔

اسے ٹکاؤ ڈھنگ سے چلانا (Inngest)۔ cart-پشٹ گیٹ کے لئے کانسیپٹ 8 سے step.wait_for_event پیٹرن کا استعمال کریں, ساتھ ہی پرت-استعمالکرتا سمورتی کیپ بھی۔

پہلے اسے چنیں۔ یہ آج کا لائو استعمال ماملا ہے: ChatGPT Instant Checkout, ACP پارستھتکی تنتر, ACP چالو ہونے کے ساتھ ہر Shopify merchant۔ ید آپ کیول ایک composition بھیج سکتے ہیں, تو اسے بھیجیں۔

فیصلہ 2: API-paying انسندھان agent (کیول x402 پیٹرن)

استعمال کا ماملا۔ آپ ایک شودھ agent کا نرمان کر رہے ہیں جو data کے لئے تیسرے پکش کو APIs کا بھگتان کرتا ہے: وتیی فیڈ, سماچار, وشیش کھوج۔ یہ Agent.market جیسی نردیشکا کے مادھیم سے runtime پر بھگتان کئے گئے APIs کا پتا لگاتا ہے, مولی کے مکابلے لاگت کا وجن کرتا ہے, اور پرت کال بھگتان کرتا ہے۔ $0.001 سے $0.50 کی اچ-آورت micropayments, کاری شرو ہونے کے باد لوپ میں کوئی مانو نہیں, کوئی commerce جیونچکر نہیں۔

چار پرتوں پر چلنا۔

• layer 1 (Discovery). Agent.market اور سمان x402-paywalled نردیشکائیں agent کو runtime پر سیوائیں ڈھونڈھنے دیتی ہیں; MCP servers x402 سمرتھن ہینڈل کے ساتھ پورو-ایکیکرت۔ وکلپ: agent.مارکیٹ پلس MCP-وایا-کلاؤڈپھlayer, runtime discovery پری-وایرڈ فالبیک سیٹ کے ساتھ۔
• پرتیں 2 اور 4 (Authorization اور Settlement, ڈھہ گئیں)۔ کاری شرو ہونے کے باد کوئی مانو نہیں۔ wallet کی on-chain پرت-لین-دین کھرچ حدبدھ ہے; استعمالکرتا-ستریی کیپ ہر بھگتان tool پر SDK tool_input_guardrail کے مادھیم سے چلتے ہیں۔ EIP-3009 signature authorization اور نپٹان دونوں ہے۔ وکلپ: x402 Base (USDC) پر, بنا کسی الگ mandate protocol کے۔
• پرت 3 (Commerce). "کھریداری" کیول ایک API کال ہے۔ وکلپ: کوئی نہیں, x402 کے مادھیم سے سیدھے API پہنچ۔

کاریانوین۔ یہ تصور 10 کا code ہے; tools کانسیپٹ 10 سے آتا ہے۔

research_agent = Agent(
    name="ResearchAgent",
    instructions="""Research the user's query by paying for data via x402.
    1. Use x402_search_agent_market to find relevant paid services
    2. Use x402_fetch to pull data (max $0.10 per call)
    3. Write up the findings
    Stay under $10 per session.""",
    tools=[x402_fetch, x402_search_agent_market],
    mcp_servers=[research_mcp_with_payments],
    model="gpt-5.5",
    # Spend caps live on x402_fetch via tool_input_guardrails
    # (Concept 10's enforce_x402_session_cap), not on the agent.
)

اتپادن میں ناکامی کی سبسے ادھک سنبھاونا ہے۔ اٹکے ہئے چکر سے اتیدھک کھرچ: agent اسی data کو پھر سے لاتا ہے اور بجٹ کو ختم کر دیتا ہے۔ ٹھیک کریں: wallet کے on-chain کیپ (سرکشا جو واستو میں آپکی رکشا کرتی ہے), SDK ستر-ویی guardrails, اور ایک ڈڈءاپ کیش تاک سمان فیچ دوبارا بھگتان ن کریں۔

اسے ٹکاؤ ڈھنگ سے چلانا (Inngest)۔ step.run میموئزیشن سے یہاں لابھ ملتا ہے۔ ستر کے مدھی میں کریش ہو گیا اور retry پہلے سے بھگتان کئے گئے data کے ساتھ پھر سے شرو ہو گیا۔ ایک پرت-استعمالکرتا سمورتی حد ایک برسٹ کو کاریبھار سنبھالنے سے روکتی ہے۔

شدھ مشین-ٹو-مشین۔ Layers 2 اور 4 ایک signature میں ڈھہ جاتے ہیں, اور Layer 3 کھالی ہے۔ یہ stack فیصلہ 1 کی تلنا میں سنرچناتمک روپ سے سرل ہے: کم protocols, کم ایکیکرن بند, پرت کال کم لاگت۔ ویاپار میں کوئی chargeback کور نہیں ہے اور کوئی commerce شبدارتھ نہیں ہے, جو ٹھیک ہے کیونک استعمال کے ماملے میں اسکی ضرورت نہیں ہے۔

فیصلہ 3: Enterprise procurement agent (AP2 پلس کنپوجڈ-سٹیک پیٹرن)

استعمال کا ماملا۔ آپ وتیی سیواؤں میں ونیمت enterprise کے لئے procurement agent کا نرمان کر رہے ہیں۔ کھریدار کاری سونپتے ہیں: "جمعہ تک ہمارے انمودت آپورتکرتاؤں سے $5,000 سے کم کیمت میں 50 ایرگونومک کیبورڈ کھریدیں۔" آڈٹ ٹریل کانونی روپ سے آوشیک ہے, کھرچ حد کئی ستروں پر چلتی ہے, اور آپورتکرتا پورو-انمودت ہوتے ہیں, اسلئے کوئی runtime کھوج نہیں ہوتی ہے۔

چار پرتوں پر چلنا۔

• پرت 1 (Discovery). آپورتکرتا سوچی پہلے سے جنات ہے۔ وکلپ: آپورتکرتا کیٹلاگ کے ساتھ ایک آنترک MCP server, کیونک discovery کا دایرا سیمت ہے۔
• layer 2 (Authorization). non-repudiable آڈٹ ٹریل وہ ہسا ہے جسے آپ چھوڑ نہیں سکتے ہیں; non-repudiable رکارڈ وہ ہے جسے ہستاکشرکرتا باد میں اسویکار نہیں کر سکتا ہے۔ AP2 mandates بلکہل ویسا ہی دیجئے۔ وکلپ: AP2, کاری نرمان پر ایک Intent Mandate کے ساتھ, checkout سے پہلے ایک Cart Mandate, اور settlement پر ایک Payment Mandate, ہر signed procurement ادھکاری دوارا۔
• پرت 3 (Commerce). بڑے آپورتکرتا ACP یا UCP کا کھلاسا کرتے ہیں; چھوٹے والے سیدھے B2B API کو اجاگر کرتے ہیں۔ وکلپ: ایسیپی-سکشم آپورتکرتاؤں کے لئے ACP, باکی کے لئے سیدھے API; agent دونوں کو سنبھالتا ہے۔
• پرت 4 (Settlement). آورتی آپورتکرتا MPP sessions کا پکش لیتے ہیں; one-off اچ مولیوں پر chargeback کور کے لئے card rails کھریدتا ہے۔ وکلپ: آورتی کے لئے MPP sessions, one-off کے لئے ACP SPT پلس card rails, آپورتکرتا اتہاس دوارا چنا گیا۔

کاریانوین۔ یہ اودھارناؤں 8, 9, اور 11 سے tools کی رچنا کرتا ہے۔

procurement_agent = Agent(
    name="ProcurementAgent",
    instructions="""Run procurement under audit-grade compliance:
    1. ALWAYS create an Intent Mandate first via ap2_create_intent_mandate
    2. Search approved suppliers via the internal MCP server
    3. Build the cart and create a Cart Mandate via ap2_create_cart_mandate
    4. Recurring suppliers: use an MPP session.
       One-off buys: use ACP plus card rails via ap2_settle_via_acp
    5. Record every mandate ID in the procurement audit log""",
    mcp_servers=[approved_suppliers_mcp],
    tools=[
        ap2_create_intent_mandate,
        ap2_create_cart_mandate,
        ap2_settle_via_acp,
        mpp_create_session,
        mpp_metered_call,
        mpp_close_session,
    ],
    model="gpt-5.5",
    # Caps and mandate rules run via tool_input_guardrails on the paying tools
    # (Concepts 9, 11, 15). require_intent_mandate on ap2_create_cart_mandate blocks
    # any cart with no prior Intent Mandate; enforce_per_run_spend_cap blocks any
    # payment over the user's run cap.
)

اتپادن میں ناکامی کی سبسے ادھک سنبھاونا ہے۔ Intent Mandate کا دایرا بیمیل ہے: ادھکاری mandate پر ہستاکشر کرتا ہے, agent کام کرتا ہے, تو cart جنادیش میں پھٹ نہیں بیٹھتا ہے۔ ٹھیک کریں: agent شرو ہونے سے پہلے mandate سکوپ کو مانی کریں shopping (کانسیپٹ 9 کا "پہلے ارادا Mandates بنائیں"), اور ان کاریوں کو اسویکار کریں جنکا دایرا استعمالکرتا دوارا ادھکرت حد سے ادھک ہے۔

اسے ٹکاؤ ڈھنگ سے چلانا (Inngest)۔ AP2 mandate signing step.wait_for_event کے لئے پراکرتک پھٹ ہے۔ ملٹی-سٹیج کاری پرت-استعمالکرتا سمورتی حد کے ساتھ, پرت چرن step.run کا استعمال کرتے ہیں۔

ونیمت ادیوگ۔ آڈٹ نیم AP2 کو Layer 2 پر لاگو کرتے ہیں; کئی آپورتکرتا ACP کو بادھی کرتے ہیں اور APIs کو Layer 3 پر ایک ساتھ نردیشت کرتے ہیں; آورتی بنام one-off MPP اور کارڈوں کو Layer 4 پر ایک ساتھ مجبور کرتا ہے۔ یہ composition فیصلہ 1 اور 2 سے بھاری ہے, اور آڈٹ ضرورت ہی وجن کو اچت ٹھہراتی ہے۔

فیصلہ 4: Multi-agent marketplace (AP2 پلس x402 پلس ERC-8004 پیٹرن)

استعمال کا ماملا۔ آپ ایک ایسا پلیٹفارم بنا رہے ہیں جہاں agents انی agents کو نیکت کرتا ہے۔ Agent A کو شودھ کی ضرورت ہے; Agent B انسندھان کو x402 سیوا کے روپ میں بیچتا ہے۔ کوئی بھی ابھی تک دوسرے پر بھروسا نہیں کرتا ہے, لین-دین تصدیق یوگی ہونا چاہئے, اور بھگتان بنا کسی کارڈ کے شدھ کرپٹو-مول ہے۔ Agent سے agent, $0.10 سے $100 پرت لیندین, دونوں پکشوں کو تصدیق یوگی پہچان کی ضرورت ہے۔

چار پرتوں پر چلنا۔

• پرت 1 (Discovery). Agent B اپنی کشمتا کو A2A پر پرکاشت کرتا ہے; Agent A اسے ڈھونڈھتا ہے۔ وکلپ: A2A, اسکے لئے بنایا گیا protocol۔
• پرت 2 (Authorization). لین-دین کے وقت کوئی مانو نہیں, لیکن وشواس دونوں تریکوں سے تصدیق یوگی ہونا چاہئے۔ AP2 mandates استعمالکرتا کی سہمت سابت کریں; ERC-8004 Agent B کو on-chain پرتشٹھا دیتا ہے Agent A پہلے جانچ کر سکتا ہے۔ وکلپ: پورن دوپکشیی تصدیق کے لئے AP2 پلس ERC-8004, composed۔
• پرت 3 (Commerce). کوئی cart نہیں, کوئی refunds, بس "یہ کاری کریں اور رپورٹ وترت کریں۔" وکلپ: کوئی نہیں, سیدھا A2A request اور پرتکریا۔
• پرت 4 (Settlement). کرپٹو-مول, اپ-سیکنڈ, کوئی chargeback کور کی ضرورت نہیں ہے۔ وکلپ: x402 a2a-x402 ایکسٹینشن کے مادھیم سے AP2 تک۔

کاریانوین۔ یہ A2A کھوج کے ساتھ اودھارنا 9 اور 10 سے tools بناتا ہے۔

researcher_hiring_agent = Agent(
    name="ResearcherHiringAgent",
    instructions="""Hire research-specialist agents to work for you:
    1. Use a2a_discover_researchers to find available agents
    2. Check ERC-8004 reputation (>50 successful jobs, no flagged disputes)
    3. Create an Intent Mandate scoped by amount and recipient
    4. Submit the task via A2A with the mandate attached
    5. Receive the result; settle via ap2_settle_via_x402""",
    tools=[
        a2a_discover_researchers,
        erc8004_check_reputation,
        ap2_create_intent_mandate,
        a2a_submit_task_with_mandate,
        ap2_settle_via_x402,
    ],
    model="gpt-5.5",
)

اتپادن میں ناکامی کی سبسے ادھک سنبھاونا ہے۔ جس پرتشٹھا کے ساتھ کھلواڑ کیا گیا ہے اس پر بھروسا کرنا: ERC-8004 سکور شروی ہیں لیکن ایک آپریٹر چھوٹی سپھل نوکریوں کے ساتھ اسے بڑھا سکتا ہے۔ ٹھیک کریں: پرتشٹھا کو انی سنکیتوں (آپریٹر identity, لین-دین-ماترا حد, dispute اتہاس) کے ساتھ سنیوجت کریں, اور پہلی بار پرتپکشیوں کے لئے ایک نردھارت راش سے اوپر مانو وقتکشا جوڑیں۔

اسے ٹکاؤ ڈھنگ سے چلانا (Inngest)۔ ایک ساتھ کئی وشیشجنوں کو کام پر رکھنے پر پھین آؤٹ; ہر پرنام کے لئے step.wait_for_event اور پرت چرن step.run کا استعمال کریں۔ یہ فیصلہ ہر Inngest آدم کو چھوتا ہے۔

شدھ بہ-agent ارتھویوستھا۔ لین-دین کے وقت لوپ میں کوئی بھی انسان نہیں; دونوں agents pre-authorized دایرے کے اندر کاری کرتے ہیں۔ agent ارتھویوستھا اسی آکار کے آسپاس بنائی جا رہی ہے, اور اوقتں سبسے ادھک ناکامی کے طریقے ہیں, کیونک بنا کسی پورو سنبندھ کے دوپکشیی وشواس کٹھن ہے اور protocol stack کیول آنشک روپ سے ہی اسکا سمادھان کرتا ہے۔

فیصلہ 5: ایک گیر-Stripe, گیر-اوپنAI stack (framework یاترا کو سابت کرنا)

اب تک ہر code نمونے میں stripe.PaymentTokens.create(...) اور OpenAI Agents SDK کا استعمال کیا گیا ہے۔ وے ACP کے لئے سبسے پرپکو ایکیکرن ہیں اور SDK اس کورس کا runtime ہے, لیکن چار-پرت واستکلا ڈجائن دوارا سٹیک-اجنییوادی ہے, اور ایک کورس جو کیول ایک stack دکھاتا ہے, اس نے یہ سابت نہیں کیا ہے۔ تو یہ فیصلہ فیصلہ 2, API-paying انسندھان agent کو ایک پوری طرح سے الگ toolچین پر پنرنرمان کرتا ہے: Google کا Agent ڈیولپمینٹ کٹ (ADK) runtime کے لئے, ایک Coinbase smart-contract wallet on-chain identity, AP2 mandates authorization کے لئے, اور نپٹان کے لئے سیدھے x402۔ شونی Stripe, شونی OpenAI۔

استعمال کا ماملا فیصلہ 2 پر کایم ہے۔ ایک شودھ agent پرت کال $0.001 سے $0.10 کا بھگتان کرتا ہے, جسکی حد پرت ستر $10 ہے۔ اپ-ڈالر, authorization, machine-to-machine نپٹان کے باد کوئی مانو نہیں۔ آرکٹیکچر فیصلہ 2 کا بھی بنا رہتا ہے: x402 Layers 2 اور 4 کو دھوست کر دیتا ہے, کھوج کے لئے کوئی commerce layer, MCP نہیں ہے۔ کیول library بدلتا ہے۔

note

نیچے دیا گیا بلاک اداہرناتمک ہے۔ Google ADK سنرچنا (Agent, tool ڈیکوریٹر) واستوک ہے اور google-adk ایک واستوک پیکیج ہے۔ بھگتان ٹکڑے سٹینڈ-ان ہیں: AP2 کا واستوک پیکیج ap2 ہے جس میں بہت الگ mandate فیلڈ ہیں اور کوئی MandateSigner ورگ نہیں ہے, Coinbase wallet کو coinbase_agentkit کے SmartWalletProvider اور ایک لائو کے مادھیم سے کانفگر کیا گیا ہے x402 کال کے لئے ایک وت پوشت account اور ایک واستوک 402 سماپن بند کی ضرورت ہوتی ہے۔ یہاں کوئی واستوک پیسا نہیں چلتا۔ بات آکار کی ہے, حصہے ہئے کھریدار کی نہیں۔

from google.adk import Agent
from google.adk.tools import function_tool  # ADK's tool decorator
from coinbase_agentkit import AgentKit, SmartWalletProvider
from decimal import Decimal
from datetime import datetime, timedelta

# Shared result models come from the Pydantic sidebar in Part 3.
from .models import X402PaymentResult, PaymentToolResult, DiscoveryResult

# --- Illustrative stand-ins for the payment rails (real APIs differ) ---
class MockMandate:
    def __init__(self, mid, rules=None): self.id, self.rules = mid, (rules or {})
class MockSigner:
    async def sign(self, mandate): return mandate          # real AP2 signs over A2A
agent_market_client = type("Mock", (), {"search": staticmethod(lambda **k: [])})()
x402_client = type("Mock", (), {})()                       # real client: x402-client
# -----------------------------------------------------------------------

# Layer 2 (Authorization): a Coinbase smart-contract wallet gives the agent its
# on-chain identity and its spend caps. This is the analog of a Stripe customer
# plus per-customer caps, but enforced by the chain.
wallet_provider = SmartWalletProvider(
    config={
        "chain": "base-mainnet",
        "spend_limits": {
            "per_transaction_usdc": Decimal("0.50"),
            "per_session_usdc": Decimal("10.00"),
            "per_day_usdc": Decimal("100.00"),
        },
    },
)
agent_kit = AgentKit(wallet_provider=wallet_provider)

# Layer 2 (Authorization): an AP2 Intent Mandate, signed by the user at session start.
# The analog of a signed, revocable Stripe authorization, but declarative.
async def create_research_intent_mandate(user_did, user_signer, session_cap_usdc):
    mandate = MockMandate(
        "intent_mock_1",
        rules={
            "max_total_usd": str(session_cap_usdc),
            "allowed_categories": ["data-api", "research-service"],
            "expires_at": (datetime.utcnow() + timedelta(hours=1)).isoformat(),
        },
    )
    return await user_signer.sign(mandate)

# Layer 1 (Discovery) + Layer 4 (Settlement) as one tool.
# ADK's @function_tool is the analog of the SDK's @function_tool.
@function_tool
async def x402_paid_fetch(url: str, max_payment_usdc: Decimal) -> X402PaymentResult | PaymentToolResult:
    """Fetch a URL that may need x402 payment up to max_payment_usdc.
    The wallet handles the signature; the on-chain cap is the safety that protects you."""
    # ADK has no tool_input_guardrail, so the check runs in-tool,
    # backed by the wallet's on-chain cap (the layer nothing can bypass).
    resp = await x402_client.get(url, max_payment_usdc=max_payment_usdc)
    return X402PaymentResult(
        content=resp.content,
        amount_paid_usdc=Decimal(str(resp.amount_paid_usdc)),
        tx_hash=resp.tx_hash,
    )

@function_tool
async def search_agent_directory(query: str, max_price_per_call_usdc: Decimal) -> list[DiscoveryResult]:
    """Search Agent.market for x402-paywalled services."""
    results = await agent_market_client.search(query=query, max_price_per_call_usdc=max_price_per_call_usdc)
    return [
        DiscoveryResult(
            service_id=r.service_id,
            name=r.name,
            description=r.description,
            price_per_call_usdc=Decimal(str(r.price_per_call_usdc)),
            endpoint_url=r.endpoint_url,
        )
        for r in results
    ]

# The agent itself: a Google ADK Agent, the direct analog of the SDK's Agent.
research_agent = Agent(
    name="research-agent",
    description="Research the user's query by paying for data via x402.",
    instructions="""Research the query.
    1. Use search_agent_directory to find relevant paid services
    2. Use x402_paid_fetch to pull data ($0.50 max per call)
    3. Write up the findings
    Stay under $10 per session.""",
    model="deepseek-v4-flash",  # illustrative; any ADK-compatible model id works
    tools=[search_agent_directory, x402_paid_fetch],
)

# Driver: the user signs the Intent Mandate once at session start;
# the agent then runs on its own inside the mandate's scope until the session ends.
async def run_research_session(user_did, user_signer, query):
    intent = await create_research_intent_mandate(
        user_did=user_did,
        user_signer=user_signer,
        session_cap_usdc=Decimal("10.00"),
    )
    return await research_agent.run_async(
        query,
        context={"intent_mandate": intent, "wallet": agent_kit},
    )

پنکت-در-پنکت انواد۔ بائیں اور فیصلہ 2 کا OpenAI پلس Stripe code, دائیں اور فیصلہ 5 کا Google ADK پلس Coinbase code۔ یہ تالکا لابھپرد ہے: ہر پنکت ایک الگ نام کے تہت ایک ہی اودھارنا ہے۔

فیصلہ 2 (OpenAI + Stripe)	فیصلہ 5 (Google ADK + Coinbase)	سمان اودھارنا, بھن library
from agents import Agent, function_tool	from google.adk import Agent + from google.adk.tools import function_tool	Agent runtime
@function_tool (OpenAI Agents SDK)	@function_tool (Google ADK)	Tool ڈیکوریٹر
RunContextWrapper	context={...} کوارگ سے run_async	پرت-رن اوستھا
کیپ کے لئے stripe.Customer.modify(...)	SmartWalletProvider(spend_limits={...})	کھرچ کیپس, چین-دیشی
tool_input_guardrail ڈیکوریٹر	ان-tool چیک + wallet کیپس	نشپادن پورو تصدیق
Runner.run(agent, ...)	agent.run_async(...)	Agent نشپادن

کیا سمان رہتا ہے۔ آرکٹیکچر: Layer 1 MCP یا ایک نردیشکا ہے, Layer 2 ایک mandate پلس wallet کیپس ہے, Layer 3 کوئی نہیں ہے (machine-to-machine ڈھہ جاتا ہے commerce), Layer 4 x402 ہے۔ primitives: Intent Mandate, EIP-3009 signatures, 402 پرتکریائیں, بھگتان-ہستاکشر headers, on-chain کھرچ حد۔ framework وہ ہے جو library سویپ سے بچتا ہے۔

دو واستوک پرچالن انتر۔

1. Google ADK میں کوئی پرتھم شرینی tool input guardrail نہیں ہے (2026 کے مدھی تک)۔ SDK کا tool_input_guardrail واستو میں پورو-نشپادن جانچ کے لئے استعمالی ہے; ADK کے tool ڈیکوریٹر کا ابھی تک کوئی پرتیکش سمککش نہیں ہے۔ سمادھان wallet کے on-chain کیپس دوارا سمرتھت ان-tool تصدیق ہے۔ ٹوپیاں ابھی بھی آپکی رکشا کرتی ہیں; ان-tool جانچ تیزی سے وپھل ہو جاتی ہے۔ ADK چنیں اور آپ ایک الگ ملٹی-agent کہانی کے لئے guardrail سودھا کا ویاپار کرتے ہیں۔
2. AP2 mandate signing یہاں ادھک مول ہے۔ Google نے AP2 بنایا ہے, اسلئے ADK پارستھتکی تنتر جنادیش-ہستاکشر UI پرواہ کو ادھک سپشٹ روپ سے ایکیکرت کرتا ہے۔ ید آپکا استعمال ماملا انواری-کٹھور authorization (فیصلہ 3 اور 4) پر منحصر کرتا ہے, تو ADK پلس AP2 ایک واستوک وکلپ ہے, ن ک کیول ایک وکلپ۔

فیصلہ 5 کی نچلی پنکت: چار-پرت واستکلا چھپی ہوئی Stripe-اینڈ-اوپنAI کہانی نہیں ہے۔ Discovery, Authorization, Commerce, Settlement, پرت layer ایک protocol چنیں, اسے استعمال کے ماملے میں اچت ٹھہرائیں: جو کسی بھی library سویپ سے بچتا ہے۔ فیصلہ 5 نے فیصلہ 2 کے سمان ہی composition بنانے کے لئے Google ADK اور ایک Coinbase wallet کا استعمال کیا; کیول آیات بدل گیا۔ ید ایک framework کو ایک الگ stack میں شخص نہیں کیا جا سکتا ہے, تو یہ ایک پوشاک پہنے ہئے library ٹیوٹوریل ہے۔ یہ والا نہیں ہے.

---

حصہ 6: Production چنتائیں: جب سسٹم لائو ہوتا ہے تو آپکو کیا مارتا ہے

حصہ 1 سے 5 تک framework کا نرمان کیا اور واستوک فیصلہ لئے۔ حصہ 6 ان چیزوں کو شامل کرتا ہے جو یہ تی کرتی ہیں ک آپکا stack واستوک استعمالکرتاؤں تک جیوت رہے گا یا نہیں۔ یہ وے ناکامیئیں ہیں جو ڈیمو میں دکھائی نہیں دیتیں اور رات 2 بجے دکھائی دیتی ہیں۔

پاٹھک ٹریک

ید آپ سمجھنے کے لئے پڑھ رہے ہیں, بھیجنے کے لئے نہیں, تو آپ حصہ 6 کو پڑھ سکتے ہیں۔ ید آپ اوقتں سے کچھ بھی واستوک روپ سے بنا رہے ہیں, تو یہ وہ جگہ ہے جہاں یہ واستوک ہو جاتا ہے۔ یہاں چار اودھارنائیں کام کرنے والی پرنالی اور بٹئے کو کھتم کرنے والی پرنالی کے بیچ انتر ہیں۔

تصور 15: Spend-limit تین واستشلپ ستروں پر پرورتن

ایک پنکت میں: تین سوتنتر ستھانوں پر حد لاگو کرکے ایک agent کو ادھک کھرچ کرنے سے روکیں, تاک ایک میں ایک بگ انی دو دوارا پکڑا جا سکے۔

ایک agent-commerce پرنالی کے بری طرح وپھل ہونے کا سبسے بڑا تریکا سرل ہے: agent انمت سے ادھک کھرچ کرتا ہے۔ ایک اٹکا ہءآ agent loop سیکنڈ میں wallet کو کھتم کر سکتا ہے۔ ہر protocol کی اپنی حد ہوتی ہے (ACP کی SPT راش, MPP کی session ٹوپی, x402 کی per-request ادھکتم), لیکن انمیں سے کوئی بھی اپنے آپ میں پریاپت نہیں ہے۔ Production سسٹم تین الگ-الگ ستروں پر spend limits لاگو کرتے ہیں۔

ستر 1: wallet اور payment-method حدئیں۔ یہ وہ ٹوپی ہے جو واستو میں آپکی سرکشا کرتی ہے۔ agent کے smart-contract wallet (x402 کے لئے) یا اسکے Stripe گراہک account (ACP اور MPP کے لئے) بنیادی ڈھانچے کے ستر پر نردھارت کھرچ حد رکھتا ہے۔ شرنکھلا یا Stripe انہیں لاگو کرتی ہے چاہے agent code کچھ بھی کرے۔ یہ ایکماتر ستر ہے جو تب کایم رہتا ہے جب agent loop پوری طرح سے وپھل ہو جاتا ہے۔

x402 کے لئے smart-contract wallet کے ساتھ:

note

نیچے دیا گیا SmartContractWallet.deploy(...) کال اداہرناتمک ہے۔ یہ دکھاتا ہے ک لیول 1 کیپ کہاں رہتے ہیں, واستوک پپ پیکیج نہیں۔ رویہ میں آپ ان کیپس کو واستوک smart-contract wallet پر سیٹ کرتے ہیں (اداہرن کے لئے Coinbase AgentKit کے SmartWalletProvider کے مادھیم سے)۔ ترستریی انشاسن ہی واستوک پاٹھ ہے۔

from decimal import Decimal

# Set ONCE when the wallet is deployed. The agent cannot change this.
wallet_spend_limits = {
    "max_per_transaction_usdc": Decimal("10.00"),    # cap per single transfer
    "max_per_day_usdc": Decimal("100.00"),           # rolling 24-hour cap
    "max_per_merchant_usdc": Decimal("50.00"),       # cap to any single recipient
}
agent_wallet = SmartContractWallet.deploy(
    owner=user_did,
    spend_limits=wallet_spend_limits,
    chain="eip155:8453",  # Base
)

ACP یا MPP کے ساتھ Stripe کے لئے, حد Stripe گراہک پر رہتی ہے:

stripe.Customer.modify(...) ایک واستوک Stripe API کال ہے۔ یہ آپ کے Stripe کھاتے کے وردھ چلتا ہے۔

# Set once via the Stripe Dashboard or API. The caps live in Stripe's infrastructure.
stripe.Customer.modify(
    user_session.stripe_customer_id,
    metadata={
        "max_per_session_usd": "500",
        "max_per_day_usd": "2000",
    },
)
# When an SPT or MPP session is minted above these, Stripe rejects it at the API level.

ستر 2: SDK tool guardrail۔ OpenAI Agents SDK کا tool_input_guardrail ہر بھگتان tool نشپادت ہونے سے پہلے چلتا ہے اور کال کو اسویکار کر سکتا ہے۔ آپ اسے اودھارنا 5 میں دیکھ چکے ہیں: یہ کسی بھگتان کو ہونے سے پہلے روکنے کا SDK-دیشی تریکا ہے, اور پروار وقت پر چلتا ہے۔ یہاں اسکا پورا الاج ہوتا ہے, کیونک یہ پورے کورس کے لئے وہت guardrail بلاک ہے۔ نیچے دیا گیا code اصل ہے اور چلتا ہے۔

import json
from decimal import Decimal
from agents import Agent, function_tool, RunContextWrapper
from agents.tool_guardrails import (
    tool_input_guardrail,
    tool_output_guardrail,
    ToolInputGuardrailData,
    ToolOutputGuardrailData,
    ToolGuardrailFunctionOutput,
)

# Tool INPUT guardrail: pre-payment check. Runs BEFORE the tool executes.
@tool_input_guardrail
def enforce_per_run_spend_cap(data: ToolInputGuardrailData) -> ToolGuardrailFunctionOutput:
    """Reject any payment tool call where the run's total spend would exceed the user's cap.
    Runs before the tool executes, the only guardrail family that can stop a payment in time."""
    args = json.loads(data.context.tool_arguments or "{}")          # raw JSON args string -> dict
    requested = Decimal(str(args.get("max_total_usd") or args.get("max_payment_usdc") or 0))
    ctx = data.context.context                                       # the run context (a dict)
    cap = Decimal(str(ctx["user_session"].per_run_spend_cap_usd))
    spent = Decimal(str(ctx.get("run_spend_usd", 0)))
    if spent + requested > cap:
        return ToolGuardrailFunctionOutput.reject_content(
            f"Refused: would spend ${spent + requested}, run cap is ${cap}"
        )
    return ToolGuardrailFunctionOutput.allow()

# Tool OUTPUT guardrail: post-payment check. Runs AFTER the tool executes.
# Useful for verifying receipts (paid more than expected, wrong amount, etc.).
@tool_output_guardrail
def verify_receipt_integrity(data: ToolOutputGuardrailData) -> ToolGuardrailFunctionOutput:
    output = data.output or {}
    if isinstance(output, dict) and "amount_paid_usdc" in output:
        # Cross-check the receipt against what we asked for.
        pass
    return ToolGuardrailFunctionOutput.allow()

# Attach BOTH guardrails to every payment-authorizing tool.
@function_tool(
    tool_input_guardrails=[enforce_per_run_spend_cap],
    tool_output_guardrails=[verify_receipt_integrity],
)
async def x402_fetch(
    ctx: RunContextWrapper,
    url: str,
    max_payment_usdc: Decimal,
) -> "X402PaymentResult":
    ...

# An agent-level output_guardrail is fine for final-reply safety
# (like redacting PII in the agent's answer), but it does NOT prevent payments.
agent = Agent(
    name="ShoppingAgent",
    tools=[x402_fetch],
    # output_guardrails=[response_safety_guardrail],  # different job, not payment safety
)

سہی guardrail پروار کا استعمال کریں

SDK میں تین guardrail پروار ہیں۔ agent کو استعمالکرتا کے پہلے سندیش پر انپٹ guardrails چلتا ہے۔ آؤٹپٹ guardrails انتم اتر agent پر چلتا ہے۔ Tool guardrails (tool_input_guardrail اور tool_output_guardrail) ہر کسٹم tool کال پر چلتے ہیں۔ بھگتان سرکشا کے لئے آپ وشیش روپ سے tool_input_guardrail چاہتے ہیں: یہ ایکماتر پروار ہے جو بھگتان tool چلنے سے پہلے سکری ہو جاتا ہے اور اسے بلاک کر سکتا ہے۔ کھرچ کو نینترت کرنے کے لئے output_guardrail تک پہنچنا agent-commerce code میں سبسے آم غلطی ہے۔ جب تک آگ لگتی ہے, پیسا کھتم ہو جاتا ہے۔

ستر 3: ایپلکیشن اور ویوسای-ترک حدئیں۔ آپکا اپنا code استعمالکرتا-وششٹ نیموں کو لاگو کرتا ہے: پرت-استعمالکرتا دینک حد, پرت-شرینی حد, انمت ویاپاری۔ یہیں پر ویاوسایک نیم رہتے ہیں۔ "یہ استعمالکرتا کسی بھی merchant پر پرت دن $500 کھرچ کر سکتا ہے, لیکن استیاپت پر کیول $50 پرت دن۔" وہ نیم یہیں ہے, کسی protocol میں نہیں۔ یہ code سادا Python اور اصل ہے۔

from decimal import Decimal

class UserSession:
    def can_spend(self, amount_usd: Decimal, merchant_id: str) -> bool:
        # Per-day cap
        if self.today_spend_usd + amount_usd > self.daily_cap_usd:
            return False
        # Per-merchant cap
        merchant_cap = self._merchant_cap_for(merchant_id)
        if self.merchant_spend_usd[merchant_id] + amount_usd > merchant_cap:
            return False
        # Per-category cap (for example, "office supplies" vs "personal")
        category = self._category_for(merchant_id)
        if self.category_spend_usd[category] + amount_usd > self.category_caps[category]:
            return False
        return True

ہر ستر الگ-الگ بنیادی ڈھانچے میں رہتا ہے۔ لیول 1 چین یا Stripe میں ہے۔ لیول 2 agent SDK میں ہے۔ لیول 3 آپ کے ایپلکیشن code میں ہے۔ ایک میں موجود بگ کو انی دو دوارا پکڑ لیا جاتا ہے۔ لیول 1 چھوڑیں اور ایک agent-لوپ بگ پورے wallet کو کھتم کر سکتا ہے۔ ستر 2 کو چھوڑیں اور آپ اڑان کے بیچ میں دوڑ کو رد کرنے کی شکت کھو دینگے۔ ستر 3 چھوڑیں اور آپ پرت-استعمالکرتا یا پرت-شرینی نیت لاگو نہیں کر سکتے۔

جال کیول protocol کیپس پر بھروسا کر رہا ہے۔ ACP کی SPT کیپ, MPP کی session کیپ, اور x402 کی per-request ادھکتم protocol-ستر کی حدئیں ہیں۔ وے وششٹ protocol درپیوگ کو روکتے ہیں, لیکن وے سبھی protocol میں شامل نہیں ہوتے ہیں۔ کیول $50 کی حد والے ACP SPT کا استعمال کرنے والی ٹیم کو کل $5,000 کے لئے لگاتار 100 agent بنانے سے کوئی سرکشا نہیں ملتی ہے۔ اپروکت تین ستر سٹیک روپ سے موجود ہیں کیونک protocol کیپ ایکتر نہیں ہوتے ہیں۔

اودھارنا 16: Agent identity سوچھتا: کنجیاں, wallets, اور audit logs

ایک پنکت میں: agent کے signing کنجی ادھکرت کھرچ کو دھوکھادھڑی سے الگ کرنے والی ایکماتر چیج ہے, اسلئے آپ کنجی کی رکشا کرتے ہیں, اسے agent کے انسار الگ کرتے ہیں, اسے گھماتے ہیں, اور ہر کھرچ کو durable سٹوریج میں لاگ کرتے ہیں۔

Agent commerce ایک ناکامی لاتا ہے جو سوایت پرنالیوں کے لئے ادوتیی ہے: agent کا کرپٹوگراپھک identity وہ سب ہے جو واستوک کھرچ اور دھوکھادھڑی کے بیچ کھڑا ہے۔ ید signing کنجی لیک ہو جاتی ہے, تو wallet (یا Stripe گراہک, یا AP2 mandate ہستاکشرکرتا) کو تب تک کھالی یا پرتروپت کیا جا سکتا ہے جب تک آپ کنجی کو گھماتے نہیں۔ Identity سوچھتا آدتوں کا سموہ ہے جو اسے روکتا ہے۔ وہاں چار ہیں۔

1. پرت-agent wallet پرتھکرن۔ ہر agent, یا agent کے ہر ورگ کو اپنا سویں کا wallet یا بھگتان ہینڈل ملتا ہے۔ وبھن نوکریوں کے ساتھ کبھی بھی agents میں signing کنجیاں ساجھا ن کریں۔ ید آپکا shopping agent اور آپکا procurement agent ایک wallet ساجھا کرتے ہیں, تو دونوں میں سے کسی ایک کا سمجھوتا سماپت ہو جاتا ہے۔ الگ wallets لاگت لگبھگ کچھ بھی نہیں (ایک بار کی تیناتی لاگت) اور سرکشا لابھ واستوک ہے۔

SmartContractWallet.deploy(...) اداہرناتمک ہے, جیسا ک تصور 15 میں ہے۔ پیٹرن ہی ماینے رکھتا ہے: پرت agent ورگ میں ایک wallet, کبھی ساجھا نہیں کیا گیا۔

# Wrong: one wallet shared across agents
shared_wallet = SmartContractWallet.deploy(...)
shopping_agent.wallet = shared_wallet
procurement_agent.wallet = shared_wallet
research_agent.wallet = shared_wallet  # one compromise drains all three

# Right: a separate wallet per agent class
shopping_agent.wallet = SmartContractWallet.deploy(
    spend_limits={"max_per_day_usdc": 100},
)
procurement_agent.wallet = SmartContractWallet.deploy(
    spend_limits={"max_per_day_usdc": 1000, "allowed_recipients": [...]},
)
research_agent.wallet = SmartContractWallet.deploy(
    spend_limits={"max_per_day_usdc": 50, "max_per_call_usdc": 0.50},
)

2. Key rotation, ایک شیڈیول پر اور مانگ پر۔ signing کنجیوں کو آدھار ریکھا کے روپ میں ہر 90 دنوں میں گھمائیں (API کنجیوں کے لئے Stripe کی مشورہ سے میل کھاتے ہئے)۔ جب کوئی agent آپریٹر ٹیم چھوڑتا ہے, جب کوئی پرنیوجن signing ستہ کو چھوتا ہے, یا جب کچھ غلط دکھتا ہے, تو انہیں فوراً گھمائیں۔ گھومنے کی آدت دنوں کی سٹیک سنکھیا سے ادھک ماینے رکھتی ہے۔

note

نیچے دیا گیا پیٹرن واستوک ہے. client نام azure_key_vault اداہرناتمک ہے; اپنے پرداتا کے والٹ SDK کا استعمال کریں۔ مدا یہ ہے ک چابی تجوری میں رہتی ہے اور آپ استعمال کے وقت ورتمان version پڑھتے ہیں۔

# Read the current key version from the vault. The version changes when the key rotates.
def get_signing_key(agent_class: str) -> SigningKey:
    return azure_key_vault.get_latest_version(
        secret_name=f"agent-wallet-signing-key-{agent_class}",
    )

# Old transactions, signed with the previous version, stay valid until they expire.
# New transactions use the current version.

3. Audit logs جو درگھٹنا سے بچ جاتا ہے۔ ہر authorization فیصلہ durable سٹوریج میں لاگ ہو جاتا ہے جو agent کے runtime سے الگ رہتا ہے: ہر SPT کھنن, ہر mandate signed, ہر x402 signature, ہر MPP session کھولا گیا۔ ید agent کریش ہو جاتا ہے, تو آڈٹ لاگ ابھی بھی وہاں ہونا چاہئے۔ Neon Postgres پلس Inngest کا چرنبدھ سنسمرن آپکو یہ دیتا ہے; آپ ادھکتم ستھایتو کے لئے سیدھے آبجیکٹ سٹوریج (S3 یا سمککش) پر بھی لکھ سکتے ہیں۔

note

آڈٹ-لاگ پیٹرن شکشن ہے۔ client نام neon_client اداہرناتمک ہے; اپنے سویں کے database client کا استعمال کریں۔ نیم یہ ہے ک بھگتان ہونے سے پہلے فیصلہ کو لاگ ان کیا جائے۔

# Every payment-authorizing action logs to durable storage BEFORE the action completes.
@function_tool
async def acp_create_cart_and_checkout(
    ctx: RunContextWrapper,
    merchant_id: str,
    items: list["CartItem"],
    max_total_usd: Decimal,
) -> "CheckoutResult":
    audit_id = str(uuid4())

    # Log the authorization decision FIRST, before any payment happens.
    await neon_client.audit_log.insert({
        "audit_id": audit_id,
        "agent_class": ctx.context["agent_class"],
        "user_did": ctx.context["user_session"].did,
        "action": "acp_create_cart_and_checkout",
        "merchant_id": merchant_id,
        "max_total_usd": max_total_usd,
        "timestamp": datetime.utcnow().isoformat(),
        "status": "initiated",
    })

    try:
        result = await _actually_complete_checkout(merchant_id, items, max_total_usd)
        await neon_client.audit_log.update(audit_id, {
            "status": "completed",
            "actual_total_usd": result.total_charged_usd,
            "order_id": result.order_id,
        })
        return result
    except Exception as e:
        await neon_client.audit_log.update(audit_id, {"status": "failed", "error": str(e)})
        raise

4. پورے لین-دین میں traces وترت کیا گیا۔ آڈٹ لاگ آپکو بتاتا ہے ک کیا سپھل ہءآ۔ Traces آپکو بتاتا ہے ک کیا ہءآ, جس میں وپھل, پن: پریاس یا رکی ہوئی کال بھی شامل ہیں۔ agent commerce میں پورن trace اکسر وپھل لیندین کو ڈیبگ کرنے کا ایکماتر تریکا ہوتا ہے, کیونک ایک استعمالکرتا request ایک SDK رن, 5 سے 10 tool calls, 2 یا 3 protocol HTTP انرودھوں کو پورا کر سکتا ہے۔ Stripe webhook جو باد میں آتا ہے, اور ایک Inngest function جو گھنٹوں باد پھر سے شرو ہوتا ہے۔ ایک trace ID کے بنا ان سبکو ایک ساتھ جوڑے بنا, پوسٹمارٹم اسنبھو ہے۔ نیچے دیا گیا OpenTelemetry code واستوک, ستھر OTel API ہے۔

from opentelemetry import trace
from opentelemetry.trace import Status, StatusCode

tracer = trace.get_tracer("agent-commerce")

@function_tool
async def acp_create_cart_and_checkout(
    ctx: RunContextWrapper,
    merchant_id: str,
    items: list["CartItem"],
    max_total_usd: Decimal,
) -> "CheckoutResult":
    # The span name is the protocol action; attributes capture what you filter by
    # in your observability tool (Datadog, Honeycomb, Grafana, and so on).
    with tracer.start_as_current_span(
        "acp.checkout",
        attributes={
            "agent.class": ctx.context["agent_class"],
            "user.did": ctx.context["user_session"].did,
            "acp.merchant_id": merchant_id,
            "acp.max_total_usd": float(max_total_usd),
            "acp.item_count": len(items),
        },
    ) as span:
        try:
            result = await _actually_complete_checkout(merchant_id, items, max_total_usd)
            span.set_attribute("acp.order_id", result.order_id)
            span.set_attribute("acp.actual_total_usd", float(result.total_charged_usd))
            span.set_status(Status(StatusCode.OK))
            return result
        except Exception as e:
            span.set_status(Status(StatusCode.ERROR, str(e)))
            span.record_exception(e)
            raise

trace حوالہ سہی اپکرن کے ساتھ httpx, openai-agents اور Inngest کے مادھیم سے سوچالت روپ سے پرواہت ہوتا ہے۔ جب اس آرڈر پر dispute کے لئے Stripe webhook 20 منٹ باد آتا ہے, تو webhook handler order کے metadata میں موجود trace_id کے مادھیم سے اسی trace سے جڑ جاتا ہے۔ ایک trace ID, پہلے request سے dispute رزالیوشن تک, لیندین کے پورے جیون کو کور کرتا ہے۔

Audit logs اور traces الگ-الگ سوالوں کے اتر دیتے ہیں, اور آپکو دونوں کی ضرورت ہے۔ Audit logs ویاوسایک سوالوں کا اتر دیں ("اس استعمالکرتا نے منگلوار کو کتنا کھرچ کیا?")۔ Traces ڈبگنگ سوالوں کا اتر دیں ("آدیش abc123 کے لئے checkout وپھل کیوں ہءآ?")۔ آڈٹ لاگ کیول سپھل پتھ کو رکارڈ کرتا ہے; یہ کبھی بھی اس کال کو کیپچر نہیں کرتا ہے جو کام کرنے سے پہلے پانچ بار پنہ پریاس کیا گیا تھا, یا protocol کال جو وقت سماپت ہونے سے پہلے 30 سیکنڈ کے لئے رکا ہءآ تھا۔ وے ناکامی آکرتیاں کیول انشوں میں دکھائی دیتی ہیں۔ traces کو چھوڑنا کیونک آپ کے پاس audit logs ہے, یہ ایک غلطی ہے ک ہر tool کس لئے ہے۔

سبسے آم identity غلطی wallet کے پتے کو agent کی پہچان کے روپ میں ماننا ہے۔ پتا ساروجنک ہے: کوئی بھی اسے بھیج سکتا ہے اور کوئی بھی یہ ستیاپت کر سکتا ہے ک اسسے کوئی لیندین ہءآ ہے۔ نجی signing کنجی identity ہے, اور آپ اسے ایک کنجی کے روپ میں سرکشت رکھتے ہیں۔ جو ٹیمیں signing کنجیوں کو پریاورن چر (یا اسسے بھی بدتر, ماخذ code میں) میں رکھتی ہیں, انہوننے agent کے identity کو ان رہسیوں تک پہنچ رکھنے والے کسی بھی شخص کو سونپ دیا ہے۔ چابیاں تجوری میں جاتی ہیں, کبھی بھی env vars میں نہیں۔

اودھارنا 17: چار protocols میں Dispute اور refund یانترکی

ایک پنکت میں: ہر protocol, disputes اور refunds کو الگ-الگ طریقے سے سنبھالتا ہے, اور آپ کے استعمال کے ماملے میں dispute model اکسر سبسے مجبوت چیج ہوتی ہے جو یہ تی کرتی ہے ک آپ کون سا protocols بناتے ہیں۔

چار protocols ہر disputes اور refunds کو اپنے طریقے سے رویہ کرتے ہیں, اور یہ انتر اکسر استعمال کے ماملے کے لئے protocol وکلپ تی کرتا ہے۔ ایک استعمال ماملا جسے chargeback سرکشا کی ضرورت ہے وہ شدھ x402 پر نہیں چل سکتا ہے۔ ایسا استعمال ماملا جہاں seller میں کوئی گراہک-سیوا سیٹءاپ نہیں ہے, ایسیپی کا استعمال نہیں کیا جا سکتا ہے۔ یہاں بتایا گیا ہے ک ہر شخص dispute کو کیسے سنبھالتا ہے, اسلئے آپ protocol کو اس dispute model سے ملا سکتے ہیں جسکی آپکو واستو میں ضرورت ہے۔

ACP: کارڈ نیٹورک کے مادھیم سے disputes۔ کیونک merchant ACP میں رکارڈ کا merchant رہتا ہے, ہر مانک card-network dispute پتھ کام کرتا ہے۔ buyer کا بینک chargeback پرارنبھ کرتا ہے; Stripe (یا جو بھی پروسیسر) merchant کی سرکشا سنبھالتا ہے; merchant اپنی موجودا refund نیت کا پالن کرتا ہے۔ یہ ACP کا سبسے بڑا ویاوہارک لابھ ہے۔ ہر retail buyer کی رٹرن کے بارے میں اپیکشا بس کام کرتی ہے۔

ACP refund کے لئے agent پرارنبھ ہوتا ہے:

acp_client.refunds.create(...) اس پاٹھیکرم میں انی ACP client کال کی طرح اداہرناتمک ہے۔ پرنام model اور tool وایرنگ واستوک ہیں۔

@function_tool
async def acp_refund(
    order_id: str,
    reason: str,
    amount_usd: Decimal | None = None,
) -> "RefundResult":
    """Start a refund through ACP. The merchant's standard refund policy applies."""
    raw = await acp_client.refunds.create(
        order_id=order_id,
        reason=reason,
        amount_usd=amount_usd,  # None means full refund
    )
    return RefundResult(
        refund_id=raw.refund_id,
        order_id=order_id,
        status=raw.status,
        amount_refunded_usd=raw.amount_refunded_usd,
    )

AP2: disputes آڈٹ ٹریل کے مادھیم سے تی ہءآ۔ dispute میں AP2 کا یوگدان mandate شرنکھلا (ارادا, پھر Cart, پھر بھگتان) ہے۔ جب ایک dispute سامنے آتا ہے, تو وہ شرنکھلا اس بات کا پرمان ہوتی ہے ک استعمالکرتا نے واستو میں کیا ادھکرت کیا ہے, اور یہ کانونی روپ سے کایم ہے۔ یہ انترنہت rail کے dispute پتھ کو پرتستھاپت نہیں کرتا ہے: ید AP2 mandate نے Stripe کے مادھیم سے کارڈ بھگتان کو ادھکرت کیا ہے, تو Stripe کی dispute پرکریا ابھی بھی لاگو ہوتی ہے۔ AP2 اس بات کا پرمان جوڑتا ہے ک استعمالکرتا کس بات پر سہمت ہءآ۔

dispute پرواہ:

1. User claims: "I never authorized this purchase."
2. Merchant retrieves the signed AP2 Cart Mandate from the transaction record.
3. Merchant presents the Cart Mandate (with the user's signature) to the
   payment processor as part of the dispute defense.
4. The card network or processor checks the signature against the user's
   registered public key. If it is valid, the dispute is resolved for the merchant.

x402: کوئی اوپچارک dispute تنتر نہیں۔ شدھ x402 بھگتان ڈجائن کے انسار گیر-واپسی یوگی ہیں۔ بھگتان ایک سے دو سیکنڈ میں on-chain کا نپٹان ہو جاتا ہے; کوئی chargeback نہیں ہے. یہ x402 کی سبسے بڑی ویاوہارک حد ہے۔ یہ $0.001 API کال کے لئے ٹھیک ہے (dispute کی کیمت بھگتان سے ادھک ہوگی) اور کسی بھی چیز کے لئے غلط ہے جہاں buyer اچت روپ سے refund چاہتا ہے۔

x402 کی نو-refund سنپت کو نرم کرنے کے تین طریقے:

• ایسکرو۔ اچ-مولی والے x402 بھگتان کے لئے, ایک smart-contract ایسکرو کا استعمال کریں جو buyer دوارا سویکرت کا سنکیت ملنے تک دھنراش کو اپنے پاس رکھتا ہے۔ ERC-8004 میں ملٹی-agent لیندین کے لئے ایسکرو primitives شامل ہے۔
• Compose AP2 اور ایک الگ ریل کے ساتھ۔ ید آپکو x402 کی گت کی ضرورت ہے لیکن dispute سمرتھن کی بھی ضرورت ہے, تو AP2 پلس x402 composition آپکو سبوت کے روپ میں mandate شرنکھلا دیتا ہے۔ x402 settlement کو تیز رکھتا ہے۔ settlement سویں ابھی بھی گیر-پرتورتی ہے; mandate بس وہی سابت کرتا ہے جس پر سہمت ہوئی تھی۔
• Seller گارنٹی۔ بھگتان کئے گئے APIs کے لئے, seller کی شرتوں میں اکسر refund لاگو off-chain نیم شامل ہوتے ہیں (ید سیوا وپھل ہو جاتی ہے تو seller سویچھا سے USDC کو واپس بھیج دیتا ہے)۔ یہ پرتشٹھت وکریتاؤں کے لئے کام کرتا ہے اور گمنام وکریتاؤں کے ساتھ الگ ہو جاتا ہے۔

MPP: Stripe کے مادھیم سے disputes۔ MPP sessions card rails پر بسے, Stripe کا مانک dispute مشینری پراپت کرتے ہیں, جو ایسیپی کے سمان ہے۔ MPP sessions stablecoin دوارا Tempo پر, یا Lightning دوارا تی کیا گیا, Stripe کا seller-side dispute رزالیوشن سے گجریں۔ Stripe ریل کی پرواہ کئے بنا پرنام کے لئے merchant کو جمیدار رکھتا ہے۔

آپکو جس dispute model کی ضرورت ہوتی ہے وہ اکسر composition کو لاگت یا ولنبتا سے ادھک چلاتا ہے۔ consumer-shopping پلیٹفارم کو chargebacks کی ضرورت ہوتی ہے, اسلئے ACP پھٹ بیٹھتا ہے۔ ایک شدھ machine-to-machine API marketplace کو بلکہل بھی disputes کی ضرورت نہیں ہے, اسلئے x402 پھٹ بیٹھتا ہے۔ ایک enterprise procurement پلیٹفارم کو آڈٹ-گریڈ ساکشی کی ضرورت ہوتی ہے, اسلئے AP2 کسی بھی settlement rail کے ساتھ پھٹ بیٹھتا ہے۔

اودھارنا 18: FastAPI اور Inngest webhook پلنبنگ: request اور response لوپ کو بند کرنا

ایک پنکت میں: کچھ بھگتان ایوینٹ اپنے وقت پر آتے ہیں (disputes, mandate signatures, seller-side بھگتان انرودھ), اسلئے آپکو انہیں پکڑنے کے لئے ایک پتلے FastAPI ہینڈلر اور کام کو durable ورکفلو میں لے جانے کے لئے ایک Inngest ایوینٹ کی ضرورت ہوتی ہے۔

حصہ 1 سے 5, اور اودھارنا 15 سے 17 تک, agent کو buyer کے روپ میں مانا جاتا ہے: یہ ایک request بھیجتا ہے, protocol اتر دیتا ہے, پرنام کے بارے میں SDK کارن بتاتا ہے۔ لیکن agent commerce دونوں ترپھ چلتا ہے۔ Stripe charge.dispute.created webhook بھیجتا ہے۔ AP2 mandate signing آپ کے server سے استعمالکرتا کے ڈوائس پر ہوتا ہے, اور باد میں واپس پوسٹ کرتا ہے۔ x402 وکریتاؤں کو ایک server-سائڈ middleware کی ضرورت ہوتی ہے جو 402 Payment Required لوٹاتا ہے اور X-PAYMENT ہیڈر کی جانچ کرتا ہے۔ انمیں سے کوئی بھی ایک Runner.run() کال کے اندر پھٹ نہیں بیٹھتا۔ انہیں HTTP حد کے روپ میں FastAPI ہینڈلر اور durable ورکفلو میں واپس پل کے روپ میں Inngest اوینٹ کی ضرورت ہے۔

یہ اودھارنا ان تین پیٹرن پر چلتی ہے جنکی آپکو اتپادن میں ضرورت ہوگی۔ انکے بنا, سسٹم میں دراریں ہیں جہاں ایسنک گھٹنائیں گھٹتی ہیں۔

پیٹرن 1: ایک Stripe webhook ایک نلنبت Inngest function میں پرواہت ہو رہا ہے۔ جب کوئی استعمالکرتا ACP آرڈر پر chargeback پھائل کرتا ہے, تو Stripe آپ کے endpoint پر charge.dispute.created بھیجتا ہے۔ یہ آرڈر کے پانچ منٹ باد یا 60 دن باد پہنچ سکتا ہے۔ آرڈر دینے والا ورکفلو بہت پہلے ہی سماپت ہو چکا ہے, لیکن agent کو ابھی بھی پرتکریا دینے کی ضرورت ہے: merchant کو سوچت کریں, آڈٹ کے لئے لاگ ان کریں, شاید ایک بچاو بنائیں۔ FastAPI ہینڈلر webhook کو Inngest اوینٹ میں بدل دیتا ہے, اور ایک Inngest function اسے اٹھاتا ہے اور وواد کو سنبھالنے کے لئے ایک agent چلاتا ہے۔

stripe.Webhook.construct_event(...) اور stripe.error.SignatureVerificationError واستوک Stripe API ہیں۔ Inngest وایرنگ اصل ہے۔ پھایرنگ API پر دھیان دیں: گھٹنائیں send(events=[inngest.Event(...)]) کے روپ میں سامنے آتی ہیں, کوئی سپشٹ نردیش نہیں۔

from fastapi import FastAPI, Request, HTTPException
from pydantic import BaseModel
from decimal import Decimal
import stripe, inngest

app = FastAPI()
inngest_client = inngest.Inngest(app_id="agent-commerce", is_production=False)

class StripeDisputeEventPayload(BaseModel):
    order_id: str
    dispute_id: str
    amount_usd: Decimal
    reason: str
    raw_event_id: str

@app.post("/webhooks/stripe")
async def stripe_webhook(request: Request):
    # 1. Verify the Stripe signature. This security gate is required.
    signature = request.headers.get("Stripe-Signature")
    payload = await request.body()
    try:
        event = stripe.Webhook.construct_event(
            payload=payload, sig_header=signature, secret=settings.stripe_webhook_secret,
        )
    except stripe.error.SignatureVerificationError:
        raise HTTPException(status_code=400, detail="Invalid signature")

    # 2. Route by event type. This handler does NO business logic.
    #    It only fires Inngest events so the durable workflow does the work.
    if event.type == "charge.dispute.created":
        await inngest_client.send(events=[
            inngest.Event(
                name="stripe/dispute.created",
                data=StripeDisputeEventPayload(
                    order_id=event.data.object.metadata.get("order_id"),
                    dispute_id=event.data.object.id,
                    amount_usd=Decimal(event.data.object.amount) / 100,
                    reason=event.data.object.reason,
                    raw_event_id=event.id,
                ).model_dump(),
                id=event.id,            # idempotency seed
            ),
        ])

    # 3. ACK Stripe right away. The real work runs in Inngest, durably.
    return {"received": True, "event_id": event.id}

# The Inngest function that handles the dispute: fully durable and retryable.
@inngest_client.create_function(
    fn_id="handle-stripe-dispute",
    trigger=inngest.TriggerEvent(event="stripe/dispute.created"),
    # Idempotency by raw_event_id makes sure Stripe retries do not process twice.
    idempotency="event.data.raw_event_id",
)
async def handle_stripe_dispute(ctx: inngest.Context) -> dict:
    payload = StripeDisputeEventPayload(**ctx.event.data)

    # Log to audit immediately.
    await ctx.step.run("audit-dispute-received", log_dispute_to_neon, payload)

    # Run an agent to assemble the dispute defense.
    defense_agent = Agent(
        name="DisputeDefenseAgent",
        instructions="Assemble dispute defense materials: order receipt, AP2 mandate if any, "
                     "delivery confirmation, customer communication history.",
        tools=[fetch_order_details, fetch_mandate_chain, fetch_delivery_proof, submit_dispute_response],
    )
    defense = await ctx.step.run(
        "build-and-submit-defense",
        Runner.run, defense_agent, f"Build defense for dispute {payload.dispute_id}",
    )
    return {"status": "completed", "output": {"defense_submitted": defense.final_output.model_dump()}}

FastAPI ہینڈلر پتلا رہتا ہے (ستیاپت کریں, پھر کسی ایوینٹ کو سکری کریں)۔ Inngest function durable (idempotency, retries, چرن جناپن) ہے۔ agent کا ترک Inngest function کے اندر ہوتا ہے, webhook ہینڈلر کے اندر کبھی نہیں۔ یہ وبھاجن ماینے رکھتا ہے کیونک Stripe لگبھگ پانچ سیکنڈ کے بھیتر 2xx response کی امید کرتا ہے, اور agent رن میں 30 یا ادھک وقت لگ سکتا ہے۔

پیٹرن 2: ایک AP2 ادھدیش-ہستاکشر callback جو نلنبت step.wait_for_event کو پھر سے شرو کرتا ہے۔ تصور 9 میں AP2 signing tool کو signature مانگتے ہئے اور پرتیکشا کرتے ہئے دکھایا گیا ہے۔ production میں وہ signing آپ کے server سے ہوتا ہے: استعمالکرتا اپنا فون ایپ کھولتا ہے, mandate دیکھتا ہے, سویکرت پر ٹیپ کرتا ہے, اور signed mandate واپس پوسٹ کرتا ہے۔ agent کے Inngest ورکفلو کو step.wait_for_event پر نلنبت کر دیا گیا تھا; FastAPI callback اس گھٹنا کو سکری کرتا ہے جو اسے جگاتی ہے۔

note

signing callback آپکا اپنا FastAPI مارگ ہے۔ Inngest سہسنبندھ if_exp= (ایک CEL ابھشخص) کا استعمال کرتا ہے, اور پرتیکشت payload async. اپسرگ کے انترگت ہے۔ wait_for_event ٹائمءآؤٹ پر None لوٹاتا ہے۔ ap2_verify_signature اور درڑھتا client اداہرناتمک ہیں; ورکفلو کا آکار واستوک ہے.

from datetime import timedelta
from pydantic import BaseModel

class MandateSignedPayload(BaseModel):
    mandate_id: str
    user_did: str
    signature: str  # the user's signature over the mandate hash
    signed_at: str

@app.post("/callbacks/ap2/mandate-signed")
async def mandate_signed_callback(payload: MandateSignedPayload, request: Request):
    # 1. Verify the signature against this user's registered public key.
    is_valid = await ap2_verify_signature(
        mandate_id=payload.mandate_id,
        user_did=payload.user_did,
        signature=payload.signature,
    )
    if not is_valid:
        raise HTTPException(status_code=400, detail="Invalid mandate signature")

    # 2. Persist the signed mandate. Mandates have a 7-year retention requirement.
    await neon_client.mandates.insert({
        "mandate_id": payload.mandate_id,
        "user_did": payload.user_did,
        "signature": payload.signature,
        "signed_at": payload.signed_at,
        "status": "signed",
    })

    # 3. Fire the Inngest event that resumes the agent's workflow.
    await inngest_client.send(events=[
        inngest.Event(name="ap2/mandate.signed", data=payload.model_dump(), id=payload.mandate_id),
    ])
    return {"received": True, "event_id": payload.mandate_id}

# The Inngest function that was waiting. if_exp correlates the wait to this mandate.
@inngest_client.create_function(
    fn_id="agent-procurement-workflow",
    trigger=inngest.TriggerEvent(event="procurement/task.created"),
)
async def procurement_workflow(ctx: inngest.Context) -> dict:
    # ... agent creates the Intent Mandate, fires "ap2/mandate.signing.requested" ...

    # Suspend until the user signs. Zero compute is used during the wait.
    signed = await ctx.step.wait_for_event(
        "wait-for-intent-mandate-signature",
        event="ap2/mandate.signed",
        if_exp=f"async.data.mandate_id == '{ctx.event.data['mandate_id']}'",
        timeout=timedelta(hours=24),   # users can take real time
    )

    if signed is None:                 # timeout returns None
        return {"status": "abandoned", "reason": "user did not sign within 24h"}

    # Resume with the signed mandate. The agent continues from exactly where it left off.
    cont = await ctx.step.run("continue-procurement", continue_with_signed_mandate, signed)
    return {"status": "completed", "output": {"procurement_continuation": cont}}

Inngest کا step.wait_for_event if_exp کے ساتھ اسکے لئے بنایا گیا ہے۔ FastAPI ہینڈلر HTTP سے Inngest کی اوینٹ بس تک ایک ترپھا پل ہے۔ گھنٹوں پہلے نلنبت کیا گیا ورکفلو signed payload کے ساتھ پھر سے شرو ہوتا ہے, اور agent وہیں سے شرو ہوتا ہے جہاں یہ رکا تھا۔

پیٹرن 3: x402 seller-side middleware (جب آپ بھگتان کئے گئے API کو اجاگر کرتے ہیں, تو ن کیول ایک کا اپبھوگ کریں)۔ multi-agent marketplace (فیصلہ 4) میں, آپکا agent کبھی-کبھی buyer اور کبھی-کبھی seller ہوتا ہے, جہاں انی agents انسندھان, وشلیشن یا code کے لئے اپنا بھگتان کریں۔ seller پکش کو ایک FastAPI middleware کی ضرورت ہے جو 402 Payment Required لوٹاتا ہے, X-PAYMENT headers کی جانچ کرتا ہے, اور کیول ایک بار facilitator دوارا بھگتان ستیاپت کرنے کے باد ہی سنسادھن پردان کرتا ہے۔

note

نیچے دیا گیا seller-side X402Middleware اداہرناتمک ہے; کوئی x402_server PyPI پیکیج نہیں ہے۔ واستوک server-سائڈ x402 x402 پیکیج کے server اور facilitator ہیلپرس اور framework ایکیکرن کے مادھیم سے آتا ہے۔ سممت کھریدار-اور-وکریتا وچار واستوک ہے, اور FastAPI مارگ واستوک ہے۔

from fastapi import FastAPI, Request, Response
from decimal import Decimal
# Illustrative seller-side imports (see note above).
from x402_server import X402Middleware, PaymentRequirement

# Configure the middleware once at app startup.
app = FastAPI()
app.add_middleware(
    X402Middleware,
    payment_requirements_by_route={
        "/api/research": PaymentRequirement(
            scheme="exact",
            network="eip155:8453",  # Base
            asset=USDC_BASE_CONTRACT,
            recipient=settings.merchant_wallet_address,
            max_amount_usdc=Decimal("0.50"),
            expiry_seconds=300,
        ),
        "/api/code-review": PaymentRequirement(
            scheme="exact",
            network="eip155:8453",
            asset=USDC_BASE_CONTRACT,
            recipient=settings.merchant_wallet_address,
            max_amount_usdc=Decimal("2.00"),
            expiry_seconds=300,
        ),
    },
    facilitator_url="https://facilitator.cloudflare.com/x402",
)

# Your business logic. The middleware enforces payment before this runs.
@app.post("/api/research")
async def research_endpoint(request: Request):
    # By the time we reach here, the X-PAYMENT header has been verified and settled.
    # request.state.x402_proof carries the on-chain transaction hash for audit.
    query = (await request.json())["query"]

    research_agent = Agent(
        name="ResearchAgent",
        instructions="Conduct deep research on the query and return a structured report.",
        tools=[search_web, fetch_papers, summarize],
    )
    result = await Runner.run(research_agent, query)

    return Response(
        content=result.final_output,
        headers={"X-PAYMENT-PROOF": request.state.x402_proof.tx_hash},
    )

x402 سممت ہے. کانسیپٹ 10 سے buyer-side code اور یہاں seller-side middleware ایک ہی protocol کے دو ہسے ہیں۔ ایک multi-agent marketplace دونوں چلاتا ہے: اسکا agents باہری سیواؤں سے کھریدتا ہے اور باہری agents کو بیچتا ہے۔

production میں تین ناکامیئیں دوہرائی جاتی ہیں:

1. Webhook handlers بجنیس لاجک انلائن کر رہا ہے۔ ایک FastAPI ہینڈلر جو webhook response کے اندر agent چلاتا ہے, Stripe کے پانچ سیکنڈ کے ٹائمءآؤٹ کو پار کر جائیگا۔ Stripe retries, agent دو بار چلتا ہے, اور آپ استعمالکرتا سے دو بار شلک لیتے ہیں۔ ہینڈلر پتلا رہتا ہے; Inngest function ٹکاؤ ہے۔
2. webhook نشکریتا کو بھول جانا۔ Stripe retries اسی event.id کے ساتھ وپھل ڈلیوری۔ Inngest function پر idempotency کنجی کے بنا, ہر retry ایک ڈپلکیٹ بناتا ہے۔ "event.data.raw_event_id" کو idempotency کنجی کے روپ میں استعمال کریں۔
3. کالبیک پر کوئی signature جانچ نہیں۔ AP2 ادھدیش-ہستاکشرت callbacks کو پنجیکرت ساروجنک کنجی کے وردھ استعمالکرتا کے signature کو ستیاپت کرنا ہوگا۔ انیتھا کوئی بھی کال کرنے والا شخص جنادیش-ہستاکشرت گھٹناؤں کو جالی بنا سکتا ہے۔ ایک وپھل چیک 400 لوٹاتا ہے, لاگ کی گئی چیتاونی نہیں۔

---

حصہ 7: سماپن: یہ پاٹھیکرم واستو میں کیا سکھا رہا تھا

تصور 19: سترت composition کا انشاسن

ایک پنکت میں: اس پاٹھیکرم میں سب کچھ ایک کام میں سمٹ جاتا ہے: استعمال کے ماملے کو پڑھیں, اسے چار layers میں توڑیں, اور ہر پرت پر سہی protocol چنیں۔

اس پاٹھیکرم میں 19 اودھارنائیں اور 5 فیصلہ ہیں۔ وے سبھی ایک داوے کے لئے منچ تییار کر رہے ہیں: 2026 میں agent commerce ایک ایکل protocol نہیں ہے, بلکہ ایک سترت واستکلا ہے, اور آپکا کام آپ کے سامنے استعمال کے ماملے کے لئے ہر layer پر سہی protocol چننا ہے۔ باکی سب کچھ اسی سے چلتا ہے۔

ایک ہی آکرت تین پیمانوں پر دکھائی دیتی ہے۔

protocol سکیل پر, چار شیرشک protocols الگ-الگ layers پر الگ-الگ سمسیاؤں کا سمادھان کرتے ہیں: ACP Layer 3 پر, AP2 Layer 2 پر, x402 اور MPP Layer پر 4. انہیں ایک ہی layer پر پرتدوندوی ماننا سبسے آم واستشلپ غلطی ہے۔ وے کیول وہیں پرتسپردھا کرتے ہیں جہاں انکا layers اوورلیپ ہوتا ہے (settlement پر MPP کے وردھ x402; کچھ پرواہ کے لئے authorization پر ACP کے SPT کے وردھ AP2)۔ باکی ہر جگہ وے رچنا کرتے ہیں۔

سسٹم سکیل پر, ایک production سسٹم میں ہر layer سے ایک protocol ہوتا ہے, جو یونورسل client کے روپ میں OpenAI Agents SDK کے مادھیم سے ایک ساتھ جڑا ہوتا ہے۔ SDK کا @function_tool, RunContextWrapper, اور tool_input_guardrail ہر پرت پر چنتاؤں کو سپشٹ روپ سے میپ کرتا ہے۔ SDK ایک protocol نہیں ہے. یہ orchestrator ہے جو آپکو compose protocols کو ساپھ-ستھرا رکھنے کی سودھا دیتا ہے۔

انشاسن پیمانے پر, آپکا کام ایک استعمال کے ماملے کو پڑھنا ہے, اسے چار layers میں وبھاجت کرنا ہے, ہر میں سہی protocol چننا ہے, اور استعمال کے ماملے کی واستوک بادھاؤں کے کھلاپھ ہر وکلپ کو اچت ٹھہرانا ہے: لیندین مولی, ولنبتا بجٹ, dispute model, آڈٹ ضرورتئیں۔ کام "پسندیدا protocol چننا" نہیں ہے۔ یہ "اس استعمال کے ماملے میں, ہر layer کیا مانگ کرتا ہے?"

حصہ 5 کے پانچ فیصلہوں نے اس انشاسن کے مادھیم سے واستوک استعمال کے ماملوں کو آگے بڑھایا۔ فیصلہ 1 (consumer shopping) ACP پلس Stripe card rails پر اترا, کیونک استعمال کے ماملے میں chargeback سرکشا کی ضرورت تھی۔ فیصلہ 2 (ایک API-paying agent) کیول x402 پر اترا, کیونک Layers 2 اور 4 machine-to-machine پرواہ کے لئے ڈھہ گئے۔ فیصلہ 3 (enterprise procurement) سبسے جٹل composition (AP2 پلس ACP پلس MPP) تک پہنچ گیا, کیونک آڈٹ اور پنراورت ضرورتؤں نے اسے مجبور کیا۔ فیصلہ 4 (ایک multi-agent marketplace) AP2 پلس ERC-8004 پلس x402 پر اترا, کیونک دوپکشیی-وشواس کی ضرورت کسی انی طریقے سے پوری نہیں کی جا سکتی تھی۔ فیصلہ 5 نے فیصلہ 2 کو پوری طرح سے الگ stack (Google ADK پلس ایک Coinbase wallet پلس AP2 پلس x402) پر پھر سے بنایا اور اسی چار-پرت آکار تک پہنچ گیا, جسسے سابت ہءآ ک واستکلا ایک آورن نہیں ہے۔ Stripe اور OpenAI۔

آپ جس composition تک پہنچتے ہیں وہ استعمال کے ماملے سے نردھارت ہوتا ہے, سواد سے نہیں۔ ایک ٹیم جو x402 کو چنتی ہے کیونک "stablecoins بھوشی ہے" لیکن ایک consumer shopping انبھو کا نرمان کر رہی ہے, اسکی سنرچنا غلط ہے۔ ایک ٹیم جو ACP کو چنتی ہے کیونک "Stripe اینٹرپرائز-گریڈ ہے" لیکن $0.001 پر API ایکسیس کے لئے بھگتان کر رہی ہے, کال کی سنرچنا غلط ہے۔ استعمال کے ماملے کو وکلپ چننے دیں۔

---

چیٹ شیٹ: ایک پیج میں framework

اسے پرنٹ کریں. اسے دیوار پر ٹیپ کر دیں. کسی agent-commerce ڈزائن کی وقتکشا کرتے وقت اسکا استعمال کریں۔

چار layers (اس stack کو یاد رکھیں)

Layer 1: DISCOVERY      ->  "What's available to buy?"
Layer 2: AUTHORIZATION  ->  "Am I allowed to spend this?"
Layer 3: COMMERCE       ->  "What's the full purchase lifecycle?"
Layer 4: SETTLEMENT     ->  "Where does the money actually move?"

ہر layer پر protocols (2026 میں شیرش چین)

Layer	شیرش چین	دوارا چنیں
Discovery	MCP, A2A, agent directories, AI shopping surfaces	جہاں agent کے آوشیک سیوائیں رہتی ہیں
Authorization	AP2 mandates, ACP SPT, TAP, ERC-8004	ٹرسٹ model: آڈٹ-کٹھور, Stripe-نیٹو, کیول پہچان, یا ملٹی-agent
Commerce	ACP, UCP, سیدھا API (کوئی نہیں)	کیا استعمال کے ماملے میں commerce جیونچکر کی ضرورت ہے?
Settlement	x402, MPP, card rails, بینک / Lightning	ارتھشاستر: لیندین مولی rail کو چلایا کرتا ہے

چار وہت رچنائیں

کیس کا پریوگ کریں	Stack
Consumer shopping	AI ستہ + ACP SPT + ACP + Stripe کارڈ
API-paying agent	MCP/directory + EIP-3009 + (کوئی نہیں) + x402
Enterprise procurement	A2A/MCP + AP2 + ACP/UCP + MPP/cards
Multi-agent marketplace	A2A + AP2 + ERC-8004 + (کوئی نہیں) + x402

Spend-limit تین ستروں پر پرورتن (آوشیک)

Level 1: Wallet / payment-method limits  (smart-contract caps OR Stripe customer caps)
Level 2: SDK tool guardrails             (tool_input_guardrail on each payment tool)
Level 3: Application business logic      (per-user, per-category, per-merchant policies)

انمیں سے کسی کو بھی چھوڑیں اور آپ پوری طرح برباد ہونے سے ایک بگ دور ہیں۔ سبسے آم غلطی لیول 2 کے لئے agent-ستر output_guardrail کا استعمال کرنا ہے۔ یہ انتم agent اتر پر سکری ہوتا ہے, بھگتان روکنے کے لئے بہت دیر ہو چکی ہے۔ اسکے بجای tool_input_guardrail کا استعمال کریں۔

آرتھک حد (اسے یاد رکھیں)

Transaction value
├── < $5         → x402 or MPP stablecoin (card fees exceed the transaction)
├── $5 - $1,000  → ACP + card rails (chargeback protection worth the 2.9%)
└── > $1,000     → AP2 + composed stack (audit + dispute defense + multi-rail)

dispute model (اکسر سبسے مجبوت بادھا)

Use case needs chargeback protection?
├── Yes → ACP + card rails (or MPP card mode)
└── No  → x402 acceptable (faster, cheaper, no refunds)

Use case needs audit evidence?
├── Yes → AP2 at Layer 2 (mandates as legally-admissible evidence)
└── No  → SPT or EIP-3009 sufficient

لانچ سے پہلے Production چیکلسٹ

• wallet/payment-method spend limits لیول 1 پر کانفگر کیا گیا
• SDK tool_input_guardrail ہر بھگتان-پرادھکرن tool سے جڑا ہءآ ہے (ستر 2)
• ایپلکیشن پرت-استعمالکرتا, پرت-شرینی اور پرت-ویاپاری حد لاگو کرتا ہے (ستر 3)
• key vault (Azure Key Vault یا سمتلی) میں Signing کنجیاں, کبھی بھی env vars میں نہیں
• پرت-agent wallet پرتھکرن (agent ورگوں میں کوئی ساجھا کنجی نہیں)
• Key rotation شیڈیول پربھاشت (90-دن کی بیسلائن)
• Audit logs سے durable بھنڈارن agent runtime سے سوتنتر
• OpenTelemetry traces سپین SDK, httpx, Inngest, اور FastAPI; پرت لیندین ایک trace ID
• ہر حد پر Pydantic models (tool returns, protocol payloads, FastAPI نکای, Inngest گھٹنائیں)
• ہر جگہ پیسے کے لئے Decimal (کبھی float نہیں)
• Stripe webhook handler signature کو ستیاپت کرتا ہے اور ایک Inngest ایوینٹ سکری کرتا ہے (پتلا ہینڈلر, durable function)
• AP2 ادھدیش-ہستاکشرت callback signature کو ستیاپت کرتا ہے اور step.wait_for_event کو پھر سے شرو کرتا ہے
• ید بھگتان کئے گئے APIs کو اجاگر کیا جائے: x402 seller-side middleware پرت روٹ کانفگر کیا گیا ہے
• Inngest idempotency ہر webhook-ٹرگر function پر کنجی سیٹ
• Dispute اور refund تنتر کو protocol کے انسار سمجھا اور پرلیکھت کیا گیا
• Human-in-the-loop production کے پہلے 30 دنوں کے لئے پشٹکرن گیٹ
• پشٹکرن گیٹ کو شتھل کرنے سے پہلے cart-سٹیکتا میٹرک ماپی گئی

---

تورت حوالہ: decision tree, سنپیڑت

جب آپ کے پاس کوئی نیا استعمال کا ماملا ہو, تو اس پیڑ پر چلیں۔

1. What's the agent buying?
   ├── Retail goods for a user → Decision 1 pattern (ACP + cards)
   ├── API access for itself → Decision 2 pattern (x402-only)
   ├── Supplier goods/services for an org → Decision 3 pattern (AP2 + composed)
   └── Work from another agent → Decision 4 pattern (AP2 + ERC-8004 + x402)

2. What's the transaction value?
   ├── < $5 → settlement = x402 or MPP stablecoin
   ├── $5-$1,000 → settlement = card rails via ACP/MPP
   └── > $1,000 → settlement = MPP sessions OR bank rails

3. What's the dispute model?
   ├── Need chargeback protection → must include card rails somewhere
   ├── Need audit evidence → must include AP2 at Layer 2
   └── Neither → x402 / direct rail sufficient

4. What's the latency budget?
   ├── < 1 sec → only stablecoin rails work
   ├── 1-5 sec → x402, MPP, or pre-signed AP2 mandates
   └── > 5 sec → full ACP checkout works

5. Compose: pick one protocol from each layer, justified against the constraints above.

---

ڈزائن-وقتکشا ٹیمپلیٹ: کسی agent-commerce آرکٹیکچر کی وقتکشا کرتے وقت پوچھے جانے والے سوال

جب آپ کسی سہکرمی کے ڈزائن (یا اپنے سویں کے ڈراپھٹ, ایک دن کی دوری کے ساتھ) کی وقتکشا کرتے ہیں, تو ان سوالوں کو کرم سے پوچھیں۔ ہر اس پاٹھیکرم کے ایک انحصہ کو میپ کرتا ہے; ید اتر سوال کو سنتشٹ نہیں کرتا ہے, تو اس انحصہ پر واپس جائیں۔

واست سوال

1. یہ کس استعمال کے ماملے میں کام کر رہا ہے? ید "ایکادھک" ہے, تو بنیادی کیا ہے? ایک ڈزائن جو سبھی چار وہت استعمال ماملوں کو پورا کرنے کا پریاس کرتا ہے وہ تصور 12 سے ورودھی پیٹرن ہے; اسے دھوجانکت کریں.
2. چار layers سپشٹ روپ سے چلیں۔ Discovery? Authorization? Commerce? Settlement? ہر layer پر کون سا protocol? چار-protocol composition کو زور سے بولیں۔
3. استعمال کے ماملے میں ہر layer کی پسند کو اچت ٹھہرائیں۔ اس layer پر یہ protocol کیوں? ایک الگ سے کیا بدلیگا? تصور 13 کا پار-بنام-بھیتر پریکشن یہاں لاگو ہوتا ہے۔
4. کیا کسی layer پر protocol اوورلیپ ہے? دو protocols Layer 4 پر پرتسپردھا کر رہے ہیں? Layer 2 پر دو? ید ہاں, تو یہ جٹلتا ہے جسے اچت ٹھہرانے کے لئے استعمال کے ماملے کی ضرورت ہے۔

آرتھک سوال

5. لین-دین مولی وترن کیا ہے? اپ-ڈالر? $10 سے $100? $1,000 سے ادھک? تصور 14 کی آرتھک حد کو settlement وکلپ کو چلایا کرنا چاہئے۔
6. ولنبتا بجٹ کیا ہے? اپ-سیکینڈ? 5 سے 30 سیکنڈ? ولنبتا بجٹ کو settlement اور mandate وکلپوں کو سیمت کرنا چاہئے۔
7. اپیکشت ماترا میں پرت لیندین لاگت کیا ہے? protocol شلک اور پروسیسر شلک تتھا پرت-لیندین بنیادی ڈھانچا لاگت جوڑیں۔ یہ جانچنے کے لئے اسکا استعمال کریں ک composition آرتھک روپ سے رویہی ہے۔

سنچالناتمک سوال

8. Spend-limit تینوں ستروں پر پرورتن? wallet/payment-method, SDK, ایپلکیشن ویوسای ترک۔ تصور 15: کسی کو بھی چھوڑیں اور آپ اجاگر ہو جائیں گے۔
9. Identity سوچھتا? پرت-agent wallet پرتھکرن, key rotation, audit logs سے durable بھنڈارن, پرت لیندین ایک trace ID کے ساتھ traces وترت۔ تصور 16 کی چار آدتیں۔
10. Dispute اور refund یانترکی? کیا composition آپ کے استعمال کے ماملے میں واستو میں ملنے والے disputes کو سنبھالتا ہے? تصور 17: یہ اکسر سبسے مجبوت بادھا ہوتی ہے۔
11. آپریشنل envelope? Inngest (یا سمککش durable نشپادن) لنبے وقت تک چلنے والے پرواہ, retries, اور idempotency کو کہاں سنبھالتا ہے? Production Worker کریش کورس میں کور کیا گیا۔
12. Human-in-the-loop گیٹ? پرواہ میں استعمالکرتا یا آپریٹر کہاں پشٹ کرتا ہے? اتپادن کے پہلے 30 دنوں کے لئے پشٹکرن گیٹ پر ڈفالٹ۔

Webhook اور ایسنک-کالبیک سوال (تصور 18)

13. Stripe webhook handler موجود ہے اور پتلا ہے? signature کو ستیاپت کرتا ہے, ایک Inngest ایوینٹ سکری کرتا ہے, پانچ سیکنڈ کے اندر ACK کرتا ہے۔ ویاوسایک ترک Inngest function میں رہتا ہے, ہینڈلر میں نہیں۔
14. AP2 ادھدیش-ہستاکشر callback موجود ہے اور استعمالکرتا signatures کو ستیاپت کرتا ہے? اسکے بنا, agent کے step.wait_for_event کبھی بھی پھر سے شرو نہیں ہوتا ہے۔ signature تصدیق کے بنا, کوئی بھی جنادیش-ہستاکشرت گھٹناؤں کو جالی بنا سکتا ہے۔
15. ید ایکسپوزنگ پیڈ APIs: x402 seller-side middleware پرت روٹ کانفگر کیا گیا ہے? ملٹی-agent مارکیٹپلیس buyer-side اور seller-side code دونوں چلاتے ہیں; seller پکش کو مڈلوییر کی ضرورت ہے۔
16. ہر webhook-ٹرگر function پر Inngest idempotency کنجیاں? سمان event.id کے ساتھ Stripe retries; idempotency کے بنا آپ دو بار چارج یا refund کرتے ہیں۔
17. انبندھ layer: Pydantic models ہر حد پر? Tool returns, protocol payloads, FastAPI request اور response نکای, Inngest گھٹنا payloads, سبھی ٹائپ کئے گئے۔ پیسے کے لئے Decimal, کبھی float نہیں۔

ناکامی-موڈ سوال

18. production میں سبسے ادھک ممکنہ ناکامی موڈ کیا ہے? ہر وہت فیصلہ میں ایک تھا: cart بیمیل (فیصلہ 1), انینترت کھرچ (فیصلہ 2), Intent Mandate سکوپ بیمیل (فیصلہ 3), کھیل پرتشٹھا (فیصلہ 4)۔ آپکا کیا ہے?
19. شمن کیا ہے? حصہ 5 میں ہر ناکامی موڈ میں ایک سپشٹ شمن تھا۔ کیا ڈزائن میں یہ شامل ہے, یا یہ "protocol اسے سنبھال لیگا" پر منحصر ہے?

ٹریک-تیاری سوال (production پرنیوجن کے لئے)

20. ٹیم کس شکشن ٹریک سے چلایا ہو رہی ہے? ریڈر, شرءآتی, مدھیورتی, انت۔ ایماندار ہو۔ Production پرنیوجن کے لئے انت-ٹریک گہرائی کی ضرورت ہے, ریڈر-ٹریک پرچتتا کی نہیں۔
21. ید agent غلط رویہ کرتا ہے تو رولبیک منصوبہ کیا ہے? Wallet کل سوچ? SPT نرسن? agent کو SDK ستر پر اکشم کریں? اسے لانچ سے پہلے پربھاشت کریں, گھٹنا کے باد نہیں۔

---

حوالہ

چار protocol کے لئے بنیادی ماخذ۔ ثانوی تبصرہ کی اپیکشا انہیں بنیادیتا دیں; specs انکے بارے میں لکھنے کی تلنا میں تیزی سے ترقی ہوتا ہے۔

ACP (Agentic Commerce Protocol)

• تفصیلات repository: github.com/agentic-commerce-protocol/agentic-commerce-protocol (Apache 2.0)
• ڈیولپر سائٹ: agenticcommerce.dev
• سہ-رکھرکھاو: OpenAI اور Stripe
• Stripe ایکیکرن docs: stripe.com/docs/agentic-commerce
• نوینتم spec version ادھرت: 2026-04-17

AP2 (Agent Payments Protocol)

• تفصیلات repository: github.com/google-agentic-commerce/AP2 (Apache 2.0)
• دستاویزیکرن سائٹ: ap2-protocol.org
• گٹھبندھن کے سدسی: Google پلس 60 سے ادھک حصہیدار (Salesforce, ServiceNow, Adobe, Shopee, Etsy, Adyen, American Express, JCB, UnionPay International, PayPal, Mastercard, Coinbase, انی)
• a2a-x402 ایکسٹینشن repository: github.com/google-a2a/a2a-x402
• نوینتم version ادھرت: v0.2.0 (اپریل 2026)

x402

• تفصیلات repository: github.com/coinbase/x402 (Apache 2.0)
• دستاویزیکرن سائٹ: x402.gitbook.io (x402.org بھی)
• Coinbase دوارا بنایا اور اب Linux Foundation کے x402 پھاؤنڈیشن (اپریل 2026) کے تہت Cloudflare, Stripe, AWS, Google, اور انی کے ساتھ چلایا کیا گیا ہے۔
• Cloudflare OpenAI Agents SDK ایکیکرن: developers.cloudflare.com/agents/x402
• دتک گرہن نردیشکا: agent.market
• x402 پھاؤنڈیشن کے سدسیوں میں شامل ہیں: Adyen, AWS, American Express, Base, Circle, Cloudflare, Coinbase, Google, Mastercard, Microsoft, Polygon Labs, Shopify, Solana پھاؤنڈیشن, Stripe, Visa

MPP (Machine Payments Protocol)

• تفصیلات سائٹ: mpp.dev
• سہ-ڈیولپرس: Stripe اور Tempo (Stripe کا L1 blockchain, Paradigm کے ساتھ انکیوبیٹ کیا گیا)
• Stripe گھوشنا: stripe.com/blog/machine-payments-protocol
• لانچ کی تاریکھ: 18 مارچ, 2026 (mainnet)
• لانچ کے وقت حصہیدار: Stripe, Visa, Lightspark, Anthropic, OpenAI, Shopify, اور 100 سے ادھک سیوائیں

نکٹورتی protocols

• A2A (Agent2Agent, Google): github.com/google-a2a/A2A, protocol AP2 وستارت
• MCP (Model Context Protocol, Anthropic): modelcontextprotocol.io, tool اور حوالہ layer agents کے مادھیم سے سیواؤں کی کھوج کریں
• UCP (Universal Commerce Protocol, Google): Google shopping ستہوں کے لئے ACP کے سمککش کے روپ میں گھوشت
• TAP (Trusted Agent Protocol, Visa اور Cloudflare): identity تصدیق protocol 14 اکٹوبر, 2025 کو لانچ ہءآ
• ERC-8004: بہ-agent لیندین کے لئے on-chain وشواس مانک

OpenAI Agents SDK

• Python SDK: pip install openai-agents (نوینتم رلیز 19 مئی, 2026)
• دستاویزیکرن: openai.github.io/openai-agents-python
• JavaScript/TypeScript SDK: github.com/openai/openai-agents-js

سنبندھت Agent Factory کریش کورس

• Build AI Agents کریش کورس: OpenAI Agents SDK بنیادی باتیں (Agent, Runner.run(), @function_tool)
• Production Worker کریش کورس: Inngest durable agent workflows کے لئے پرچالن envelope کے روپ میں
• Eval-Driven Development کریش کورس: agents کا پریکشن اور مولیانکن
• Choosing Agentic Architectures کریش کورس: کون سا agentic پیٹرن پھٹ بیٹھتا ہے جو کیس کا استعمال کرتا ہے
• تیناتی-agent کریش کورس (کلاؤڈ تیناتی): کلاؤڈ ہارنیس (Azure کنٹینر ایپس پلس Neon پلس Cloudflare)۔ پرگت پر ہے; شپ ہونے پر لنک کریں۔

پرچالن اور انبندھ-پرت tools (اودھارنا 16 اور 18 میں بھاری استعمال کیا گیا)

• Inngest: inngest.com, durable نشپادن پلیٹفارم جو اس پاٹھیکرم میں agent workflows چلاتا ہے
• FastAPI: fastapi.tiangolo.com, async HTTP layer جہاں webhook endpoints اور seller-side x402 middleware رہتے ہیں
• Pydantic: pydantic.dev, ہر حد پر پرکار کا انبندھ (tool returns, protocol payloads, FastAPI نکای, Inngest اوینٹ)
• OpenTelemetry: opentelemetry.io, httpx, openai-agents, FastAPI, اور Inngest کے لئے آٹو-انسٹرومینٹیشن کے ساتھ وترت ٹریسنگ; ایک trace ID پورے لیندین کو پھیلاتا ہے
• httpx: python-httpx.org, x402-client کے نیچے async HTTP client, ACP client, اور AP2 a2a-x402 ایکسٹینشن
• Azure Key Vault: جہاں signing کنجیاں production میں رہتی ہیں, کانسیپٹ 16 کے انشاسن کے انسار گھمائی جاتی ہیں
• Stripe webhooks دستاویز: stripe.com/docs/webhooks, signature تصدیق, ایوینٹ پرکار اور retry شبدارتھ

---

اب آپ کے پاس سنپورن framework ہے: چار layers, چار protocols, انہیں بنانے کے نیم, پانچ کاریشیل فیصلہ, production چنتائیں جو تی کرتی ہیں ک سسٹم جیوت رہے گا یا نہیں, اور رکھنے کے لئے ایک پرشٹھ کا حوالہ۔ protocols چلتا رہے گا۔ چار ستریی انشاسن نہیں ہوگا. layers سے نرمان کریں, اور جب protocol نام بدل جائیں گے تب بھی آپ سہی رہیں گے۔