একটি AI agent একটি scraper লিখতে, এটি debug করতে, ও আপনাকে ঠিক কোথায় deploy করতে হবে তা বলতে পারে। তারপর এটি থামে। কারণ পরবর্তী ধাপ — আসলে সার্ভার ভাড়া নেওয়া — প্রায় সবসময় একজন মানব লাগে: একটি অ্যাকাউন্ট খোলা, হয়তো একটি পরিচয়-যাচাই পার করা, একটি checkout-এ একটি কার্ড নম্বর টাইপ করা। agent কঠিন অংশটা করল আর এখন বিরক্তিকর অংশটার জন্য আপনার অপেক্ষায়।
সেই ফাঁকটাই এর অস্তিত্বের পুরো কারণ। আমরা মাঝখান থেকে মানবকে সরিয়েছি।
autonomy সাধারণত কোথায় ভাঙে
ভাবুন একটি সাধারণ হোস্টে "সার্ভার ভাড়া নেওয়া" আসলে কী জড়িত। একটি signup ফর্ম। confirm করতে একটি ইমেল। বিলিং বিবরণ, কখনও ID। checkout-এ একটি কার্ড। IP খুঁজতে একটি dashboard। এর প্রতিটি ধরে নেয় একজন ব্যক্তি সেখানে বসে আছে।
একটি agent সেখানে বসতে পারে না। এটি একটি API ডাকতে, একটি token ধরে রাখতে, সিদ্ধান্ত নিতে পারে — কিন্তু একটি যাচাই-ইমেল পেতে বা একটি ক্রেডিট কার্ড বের করতে পারে না। তাই যে মুহূর্তে অবকাঠামো ছবিতে ঢোকে, স্বায়ত্ত workflow-টা অতিরিক্ত ধাপ সহ একটি মানব workflow-এ ফিরে যায়। আপনি চেয়েছিলেন একটি agent যা ship করে; আপনি পেলেন একটি agent যা একটি ticket দাখিল করে।
flow, শুরু থেকে শেষ
EQVPS-এ একই action হলো MCP tools (16টি) plus একটি REST API — আর গুরুত্বপূর্ণভাবে, agent নিজের credential পেতে পারে। এই যে আসল ক্রম:
// 1. একটি অ্যাকাউন্ট পান — token সাথে সাথে ফিরে আসে, কোনো ইমেল নয়, মানব নয়
register_account({ first_name: "Ada", last_name: "Agent", email: "ada@example.com" })
// → { token: "..." } এখান থেকে Authorization: Bearer <token> হিসেবে পাঠান
// 2. কী উপলব্ধ দেখুন
list_plans()
// → spec, দাম ও OS image id সহ প্ল্যান
// 3. balance-এ টাকা আছে নিশ্চিত করুন
get_balance()
// → { balance: 25, currency: "USD" }
// 4. Order — এটি balance debit করে ও বক্স provision করে
order_vps({ product: "nano", os_id: 1, hostname: "ada-worker" })
// → { service_id, paid_from_balance: true }
// 5. নিজের নতুন সার্ভারের key পড়ুন
get_vps_status({ service_id })
// → { ip, ssh_port, password } অর্ডারের ~60 সেকেন্ড পরে
পাঁচটি call আর agent নিজে ভাড়া নেওয়া একটি মেশিনে SSH করে ঢুকেছে। কোনো dashboard নেই, প্রতিটি ধাপ অনুমোদন করা কেউ নেই। আপনি বরং সাধারণ HTTP থেকে এটি চালাতে চাইলে, একই endpoint REST-এ আছে — MCP বা REST, আপনার সিদ্ধান্ত।
সৎ অংশ: কী স্বয়ংক্রিয়, কী নয়
অর্ডার করা পুরোপুরি স্বায়ত্ত। balance funded করা নয় — এখনও নয়। এখন কেউ একবার balance-এ ক্রিপ্টো রাখে (USDC/USDT, বা একটি কার্ড on-ramp), আর সেই বিন্দু থেকে agent নিজে অর্ডার, scale ও cancel করে, শুধু যা আছে তা খরচ করে।
সবাই যে শেষ-অবস্থা কল্পনা করে — একটি agent on-chain, per request, কোনো pre-funding ছাড়া পরিশোধ করছে — সেটি x402 ধাঁচ, আর আমরা মনে করি এটাই এর গন্তব্য। আমরা এটি যুক্ত করিনি। এর জন্য USDC-settled rail ও কিছু জিনিস দরকার যা আমরা আজ চালাই না, তাই বক্সে "fully autonomous payments" লাগানোর বদলে, এই যে সত্য: এখন স্বায়ত্ত অর্ডার, পরে স্বায়ত্ত funding। prepaid balance-ই সেতু, আর সৎভাবে এটি একটি spend cap হিসেবেও কাজ করে যা আপনি সম্ভবত এমনিতেই চান।
কয়েকটি আসল বিবরণ
MCP সার্ভার https://mcp.eqvps.com/mcp-এ Streamable HTTP বলে, তাই এটি একটি local shim ছাড়াই যেকোনো MCP client-এ বসে। Auth হলো একটি Bearer token যা agent নিজে register_account দিয়ে তৈরি করে — একই token MCP ও REST-জুড়ে, একই অ্যাকাউন্ট ও balance-এ কাজ করে। সেশন server-side ট্র্যাক করা হয়, তাই একটি দীর্ঘ-চলা agent একটি সংযোগ ধরে রেখে tools ডাকতে থাকতে পারে।
এটি চালানো থেকে একটি ব্যবহারিক নোট: token ও ফেরত-পাওয়া root password-কে সেই গোপনীয়তা হিসেবে ভাবুন যা তারা। agent-এর এগুলো সংরক্ষণ করা উচিত, log বা chat-এ echo করা নয়। balance আর্থিক blast radius সীমিত করে; মৌলিক secret hygiene বাকিটা সীমিত করে।
কেন এটি গুরুত্বপূর্ণ
আপাতত আমাদের প্রকৃত গ্রাহকদের বেশিরভাগ এমন মানুষ যারা ক্রিপ্টোতে পরিশোধ করতে পছন্দ করে — আমরা ভান করব না যে web সার্ভার-কেনা স্বায়ত্ত agent-এ উপচে পড়ছে। কিন্তু দিকটা স্পষ্ট। agent যত দীর্ঘ, আসল কাজ নেয়, "এটি কি নিজের অবকাঠামো পেতে ও চালাতে পারে?" একটি party trick হওয়া থামিয়ে একটি প্রয়োজন হয়ে ওঠে। সেই দিন পুরোপুরি এলে, rail আগে থেকেই থাকতে হবে।
এরা আছে। আপনার agent-এ MCP সার্ভার যোগ করুন — একটি MCP client সংযুক্ত করা দিয়ে শুরু করুন — একটি ছোট balance funded করুন, আর এটিকে তার প্রথম সার্ভার ভাড়া নিতে দিন। root পর্যন্ত প্রায় এক মিনিট।
মন্তব্য
এখনো কোনো মন্তব্য নেই। প্রথম হোন।