যখন এজেন্টরা সহকর্মী হয়ে ওঠে: Buzz-এর পেছনের ধারণা
Ai Security Networkসূচিপত্র
Buzz নিয়ে আমি আগেও লিখেছি, তখন মূল ফোকাস ছিল Shared Compute এবং সাধারণ মডেল পরিচালনার উপর। সেটাই আমার কাছে প্রথমে প্রজেক্টের সবচেয়ে আকর্ষণীয় এবং অস্বাভাবিক অংশ মনে হয়েছিল। কিন্তু Buzz নিয়ে যত বেশি সময় কাটিয়েছি, ততই কর্মক্ষেত্রটি নিজেই আরও আকর্ষণীয় হয়ে উঠেছে। তাই আমি এখন Buzz একটি ছোট সেটআপে পরীক্ষা করেও দেখেছি।
এর একটি কারণ হলো গত কয়েক মাসে ক্রমশ স্পষ্ট হয়ে ওঠা একটি সমস্যা। AI নিয়ে আমার কাজ শুধু দ্রুত হয়নি, বরং আরও বিশৃঙ্খলও হয়ে উঠেছে। Codex একটি রিপোজিটরিতে কাজ করছে, Claude Code দ্বিতীয় একটি আইডিয়া যাচাই করছে, অন্য একটি এজেন্ট তথ্য সংগ্রহ করছে, আর মাঝখানে টার্মিনাল, ব্রাউজার, ইমেইল এবং একাধিক চ্যাট চলছে। প্রতিটি এজেন্ট নিজে নিজে দরকারী হতে পারে। সমস্যা তৈরি হয় সংযোগস্থলে। কনটেক্সট কপি করতে হয়, সিদ্ধান্তগুলো বারবার বলতে হয়, আর ফলাফল হাতে হাতে একত্র করতে হয়।
ঠিক এখানেই Buzz কাজে আসে। এই ওপেন-সোর্স প্রজেক্টটি এসেছে Block থেকে, যা Twitter-এর সহপ্রতিষ্ঠাতা Jack Dorsey পরিচালিত এবং Square-এর পেছনের কোম্পানি। এটি আরেকটি AI অ্যাসিস্ট্যান্ট তৈরি করতে চায় না। Buzz একটি সাধারণ কর্মক্ষেত্র তৈরি করে, যেখানে মানুষ এবং এজেন্টরা একই চ্যানেল, থ্রেড, প্রজেক্ট এবং প্রোটোকল ব্যবহার করে। একটি Codex এজেন্ট একটি পরিকল্পনা তৈরি করতে পারে, Claude Code সেটির সমালোচনা করতে পারে, একজন মানুষ সিদ্ধান্ত নিতে পারে এবং পরবর্তী এজেন্ট তা থেকে রিপোজিটরিতে একটি পরিবর্তন তৈরি করতে পারে। পুরো চেইনটি একই জায়গায় দৃশ্যমান থাকে।
দ্রুত ব্যবহৃত শব্দ “Slack-killer” আমার কাছে খুবই সংক্ষিপ্ত মনে হয়। Buzz অনেক এজেন্ট নিয়ে কাজ করা দলের জন্য একটি সম্ভাব্য কাজের ধরন দেখায়। একই সাথে, এটি এখনও নবীন, রিসোর্স-ক্ষুধার্ত এবং নিরাপত্তার দিক থেকে যতটা বন্ধুসুলভ ইন্টারফেস মনে হয় তার চেয়ে বেশি জটিল। বড় ধারণা এবং প্রাথমিক উন্নয়নের এই মিশ্রণই একে আরও ঘনিষ্ঠভাবে দেখার আগ্রহ তৈরি করে।
Buzz সবচেয়ে ভালো এজেন্ট তৈরি করতে চায় না। Buzz সেই স্থান হতে চায় যেখানে বিভিন্ন এজেন্ট এবং মানুষ একসাথে কাজ করতে পারে।
আসল সমস্যাটি মডেল নয়
বেশিরভাগ AI টুল একজন মানুষ এবং একটি এজেন্টের মধ্যে সম্পর্ক হিসেবে তৈরি হয়েছে। আমি Codex খুলি, একটি কাজ লিখি এবং একটি ফলাফল পাই। এরপর Claude Code খুলি, একই পটভূমি আবার ব্যাখ্যা করি এবং দ্বিতীয় মতামত চাই। একক কাজের জন্য এটি ভালো কাজ করে। কিন্তু একটি টিমে বা একসাথে একাধিক এজেন্ট চললে একটি নতুন সমন্বয় সমস্যা তৈরি হয়।
এই সমস্যাটি আমি নিজের দৈনন্দিন কাজেও দেখি। Claude Code, Codex, Hermes, ব্রাউজার, চ্যাট এবং বিভিন্ন টার্মিনাল পাশাপাশি চলে। সেশন প্রোটোকল এক টুল থেকে আরেক টুলে যায়। একটি এজেন্ট মিটিং নোট জানে, আরেকটি রিপোজিটরি জানে, তৃতীয়টি প্রয়োজনীয় অ্যাক্সেস বা স্কিল জানে। প্রত্যেকের কাছে একটি অংশ থাকে, কিন্তু কারও কাছে সাধারণ কাজের অবস্থা থাকে না।
মিশন-কন্ট্রোল ড্যাশবোর্ড এটি শুধু আংশিকভাবে সমাধান করে। এগুলো হয়তো দেখায় যে পাঁচটি এজেন্ট সক্রিয়। কিন্তু এগুলো এমন একটি সাধারণভাবে বোধগম্য জায়গা তৈরি করে না যেখানে অ্যাসাইনমেন্ট, আলোচনা, মধ্যবর্তী অবস্থা, রিভিউ এবং সিদ্ধান্ত একসাথে থাকে। তাই Buzz একটি সুন্দর এজেন্ট তালিকা দিয়ে শুরু করে না, বরং কর্মক্ষেত্র নিয়েই কাজ করে।
এজেন্টরা সদস্য, আলাদাভাবে জোড়া লাগানো বট নয়
প্রথম দর্শনে Buzz পরিচিত মনে হয়। এখানে কমিউনিটি, পাবলিক ও প্রাইভেট চ্যানেল, থ্রেড, ডাইরেক্ট মেসেজ, ফোরাম, সার্চ, হাডল এবং একটি মোবাইল অ্যাপ আছে। সাধারণ Slack ইন্টিগ্রেশনের সাথে মূল পার্থক্য এর নিচে লুকিয়ে আছে।
Buzz-এ একটি এজেন্ট নিজেই একটি সদস্য। এর নিজস্ব প্রোফাইল, একটি ক্রিপ্টোগ্রাফিক কী পেয়ার, চ্যানেল সদস্যপদ এবং নিজস্ব অডিট ট্রেইল রয়েছে। তার বার্তাগুলো তার নিজের পরিচয়ে দেখা যায়। এর ফলে পরে শুধু এটাই দেখা যায় না যে “AI” কিছু করেছে। বরং স্পষ্ট হয় কোন এজেন্ট কাজ করেছে, কোন চ্যানেলে সে অ্যাসাইনমেন্ট পেয়েছে, এবং কোন মানুষ বা অন্য এজেন্ট তাকে সক্রিয় করেছে।
প্রথমে এটি ইউজার ম্যানেজমেন্টের ছোট পরিবর্তন মনে হতে পারে। কিন্তু বাস্তব কাজের জন্য এটি কেন্দ্রীয়। একটি Slack বট সাধারণত একটি ইন্টিগ্রেশনের সাথে জড়িত থাকে এবং একজন মানুষের মেনশনের জন্য অপেক্ষা করে। ভিন্ন প্রদানকারীর দুটি বট সাধারণত একে অপরের সম্পর্কে কিছু জানে না। Buzz-এ এজেন্টরা অন্য এজেন্টদের সম্বোধন করতে পারে, কাজ হস্তান্তর করতে পারে এবং একই থ্রেডে তাদের ফলাফল আলোচনা করতে পারে। এতে Codex এবং Claude Code একটি একক সিস্টেমে পরিণত হয় না। তবে তারা একটি সাধারণ যোগাযোগ স্থান পায়।
Buzz স্বয়ংক্রিয়ভাবে সব বুদ্ধিমত্তা নিজে নিয়ে আসে না। এই কর্মক্ষেত্র তথাকথিত হারনেস এবং মডেলগুলোকে সংযুক্ত করে, যেগুলো ইতিমধ্যে লোকালি, একটি সার্ভারে বা কোনো প্রদানকারীর মাধ্যমে চলছে। বর্তমান প্রজেক্টের অবস্থা অনুযায়ী এর মধ্যে রয়েছে Codex, Claude Code এবং Goose। খোলা ইন্টারফেসের মাধ্যমে আরও এজেন্ট সংযুক্ত করা যেতে পারে। এটি একটি bring-your-own-agent মডেল: Buzz সমন্বয় করে, আর সংশ্লিষ্ট এজেন্ট নিজের টুল, স্কিল, অ্যাক্সেস এবং মডেল খরচ দিয়ে চিন্তা করে ও কাজ করে।
Relay হলো সাধারণ কাজের অবস্থা
প্রযুক্তিগতভাবে Buzz কয়েকটি অংশ নিয়ে গঠিত। ডেস্কটপ অ্যাপ হলো ইন্টারফেস। একটি কমিউনিটি হলো প্রকৃত কর্মক্ষেত্র। Buzz Relay এর বার্তা, সদস্য, এজেন্ট, নিয়ম, মিডিয়া, সার্চ ডেটা, ওয়ার্কফ্লো এবং Git ইভেন্ট সংরক্ষণ ও বিতরণ করে। এজেন্টরা ডেস্কটপ অ্যাপের একই কম্পিউটারে, একটি চিরস্থায়ীভাবে চলমান সার্ভারে বা সম্পূর্ণ ভিন্ন মেশিনে কাজ করতে পারে।
প্রোটোকল হিসেবে Buzz Nostr ব্যবহার করে। মানুষ এবং এজেন্টরা নিজেদের প্রাইভেট কী দিয়ে ইভেন্ট স্বাক্ষর করে। Relay পরিচয় এবং সদস্যপদ যাচাই করে, ইভেন্ট সংরক্ষণ করে এবং অনুমোদিত ক্লায়েন্টদের কাছে বিতরণ করে। তবে এর ফলে Buzz কোনো জাদুকরী পিয়ার-টু-পিয়ার নেটওয়ার্ক হয়ে যায় না। Relay হলো একটি কমিউনিটির কেন্দ্রীয় উৎস। Relay-এর মধ্যে স্বয়ংক্রিয় রেপ্লিকেশন নেই, এবং বার্তাগুলো যে Relay-তে পাঠানো হয়েছে সেখানেই থেকে যায়।
এই গঠনের দুটি আকর্ষণীয় ফলাফল রয়েছে। পরিচয় কোনো কেন্দ্রীয় Slack অ্যাকাউন্টের সাথে সহজভাবে যুক্ত নয়, বরং একটি নিজস্ব কী পেয়ারের উপর ভিত্তি করে গড়ে ওঠে। একই সাথে একটি টিম নিজেই কর্মক্ষেত্র পরিচালনা করতে পারে। যারা প্রথমে শুধু পরীক্ষা করতে চায়, তারা Block দ্বারা হোস্ট করা কমিউনিটি ব্যবহার করতে পারে। যারা ডেটা সংরক্ষণ, উপলব্ধতা এবং ব্যাকআপ নিজেরাই নিয়ন্ত্রণ করতে চায়, তারা নিজস্ব ইনফ্রাস্ট্রাকচারে Relay চালাতে পারে।
বর্তমান সার্ভার আর্কিটেকচার পরিচিত কম্পোনেন্ট ব্যবহার করে: ইভেন্ট এবং ফুল-টেক্সট সার্চের জন্য PostgreSQL, Pub/Sub-এর জন্য Redis, এবং মিডিয়ার জন্য S3-সামঞ্জস্যপূর্ণ স্টোরেজ। এটি ইনস্টলেশনের পর ভুলে যাওয়ার মতো কোনো ছোট সার্ভিস নয়। নিজস্বভাবে পরিচালিত একটি Relay-এর জন্য প্রয়োজন TLS, আপডেট, ব্যাকআপ, মনিটরিং এবং পরিষ্কার কী ব্যবস্থাপনা।
সাধারণ কনটেক্সট কেন এতটা মূল্যবান
Buzz-এর সবচেয়ে শক্তিশালী ধারণা হলো স্থায়ী, একসাথে দৃশ্যমান কনটেক্সট। একটি প্রজেক্ট আর শুধু Slack-এর একটি চ্যাট মেসেজ, একটি আলাদা এজেন্ট রান, GitHub-এর একটি পুল রিকোয়েস্ট এবং ভিডিও কনফারেন্সের একটি সিদ্ধান্তে ভাগ হয়ে থাকে না। Buzz এই চিহ্নগুলোকে একটি ইভেন্ট স্পেসে একত্র করার চেষ্টা করে।
বিভিন্ন এজেন্টের বিভিন্ন শক্তি থাকলে এটি বিশেষভাবে কার্যকর হয়। একটি বাস্তবসম্মত প্রক্রিয়া এমন হতে পারে:
- একজন মানুষ প্রজেক্ট চ্যানেলে লক্ষ্য এবং সীমা বর্ণনা করে।
- একটি রিসার্চ এজেন্ট তথ্য সংগ্রহ করে এবং তার সোর্স নথিভুক্ত করে।
- দ্বিতীয় একটি এজেন্ট দুর্বলতাগুলোতে আক্রমণ করে এবং পাল্টা যুক্তি খোঁজে।
- Codex বা Claude Code একটি নির্দিষ্ট পরিকল্পনা তৈরি করে।
- আরেকটি এজেন্ট পরিকল্পনাটি নিরাপত্তা, অনুপস্থিত টেস্ট বা অস্পষ্ট অনুমানের জন্য যাচাই করে।
- মানুষের অনুমোদনের পর, পরিবর্তনটি একটি আলাদা Worktree-তে বাস্তবায়িত হয়।
- ডিফ, টেস্ট ফলাফল, রিভিউ এবং সিদ্ধান্ত সংশ্লিষ্ট চ্যানেলে খুঁজে পাওয়া যায়।
adversarial রিভিউতে এই প্যাটার্ন বিশেষভাবে আকর্ষণীয়। একটি মডেলকে স্পষ্টভাবে একটি প্রোডাক্ট পরিকল্পনা বা বাস্তবায়নে আক্রমণ করার ভূমিকা দেওয়া হয়। দ্বিতীয় মডেলকে সিদ্ধান্তগুলো রক্ষা করতে বা উন্নত করতে হয়। যেহেতু উভয়েই পুরো থ্রেড দেখতে পায়, একটি প্রকৃত মোকাবিলা তৈরি হয়, শুধু কপি করা টেক্সটের একটি বিচ্ছিন্ন রিভিউ নয়।
কনটেন্ট এবং ব্যবসায়িক প্রক্রিয়ার জন্যও এই প্যাটার্ন আকর্ষণীয়। একটি এজেন্ট বিষয়বস্তু নিয়ে গবেষণা করে, দ্বিতীয়টি লেখে, তৃতীয়টি সম্পাদনা করে। মানুষ এবং এজেন্টরা একসাথে অগ্রগতি নিয়ে আলোচনা করতে পারে যাতে নিয়মিতভাবে মেট্রিক বা নতুন খবর একটি চ্যানেলে প্রবাহিত হতে পারে। হাডল এক ধাপ আরও এগিয়ে যায়: মানুষ এবং এজেন্ট একটি অডিও কনফারেন্সে কথা বলে, কথোপকথনটি টেক্সটে রূপান্তরিত হয় এবং পরে নির্দিষ্ট কাজে পরিণত হতে পারে।
এখানেই Buzz একটি গ্রুপ চ্যাটের চেয়ে বেশি কিছু হয়ে ওঠে। চ্যানেলটি শুধু যোগাযোগের জায়গা নয়। এটি একটি অনুসরণযোগ্য কাজের প্রোটোকলে পরিণত হয়।
Buzz GitHub-কেও প্রতিস্থাপন করতে চায়
Buzz Git রিপোজিটরি, প্যাচ, রিভিউ এবং স্ট্যাটাস ইভেন্টগুলোকে একই কর্মক্ষেত্রে সংযুক্ত করে। Relay নিজেই রিপোজিটরি হোস্ট করতে পারে। এজেন্টরা Worktree ব্যবহার করতে পারে, আলাদাভাবে ভ্যারিয়েন্টে কাজ করতে পারে, পরিবর্তনগুলো প্যাচ হিসেবে প্রস্তুত করতে পারে এবং প্রজেক্ট কনটেক্সটে রিভিউ আলোচনা করতে পারে।
এর পেছনের ভিশনটি শক্তিশালী: একটি ফিচার-ব্র্যাঞ্চ একটি স্থানে পরিণত হয়। সেখানে শুধু কমিটই থাকে না, বরং কেন একটি পরিবর্তন প্রয়োজনীয় ছিল, কোন বিকল্পগুলো বাতিল করা হয়েছিল, CI কী রিপোর্ট করেছে এবং কে মার্জ অনুমোদন করেছে তার আলোচনাও থাকে। বিশেষ করে এজেন্টিক-ভাবে তৈরি কোডের ক্ষেত্রে আজ এই সৃষ্টির ইতিহাস প্রায়ই অনুপস্থিত থাকে।
তবুও আমি এখনই GitHub-কে অকালে বাতিল করব না। GitHub শুধু Git স্টোরেজ নয়, বরং বছরের পর বছর ধরে গড়ে ওঠা অধিকার, রিভিউ, CI/CD, সিকিউরিটি স্ক্যান, রিলিজ, ইন্টিগ্রেশন এবং বাহ্যিক সহযোগিতার একটি ইকোসিস্টেম। Buzz-এর কার্যকরী Git ভিত্তি এবং একটি আকর্ষণীয় forge পদ্ধতি রয়েছে। তবে প্রজেক্টের নিজস্ব স্ট্যাটাস স্পষ্টভাবে ইতিমধ্যে কার্যকরী অংশ, এখনও সংযোগযুক্ত ফাংশন এবং ভিশনের মধ্যে পার্থক্য করে। গুরুত্বপূর্ণ রিপোজিটরির জন্য একটি ধাপে ধাপে ব্যবহার তাৎক্ষণিক মাইগ্রেশনের চেয়ে বেশি বিচক্ষণ।
Buzz-এর সাথে আমার প্রথম পরীক্ষা
আমি সচেতনভাবে ছোট করে শুরু করেছি: একটি নিজস্ব কমিউনিটি, একটি চ্যানেল এবং স্পষ্টভাবে আলাদা ভূমিকাসহ দুটি এজেন্ট। Codex-এর একটি টেকনিক্যাল পরিকল্পনা তৈরি করার কথা ছিল, Claude Code-এর অনুমান, নিরাপত্তা ত্রুটি এবং অপ্রয়োজনীয় জটিলতা আক্রমণ করার কথা ছিল। প্রোডাকশন অ্যাক্সেস ডেটা, গ্রাহক ডেটা এবং সংবেদনশীল রিপোজিটরি বাইরে রাখা হয়েছিল। আমি প্রথমে সর্বাধিক স্বায়ত্তশাসন নয়, বরং সহযোগিতা পরীক্ষা করতে চেয়েছিলাম।
প্রথম খোলা অ্যাসাইনমেন্টটি খুব অস্পষ্ট ছিল। উভয় এজেন্ট পরিকল্পনা করতে শুরু করেছিল, একে অপরের প্রতিক্রিয়া দিচ্ছিল এবং শেষ পর্যন্ত পরবর্তী নির্দেশের জন্য অপেক্ষা করছিল। এটি একটি ভালো স্মরণিকা ছিল যে একটি সাধারণ চ্যানেল এখনও অর্কেস্ট্রেশন প্রতিস্থাপন করে না। “Codex পরিকল্পনা তৈরি করবে, Claude সেটি যাচাই করবে, এরপর তোমরা অনুমোদনের জন্য অপেক্ষা করবে” এই স্পষ্ট নির্দেশের সাথে প্রক্রিয়াটি অনেক বেশি শান্ত এবং অনুসরণযোগ্য হয়ে উঠেছিল। বেশি এজেন্ট কোনো প্রক্রিয়ার সংজ্ঞা প্রতিস্থাপন করে না।
আমাকে সবচেয়ে বেশি প্রভাবিত করেছে একটি চমকপ্রদ একক উত্তর নয়, বরং মিডিয়া বিরতির অনুপস্থিতি। উভয় এজেন্ট একই থ্রেড দেখেছিল, সমালোচনাটি মূল পরিকল্পনার পাশে থেকে গিয়েছিল, এবং আমি সবসময় জানতে পারতাম কে ঠিক কাজ করছে। আমাকে উইন্ডোর মধ্যে কোনো টেক্সট কপি করতে হয়নি এবং দ্বিতীয় কোনো এজেন্টকে পূর্ব ইতিহাস আবার ব্যাখ্যা করতে হয়নি। ঠিক এখানেই আমার কাছে Buzz-এর প্রকৃত মূল্য নিহিত।
তীব্র সফটওয়্যার ডেভেলপমেন্টের জন্য Codex বা Claude Code-এ সরাসরি কাজ তবুও দ্রুততর ছিল। Buzz যোগাযোগ, লগিং এবং সাধারণ কনটেক্সট যোগ করে। এই স্তরটি সময় এবং টোকেন খরচ করে। প্রতিটি অতিরিক্ত এজেন্টের নিজস্ব সেশন থাকে, এবং একাধিক মডেলের ক্ষেত্রে বিস্তৃত চ্যানেল হিস্ট্রি বারবার প্রক্রিয়া করা হতে পারে। তাই দীর্ঘ কোডিং রানের জন্য আমি এখনও নেটিভ হারনেস ব্যবহার করব এবং Buzz বরং পরিকল্পনা, হস্তান্তর এবং রিভিউয়ের জন্য ব্যবহার করব।
আমি এখনও পর্যাপ্ত গভীরভাবে পরীক্ষা করিনি ওয়ার্কফ্লো, দীর্ঘ হাডল, লোকাল মডেল এবং একাধিক স্থায়ীভাবে চলমান রিমোট এজেন্ট। ঠিক এখানেই Buzz-কে দৈনন্দিন জীবনে প্রমাণ করতে হবে যে কাজগুলো শুধু সুন্দরভাবে দৃশ্যমান নয়, বরং নির্ভরযোগ্যভাবে সম্পন্নও হয়। সফটওয়্যারটি এখনও ভার্সন ১.০-এর আগে এবং কিছু জায়গায় তদনুযায়ী নবীন মনে হয়। পরীক্ষার জন্য এটি ঠিক আছে। কিন্তু কেন্দ্রীয় প্রক্রিয়াগুলোর জন্য এখনও নিয়ন্ত্রণ, পুনরাবৃত্তি লজিক এবং একটি স্পষ্ট ম্যানুয়াল ফিরে যাওয়ার পথ প্রয়োজন।
সাধারণ কনটেক্সট একটি নিরাপত্তা সীমানাও
Buzz-কে যা দরকারী করে তোলে, তা একই সাথে আক্রমণের ক্ষেত্রও বাড়িয়ে দেয়। একটি সংযুক্ত Codex, Claude Code বা Hermes এজেন্ট সম্ভবত ফাইল অ্যাক্সেস, শেল, ব্রাউজার, MCP সার্ভার, ইমেইল, ক্যালেন্ডার বা অন্যান্য অভ্যন্তরীণ টুল নিয়ে আসে। যদি একজন টিম সদস্য এই এজেন্টকে সম্বোধন করতে পারে, তবে অনুমতি একটি চ্যাট উত্তর লেখার চেয়ে অনেক দূর পর্যন্ত পৌঁছায়।
তাই সবচেয়ে গুরুত্বপূর্ণ নিয়মটি হলো: একটি এজেন্ট শুধুমাত্র সেই চ্যানেলে কাজ করতে পারবে, যার বিষয়বস্তু এবং সদস্যরা তার টুল অ্যাক্সেসের সাথে সামঞ্জস্যপূর্ণ। চ্যানেল সদস্যপদই কেন্দ্রীয় অ্যাক্সেস গেট। যে সদস্য, সে পড়তে এবং লিখতে পারে। যে সদস্য নয়, সে প্রাইভেট চ্যানেল দেখতেও পারবে না এবং সেগুলোর ইভেন্ট সাবস্ক্রাইবও করতে পারবে না।
ক্রিপ্টোগ্রাফিক স্বাক্ষরও প্রতিটি অডিট সমস্যার সমাধান করে না। Buzz-এ একটি চেইনযুক্ত, ম্যানিপুলেশন-দৃশ্যমান অডিট লগ রয়েছে। ডেটাবেসে লেখার অ্যাক্সেসযুক্ত একজন আক্রমণকারী ম্যানিপুলেশনের পরে চেইনটি পুনরায় গণনা করতে পারবে। তাই লগটি tamper-evident, tamper-resistant নয়। এটি পরিবর্তন শনাক্তযোগ্য করে তোলে, যতক্ষণ পর্যন্ত স্টোরেজের বিশ্বাসের ভিত্তি সম্পূর্ণভাবে ভেঙে না পড়ে।
Block-হোস্ট করা কমিউনিটির জন্য আরেকটি বিষয় যোগ হয়: বার্তা, ডাইরেক্ট মেসেজ এবং আপলোড করা মিডিয়া এন্ড-টু-এন্ড এনক্রিপ্টেড নয়। Block পরিচালনা, নিরাপত্তা, মডারেশন বা আইনি বাধ্যবাধকতার জন্য এই কনটেন্ট দেখতে পারে। এছাড়াও, যদি একটি এজেন্ট কোনো ক্লাউড সার্ভিস ব্যবহার করে, তাহলে সংশ্লিষ্ট মডেল প্রদানকারী প্রম্পট এবং চ্যানেল কনটেন্ট পেতে পারে।
সেলফ-হোস্টিং ডেটা মালিকানা পরিবর্তন করে, কিন্তু স্বয়ংক্রিয়ভাবে পুরো ডেটা প্রবাহ পরিবর্তন করে না। একটি নিজস্ব Relay বার্তা এবং ফাইল নিজস্ব ইনফ্রাস্ট্রাকচারে রাখে। এজেন্ট এখনও একটি ক্লাউড মডেল ব্যবহার করলে, অ্যাসাইনমেন্টের জন্য প্রয়োজনীয় ডেটা তবুও Relay ছেড়ে চলে যায়। তাই সত্যিকারের লোকাল অপারেশনের জন্য একটি নিজস্ব Relay এবং লোকাল মডেল ও লোকাল টুল উভয়েরই প্রয়োজন। Buzz Shared Compute-এর সম্ভাবনা এবং সীমা নিয়ে আমি আগেই আলাদাভাবে লিখেছি।
আমি আপাতত Buzz কীভাবে ব্যবহার করছি
আমার প্রথম পরীক্ষার জন্য আমি একটি ছোট, স্পষ্টভাবে সীমাবদ্ধ কমিউনিটি ব্যবহার করেছি। কোনো প্রোডাকশন অ্যাক্সেস ডেটা নয়, কোনো গ্রাহক ডেটা নয় এবং গোপনীয়তাযুক্ত কোনো রিপোজিটরি নয়। দুটি এজেন্টই যথেষ্ট ছিল: একটি তৈরি করে, একটি যাচাই করে। এর সাথে আমি একজন মানুষ হিসেবে অ্যাসাইনমেন্ট, অনুমোদনের পয়েন্ট এবং বন্ধ করার শর্ত নির্ধারণ করি।
আমার প্রথম সেটআপ শত শত এজেন্টসহ কোনো স্বায়ত্তশাসিত প্রতিষ্ঠান ছিল না, বরং একটি সীমিত রিভিউ ছিল:
- একটি এজেন্ট একটি বিদ্যমান ইস্যু থেকে একটি টেকনিক্যাল পরিকল্পনা তৈরি করে।
- দ্বিতীয় একটি এজেন্ট নিরাপত্তা ত্রুটি, অনুপস্থিত অনুমান এবং অপ্রয়োজনীয় জটিলতা খোঁজে।
- উভয়কেই সোর্স, ফাইল এবং খোলা প্রশ্নগুলো উল্লেখ করতে হয়।
- সর্বোচ্চ দুই রাউন্ড আলোচনার পরে দলটি মানুষের অনুমোদনের জন্য অপেক্ষা করে।
- এরপরই একটি এজেন্ট একটি বিচ্ছিন্ন Worktree-তে পরিবর্তন প্রস্তুত করতে পারবে।
এভাবে আমি সাথে সাথে আমার পুরো অপারেশন পুনর্গঠন না করেই Buzz-এর প্রকৃত শক্তি পরীক্ষা করতে পেরেছি। একই সাথে টোকেন খরচ, লেটেন্সি, অধিকার এবং অনুসরণযোগ্যতা দৃশ্যমান হয়ে উঠেছিল।
একক কাজে একটি একক কোডিং অ্যাসাইনমেন্টের জন্য আমি সরাসরি এজেন্ট ইন্টারফেসেই থাকি। এটি দ্রুততর এবং নিয়ন্ত্রণ করা সহজ। Buzz আকর্ষণীয় হয়ে ওঠে যখন একাধিক মানুষ, একাধিক এজেন্ট বা একাধিক কাজের প্রবাহের একই কনটেক্সট প্রয়োজন হয়। তাই ছোট ডেভেলপার টিম, এজেন্সি, গবেষণা গোষ্ঠী এবং টেকনিক্যালি দক্ষ সোলোপ্রেনিয়াররাই সবচেয়ে স্বাভাবিক লক্ষ্য গোষ্ঠী।
একটি বড় প্রতিষ্ঠানের জন্য আমি আরও সতর্ক থাকব। ভার্সন ১.০-এর আগে, দীর্ঘমেয়াদী সাপোর্ট লাইন ছাড়া এবং এখনও নবীন ওয়ার্কফ্লো সহ, আমি Buzz-কে গুরুত্বপূর্ণ যোগাযোগ বা সোর্স কোডের একমাত্র জায়গা বানাব না। একটি পাইলট প্রজেক্ট যুক্তিসঙ্গত হতে পারে। বর্তমানে Slack এবং GitHub-এর সম্পূর্ণ প্রতিস্থাপন প্রজেক্টের উন্নয়নের গতির উপর একটি বাজি হবে।
Buzz-এর পেছনের ধারণা বর্তমান ক্লায়েন্টের চেয়ে বড়
আমার কাছে Buzz-এর সবচেয়ে আকর্ষণীয় অংশ কোনো একক ফিচার নয়। চ্যানেল, ফোরাম, হাডল, Git হোস্টিং এবং লোকাল মডেল অন্য জায়গায়ও পাওয়া যায়। নতুন বিষয়টি হলো এই ধারাবাহিক ধারণা যে এজেন্টরা আর শুধু একক ব্যবহারকারীর ব্যক্তিগত টুল নয়। তারা একটি সাধারণ কাজের প্রক্রিয়ার দৃশ্যমান অংশগ্রহণকারীতে পরিণত হচ্ছে।
এর ফলে প্রশ্নটি পরিবর্তিত হয়। আমরা আর শুধু জিজ্ঞাসা করি না কোন মডেল সবচেয়ে ভালো কোড লেখে। আমাদের সিদ্ধান্ত নিতে হবে কীভাবে মানুষ এবং একাধিক এজেন্ট কাজ ভাগ করবে, কনটেক্সট শেয়ার করবে, একে অপরকে নিয়ন্ত্রণ করবে এবং দায়বদ্ধতা অনুসরণযোগ্য রাখবে। ঠিক এর জন্যই আজ প্রায়ই সামাজিক এবং প্রযুক্তিগত অবকাঠামোর অভাব রয়েছে।
Buzz এখনও একটি সম্পূর্ণ উত্তর দেয় না। সফটওয়্যারটি নবীন, কিছু ওয়ার্কফ্লো অবিশ্বস্ত, সাধারণ কনটেক্সট ব্যয়বহুল হয়ে উঠতে পারে এবং সেলফ-হোস্টিং প্রকৃত পরিচালনার দায়িত্ব নিয়ে আসে। তবুও প্রজেক্টটি একটি বাস্তব সমস্যাকে স্পর্শ করে। এজেন্টরা যত বেশি কাজ গ্রহণ করবে, ততই পাঁচটি আলাদা চ্যাট পাশাপাশি খোলা যথেষ্ট নয়। আমাদের একটি সাধারণ জায়গা দরকার, যেখানে তাদের কাজ দৃশ্যমান, সীমাবদ্ধ এবং যাচাইযোগ্য থাকে।
হয়তো Buzz একদিন Slack এবং GitHub প্রতিস্থাপন করবে। আজকের জন্য একটি ছোট কিন্তু আরও গুরুত্বপূর্ণ কথাই যথেষ্ট: Buzz একটি বিশ্বাসযোগ্য নকশা দেখায়, একটি কর্মক্ষেত্র কেমন হতে পারে যখন সেখানে আর শুধু মানুষ কাজ করে না। Shared Compute আমার নজর প্রজেক্টের দিকে টেনেছিল। সাধারণ কর্মক্ষেত্রই সেই কারণ, যার জন্য আমি Buzz পরীক্ষা করা চালিয়ে যাব।
প্রথম পরীক্ষার পর আমার সিদ্ধান্ত
আমার সংক্ষিপ্ত পরীক্ষায় Buzz ঠিক সেই সমস্যাটি স্পর্শ করেছে, যা আমার AI এজেন্টদের সাথে বর্তমানে রয়েছে। একক মডেলগুলো অনেক আগেই আর বাধা নয়। কঠিন বিষয়টি হলো একাধিক এজেন্ট, সিদ্ধান্ত এবং ফলাফলকে একটি সাধারণ লাইনে রাখা। Buzz এই কাজটি দৃশ্যমান করে এবং Codex, Claude Code ও অন্যান্য এজেন্টদের এমন একটি জায়গা দেয়, যেখানে তারা শুধু আমার প্রতি নয়, একে অপরের প্রতিও প্রতিক্রিয়া জানাতে পারে।
আমাকে সাধারণ কনটেক্সট, স্পষ্টভাবে আলাদা এজেন্ট পরিচয় এবং একটি ফলাফল সরাসরি দ্বিতীয় একটি মডেল দিয়ে আক্রমণ করানোর সম্ভাবনা প্রভাবিত করেছে। অতিরিক্ত ওভারহেড আমাকে কম প্রভাবিত করেছে। একটি একক কোডিং অ্যাসাইনমেন্টের জন্য Codex বা Claude Code-এর মাধ্যমে সরাসরি পথ এখনও দ্রুততর। যখনই একাধিক এজেন্ট বা মানুষ জড়িত থাকে, তখনই Buzz তার শক্তি দেখাতে শুরু করে।
আমার পরীক্ষাটি ইচ্ছাকৃতভাবে সংক্ষিপ্ত ছিল। আমি স্থায়ী টিম অপারেশন, বড় রিপোজিটরি, জটিল ওয়ার্কফ্লো বা দীর্ঘ লোড স্পাইক কোনোটিই যাচাই করিনি। কারণ সফটওয়্যারটি এখনও নবীন এবং খুব দ্রুত পরিবর্তিত হচ্ছে। আমি আজ Buzz-কে গুরুত্বপূর্ণ যোগাযোগ বা সোর্স কোডের একমাত্র জায়গা বানাব না। কিন্তু একটি ছোট টিম, একটি এজেন্সি বা ব্যক্তিগত AI ল্যাবের জন্য এটি ইতিমধ্যে একটি আকর্ষণীয় ডেমোর চেয়ে বেশি কিছু। এটি এমন একটি টুল, যা আমি ব্যবহার চালিয়ে যেতে চাই এবং আমার দৈনন্দিন কাজে সুনির্দিষ্টভাবে যুক্ত করতে চাই।
পরবর্তীবার পর্যন্ত,
Joe
