আমার AI এজেন্টরা আমাদের টিম চ্যাটে ফলাফল পোস্ট করেছিল। একজন মানুষ উত্তর দিলেন, এবং একটি দ্বিতীয় এজেন্ট প্রথম মেসেজটি না দেখেই সেখানে ঢুকে পড়ল। এই ধারাবাহিকতায় প্রেক্ষাপট হারিয়ে যাওয়া (missed context), কাজের পুনরাবৃত্তি এবং সরাসরি ভুলগুলো তৈরি হলো। বিদ্যমান মেমরি সার্ভার এবং মনিটরিং স্ট্যাকে একটি হালকা ওজনের Inter-Agent Communication Protocol (IACP) যুক্ত করার পর, এই বিশৃঙ্খলা থেমে গেল এবং কাজের ধারা আরও সুসংহত হলো।

কেন এই সমস্যাটি গুরুত্বপূর্ণ ছিল

প্রোডাকশনে, AI এজেন্টগুলো আর বিচ্ছিন্ন কোনো পরীক্ষা নয়; তারা মাইক্রো-সার্ভিস হিসেবে কাজ করে যা ডেটা সংগ্রহ করে, কোড তৈরি করে বা ডিপ্লয়মেন্ট ট্রিগার করে। যখন প্রতিটি এজেন্ট শুধুমাত্র মানুষের সাথে কথা বলে, তখন দায়িত্বের ওভারল্যাপ একটি লুকানো রেস কন্ডিশন (race condition) হয়ে দাঁড়ায়। একটি সাধারণ স্ল্যাক (Slack) মেসেজ নিরীহ মনে হতে পারে, কিন্তু ডেভেলপারদের পরস্পরবিরোধী আউটপুট সামলাতে কয়েক মিনিট সময় নষ্ট হয়, দুটি বট যখন একই রিপোজিটরি এডিট করে তখন পাইপলাইন আটকে যায় এবং অটোমেশনের ওপর আস্থা কমে যায়।

অনুপস্থিত লিঙ্ক: রিয়েল-টাইম শেয়ার্ড স্টেট

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

বিদ্যমান টুলের ওপর IACP তৈরি করা

সম্পূর্ণ নতুন প্ল্যাটফর্ম তৈরি করার পরিবর্তে, আমি কথোপকথনের ইতিহাস সংরক্ষণকারী মেমরি সার্ভার এবং এজেন্টের স্বাস্থ্য ট্র্যাক করার মনিটরিং স্যুটটিকে বর্ধিত করেছি। এই প্রোটোকলটি পাঁচটি সুনির্দিষ্ট সক্ষমতা যোগ করে:

  • Structured Identity – প্রতিটি আউটবাউন্ড মেসেজে claude@greenmac:8f3a2c-এর মতো একটি অনন্য আইডেন্টিফায়ার থাকে। এই ফরম্যাটটি রিসিভারকে তাৎক্ষণিকভাবে জানিয়ে দেয় যে মেসেজটি কে এবং কোন ইন্সট্যান্স থেকে পাঠিয়েছে, যা অস্পষ্ট “বট বলছে X” জাতীয় বক্তব্য দূর করে।

  • History Injection – উত্তর দেওয়ার আগে, একটি বট অন্যান্য এজেন্টদের মেসেজসহ সাম্প্রতিক চ্যাট সেগমেন্টটি সংগ্রহ করে এবং সেটি তার প্রম্পটের শুরুতে যুক্ত করে। ফলে প্রেক্ষাপট কখনো হারিয়ে যায় না এবং মডেলটি তার সহকর্মীরা ইতিমধ্যে কী অবদান রেখেছে তা নিয়ে যুক্তি দিতে পারে।

  • State Transitions – এজেন্টরা ঘন ঘন হার্টবিট পাঠানো বন্ধ করে দেয়। পরিবর্তে, তাদের অভ্যন্তরীণ স্টেট পরিবর্তিত হওয়ার সাথে সাথে তারা একটি স্ট্যাটাস পরিবর্তন পোস্ট করে—working, blocked, অথবা idle। কনজিউমাররা তাৎক্ষণিকভাবে এতে প্রতিক্রিয়া জানায়, উদাহরণস্বরূপ একটি ডিপেন্ডেন্ট টাস্ক তখনই কিউ (queue) করা হয় যখন আপস্ট্রিম এজেন্ট idle রিপোর্ট করে।

  • Advisory Leases – যখন কোনো এজেন্টের কোনো রিসোর্সের (একটি রিপো, একটি API এন্ডপয়েন্ট, একটি কম্পিউট নোড) ওপর একচেটিয়া অ্যাক্সেস প্রয়োজন হয়, তখন এটি একটি TTL (time-to-live)-সহ একটি লিজ দাবি করে। যদি এজেন্টটি ক্র্যাশ করে, তবে লিজটি স্বয়ংক্রিয়ভাবে শেষ হয়ে যায়, যা রিসোর্সটি অন্যদের জন্য উন্মুক্ত করে এবং দুটি বট যাতে একে অপরের কাজে বাধা না দেয় তা নিশ্চিত করে।

  • Inbox Mechanism – যদি এজেন্টের ইনবক্সে কোনো না পড়া মেসেজ থাকে, তবে একটি “stop hook” এজেন্টের ওয়ার্কফ্লো সাময়িকভাবে থামিয়ে দেয়। বর্তমান কাজ শেষ করার আগে এজেন্টকে অবশ্যই সেই আইটেমগুলো প্রসেস করতে হবে, যা নিশ্চিত করে যে পেন্ডিং কোঅর্ডিনেশন সিগন্যালগুলো অবহেলিত হচ্ছে না।

এই অংশগুলো একটি সহজ এবং পর্যবেক্ষণযোগ্য কমিউনিকেশন লেয়ার তৈরি করে যা প্রতিটি অংশগ্রহণকারীকে একই প্রেক্ষাপটে রাখে।

যেসব টিম এটি অবহেলা করে তাদের ঝুঁকি

যদি কোনো টিম অ্যাড-হক প্রম্পট এবং ম্যানুয়াল মনিটরিংয়ের ওপর নির্ভর করতে থাকে, তবে লুকানো খরচগুলো বাড়তে থাকে:

  • Duplicated effort – দুটি এজেন্ট একই রিপোর্ট তৈরি করতে পারে, যা কম্পিউট সাইকেল এবং ক্লাউড খরচ বাড়িয়ে দেয়।
  • Resource contention – একটি কোডবেসে একই সাথে রাইট (write) করার ফলে মার্জ কনফ্লিক্ট তৈরি হয় যার জন্য মানুষের হস্তক্ষেপ প্রয়োজন হয়।
  • Operational risk – একটি এজেন্ট যদি পুরনো স্ট্যাটাসের ওপর ভিত্তি করে কাজ করে, তবে সেটি হয়তো ডিপ্লয়মেন্ট করার চেষ্টা করতে পারে যখন অন্য একটি এজেন্ট ইতিমধ্যে রোলব্যাক করছে, যা সার্ভিসকে অস্থিতিশীল করে তোলে।

এজেন্টরা কীভাবে তাদের পরিচয়, স্টেট এবং রিসোর্স দাবি ঘোষণা করবে তা আনুষ্ঠানিক করার মাধ্যমে, IACP কোনো ভারী ওজ heavy-weight অর্কেস্ট্রেশন ইঞ্জিন ছাড়াই এই ঝুঁকিগুলো কমিয়ে আনে।

পাল্টা যুক্তি: অতিরিক্ত ওভারহেড

সমালোচকরা যুক্তি দেন যে হিস্ট্রি ইনজেক্ট করা এবং লিজ ম্যানেজ করা ল্যাটেন্সি এবং অতিরিক্ত কোড পাথ তৈরি করে। যেসব পরিবেশে একটি একক এজেন্ট একটি নির্দিষ্ট কাজ সম্পন্ন করে, সেখানে এই প্রোটোকলের সুবিধা সামান্য হতে পারে। তবে, এই ইমপ্লিমেন্টেশনটি বিদ্যমান মেমরি এবং মনিটরিং সার্ভিসগুলোকেই পুনরায় ব্যবহার করে, তাই অতিরিক্ত লোড খুবই সামান্য। যেসব টিম ইতিমধ্যে এজেন্টদের মধ্যে বিভ্রান্তি অনুভব করছে, তাদের জন্য এই বিনিময়টি (trade-off) স্পষ্টতই লাভজনক।

পরবর্তী লক্ষ্য

প্রোটোকলটি এখনও একটি প্রোটোটাইপ হিসেবে রয়েছে, তবে এর মডুলার প্রকৃতি যেকোনো ল্যাঙ্গুয়েজ-অ্যাগনস্টিক (language-agnostic) এজেন্ট ফ্রেমওয়ার্কের সাথে ইন্টিগ্রেশনের সুযোগ দেয়। সম্ভাব্য পরবর্তী পদক্ষেপগুলোর মধ্যে রয়েছে:

  • একটি লাইটওয়েট SDK প্রকাশ করা যাতে ডেভেলপাররা কোর লজিক পরিবর্তন না করেই পাঁচটি হুক যুক্ত করতে পারেন।
  • মনিটরিং সুইটে এমন মেট্রিক্স যোগ করা যা স্টেট ট্রানজিশন এবং লিজ চর্ন ভিজ্যুয়ালাইজ করতে পারে, যা টিমগুলোকে বাটলনেক শনাক্ত করতে সাহায্য করবে।
  • পলিসি লেয়ার নিয়ে পরীক্ষা-নিরীক্ষা করা যা হাই-ট্রাফিক পরিস্থিতিতে স্বয়ংক্রিয়ভাবে নির্দিষ্ট কিছু এজেন্টের লিজকে অন্যদের তুলনায় অগ্রাধিকার দেবে।

যদি এই এক্সটেনশনগুলো জনপ্রিয়তা পায়, তবে IACP মাল্টি-এজেন্ট প্রোডাকশন পাইপলাইনের জন্য একটি ডি-ফ্যাক্টো স্ট্যান্ডার্ড হয়ে উঠতে পারে, ঠিক যেমনটি HTTP ওয়েব সার্ভিসের ক্ষেত্রে করেছিল।

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