নির্দেশনার বদলে সীমানা: স্বায়ত্তশাসিত AI-এজেন্টদের উপর নিয়ন্ত্রণ কীভাবে ধরে রাখবেন
কেন AI-এজেন্টদের উপর নিয়ন্ত্রণ প্রম্পটের নির্দেশনার উপর গড়া যায় না — এবং কীভাবে তা কারিগরি সীমানার উপর গড়বেন। এক সেশনের পাঁচটি ঘটনা।
এই ছবিটি লোড করা যায়নি।AI-এজেন্টরা যত বেশি স্বায়ত্তশাসিত হচ্ছে, তত বেশি আমরা তাদের পরিচিত পদ্ধতিতে নিয়ন্ত্রণ করতে চাই — প্রম্পটে নিয়ম লিখি: «এটা ছুঁবেন না», «শুধু ওখানেই কাজ করুন», «কখনোই ওটা করবেন না»। তিনটি সমান্তরাল এজেন্ট নিয়ে পরীক্ষা চলাকালীন দুই দিনে আমি এমন ঘটনার একটি জীবন্ত সংগ্রহ জমিয়েছি যেখানে এই পদ্ধতি ভেঙে পড়ে — এবং যেখানে অন্যটি কাজ করে। নিবন্ধের মূল বক্তব্য সরল: নির্দেশনা হলো একটি অনুরোধ, যা এজেন্ট কিছু সম্ভাব্যতায় পালন করে; সীমানা হলো সিস্টেমের একটি বৈশিষ্ট্য, যা আনুগত্যের উপর নির্ভর করে না। যখন এজেন্ট একজন ছিল এবং তত্ত্বাবধানে কাজ করত, পার্থক্যটি শৈলীগত মনে হতো। যখন এজেন্ট অনেক হলো, তখন তা স্থাপত্যগত প্রমাণিত হলো।
এক সেশনের পাঁচটি ঘটনা
নিচের সব ঘটনাই এই ব্লগে একই কাজের সেশনে ঘটেছে — সেগুলো নথিভুক্ত, এবং প্রতিটি দেখায় টেক্সটের মাধ্যমে নিয়ন্ত্রণ কীভাবে ব্যর্থ হয়।
নির্দেশনা ছিল না — দুর্ঘটনা ঘটে গেল। এজেন্ট, তার কাজের প্রস্তুতি নিতে গিয়ে git stash সাধারণ ডিরেক্টরিতে চালাল এবং আমার আনকমিট করা ফাইল, যা তার কাজের সাথে সম্পর্কিত নয়, স্ট্যাশে নিয়ে গেল। কেউ কিছু «লঙ্ঘন» করেনি: নিষেধাজ্ঞা কেবল ছিলই না। এটি নির্দেশনার মৌলিক বৈশিষ্ট্য — সেগুলো দুর্ঘটনার পরে লেখা হয়। এজেন্টের কী করা উচিত নয় তার সম্পূর্ণ তালিকা লেখা অসম্ভব।
নির্দেশনা ছিল — এবং কাজ করেনি। প্রথম দুর্ঘটনার পরে আমি এজেন্টদের একটি স্পষ্ট নিয়ম যোগ করি: «কঠোরভাবে নিজের কাজের ডিরেক্টরিতেই কাজ করো»। একজন এজেন্ট তবুও মূল ডিরেক্টরিতে git-কমান্ড চালাল — শুধু পরম পথে সেটিতে প্রবেশ করল। দুষ্টুমি বা বোকামি থেকে নয়: মডেল সম্ভাব্যতাভিত্তিক, এবং টেক্সট নিয়ম মেনে চলাও একটি সম্ভাব্যতা, যা কনটেক্সটের দৈর্ঘ্য ও রানের সংখ্যা দিয়ে গুণ হয়।
কারিগরি সীমানা নীরবে কাজ করল। একই পরীক্ষায় সবচেয়ে প্রত্যাশিত দুর্ঘটনাটি একবারও ঘটেনি — «এক এজেন্ট সবার ব্র্যাঞ্চ বদলে দিল»। এজেন্টরা সতর্ক ছিল বলে নয়, বরং git worktree শারীরিকভাবে একটি ব্র্যাঞ্চ দুটি কাজের কপিতে লেখার অনুমতি দেয় না। সুরক্ষা টুলে অন্তর্নির্মিত। তা মনে রাখতে হয় না, তা মেনে চলতে হয় না — তা কেবল আছে।
নির্দেশনা সেখানে দাঁড়িয়ে ছিল যেখানে সীমানা থাকা উচিত। সবচেয়ে অপ্রীতিকর আবিষ্কার: এই ব্লগের প্রোড প্রম্পটের একটি লাইন দিয়ে সুরক্ষিত ছিল। master-এ push স্বয়ংক্রিয় ডিপ্লয় চালু করে, এবং প্রতিটি এজেন্ট থেকে তা কেবল «কোনো git push নয়» টেক্সট দিয়ে আলাদা ছিল। তা টিকে ছিল — কিন্তু এটি ভাগ্য, নিয়ন্ত্রণ নয়: এখানে প্রকৃত সীমানা হলো অ্যাক্সেস অধিকার, protected branch, লেখার অধিকারহীন টোকেন। অনুরোধ তালার জায়গায় দাঁড়িয়ে ছিল।
এজেন্টের উপরে সীমানা। সেশনে দুবার রানটাইম পরীক্ষাধীন এজেন্টদের নয়, বরং আমার মূল সহায়ককে থামিয়েছে: অনুমতি শ্রেণিবিন্যাসক প্রোড-সার্ভারে SSH এবং আনকমিট করা পরিবর্তনের ব্যাপক মুছে ফেলা ব্লক করেছে — এমন কাজ যা আনুষ্ঠানিকভাবে কাজ থেকে অনুসৃত, কিন্তু স্পষ্ট মানবিক «হ্যাঁ» দরকার ছিল। উভয় ব্লকই সঠিক ছিল। এবং উভয়ই এজেন্টের «শৃঙ্খলার» উপরে ঘটেছে, যে সম্পূর্ণ আন্তরিকভাবে মনে করেছিল সে পরিকল্পনা অনুযায়ী কাজ করছে।
নীতিটি নতুন নয় — কেবল সত্তাটি নতুন
প্রকৌশল LLM-এর অনেক আগেই এই শিক্ষা পেয়েছে। Toyota-র উৎপাদন ব্যবস্থায় নীতিটির নাম poka-yoke: ভুল প্রতিরোধ করে প্রক্রিয়ার একটি ডিভাইস, নির্বাহকের সতর্কতা নয়। যে যন্ত্রাংশ কেবল সঠিক দিকেই লাগানো যায়, তা «সঠিকভাবে লাগাও» পোস্টারের চেয়ে নির্ভরযোগ্য। প্ল্যাটফর্ম প্রকৌশলে একেই guardrails বলে, নিরাপত্তায় — defense in depth। সবখানে একই ভাবনা: নির্বাহক পড়েছে, বুঝেছে এবং ভোলেনি তার উপর নির্ভর করো না — এমন করো যাতে ভুল কাজ অসম্ভব বা ব্যয়বহুল হয়।
“নির্দেশনা হলো একটি অনুরোধ। সীমানা হলো সিস্টেমের একটি বৈশিষ্ট্য। অনুরোধের উপর নির্ভর করা নিয়ন্ত্রণ নিয়ন্ত্রণ নয়, বরং ক্রমপুঞ্জিত প্রভাবসহ ভাগ্য।”
– সমান্তরাল এজেন্টদের সাথে দুই দিনের কাজের মূল উপসংহার
AI-এজেন্টদের সাথে এই পুরোনো নীতিটি তিনটি কারণে আরও তীক্ষ্ণ হয়। এজেন্ট অনেক — নির্দেশনা ব্যর্থ হওয়ার সম্ভাব্যতা প্রতিটি এজেন্টের প্রতিটি রানে গুণ হয়। এজেন্ট দ্রুত — «ভুল করতে শুরু» ও «ভেঙে ফেলার» মধ্যে সেকেন্ড পেরিয়ে যায়, মানুষ হস্তক্ষেপ করার সময় পায় না। এবং এজেন্ট আক্ষরিক, কিন্তু নির্ভরযোগ্য নয়: তারা প্রম্পটের টেক্সট যেকোনো জুনিয়রের চেয়ে পরিশ্রমসহ পালন করে, তবুও সম্ভাব্যতাভিত্তিকভাবে — এবং স্কেলে নিয়মের সম্ভাব্যতাভিত্তিক পালন লঙ্ঘনের নিশ্চয়তা দেয়।
অনুশীলনে সীমানা কেমন দেখায়
এই সেশনের পরে আমি যে স্তরগুলো গড়েছি — ফাইল সিস্টেম থেকে যাচাই পর্যন্ত:
- ফাইল সিস্টেম: প্রতিটি এজেন্টের জন্য নিজস্ব কাজের কপি (git worktree, যা Anthropic সুপারিশ করে সমান্তরাল সেশনের জন্য, Claude Code-এ তা অন্তর্নির্মিত), এবং OS স্তরে — স্যান্ডবক্স: Claude Code-এ sandboxing OS-এর মানক প্রিমিটিভ দিয়ে ফাইল সিস্টেম ও নেটওয়ার্ক আলাদা করে — Anthropic-এর তথ্য অনুযায়ী, এটি তাদের অভ্যন্তরীণ অনুমতি অনুরোধ ৮৪% কমিয়েছে, এবং সফল prompt-injection ভেতরেই আটকে থাকে।
- লেখার অধিকার: প্রোড এবং মাস্টার প্রম্পটে নয়, অধিকার দিয়ে সুরক্ষিত — protected branch, push ছাড়া টোকেন, এজেন্টদের জন্য আলাদা অ্যাকাউন্ট। প্রম্পটে রাখার অনুরোধ করা যেতে পারে, তবে দ্বিতীয় স্তর হিসেবে।
- রানটাইম: worktree ডেটাবেস, পোর্ট এবং কন্টেইনার আলাদা করে না — সেগুলো সব কপির জন্য সাধারণ। যে এজেন্টরা টেস্ট এবং সার্ভার চালায়, তাদের একবার ব্যবহারযোগ্য রিসোর্স দরকার: সাময়িক ডেটাবেস, নিজস্ব পোর্ট, প্রতি এজেন্টের জন্য কন্টেইনার।
- কাজের অনুমতি: অপরিবর্তনীয় অপারেশনগুলো নিশ্চিতকরণ বা ক্লাসিফায়ারের মধ্য দিয়ে যায় — যেমন Claude Code-এ auto mode, যা সবকিছু জিজ্ঞাসা করা বা কিছুই না জিজ্ঞাসা করার বদলে প্রতিটি কাজ মূল্যায়ন করে। এটি এমন একটি সীমা যা কেবল মানুষের স্পষ্ট সিদ্ধান্তে সরে।
- আর্টিফ্যাক্ট দিয়ে যাচাই: এজেন্টের স্ব-প্রতিবেদনে নয়, ডিস্কের চিহ্নে ভরসা করা। আমার আটকে যাওয়া এজেন্ট ইন্টারফেসে কাজ করছে বলে দেখাচ্ছিল; বিশ মিনিটে তার কপিতে নতুন ফাইল না থাকায় রোগনির্ণয় হলো। নিজের ব্রাঞ্চে কমিট — একই ধারণা: এমন ফলাফল যা ব্যর্থতা এবং এজেন্টের আশাবাদ দুটোই টিকে যায়।
এই স্কিমে নির্দেশনা কোথাও হারায় না — সেগুলো প্রথম নয়, শেষ স্তর হয়ে যায়। প্রম্পটে «নিজের ডিরেক্টরিতে কাজ করো» এখনও উপকারী: এটি চেষ্টার হার কমায়। কিন্তু চেষ্টা এবং দুর্ঘটনার মধ্যে ভরসা নয়, একটি সীমা থাকা উচিত।
সৎ সতর্কতা
সীমা পরম নয়: স্যান্ডবক্স এড়ানো যায়, ক্লাসিফায়ার ভুল করে, এবং প্রকাশিত এড়ানোর বিশ্লেষণগুলো এটি নিয়মিত দেখায়। তাই সীমা স্তরে স্তরে গড়া হয় — নিরাপত্তার সবকিছুর মতোই। আর সীমা শুরুতেই নির্দেশনার চেয়ে বেশি খরচসাপেক্ষ: worktree, অধিকার এবং স্যান্ডবক্স সেট করা — ঘণ্টার কাজ, প্রম্পটে এক লাইন লেখা — সেকেন্ডের। অসামঞ্জস্য অন্য জায়গায়: সীমার খরচ একবার, নির্দেশনার খরচ প্রতিটি রানে ব্যর্থতার সম্ভাবনা। আমার কাছে আইসোলেশন সেটআপ পরিশোধিত হয়েছিল পরীক্ষার প্রথম পুনরারম্ভেই, যা একটিও দ্বন্দ্ব ছাড়াই সম্পন্ন হয়েছিল।
উপসংহার
সিরিজের প্রশ্ন — নিয়ন্ত্রণ না হারিয়ে AI-এজেন্টদের বাস্তব কাজে কীভাবে যুক্ত করা যায়। এই নিবন্ধের উত্তর: নিয়ন্ত্রণ হলো এজেন্টকে যা বলা হয় তা নয়, বরং তার চারপাশে যা গঠিত তা। প্রম্পটে আরেকটি «কখনো X করো না» যোগ করার আগে নিজেকে জিজ্ঞাসা করা উচিত: X-কে প্রযুক্তিগতভাবে অসম্ভব করা যায় কি? যদি যায় — সেটাই প্রচেষ্টার সঠিক জায়গা। প্রম্পট অনুরোধ করুক; নিষেধ করা উচিত সিস্টেমের।
সূত্র ও নির্দেশিকা
- Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — OS স্তরে ফাইল সিস্টেম এবং নেটওয়ার্কের আইসোলেশন; ৮৪% সংখ্যার উৎস।
- How we contain Claude across products (Anthropic Engineering, 2026) — এজেন্ট পণ্যগুলোতে সম্পূর্ণভাবে এক্সিকিউশন সীমা কীভাবে গঠিত।
- How we built Claude Code auto mode (Anthropic Engineering) — «সবকিছু জিজ্ঞাসা করা» এবং «কিছুই না জিজ্ঞাসা করা»-র মধ্যে সীমা হিসেবে অনুমতি ক্লাসিফায়ার।
- Poka-Yoke (Lean Enterprise Institute) — প্রক্রিয়া-ডিজাইনের মাধ্যমে ত্রুটি প্রতিরোধের চিরায়ত নীতি।
- git-worktree এবং git-stash — Git-এর অফিসিয়াল ডকুমেন্টেশন: ওয়ার্কিং কপি এবং সাধারণ স্ট্যাশের কার্যপদ্ধতি।
- Claude Code: Best practices for agentic coding (Anthropic Engineering) — সমান্তরাল সেশনের জন্য worktree-এর সুপারিশ।
- Как честно сравнить LLM на своём коде: эксперимент с тремя моделями Claude — সিরিজের পূর্ববর্তী নিবন্ধ: যে পরীক্ষায় বর্ণিত ঘটনাগুলো সংগৃহীত।
