এজেন্টিক ডিজাইন প্যাটার্নস সম্পর্কে নতুন বই এআই এজেন্টগুলির বোঝাপড়াকে পুনরায় গঠন করছে

লেখক：যানহুয়া

অ্যান্টনিও গুল্লি গুগলের ইঞ্জিনিয়ারিং ডিরেক্টর। তিনি ৪৫৩ পৃষ্ঠার একটি বই লিখেছেন, যেখানে এআই এজেন্ট ডেভেলপমেন্টকে ২১টি ডিজাইন প্যাটার্নে বিভক্ত করা হয়েছে।

কিন্তু এটি একটি বই সমালোচনা নয়। আমি এই বইটি পড়ার উদ্দেশ্য খুব নির্দিষ্ট: আমি Harness Engineering লিখেছি, Clawdbot-এর বাধাগুলির অভিজ্ঞতা লিখেছি, “AI এজেন্টগুলি জাদু নয়” এই প্রবন্ধটি লিখেছি যেখানে টোকেন পোড়ানোর থেকে প্রকৃতপক্ষে কার্যকর হওয়ার সাতটি পরিবর্তনের কথা বলা হয়েছে; প্রতিবার লেখার পরেই একটি পূর্ণাঙ্গভাবে বুঝতে পারা যায়নি প্রশ্ন থাকত: এইসবের পিছনে কি একটি পুনরায় ব্যবহারযোগ্য মৌলিক যুক্তি আছে?

এই বইটি আমাকে উত্তর দিয়েছে, এবং আমার চেয়ে বেশি গভীর।

তুমি যা লিখেছো সেটা সম্ভবত এজেন্ট নয়

প্রোলোগেই বইটির সবচেয়ে কঠোর বিচার লুকিয়ে আছে।

অধিকাংশ মানুষ যে এআই ব্যবহার করে, তা শুধু Level 0: বিনা টুল, বিনা মেমোরি, বিনা ক্রিয়াকলাপ সহ প্রত্যক্ষ LLM। আপনি যদি জিজ্ঞাসা করেন যে 2025 সালের অস্কার সেরা চলচ্চিত্রটি কোনটি, তাহলে সে অনুমান করবে। বইটিতে খুব স্পষ্টভাবে বলা হয়েছে: Level 0 জিনিসগুলি Agent নয়।

উপরের দিকে যাওয়াই সত্যিকারের এজেন্ট:

• লেভেল 1: টুল ব্যবহারকারী

  এজেন্ট এখন টুল ব্যবহার শুরু করছে: অনুসন্ধান, API, ডাটাবেস। কিন্তু এটি শুধু “ইন্টারফেস কল করতে পারে” এটাই নয়, এটাকে নিজে বুঝতে হবে কখন কল করবে, কী কল করবে, এবং ফলাফলটি কীভাবে ব্যবহার করবে। বইটিতে একটি খুব স্পষ্ট উদাহরণ দেওয়া হয়েছে: ব্যবহারকারী জিজ্ঞাসা করল “সাম্প্রতিককালে কোন নতুন ওয়েবসিরিজ এসেছে?”, এজেন্টটি নিজেই বুঝতে পারল যে এই তথ্যটি ট্রেনিং ডেটার মধ্যে নেই, তাই সে সক্রিয়ভাবে অনুসন্ধান টুলটি কল করল এবং ফলাফলগুলি সংহত করল। মূল পদক্ষেপটি “নিজেই বুঝতে”। মানুষ তাকে “তুমি একটু搜索 করো” বলছেননি, বরং এটি নিজেই বুঝলো যে搜索-এর প্রয়োজন। এই বিচারক্ষমতাই Level 1-এর দরজা।

• পর্যায় ২: কৌশলগত চিন্তাবিদ

  দুটি জিনিস যোগ হয়েছে: পরিকল্পনা এবং Context Engineering। বইটিতে Context Engineering-এর সংজ্ঞা দেওয়া হয়েছে: তথ্যের স্তূপ তৈরি নয়, বরং পরিকল্পিতভাবে প্রাসঙ্গিক তথ্য বাছাই, কাটিয়ে ফেলা এবং প্যাকেজ করা। উদাহরণটি অসাধারণ: ব্যবহারকারী দুটি স্থানের মধ্যে একটি কফি শপ খুঁজছে। Agent প্রথমে ম্যাপ টুলটি কল করে অসংখ্য ডেটা পায়, তারপর নিজেই বিচার করে “পরবর্তী ধাপে শুধুমাত্র রাস্তার নামটি প্রয়োজন”, ম্যাপের আউটপুটকে একটি ছোট তালিকায় কাটিয়ে ফেলে, তারপর সেটি স্থানীয় অনুসন্ধান টুলের জন্য প্রদান করে। প্রতিটি ধাপেই তথ্যের শব্দ কমানোর চেষ্টা করা হচ্ছে।

  বইয়ে একটি বাক্য আমি কয়েকবার পড়েছি: “AI-কে সর্বোচ্চ সঠিকতা অর্জনের জন্য এটিকে ছোট, ফোকাসযুক্ত এবং শক্তিশালী কনটেক্সট দিতে হবে।” Context Engineering ঠিক এই কাজটি করে।

  এই স্তরে, এজেন্ট নিজেকে পুনর্বিবেচনা করতে পারে। কাজ শেষ করে নিজে একবার পরীক্ষা করে, সমস্যা খুঁজে পেলে নিজেই সংশোধন করে। আমি পরে বিস্তারিত ব্যাখ্যা করব।

• লেভেল ৩: মাল্টি-এজেন্ট সহযোগিতা

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

এই চারটি লেভেল দেখার পর, আমি হঠাৎ বুঝতে পারলাম কেন অনেকে বলে “আমার Agent ভালো কাজ করছে না”। মডেলটির সমস্যা নেই, সমস্যা হলো আপনি এটিকে একটি চ্যাটবট হিসেবে ব্যবহার করছেন, এবং এটি হয়তো Level 1-এও পৌঁছায়নি।

কনটেক্সট ইঞ্জিনিয়ারিং: বইয়ের সবচেয়ে কম মূল্যায়িত ধারণা

আমি একটি হারনেস ইঞ্জিনিয়ারিং লিখেছিলাম, যেখানে বলা হয়েছে যে রেসকোর্সের ডিজাইন ইঞ্জিনের অশ্বশক্তির চেয়ে বেশি গুরুত্বপূর্ণ। এই বইটি পড়ে আমি বুঝতে পারলাম যে Context Engineering হল প্রম্পট স্তরে হারনেস ইঞ্জিনিয়ারিং-এর ম্যাপিং।

প্রাচীন Prompt Engineering শুধু “আপনি কিভাবে জিজ্ঞাসা করেন” নিয়ন্ত্রণ করে। বইয়ের Context Engineering নিয়ন্ত্রণ করে “জিজ্ঞাসা করার আগে, Agent-এর সামনে কী রাখা আছে”। এটি চারটি স্তরের তথ্য অন্তর্ভুক্ত করে:

1. প্রথম স্তর, সিস্টেম প্রম্পট। এজেন্ট কে তার কথাবার্তা এবং সীমানা সংজ্ঞায়িত করে। অধিকাংশ মানুষ শুধু এই স্তরটি লিখেছে।

2. দ্বিতীয় স্তর, বাহ্যিক ডেটা। RAG দ্বারা অনুসন্ধানকৃত দলিল, টুল কলের রিটার্ন ভ্যালু, রিয়েল-টাইম API ডেটা। এটি বেশিরভাগ মানুষের জন্য বাধা: ডেটা দেওয়ার কথা জানা থাকলেও মডেলকে ভেসে যাওয়ার থেকে বাঁচাতে কীভাবে ডেটা দেবেন তা জানা থাকে না।

3. তৃতীয় স্তর, নিহিত ডেটা। ব্যবহারকারীর পরিচয়, ইন্টারঅ্যাকশনের ইতিহাস, পরিবেশের অবস্থা। যা আপনি স্পষ্টভাবে বলেননি কিন্তু এজেন্টকে জানা উচিত। উদাহরণস্বরূপ, আপনি এজেন্টকে বলছেন “আমার জন্য জনকে ইমেইল করে আগামীকালের মিটিংটি নিশ্চিত করুন”, এটি জানা উচিত যে আপনার ক্যালেন্ডারে আগামীকালের মিটিংটি কী, এবং আপনি এবং জনের মধ্যে কী সম্পর্ক।

4. চতুর্থ স্তর, ফিডব্যাক লুপ। প্রতিটি আউটপুটের পরে, এজেন্ট স্বয়ংক্রিয়ভাবে গুণগত মান মূল্যায়ন করে এবং পরবর্তী কনটেক্সট স্ট্র্যাটেজি সামঞ্জস্য করে। বইটিতে এটিকে "অটোমেটেড কনটেক্সট অপ্টিমাইজেশন" বলা হয়েছে, যা Google-এর Vertex AI Prompt Optimizer-এর প্রকৌশলগত বাস্তবায়ন।

আমি এখানে পড়ার সময় আগে লেখা “AI এজেন্টগুলি জাদু নয়” শিরোনামের প্রবন্ধটি মনে পড়ল, যেখানে একটি অভিজ্ঞতা ছিল “আপনার এজেন্টের নিয়ম দরকার, এবং অনেক নিয়ম”। এখন ফিরে তাকালে, সেই নিয়মগুলি মূলত Context Engineering-এর হাতে করা সংস্করণ ছিল, যা বইটিতে এটিকে ব্যবস্থাগতভাবে সজ্জিত করা হয়েছে।

রিফ্লেকশন: দুটি এজেন্ট একটির চেয়ে সত্যিই ভালো

এটি বইটির মধ্যে আমার জন্য সবচেয়ে বেশি ব্যবহারিক মূল্যবান প্যাটার্ন।

রিফ্লেকশনের মূল কথা সহজ: এজেন্ট কাজ শেষ করে নিজেই তা পরীক্ষা করে সমস্যা খুঁজে বের করে নিজেই সংশোধন করে। কিন্তু এটি বাস্তবায়নের পদ্ধতি গুরুত্বপূর্ণ। বইটিতে স্পষ্টভাবে বলা হয়েছে: Producer এবং Critic দুটি আলাদা Agent হতে হবে, যাদের জন্য আলাদা system prompt দেওয়া হবে। একই persona নিজের কাজ পরীক্ষা করলে অবশ্যই অন্ধবিন্দু থাকবে। আপনি যদি একই LLM-কে কোড লিখতে বলেন, তারপর নিজের লেখা কোডটি পরীক্ষা করতে বলেন, তাহলে এটি প্রায়ই “খুব ভালো” বলবে।

The book provides a complete code example.

• প্রোডিউসারের প্রম্পট হলো: “আপনি একজন Python ডেভেলপার, একটি ফ্যাক্টোরিয়াল গণনা করার ফাংশন লিখুন, যা বোর্ডার কন্ডিশন এবং এক্সেপশন প্রক্রিয়া করে।”

• ক্রিটিকের প্রম্পট হলো “আপনি একজন ক্ষুদ্রতম বিস্তারিত উচ্চ পর্যায়ের ইঞ্জিনিয়ার, যিনি কোডের প্রতিটি লাইন পরীক্ষা করেন, বাগ, স্টাইল, অবহেলিত বোর্ডার কন্ডিশন, উন্নতির জন্য সম্ভাব্য জায়গা চেক করেন। যদি পারফেক্ট হয়, তাহলে CODE_IS_PERFECT আউটপুট করুন, অন্যথায় সমস্ত সমস্যা তালিকাভুক্ত করুন”。

• এরপর একটি for লুপ: প্রোডিউসার কোড লেখে → ক্রিটিক পরীক্ষা করে → প্রোডিউসার মন্তব্য অনুযায়ী সংশোধন করে → ক্রিটিক আবার পরীক্ষা করে → যতক্ষণ না ক্রিটিক CODE_IS_PERFECT বলে বা সর্বোচ্চ পুনরাবৃত্তির সংখ্যা পৌঁছায়।

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

কোড লেখার চেয়েও বেশি ব্যবহার আছে। নিবন্ধ লেখা, পরিকল্পনা তৈরি, দলিল সারাংশ এবং যুক্তিগত সমস্যা সমাধান—Producer-Critic মডেলটি সবকিছুতেই প্রয়োগ করা যায়। বইটিতে সাতটি প্রয়োগের ক্ষেত্র উল্লেখ করা হয়েছে, যার মূল যুক্তি একই: প্রথমে উৎপাদন, তারপর পর্যালোচনা, এবং শেষে সংশোধন।

মাল্টি-এজেন্ট এতটাই জটিল হওয়া উচিত নয়

এই অধ্যায়ে আমার সবচেয়ে পছন্দের ছিল সেই ছয়টি যোগাযোগ টপোলজি। অনেকেই শুরুতেই জটিল জিনিস নিয়ে ব্যস্ত হয়, কিন্তু প্রায় সব স্থিতিতে তিনটি যথেষ্ট:

1. একক এজেন্ট (স্বাধীন কার্যাবলী): কাজটিকে পরস্পর নির্ভরশীল নয় এমন উপ-সমস্যাগুলিতে বিভক্ত করা যায়, যেখানে প্রতিটি এজেন্ট নিজের কাজ নিজেই সম্পন্ন করে। সহজ, সহজে রক্ষণাবেক্ষণযোগ্য।

2. পিয়ার-টু-পিয়ার (Peer-to-Peer): এজেন্টগুলি সরাসরি যোগাযোগ করে, কোনো কেন্দ্রীয় নিয়ন্ত্রণ নোড নেই। ডিসেন্ট্রালাইজড, ভালো ত্রুটি সহনশীলতা, একটি এজেন্ট বন্ধ হলেও সমগ্র ব্যবস্থার ক্ষতি হয় না। কিন্তু সমন্বয়ের খরচ বেশি, ব্যবস্থা বিশৃঙ্খল হয়ে যাওয়ার ঝুঁকি বেশি।

3. সুপারভাইজার (কেন্দ্রীয় সমন্বয়ক): একটি সুপারভাইজার এজেন্ট একাধিক ওয়ার্কার এজেন্টকে নিয়ন্ত্রণ করে। কাজ বণ্টন, ফলাফল সংগ্রহ এবং সংঘাত সমাধান করে। স্তরীয় কাঠামো পরিষ্কার এবং পরিচালনা সহজ। তবে সুপারভাইজার একক বিফলতা এবং কর্মক্ষমতার বাধা।

অন্য তিনটি (Supervisor-as-Tool, হায়ারার্কিক্যাল, কাস্টম মিক্সড) হল প্রথম তিনটির পরিবর্তন এবং সংমিশ্রণ। বইটিতে খুব বাস্তবসম্মতভাবে বলা হয়েছে: আপনার প্রয়োজনীয় টপোলজি আপনার কাজের জটিলতার উপর নির্ভর করে। কাজটি যত বেশি ছোট ছোট অংশে ভাগ হয়, যোগাযোগের খরচ তত বেশি হয়, এবং একটি নির্দিষ্ট সীমার পর Supervisor মডেল হায়ারার্কিক্যাল মডেলের চেয়ে বেশি দক্ষ হয়ে ওঠে।

আমার অনুভূতি হলো, অনেকে মাল্টি-এজেন্ট তৈরি করার সময় ৮০% সময় যোগাযোগ প্রোটোকলে ব্যয় করে, কিন্তু একটি বেসিক প্রশ্ন জিজ্ঞাসা করে না: এই কাজটি কি সত্যিই একাধিক এজেন্টের প্রয়োজন? বইটিতে স্পষ্টভাবে লেখা আছে, লেভেল 2-এর একক এজেন্ট + রিফ্লেকশন প্রায়শইই যথেষ্ট। লেভেল 3 হলো সেই সিচুয়েশনগুলির জন্য যেখানে একক এজেন্ট সত্যিই কাজটি করতে অক্ষম।

মেমোরি তিন স্তরের মডেল, আমি আগে অস্পষ্টভাবে অনুভব করেছিলাম কিন্তু নাম দেইনি

মেমোরি এই অধ্যায়টিতে আমি সবচেয়ে বেশি সম্পৃক্ত হয়েছিলাম, কারণ আমি যখন অবসিডিয়ান + ক্লাউড সম্পর্কে সেই দুটি নিবন্ধ লিখছিলাম, তখন আমি একটি প্রশ্নের উপর ধ্যান দিচ্ছিলাম: এজেন্টের মেমোরি কীভাবে স্তরবদ্ধ করা উচিত?

বইয়ে উত্তর দেওয়া হয়েছে:

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

2. স্টেট (অবস্থা স্তর): বর্তমান কাজের সময় অস্থায়ী ডেটা। যেমন: “বর্তমানে কোন কাজ করা হচ্ছে”, “কতটা সম্পন্ন হয়েছে”, “মধ্যবর্তীতে কোন ডেটা তৈরি হয়েছে”। সেশনের চেয়ে দীর্ঘ, কিন্তু কাজ শেষ হলে পরিষ্কার করে দেওয়া হয়। বইটিতে Google ADK-এর স্টেট মেকানিজম ব্যবহার করে একটি পূর্ণাঙ্গ উদাহরণ দেওয়া হয়েছে।

3. মেমোরি (পারসিস্টেন্ট লেয়ার): সেশন এবং টাস্কের মধ্যে দীর্ঘমেয়াদী মেমোরি। ব্যবহারকারীর পছন্দ, শেখা অভিজ্ঞতা, গুরুত্বপূর্ণ ঐতিহাসিক সিদ্ধান্তগুলি ডাটাবেস বা ভেক্টর স্টোরে সংরক্ষণ করা হয়, যেখানে সেমান্টিক রিট্রিভাল করা হয়। বইটিতে একটি খুব গুরুত্বপূর্ণ বিষয় উল্লেখ করা হয়েছে: মেমোরি শুধু সংরক্ষণ করা নয়, বরং “কী সংরক্ষণ করবেন, কখন সংরক্ষণ করবেন, কীভাবে রিট্রিভ করবেন” – এই সম্পূর্ণ কৌশলটি ডিজাইন করা দরকার। অতিরিক্ত সংরক্ষণ করলে নয়েজ বেশি হয়, আবার খুব কম সংরক্ষণ করলে পর্যাপ্ত হয় না।

আমি আগের Clawdbot নিবন্ধে "স্টেট ফাইল" এবং "ওয়ার্কস্পেস ডকুমেন্ট" উল্লেখ করেছিলাম, যা মূলত হাতে করে State লেয়ার এবং Memory লেয়ার তৈরি করার কথা বলছিল, বইটি এই কাজটিকে ফ্রেমওয়ার্ক করেছে।

পাঁচটি অনুমান, পঞ্চমটি সবচেয়ে অবাস্তব

বইয়ের শেষে এজেন্টের ভবিষ্যতের পাঁচটি অনুমান উল্লেখ করা হয়েছে, প্রথম চারটি এখনও যুক্তিসঙ্গত অনুমানের সীমার মধ্যে: জেনারিক এজেন্ট কোডিং থেকে প্রজেক্ট ম্যানেজমেন্ট পর্যন্ত, গভীরভাবে ব্যক্তিগতকৃত এজেন্ট আপনার প্রয়োজনীয়তা সক্রিয়ভাবে শনাক্ত করবে, এমবডিড ইন্টেলিজেন্স স্ক্রিন ছাড়িয়ে ভৌত বিশ্বে প্রবেশ করবে, এবং এজেন্ট একটি স্বাধীন অর্থনৈতিক সত্তা হয়ে উঠবে।

পঞ্চমটি আমাকে আশ্চর্য করে দিল: ডিফর্মেবল মাল্টি-এজেন্ট।

আপনি শুধু লক্ষ্য ঘোষণা করেন, যেমন: “একটি প্রিমিয়াম কফি ই-কমার্স ব্যবসা শুরু করুন।” সিস্টেম নিজেই সিদ্ধান্ত নেয়: প্রথমে “বাজার গবেষণা এজেন্ট” এবং “ব্র্যান্ড এজেন্ট” তৈরি করুন। এক চক্র ডেটা চালানোর পর, সিস্টেম নিজেই বুঝতে পারে যে “ব্র্যান্ড এজেন্ট” প্রয়োজন নেই, এবং এটিকে তিনটি নতুন এজেন্টে বিভক্ত করে: “লোগো ডিজাইন এজেন্ট”, “ওয়েবসাইট তৈরি এজেন্ট”, “সাপ্লাই চেইন এজেন্ট”। যদি “ওয়েবসাইট তৈরি এজেন্ট” বাধা হয়ে দাঁড়ায়, সিস্টেম স্বয়ংক্রিয়ভাবে তিনটি সম songালীভাবে কাজ করা এজেন্ট কপি করবে, যারা ভিন্ন ভিন্ন পৃষ্ঠা তৈরি করবে। পুরো প্রক্রিয়াটির মধ্যে, সিস্টেম প্রতিটি এজেন্টের prompt-এর স্বয়ংক্রিয়ভাবে অপটিমাইজেশন করতে থাকবে, এবং টিমের কাঠামোকে নিয়মিতপ্রকারে পুনর্গঠন করবে।

বইটিতে এটিকে "লক্ষ্য-প্রেরিত, স্ব-রূপান্তরিত মাল্টি-এজেন্ট সিস্টেম" বলা হয়েছে। এটি আপনার লিখিত পরিকল্পনা বাস্তবায়ন করছে না, বরং নিজেই পরিকল্পনা তৈরি করছে, নিজেই পরিকল্পনা সামঞ্জস্য করছে এবং নিজেই বাস্তবায়ন দলকে পুনর্গঠন করছে।

এটি কারপাথির অটোরিসার্চকে মনে করিয়ে দেয়: একটি program.md লিখুন, যেখানে লক্ষ্য, মাপকাঠি, সীমানা সংজ্ঞায়িত করা হয়, তারপর “শুরু” করুন। মানুষ চক্রের বাইরে। কিন্তু এই বইটি আরও এগিয়ে যায়: এজেন্ট দলকে কীভাবে গঠন করা হবে বা পুনর্গঠন করা হবে, সেটাও সিস্টেমের উপর ছেড়ে দেওয়া হয়েছে। মানুষ শুধু “কী চায়” তা ঘোষণা করে।

যা আপনি তাত্ক্ষণিকভাবে করতে পারেন তা তিনটি

এই বইটি পড়ে আমার তিনটি তাৎক্ষণিকভাবে বাস্তবায়নযোগ্য কাজ রয়েছে:

• প্রথমে, আপনার বর্তমান Agent-এর জন্য একটি Critic যোগ করুন। আপনি যদি Claude Code, CrewAI বা নিজের তৈরি করা কোনো ফ্রেমওয়ার্ক ব্যবহার করেন, তাহলে আপনার বর্তমান workflow-এর শেষে একটি ধাপ যোগ করুন: অন্য একটি Agent (ভিন্ন system prompt ব্যবহার করে) পূর্ববর্তী ধাপের আউটপুট পরীক্ষা করুন। কোড জেনারেশনের সাথে কোড রিভিউ, লেখা লেখার সাথে তথ্য যাচাই, পরিকল্পনা তৈরির সাথে সম্ভাব্যতা মূল্যায়ন। একবার LLM-এর কল বেশি, কিন্তু গুণগত উন্নতি প্রায় দ্বিগুণ। বইয়ের Producer-Critic মডেলটি প্লাগ-অ্যান্ড-প্লে।

• দ্বিতীয়ত, শুধু Prompt Engineering নয়, Context Engineering শুরু করুন। আপনি যে নির্দেশনা ফাইলটি Agent-এর জন্য লিখেছেন, তাকে পুনরায় দেখুন। যদি সেখানে শুধু “আপনাকে কী করতে হবে” এমন নিয়ম থাকে এবং “আপনি এখন কোন পরিস্থিতিতে রয়েছেন” এমন প্রেক্ষাপট না থাকে, তবে তা যোগ করুন। Agent-কে বলুন যে সে এখন কোন প্রকল্পের মধ্যে আছে, আগে কী কী সিদ্ধান্ত নিয়েছে, এবং ব্যবহারকারীর পছন্দগুলি কী। বইয়ের Context Engineering-এর অধ্যায়টি এবং আপনার AGENTS.md একই বিষয়ের দুটি বিবৃতি।

• তৃতীয়ত, এখনই Multi-Agent-এ যাওয়ার চেষ্টা করবেন না। আপনার একক Agent-কে Level 2-এ পৌঁছান: এটিতে টুল, Reflection এবং Memory থাকা দরকার। বইটিতে বারবার উল্লেখ করা হয়েছে যে, Level 2-এর একক Agent-এ Producer-Critic এবং Context Engineering যোগ করলে বেশিরভাগ বাস্তব পরিস্থিতি কভার করা যায়। Level 3 হল সত্যিকারের বহু-ক্ষেত্র, বহু-পর্যায় এবং সমান্তরালভাবে বিভাজনের প্রয়োজনীয়তা বিশিষ্ট কাজের জন্য। অধিকাংশের সমস্যা হল Agent-এর সংখ্যা যথেষ্ট নয়, বরং একটি Agent-ও ঠিকমতো সেটআপ করা হয়নি।

এই বইটি ৪৫৩ পৃষ্ঠার, স্প্রিঙ্গার, ২০২৫। কোড উদাহরণগুলি ল্যাঙ্গচেইন/ল্যাঙ্গগ্রাফ, গুগল এডিকে, ক্রিউএআই, ওপেনএআই এপিআই কভার করে। ভূমিকা লিখেছেন গুগল ক্লাউড এআই ভিপি, এবং গোল্ডম্যান স্যাক্সের সিআইও-এর পরিচয়ও রয়েছে, যা অপ্রত্যাশিতভাবে দারুণ।

কিন্তু আমি এটিকে সুপারিশ করি কারণ এটি “সম্পূর্ণ” নয়। আপনি যখন এটি পড়বেন, তখন একটি বিষয় বুঝতে পারবেন: আপনি গত ছয় মাসে Agent-এ যে সমস্যাগুলির সম্মুখীন হয়েছেন, সেগুলির সবগুলিরই একটি প্যাটার্ন হিসেবে সংগ্রহ করা হয়েছে। আপনাকে Reflection আবিষ্কার করতে হবে না, Memory-এর স্তরীকরণ কীভাবে করবেন তা অনুমান করতে হবে না, Multi-Agent-এর জন্য কোন যোগাযোগ টপোলজি ব্যবহার করবেন তা পরীক্ষা করতে হবে না।

আপনার জন্য একটি মানচিত্র আঁকা হয়েছে, বাকিটা হল হাঁটা।

আপনি কি AI এজেন্ট ব্যবহার করে ডেভেলপমেন্ট করছেন? আপনার বর্তমান এজেন্ট কোন লেভেলে পৌঁছেছে?