মানুষের নীতির অধীনে এজেন্টিক পেমেন্ট

এজেন্টিক পেমেন্ট হলো এমন পেমেন্ট, যা চেকআউটে কোনো ব্যক্তির বদলে সফটওয়্যার শুরু করে। একটি AI এজেন্ট ক্রেডেনশিয়াল ধারণ করে, ঠিক করে একটি কেনাকাটা হওয়া উচিত, এবং নিজেই অর্থ সরায় — ইনভয়েস পরিশোধ করে, সাবস্ক্রিপশন নবায়ন করে, চার্টার বুক করে — কোনো মানুষ শেষ বোতামটি না টিপেই। পার্থক্যকারী বিষয় হলো সূচনাকারী। কেউ buy ক্লিক করলে সেটি সামনে চ্যাটবটওয়ালা সাধারণ কার্ড পেমেন্ট; এজেন্টিক পেমেন্টে অর্থ সরার মুহূর্তে সিদ্ধান্ত, অনুমোদন ও সেটেলমেন্ট করে সফটওয়্যার। এই ক্যাটাগরির সব কঠিন বিষয় এই একটি বৈশিষ্ট্য থেকেই আসে: যে খরচ করছে সে মানুষ নয়, আর অচেনা কাউকে অর্থ পাঠানোর আগে মানুষ যেমন ক্লান্ত, সন্দিহান বা নার্ভাস হয়, সে তা হয় না।

তাই আকর্ষণীয় প্রশ্ন কখনোই এটি ছিল না যে এজেন্ট অর্থ খরচ করবে কি না — তারা ইতিমধ্যেই পারে। প্রশ্ন হলো, কোন নিয়মের অধীনে তারা খরচ করবে তা কে ঠিক করে, এবং সেই নিয়ম প্ল্যাটফর্ম কার্যকর করে নাকি এজেন্ট শুধু প্রতিশ্রুতি দেয়।

ব্যর্থতার ধরন সুস্পষ্ট, আর সেটাই মূল কথা

একটি এজেন্টকে লাইভ পেমেন্ট ক্রেডেনশিয়াল দিন, কিন্তু কোনো সীমা না দিন, তাহলে আপনি এমন একটি ওয়্যার-ফ্রড ঘটনা বানিয়ে রেখেছেন যা এখনো ঘটেনি। ভুল হওয়ার পথ অদ্ভুত কিছু নয়। ওয়েব পেজে লুকানো একটি প্রম্পট ইনজেকশন এজেন্টকে হামলাকারীকে পেমেন্ট করতে বলে। ত্রুটিপূর্ণ টুল ডেসক্রিপশন বৈধ কেনাকাটাকে ভুল প্রাপকের দিকে ঠেলে দেয়। সাকসেস সিগন্যাল ফিরে না আসায় একটি রিট্রাই লুপ একই চার্জ হাজার বার চেষ্টা করে। এর কোনোটির জন্য চতুর প্রতিপক্ষ লাগে না — এগুলো স্বয়ংক্রিয় সফটওয়্যারের সাধারণ বাগ, শুধু আউটপুটটা হলো আপনার অ্যাকাউন্ট থেকে বেরিয়ে যাওয়া অর্থ।

লোভনীয় সমাধান হলো এজেন্টকে আরও সতর্ক করা: ভালো সিস্টেম প্রম্পট, কড়া নির্দেশ, খরচ নিয়ে আরও গভীরভাবে ভাবা মডেল। এতে নিয়ন্ত্রণ চলে যায় সিস্টেমের সবচেয়ে কম ভরসাযোগ্য জায়গায় — এজেন্টের নিজের যুক্তিতে, যা থেকে তাকে সরিয়ে আনা সম্ভব। যে বাজেট এজেন্ট তর্কে পেরিয়ে যেতে পারে তা বাজেট নয়। নিয়ন্ত্রণ থাকতে হবে এমন জায়গায় যেখানে এজেন্ট পৌঁছাতে পারে না, অর্থাৎ এজেন্টের পুরোপুরি বাইরে।

পলিসিই প্রোডাক্ট, প্রম্পট নয়

কন্টেইনমেন্ট মডেল হলো এমন একটি পলিসি যা অর্থ সরার আগে প্ল্যাটফর্ম কার্যকর করে, এজেন্ট সিদ্ধান্ত নেওয়ার পরে নয়। প্রতিটি এজেন্ট পায় প্রতি ট্রানজাকশনের ক্যাপ ও দৈনিক লিমিট — আমাদের ডেমো পলিসিতে পেমেন্টপ্রতি €150.00, দিনে €500.00 — এবং তার ওপরে মাসিক €6,000.00 সীমা। এগুলো প্ল্যাটফর্মের যাচাই করা শক্ত দেয়াল, এজেন্টের রাখা প্রতিশ্রুতি নয়। ডেমোর ট্রাভেল বট €640.00-এ চার্টার করতে চাইলে পেমেন্ট সঙ্গে সঙ্গে প্রত্যাখ্যাত হলো: ক্যাপ ছাড়িয়ে, এক সেন্টও সরার আগে। যে এজেন্ট প্রতিদিন নিখুঁত আচরণ করে, সেও মাসের সীমা ছাড়িয়ে যেতে পারে না।

বাজেট বলে কত; অ্যালাউলিস্ট বলে কোথায়। এজেন্ট শুধু সেই মার্চেন্টদের পেমেন্ট করে যাদের নাম আপনি আগে থেকে দিয়েছেন। ডেমোর Ops Agent ঠিক চারটি চেনে, এবং তালিকাবহির্ভূত ভেন্ডরে €180.00-এর চেষ্টা not-listed হিসেবে প্রত্যাখ্যাত হয়েছে। দুটি মিলে একটি বাক্স আঁকে: এই পরিমাণ অর্থ, শুধু এই প্রাপকদের। বাক্সের ভেতরে এজেন্ট পূর্ণ গতিতে চলে, কখনো জিজ্ঞেস করতে হয় না; বাক্সটাই সেই জিনিস যার মালিক মানুষ।

প্রশ্ন কখনোই এটি নয় যে AI এজেন্ট অর্থ খরচ করবে কি না। প্রশ্ন হলো, যে নিয়মের অধীনে সে খরচ করে তা কে লিখেছে — আর উত্তর সবসময় হওয়া উচিত একজন মানুষ, আগে থেকে, লিখিতভাবে।

রেখার ওপরে একজন মানুষ

কিছু সিদ্ধান্ত বাক্সের হাতে ছেড়ে দেওয়ার মতো বড়। তাই পলিসিতে একটি থ্রেশহোল্ড থাকে: একটি নির্দিষ্ট পরিমাণ, যার ওপরে পেমেন্ট যাওয়ার আগে মানুষকে অনুমোদন দিতে হয়। ডেমোতে রেখাটি €100.00-এ। Ops Agent যখন Nord Logistics-এর ইনভয়েস #088 চিহ্নিত করল — €120.00, €500.00 দৈনিক বাজেটের বেশ ভেতরে কিন্তু অনুমোদনের রেখার ওপরে — সে পেমেন্ট করেনি। সে থামল, প্রস্তাবটি একজন মানুষের সামনে রাখল, এবং অপেক্ষা করল। এক লাইনের উত্তরে ছাড়পত্র মিলল; পেমেন্ট 9F21-0716 রেফারেন্সে সেটেল হলো এবং 09:41-এ অডিট লগে উঠল। রেখার নিচে এজেন্ট নিজে চলে; ওপরে আগে একজন মানুষ উত্তর দেন।

অনুমোদন এমন চেকবক্স নয় যা মিলিয়ে যায়। এতে লেখা থাকে কে অনুমোদন দিয়েছেন, কোন ডিভাইসে, কখন, সিগনেচারসহ — অ্যাপে অনুমোদিত, ফোন কি, 09:41:12। পরে কেউ জানতে চাইলে পেমেন্ট কেন হলো, উত্তর হয় একজন নামধারী ব্যক্তি আর একটি টাইমস্ট্যাম্প, কাঁধ ঝাঁকানো নয়।

কিল-সুইচ এবং চুপচাপ বদলানো যায় না এমন লগ

ভালো দেয়ালের ভেতরেও এজেন্ট ভুল আচরণ করে এবং পলিসি ভুল প্রমাণিত হয়। দুটি নিয়ন্ত্রণ তা সামলায়। প্রথমটি কিল-সুইচ: এক ট্যাপে একটি এজেন্ট থেমে যায় এবং তার শুরু করা সব পেমেন্ট সঙ্গে সঙ্গে বন্ধ হয়। কি বৈধ থাকে, তাই অন্য কিছু ভাঙে না — মানুষ আবার চালু না করা পর্যন্ত এজেন্ট শুধু খরচ করতে পারে না, আর তার পেন্ডিং প্রস্তাবগুলো হারিয়ে না গিয়ে যেখানে ছিল সেখানেই স্থির থাকে। ডেমো ফ্লিটে ট্রাভেল বট €0.00 খরচ নিয়ে থেমে আছে, তার কিউ অক্ষত।

দ্বিতীয়টি হলো append-only audit log। প্রতিটি সিদ্ধান্ত রেকর্ডে থাকে: এজেন্ট কী চেষ্টা করেছে, কোন policy check পাস বা ফেল করেছে, কে কী অনুমোদন করেছে, এমনকি key rotation পর্যন্ত। একটি রেকর্ড থেকেই পুরো পেমেন্ট পুনর্গঠন করা যায় — decision DEC-4471-এ আছে অনুরোধ, প্রতিটি policy check ও তার ফলাফল (allowlist pass, cap pass, threshold escalate), মানুষের স্বাক্ষর, এবং rail ও reference সহ settled অ্যামাউন্ট। প্রতিটি এন্ট্রিতে থাকে তার নিজের hash, আগের এন্ট্রির hash এবং চেইনে তার অবস্থান — ডেমোতে #4,471 — তাই যেকোনো ফিল্ড বদলালে পরের প্রতিটি রেকর্ড ভেঙে যায়। লগ hash সহ JSON হিসেবে এক্সপোর্ট হয়: এটি অডিটরের হাতে তুলে দেওয়ার জন্য আপনার, আমাদের কাছে রেখে দেওয়ার জন্য নয়।

Settlement থাকুক সাদামাটা, নতুনত্ব থাকুক authorization-এ

agentic payments-কে একেবারে গোড়া থেকে নতুন করে বানানোর একটা প্রলোভন থাকে — নতুন rail, নতুন instrument, অর্থ চলাচলের নতুন পথ। এটা এড়িয়ে চলুন। সত্যিকারের নতুন অংশটি হলো authorization: এজেন্ট কীভাবে প্রমাণ করে যে সে পেমেন্ট করতে পারে, কার policy-র অধীনে, কোন অনুমোদনে। পেমেন্ট এই গেট পার হলে তার settlement হওয়া উচিত বছরের পর বছর ধরে সাদামাটা থাকা rail-এ। ডেমোতে অনুমোদিত €120.00 প্রস্তাবটি একটি সাধারণ SEPA credit transfer হয়ে যায় — অনুমোদনের কয়েক মিনিট পর SEPA Instant-এ settled — এবং পরবর্তী ধাপে তা মানুষের করা পেমেন্ট থেকে আলাদা করা যায় না। ব্যাংক জানেও না, পরোয়াও করে না যে একজন এজেন্ট এটি শুরু করেছে।

এই বিভাজন ইচ্ছাকৃত। সাদামাটা rail অনুমানযোগ্য, স্কিম অনুমতি দিলে reversible, এবং যেকোনো treasury ও অডিটরের কাছে সুপরিচিত। নতুনত্ব policy-তে আর পেমেন্ট settled rail-এ রাখলে ঝুঁকিপূর্ণ ও দ্রুত বদলানো অংশটি পুরোপুরি আপনার নিয়ন্ত্রণে থাকে, আর অন্যের ব্যাংকের সঙ্গে যে অংশ যুক্ত, সেখানে কাউকে নতুন করে কিছু শিখতে হয় না। এজেন্টরা সেই একই core থেকে খরচ করে, যার ওপর বাকি payment family চলে — /products/pay-তে বর্ণিত — রোবটের জন্য বানানো কোনো সমান্তরাল জগৎ থেকে নয়।

প্রোটোকলের চিত্র এখনো স্থির হয়নি — সেভাবেই তৈরি করুন

একজন এজেন্ট মার্চেন্টের কাছে তার পরিচয় ও mandate কীভাবে উপস্থাপন করবে, তা এখনো উন্মুক্ত প্রশ্ন। এজেন্ট কীভাবে প্রমাণ করবে সে কে, কী কেনার অনুমতি তার আছে, এবং টাকা নেওয়ার আগে মার্চেন্ট কীভাবে তা যাচাই করবে — এ নিয়ে একাধিক প্রস্তাব প্রতিযোগিতা করছে। কোনোটিই জেতেনি, আর আজ একটিমাত্রের ওপর সবকিছু বাজি ধরা অকালপক্ক হবে। নিরাপদ অবস্থান হলো authorization protocol-কে বদলযোগ্য রাখা এবং তার পেছনের সবকিছু স্থির রাখা: সামনের wire format বদলালে policy engine, audit model ও settlement rail বদলায় না।

বাস্তবে এর অর্থ ছোট, সাদামাটা একটি integration surface। এজেন্টরা mcp.protocore.io/agents-এ MCP দিয়ে সংযুক্ত হয়; প্রোটোকলটি বোঝে এমন যেকোনো framework একটি wallet ধারণ করতে পারে। ইন্টারফেস ইচ্ছা করেই সংকীর্ণ — পেমেন্টের প্রস্তাব দাও, সিদ্ধান্ত নাও — কারণ আসল লজিক থাকে প্ল্যাটফর্মে, prompt-এ নয়। এজেন্ট মার্চেন্টের কাছে কীভাবে নিজেকে প্রমাণ করবে তা ইন্ডাস্ট্রি ঠিক করলে সামনের অংশ বদলাবে, আর পেছনের দেয়ালগুলো ঠিক যেখানে ছিল সেখানেই থাকবে।

এর অবস্থান কোথায়

agentic payments এই বাজি নয় যে স্বয়ংক্রিয় সফটওয়্যার সীমাহীনভাবে খরচ করবে। বরং উল্টোটা: সফটওয়্যার খরচ করবেই, তাই সীমাগুলো বাস্তব, বাইরের এবং পাঠযোগ্য হওয়াই ভালো। বাজেট ও allowlist বক্সটি আঁকে, threshold বড় সিদ্ধান্তগুলো একজন মানুষের কাছে পাঠায়, kill-switch সবকিছু থামিয়ে দেয়, আর append-only লগ নিশ্চিত করে যে প্রতিটি পেমেন্ট পরে পুনর্গঠন করা যায়। /products/agents-এর প্রোডাক্ট পেজ এখানে ব্যবহৃত ডেমো ডেটায় পুরো চক্রটি দেখায় — এজেন্ট তৈরি, policy নির্ধারণ, একটি পেমেন্টের escalate ও settle হওয়া — আর /products/pay হলো সেই core, যার ওপর এই পেমেন্টগুলো চলে। স্বাধীনতা বাস্তব; লাগামও বাস্তব, এবং সেটি মানুষের হাতে।